Слой трансформаций — то место, где сырые данные превращаются в таблицы, которыми пользуются. Последние годы он был устроен одинаково: оркестратор запускает шаги, каждый шаг выполняет запрос в складе данных, склад считает. Сейчас всё чаще встречается другая схема: движок работает прямо в процессе, а данные лежат файлами.
Разберём, что именно поменялось, где новая схема выигрывает и где ломается.
Как устроен конвейер
В привычной схеме есть три отдельные вещи. Хранилище, которое умеет считать. Описание преобразований — как правило, набор запросов с зависимостями между ними. И оркестратор, который решает, что за чем запускать, следит за расписанием и повторяет упавшее.
Вычисление происходит там, где лежат данные: инструмент трансформаций сам ничего не считает, он отправляет запросы и ждёт. Отсюда и главное свойство схемы — она масштабируется настолько, насколько масштабируется хранилище, и стоит настолько, насколько стоит хранилище.
Разработка в такой схеме имеет характерную особенность: чтобы проверить одну строчку, нужно хранилище. Локально не запускается ничего, и цикл правки упирается в очередь запросов и в чужие ресурсы.
Тупик: ускорять конвейер настройками
Первое, что пробуют, когда конвейер становится медленным и дорогим, — крутить его изнутри: материализовать промежуточные таблицы, дробить шаги, переносить расписание на ночь, добавлять инкрементальность.
Это помогает ровно один раз и не трогает причину. Причина в том, что каждый шаг — это круг через сеть до хранилища и обратно, а разработка идёт со скоростью этих кругов. Инкрементальность уменьшает объём работы, но не убирает круг; ночное расписание прячет проблему от глаз, но делает цикл правки суточным.
Второй частый ход — вынести часть работы в отдельный кластер обработки. Это меняет одну инфраструктуру на другую, обычно более сложную, и вопрос локальной разработки не решает вовсе.
Стоит назвать и то, что в этой схеме работает хорошо, — иначе разбор выйдет однобоким. Зависимости между шагами описаны явно, поэтому граф пересчёта строится сам. История запусков сохраняется. Права и учёт стоимости уже есть в хранилище. И, что важнее всего для больших организаций, аналитик может писать преобразования, не имея дела ни с одним из инженерных инструментов.
Что предлагает движок в процессе
Альтернатива устроена принципиально иначе. Данные лежат файлами в объектном хранилище в открытом формате. Движок — это библиотека, которая запускается внутри вашего процесса, читает эти файлы напрямую и считает на той же машине, где идёт вычисление.
Отсюда три следствия.
Локальный цикл становится секундным. Тот же самый код — те же самые запросы — выполняется на ноутбуке над подмножеством данных, без очереди и без чужих ресурсов.
Исчезает отдельный слой оркестрации для мелких задач. Трансформация становится обычной программой: её можно вызвать из кода, из теста, из задачи по расписанию — тем же способом, каким вызывается остальной код.
Стоимость перестаёт быть привязанной к хранилищу. Вы платите за машину, которая считает, и за хранение файлов, а не за вычисления в складе по его тарифу.
Где эта схема ломается
Она ломается не там, где ожидают.
На объёме, который не влезает в память одной машины. Движки в процессе умеют работать с данными больше памяти, но с оговорками, и на определённом размере честнее вернуться к хранилищу, чем героически оптимизировать.
На одновременном доступе. Файлы в объектном хранилище не дают транзакций сами по себе. Как только писателей больше одного или читатели видят таблицу в момент перезаписи, нужен слой табличного формата — и вместе с ним возвращается часть сложности, ради ухода от которой всё затевалось.
На правах. В складе данных права выданы на таблицы и колонки. В схеме с файлами права выданы на объекты в хранилище, а колоночные ограничения нужно реализовывать самим — обычно отдельными наборами файлов, что размножает данные.
На людях, которые не программисты. Аналитик, привыкший к запросам в складе, получает вместо привычной консоли программу, которую нужно запускать. Это не техническая проблема, но она решает судьбу внедрения чаще технических.
На наблюдаемости. У склада есть история запросов, стоимость каждого и понятные журналы. У программы на своей машине этого нет, пока вы это не сделали.
Как это выглядит на практике
Переход редко бывает полным, и это нормальное состояние, а не промежуточное.
Типичная работающая конфигурация выглядит так: тяжёлые пересчёты на всей истории остаются в хранилище, а витрины, которые правят каждую неделю, считаются движком в процессе над теми же файлами. Общее у обеих половин — формат данных: пока таблицы лежат в открытом виде, обе стороны читают одно и то же, и переносить шаги между ними можно по одному.
Что стоит сделать до переноса первого шага. Зафиксировать, где лежат исходные данные и в каком формате, — если ответ «в складе, во внутреннем формате», то начинать надо не с движка, а с выгрузки. Договориться, кто пишет в таблицы: пока писатель один, табличный формат можно отложить, а как только появляется второй, откладывать нельзя. И завести проверку результатов, которая сравнивает старый и новый расчёт на одном периоде, — без неё перенос превращается в веру.
Чего делать не стоит — переносить всё сразу ради единообразия. Смешанная схема выглядит некрасиво на диаграмме, но обходится дешевле, чем полный переезд, и позволяет остановиться в любой момент.
Как выбирать
Практический признак: движок в процессе выигрывает там, где цикл разработки важнее объёма, и проигрывает там, где объём важнее цикла.
Витрины, которые считаются из десятков таблиц и постоянно правятся, — это про цикл. Ночной пересчёт всей истории — про объём.
Второй признак — кто владеет данными. Если данные уже лежат файлами и склад используется как вычислитель, переход снимает лишний слой. Если данные живут в складе и наружу не выходят, переход означает переезд данных, а это отдельный проект.
Третий — состав команды. Схема с движком в процессе требует инженерных привычек: репозиторий, тесты, окружения. Там, где трансформации пишут аналитики, склад с его консолью остаётся честнее.
Позиция редакции
Мы считаем, что смещение идёт не от одного инструмента к другому, а от управления вычислением снаружи к вычислению внутри процесса — и что главная выгода здесь не в стоимости, а в возвращении секундного цикла правки, который в конвейерной схеме потерян.
Практический вывод: попробуйте перенести на движок в процессе те трансформации, которые чаще всего переписывают, и оставьте в складе те, которые считаются редко и на всей истории.
Мы неправы, если ваши данные не выходят из склада и не должны: тогда переход означает вынести их наружу, завести табличный формат, права и наблюдаемость заново — и цена этого перевесит любой выигрыш в цикле разработки.