Озеро данных и хранилище данных решают разные задачи, но их постоянно путают и пытаются заменить одно другим. В итоге компания либо сваливает сырые логи в дорогое реляционное хранилище, либо строит «озеро», в котором аналитик не может найти ни одной достоверной цифры. Разберём, чем эти подходы отличаются по существу и под какие задачи их выбирать.

Хранилище: дисциплина и доверие к цифрам

Корпоративное хранилище данных (DWH) – это структурированный слой, куда данные попадают по схеме, заданной заранее. Вы описываете модель, настраиваете ETL, и каждая запись приходит очищенной и согласованной. Отсюда главное свойство DWH: цифрам можно доверять. Финансовая отчётность, регуляторные выгрузки, регламентные витрины для руководства – всё это живёт в хранилище, потому что здесь жёсткая схема и предсказуемое качество.

Платой за дисциплину становится негибкость. Любое новое поле требует переделки модели и ETL. Хранение структурированных данных в реляционных СУБД обходится дорого, поэтому складывать туда веб-логи, телеметрию датчиков или переписку из чат-ботов экономически бессмысленно. DWH отвечает на вопросы, которые вы сформулировали заранее, и плохо подходит для исследовательской работы.

Озеро: сырьё для аналитики и ИИ

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

Именно детализация делает озеро фундаментом ИИ-проектов. Модели учатся на сырых событиях, а не на агрегатах из витрин. Если вы заранее усреднили данные под отчёт, обучать на них модель уже поздно. Поэтому команды data science работают с озером, а бизнес-пользователи – с хранилищем.

Риск тоже известен: без каталога, метаданных и контроля доступа озеро превращается в «болото данных», куда никто не заглядывает. Дисциплина управления здесь не отменяется, а смещается – от схемы записи к каталогизации и происхождению данных.

Как выбирать и как соблюсти закон

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

Отдельно – регуляторный контур. Персональные данные в озере подпадают под 152-ФЗ ровно так же, как в любой другой системе, а после июльских поправок и эффекта GDPR требования к локализации и согласиям ужесточились. Сырьё в озере особенно легко собрать «про запас» без правовых оснований – это прямой риск. Закладывайте разметку персональных данных и политики удаления на этапе проектирования, а не после запуска. Для госсектора это тем более актуально на фоне программы «Цифровая экономика», где аналитика на больших данных становится требованием, а не опцией.

Вывод

Озеро и хранилище – не конкуренты, а два слоя одной архитектуры данных. Озеро даёт глубину и гибкость для ИИ, хранилище – доверие к цифрам для бизнеса и регулятора. Если вы проектируете платформу под аналитику и машинное обучение, начните с разделения этих ролей, а затем свяжите их в единый контур данных и BI.