Популярные методы проверки данных для аналитики и зачем они вам нужны

Примечание редактора: эта статья была первоначально опубликована в блоге Iteratively 14 декабря 2020 года.

В конце концов, ваша аналитика данных должна быть протестирована, как и любой другой код. Если вы не проверяете этот код и данные, которые он генерирует, это может быть дорогостоящим (например, 9,7 миллиона долларов в год, по данным Gartner).

Чтобы избежать этой участи, компании и их инженеры могут использовать ряд упреждающих и реактивных методов проверки данных. Мы настоятельно рекомендуем первое, как мы объясним ниже. Проактивный подход к проверке данных поможет компаниям убедиться, что имеющиеся у них данные чистые и готовы к работе.

Методы реактивной и проактивной проверки данных: решайте проблемы с данными до того, как они станут проблемой

«Унция профилактики стоит фунта лечения». Это старое высказывание верно практически в любой ситуации, включая методы проверки данных для аналитики. Другой способ сказать, что лучше быть активным, чем реактивным.

Целью любой проверки данных является определение того, где данные могут быть неточными, непоследовательными, неполными или даже отсутствовать.

По определению, реактивная проверка данных происходит постфактум и использует обнаружение аномалий для выявления любых проблем, которые могут возникнуть в ваших данных, и для облегчения симптомов неверных данных. Хотя эти методы лучше, чем ничего, они, в первую очередь, не решают основные проблемы, вызывающие неверные данные.

Вместо этого мы считаем, что команды должны стараться использовать проактивные методы проверки данных для своей аналитики, такие как безопасность типов и схематизация, чтобы гарантировать точность, полноту и ожидаемую структуру получаемых данных (и чтобы будущие члены команды не имели бороться с плохим кодом аналитики).

Хотя может показаться очевидным выбор более комплексного подхода к проверке, многие команды в конечном итоге используют реактивную проверку данных. Это может быть по ряду причин. Часто аналитический код является второстепенным для многих команд, не занимающихся данными, и поэтому остается непроверенным.

К сожалению, данные также часто обрабатываются без какой-либо проверки. Кроме того, плохой аналитический код замечают только тогда, когда он действительно плох, обычно через несколько недель, когда кто-то замечает, что отчет вопиюще неверен или даже отсутствует.

Методы реактивной проверки данных могут выглядеть как преобразование ваших данных в вашем хранилище с помощью такого инструмента, как dbt или Dataform.

Хотя все эти методы могут помочь вам решить ваши проблемы с данными (и часто с объективно отличными инструментами), они по-прежнему не помогут вам устранить основную причину ваших плохих данных (например, разрозненное управление данными или аналитику, реализованную в проекте). по проектам без общения между командами) в первую очередь, заставляя вас возвращаться к ним каждый раз.

Одной реактивной проверки данных недостаточно; вам необходимо использовать упреждающие методы проверки данных, чтобы быть действительно эффективными и избежать дорогостоящих проблем, упомянутых ранее. Вот почему:

• Данные — это командный вид спорта. Обеспечить чистоту ваших данных должен не только один отдел или один человек. Для обеспечения высокого качества данных и решения проблем до их возникновения требуется, чтобы все работали вместе.
• Проверка данных должна быть частью жизненного цикла разработки программного обеспечения (SDLC). Когда вы интегрируете его в свой SDLC и параллельно с существующей разработкой через тестирование и автоматизированным процессом контроля качества (вместо того, чтобы добавить его в качестве задним числом), вы экономите время, предотвращая проблемы с данными, а не устраняя их позже.
• Упреждающая проверка данных может быть интегрирована в ваши существующие инструменты и конвейеры CI/CD. Это легко для ваших команд разработчиков, потому что они уже вложили средства в автоматизацию тестирования и теперь могут быстро расширить ее, добавив охват аналитики.
• Упреждающее тестирование проверки данных — один из лучших способов эффективной работы быстро меняющихся команд. Это гарантирует, что они могут выполнять итерации быстро и избегать дрейфа данных и других последующих проблем.
• Упреждающая проверка данных дает вам уверенность в том, что вы можете изменять и обновлять свой код по мере необходимости, сводя к минимуму количество ошибок, которые вам придется устранять позже. Этот упреждающий процесс гарантирует, что вы и ваша команда измените только тот код, который непосредственно связан с интересующими вас данными.

Теперь, когда мы выяснили, почему проактивная проверка данных важна, возникает следующий вопрос: как вы это делаете? Какие инструменты и методы используют команды, чтобы убедиться, что их данные в порядке, прежде чем возникнут проблемы?

Давайте погрузимся.

Методы проверки данных

Проверка данных — это не просто один шаг, который происходит в определенный момент. Это может произойти в нескольких точках жизненного цикла данных — на клиенте, на сервере, в конвейере или в самом хранилище.

Это на самом деле очень похоже на тестирование программного обеспечения во многих отношениях. Однако есть одно ключевое отличие. Вы не тестируете выходные данные в одиночку; вы также подтверждаете правильность ввода ваших данных.

Давайте посмотрим, как выглядит проверка данных в каждом месте, изучив, какие из них являются реактивными, а какие — упреждающими.

Методы проверки данных в клиенте

Вы можете использовать такие инструменты, как Amplitude Data, для обеспечения безопасности типов, модульного тестирования и линтинга (статического анализа кода) для проверки данных на стороне клиента.

Теперь это отличная отправная точка, но важно понимать, какое тестирование такого рода инструментов позволяет вам выполнять на этом уровне. Вот разбивка:

• Безопасность типов — это когда компилятор проверяет типы данных и инструкции реализации в источнике, предотвращая последующие ошибки из-за опечаток или неожиданных переменных.
• Модульное тестирование — это изолированное тестирование определенного фрагмента кода. К сожалению, большинство команд не интегрируют аналитику в свои модульные тесты, когда дело доходит до проверки их аналитики.
• A/B-тестирование — это когда вы тестируете свой поток аналитики на наборе данных золотого состояния (версия вашей аналитики, которая, как вы знаете, была идеальной) или копии ваших производственных данных. Это поможет вам понять, являются ли изменения, которые вы вносите, хорошими и улучшением существующей ситуации.

Методы проверки данных в процессе разработки

Проверка данных в конвейере — это проверка того, что данные, отправляемые клиентом, соответствуют формату данных в вашем хранилище. Если они не находятся на одной странице, ваши потребители данных (менеджеры по продуктам, аналитики данных и т. д.) не получат полезной информации с другой стороны.

Методы проверки данных в пайплайне могут выглядеть так:

• Проверка схемы , чтобы убедиться, что отслеживание событий соответствует тому, что было определено в вашем реестре схем.
• Интеграция и тестирование компонентов с помощью реляционных, уникальных и суррогатных ключевых служебных тестов в таком инструменте, как dbt, чтобы убедиться, что отслеживание между платформами работает хорошо.
• Тестирование свежести с помощью такого инструмента, как dbt, чтобы определить, насколько «свежи» ваши исходные данные (то есть насколько они актуальны и здоровы).
• Распределительные тесты с помощью такого инструмента, как «Большие надежды», чтобы получать оповещения, когда наборы данных или образцы не соответствуют ожидаемым входным данным, и убедиться, что изменения, внесенные в ваше отслеживание, не испортят существующие потоки данных.

Методы проверки данных в хранилище

Вы можете использовать тестирование dbt, тестирование формы данных и большие надежды, чтобы убедиться, что данные, отправляемые в ваше хранилище, соответствуют соглашениям, которые вы ожидаете и в которых нуждаетесь. Вы также можете выполнять преобразования на этом уровне, включая проверку типов и безопасность типов в этих преобразованиях, но мы бы не рекомендовали этот метод в качестве основного метода проверки, поскольку он является реактивным.

На этом этапе методы проверки, доступные командам, включают проверку соответствия данных определенным соглашениям, а затем их преобразование в соответствии с ними. Команды также могут использовать тесты взаимосвязи и свежести с помощью dbt, а также тестирование ценности/диапазона с помощью «Больших ожиданий».

Вся функциональность этого инструмента сводится к нескольким ключевым методам проверки данных на этом уровне:

• Схематизация , чтобы убедиться, что данные и преобразования CRUD соответствуют установленным соглашениям.
• Тестирование безопасности для обеспечения соответствия данных требованиям безопасности, таким как GDPR.
• Тестирование взаимосвязей в таких инструментах, как dbt, чтобы убедиться, что поля в одной модели сопоставляются с полями в данной таблице (так называемая ссылочная целостность).
• Тестирование на свежесть и распространение (как мы упоминали в разделе конвейера).
• Проверка диапазона и типа , которая подтверждает, что данные, отправляемые клиентом, находятся в пределах ожидаемого диапазона или формата хранилища.

Отличный пример многих из этих тестов в действии можно найти, изучив механизм обнаружения и метаданных Lyft Amundsen. Этот инструмент позволяет потребителям данных в компании искать пользовательские метаданные, чтобы повысить удобство использования и безопасность. Основной метод Lyft для обеспечения качества данных и удобства использования — это своего рода управление версиями с помощью задачи Airflow по очистке графа, которая удаляет старые, дублирующиеся данные при добавлении новых данных в их хранилище.

Почему сейчас самое время использовать более совершенные методы проверки данных

В прошлом группы обработки данных испытывали затруднения с проверкой данных, потому что их организации не осознавали важность гигиены и управления данными. Это уже не тот мир, в котором мы живем.

Компании осознали, что качество данных имеет решающее значение. Просто реактивной очистки плохих данных недостаточно. Наем групп инженеров данных для очистки данных путем преобразования или написания бесконечных SQL-запросов — ненужная и неэффективная трата времени и денег.

Раньше считалось приемлемым иметь данные, точность которых составляет 80 % (плюс-минус, в зависимости от варианта использования), оставляя погрешность в 20 %. Этого может быть достаточно для простого анализа, но этого недостаточно для работы механизма рекомендаций по продуктам, обнаружения аномалий или принятия важных бизнес-решений или решений по продуктам.

Компании нанимают инженеров для создания продуктов и отличной работы. Если им приходится тратить время на работу с неверными данными, они не используют свое время по максимуму. Но проверка данных возвращает им это время, чтобы они могли сосредоточиться на том, что у них получается лучше всего: создании ценности для организации.

Хорошая новость заключается в том, что высококачественные данные находятся в пределах досягаемости. Чтобы достичь этого, компаниям необходимо помочь всем понять его ценность, разрушив разрозненность между производителями и потребителями данных. Затем компаниям следует отказаться от электронных таблиц и применить к своей аналитике лучшие инженерные методы, такие как управление версиями и схематизация. Наконец, они должны убедиться, что во всей организации соблюдаются передовые методы работы с данными, с планом отслеживания и управления данными.

Инвестируйте в упреждающую проверку аналитики, чтобы получать дивиденды от данных

В современном мире реактивных, неявных инструментов и методов проверки данных уже недостаточно. Они стоят вам времени, денег и, возможно, самое главное, доверия.

Чтобы избежать этой участи, придерживайтесь философии проактивности. Выявляйте проблемы до того, как они станут дорогостоящими проблемами, проверяя свои аналитические данные с самого начала и на протяжении всего жизненного цикла разработки программного обеспечения.