Экономия HP в облаке на 32% меняет логику выбора SQL ETL-платформы

Каждый руководитель платформы с бюджетным циклом на 2026 год смотрит на одну и ту же строку расходов: контракт на хранилище данных, лицензия на фреймворк трансформации, оркестратор и отдельный стек observability — всё это продлевается в разное время. Цифра HP по serverless, которую активно обсуждают на этой неделе, интересна сама по себе, но главная история в том, как она меняет расчёт «строить или покупать» для SQL ETL в ближайшие два квартала. Команды, подписавшие контракты с тремя вендорами в 2023 году, скоро выяснят, были ли их архитектурные решения стратегическими или просто удобными.

Суть проблемы

SQL ETL в большинстве организаций — это не одна система. Их четыре. Как описал Databricks, типичный стек распределяет выполнение по хранилищу данных, моделирование — по фреймворку трансформации, планирование — по оркестратору, а lineage, мониторинг и контроль качества — по ещё большему числу систем. Каждый слой покупался для решения конкретной задачи. Вместе они создают операционное торможение, которое растёт с каждым новым пайплайном.

Ситуация на рынке найма усугубляет проблему. Аналитический инженер, отлично знающий dbt, — это не тот же человек, что инженер хранилища, пишущий хранимые процедуры, и не тот, что аналитик, строящий no-code трансформации. Каждый фрагментированный стек в итоге требует как минимум одного специалиста на каждый слой плюс платформенную команду для склейки всего вместе. Это от трёх до пяти FTE координационных расходов до того, как будет запущен хоть один пайплайн. Финтех-компании на стадии Series B и операторы iGaming среднего рынка ощущают это особенно остро: они не могут позволить себе команду из 12 человек для дата-платформы, но их регуляторная нагрузка (SOX, MGA, отчётность по MiCA) требует тех же гарантий lineage и качества, что и у публичного банка.

Последствия предсказуемы. Пайплайны ломаются сразу в нескольких системах. Зависимости трудно отследить. Устранение инцидентов превращается в охоту в Slack среди инструментов, не имеющих общего контекста. Фрагментированный SQL ETL — это источник скрытых затрат, хрупких пайплайнов и медленного устранения инцидентов, и это не маркетинговые слова. Это точное описание того, что происходит на 18-м месяце работы с мультивендорным стеком, когда уходит первый старший дата-инженер, унося с собой всё внутреннее знание.

Ограничение, изменившееся за последние 18 месяцев: serverless и декларативное выполнение наконец догнали опыт работы с хранилищами. Аргумент в пользу «просто используйте Snowflake + dbt + Airflow + Monte Carlo» раньше можно было защитить. Это становится всё труднее, когда альтернатива на единой платформе выдаёт результаты в стиле HP.

Доступные варианты

Для CTO, принимающего решение стоимостью от шести до восьми знаков в следующие 90 дней, реалистично существует четыре пути.

Путь первый: остаться фрагментированным, оптимизировать каждый слой. Оставить Snowflake или BigQuery в качестве хранилища, dbt для трансформации, Airflow или Dagster для оркестрации и добавить observability поверх. Здесь уже находится большинство команд на Series B. Преимущество — лучшие инструменты на каждом слое и широкий рынок найма. Цена — интеграционный налог, который невидим в заказе на покупку и очень заметен в дежурном расписании.

Путь второй: консолидация на lakehouse-платформе. Перенести выполнение, оркестрацию, lineage и контроль качества в единую систему. Databricks теперь поддерживает запуск существующих dbt-рабочих процессов прямо на платформе, перенос SQL-запросов в стиле хранилища в скрипты и хранимые процедуры, Materialized Views для ускорения BI, декларативные пайплайны для продакшна и no-code инструменты для аналитиков. Суть предложения в том, что всё это использует один движок выполнения, одну модель управления и один слой observability. Экономия HP в 32% на облаке и сокращение времени выполнения на 36% получены именно этим путём — конкретно его serverless-вариантом.

Путь третий: консолидация на расширенной поверхности вендора хранилища. Snowflake движется в том же направлении со Snowpark, динамическими таблицами и нативной оркестрацией. Компромисс схож по духу, но отличается профилем vendor lock-in. Вы делаете ставку на вендора, чья модель ценообразования привязана к единицам вычислений, а не к node-часам.

Путь четвёртый: DIY на основе open-table format. Iceberg или Delta на объектном хранилище, ClickHouse или Trino для запросов, dbt для моделирования и оркестратор на ваш выбор. Максимальная гибкость, максимальный штат платформенной команды. Реалистично только если у вас восемь и более старших дата-инженеров и сильная культура платформенной разработки.

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

Что на самом деле должны делать дата-команды

Моя точка зрения: если у вас менее 50 специалистов по данным и SQL ETL охватывает более трёх вендоров, следующий цикл продления контрактов — момент для консолидации. Не потому что консолидация добродетельна, а потому что интеграционный налог теперь больше, чем премия за «лучшее в классе» для большинства рабочих нагрузок объёмом до нескольких петабайт.

Вопрос, который ваш CFO должен задать руководителю платформы на этой неделе, — не «стоит ли нам перейти на serverless», а «какой процент наших текущих расходов на дата-инфраструктуру идёт на координационные накладные расходы, а не на вычисления?» Если ответ превышает 30% — а это обычно так, когда считаешь инженерное время на склеивающий код и устранение инцидентов — у вас проблема с юнит-экономикой, замаскированная под архитектурную проблему.

Практически, последовательность миграции, которая работает: начните с самых дорогостоящих и наименее сложных пайплайнов (как правило, BI-агрегации, выигрывающие от Materialized Views), перенесите их первыми, честно измерьте время выполнения и затраты относительно существующего стека, затем расширяйтесь. Не начинайте с запутанного клубка хранимых процедур. Именно там умирают проекты консолидации. Результат HP был получен путём перевода существующих пайплайнов на serverless-вычисления, а не путём создания с нуля — и это реалистичный план действий для большинства команд.

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

Подводные камни и граничные случаи

В проектах консолидации снова и снова всплывают три типа ошибок.

Первый — ловушка персон. Статья правильно выделяет три типа SQL-специалистов: аналитические инженеры, инженеры хранилищ данных и аналитики. Платформа, которая на бумаге поддерживает всех троих, но обеспечивает отличный опыт только для одного, тихо вытолкнет остальных обратно к теневым инструментам. Оценивайте SQL Editor для хранимых процедур, редактор декларативных пайплайнов и Lakeflow Designer с реальными представителями каждой группы. Не позволяйте аналитическим инженерам проводить тестирование в одиночку.

Второй — неожиданные расходы на serverless. Экономика serverless отлична для взрывных нагрузок и может оказаться хуже, чем provisioned compute, для стабильных, предсказуемых задач. Экономия HP в 32% — реальная цифра для рабочей нагрузки HP. Ваша может отличаться. Проведите двухнедельную теневую оценку нагрузки перед принятием решения.

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

И один момент для главного юрисконсульта: автоматически зафиксированный lineage полезен только если он экспортируется в формате, который признают ваши аудиторы. Проверьте путь экспорта, а не только интерфейс.

Ключевые выводы

• Экономия HP в 32% на облаке и сокращение времени выполнения на 36% на serverless меняет разговор о юнит-экономике для любой команды, сегодня работающей с мультивендорным SQL ETL.
• Фрагментация — это проблема найма прежде, чем становится проблемой инструментария. Каждый слой стека добавляет требование к специалисту и координационный налог, растущий с количеством пайплайнов.
• Пути консолидации сходятся. Lakehouse-платформы и нативные расширения хранилищ гонятся к одному и тому же пункту назначения с противоположных направлений, с разными профилями vendor lock-in.
• Последовательность миграции важнее выбора вендора. Начинайте с высокозатратных, малосложных пайплайнов и честно измеряйте результаты, прежде чем браться за клубок хранимых процедур.
• Команды, оценивающие SQL ETL-платформы в 2026 году, должны спрашивать: какой процент наших текущих расходов на данные составляют координационные накладные расходы и что видит наш главный юрисконсульт, когда регулятор запрашивает lineage?