Dbt или не dbt, вот в чем вопрос
Уроки, извлеченные из опыта внедрения dbt в компании Intercom в течение одного года
Если Вы работаете с данными, то Вам, вероятно, хорошо знакомы проблемы, связанные с управлением аналитической кодовой базой. Многогранный SQL, спагетти-код, устаревшие преобразования, запутанная история данных, временные анализы, удобно расположившиеся посреди производственных отчетов, неоднородные типы данных, отсутствие последовательных соглашений об наименовании - вот лишь некоторые из них. В Intercom мы также столкнулись со всеми этими проблемами...
Именно поэтому для управления преобразованиями данных чуть больше года назад было принято решение внедрить dbt. Сегодня мы размышляем о том, что нам нравится в dbt, что не нравится, а также о том, какие уроки мы извлекли из внедрения dbt в существующую кодовую базу, уже содержавшую тонну преобразований.
Плюсы
Начнем с положительных моментов.
Упорядоченная кодовая база
Нам очень нравится то, что dbt не зависит от структуры папок, необходимых для организации кодовой базы. Несмотря на то, что вначале нам потребовалось несколько итераций, чтобы сделать все правильно, теперь у нас есть проверенный способ хранения основных фактов и измерений, моделей агрегированной отчетности и рисков. Все промежуточные этапы, необходимые для построения любой из этих моделей, хранятся в одной подпапке с моделью, в которой они используются.
В результате мы получили упорядоченную кодовую базу, которую легко читать и в которую достаточно легко внедрять людей - если Вы можете понять, как работает одна модель, тогда совершенно точно Вы сможете разобраться во всех остальных.
Постановочные модели (Staging models)
Постановочные модели - отличный способ обеспечить согласованность данных в Вашей кодовой базе. Мы используем наши модели для объединения данных из разных источников в общую таблицу, переименования столбцов в соответствии с последовательными шаблонами, распаковки столбцов JSON и приведение столбцов к определенным типам данных.
Это полезно, поскольку в производственных таблицах очень часто встречаются несоответствия в способах хранения данных, например, двоичные столбцы, которые могут быть не только TRUE/FALSE, но и 1/0, и эти незначительные различия иногда могут привести к совершенно неожиданным ошибкам на последующих этапах. Постановочный слой дает нам возможность выявить эти несоответствия и оперативно их исправить.
Моментальные снимки (Snapshots)
Если Вы когда-либо пытались создать таблицы медленно меняющихся измерений, используя только SQL и Airflow (или какой-либо другой аналогичный инструмент), то Вы наверняка знаете, насколько это сложно. Вы либо каждый день создаете полный архив таблицы, стремительно увеличивая объем данных, либо берете текущее состояние таблицы, сравниваете его со «старым» состоянием, затем обрабатываете строки, которые изменились, обрабатываете новые строки, которые были вставлены, обрабатываете строки, которые были удалены в источнике, и так далее.
dbt помещает всю эту логику в команде Snapshot, что значительно облегчает процесс создания подобныхх таблиц. Вы вводите ссылку на нужную Вам модель в команду Snapshot, а все остальное за Вас делает dbt.
Lineage и оркестрация данных — другими словами, "ref" и "source"
Методы определения ссылок на модели в dbt "ref" и "source" достаточно просты и при этом эффективны. Вместо того чтобы указывать на имя производственной таблицы, Вы указываете на "источник". Вы даже можете изменить базовые таблицы, используемые в исходной модели, и все последующие модели автоматически адаптируются к внесенным изменениям.
Точно также метод "ref" строит граф зависимостей для Ваших моделей. До появления dbt в случае, если Вам нужно было «протянуть» изменения через некоторые промежуточные этапы, Вам пришлось бы вручную выполнять запросы для построения каждой из этих моделей вплоть до конечной модели. Например, допустим, у Вас есть агрегированная таблица, в которой представлены данные об ARR Вашей организации за разные годы. Вы обнаружили, что один из счетов был зафиксирован не в том регионе, и поэтому часть выручки отобразилась так, как будто она поступила из региона EMEA, а на самом деле - из APAC. Чтобы исправить этот недочет, сначала нужно исправить таблицу измерений, в которой хранится информация о счетах, и только потом перестроить сводную таблицу, в которой отображается ARR.
С помощью dbt Вам нужно просто запустить dbt run -s dim_accounts+, и dbt обновит все модели, расположенные ниже таблицы измерения счетов. Мы использовали упрощенный пример, включающий двухэтапное преобразование, на практике же процесс создания отчетов, как правило, намного сложнее и обычно включают в себя несколько промежуточных этапов, которые необходимо обновить, прежде чем необходимые изменения будут отражены в итоговом отчете.
Макросы
Одним из главных недостатков SQL всегда было отсутствие возможности использовать функции или методы. Да, вы можете создавать UDF-функции, но их нужно "устанавливать" на Ваше хранилище или SQL-движок, а их базовые определения часто хранятся во внешней кодовой базе. Каждый раз, когда Вы вносите изменения, Вам приходится заново устанавливать их на хранилище, а это неудобно и трудно.
Макросы dbt справляются с этой задачей на ура.
Один из способов использования макросов, которым мы очень гордимся, - это работа с конфиденциальными данными в таблицах медленно меняющихся измерений. В них хранится вся история изменений для каждого объекта. Эта история также содержит конфиденциальную информацию. Когда какая-либо запись удаляется из источника - скажем, при закрытии счета, - нам нужно убедиться в том, что мы удалили все следы данных, которые можно считать конфиденциальными. Чтобы решить эту проблему, мы создали макрос, который запускается на каждом снимке и удаляет все необходимее конфиденциальные данные.
Еще один макрос вычисляет схему, в которой должны быть материализованы Ваши модели, в зависимости от того, работают они локально или на производстве, и автоматически создает отдельные схемы разработчика. Вы можете превратить часто используемые фрагменты запросов в макросы, выбрать запуск вариаций запроса в зависимости от окружения, ограничить данные, которые Вы используете во время разработки и итераций – возмжности практически неограниченны.
Чтобы значительно упростить Вашу жизнь, dbt поставляется с некоторыми полезными макросами, уже встроенными в dbt_utils, которые основаны на распространенных случаях, с которыми все мы с Вами периодически сталкиваемся. Вы когда-нибудь делали группировку по 1, 2, 3, 4, 5, 6, 7, 8, 9? Так это dbt_utils.group_by(9) делает для Вас. Точно также dbt_utils.union_relations выполнит безопасное объединение двух таблиц, даже если они не содержат одинакового набора столбцов.
Тесты
Хотя встроенные тесты dbt довольно примитивны, они настолько просты в реализации, что их трудно не полюбить. Даже такие вещи, как проверка того, что определенные столбцы всегда уникальны, не являются null или содержат значения из предопределенного набора, помогут Вам очень быстро создать тесты для всех Ваших моделей.
dbt поставляется с 4 общими тестами - not_null, unique, accepted_values и relationship. Помимо встроенных тестов, dbt также позволяет проводить собственные тесты, и этот процесс довольно прост. По сути, все, что Вам нужно сделать, это написать SQL-запрос, который возвращает "неприемлемые" для Вас строки, и это можно превратить в тест.
Мы добавили общие тесты повсюду и очень часто удивлялись тому, сколько проблем, которые могли бы оставаться незамеченными в течение долгого времени, нам с их помощью удалось выявить сразу же.
Документирование
dbt берет все Ваши yml-файлы и превращает их в аккуратную документацию. Кроме того, он даже создает красивые визуальные представления графов зависимостей для Ваших моделей, позволяя легко понять, как именно была построена та или иная модель. Чтобы воспользоваться этой функцией, не нужно делать никаких лишних телодвижений - все необходимое уже есть в самом dbt.
Документация, которая поставляется в комплекте с dbt, гораздо лучше, чем большинство организаций способны создать за всю свою жизнь. И точка.
Минусы
Теперь поговорим о том, что нам НЕ нравится.
Барьер
Для начинающих пользователей dbt существует определенный барьер. Хотя 90 % кодовой базы dbt - это SQL, остальные 10 % требуют серьезного обучения. Даже процесс разбиения кода не так-то прост, как кажется с первого взгляда, и многим может потребоваться время, чтобы разобраться с данной задачей.
Кроме того, если Вы решили не приобретать облачное предложение dbt, Вы должны обладать достаточными знаниями для работы с командными строками, чтобы использовать все возможности инструмента.
Таким образом, внедрение dbt в команде, где люди умеют работать только с SQL, может оказаться непростой задачей. Это важно учитывать при принятии решения о том, подходит ли dbt для Вашей организации или нет.
Простота итераций
Те же "ref", "source" и макросы, которые делают dbt таким полезным, инояхгда могут вызывать определенные сложности при итерации и локальной работе. В SQL Вы можете просто скопировать Ваши CTE или подзапросы и выполнить их в SQL-клиенте, чтобы посмотреть, какой результат они дают. Однако с моделями dbt такой трюк не пройдет, потому что они написаны на jinja2, который компилируется в SQL.
Чтобы решить эту проблему, Вам нужно либо подписаться на облако dbt, либо перебрать множество плагинов и настроек, чтобы заставить Вашу IDE работать как надо. Или же Вы можете компилировать свой код каждый раз, когда вносите изменения, а затем выполнять фрагменты скомпилированного SQL, который по сравнению с моделями dbt читать сложнее. Трудности в процессе итераций могут внести определенную нотку разочарования в процесс разработки, и мы убедились в этом на собственном опыте.
Слишком много шаблонов
Иногда кажется, что для создания простейших вещей с помощью dbt требуется слишком много шаблонов, которые напрямую связаны с накладными расходами.
В дополнение к двум пунктам, упомянутым выше, все эти шаблоны также сильно омрачают процесс разработки в dbt.
Как внедрить dbt, если у Вас уже осуществлено множество преобразований
Итак, Вы внимательно изучили все за и против и решили, что dbt - действительно то, что Вам нужно – примите наши поздравления! Следующая распространенная проблема заключается в определении того, КАК лучше реализовать новый аналитический проект на базе dbt в организации, в которой уже до этого была проведена масса преобразований. В Intercom мы столкнулись с такой же ситуацией, и вот несколько уроков, которые мы извлекли из нашего опыта, и которыми готовы поделиться с Вами
Определите условия успеха
Внедрение dbt – задача довольно сложная, и Вам придется проделать много работы, прежде чем Вы увидите реальные результаты. В определенные моменты времени Вы наверняка будете задаваться вопросом, зачем Вы вообще все это делаете. Как раз это и подводит нас к самому главному - с самого начала очень важно определить условия успеха. Чего именно Вы пытаетесь добиться, внедряя dbt?
- Уменьшить количество ошибок в Ваших моделях?
- Повысить согласованность Ваших продуктов данных?
- Повысить скорость работы Вашей команды разработчиков данных?
- Сократить потери времени на дублирование работы?
- Получить четкое определения используемых метрик?
- Облегчить работу новых сотрудников с Вашей кодовой базой?
Все это веские причины для внедрения dbt - но потратьте время и определите, что именно является ВАШИМ приоритетом.
Land and expand
При внедрении новой системы всегда есть соблазн избавиться от всех существующих моделей и заменить их новой крутой штукой. Такой подход крайне рискован, поскольку Вы еще не знаете, насколько сложным (или легким) окажется процесс преобразований, и понравится ли Вам конечный результат или нет.
Прежде чем бросаться в омут с головой, попробуйте выбрать регулярно используемый отчет, с которым часто возникают проблемы, которые потенциально можно решить с помощью dbt. На основе этого отчета постройте концептуальное дерево фактов и измерений, необходимых для получения желаемого результата, и начните строить эти модели в dbt.
По завершении этого процесса Вы сможете понять, довольны ли Вы своим решением использовать dbt или нет. Если да, то зачастую можно обнаружить дополнительные варианты использования, которые сопряжены с моделями, которые Вы только что построили. Они-то как раз и могут стать подходящими кандидатами для последующих трансформаций.
Разделяйте Ваши схемы
Когда Вы развиваете проект dbt в процессе других преобразований, очень полезно выделить его в новую схему. Это не только дает пользователям данных четкое представление о роли той или иной модели, но и предоставляет Вам возможность дополнительного контроля, поскольку в этом случае Вы сможете использовать различные протоколы безопасности для каждого из этих уровней и даже увидеть, какие модели используются чаще всего.
Мы предлагаем разделить Ваши схемы следующим образом:
- base - материализованные промежуточные модели;
- prep - промежуточные модели, которые не служат окончательной цели и существуют только для того, чтобы помочь Вам создать другие модели;
- core - факты и измерения;
- mart - агрегированные метрические или отчетные таблицы
Однако такое разделение может быть довольно субъективно, и Вы должны понять, что именно лучше всего подходит именно Вам.
Заключение
Прошел год, а мы все еще в процессе переноса нашей огромной кодовой базы аналитики в dbt. За это время мы несколько раз итерировали наш проект, столкнулись с определенными разочарованиями и насладились множеством успехов, основанных на использовании dbt.
Мы искренне надеемся, что данная статья поможет Вам принять взвешенное решение о том, подходит ли Вам dbt или нет!
