Повышение качества данных: изучение контрактов на передачу данных с Lyft

Похоже, это вторая часть моей серии статей о качестве данных!

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

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

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

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

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

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

По этой причине мне было особенно интересно поближе познакомиться с подходом Lyft.

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

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

Airbnb разработала оценку DQ, которая фокусируется на измерении и улучшении четырех различных аспектов качества данных :

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

Verity от Lyft — это платформа, предназначенная для повышения качества данных по пяти измерениям.

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

Легко провести параллели между пятью аспектами качества данных, улучшенными с помощью Verity от Lyft, и четырьмя аспектами качества данных, измеренными с помощью показателя DQ Airbnb. Например, такие аспекты, как своевременность, безусловно, будут способствовать повышению надежности оценки DQ, тогда как точность будет зависеть от семантической правильности, полноты и уникальности данных. С другой стороны, на оценку юзабилити влияет согласованность данных среди других факторов.

Verity компании Lyft фокусируется на определении проверок , связанных с семантической правильностью, согласованностью, полнотой, уникальностью, правильностью формата и своевременностью . Он основан на подходе «сначала тестирование» и «проверка», тогда как унифицированный показатель DQ Airbnb делает упор на оценку качества данных по различным параметрам.

Если бы мы хотели включить оценку DQ в эту последнюю схему, это было бы на стороне этапов оповещения/отладки.

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

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

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

Теперь мой основной интерес лежит в левой части, в конфигурациях определений проверок, аспектах тестирования и проверки.

Как Lyft интегрирует тестирование качества данных в свои процессы?

Давайте сначала рассмотрим пути выполнения.

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

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

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

Проверки Verity можно интегрировать в Airflow DAG, чтобы гарантировать, что только высококачественные необработанные данные обрабатываются и сохраняются в Hive в качестве производных данных.

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

…

VerityAirflowOperator можно использовать в режиме блокировки для остановки DAG в случае сбоя проверки, предотвращая попадание неверных данных в рабочую среду. При этом используется « Этап-Проверка-Обмен Шаблон: мы создаем данные в поэтапной схеме, проверяем данные с помощью оператора блокировки, затем продвигаем их в производство, если они проходят проверку качества.

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

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

Таким образом, существует три основных способа запуска проверки: в рамках группы обеспечения доступности баз данных Airflow, вручную или по расписанию через платформу/пользовательский интерфейс Verity.

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

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

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

Verity API Server — этот сервис обрабатывает все внешние API, связанные с выполнением проверок, а также сохранением и получением их результатов. Сервер API не выполняет никаких проверок, а записывает сообщение в нашу очередь проверок, которая использует SimpleQueueService (СКС).

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

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

Теперь давайте посмотрим на эти тесты качества данных.

Вот пример, который проверяет, никогда ли rider_events.session_id не равен нулю. Это достигается за счет сочетания компонентов запроса и условия.

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

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

Проверка схемы не является новой концепцией. Существует несколько методов определения схем данных событий в системах, основанных на событиях, таких как схема JSON, буферы протоколов, Avro или форматы хранения, такие как Parquet. Оптимальный выбор зависит от вашего технологического стека, использования и конкретных требований.

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

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

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

Именно здесь в игру вступает Verity DSL.

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

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

Однако DSL контракта данных Verity предлагает более тонкую детализацию, определяющую небольшие независимые правила, что особенно хорошо подходит для этого контекста: семантическое значение и использование данных варьируются в зависимости от конкретного потребителя. Кроме того, не всем потребителям необходимо использовать все свойства объекта. Их ожидания различаются. Это не означает, что они противоречивы (что, безусловно, было бы проблемой), а скорее дополняют друг друга и различны.

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

И именно этот аспект сотрудничества мне особенно резонирует. Потерпите, это может показаться натяжкой, но, с моей точки зрения, об этом стоит упомянуть. :)

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

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

Ну, я большой любитель проводить параллели…

Обратите внимание, что этот аспект сотрудничества также упоминается в Хартии правдивости Lyft.

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

Мне не совсем понятно, как проблемы с контрактами данных распределяются между потребителями и производителями через пользовательский интерфейс платформы Verity, но я определенно осознаю важность сотрудничества через информационные панели:

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

• Потребитель интерфейса может быть уверен, что его доверие к интерфейсу не будет скомпрометировано.

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

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

Soda Core — это бесплатный инструмент командной строки с открытым исходным кодом и библиотека Python, которая позволяет инженерам данных проверять качество данных. Он использует определяемый пользователем ввод для создания SQL-запросов, которые проверяют наборы данных в источнике данных для поиска недействительных, отсутствующих или неожиданных данных. Если проверки завершаются неудачей, они выявляют данные, которые вы определили при проверке как «плохие».

Во время сканирования набора данных Soda Core выполняет предопределенные проверки для выявления недействительных, отсутствующих или неожиданных данных.

Вот эквивалентная проверка с использованием синтаксиса Soda.core для теста Verity DSL, который был определен ранее.

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

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

Стоит отметить, что Soda Core также может облегчить проверку качества потоковых данных за счет простой интеграции с Spark DataFrames.

Хотя проверки качества данных Verity для Hive применяются к статическим наборам данных, проверки потоковых данных должны быть более легкими и эффективными.

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

Наконец, отметим, что существуют и другие инструменты проверки данных, такие как DeeQu, Great Expectations и…

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

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

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

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

Подобно рейтингу DQ Airbnb, Verity от Lyft способствует налаживанию обратной связи между производителями и потребителями данных. Стимулируя и предоставляя каждой команде возможность взять на себя ответственность за качество данных, Verity создает благоприятную среду, в которой качество данных постоянно улучшается.

Нашли эту статью полезной? Следуй за мной Линкедин , Хакернун , и Середина ! Пожалуйста 👏 поделитесь этой статьей!