Инженерия данных
Пайплайны, превращающие сырые операционные данные в чистые витрины для аналитики.
Сырые данные редко бывают неверными намеренно. Они противоречивы, потому что их создавали системы, решавшие другую задачу, а расплачивается за это тот, кто пытается построить по ним отчёт.
Слои как принцип
Мы строим хранилища слоями: сырой слой в том виде, как данные пришли, и он не редактируется; очищенный слой, где типы и ключи проверяются; и смоделированный слой под те вопросы, которые действительно задают. Каждый слой воспроизводим из предыдущего, поэтому плохая трансформация лечится перезапуском, а не правкой строк.
Где это помогает больше всего
Мы также делаем бэкенды, которые порождают исходные данные, поэтому понимаем, почему колонка nullable и откуда берутся грязные строки. Моделировать проще с той стороны, которая создала беспорядок.
Что сюда входит
- 01
Разработка конвейеров
Загрузка, очистка и трансформация, которые можно безопасно перезапустить, со сбоями, которые видно, а не которые молчат.
- 02
Проектирование хранилищ и lakehouse
Медальонная архитектура на Microsoft Fabric, PostgreSQL или объектном хранилище: выбор по нагрузке, а не по моде.
- 03
Размерное моделирование
Звёздные схемы с определённой гранулярностью и согласованными измерениями, чтобы два отчёта по одной метрике не разошлись.
- 04
Миграция и модернизация
Уход от таблиц Excel, устаревшего хранилища или конвейера, который никто не помнит, со сверкой со старым результатом.
Вопросы
Частые вопросы
Нужно ли нам хранилище или достаточно базы данных?
Часто достаточно грамотно смоделированного PostgreSQL, и сказать это означает для нас проект поменьше. Хранилище оправдывает себя, когда отчётные запросы начинают конкурировать с приложением за одну и ту же базу.
На какой платформе вы строите?
Microsoft Fabric, если компания уже живёт в экосистеме Microsoft; PostgreSQL, если объёмы не оправдывают отдельную платформу. Выбор определяется нагрузкой и командой, которая будет это эксплуатировать.