О чем эта статья: В данной статье я хочу сравнить TCO старых добрых ETL как например Informatica, ODI, MarkitEDM и подобных им vs DBT + AirFlow и подобных им
Очень легко проанализировать стоимость лицензий или вычислений и хранения в случае облачной БД, но очень сложно — TCO. Стоимость разработки одной фичи, стоимость поддержки, стоимость сопровождения, стоимость изменений. Очень заманчиво учитывать только расходы на лицензии и вычисления и предполагать, что все остальные расходы одинаковы, хотя это не так.
По умолчанию облачные MPP-базы обычно дешевле по хранению и вычислениям и не имеют лицензионной платы, и возникает соблазн использовать такой же безлицензионный подход в ETL, но есть недостатки:
Например, если у вас микросервисы, то их сложно отлаживать, потому что все логи и скрипты исчезают.
Если у вас есть графический инструмент, то гораздо проще ориентироваться, видеть весь пайплайн целиком и отлаживать его. Это крупнейшая утечка времени и, как следствие, денег. Это увеличивает время онбординга новых разработчиков и сильно усложняет понимание системы с десятками тысяч моделей и таблиц.
Если у вас микросервисы и нужно выполнить небольшой SQL-запрос, тонакладные расходы на запуск и инициализацию микросервиса могут достигать и 99%, а файл 100Кб может грузиться 30 минут.
Если вы используете Python, Java или другие не-SQL языки, у вас появляются большие трассировки ошибок, которые сваливаются в одну большую кучу, где иногда трудно найти конкретную ошибку по сравнению с простыми SQL-ошибками.
В облачных MPP обычно нет проверок PK и FK, их нужно реализовывать вручную, что требует времени и увеличивает TCO.
Если вы используете связку Python, Java и API внутри БД вместо более широкого использования SQL, вы пишете гораздо больше кода, что приводит к увеличению времени работы с Git и слияниями, code review и утверждениями.
Больше времени уходит на сборку образов, Docker, контейнеры и Kubernetes. Можно возразить, что при использовании графического ETL-инструмента или более «олдскульного» подхода нужно делать то же самое. На самом деле — значительно меньше, потому что задачи БД очень стандартны: извлечь данные, очистить, трансформировать и загрузить или поместить в Data Mart.
Вытекает из предыдущего принцип Low-code, который уже давно применяется в олдскульных ETL, и код генерируется из вашего дизайна, а не пишется вручную в большом объёме. Графический ETL позволяет писать в 10–20 раз меньше кода и удерживает вас в рамках лучших практик индустрии ETL с, скажем, 50-летним опытом. В то время как программирование пайплайнов данных на Python можно реализовать множеством разных способов.
Если вы используете графический ETL, у вас есть история запусков, логи и скрипты в одном месте, чего нет в микросервисах.
Если вы используете графический ETL, у вас, вероятно, есть встроенный или более простой data lineage для бизнес-данных.
Есть плюсы у DBT + AirFlow:
Нативная шаблонизация. Макросы и код генерирующий другой код можно написать где угодно, но все же у DBT это родная фича
Лучшая совместимость с ИИ и Агентами. Агенты можно натравить и на Informatica, но когда все в коде, всё в Git не нужно дополнительно объяснять агенту что такое Informatica и как с ней работать
Вывод: Бесплатные ETL-инструменты или only-code, такие как DBT Core, на начальном этапе стоят дешевле по сравнению с дорогими графическими ETL-инструментами, но позже стоимость сопровождения, проблемы с производительностью, отладка и размер команды могут нивелировать или даже легко превысить TCO.
TCO также различается для классических СУБД, таких как Oracle и SQL Server. Из-за блокирующей природы SQL Server иногда приходится покупать значительно более мощное оборудование и тратить больше времени на избегание блокировок, чем в более простой архитектуре Oracle.
Мой личный итоговый вывод: хотя облачные MPP — это действительно шаг вперёд для аналитический БД. Использование неграфического ETL имеет серьёзные недостатки и будет выигрышно только в небольших или в статических проектах. В крупных сложных проектах TCO dbt вероятней всего будет выше и в итоге увеличивает, а не снижает затраты.
P.S.
Есть один крупный фактор, который меняет и может сильно изменить рынок — AI.
Есть большие ожидания, что AI сможет работать с крупными репозиториями и даже писать самогенерируемый ETL. Мы пока до этого не дошли и, возможно, не дойдём в среднесрочной перспективе.
Это серьёзный вызов для обоих подходов: современного подхода DBT и классических графических ETL-инструментов.
Классическим графическим ETL-инструментам придётся «раскрыть внутренности», чтобы позволить AI работать с ними.
DBT и другие бесплатные инструменты находятся под угрозой, потому что добавляют дополнительный уровень абстракции, который нужен людям для организации SQL- и Java-скриптов обработки данных. Абстракция создаёт накладные расходы, а AI в ней не нуждается. Это означает, что у AI не будет этих накладных расходов, и он будет быстрее — иногда значительно быстрее, но тогда никто кроме AI не сможет в этом разобраться.
