Почему команды данных борются с проверкой данных (и как это изменить)

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

Вы знаете старую поговорку: «Мусор на входе, мусор на выходе»? Скорее всего, вы слышали эту фразу в отношении гигиены ваших данных. Но как исправить мусор, связанный с плохим управлением данными и их качеством? Ну, это сложно. Особенно, если у вас нет контроля над внедрением кода отслеживания (как в случае со многими группами данных).

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

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

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

Во-первых, почему группы данных испытывают трудности с проверкой данных?

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

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

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

Мораль этой истории? Никто не выигрывает, когда проверка данных откладывается на второй план.

К счастью, эти проблемы можно преодолеть с помощью хороших методов проверки данных. Давайте более подробно рассмотрим каждую болевую точку.

Группы обработки данных часто не контролируют сам сбор данных.

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

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

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

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

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

Это подводит нас к следующему пункту.

Группы обработки данных (и их организации) часто не имеют установленных процессов проверки данных для аналитики.

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

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

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

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

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

Чтобы преодолеть этот «дикий запад» управления данными и обеспечить надлежащее управление данными, группы обработки данных должны разработать процессы, определяющие, когда, где и как данные следует тестировать в упреждающем режиме. Это может показаться устрашающим, но на самом деле тестирование данных может легко вписаться в существующий жизненный цикл разработки программного обеспечения (SDLC), инструменты и конвейеры CI/CD.

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

Специалисты по работе с данными и инженеры полагаются на методы реактивного, а не упреждающего тестирования данных.

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

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

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

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

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

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

Упреждающая проверка данных означает использование правильных инструментов и процессов тестирования на каждом этапе конвейера данных:

• В клиенте с такими инструментами, как Amplitude, для обеспечения безопасности типов, модульного тестирования и A/B-тестирования.
• В разработке находятся такие инструменты, как Amplitude, Segment Protocols и репозиторий схем Snowplow с открытым исходным кодом Iglu для проверки схемы, а также другие инструменты для тестирования интеграции и компонентов, проверки актуальности и тестов распределения.
• На складе с такими инструментами, как dbt, Dataform и Great Expectations, чтобы использовать схематизацию, тестирование безопасности, тестирование взаимосвязей, тестирование свежести и распространения, а также проверку диапазона и типа.

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

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

Как изменить валидацию данных для аналитики в лучшую сторону

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

Все в организации получают выгоду от качественного сбора и проверки данных, от клиента до хранилища.

Чтобы управлять этим, вам нужны три вещи:

1. Руководство сверху вниз от руководителей данных и руководства компании , которое устанавливает процессы для обслуживания и использования данных в бизнесе.
2. Пропаганда данных на всех уровнях компании , чтобы каждая команда понимала, как данные помогают им выполнять свою работу лучше, и как регулярное тестирование способствует этому.
3. Рабочие процессы и инструменты для эффективного управления вашими данными , будь то внутренний инструмент, сочетание таких инструментов, как Segment Protocols или Snowplow и dbt, или, что еще лучше, встроенная в вашу платформу Analytics, такая как Amplitude. На каждом из этих шагов также важно, чтобы лидеры данных делились победами и быстро и часто продвигались к получению хороших данных. Такая прозрачность не только поможет потребителям данных увидеть, как они могут лучше использовать данные, но и поможет производителям данных (например, вашим инженерам, проводящим тестирование) увидеть плоды своего труда. Это беспроигрышный вариант.

Преодолейте проблемы с проверкой данных

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

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