Чтобы ускорить принятие решений и лучше поддерживать мониторинг метрик бизнеса, в Airbnb внедрили сертификацию всех метрик и наборов данных, написали рекомендации о проверках качества данных, но не обеспечили их выполнение. О возникшей из-за этого проблеме и её решении рассказываем к старту флагманского курса по Data Science.
Добавление проверок качества данных в конвейер стало стандартной практикой в нашем рабочем процессе инженерии данных и помогло нам обнаружить многие критические проблемы качества данных на ранних этапах конвейера.
Расскажем о проблемах, с которыми мы столкнулись при добавлении большого количества проверок данных (на качество данных, точность, полноту и аномалии) для предотвращения ошибок в данных в масштабах всей компании, и как это побудило нас создать фреймворк, чтобы добавлять проверки легко.
Проблемы
Когда мы ввели процесс сертификации аналитических данных Midas, мы создали рекомендации о том, какие проверки качества данных необходимо добавить, но не обеспечили их выполнение. В результате каждая команда инженеров по обработке данных приняла свой собственный подход.
1. Подходы
В экосистеме аналитических данных Airbnb мы используем Apache Airflow для планирования заданий ETL или конвейеров данных. В качестве различных механизмов выполнения широко используются Hive SQL, Spark SQL, Scala Spark, PySpark и Presto. Однако, поскольку команды начали создавать одинаковые проверки качества данных в разных механизмах выполнения, мы столкнулись с другими проблемами:
Не было централизованного способа посмотреть покрытие данных проверками.
Изменение рекомендаций по проверке данных требовало изменений во множестве мест кодовой базы по всей компании.
Реализации, рассчитанные на будущее, практически невозможно было масштабировать. Команды изобретали колесо, один и тот же код распространялся по всей кодовой базе.
2. Дублирование усилий
Разным командам часто требовалось создавать инструменты, отвечающие их собственным требованиям к различным проверкам данных. Каждая команда Data Engineering начала создавать инструменты проверки данных отдельно от других. Хотя инструменты надёжно работали и удовлетворяли потребности бизнеса, такой подход был проблематичным по нескольким причинам:
Мы начали создавать несколько фреймворков параллельно.
Системы проверки данных стали дорогостоящими в обслуживании и привели к накладным расходам.
Недостающие функции и отсутствие гибкости/расширяемости затрудняли повторное использование.
3. Сложный код DAG Airflow
Каждая проверка была добавлена как отдельная задача в Airflow, как часть конвейера ETL. Файлы Airflow DAG вскоре стали огромными. Операционные накладные расходы на эти проверки выросли до такой степени, что их стало трудно поддерживать:
Не было поддержки блокирующих и неблокирующих проверок. Незначительные сбои при проверке или ложные срабатывания часто блокировали SLA критически важных конвейеров данных.
Логика ETL и проверки данных тесно сплелись и стали непригодными для повторного использования.
Обслуживание стало сложным с операционной точки зрения: мы отслеживали зависимости вручную, что также затрудняло добавление проверок.
Определение требований
Чтобы устранить эти недостатки инструментария, мы задались целью создать единый фреймворк проверки данных, который отвечал бы следующим требованиям и обеспечивал бы более высокую степень удобства использования:
Расширяемость: в Airbnb используется методология проверки данных Unify.
Управление через конфигурацию: определение проверок в виде файлов в формате YAML для ускорения разработки.
Простота: упрощённый интерфейс для ускоренного внедрения в масштабах компании.
Фреймворк Wall
Wall — способ писать автономные проверки качества данных. Это основа, призванная защитить наши аналитические решения от ошибок в плохих данных и обеспечить достоверность данных по всему Airbnb. Wall написан на языке Python поверх Apache Airflow. Пользователи могут добавлять проверки качества данных в свои группы Airflow DAG, написав простой файл конфигурации и вызвав в своей группе DAG вспомогательную функцию.
Wall предоставляет большинство имеющихся в компании механизмов проверки качества и обнаружения аномалий в рамках общей структуры, что значительно облегчает стандартизацию проверок данных.
Он поддерживает шаблонизированную пользовательскую бизнес-логику на основе SQL, проверки точности и расширяемую библиотеку предопределенных проверок.
Wall управляется конфигурацией — для добавления проверок не требуется код.
Проверки могут использоваться в конвейере ETL по схеме Stage-Check-Exchange или как отдельные проверки.
Фреймворк можно расширять — любая команда может добавить свои специфические для команды проверки в Wall довольно легко, следуя модели с открытым исходным кодом (по согласованию с командой Data Engineering Paved Path).
Бизнес-пользователи могут легко добавлять проверки качества без создания DAG Airflow или задач для каждой проверки.
Wall заботится о проверках на основе SQL и создании задач по обнаружению аномалий. Он также заботится о создании задач стадии и обмена и установке соответствующих зависимостей от проверок в отделенной манере. Поэтому после перехода на Wall конвейеры ETL были значительно упрощены, и мы наблюдали случаи, когда удавалось избавиться более чем от 70 % кода DAG.
Архитектура Wall
В соответствии с нашими ключевыми требованиями фреймворк можно расширять. Он состоит из трёх основных компонентов — WallApiManager, WallConfigManger и WallConfigModel.
WallApiManager
Wall Api Manager — это публичный интерфейс для организации проверок и обменов с помощью Wall. Пользователи Wall используют это только из своих файлов DAG. Он принимает на вход путь к папке config и поддерживает широкий спектр ETL-операций, таких как Spark, Hive и т. д.
WallConfigManager
Wall Config Manager анализирует и проверяет файлы конфигурации проверки, а затем вызывает соответствующие модели CheckConfigModels для создания списка задач Airflow. Wall в основном использует проверки Presto для генерации проверок данных.
CheckConfigModel
Каждая проверка — это отдельный класс, который наследуется от BaseCheckConfigModel. Классы CheckConfigModel в основном отвечают за проверку параметров и генерацию заданий Airflow для проверки. CheckConfigModel делает фреймворк расширяемым. Различные команды могут добавлять свои собственные CheckConfigModel, если существующие модели не поддерживают их сценарии использования.
Основные характеристики
Wall обеспечил следующие ключевые особенности, о которых мы говорили выше.
Гибкость
Конфигурации могут быть расположены в том же репозитории, где команды уже определяют свои DAG конвейеров данных — команды или владельцы DAG могут решить, где они будут расположены. Команды могут использовать либо отдельный файл YAML для каждой таблицы, либо один файл YAML для группы таблиц для определения проверок.
Каждая модель конфигурации проверки может определять произвольный набор параметров и при необходимости переопределять параметры. Одни и те же конфигурации проверки могут быть оркестрованы, а также могут выполняться по-разному в зависимости от контекста работы, т. е. как часть stage-check-exchange ETL или в качестве предварительных и пост-проверок.
Свойство проверки может быть иерархическим (т. е. он может быть определено на уровне команды, файла, таблицы или на уровне проверки). Значения свойств нижнего уровня переопределяют значения верхнего уровня. Команды могут определять настройки по умолчанию на уровне команды в общем файле YAML вместо дублирования одних и тех же конфигураций и проверок в разных файлах.
В случае проверок stage-check-exchange пользователи могут указать блокирующие и неблокирующие проверки. Это делает Wall гибче в адаптации новых проверок.
Расширяемость
Новый тип проверки модели легко адаптировать к работе. Wall поддерживает широко используемые механизмы проверки/валидации данных.
Каждая модель конфигурации проверки отделена от другой и может определять свой собственный набор параметров, валидаций, логику генерации проверки, предварительную обработку и т. д.
Модели контрольных конфигураций могут быть разработаны сообществом инженеров данных при сотрудничестве с командой Data Engineering Paved Path.
Простота
Простота копирования-вставки для применения аналогичных проверок в различных таблицах или контекстах.
Модели проверки интуитивно понятны.
Проверки отделены от определения DAG и конвейера ETL, поэтому их можно обновлять без обновления ETL.
Легко проверить всё сразу.
Добавление проверки Wall
На самом высоком уровне, чтобы организовать конвейер ETL с проверкой данных, пользователям необходимо написать конфигурацию YAML и вызвать API Wall из своей группы DAG.
Вот насколько легко добавить проверку: предположим, вы хотите проверить, что раздел таблицы foo.foo_bar в wall_tutorials_00 DAG не пуст. Сделать это можно так:
Выберите папку для добавления конфигураций проверки, например projects/tutorials/dags/wall_tutorials_00/wall_checks. Создайте в этой папке конфигурацию проверки (например foo.foo_bar.yml) с таким содержанием:
primary_table: foo.foo_bar
emails: ['subrata.biswas@airbnb.com']
slack: ['#subu-test']
quality_checks:
- check_model: CheckEmptyTablePartition
name: EmptyPartitionCheckФайл DAG wall_tutorials_00.py обновляется, чтобы создать прверки на основе конфигурации.
from datetime import datetime
from airflow.models import DAG
from teams.wall_framework.lib.wall_api_manager.wall_api_manager import WallApiManager
args = {
"depends_on_past": True,
"wait_for_downstream": False,
"start_date": datetime(2020, 4, 24),
"email": ["subrata.biswas@airbnb.com",],
"adhoc": True,
"email_on_failure": True,
"email_on_retry": False,
"retries": 2,
}
dag = DAG("wall_tutorials_00", default_args=args)
wall_api_manager = WallApiManager(config_path="projects/tutorials/dags/wall_tutorials_00/wall_checks")
# Invoke Wall API to create a check for the table.
wall_api_manager.create_checks_for_table(full_table_name="foo.foo_bar", task_id="my_wall_task", dag=dag)Валидация и тестирование
Теперь в списке задач wall_tutorials_00 вы увидите такие, созданные Wall задачи:
<Task(NamedHivePartitionSensor): ps_foo.foo_bar___gen>
<Task(SubDagOperator): my_wall_task>Wall создал задачу SubDagOperator и NamedHivePartitionSensor для таблицы в основном DAG (wall_tutorials_00) и инкапсулировал проверки в подграф. Чтобы получить список задач, вам нужно посмотреть задачи подграфа, т. е. выполнить list_tasks для wall_tutorials_00.my_wall_task dag. Вернётся такой список:
<Task(WallPrestoCheckOperator): EmptyPartitionCheck_foo.foo_bar>
<Task(DummyOperator): group_non_blocking_checks>
<Task(DummyOperator): foo.foo_bar_exchange>
<Task(DummyOperator): group_blocking_checks>
<Task(DummyOperator): foo.foo_bar_exchange>
<Task(PythonOperator): validate_dependencies>Вероятно, вы заметили, что Wall создал в подграфе несколько задач DummyOperator и одну задачу PythonOpearator. Это требовалось, чтобы обслуживать потоки выполнения, то есть блокирующие и неблокирующие проверки, зависимости, валидацию и т. п. Эти задачи можно игнорировать, а также удалить или изменить в будущем: у них нет зависимостей.
Протестировать задачу проверки можно как задачу Airflow:
airflow test wall_tutorials_00.my_wall_task EmptyPartitionCheck_foo.foo_bar {ds}Wall в экосистеме данных Airbnb
Интегрировать Wall с другими инструментами экосистемы данных Airbnb было критически важно для долгосрочного успеха. Чтобы инструменты интегрировались легко, мы опубликовали результаты этапа «check» как события Kafka, на которые другие инструменты могут подписаться. Диаграмма ниже показывает интеграцию инструментов с Wall:
Заключение
Wall обеспечивает соответствие высоким стандартам качества данных Airbnb, благодаря ему планка стандартов не снижается. Включение стандартизованных, но расширяемых проверок, которые легко распространить на нашу распределённую организацию инженерии данных, обеспечивает всей компании надёжные, заслуживающие доверия данные.
Чтобы не дублировать усилия в изучении науки о данных, вы можете обратить внимание на наш флагманский курс, где вы научитесь решать проблемы бизнеса. Также вы можете перейти на страницы других курсов, чтобы узнать, как мы готовим специалистов в других направлениях IT.
Другие профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также:
