Путь данных от CSV до BI-витрины: RAW, STG, CORE, MARTS на примере с Airflow

Представьте, что вы загружаете файл orders.csv с 11 строками и валовой суммой 4720.30, а в итоговом дашборде видите всего 7 строк и выручку 2200.30. Куда делись 4 строки и почему изменилась сумма? Ответ кроется в архитектуре современного хранилища данных: данные проходят через четыре слоя — RAW, STG, CORE и MARTS. Каждый этап выполняет свою функцию: от простого копирования до применения бизнес-правил. В этой статье мы на конкретном примере разберём, как меняются строки и суммы, как обрабатываются ошибки и почему такой подход гарантирует достоверность дашбордов. Внутри — MinIO, Postgres и Airflow.

Как данные проходят через RAW, STG, CORE и MARTS

Архитектура современного DWH часто включает четыре стандартных слоя: RAW (сырые данные), STG (подготовленные), CORE (ядро) и MARTS (витрины). На примере файла orders.csv автор демонстрирует, как на каждом этапе меняется количество записей и суммы. В RAW попадают все 11 строк без изменений — это копия источника. Затем в STG данные проходят первичную валидацию: проверка форматов, обязательных полей, уникальности ключей. Именно здесь отсеиваются четыре строки: например, с некорректным идентификатором заказа или отсутствующей датой. Эти строки не теряются бесследно — они сохраняются в отдельную таблицу rejects с указанием причины отбраковки.

Далее на слое CORE применяются бизнес-правила: пересчёт сумм, фильтрация тестовых заказов, обогащение из справочников. В результате валовая сумма 4720.30 превращается в 2200.30 выручки — часть заказов оказывается возвратами или отменами. На слое MARTS данные агрегируются и готовятся для BI-инструмента. Такой подход позволяет отследить, на каком этапе и почему изменились цифры, а также гарантирует, что дашборд основан на проверенных данных.

Почему строки и суммы меняются на каждом слое?

Изменение количества строк и сумм — нормальный процесс в ETL-пайплайне. На слое RAW данные максимально близки к источнику, но уже здесь могут быть выявлены дубликаты или некорректные форматы. На STG строгая валидация отбрасывает записи, не прошедшие проверки целостности. На CORE бизнес-логика пересчитывает показатели: например, применяются скидки, исключаются налоги или конвертируются валюты. Каждая трансформация должна быть документирована, чтобы аналитик мог объяснить расхождение между исходным файлом и финальной витриной.

Технические детали: MinIO, Postgres и Airflow

В качестве объектного хранилища для RAW-слоя используется MinIO — S3-совместимое решение, куда файлы попадают сразу после выгрузки из источника. Postgres выступает в роли реляционного DWH: таблицы STG, CORE и MARTS развёрнуты в нём. Airflow оркестрирует пайплайн: даг загружает файл из MinIO, парсит его, валидирует, трансформирует и записывает в Postgres. При повторной доставке того же файла Airflow обрабатывает инкрементальные изменения: новые строки добавляются, а уже обработанные игнорируются благодаря хэш-ключам или контрольным суммам. Это позволяет не терять данные при сбоях и не дублировать записи.

Как обрабатываются ошибки при загрузке CSV в DWH?

Ошибки неизбежны при загрузке данных из файлов. Например, в orders.csv могут встретиться строки с неверным форматом даты, пустым полем суммы или дубликатом ключа. На этапе STG каждая такая строка проверяется: если она не проходит валидацию, она записывается в таблицу rejects с кодом ошибки и описанием. Это позволяет не терять данные, а откладывать их для последующего анализа и исправления. В нашем примере четыре строки были отброшены именно из-за ошибок валидации. Такой подход повышает качество данных и доверие к отчётам.

Кого затронет и как

Статья будет полезна Data-инженерам, аналитикам данных и всем, кто строит или поддерживает DWH. Разработчики ETL-процессов узнают, как организовать надёжную обработку файлов с контролем качества. Аналитики поймут, почему цифры в дашбордах могут отличаться от исходных данных, и как интерпретировать rejects. В российском контексте использование MinIO и Postgres актуально для компаний, которые ищут open-source альтернативы западным решениям в условиях импортозамещения.

Что будет дальше

Автор планирует расширить пайплайн: добавить потоковую обработку через Kafka, ввести слой данных для ML-моделей и автоматизировать мониторинг качества данных с помощью dbt. В ближайшей перспективе — публикация шаблонов дагов Airflow для типовых сценариев загрузки CSV. Читателям стоит следить за обновлениями, чтобы внедрить описанные практики в своих проектах.

Итог

Путь от CSV до BI-витрины — это не просто технический процесс, а гарантия доверия к данным. Каждая отброшенная строка и каждая изменённая сумма имеют объяснение. Прозрачная архитектура с RAW, STG, CORE и MARTS позволяет отслеживать трансформации и быстро находить ошибки. Следуя этому подходу, вы сможете строить дашборды, которым можно верить.