Как да проверявате данни, анализи и визуализации на данни

Тестването на приложения е дисциплина за съзряване с инструменти, които помагат на екипите за осигуряване на качеството да разработят и автоматизират функционални тестове, да изпълняват тестове за натоварване и производителност, да извършват статичен анализ на кода, да обгръщат API с модулни тестове и да валидират приложенията срещу известни проблеми със сигурността. Екипите, практикуващи devops, могат да реализират непрекъснато тестване, като включват всички или подгрупа от техните автоматизирани тестове в своите CI / CD тръбопроводи и използват резултатите, за да определят дали дадена компилация трябва да бъде доставена до целевата среда.

Но всички тези възможности за тестване могат лесно да игнорират един важен набор от тестове, който е критичен за всяка обработка на приложения или представяне на данни, анализи или визуализации на данни.

Точни ли са данните и валидни ли са анализите? Визуализациите на данни показват ли резултати, които имат смисъл за специалистите по темата? Освен това, тъй като екипът прави подобрения в тръбопроводите за данни и базите данни, как трябва да гарантират, че промените не навредят на приложение или табло за управление надолу по веригата?

Според моя опит в разработването на богати на данни и анализи приложения, този тип тестване и валидиране често е втора мисъл в сравнение с тестовете за единица, функционалност, производителност и сигурност. Също така е по-труден набор от критерии за тестване, поради няколко причини:

  • Валидирането на данни и анализи е трудно за разработчици, тестери и изследователи на данни, които обикновено не са експерти по темата, особено за това как се използват таблата и приложенията за разработване на прозрения или стимулиране на вземането на решения.
  • Данните сами по себе си са несъвършени, с известни и често неизвестни проблеми с качеството на данните.
  • Опитът за улавяне на правила за валидиране не е тривиален, защото често има общи правила, които се прилагат за повечето данни, последвани от правила за различни видове отклонения. Опитът за улавяне и кодиране на тези правила може да бъде трудно и сложно предложение за приложения и визуализации на данни, които обработват големи обеми от сложни набори от данни.
  • Активните организации, управлявани от данни, зареждат нови набори от данни и развиват тръбопроводи за данни, за да подобрят анализа и вземането на решения.
  • Системите за обработка на данни често са сложни, с различни инструменти за интегриране, управление, обработка, моделиране и предоставяне на резултати.

Екипите, които за първи път представят лоши данни или невалидни анализи на заинтересованите страни, обикновено е първият сигнал за събуждане, че техните практики и инструменти може да са необходими за тестване, диагностика и решаване на тези проблеми с данни активно.

Разбиране на линията на данни и качеството на данните

Проблемите с данните се решават най-добре при техните източници и чрез различните трансформации на данни, извършени при зареждане и обработка на данните. Ако изходните данни имат нови проблеми с качеството на данните или ако има дефекти, въведени в конвейера за данни, е много по-ефективно да ги идентифицирате и разрешите в началото на конвейера за обработка на данни.

Две практики и свързаните с тях инструменти помагат при тези проблеми. И двете позволяват на екипите за разработка и данни да идентифицират проблеми с данните, преди да достигнат до визуализации на данни надолу по веригата и приложения.

Първата практика включва инструменти за качество на данните, които често са допълнителни възможности за извличане, трансформиране и зареждане (ETL), както и някои инструменти за подготовка на данни. Инструментите за качество на данните служат за множество цели, но едно нещо, което могат да направят, е да идентифицират и коригират известни проблеми с данните. Някои корекции могат да бъдат автоматизирани, докато други могат да бъдат маркирани като изключения и изпратени до администраторите на данни за коригиране ръчно или за актуализиране на правилата за почистване.

Informatica, Talend, IBM, Oracle, Microsoft и много други предлагат инструменти за качество на данните, които се включват в техните ETL платформи, докато инструментите за подготовка на данни от Tableau, Alteryx, Paxata, Trifacta и други имат възможности за качество на данните.

Втората практика е родословието на данните. Докато качеството на данните помага да се идентифицират проблеми с данните, родословието на данни е набор от практики и инструменти, които проследяват промените в данните и основните внедрения. Те помагат на потребителите да разберат къде в жизнения цикъл на данните е приложена трансформация, изчисление или друга манипулация на данни. Инструментите, отчетите и документацията за линията на данни могат след това да се използват за проследяване обратно в тръбопровод за данни и да помогнат да се определи къде в потока от данни е бил въведен дефект или друг проблем.

Използване на златни набори от данни за валидиране на визуализации на данни

Анализът, таблата за управление и визуализациите на данни не работят със статични източници на данни. Данните се променят с известна скорост и в същото време разработчиците и изследователите на данни може да променят основните потоци от данни, алгоритми и визуализации. Когато разглеждате табло за управление, е трудно да отделите дали непредвиденият проблем с данните се дължи на програмна промяна или дали е свързан с данни или промени в качеството на данните.

Един от начините за изолиране на промените е да се отдели известен златен набор от данни, за да се утвърдят промените в потока от данни, приложението и визуализацията на данните. Използвайки златен набор от данни, тестващият екип може да дефинира модулни, функционални и тестове за ефективност, за да валидира и сравнява резултатите. Тестерите могат да изпълняват A / B тестове, където A е резултатът преди въвеждането на промените в изпълнението и B е резултатът след направените промени. Тестът трябва да показва разлики в изхода в очаквани области, където потоците от данни, модели, анализи, бизнес логика или визуализации са били променени.

Въпреки че това е относително проста концепция, не е тривиално да се приложи.

Първо, екипите трябва да създадат златните набори от данни и да решат какъв обем и разнообразие от данни представлява изчерпателен набор от извадки за тестване. Той може също да изисква множество набори от данни, за да помогне за валидиране на различни сегменти от данни, гранични условия или аналитични модели. Един инструмент, който може да помогне на екипите да управляват тестови данни, е Delphix за управление на тестови данни; други доставчици също предлагат тази възможност.

Второ, след като бъдат създадени златни набори от данни, екипите за тестване може да изискват допълнителни среди или инструменти за превключване на основните източници на данни в техните среди. Например тестерите може да искат да тестват срещу златните набори от данни, след което да изпълнят втори път срещу данни, които са реплика на производствени данни. Екипите, работещи в облачни среди и използващи инструменти като инфраструктура като код като Puppet, Chef и Ansible, могат да създадат и разрушат множество среди за тестване за тези различни цели.

И накрая, екипите за тестване се нуждаят от инструменти за прилагане на A / B тестване на данни и резултати. Много екипи, които познавам, правят това ръчно, като пишат SQL заявки и след това сравняват резултатите. Ако наборите данни и тестовете са прости, този подход може да е достатъчен. Но ако трябва да бъдат тествани множество точки в потока от данни, вероятно се нуждаете от специализирани инструменти за централизиране на тестовите заявки, автоматизирането им и използването на отчети за потвърждаване на промените. Един инструмент, QuerySurge, е специално проектиран за внедряване на A / B тестване спрямо потоци от данни, бази данни и някои инструменти за бизнес разузнаване.

Ефективна работа с експерти по теми

В един момент трябва да привлечете експерти по темата, за да използвате нови и актуализирани визуализации на данни и да предоставите обратна връзка. Те трябва да помогнат да отговорят на въпроси дали анализът е валиден и полезен за развиване на прозрения или помощ при вземането на решения, основани на данни.

Проблемът, пред който са изправени много екипи, е да получат достатъчно време от специалистите по темата, за да участват в това тестване. Това може да бъде значително предизвикателство, когато се опитвате да тествате и внедрявате промени често.

За да използвам ефективно времето им, препоръчвам три отделни дейности:

  • Внедрете възможно най-много от качеството на данните, родословието на данни и A / B тестване на златни набори от данни. Преди да привлечете експерти по предмета, направете разумни усилия да потвърдите, че суровите и изчислени данни са верни. Това трябва да се направи с увереност, за да можете да обясните и в идеалния случай да илюстрирате на специалистите по темата, че основните данни, трансформации и изчисления са точни - така че можете да бъдете уверени, че не е необходимо да инвестират значително време, за да го тестват ръчно.
  • Проектирайте визуализации на данни, за да помогнете на експертите по темата да прегледат и валидират данните и анализа. Някои визуализации могат да бъдат резултати от A / B тестове, докато други трябва да бъдат визуализации, които излагат данни от ниско ниво. Когато се прилагат по-мащабни промени в данни, алгоритъм, модел или визуализация, често помага тези визуализации на данни за контрол на качеството да бъдат на място, за да помогнат на експертите по темата да извършват бързи проверки.
  • Искате тематични експерти да извършат тестове за приемане от потребителите (UAT) на финализираните приложения и визуализации на данни. Докато достигнат тази стъпка, те трябва да имат пълна увереност, че данните и анализите са валидни.

Тази последна стъпка е необходима, за да се определи дали визуализациите са ефективни при проучване на данните и отговаряне на въпроси: Лесна ли е визуализацията за използване? Налични ли са правилните размери за пробиване в данните? Помага ли визуализацията успешно да отговори на въпросите, на които е предназначена да отговори?

В този момент от процеса тествате потребителския опит и се уверявате, че таблата и приложенията са оптимизирани. Тази критична стъпка може да се направи много по-ефективно, когато има разбиране и доверие в основните данни и анализи.