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

Автор этой статьи - Франциско Альберини, продакт-менеджер в Monte Carlo и бывший продакт-менеджер в Segment.

Существует миллион разных причин, по которым могут возникать сбои в работе конвейеров данных, и нет ни одного универсального подхода, помогающего сразу понять, как и почему они случаются. В этой статье я расскажу вам о пяти шагах, которые нужно совершить дата-инженеру, чтобы провести анализ первопричин (Root Cause Analysis - RCA) проблем с качеством и пригодностью данных (Data Quality).

Хоть я и не могу знать наверняка, но я уверен, что многие из нас оказывались в такой ситуации.

Я говорю о наполненном тревогой и отчаянием сообщении в Slack во второй половине дня, которое выглядит примерно так:

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

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

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

2. Если она была недоступна, то часами дебажить этот конвейер, выборочно сверяя одну с одной тысячи таблиц.

Думаю, что суть вы уловили.

За годы общения и совместной работы с десятками команд дата-инженеров, я узнал, что проведение анализа первопричин (RCA) проблем с качеством данных может быть либо не сложнее просмотра логов Airflow, либо представлять из себя глубокий анализ 5 и более систем, чтобы в конце концов выяснить, что поставщик данных добавил парочку пробельных символов в конце значений нескольких записей.

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

Что нужно для продуктивного анализа первопричин?

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

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

Например, одной из самых распространенных причин даунтайма данных является их свежесть, т.е. когда мы получаем сильно устаревшие данные. Это может произойти по ряду причин, куда входят: зависание задачи в очереди, тайм-аут, партнер, который вовремя не поставил свой набор данных, ошибка или случайное изменение расписания, в результате которого задачи были удалены из DAG (Directed Acyclic Graph - ориентированный/направленный ациклический граф).

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

1. Неожиданное изменение данных, поступающих в задачу, конвейер или систему;

2. Изменение логики (ETL, SQL, задачи Spark, и т. д.) преобразование данных

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

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

Ваши действия должны быть следующими.

Шаг 1. Проверьте ваш lineage.

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

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

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

Выводы. Убедитесь, что вся команда (дата-инженеры, дата-аналитики, инженеры-аналитики и дата-сайентисты), в чью работу входит поиск и устранение проблем с данными, имеют доступ к самой последней версии lineage ваших данных. Ваш lineage должен быть информативным и включать результаты обработки данных, такие как отчеты бизнес-аналитиков, модели машинного обучения или reverse-ETL воронки. Lineage нижнего уровня - это плюс.

Шаг 2. Проверьте ваш код.

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

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

• Какой код последний раз обновлял таблицу? И когда?

• Как вычисляются релевантные поля? Что в этой логике могло создать “неправильные” данные?

• Были ли в последнее время какие-либо изменения в логике, которые потенциально могли создать проблему?

• Вносились ли в таблицу специальные записи?

• Как давно с ней происходило обратное заполнение (backfilling)?

  

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

Шаг 3. Проверьте ваши данные.

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

Спросите себя:

• Данные неверны за какой-то определенный период времени?

• Ошибка данных возникла в конкретном подклассе или сегменте данных, например, только у ваших пользователей Android или только в заказах из Франции?

• Есть ли новые сегменты данных (которые еще не учитываются в вашем коде…) или отсутствующие сегменты (которые используются в вашем коде…)?

• Вносились ли изменения в схему за последнее время таким образом, что это объяснило проблему?

• Может быть ваши денежные единицы изменились с долларов на центы? Ваши таймстэмпы с PST на EST?

И список продолжается.

Одним из наиболее многообещающих подходов к выявлению проблем является изучение того, как другие поля в таблице с аномальными записями могут указывать на то, где происходит аномалия данных. Например, моя команда недавно обнаружила, что в важной таблице Users по одному из наших пользователей произошел резкий скачок количества null в поле user_interests. Мы посмотрели на поле источника (Twitter, FB, Google), с целью увидеть,  укажет ли эта связь правильное направление.

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

1. Доля записей, у которых source="Twitter" значительно выросла, вместе с чем естественным образом выросло и количество записей с user_interests="null", которые характерны для данного источника.

2. Для записей с source="Twitter" увеличилась доля записей с user_interests="null", в то время как сам объем записей с source=”Twitter” остался без изменений.

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

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

Шаг 4. Проверьте вашу операционную среду.

Хорошо, данные проверены. Что дальше? Многие проблемы с данными являются прямым результатом операционной среды, в которой выполняются ваши ETL/ELT задачи (джобы).

Просмотрите логи и трассировки ошибок из ваших ETL движков - это поможет вам ответить на некоторые из следующих вопросов:

• Были ли какие-либо ошибки в соответствующих задачах?

• Были ли необычные задержки во время запуска задач?

• Вызывали ли задержки какие-либо длительные запросы или низкоэффективные задачи?

• Были ли какие-либо проблемы с разрешениями, сетью или инфраструктурой, влияющие на выполнение? Вносились ли в них в последнее время какие-либо изменения?

• Были ли какие-либо изменения в расписании задач, по причине которых задача могла быть случайно пропущена или потеряна в дереве зависимостей?

  

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

Шаг 5. Задействуйте своих коллег.

Вы перепробовали все возможное (или, может быть, вы сразу хотите пойти легким путем) - что дальше? Вам следует попросить помощь у вашей команды. Но прежде чем начать бомбардировать Slack вопросами, спросите себя:

• Какие аналогичные проблемы возникали в прошлом с этим набором данных? Что сделала команда, чтобы диагностировать, а затем решить эти проблемы?

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

• Кто использует набор данных, с которым сейчас возникает проблема? К кому я могу обратиться за дополнительной информацией?

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

Подведем итоги

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

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

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

Статья переведена в преддверии старта курса Data Engineer от OTUS.

• УЗНАТЬ ПОДРОБНЕЕ О КУРСЕ