Объём данных у наших заказчиков растёт быстрее, чем планы по их обработке. Транзакции из ERP, логи порталов госуслуг, выгрузки из биллинга, машинные данные с датчиков – всё это нужно хранить и анализировать. Возникает развилка: складывать данные в классическое хранилище (Data Warehouse, DWH) или строить data lake на Hadoop. Это не вопрос моды. Это вопрос того, где вы платите за порядок – на входе или на выходе.

Хранилище данных: порядок на входе

DWH работает по принципу schema-on-write. Прежде чем строка попадёт в хранилище, вы описываете её структуру, проводите ETL, чистите и согласуете справочники. На выходе аналитик получает доверенные витрины: продажи по регионам, исполнение бюджета, динамика обращений. SQL-инструменты и BI-отчёты работают поверх этого без сюрпризов.

Цена такого порядка – жёсткость и стоимость. Каждый новый источник требует доработки ETL-процедур, а массивно-параллельные СУБД вроде Teradata, Oracle Exadata или Microsoft PDW стоят дорого в пересчёте на терабайт. Для регламентной отчётности, особенно в госсекторе, где цифры идут в надзорные органы, эта строгость оправдана. Когда мы готовили аналитику по нагрузке для защищённого портала на выборах, именно предсказуемость витрин позволила отдавать проверяемые цифры в срок.

Data Lake: порядок на выходе

Подход data lake переворачивает логику – schema-on-read. Вы складываете данные в HDFS как есть: логи, JSON, выгрузки, бинарные файлы. Структуру задаёте в момент чтения, через MapReduce или Hive. Хранение на стандартных серверах дешевле в разы, а добавить новый источник – значит просто положить файлы в каталог.

Плата за гибкость приходит позже. Без дисциплины каталогизации озеро данных превращается в свалку, где никто не помнит, что лежит в папке за прошлый квартал. Hadoop не даёт транзакций и быстрых точечных запросов, а инструменты вроде Hive пока заметно медленнее зрелых СУБД. Для разведочного анализа больших и сырых массивов это приемлемо, для оперативной отчётности – нет.

Как выбирать

Мы не противопоставляем подходы, а раскладываем нагрузку по слоям. Сырые и слабоструктурированные данные – логи аутентификации в УЭК и входе на госуслуги, потоки с устройств – садятся в data lake, где дёшево хранить и удобно прогонять тяжёлые расчёты. Очищенные и согласованные показатели поднимаются в DWH, откуда их забирают BI и регламентные отчёты. Hadoop при этом часто работает как разгрузочная площадка для ETL: тяжёлую трансформацию выполняет кластер, а в хранилище попадает уже готовый результат.

Выбор диктуют три вопроса. Нужны ли проверяемые цифры для надзора и руководства – тогда без витрин DWH не обойтись. Растёт ли объём слабоструктурированных данных быстрее, чем бюджет на лицензии СУБД – тогда озеро снимает нагрузку и стоимость. Готова ли команда поддерживать каталог и качество данных – без этого озеро не взлетит ни при каком бюджете. Как мы отмечали в прогнозе на 2013 год, спрос на обработку больших данных в России только разгоняется, и закладывать архитектуру стоит с запасом.

Вывод

DWH и data lake решают разные задачи и хорошо живут вместе. Хранилище отвечает за доверенную отчётность, озеро – за дешёвое хранение и тяжёлые расчёты на сырых данных. Проектировать эту связку лучше до того, как данные станут неуправляемыми. Слои хранения и аналитики разумно проектировать под конкретные источники и регламенты, а не подгонять источники под готовую схему.