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

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

Уверен, что некоторые из вас, когда начинали изучать метаданные dbt, через какое-то время плевали на все это и просто создавали модели через .sql файлы с указанием необходимых параметров в config-е. Что не является целевым использованием dbt, ведь в документации такая модель, описанная только через .sql файл, не будет корректно отображаться. А еще некоторые метаданные доступны только в .yml файлах.

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

Dbt своих пользователей позиционирует, как analytic engineer – некий симбиоз аналитика, который разбирается в предметной области, и инженера, который разбирается в технологиях. Но я могу сказать точно, что никакой аналитик не сможет разобраться в метаданных dbt. Даже не все data-инженеры смогут.

Поэтому в Datapulse мы решили эту проблему. Есть простенький интерфейс, все параметры моделей указываются там. А дальше Datapulse сам раскладывает метаданные по файликам. Это тот случай, когда я выступаю за GUI-интерфейсы, хотя часто сам же ругался на них. Особенно если дело касалось GUI ETL тулзов и скриптовых ETL.

Как же часто в эту проблемы вляпываются как новички в dbt, так и профессионалы. Потому что очень легко забыть, как отвратительно ведет себя dbt при материализации view или table. То есть обычные материализации, где таблица перестраивается полностью или пересоздается view.

А омерзительность поведения заключается в том, что dbt перед обновлением таблицы или пересозданием view делает drop view|table … cascade. То есть попутно удаляя все зависимые от этой таблицы объекты.

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

Такое поведение dbt починить нельзя. Только если писать собственные материализации.

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

Благо есть различные надстройки (пакеты), разработанные сторонними компаниями, но их еще нужно установить, в них разобраться и настроить под себя, что несомненно займет у вас приличное количество времени.

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

А это проблема совсем коварная, потому что говорят о ней мало и в документации нигде не написано о подобном поведении.

Сделали вы таблицу. Таблица со временем разрослась и стала большой и страшной. И тут значение в одном столбце из источника приходит не varchar(50), а varchar(10). И dbt автоматически, не уведомляя никого, начинает alter table, перед этим делая бэкап таблицы. И на больших и страшных объемах у вас ETL и встает, причем наглухо.

И сперва вы совсем не понимаете, почему он так долго крутится. А потом усердно ищете в логах, что же такое случилось, что обычный select * работал 4 часа.

Поэтому мой совет всем – всегда явно в SQL (не в .yml!) явно указывайте типы данных столбцов (через cast). Лучше получить ошибку за несколько миллисекунд, чем ждать пару часов, гадая о причинах.

Очень недостает dbt функционала по сбору данных из различных источников. Да, сам dbt позиционирует себя лишь как инструмент трансформации данных (T в аббревиатуре ETL). То есть нам изначально говорят, что на большее не рассчитывайте. Используйте другие инструменты, такие как Airbyte.

Но так не хочется плодить зоопарк платформ и инструментов. И голубая мечта – дать возможность аналитикам выгружать данные. В общем, dbt подобного функционала очень не хватает.

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

Одним из базовых макросов в dbt – это ref, при котором вы явно указываете зависимость одной модели от другой, а также на основе этого будет строиться граф и data lineage. Весьма удобная штуковина, за одним малым исключением. Исключением из разряда «хотели как лучше, получилось как всегда».

Разработчики dbt логично предположили, что если одна модель не отработала и упала с ошибкой, то зачем тратить ресурсы на запуск модели, которая зависит от первой. Тем самым, запуская с помощью dbt run две модели, где одна зависит от другой через ref, и первая модель падает, вторая (зависимая) будет пропущена и не запустится.

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

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

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

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

Да и сама jinja является весьма специфичным языком, который точно нельзя назвать удобным. Больно на нем писать и больно отлаживать.

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

Наш менеджер свяжется с вами для предоставления бесплатного доступа и презентует наш сервис