dbt Squared: Использование dbt Core и dbt Cloud вместе в масштабе

Команды процветают, когда каждому члену команды предоставляются инструменты, которые наилучшим образом дополняют и усиливают их навыки. Вы бы не дали Криштиану Роналду теннисную ракетку и не ожидали бы идеальной подачи! В Roche предоставление правильных инструментов нашим коллегам было критически важным для того, чтобы увеличить нашу команду по работе с данными с 10 основных инженеров до более чем 100 участников всего за два года. Мы приняли как dbt Core, так и dbt Cloud в Roche (решение dbt-squared, если хотите!) для быстрого масштабирования нашей платформы данных.

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

• Технологии: dbt на CLI был подходящим инструментом для основных инженеров, но не мог масштабироваться для наших аффилированных команд. dbt Cloud стал катализатором их вклада в платформу.
• Люди: Нам нужно было интегрировать команды, хорошо разбирающиеся в SQL, но новые в dbt, в наш рабочий процесс с минимальными препятствиями.
• Процесс: Локальные процессы CI/CD, GitOps и разработки в основной команде нуждались в адаптации, чтобы позволить большему количеству участников и обеспечить качество в масштабе.

dbt Core дал старт росту нашей платформы данных, а dbt Cloud позволил нам распространить ее по всему миру. Сегодня мы можем:

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

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

С чего мы начали

Наш путь с dbt в Roche начался примерно 3 года назад, когда мы начали строить облачную систему рекомендаций контента, адаптированную для наших торговых представителей. Мы начали с небольшой команды из менее чем 10 человек и разработали нашу основную архитектуру на основе некоторых четко определенных принципов: развертывать все как код, выбирать серверлесс, когда это возможно, и применять Extract Load Transform вместо Extract Transform Load.

С этими принципами на уме мы разработали высокомасштабируемую архитектуру, используя сервисы AWS для извлечения и загрузки данных в озеро данных на основе S3 и кластер Data Warehouse Redshift. Помните, когда мы начинали, Redshift Serverless еще не существовал! Все преобразования данных происходят в хранилище с использованием (угадайте!) dbt.

Простота dbt в сочетании с вычислительной мощностью Redshift позволила нам реализовать архитектуру Data Vault, способную поддерживать нашу систему рекомендаций контента. После успеха здесь возник интерес к масштабированию платформы для множества новых случаев использования в коммерческой фармацевтической области.

Проблема масштабируемости

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

Технологии

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

1. Действовать как катализатор для повторного использования кода и обмена лучшими практиками
2. Легче делиться общими моделями и макросами, которые охватывают несколько стран в проектах
3. Продвигать общий рабочий процесс — инженер, работающий сегодня над случаем использования в Бразилии, мог бы легко работать завтра над решением для Германии.

Вторым архитектурным решением было, создавать ли один проект dbt для всех 50+ страновых команд или следовать многопроектному подходу, в котором каждая страна имела бы свой отдельный проект dbt в общем репозитории. Было критически важно, чтобы каждая страновая команда могла двигаться с разной скоростью и имела полный контроль над своими доменами. Это позволило бы избежать таких проблем, как коллизии имен моделей между странами, и устранить зависимости, которые могли бы привести к каскадным ошибкам между странами. Поэтому мы выбрали подход "один проект на страну".

Структура проекта Roche, как видно в репозитории

Получившийся поток данных от основной команды к страновым командам теперь следует этой схеме. База данных Sources содержит все необработанные данные в кластере Redshift, а база данных Integrated содержит курированные и готовые к потреблению выходные данные из основного проекта dbt. Эти выходные данные называются Продуктами Исходных Данных (SDP). Эти SDP затем используются основной командой для создания Глобальных Продуктов Данных — продуктов, адаптированных для ответа на бизнес-вопросы глобальных заинтересованных сторон. Они также фильтруются на уровне стран и используются в качестве источников для страновых Продуктов Данных, управляемых страновыми командами. Эти продукты, в свою очередь, размещаются в соответствующей базе данных affiliate_db_<country>. Разделение на уровне базы данных облегчает управление данными и управление конфиденциальностью.

Структура проекта Roche, как видно в репозитории

Люди

В начале пути мы сформировали основную команду с нуля, отбирая людей с большим опытом в инженерии, которые были комфортны в работе с командной строкой. С другой стороны, страновые команды состояли из людей, работающих с устаревшими системами данных в компании — некоторые из них имели глубокое понимание таких технологий, как Informatica, Talend или Hadoop. У всех было одно общее — никто никогда не использовал dbt.

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

Процесс

Успех этой программы зависел от принятия практик DevOps с самого начала. Это требовало культурного сдвига, что может быть особенно сложным в крупных организациях. Нам нужно было взять процессы DevOps, которые хорошо работали для основной команды, и масштабировать их для десятков команд, чтобы обеспечить тот же уровень качества и согласованности в наших продуктах данных. Благодаря бесшовной интеграции dbt с git, наши процессы CI/CD смогли масштабироваться без усилий, позволяя автоматизировать тестирование, сборку и выпуск наших конвейеров.

Часто упускаемый из виду, этот третий столп процесса может быть ключом к успеху при масштабировании глобальной платформы. Простые вещи, такие как учет разницы в часовых поясах, могут определить, будет ли сообщение понято всеми. Чтобы облегчить коммуникацию и координацию между глобальными и страновыми командами, все команды следуют одному и тому же циклу спринта, и мы проводим еженедельные scrum of scrums. Нам нужно было создать обширную документацию по внедрению, обеспечить новичкам надлежащее обучение и руководство, а также создать выделенные каналы в Slack для объявлений, отчетов о происшествиях и случайных мемов, помогая строить сообщество, которое простирается от Бразилии до Малайзии.

Структура проекта Roche, как видно в репозитории

Решение: dbt Squared

Технологии и люди

Различные уровни технической зрелости наших команд требовали различных технических решений. Основная команда была хорошо знакома с dbt Core (даже вносила вклад в проект!) и работала над одним и тем же проектом в течение 3 лет, используя лучшие практики разработки программного обеспечения (например, CI/CD, модульные тесты, линтинг и pre-commit хуки). Аффилированные команды имели заметно другой опыт работы с этими инструментами. Таким образом, мы внедрили dbt Cloud для страновых команд, чтобы избежать их интеграции в сложные основные рабочие процессы, что бы их ненужно замедлило.

dbt Cloud устранил необходимость в настройке локальных сред; не нужно беспокоиться о версиях библиотек или об установке клиентов git. Вместо этого они быстро создавали и тестировали модели dbt. Поскольку SQL является второй натурой для всех страновых команд (независимо от платформы, которую они использовали до dbt), они освоили dbt в кратчайшие сроки, и потребность в поддержке со стороны основной команды быстро стала минимальной.

Эта автономия оказалась критически важной; в противном случае было бы непрактично иметь полностью централизованную команду поддержки. Мы назначили региональных лидеров для наблюдения за работой нескольких страновых команд. Это сделало страновые команды менее зависимыми от основных команд; теперь разные страны могли сотрудничать в работе с dbt независимо.

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

Процесс

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

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

Поток настройки проекта

Поскольку мы решили использовать многопроектную архитектуру, требовалась некоторая начальная настройка. Каждая страна нуждалась в проекте dbt в нашем Git-репозитории, а также в развертывании в dbt Cloud… дважды, так как у каждого аффилиата есть проект для разработки и проект для производства. Чтобы избежать ручной настройки всех проектов в интерфейсе dbt Cloud, мы реализовали библиотеку на Python в качестве обертки вокруг Административного API dbt Cloud. Это читало YAML-файл конфигурации и автоматически развертывало все проекты. Это сэкономило много времени, так как у нас уже был настроен проект dbt новой команды как в git-репозитории, так и в dbt Cloud, как только они были готовы начать строить.

Поток разработки

Основные команды, использующие dbt на CLI, часто использовали команду defer, которая может быть использована в dbt Cloud, но требует обходного пути, который включает в себя внедрение файла манифеста производства в ваш репозиторий. Несколько раундов плодотворных обсуждений с командой dbt Labs привели нас к использованию “Proxy Views”, которые эмулируют функциональность клонирования без копирования и позволяют использовать аналогичный рабочий процесс defer. Для работы этого решения нам также нужно было переопределить макрос redshift__list_relations_without_caching (для получения более подробной информации, пожалуйста, прочитайте комментарии нашего ведущего инженера Якуба Лански здесь). Это позволяет каждому инженеру разрабатывать и тестировать свои модели без необходимости полностью воссоздавать зависимости вверх по потоку. Вместо этого эти зависимости моделей вверх по потоку создаются как представления в целевой схеме разработчика, которые указывают на их производственные аналоги. Это особенно критично при реализации моделей, которые зависят от десятков зависимостей вверх по потоку. Избегая ненужного дублирования данных, мы значительно сократили время разработки.

Поток выпуска

И наконец, основная команда использует фреймворк pre-commit, чтобы обеспечить качество кода перед открытием запросов на слияние в общую ветку. Основная команда также использует sqlfluff, чтобы стандартизировать код в нескольких потоках работы. Поскольку dbt Cloud пока не предлагает возможность запускать pre-commit хуки непосредственно в IDE, мы перенесли эти рабочие процессы в проверки CI. Эти проверки запускаются, когда создается запрос на слияние в общую ветку, гарантируя, что даже если разработчик не использует фреймворк локально, изменения кода оцениваются перед завершением слияния.

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

Заключение

Менее чем за год мы смогли мигрировать изолированные конвейеры данных из таких инструментов, как Informatica, Spark, Talend и Oracle, в dbt, обеспечивая работу почти 50 дашбордов сегодня.

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

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

Примечание редактора: Эта статья была написана Жоао Антунесом и Янником Мистели из Roche, с редакционным и техническим руководством от Шона Макинтайра из dbt Labs