Data ecosystem

Введение​

Год был 2020. Я жила в доме, где были только котята, а dbt Labs все еще называлась Fishtown Analytics. Один из корпоративных клиентов, с которым я работала, Jetblue, попросил меня помочь запускать их модели dbt каждые 2 минуты, чтобы соответствовать SLA в 5 минут.

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

Перенесемся в 2023 год. Я пишу это, пока мой огромный пес храпит рядом со мной (не волнуйтесь, коты тоже размножились). Jetblue переросла lambda views из-за ограничений производительности (представление может быть только настолько производительным), и мы находимся на очередной вехе в пути dbt к поддержке потоковой передачи. Какое время!

Сегодня мы объявляем, что теперь поддерживаем материализованные представления в dbt. Итак, что это значит?

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

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

Data Vault 2.0 — это техника моделирования данных, разработанная для масштабирования крупных проектов по созданию хранилищ данных. Это строгая, предписывающая система, подробно описанная в книге, ставшей библией для этой техники.

Так почему же Data Vault? Вы сталкивались с проектом по созданию хранилища данных с более чем 50 источниками данных, с более чем 25 разработчиками данных, работающими на одной платформе данных, или с данными, охватывающими более 5 лет с двумя или более поколениями исходных систем? Если нет, то может быть сложно изначально понять преимущества Data Vault, и, возможно, моделирование по Кимбаллу будет лучше для вас. Но если вы находитесь в любой из перечисленных ситуаций, то эта статья для вас!

dbt Cloud — это хостинговый сервис, который многие организации используют для своих развертываний dbt. Среди прочего, он предоставляет интерфейс для создания и управления заданиями развертывания. Когда задания запускаются (например, по расписанию cron или через API), они генерируют различные артефакты, содержащие ценную метадату, связанную с проектом dbt и результатами выполнения.

dbt Cloud предоставляет REST API для управления заданиями, артефактами выполнения и другими ресурсами dbt Cloud. Инженеры по данным/аналитике часто пишут пользовательские скрипты для автоматизированных вызовов API, используя инструменты cURL или Python Requests. В некоторых случаях инженеры копируют/переписывают их между проектами, которым нужно взаимодействовать с API. Теперь у них есть куча скриптов, которые нужно поддерживать и развивать, если изменяются бизнес-требования. Если бы только существовал специальный инструмент для взаимодействия с API dbt Cloud, который абстрагировал бы сложности вызовов API за простым в использовании интерфейсом... О, подождите, он есть: dbt-cloud-cli!

Особая благодарность: Emilie Schario, Matt Winkler

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

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

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

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

Наличие шаблона запроса на слияние (PR) GitHub — один из самых важных и часто упускаемых из виду аспектов создания эффективного и масштабируемого аналитического рабочего процесса, ориентированного на dbt. Открытие запроса на слияние — это финальный шаг в вашем процессе моделирования, который обычно включает в себя много сложной работы!

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

Airflow и dbt часто рассматриваются как взаимоисключающие:

Вы либо строите SQL-трансформации, используя SQL-операторы базы данных Airflow (например, SnowflakeOperator), либо разрабатываете их в проекте dbt.

Вы либо оркестрируете модели dbt в Airflow, либо развертываете их, используя dbt Cloud.

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