Вопрос «озеро или хранилище» звучит на каждом втором проекте, но сформулирован неверно. Это не выбор между двумя продуктами, а выбор модели работы с данными. Хранилище отвечает на заранее известные вопросы быстро и предсказуемо. Озеро хранит всё подряд, чтобы вопросы можно было задать потом. Зрелый аналитический контур опирается на оба слоя – важно не перепутать их роли.

Где проходит граница

Data Warehouse (DWH) – это структурированное хранилище под регламентную отчётность. Данные приходят из учётных систем, проходят ETL, ложатся в выверенную схему. Здесь живут финансовая отчётность, KPI, регуляторные формы для ЦБ и ведомств. Схема задаётся до загрузки (schema-on-write), поэтому запросы стабильны, а цифры в двух отчётах сходятся. Цена этой строгости – медленные изменения: новый источник требует переработки модели.

Data Lake хранит сырые данные в исходном виде: логи, телеметрию, выгрузки, документы, потоки с датчиков. Структуру вы накладываете в момент чтения (schema-on-read). Это даёт гибкость для исследовательской аналитики и машинного обучения, но без дисциплины озеро превращается в «болото» – свалку файлов, где никто не знает происхождения и качества данных.

Практический критерий простой. Если вопрос известен и повторяется – это DWH. Если вы пока не знаете, что будете искать, и не хотите терять данные – это Lake.

Как собрать связку

В реальных проектах слои не конкурируют, а дополняют друг друга. Рабочая схема такая: сырьё садится в озеро, оттуда очищенные и согласованные витрины переносятся в хранилище, а BI-инструменты и регламентная отчётность смотрят уже в DWH. Data scientists при этом работают напрямую с озером, не нагружая продуктивный контур отчётности.

Три вещи определяют, взлетит ли архитектура:

  • Каталог и метаданные. Без описания источников, владельцев и качества данных озеро мертво. Каталог – первое, что закладывают, а не последнее.
  • Управление доступом. В госсекторе и финансах действуют требования по защите персональных данных (152-ФЗ) и сегментации доступа. Сырой слой содержит самое чувствительное – права раздаются на уровне таблиц и колонок, а импортозамещение СУБД учитывается на этапе выбора платформы.
  • Резервирование. Аналитический контур – такой же production, как и учётные системы. Продумайте резервное копирование и план восстановления для обоих слоёв. Недавняя атака шифровальщика на Colonial Pipeline напомнила, что без рабочих бэкапов любая архитектура хрупка.

С чего начать

Не начинайте с покупки платформы. Начните с инвентаризации источников и вопросов, на которые бизнес хочет отвечать. Опишите 5–10 ключевых сценариев и станет видно, что из них требует строгой схемы, а что исследовательской свободы.

Витрины и пайплайны не обязательно писать кодом с нуля: часть трансформаций и сборки отчётов закрывается визуальными инструментами, как мы разбирали в материале про платформы low-code. Это ускоряет первые результаты и снижает зависимость от узкого круга разработчиков.

Дальше – итерации. Сначала озеро под пару приоритетных источников, затем первые витрины в хранилище, затем BI поверх них. Большой «биг-банг» с одновременным запуском всего слоя почти всегда буксует на интеграции и качестве данных.

Вывод

Data Lake и Data Warehouse решают разные задачи и в зрелом контуре работают вместе: озеро принимает и хранит всё, хранилище отдаёт выверенные цифры. Спор «или-или» уводит от главного – управления метаданными, доступом и качеством. Дальше архитектуру стоит проектировать под конкретные источники и регуляторные требования, выстраивая аналитический контур и BI поверх связки озера и хранилища.