{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged Data Quality",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/data-quality\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/data-quality\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "272",
            "url": "https:\/\/gavrilov.info\/all\/novaya-era-transformacii-dannyh-dbt-protiv-bruin-i-aac\/",
            "title": "Новая эра трансформации данных: dbt против Bruin и aaC",
            "content_html": "<p>В мире данных произошла тихая, но фундаментальная революция. На смену традиционному подходу <b>ETL (Extract, Transform, Load)<\/b>, где данные преобразовывались до загрузки в хранилище, пришла новая парадигма — <b>ELT (Extract, Load, Transform)<\/b>. Благодаря мощности современных облачных хранилищ (таких как Snowflake, BigQuery, Databricks, Starburst\\Trino) стало выгоднее сначала загружать сырые данные, а уже затем трансформировать их непосредственно в хранилище.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/demo.gif\" width=\"1200\" height=\"900\" alt=\"\" \/>\n<\/div>\n<p>Этот сдвиг породил потребность в инструментах, которые специализируются на последнем шаге — трансформации (T). Именно в этой нише dbt (data build tool) стал безоговорочным лидером, но на его поле появляются и новые сильные игроки, такие как Bruin. Давайте разберемся, что это за инструменты, какой подход они олицетворяют и в чем их ключевые различия.<\/p>\n<h4>Подход «Аналитика как код»<\/h4>\n<p>И dbt, и Bruin являются яркими представителями движения <b>“Analytics as Code”<\/b> (аналитика как код). Это не просто инструменты, а целая философия, которая переносит лучшие практики разработки программного обеспечения в мир аналитики данных.<\/p>\n<p><b>Основные принципы и идеи:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Версионирование:<\/b> Все трансформации данных описываются в виде кода (в основном SQL), который хранится в системе контроля версий, такой как Git. Это позволяет отслеживать изменения, совместно работать и откатываться к предыдущим версиям.<\/li>\n<li><b>Модульность и переиспользование (DRY – Don’t Repeat Yourself):<\/b> Сложные трансформации разбиваются на небольшие, логически завершенные модели, которые могут ссылаться друг на друга. Это делает код чище, понятнее и позволяет повторно использовать уже написанную логику.<\/li>\n<li><b>Тестирование:<\/b> Код трансформаций должен быть протестирован. Инструменты позволяют автоматически проверять качество данных после преобразований: на уникальность ключей, отсутствие `NULL` значений, соответствие заданным условиям и т.д.<\/li>\n<li><b>Документация и прозрачность:<\/b> Процесс трансформации становится самодокументируемым. Инструменты могут автоматически генерировать документацию и строить графы зависимостей моделей (data lineage), показывая, как данные текут и преобразуются от источника к конечному виду. <a href=\"https:\/\/www.element61.be\/en\/resource\/when-use-dbt-or-delta-live-tables\">element61.be<\/a><\/li>\n<li><b>CI\/CD (Continuous Integration \/ Continuous Deployment):<\/b> Изменения в коде трансформаций могут автоматически тестироваться и разворачиваться в продуктивную среду, что значительно ускоряет циклы разработки.<\/li>\n<\/ol>\n<p><b>Решаемые проблемы:<\/b><\/p>\n<ul>\n<li><b>“Черные ящики” ETL:<\/b> Заменяют сложные, трудноподдерживаемые и непрозрачные ETL-процессы на понятный и документированный код.<\/li>\n<li><b>Рассинхронизация команд:<\/b> Стирают границы между инженерами данных и аналитиками, позволяя аналитикам, владеющим SQL, самостоятельно создавать надежные модели данных.<\/li>\n<li><b>Низкое качество данных:<\/b> Встроенные механизмы тестирования помогают обеспечить надежность и согласованность данных.<\/li>\n<\/ul>\n<p>---<\/p>\n<h4>dbt (data build tool): Золотой стандарт трансформации<\/h4>\n<p><b>dbt<\/b> — это инструмент с открытым исходным кодом, который позволяет аналитикам и инженерам трансформировать данные в их хранилищах с помощью простых SQL-запросов. Важно понимать, что dbt <b>не извлекает и не загружает данные<\/b>. Он специализируется исключительно на шаге <b>“T”<\/b> в ELT  <a href=\"https:\/\/vutr.substack.com\/p\/why-is-dbt-so-popular\">vutr.substack.com<\/a>. <a href=\"https:\/\/github.com\/dbt-labs\/dbt-core\">dbt git<\/a>.<\/p>\n<p>Он работает как компилятор и исполнитель: вы пишете модели данных в `.sql` файлах, используя шаблонизатор Jinja для добавления логики (циклы, условия, макросы). Затем dbt компилирует этот код в чистый SQL и выполняет его в вашем хранилище данных <a href=\"https:\/\/www.element61.be\/en\/resource\/when-use-dbt-or-delta-live-tables\">element61.be<\/a>.<\/p>\n<h5>Плюсы dbt<\/h5>\n<ul>\n<li><b>Огромное сообщество и экосистема:<\/b> dbt стал де-факто стандартом индустрии. Существует огромное количество статей, курсов, готовых пакетов (библиотек) и экспертов.<\/li>\n<li><b>Фокус на SQL:<\/b> Низкий порог входа для аналитиков, которые уже знают SQL. Это демократизирует процесс трансформации данных.<\/li>\n<li><b>Мощное тестирование и документирование:<\/b> Встроенные команды для тестирования данных и автоматической генерации проектной документации с графом зависимостей.<\/li>\n<li><b>Зрелость и надежность:<\/b> Инструмент проверен временем и используется тысячами компаний по всему миру.<\/li>\n<li><b>Гибкость:<\/b> Благодаря шаблонизатору Jinja можно создавать очень сложные и переиспользуемые макросы, адаптируя dbt под любые нужды.<\/li>\n<\/ul>\n<h5>Минусы dbt<\/h5>\n<ul>\n<li><b>Только трансформация:<\/b> dbt не занимается извлечением (E) и загрузкой (L). Для этого вам понадобятся отдельные инструменты (например, Fivetran, Airbyte), что усложняет стек технологий.<\/li>\n<li><b>Кривая обучения:<\/b> Хотя основы просты, освоение продвинутых возможностей Jinja, макросов и структуры проекта требует времени.<\/li>\n<li><b>Зависимость от Python-моделей:<\/b> Хотя недавно появилась поддержка моделей на Python, она все еще не так нативна и проста, как основной SQL-подход, и требует дополнительных настроек.<\/li>\n<\/ul>\n<p>---<\/p>\n<h4>Bruin Data: Универсальный боец<\/h4>\n<p><b>Bruin<\/b> — это более новый игрок на рынке, который позиционирует себя как инструмент для создания “end-to-end” пайплайнов данных. В отличие от dbt, он не ограничивается только трансформацией, а стремится охватить больше этапов работы с данными, включая их загрузку (ingestion) <a href=\"https:\/\/github.com\/bruin-data\/bruin\">https:\/\/github.com\/bruin-data\/bruin<\/a>.<\/p>\n<p>Bruin разделяет ту же философию “Analytics as Code”, но предлагает более интегрированный опыт, где SQL и Python являются равноправными гражданами.<\/p>\n<h5>Плюсы Bruin<\/h5>\n<ul>\n<li><b>Универсальность:<\/b> Один инструмент для определения всего пайплайна: от загрузки из источников до финальных витрин данных. Это может упростить стек технологий.<\/li>\n<li><b>Нативная поддержка SQL и Python:<\/b> Позволяет легко комбинировать задачи на разных языках в одном пайплайне без дополнительных настроек. Это идеально для задач, где чистый SQL громоздок (например, работа с API, машинное обучение).<\/li>\n<li><b>Простота конфигурации:<\/b> Зачастую требует меньше шаблонного кода (boilerplate) для определения ассетов и пайплайнов по сравнению с dbt.<\/li>\n<li><b>Встроенное качество данных:<\/b> Как и dbt, делает акцент на проверках качества на каждом шаге.<\/li>\n<\/ul>\n<h5>Минусы Bruin<\/h5>\n<ul>\n<li><b> Пока маленькое сообщество:<\/b> Как у нового инструмента, у Bruin гораздо меньше пользователей, готовых решений и обсуждений на форумах по сравнению с dbt. Найти помощь или готовый пакет для решения специфической задачи сложнее.<\/li>\n<li><b>Незрелость:<\/b> Инструмент моложе, а значит, наверное, потенциально менее стабилен и может иметь меньше интеграций по сравнению с проверенным dbt. Пока нет облачных функция за деньги. Я так думал, но все же есть <a href=\"https:\/\/getbruin.com.\">https:\/\/getbruin.com.<\/a><\/li>\n<li><b>“Мастер на все руки — эксперт ни в чем?”:<\/b> Стремление охватить все этапы (E, L, T) может означать, что в каждом отдельном компоненте Bruin может уступать лучшим в своем классе специализированным инструментам (например, Fivetran в загрузке, dbt в трансформации), но это конечно субъективно.<\/li>\n<\/ul>\n<h4>Сводное сравнение<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Характеристика<\/td>\n<td style=\"text-align: center\">dbt (data build tool)<\/td>\n<td style=\"text-align: center\">Bruin Data<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Основная задача<\/b><\/td>\n<td style=\"text-align: center\">Трансформация (T в ELT)<\/td>\n<td style=\"text-align: center\">Весь пайплайн (E, L, T)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Ключевые языки<\/b><\/td>\n<td style=\"text-align: center\">SQL с шаблонизатором Jinja<\/td>\n<td style=\"text-align: center\">SQL и Python как равноправные<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Экосистема<\/b><\/td>\n<td style=\"text-align: center\">Огромная, стандарт индустрии<\/td>\n<td style=\"text-align: center\">Маленькая, развивающаяся<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Зрелость<\/b><\/td>\n<td style=\"text-align: center\">Высокая, проверен временем<\/td>\n<td style=\"text-align: center\">Низкая\/Средняя<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Стек инструментов<\/b><\/td>\n<td style=\"text-align: center\">Требует отдельных E\/L инструментов<\/td>\n<td style=\"text-align: center\">Стремится быть самодостаточным<\/td>\n<\/tr>\n<\/table>\n<h4>Итого<\/h4>\n<p>Выбор между dbt и Bruin — это выбор между двумя стратегиями построения современного стека данных.<\/p>\n<p><b>Выбирайте dbt, если:<\/b><\/p>\n<ul>\n<li>Вы строите гибкий стек из лучших в своем классе инструментов (“best-of-breed”): один для загрузки, другой для хранения, третий для трансформации.<\/li>\n<li>Ваша команда в основном состоит из аналитиков, сильных в SQL.<\/li>\n<li>Для вас критически важны поддержка сообщества, стабильность и наличие готовых решений.<\/li>\n<li>Вы работаете в большой организации, где принятие отраслевых стандартов является преимуществом.<\/li>\n<li>Вы готовы переехать к ним в платное облако, когда нибудь. Большая часть функционала доступна там.<\/li>\n<\/ul>\n<p><b>Выбирайте Bruin, если:<\/b><\/p>\n<ul>\n<li>Вы предпочитаете единый, интегрированный инструмент для управления всеми пайплайнами, чтобы упростить архитектуру<\/li>\n<li>Вы любите open source и End-to-end дата framework: фор data ingestion + transformations + кволити. :)<\/li>\n<li>Ваши пайплайны требуют тесной связки SQL и Python для трансформаций (например, обогащение данных через вызовы API или модели ML).<\/li>\n<li>Вы начинаете новый проект или работаете в небольшой команде и цените скорость настройки и меньшее количество движущихся частей.<\/li>\n<li>Вы Go’шник :) –  Bruin написан на Go почти на 100%.<\/li>\n<\/ul>\n<p>И dbt, и Bruin — мощные инструменты, воплощающие современные подходы к инженерии данных. dbt предлагает проверенный, сфокусированный и невероятно мощный движок для трансформаций, ставший стандартом. Bruin же предлагает более универсальный и интегрированный подход, который может быть привлекателен для команд, стремящихся к простоте и нативной поддержке Python.<\/p>\n<h4>А что такое “Аналитика как код” (Analytics as Code, AaC)?<\/h4>\n<p><b>Аналитика как код<\/b> — это подход к управлению аналитическими процессами, при котором все компоненты аналитики — от моделей данных и метрик до отчетов и правил доступа — определяются в виде кода в человекочитаемых файлах. Эти файлы затем управляются так же, как исходный код любого другого программного обеспечения: с помощью систем контроля версий, автоматизированного тестирования и развертывания <a href=\"https:\/\/medium.com\/gooddata-developers\/analytics-as-code-managing-analytics-solutions-like-any-other-software-504372ba6a61\">medium.com<\/a>.<\/p>\n<p>Самая близкая и известная аналогия — это <b>Infrastructure as Code (IaC)<\/b>. Как IaC (например, с помощью Terraform) позволил инженерам описывать серверы, сети и базы данных в коде вместо ручной настройки через веб-интерфейсы, так и AaC позволяет описывать в коде всё, что связано с данными <a href=\"https:\/\/medium.com\/@terezacihelkova\/analytics-as-code-what-is-it-and-how-does-it-help-you-93e9a3c179ee\">medium.com<\/a>.<\/p>\n<blockquote>\n<p>Идея проста и убедительна: “настройте свои системы один раз, выразите это в виде кода, а затем поместите в систему контроля версий” <a href=\"https:\/\/www.holistics.io\/blog\/analytics-as-code\/\">holistics.io<\/a>.<\/p>\n<\/blockquote>\n<h4>Проблема: Как было раньше?<\/h4>\n<p>Чтобы понять ценность AaC, нужно посмотреть на проблемы, которые он решает. В традиционном подходе аналитика часто была разрозненной и хрупкой:<\/p>\n<ul>\n<li><b>Логика в “черных ящиках”:<\/b> Сложные преобразования данных были скрыты внутри GUI-интерфейсов старых ETL-инструментов или непосредственно в настройках BI-платформы (например, Tableau, Power BI). Никто, кроме автора, не мог легко понять, как рассчитывается та или иная метрика.<\/li>\n<li><b>Разрозненные SQL-скрипты:<\/b> Аналитики хранили важные SQL-запросы на своих локальных машинах, в общих папках или на wiki-страницах. Не было единой версии правды, код дублировался и быстро устаревал.<\/li>\n<li><b>Отсутствие контроля версий:<\/b> Невозможно было отследить, кто, когда и почему изменил логику расчета ключевого показателя. Откат к предыдущей работающей версии был настоящей головной болью.<\/li>\n<li><b>“Ручное” тестирование:<\/b> Проверка качества данных после изменений была ручным, подверженным ошибкам процессом. Часто о проблемах узнавали уже от бизнес-пользователей, которые видели неверные цифры в отчетах.<\/li>\n<li><b>Рассинхронизация:<\/b> Инженеры данных готовили сырые таблицы, а аналитики строили свою логику поверх них. Любые изменения с одной стороны могли сломать всю цепочку, не будучи замеченными вовремя.<\/li>\n<\/ul>\n<p>Этот хаос приводил к главному — <b>недоверию к данным<\/b>. Никто не мог быть уверен, что цифры в дашборде верны.<\/p>\n<h4>Ключевые принципы “Аналитики как код”<\/h4>\n<p>AaC решает эти проблемы, внедряя практики из мира разработки ПО.<\/p>\n<ol start=\"1\">\n<li><b>Декларативное определение:<\/b> Все аналитические артефакты описываются в файлах.\n<ul>\n  <li>Модели данных:** `SELECT * FROM ...` в `.sql` файлах.<\/li>\n  <li>Тесты:** `not_null`, `unique` в `.yml` файлах.<\/li>\n  <li>Документация:** Описания таблиц и полей в `.yml` файлах.<\/li>\n  <li>Метрики и дашборды:** Определения в `.yml` или специализированных файлах <a href=\"https:\/\/medium.com\/gooddata-developers\/analytics-as-code-managing-analytics-solutions-like-any-other-software-504372ba6a61\">medium.com<\/a>.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Контроль версий (Git):<\/b> Весь код хранится в репозитории (например, на GitHub или GitLab).\n<ul>\n  <li>Прозрачность:** Каждое изменение — это `commit` с понятным описанием.<\/li>\n  <li>Совместная работа:** Аналитики работают в отдельных ветках, а изменения вносятся через `Pull Request` (или `Merge Request`), что позволяет проводить ревью кода (code review).<\/li>\n  <li>Восстанавливаемость:** Если что-то пошло не так, можно легко откатиться к предыдущей версии.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Автоматизированное тестирование:<\/b> Тесты являются неотъемлемой частью кода. Они запускаются автоматически при каждом изменении, чтобы гарантировать, что данные по-прежнему соответствуют ожиданиям (например, `user_id` всегда уникален и не равен `NULL`).<\/li>\n<\/ol>\n<ol start=\"4\">\n<li><b>CI\/CD (Непрерывная интеграция и развертывание):<\/b> Процессы полностью автоматизированы.\n<ul>\n  <li>Когда аналитик вносит изменения в `Pull Request`, автоматически запускаются тесты.<\/li>\n  <li>После одобрения и слияния ветки изменения автоматически развертываются в продуктивной среде (например, dbt Cloud или Jenkins запускает команду `dbt run`).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"5\">\n<li><b>Модульность и переиспользование (DRY – Don’t Repeat Yourself):<\/b> Сложные потоки данных разбиваются на небольшие, логичные и переиспользуемые модели. Одна модель может ссылаться на другую, создавая четкий граф зависимостей (lineage), который можно визуализировать.<\/li>\n<\/ol>\n<h4>Преимущества подхода AaC<\/h4>\n<p>Принятие этой философии дает компании ощутимые выгоды:<\/p>\n<ul>\n<li><b>Надежность и доверие:<\/b> Благодаря автоматическому тестированию и ревью кода значительно повышается качество данных, а вместе с ним и доверие бизнеса к аналитике.<\/li>\n<li><b>Скорость и гибкость:<\/b> Аналитики могут вносить изменения гораздо быстрее. Цикл от идеи до готового отчета сокращается с недель до дней или даже часов.<\/li>\n<li><b>Масштабируемость:<\/b> Кодовая база легко поддерживается и расширяется. Новые члены команды могут быстро разобраться в проекте благодаря документации и прозрачности.<\/li>\n<li><b>Прозрачность и обнаруживаемость:<\/b> Автоматически сгенерированная документация и графы зависимостей позволяют любому сотруднику понять, откуда берутся данные и как они рассчитываются.<\/li>\n<li><b>Демократизация:<\/b> AaC дает возможность аналитикам, владеющим SQL, самостоятельно создавать надежные и протестированные модели данных, не дожидаясь инженеров данных. Это стирает барьеры между командами.<\/li>\n<\/ul>\n<p>В конечном итоге, “Аналитика как код” — это культурный сдвиг, который превращает аналитику из ремесленного занятия в зрелую инженерную дисциплину, обеспечивая скорость, надежность и масштабируемость, необходимые современному бизнесу.<\/p>\n",
            "date_published": "2025-08-23T16:04:02+03:00",
            "date_modified": "2025-08-24T11:51:29+03:00",
            "tags": [
                "BI",
                "Data Engineer",
                "Data Quality",
                "dbt",
                "ETL"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-23-v-15.37.26.png",
            "_date_published_rfc2822": "Sat, 23 Aug 2025 16:04:02 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "272",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-23-v-15.37.26.png",
                    "https:\/\/gavrilov.info\/pictures\/demo.gif"
                ]
            }
        },
        {
            "id": "266",
            "url": "https:\/\/gavrilov.info\/all\/opisanie-paterna-write-audit-publish\/",
            "title": "Описание патерна Write-Audit-Publish",
            "content_html": "<p>Кстати, хорошо ложится на git-like подход работы с данными.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-208.png\" width=\"800\" height=\"971\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Ссылка: <a href=\"https:\/\/habr.com\/ru\/articles\/93773\">https:\/\/habr.com\/ru\/articles\/93773<\/a><\/div>\n<\/div>\n<p><b>Write-Audit-Publish (WAP)<\/b> — это патерн проектирования в инженерии данных, предназначенный для повышения надежности и качества данных перед тем, как они станут доступны конечным потребителям (аналитикам, дашбордам, другим системам).<\/p>\n<p>Основная цель WAP — предотвратить попадание некорректных, неполных или ошибочных данных в “production” среду. Вместо того чтобы записывать данные напрямую в целевую таблицу, процесс разделяется на три изолированных этапа <a href=\"https:\/\/lakefs.io\/blog\/what-is-write-audit-publish\">lakefs.io<\/a>.<\/p>\n<h5>Как это работает?<\/h5>\n<p>Процесс WAP состоит из трех логических шагов:<\/p>\n<ol start=\"1\">\n<li><b>Write (Запись)<\/b>  <br \/>\nНа этом этапе данные (новые или обновленные) записываются в промежуточную, изолированную область. Это может быть отдельная таблица, временный каталог в озере данных или, что более современно, отдельная ветка (branch) в табличном формате, таком как Apache Iceberg. Ключевой момент — эти данные <b>не видны<\/b> конечным потребителям.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Audit (Аудит\/Проверка)<\/b>  <br \/>\nПосле записи данные в изолированной области подвергаются всесторонней проверке. Этот этап — сердце патерна. Проверки могут включать:<\/li>\n\n<ul>\n  <li><b>Технические проверки:<\/b> соответствие схеме данных, отсутствие `NULL` в ключевых полях, уникальность идентификаторов.<\/li>\n  <li><b>Бизнес-логика:<\/b> проверка на соответствие бизнес-правилам (например, сумма заказа не может быть отрицательной).<\/li>\n  <li><b>Статистические проверки:<\/b> выявление аномалий и выбросов.<\/li>\n  <li><b>Сравнительные проверки:<\/b> сверка с данными из других таблиц или систем.  <br \/>\nЕсли аудит не пройден, данные остаются в изоляции для анализа и исправления, не затрагивая при этом рабочую среду.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Publish (Публикация)<\/b>  <br \/>\nТолько если этап аудита успешно пройден, данные публикуются, то есть становятся видимыми для конечных пользователей. Этот процесс, как правило, является <b>атомарной операцией<\/b>. Это означает, что все изменения применяются одновременно, как единая транзакция. Потребители видят либо старое состояние данных, либо полностью обновленное и проверенное, без промежуточных, грязных состояний.<\/li>\n<\/ol>\n<h4>Примеры использования и реализации<\/h4>\n<p>Патерн WAP не привязан к конкретной технологии, но некоторые современные инструменты делают его реализацию особенно удобной.<\/p>\n<h5>1. Apache Iceberg<\/h5>\n<p>Apache Iceberg, открытый табличный формат для озер данных, идеально подходит для реализации WAP благодаря своей поддержке ветвления (branching) и тегирования (tagging), похожей на Git.<\/p>\n<ul>\n<li><b>Write:<\/b> Новые данные записываются не в основную ветку `main`, а в отдельную ветку, например `ingestion_updates_20240816`.<\/li>\n<li><b>Audit:<\/b> Запросы на проверку качества данных выполняются исключительно к данным в этой новой ветке.<\/li>\n<li><b>Publish:<\/b> Если проверки прошли успешно, основная ветка `main` “перематывается” (fast-forward) на состояние ветки `ingestion_updates_20240816`. Эта операция метаданных происходит мгновенно и атомарно. Если проверки не пройдены, ветка просто удаляется <a href=\"https:\/\/www.tabular.io\/apache-iceberg-cookbook\/data-engineering-write-audit-publish\">www.tabular.io<\/a><\/li>\n<\/ul>\n<p>Этот подход также позволяет координировать обновления для нескольких таблиц, используя общее имя ветки, проводить перекрестные проверки, а затем публиковать все изменения одновременно для обеспечения консистентности <a href=\"https:\/\/www.tabular.io\/apache-iceberg-cookbook\/data-engineering-write-audit-publish\">www.tabular.io<\/a>.<\/p>\n<h5>2. Snowflake<\/h5>\n<p>В облачном хранилище данных Snowflake патерн WAP также может быть эффективно реализован.<\/p>\n<ul>\n<li><b>Write:<\/b> Данные загружаются во временную или “staging” таблицу.<\/li>\n<li><b>Audit:<\/b> С помощью SQL-запросов и инструментов, таких как `Snowflake Tasks`, выполняются проверки данных в этой staging-таблице.<\/li>\n<li><b>Publish:<\/b> Если данные корректны, они атомарно переносятся в основную, “production” таблицу с помощью команды `MERGE`, которая позволяет эффективно вставлять, обновлять и удалять строки за одну операцию <a href=\"https:\/\/www.getorchestra.io\/guides\/data-engineering-patterns-write-audit-publish-wap---snowflake\">www.getorchestra.io<\/a>. Для отслеживания изменений в исходных таблицах часто используются `Snowflake Streams`.<\/li>\n<\/ul>\n<h5>Ключевые преимущества WAP<\/h5>\n<ul>\n<li><b>Повышение доверия к данным:<\/b> Пользователи могут быть уверены, что данные, которые они видят, прошли строгую проверку качества.<\/li>\n<li><b>Надежность конвейеров данных (pipelines):<\/b> Сбои в процессе трансформации или загрузки не нарушают целостность данных в основной системе.<\/li>\n<li><b>Изоляция и атомарность:<\/b> Изменения либо применяются целиком, либо не применяются вовсе, что исключает “грязное чтение”.<\/li>\n<li><b>Улучшенная отладка:<\/b> Если данные не прошли аудит, они остаются в изолированной среде, где инженеры могут легко их проанализировать и исправить ошибку.<\/li>\n<\/ul>\n<p>В итоге, WAP позволяет перейти от оркестрации, основанной на “успешности выполнения задачи”, к оркестрации, основанной на “готовности и качестве данных” <a href=\"https:\/\/www.tabular.io\/apache-iceberg-cookbook\/data-engineering-write-audit-publish\/\">www.tabular.io<\/a><\/p>\n<h4>Ссылки<\/h4>\n<ul>\n<li><b>Общее описание и важность патерна:<\/b> What Is Write-Audit-Publish and Why Should You Care? <a href=\"https:\/\/lakefs.io\/blog\/what-is-write-audit-publish\">lakefs.io<\/a><\/li>\n<li><b>Реализация с Apache Iceberg:<\/b> Write – Audit- Publish (WAP) Pattern – Tabular <a href=\"https:\/\/www.tabular.io\/apache-iceberg-cookbook\/data-engineering-write-audit-publish\">www.tabular.io<\/a><\/li>\n<li><b>Пример реализации на AWS с Apache Iceberg:<\/b> Write-Audit-Publish Pattern with Apache Iceberg on AWS <a href=\"https:\/\/www.guptaakashdeep.com\/wap-via-apache-iceberg-on-aws-using-wapid\/\">www.guptaakashdeep.com<\/a><\/li>\n<li><b>Реализация в Snowflake:<\/b> Data Engineering Patterns: Write-Audit-Publish (WAP) – Snowflake <a href=\"https:\/\/www.getorchestra.io\/guides\/data-engineering-patterns-write-audit-publish-wap---snowflake\">www.getorchestra.io<\/a><\/li>\n<\/ul>\n",
            "date_published": "2025-08-16T22:46:33+03:00",
            "date_modified": "2025-08-16T22:47:54+03:00",
            "tags": [
                "Data Governance",
                "Data Quality"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-208.png",
            "_date_published_rfc2822": "Sat, 16 Aug 2025 22:46:33 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "266",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-208.png"
                ]
            }
        },
        {
            "id": "163",
            "url": "https:\/\/gavrilov.info\/all\/net-inzheneram-po-obrabotke-dannyh-ne-nuzhen-dbt\/",
            "title": "Нет, инженерам по обработке данных не НУЖЕН dbt",
            "content_html": "<p>Оригинал: <a href=\"https:\/\/blog.det.life\/no-data-engineers-dont-need-dbt-30573eafa15e\">https:\/\/blog.det.life\/no-data-engineers-dont-need-dbt-30573eafa15e<\/a><\/p>\n<p>Нужно ли мне изучать dbt? Я часто вижу этот вопрос на Reddit, и он меня путает. Звучит просто. Использует ли ваша компания dbt? Если да, то да. Если нет, то нет. Как и любой другой инструмент, dbt лучше всего использовать в тех сценариях, где он хорошо подходит. В то же время, я часто читаю мнения людей, которые говорят, что dbt не приносит пользы. Затем они начинают перечислять десять инструментов, которые они используют вместо этого. Должен быть какой-то средний путь.<\/p>\n<p>Видите ли, здесь важен именно аспект «хорошей подгонки», а не необходимость. Мы используем инструменты для решения проблем. Позвольте повторить это. Мы используем инструменты для решения проблем. Не потому, что они крутые или мы хотим добавить их в наш набор навыков, или потому что все остальные их используют. Инструменты помогают нам решать проблемы. Давайте рассмотрим проблемы, которые помогает решать dbt, и случаи, когда он подходит. Черт возьми. Давайте также поговорим о сценариях, в которых он не подходит.<\/p>\n<p>Что такое dbt — лучшее определение?<br \/>\nСуществует распространенное заблуждение, что dbt — это инструмент ELT, который позволяет извлекать, загружать и преобразовывать данные. Это неверно. Dbt — это всего лишь инструмент для преобразования данных с использованием SQL. Если вы не используете SQL для преобразования данных, использование dbt станет огромным изменением. Возможно, это не для вас. Если у вас есть хранилище данных, где SQL является общим языком, то dbt может быть хорошим вариантом.<\/p>\n<p>Говорить, что dbt — это просто инструмент для преобразования, недооценивает его ценность, потому что преобразование данных — это большая задача в корпоративной среде. Так что давайте дадим ему лучшее определение:<br \/>\nDbt — это набор утилит, который позволяет управлять преобразованием данных с использованием динамического SQL в гибком языке шаблонов.<\/p>\n<p>Это уже получше, хотя я не уверен, как бы это восприняли в отделе маркетинга dbt Labs. Проблема в том, что это определение говорит нам, что делает dbt, но не объясняет, как он это делает или какие проблемы он решает. Чтобы уточнить определение, давайте обсудим некоторые проблемы, возникающие при преобразовании данных. В частности, давайте обсудим четыре ключевые проблемы, с которыми мы все сталкиваемся.<\/p>\n<p>Управление зависимостями<br \/>\nДинамический код<br \/>\nМатериализация<br \/>\nТестирование – качество данных и проверка кода<br \/>\nГенерация документация ( плюс от меня )<\/p>\n<p>Управление зависимостями<br \/>\nПрежде чем мы напишем строчку SQL, мы должны знать исходные данные для наших таблиц и представлений. Это очевидно, верно? Если мы выбираем столбцы, мы должны знать, откуда мы выбираем. Это включает в себя базу данных, схему и таблицу. Таблица обычно, но не всегда, статична. Однако база данных и схема часто меняются в разных средах. Например, у нас могут быть рабочие, промежуточные и производственные среды, использующие разные базы данных.<\/p>\n<p>Не большая проблема для решения, но самодельные решения будут нуждаться в реализации какой-то системы управления зависимостями. Dbt делает это с помощью функции ref(). Вот пример того, как это работает у меня на работе. Если я использую ref() в WHERE clause, dbt автоматически подберет нужную таблицу для среды, в которой мы работаем.<\/p>\n<p>dev: dev_lgodin_dw.common.date_d<br \/>\nstaging: dw_staging.common.date_d<br \/>\nprod: dw.common.date_d<\/p>\n<p>```sql<br \/>\nselect<br \/>\ndate,<br \/>\nyear,<br \/>\nmonth<br \/>\nfrom {{ ref(‘date_d’) }}<br \/>\n```<\/p>\n<p>Управление зависимостями – это гораздо больше, чем просто идентификация полностью квалифицированного имени таблицы. Мы должны понимать порядок выполнения преобразований. Например, fact_sales должна выполняться перед fact_sales_monthly. Использование ref() автоматически решает эту задачу. Фактически, dbt создает граф зависимостей каждый раз при его запуске. Посмотрите на зависимости ниже для dbt-fake.<\/p>\n<p>Граф зависимостей dbt<\/p>\n<p>Давайте надеяться, что вы никогда не увидите что-то подобное в вашем хранилище данных. Я использую это для создания фальшивых данных, поэтому это не типичный сценарий. Используя ref() в моих моделях, dbt фиксирует зависимости за меня. Он выполнит эти модели в четыре этапа, используя параллелизм, когда это возможно.<\/p>\n<p>fake_companies, fake_dates и fake_numbers<br \/>\ncompanies_base<br \/>\nemployees_base<br \/>\nenterprise_orders_base<\/p>\n<p>Теперь представьте хранилище данных с сотнями источников и сотнями моделей. Ручное определение зависимостей было бы непростой задачей. Вам понадобилась бы какая-то утилита для управления зависимостями. Dbt решает эту задачу из коробки. Если вы хотите пойти дальше, вы можете изучить зависимости с помощью переменной graph или manifest.json в dbt.<\/p>\n<p>Динамический SQL<br \/>\n```sql<br \/>\n{{<br \/>\nconfig(<br \/>\nmaterialized = ‘incremental’,<br \/>\nunique_key = [‘order_date’, ‘user_id’, ‘product_id’],<br \/>\n)<br \/>\n}}<\/p>\n<p>select<br \/>\ndate as order_date,<br \/>\nuser_id,<br \/>\nproduct_id,<br \/>\nnum_items,<br \/>\nsum(num_items) over (partition by user_id) as total_weekly_items,<br \/>\ncurrent_timestamp() as created_at,<br \/>\ncurrent_timestamp() as updated_at<br \/>\nfrom {{ get_date_filtered_subquery(<br \/>\nsource_model=ref(‘stg_orders’),<br \/>\ntarget_model=this,<br \/>\nrun_at_date=get_run_at_date()) }}<br \/>\n```<\/p>\n<p>Моя главная жалоба на SQL заключается в его слабой поддержке для написания динамических запросов. Каждый поставщик реализует свои собственные методы для динамической генерации SQL путем склеивания строк и запуска некоторых команд exec. Dbt интегрирует Jinja-SQL как часть комплексного пакета для преобразования данных. Это значит, что мы можем писать динамический SQL на языке шаблонов.<\/p>\n<p>Хотели ли вы когда-нибудь использовать цикл for в SQL для написания повторяющегося кода? Вы можете сделать это. Я часто использую метаданные для генерации больших запросов. Например, у нас есть таблица Customer 360 с ~200 столбцами. Эта таблица строится динамически с использованием CSV для метаданных и Jinja для генерации SQL. Это не только экономит время, но и значительно уменьшает количество ошибок, вызванных ручным вводом.<\/p>\n<p>Как насчет автоматизации логики дат в ваших преобразованиях? Да, динамический SQL спасает положение. Нужно ли запускать ваши задания для конкретных дат, возможно, для обеспечения идемпотентности? Dbt поможет. Суть в том, что SQL хорош, но динамический SQL позволяет писать запросы, как программист. С Jinja мы можем создавать переиспользуемые компоненты, называемые макросами. Мы можем использовать циклы для написания повторяющегося кода. Мы можем думать о SQL как о результате нашей работы, а не только об усилиях.<\/p>\n<h4>Автоматическая Материализация<\/h4>\n<p>Самое распространенное, что мы делаем в хранилищах данных, — это создаем\/обновляем таблицы и представления. Dbt называет это материализацией. Обычно мы используем insert или merge для этого. Хотя эти операторы не сложны, они быстро становятся утомительными. Мы находим себя пишущими один и тот же код снова и снова, просто чтобы записать разные столбцы в базу данных. Какое это пустая трата времени.<\/p>\n<p>С dbt нам никогда не нужно писать операторы insert или merge. Мы пишем запросы и настраиваем материализацию. Хотите представление (view)? materialization = ‘view’. Это инкрементальная таблица? Правильно, materialization = ‘incremental’. Может быть, вам нужна медленно меняющаяся размерность типа-2? Это немного другое, но dbt имеет для этого “снимки” (snapshots). Когда все сказано и сделано, мы настраиваем, как мы хотим материализовать данные, и dbt автоматически обрабатывает это. Это мощно. Давайте посмотрим на пример. Код ниже реализует инкрементальную таблицу.<\/p>\n<p>```sql<br \/>\n{{<br \/>\nconfig(<br \/>\nmaterialized = ‘incremental’,<br \/>\nunique_key = [‘order_date’, ‘user_id’, ‘product_id’],<br \/>\n)<br \/>\n}}<\/p>\n<p>select<br \/>\ndate as order_date,<br \/>\nuser_id,<br \/>\nproduct_id,<br \/>\nnum_items,<br \/>\nsum(num_items) over (partition by user_id) as total_weekly_items,<br \/>\ncurrent_timestamp() as created_at,<br \/>\ncurrent_timestamp() as updated_at<br \/>\nfrom {{ get_date_filtered_subquery(<br \/>\nsource_model=ref(‘stg_orders’),<br \/>\ntarget_model=this,<br \/>\nrun_at_date=get_run_at_date()) }}<br \/>\n```<\/p>\n<p>Вот и все, что я написал. Теперь давайте посмотрим на код, который выполняет dbt. В первый раз, когда я запустил эту модель, таблица не существовала в базе данных, поэтому она была создана с полной историей.<\/p>\n<p>```sql<br \/>\ncreate or replace table `leogodin217-dbt-tutorial`.`enterprise_sales`.`weekly_orders`<br \/>\nOPTIONS()<br \/>\nas (<br \/>\nselect<br \/>\ndate as order_date,<br \/>\nuser_id,<br \/>\nproduct_id,<br \/>\nnum_items,<br \/>\nsum(num_items) over (partition by user_id) as total_weekly_items,<br \/>\ncurrent_timestamp() as created_at,<br \/>\ncurrent_timestamp() as updated_at<br \/>\nfrom (<br \/>\nselect<br \/>\n*<br \/>\nfrom `leogodin217-dbt-tutorial`.`enterprise_sales`.`stg_orders`<br \/>\n) as stg_orders<br \/>\n);<br \/>\n```<\/p>\n<p>Во второй раз, когда я запустил модель, таблица уже существовала, и dbt знал, что нужно сделать инкрементальное обновление. Не знаю, как вы, но я ненавижу писать подобный код. Это скучная, монотонная работа с множеством возможностей для ошибок. Особенно с десятью или более столбцами.<\/p>\n<p>```sql<br \/>\nmerge into `leogodin217-dbt-tutorial`.`enterprise_sales`.`weekly_orders` as DBT_INTERNAL_DEST<br \/>\nusing (<br \/>\nselect<br \/>\ndate as order_date,<br \/>\nuser_id,<br \/>\nproduct_id,<br \/>\nnum_items,<br \/>\nsum(num_items) over (partition by user_id) as total_weekly_items,<br \/>\ncurrent_timestamp() as created_at,<br \/>\ncurrent_timestamp() as updated_at<br \/>\nfrom (<br \/>\nselect<br \/>\n*<br \/>\nfrom `leogodin217-dbt-tutorial`.`enterprise_sales`.`stg_orders`<br \/>\nwhere date between ‘2024-07-07’ and ‘2024-07-13’<br \/>\n) as stg_orders<br \/>\n) as DBT_INTERNAL_SOURCE<br \/>\non (<br \/>\nDBT_INTERNAL_SOURCE.order_date = DBT_INTERNAL_DEST.order_date<br \/>\n) and (<br \/>\nDBT_INTERNAL_SOURCE.user_id = DBT_INTERNAL_DEST.user_id<br \/>\n) and (<br \/>\nDBT_INTERNAL_SOURCE.product_id = DBT_INTERNAL_DEST.product_id<br \/>\n)<\/p>\n<p>when matched then update set<br \/>\n`order_date` = DBT_INTERNAL_SOURCE.`order_date`,<br \/>\n`user_id` = DBT_INTERNAL_SOURCE.`user_id`,<br \/>\n`product_id` = DBT_INTERNAL_SOURCE.`product_id`,<br \/>\n`num_items` = DBT_INTERNAL_SOURCE.`num_items`,<br \/>\n`total_weekly_items` = DBT_INTERNAL_SOURCE.`total_weekly_items`,<br \/>\n`created_at` = DBT_INTERNAL_SOURCE.`created_at`,<br \/>\n`updated_at` = DBT_INTERNAL_SOURCE.`updated_at`<\/p>\n<p>when not matched then insert<br \/>\n(`order_date`, `user_id`, `product_id`, `num_items`, `total_weekly_items`, `created_at`, `updated_at`)<br \/>\nvalues<br \/>\n(`order_date`, `user_id`, `product_id`, `num_items`, `total_weekly_items`, `created_at`, `updated_at`)<br \/>\n```<\/p>\n<h4>Тестирование. Раз, два, три, тестирование.<\/h4>\n<p>Не секрет, что хранилища данных отстают на световые годы от традиционной разработки программного обеспечения в плане тестирования. Существуют множество причин для этого. Во-первых, тестировать хранилища данных на порядки сложнее, чем общее ПО. В Python-приложении мы можем выделить отдельный модуль. Это не применимо в хранилище данных. Нам всегда нужна работающая база данных для тестирования чего-либо. В лучшем случае у нас есть интеграционные или системные тесты. Более того, помимо тестирования нашего кода, нам нужно тестировать сами данные. Это не часто входит в область ответственности разработчиков приложений. Как dbt справляется с этим?<\/p>\n<h4>Качество данных<\/h4>\n<p>Меня наняли на текущую должность для улучшения архитектуры dbt и качества данных. Обычно нам редко удается выполнить задачи такого рода, но мы сделали это — с огромной помощью команды. Мы не часто говорим о качестве данных в нашем хранилище, потому что мы приложили усилия, чтобы исправить это. Многие команды пытаются внедрить более сложные решения, но именно мы первыми находим проблемы с помощью тестов dbt.<\/p>\n<h4>Валидация кода<\/h4>\n<p>Существуют и другие типы тестов. Важно отметить, что тесты качества данных проверяют данные и зависят от входящих источников. Мы не можем тестировать крайние случаи, если они не включены в наши данные. Проверка качества данных касается данных, но не гарантирует, что наш код корректен. Здесь на помощь приходит валидация кода.<\/p>\n<p>Мы кратко обсудили концепцию юнит-тестов, и, честно говоря, у dbt нет настоящих юнит-тестов. Но у него есть возможность контролировать состояние входных данных нашей модели и сравнивать результаты с известными значениями. Это сложная задача в хранилищах данных. Проблема, которая не была хорошо решена в отрасли, но dbt предоставляет разумное решение.<\/p>\n<h4>Финальное определение для dbt<\/h4>\n<p>Мы обсудили четыре ключевые проблемы, с которыми сталкиваемся при преобразовании данных и как dbt решает их. У dbt есть много других функций, и стоит посетить их веб-сайт для получения дополнительной информации. Там вы найдете больше о контроле версий, документации, графических операторах для запуска подмножеств моделей и многое другое. Но мы знаем достаточно, чтобы улучшить наше определение.<\/p>\n<p>Что такое dbt?<br \/>\nDbt — это комплексный пакет, позволяющий инженерам сосредоточиться на реализации бизнес-логики в преобразованиях хранилища данных.<\/p>\n<p>Как работает dbt?<br \/>\nDbt работает, абстрагируя общие шаблоны хранилищ данных в автоматизацию, управляемую конфигурацией, и предоставляя набор инструментов для упрощения SQL-преобразований, тестов и документации.<\/p>\n<h4>Когда dbt вам не нужен<\/h4>\n<p>Не существует единого инструмента, который подошел бы всем. Мы говорили об этом. Мы используем инструменты для решения проблем. Dbt не решает все проблемы. В каких случаях dbt не является правильным инструментом для работы?<\/p>\n<ul>\n<li>У вас уже есть зрелая платформа. Хранилища данных существуют намного дольше, чем dbt. Многие компании создали фантастические среды для преобразований. Эти инженеры не нуждаются в новых инструментах.<\/li>\n<li>Вы используете ETL вместо ELT. Я знаю, что сейчас ELT в моде, но есть много примеров, когда ETL лучше подходит. Если это ваш рабочий процесс, то dbt не поможет. Dbt только преобразует данные. Он не будет перемещать данные с S3 в Snowflake. Он не будет читать из MongoDB и записывать в Postgres. Это не его задача.( До тех пор пока у вас нет Trino )<\/li>\n<li>Ваша рабочая нагрузка не принадлежит хранилищу данных. Некоторые источники данных не вписываются в простой ELT-паттерн. Cai Perry-Jones написал пример с сотнями файлов CSV с разными схемами. Модели Python в dbt, конечно, могут справиться с этим, но возможно, лучше сделать это до того, как данные попадут в ваше хранилище данных. Конечно, как только они попадут туда, dbt может быть правильным инструментом для интеграции этих данных в нижележащие таблицы и представления.<\/li>\n<\/ul>\n<p>Хотите лучше понять dbt? Попробуйте мой список статей по промежуточному и продвинутому уровню dbt.<\/p>\n<h4>Нужен ли вам dbt?<\/h4>\n<p>Надеюсь, к этому моменту вы поняли, что мы все время задавали неправильный вопрос. Никому не нужен dbt, если это не требуется для их работы. Гораздо лучше задать вопрос: поможет ли dbt решить проблемы, с которыми мы сталкиваемся? Если dbt делает вашу работу проще, то, вероятно, это хороший выбор. Dbt помог нам улучшить качество данных, уменьшить количество сбоев задач и улучшить нашу дисциплину разработки программного обеспечения. По этим причинам он хорошо подходит для нас. Нам не нужен dbt, но он, безусловно, решает множество проблем.<\/p>\n",
            "date_published": "2024-09-28T00:50:15+03:00",
            "date_modified": "2024-09-28T00:50:05+03:00",
            "tags": [
                "Data",
                "Data Engineer",
                "Data Quality"
            ],
            "_date_published_rfc2822": "Sat, 28 Sep 2024 00:50:15 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "163",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "106",
            "url": "https:\/\/gavrilov.info\/all\/ocenka-kachestva-dannyh-sleduyuschiy-etap-obespecheniya-kachestv\/",
            "title": "Оценка качества данных: Следующий этап обеспечения качества данных в Airbnb",
            "content_html": "<p><a href=\"https:\/\/medium.com\/airbnb-engineering\/data-quality-score-the-next-chapter-of-data-quality-at-airbnb-851dccda19c3\">https:\/\/medium.com\/airbnb-engineering\/data-quality-score-the-next-chapter-of-data-quality-at-airbnb-851dccda19c3<\/a><\/p>\n<p>Автор: Кларк Райт<\/p>\n<p>Введение<\/p>\n<p>В наши дни, с увеличением объема данных, собираемых компаниями, мы все осознаем, что больше данных не всегда означает лучше. Фактически больше данных, особенно если нельзя полагаться на их качество, может замедлить компанию, затруднить принятие решений или привести к плохим решениям.<\/p>\n<p>С 1,4 миллиарда кумулятивных посещений гостей на конец 2022 года рост Airbnb вынудил нас прийти к точке перегиба, где ухудшение качества данных начало препятствовать работе наших специалистов по данным. Еженедельные отчеты по метрикам были трудно подготовить в срок. Вроде бы базовые метрики, такие как “Активные объявления”, зависели от сложной сети зависимостей. Для проведения значимой работы с данными требовалось значительное институциональное знание для преодоления скрытых трудностей с данными.<\/p>\n<p>Для решения этой проблемы мы ввели процесс Midas для подтверждения наших данных. Начиная с 2020 года процесс Midas, вместе с работой по переархитектуре наших самых важных моделей данных, привел к драматическому повышению качества и своевременности данных для самых критически важных данных Airbnb. Однако достижение полных критериев качества данных, требуемых Midas, требует значительных кросс-функциональных инвестиций для проектирования, разработки, проверки и поддержания необходимых активов данных и документации.<\/p>\n<p>Хотя это имело смысл для наших самых важных данных, достижение таких строгих стандартов в масштабах представляло сложности. Мы подходили к моменту убыточности вложений в качество данных. Мы подтвердили наши самые критические активы, восстанавливая их надежность. Однако для всех наших несертифицированных данных, которые оставались большинством наших офлайн-данных, нам не хватало видимости в их качество и не было четких механизмов для повышения его уровня.<\/p>\n<p>Как мы могли бы распространить выигрыши и лучшие практики Midas на весь наш хранилище данных?<\/p>\n<p>В этом блоге мы расскажем о нашем инновационном подходе к оценке качества данных — Оценке качества данных Airbnb (“DQ Score”). Мы расскажем, как мы разработали DQ Score, как он используется сегодня и как он будет поддерживать следующий этап обеспечения качества данных в Airbnb.<\/p>\n<p>Масштабирование качества данных<\/p>\n<p>В 2022 году мы начали исследование идей по масштабированию качества данных за пределами сертификации Midas. Производители данных запрашивали процесс более легкого веса, который мог бы предоставить некоторые ограждающие поручни качества Midas, но с меньшей строгостью и временными затратами. В то же время потребители данных продолжали летать слепо на всех данных, которые не были сертифицированы Midas. Бренд вокруг сертифицированных данных Midas был настолько сильным, что потребители начали сомневаться, стоит ли доверять каким-либо несертифицированным данным. Чтобы избежать разбавления бренда Midas, мы хотели избежать введения упрощенной версии сертификации, которая дополнительно стратифицировала бы наши данные, не открыв при этом долгосрочной масштабируемости.<\/p>\n<p>Решив эти проблемы, мы решили перейти к стратегии качества данных, направленной на то, чтобы прямо подталкивать стимулы в области качества данных к производителям и потребителям данных. Мы приняли решение, что мы больше не можем полагаться на принуждение для масштабирования качества данных в Airbnb, и вместо этого нам нужно полагаться на поощрение как производителя данных, так и потребителя.<\/p>\n<p>Для полного включения этого подхода поощрения мы считали важным представить концепцию оценки качества данных, прямо связанную с данными активами.<\/p>\n<p>Мы определили следующие цели для оценки:<\/p>\n<p>Эволюция нашего понимания качества данных за пределами простого двоичного определения (сертифицированные против несертифицированных).<br \/>\nВыравнивание входных компонентов для оценки качества данных.<br \/>\nОбеспечение полной видим<\/p>\n<p>ости в качество нашего офлайн-хранилища данных и отдельных данных активов. Эта видимость должна 1) создавать естественные стимулы для производителей для улучшения качества данных, которые они владеют, и 2) стимулировать спрос на данные высокого качества со стороны потребителей данных и позволять им решать, является ли качество подходящим для их потребностей.<br \/>\nСоставление оценки<\/p>\n<p>Прежде чем погружаться в тонкости измерения качества данных, мы достигли согласия по видению, определив принципы направления DQ Score. При участии многофункциональной группы практиков данных мы выработали согласие по следующим основным принципам:<\/p>\n<p>Полное охват — оценка может быть применена к любому активу данных офлайн-хранилища данных<br \/>\nАвтоматизированность — сбор входных данных, определяющих оценку, на 100% автоматизирован<br \/>\nДейственность — оценка легко обнаруживается и используется как для производителей, так и для потребителей<br \/>\nМногомерность — оценку можно разложить на столбы качества данных<br \/>\nЭволютивность — критерии оценки и их определения могут меняться со временем<br \/>\nХотя они могут показаться простыми или очевидными, установка этих принципов была критичной, поскольку они направляли каждое принятое решение в разработке оценки. Вопросы, которые в противном случае могли бы сорвать прогресс, были сопоставлены нашими принципами.<\/p>\n<p>Например, наши принципы были критичными при определении того, какие элементы из нашего списка желаемых критериев оценки следует рассматривать. Было несколько входов, которые, конечно, могли бы нам помочь измерить качество, но если их нельзя было измерить автоматически (Автоматизированность) или если они были настолько запутанными, что практики данных не могли бы понять, что означает или как это можно улучшить (Действенность), то они были отклонены.<\/p>\n<p>У нас также был ряд входных сигналов, которые более прямо измеряли качество (сертификация Midas, проверка данных, ошибки, SLA, автоматические проверки качества данных и т. д.), в то время как другие были более похожи на показатели качества (например, правильная принадлежность, хорошая гигиеничность управления, использование инструментов планирования). Были ли более явные и прямые измерения качества более ценными, чем показатели?<\/p>\n<p>Руководствуясь нашими принципами, мы в конечном итоге определили четыре измерения качества данных: Точность, Надежность (Своевременность), Управление и Удобство использования. Было несколько других возможных измерений, которые мы рассматривали, но эти четыре измерения были наиболее смысловыми и полезными для наших практиков данных и имели смысл как оси улучшения, на которых нам важно и мы готовы инвестировать в улучшение наших данных вдоль этих измерений.<\/p>\n<p>Каждое измерение могло объединять неявные и явные показатели качества, где ключевое заключалось в том, что не каждый потребитель данных должен полностью понимать каждый отдельный компонент оценки, но они будут понимать, что набор данных, который плохо справляется с Надежностью и Удобством использования.<\/p>\n<p>Мы также могли бы взвесить каждое измерение в соответствии с нашим восприятием его важности для определения качества. Мы учитывали 1) сколько оценочных компонентов принадлежит каждому измерению, 2) обеспечивая быстрый умственный расчет, и 3) какие элементы важны больше всего для наших практикующих, чтобы распределить 100 общих баллов между измерениями:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-19.png\" width=\"1256\" height=\"410\" alt=\"\" \/>\n<div class=\"e2-text-caption\">The “Dimensions of Data Quality” and their weights<\/div>\n<\/div>\n<p>Тем временем, при необходимости, измерения могут быть раскрыты для получения более детального представления о проблемах качества данных. Например, измерение “Стюардшип” оценивает актив для показателей качества, таких как то, построено ли оно с использованием наших инструментов для инженерии данных, его соблюдение правил управления, и соответствие стандартам валидного владения данных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-20.png\" width=\"1400\" height=\"911\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Unpacking the Data Stewardship Dimension<\/div>\n<\/div>\n<p>Представление Рейтинга для Практиков<\/p>\n<p>Мы понимали, что представление Рейтинга качества данных в формате, который можно исследовать и использовать, является ключевым моментом для его принятия и успеха. Кроме того, нам нужно было предоставить информацию о качестве данных непосредственно в том месте, где пользователи данных уже обнаруживали и исследовали данные.<\/p>\n<p>К счастью, у нас было два существующих инструмента, которые сделали бы это гораздо проще: Dataportal (каталог данных и пользовательский интерфейс для исследования данных Airbnb) и Unified Metadata Service (UMS). Сам рейтинг вычисляется в ежедневном автономном потоке данных, который собирает и преобразует различные элементы метаданных из наших систем данных. Завершающий этап потока данных загружает рейтинг для каждого актива данных в UMS. Подключив DQ Score к UMS, мы можем предоставлять рейтинг и его компоненты наряду с каждым активом данных в Dataportal, отправной точке для всех открытий и исследований данных в Airbnb. Оставалось только разработать его представление.<\/p>\n<p>Одной из наших целей было предоставить концепцию качества данным практикующим с различным уровнем экспертизы и потребностей. Наши пользователи полностью приняли динамичный подход “сертифицированные против несертифицированных”, но впервые мы представляли концепцию спектра качества, а также критерии, используемые для его определения.<\/p>\n<p>Какова была бы наиболее интерпретируемая версия Рейтинга качества данных? Нам нужно было представить единый рейтинг качества данных, который был бы понятен на первый взгляд, а также делать возможным исследование рейтинга более подробно.<\/p>\n<p>Наш конечный дизайн представляет качество данных тремя способами, каждый со своим особым применением:<\/p>\n<ol start=\"1\">\n<li>Единый высокоуровневый рейтинг от 0 до 100. Мы установили категориальные пороги “Плохо”, “Хорошо”, “Отлично” и “Превосходно” на основе анализа профилирования нашего хранилища данных, который изучал существующее распределение нашего Рейтинга DQ. Подходит для быстрой высокоуровневой оценки общего качества набора данных.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Измерения рейтинга, где актив может иметь идеальный балл по точности, но низкий по надежности. Полезно, когда конкретная область недостатка не проблематична (например, потребитель хочет, чтобы данные были очень точными, но не беспокоится о том, что они поступают каждый день быстро).<\/li>\n<\/ol>\n<ol start=\"3\">\n<li>Полная детализация рейтинга + Шаги по улучшению, где пользователи данных могут видеть, в чем конкретно актив уступает, и продюсеры данных могут предпринять меры для улучшения качества актива.<\/li>\n<\/ol>\n<p>Все три эти представления показаны на скриншотах ниже. Стандартное представление предоставляет измерения “Баллы за категорию”, категориальный дескриптор “Плохо” вместе с 40 баллами и шагами по улучшению.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-21.png\" width=\"1400\" height=\"1208\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Full data quality score page in Dataportal<\/div>\n<\/div>\n<p>Если пользователь исследует полные детали рейтинга, он может изучить конкретные недостатки качества и просматривать информативные подсказки, предоставляющие более подробное описание определения и заслуг компонента оценки.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-22.png\" width=\"1400\" height=\"1545\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Full score detail presentation<\/div>\n<\/div>\n<p>Как сегодня используется рейтинг<\/p>\n<p>Для производителей данных рейтинг предоставляет:<\/p>\n<p>Ясные, действенные шаги для улучшения качества данных своих активов.<br \/>\nКоличественную оценку качества данных, измеряя их работу.<br \/>\nЯсные ожидания в отношении качества данных.<br \/>\nЦели для устранения технического долга.<br \/>\nДля потребителей данных рейтинг качества данных:<\/p>\n<p>Повышает обнаруживаемость данных.<br \/>\nСлужит сигналом доверия к данным (аналогично тому, как работает система отзывов для гостей и хозяев Airbnb).<br \/>\nИнформирует потребителей о конкретных недостатках качества, чтобы они могли быть уверены в использовании данных.<br \/>\nПозволяет потребителям искать и требовать качества данных.<br \/>\nС точки зрения стратегии данных, мы используем внутренние данные запросов в сочетании с рейтингом качества данных для управления усилиями по улучшению качества данных в нашем хранилище данных. Рассматривая как объем, так и тип потребления (например, является ли определенная метрика доступной в нашем исполнительском отчете), мы можем направлять команды данных на наиболее значимые улучшения качества данных. Эта видимость была очень просветительной для команд, которые не были осведомлены о своем длинном хвосте активов низкого качества, и она позволила нам удвоить усилия в области инвестиций в качество для сложных моделей данных, которые обеспечивают значительную часть нашего потребления данных.<\/p>\n<p>Наконец, разработав рейтинг качества данных, мы смогли предоставить единое руководство нашим производителям данных по созданию высококачественных, хотя и несертифицированных активов. Рейтинг качества данных не заменил сертификацию (например, только данные, сертифицированные Midas, могут получить рейтинг DQ > 90). Мы продолжаем сертифицировать наш самый критический поднабор данных и считаем, что сценарии использования для этих активов всегда будут обосновывать ручную проверку, строгость и поддержание сертификации. Но для всего остального рейтинг DQ укрепляет и масштабирует принципы Midas в нашем хранилище данных.<\/p>\n<p>Что дальше<\/p>\n<p>Мы рады тому, что теперь можем измерять и наблюдать количественные улучшения в качестве данных, но мы только начали. Недавно мы расширили исходный рейтинг DQ, чтобы оценивать наши метрики и измерения Minerva. Точно так же мы планируем внедрить концепцию рейтинга DQ для других активов данных, таких как наши журналы событий и функции машинного обучения.<\/p>\n<p>Поскольку требования и запросы к нашим данным продолжают развиваться, также будут меняться наши ожидания качества. Мы будем продолжать разрабатывать, как мы определяем и измеряем качество, и с быстрым улучшением в областях, таких как управление метаданными и классификация данных, мы ожидаем дополнительного повышения эффективности и производительности для всех практиков данных в Airbnb.<\/p>\n<p>Благодарности<\/p>\n<p>Рейтинг DQ не был бы возможен без участия нескольких кросс-функциональных и кросс-организационных коллег. К ним относятся, но не ограничиваются: Марк Стейнбрик, Читта Широлкар, Джонатан Паркс, Сильвия Томияма, Феликс Оук, Джейсон Флиттнер, Ин Пан, Логан Джордж, Вуди Чжоу, Мишель Томас и Эрик Риттер.<\/p>\n<p>Отдельное спасибо членам обширного сообщества данных Airbnb, которые предоставили входные данные или помощь команде реализации на протяжении фаз дизайна, разработки и запуска.<\/p>\n<p>Если вас интересует такая работа, ознакомьтесь с некоторыми из наших связанных вакансий.<\/p>\n<p>****************<\/p>\n<p>Все названия продуктов, логотипы и бренды являются собственностью соответствующих владельцев. Все названия компаний, продуктов и услуг, использованные на этом сайте, представлены исключительно в информационных целях. Использование этих названий, логотипов и брендов не подразумевает их одобрение.<\/p>\n<p>Перевод ChatGPT<\/p>\n",
            "date_published": "2023-12-27T23:00:29+03:00",
            "date_modified": "2023-12-27T23:00:13+03:00",
            "tags": [
                "big data",
                "Data Governance",
                "Data Quality"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-19.png",
            "_date_published_rfc2822": "Wed, 27 Dec 2023 23:00:29 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "106",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-19.png",
                    "https:\/\/gavrilov.info\/pictures\/image-20.png",
                    "https:\/\/gavrilov.info\/pictures\/image-21.png",
                    "https:\/\/gavrilov.info\/pictures\/image-22.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}