«Фарш невозможно прокрутить назад» — этой поговоркой инженеры данных могли бы объяснить, как работает классический ETL. Ошибка может случиться на любом этапе: не тот коэффициент применили, не ту валюту подставили, забыли про скидку. Но после того как исходные данные трансформированы и отчет сформирован, но иногда бывают такие ситуации, когда вернуться к первоисточнику по какой-то причину уже нельзя.
В FinOps эта ситуация — не метафора, а суровая реальность. Данные от облачных провайдеров доступны лишь в ограниченном окне (30–90 дней), а иногда и меньше. Если вы сначала обработали их, а потом поняли, что ошиблись, может так случиться, что перезапросить исходники уже не получится.
В этой статье мы разберем два подхода к построению процессов обработки и преобразования данных — ETL и ELT — и докажем, почему для FinOps выбор ELT — это не просто вопрос производительности, а вопрос выживания исторических данных.
ETL vs ELT: два подхода к обработке данных
Классический ETL (Extract → Transform → Load):
1. Извлекаем данные из источника.
2. Трансформируем (чистим, обогащаем, агрегируем).
3. Загружаем результат в хранилище.
Плюсом этого подхода является то, что в хранилище лежит только «чистый» продукт, что экономит место. Однако есть и огромный минус – исходники просто не сохраняются в системе, и если информация была обработана некачественно переделать все заново будет иногда сложно — надо по новой извлекать данные из источника.
Альтернативный ELT (Extract → Load → Transform):
1. Извлекаем данные.
2. Сразу загружаем «как есть» в «сырое»/промежуточное хранилище.
3. Только потом, асинхронно, трансформируем.
4. Загружаем результат в постоянное хранилище.
Иными словами в ELT мы сначала сохраняем все, что пришло, в первозданном виде. А уже потом, в спокойном режиме, применяем любые трансформации. И если что-то пошло не так — всегда можно вернуться к изначальным вводным и обработать их заново.
Почему для FinOps ELT — это не «лучше», а «единственно возможно»?
Биллинговые API большинства провайдеров имеют глубину хранения — 30, 60, реже 90 дней, а метрики из мониторинга могут быть доступны и на более короткие сроки, и если окно загрузки пропущено данные теряются навсегда.
Пример из практики: Вы настроили ETL-процесс, он отработал, загрузил все необходимые данные. Через месяц вы поняли, что неправильно обрабатывали стоимость — не учли региональные коэффициенты. А исходный файл с детализацией за тот месяц уже не получить. Отчетность за этот период навсегда останется неверной.
Именно поэтому в архитектуру Клаудмастер мы изначально заложили принцип ELT. Платформа сначала сохраняет «сырые» биллинги провайдеров в неизменном виде, и только потом применяет к ним движок трансформаций. Это дает нашим клиентам «право на ошибку»: если через полгода вам понадобится пересчитать исторические затраты, то Клаудмастер сделает это, обратившись к сохраненным первоисточникам
Поэтому при работе с внешними системами, которые не умеют хранить свою историю бесконечно, ELT — это единственная стратегия, которая сохраняет возможность пересчета и исправления ошибок.
Шаги трансформации: что мы делаем с данными после загрузки
Сохранить сырые данные — это только полдела. Главное — уметь превратить их в структурированную, непротиворечивую и удобную для анализа информацию. Для этого мы используем десять шагов работы с данными, каждый из которых решает свою задачу.
1. Фильтрация. Убираем все, что нам не нужно: служебные записи, тестовые аккаунты, данные, выходящие за пределы интересующего периода.
2. Дедупликация. Удаляем дубли. Например если один и тот же файл загрузился дважды по технической ошибке или биллинговая система сгенерировала две одинаковые записи.
3. Очистка от мусора. Что считать мусором — определяем сами. Это могут быть строки с нулевыми суммами, записи без идентификаторов, данные из неподдерживаемых регионов.
4. Преобразование типов. Например на входе пришла строка «03-02-2026», а мы ожидаем тип YYYY-MM-DD. На этом этапе приводим все к единому формату.
5. Унификация. Приводим данные к единому корпоративному стандарту. Например, телефоны: +7 (495) 123-45-67 → +74951234567 или email: User@Company.RU → user@company.ru.
6. Исправление опечаток и неточностей. Город «Москва» может прийти как «Москва», «Moscow», «г. Москва». Нужны правила, которые приведут все к единому значению.
7. Обогащение. Добавляем информацию, которой не было в исходных данных. Например, у нас есть идентификатор клиента, а мы добавляем его полное название из справочника НСИ. Или добавляем пометку «критичный клиент» на основе правил.
8. Сопоставление (маппинг). Связываем информацию из разных систем. Например, в биллинговом файле указан идентификатор виртуальной машины, а нам нужно добавить название проекта, к которому она относится. Для этого нужна таблица соответствий.
9. Агрегация. Собираем детальные данные в более крупные блоки. Например, поминутные показания нагрузки агрегируем до часовых или суточных. Это уменьшает объем данных и ускоряет формирование отчетов.
10. Нормализация/денормализация. В зависимости от того, какую схему хранения мы выбрали, мы либо разносим данные по разным таблицам в 3NF, либо используем схему «Звезда», либо, наоборот, собираем все в одну широкую денормализованную таблицу.
Правила трансформации: как не превратить ELT в хаос
При большом количестве данных и их трансформаций возникает риск, что ELT системы просто невозможно будет поддерживать. Для решения этой проблемы согласовываются и документируются правила трансформации (Transform Rules и любое преобразование должно четко следовать этим правилам.
Что должно быть описано в Transform Rules:
— Источник и цель: откуда берем данные, в какую таблицу/слой кладем результат
— Схема отображения: какой атрибут источника в какой атрибут цели идет
— Логика преобразования: как из исходного значения получить целевое
— Типы данных: что ожидаем на входе, что получаем на выходе
Возможные форматы документирования:
— Таблицы отображения (Source-to-Target mapping): простое соответствие колонок
— Словари данных: описание каждой сущности в целевой системе с примерами
— ER-диаграммы: визуализация связей между сущностями
— Диаграммы потоков данных (Data Flow Diagrams): как данные движутся между слоями
Важно отметить: даже если вы не делаете идеальную документацию с первого дня, фиксируйте правила хотя бы в комментариях в коде или в Confluence. Потому что через три месяца никто, включая вас, не вспомнит, почему стоимость считалась именно так.
Почему для FinOps мы выбираем пакетную загрузку?
Данные обычно могут быть загружены двумя способами:
-
потоковой загрузкой (streaming): записи приходят по одной, непрерывно
-
пакетной загрузкой (batch): данные собираются в пакет и загружаются по расписанию (раз в час, раз в день…)
FinOps — это про управление расходами, а не про реакцию на каждое изменение инфраструктуры, здесь главное не скорость поступления, а надежность и возможность пересчитать. Поэтому и подход к загрузке данных должен быть соответствующим: размеренным, предсказуемым и удобным для перезапуска. Именно таким критериям отвечает пакетная загрузка.
1. Асинхронность: нет необходимости реагировать на каждое событие в реальном времени. Отчеты строятся раз в день, реже — раз в час.
2. Простота: пакетные процессы легче разрабатывать, тестировать и отлаживать.
3. Перезапускаемость: при ошибке легко перезапустить загрузку конкретного пакета, при потоковой загрузке процесс сильно усложняется.
4. Совместимость: API облачных провайдеров сами отдают данные порциями, а не потоком.
Конечно это не означает, что стриминг — зло. Для некоторых типов данных (например, алерты) он незаменим. Но для финансовых данных и метрик, которые ложатся в аналитическую систему, пакетная загрузка — это стандарт.
Заключение: ELT — это не про скорость, это про безопасность истории
В мире, где данные от внешних поставщиков имеют ограниченный срок хранения, классический ETL становится опасным. Вы рискуете потерять возможность исправить ошибки и пересчитать метрики. Выбор ELT — это стратегическое решение, которое обеспечивает:
Безопасность: исходные данные всегда доступны для пересчета.
Гибкость: можно менять логику трансформации, не перегружая внешние системы.
Аудит: всегда можно посмотреть, что пришло «как есть», и сравнить с результатом.
ссылка на оригинал статьи https://habr.com/ru/articles/1025790/