Инженеры данных + dbt v1.5: Эволюция мастерства для масштабирования

Я, Сунг, случайно попал в индустрию данных осенью 2014 года. Я использовал нечто под названием язык команд аудита (ACL) для автоматизации дебетов, равных кредитам, для аналитики бухгалтерского учета (да, это так же утомительно, как звучит). Я помню, как усердно работал в гостиничном номере в Де-Мойне, штат Айова, где самым интересным местом был Panda Express. Было поздно ночью, около 2 часов утра. Я сделал шаг назад и подумал: «Почему я так усердно работаю над чем-то, что мне неинтересно, с инструментами, которые больше вредят, чем помогают?»

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

Технические навыки	Место в технологическом стеке	Почему это было важно в то время
Airflow	Оркестратор	Промышленный стандарт для запуска конвейеров данных
SQL	Лингва франка преобразования данных	Моя бизнес-логика закодирована (например: доход по месяцам)
Python	Лингва франка инженерии данных	Это то, как вы используете Airflow
Terraform	Подготовка инфраструктуры для кластера Kubernetes в Airflow	Автоматизация инфраструктуры
Google Cloud	Облако	Большая клиентская база
Amazon Web Services	Облако	Большая клиентская база
dbt	T в ELT	Причина, по которой люди наконец тестируют свои данные с помощью SQL
BigQuery	Облачный склад данных	Многие из моих клиентов использовали это

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

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

Я все еще жонглирую своими беспорядочными конвейерами данных и задаюсь вопросом, что является сигналом, а что шумом в том, как развивать свои навыки. Я чувствую себя инженером данных на 0,5x. Это как сделать 2 шага вперед и 1 большой шаг назад. Так что мой вопрос становится:

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

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

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

Где dbt встречает инженеров данных и куда он движется

Радости и боли инженерии данных и аналитической инженерии реальны; победа, которую вы получаете, когда заинтересованная сторона в конечном итоге вносит вклад в модель dbt; потеря, когда конвейер ломается, и шквал уведомлений в Slack, которые обрушиваются на вас. dbt преобразовал ;) способ взаимодействия команд данных с их данными и людьми, которые от них зависят. Когда dbt был впервые разработан, он стремился привнести лучшие практики в области программной инженерии в область аналитики — это означало версионное управление, тщательное тестирование и совместные преобразования данных. dbt принес тесты на основе кода, интегрированное CI, эффективную разработку с пакетами и глобальную документацию. Эти функции стали основой того, как работают команды данных, и позволили инженерам данных сосредоточиться на самой важной части своей работы: создании конвейеров данных, которые питают бизнес.

Строим будущее: куда идут инженеры данных с dbt

По мере роста dbt росла и сложность проектов dbt. Тристан много писал об этом, но несколько лет назад большой проект dbt состоял из ~500 моделей. Сегодня существует множество организаций с тысячами моделей dbt. Этот уровень сложности и организации изменил ландшафт интересных проблем в области аналитической инженерии; графы зависимостей становятся все больше, определение владельцев становится неясным, и барьер для вклада повышается. Вы можете увидеть, как более крупные и сложные команды данных подходят к этому сегодня в этом публичном обсуждении на GitHub: https://github.com/dbt-labs/dbt-core/discussions/5244.

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

Ниже мы разберем, как dbt v1.5 развивает масштаб и контроль в вашей работе и как это повысит вашу ежедневную практику инженерии данных (и уберет некоторые из тех панических сообщений в Slack 😉).

Контракты моделей

• Проблемы, с которыми вы сталкиваетесь: Я не могу гарантировать форму моих данных (например: имена столбцов, типы данных, отсутствие пустых значений) без тройной проверки моей работы и многократного запуска dbt build и визуальной проверки моих данных. Я устаю делать это каждый день, поэтому в долгосрочной перспективе я перестаю это делать.
• Решение: Контракты моделей позволяют вам определить, как модель должна соответствовать — какие столбцы никогда не будут null, какие столбцы всегда будут определенного типа и многое другое — все это в файле YAML. Эти контракты предназначены для создания уровней ответственности между теми, кто создает модель с контрактом, и конечными потребителями этой модели.
• Как это изменит вашу ежедневную работу: Долгий сомнение — "могу ли я доверять этой таблице?" — устраняется с помощью контракта модели. Эти контракты создают системы ответственности, управления и надежности, в конечном итоге позволяя людям чувствовать уверенность в моделях, на которые они ссылаются. С контрактом вам не нужно тестировать, является ли первичный ключ из вышестоящей ссылки null, контракт это указал — и этот контракт является законом.

# пример контракта для snowflake
models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: id
        data_type: integer
        description: hello
        constraints:
          - type: not_null
          - type: primary_key # не применяется -- будет предупреждение и включение в DDL
          - type: check       # не поддерживается -- будет предупреждение и исключение из DDL
            expression: "id > 0"
        tests:
          - unique            # ограничение primary_key не применяется
      - name: customer_name
        data_type: text
      - name: first_transaction_date
        data_type: date

--SQL выполняется в базе данных
create or replace transient table <database>.<schema>.dim_customers        
(
    id integer not null primary key,
    customer_name text,
    first_transaction_date date  
)
as
(
select 
  1 as id, 
  'My Favorite Customer' as customer_name, 
  cast('2019-01-01' as date) as first_transaction_date
);

Версии моделей

• Проблемы, с которыми вы сталкиваетесь: Я меняю свою важную модель fct_orders.sql каждую неделю, и многие люди полагаются на нее в своей работе. Однако я продолжаю получать сомнительные вопросы о том, что изменилось с момента моего последнего обновления, и у меня нет хорошего способа вселить уверенность, что это не сломает то, на что они полагаются.
• Что это такое: Версии моделей в v1.5 позволяют вам создавать, указывать и ссылаться на версии моделей. Основные отчетные модели теперь могут обновляться и устаревать, следуя практикам программной инженерии, и создавать системы ответственности между создателями данных и потребителями данных.
• Как это изменит вашу ежедневную работу: Не каждая модель нуждается в версионности, но для основных моделей, которые питают вашу бизнес-аналитику, питают вашу команду данных, у вас теперь будет возможность создавать несколько версий модели и внедрять критические изменения более реалистичным и ответственным образом. Скажем, я основной владелец dbt Проекта A основной команды данных, и внутри этого проекта содержится основная модель dim_customers, которая питает способ анализа данных о клиентах и CLV (пожизненная ценность клиента) для финансов, успеха клиентов и маркетинга. Мне нужно внести критическое изменение в dim_customers — CLV будет удален в пользу более сложного значения ROI. Финансовая команда использует существующее значение CLV для когортного анализа и других отчетов, но понимает, что новый столбец ROI может быть более предпочтительным со временем. Однако требуется время, чтобы перейти на эти отчеты и системы, чтобы соответствовать значениям ROI, поэтому Проект A может разработать dim_customers_v2, который заменяет LTV на новый ROI.

models:
  - name: dim_customers
    latest_version: 2
    config:
      contract:
        enforced: true
    columns:
      - name: id
        data_type: integer
        description: hello
        constraints:
          - type: not_null
          - type: primary_key # не применяется -- будет предупреждение и включение в DDL
          - type: check       # не поддерживается -- будет предупреждение и исключение из DDL
            expression: "id > 0"
        tests:
          - unique            # ограничение primary_key не применяется, поэтому также проверяйте с помощью теста dbt
      - name: customer_name
        data_type: text
      - name: first_transaction_date
        data_type: date
    versions:
      - v: 2
        columns: 
          - include: '*'
            exclude: ['first_transaction_date']
      - v: 1
        columns:
          - include: '*'
        defined_in: dim_customers

select * from {{ ref('dim_customers', v=2) }}

Доступ к моделям

• Проблемы, с которыми вы сталкиваетесь: Я разделил свои подкаталоги проекта dbt на продажи, маркетинг и финансы, и у меня большая команда, которая ежедневно ссылается на модели dbt в этих папках. Однако я замечаю, что многие ссылки используют промежуточные таблицы, которые не завершены и не должны использоваться. У меня нет хорошего способа предотвратить неправильные ссылки.
• Что это такое: Теперь вы можете определять публичные, частные и защищенные модели в подкаталогах и моделях проекта dbt, чтобы ваши коллеги касались только того, что им положено!
• Как это изменит вашу ежедневную работу: Изнурительные вздохи, когда вы говорите своим коллегам: «вы не должны использовать эту модель», теперь исчезли. dbt практикует энергичные границы между несколькими файлами и подпапками и объясняет вашим коллегам, почему они не могут ссылаться на конкретную модель dbt.

models:
  - name: finance_model
    access: private
    group: finance
  - name: marketing_model
    group: marketing

--models/marketing/marketing_model.sql

select * from {{ ref('finance_model') }}

$ dbt run -s marketing_model
...
dbt.exceptions.DbtReferenceError: Parsing Error
  Node model.jaffle_shop.marketing_model attempted to reference node model.jaffle_shop.finance_model, 
  which is not allowed because the referenced node is private to the finance group.

Как выглядит победа с v1.5 для вас, инженера данных?

Это все замечательно, но как мы узнаем, работают ли эти функции, чтобы сделать вашу работу более упорядоченной, интуитивной или легкой? Потому что вы, вероятно, задаетесь вопросом: «Пытаемся ли мы раздуть v1.5 как эту серебряную пулю, чтобы решить все проблемы с преобразованием данных?» Краткий ответ: «Нет». Мы просто хотим иметь меньше головной боли, когда дело доходит до управления и масштабирования вашей работы с данными, и вернуть радость работы с данными.

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

😊 Эмоциональная победа	📝 Будущие пункты резюме
Пригласите людей в магию работы с данными и в данных	- Масштабировал с 10 до 500 пользователей в dbt Cloud и, в среднем, вводил новых пользователей за 1 неделю
На шаг ближе к самообслуживанию без закатывания глаз	- Установил время безотказной работы 99,99% с основными метриками, такими как доход, маркетинг, отток с контрактами моделей и dbt Semantic Layer и сократил усилия по проверке данных бизнесом на 5 часов в неделю
Утомительная административная работа исчезает, и вы получаете облегчение, зная, что люди не «двигаются быстро и ломают вещи»... так часто	- Сократил 5% всех затрат на преобразование с меньшим количеством кода, реализуя контракты моделей данных с 10% более высоким качеством. Убрал 4 часа на человека в неделю в командах по финансам, маркетингу, продажам, сократив дублирующую разработку на 20% и сократив базовый сбор контекста
Почувствуйте вкус быть в наступлении, а не в защите в своей работе	- Использовал dbt для увеличения дохода (например: встроенные продукты данных) и добавил новый SKU, приносящий $500,000 в год

Итак, что дальше?

• Попробуйте v1.5! Дайте нам знать, как вам эргономика и функциональность контрактов моделей, версий и групповых разрешений. Откройте проблему, если заметите какие-либо ошибки.
• Посмотрите запись сообщества о контрактах — отличный способ увидеть их в действии — или посмотрите запись со Staging, чтобы увидеть функции dbt v1.5 в действии!
• Комментируйте прямо в этом посте свои мысли о v1.5 или этой статье!
• Присоединяйтесь к каналу #multi-project в dbt Community Slack — начните обсуждения с людьми, как я, о болях и достижениях в проектах с многократным развертыванием dbt. Убедитесь, что конструкции в v1.5 хорошо переводятся на будущее с многопроектной структурой.