Привет! Я Максим Еремин, больше восьми лет занимаюсь облачными сервисами и работаю в Cloud.ru — отвечаю за Evolution Managed ArenadataDB.

Сегодня хочу поговорить вот о чем. У корпоративных хранилищ есть одна особенность: чем дольше они живут, тем больше задач на них пытаются навесить.

Сначала туда попадают предсказуемые вещи: CRM, ERP и внутренняя отчетность. Но потом добавляются документы, записи разговоров, данные для ML, генеративный ИИ и еще десяток сценариев, о которых никто не думал, когда проектировал DWH 10 лет назад.

И в какой-то из четвергов становится понятно, что проблема не в самом хранилище (оно-то по-прежнему работает), а в том, что бизнес уже давно ушел вперед.

При этом просто взять и заменить DWH на что-то махом не вариант. За годы вокруг него успевают вырасти витрины, ETL-процессы, отчеты и десятки интеграций. Чем дольше живет корпоративное хранилище, тем страшнее в него вмешиваться.

Поэтому команда пытается ответить сразу на два вопроса: на что переехать и что оставить в DWH?

Ответ у них общий: гибридная архитектура, где корпоративное хранилище продолжает выполнять свои задачи, а часть данных и нагрузок постепенно переезжает в Data Lakehouse.

Как ее выстроить? Вот про это и расскажу.

Почему DWH становится мало

Первая причина: появляются данные, для которых DWH не проектировалось.

Классическое DWH изначально создавалось для работы со структурированными данными. Пока речь идет о таблицах из CRM, ERP, бухгалтерских и других внутренних систем, оно чувствует себя вполне комфортно.

Но потом бизнес приходит с очередной идеей. Например, начинает хранить записи разговоров кол-центра, работать с PDF-документами, изображениями или строить RAG-системы.

Да, все это можно положить в DWH. Вопрос только в том, зачем.

И чем больше таких сценариев появляется, тем сильнее становится ощущение, что корпоративное хранилище постепенно превращается в склад всего подряд.

Но есть и вторая причина: не все данные должны храниться одинаково.

А под капотом у этой причины — деньги.

Не все данные нужны бизнесу каждый день. По одним постоянно строятся отчеты, работают витрины и выполняются запросы. Другие могут месяцами лежать без движения и работать точечно: для проверки гипотезы, обучения модели или какого-нибудь разового исследования.

Проблема в том, что в классическом DWH все эти данные продолжают жить вместе. И чем больше их становится, тем больше вычислительных ресурсов приходится держать рядом с ними.

Ну и зачем тогда платить за вычисления, если большая часть этих данных почти никогда не используется?

Что тогда делать

Полностью отказываться от DWH и переносить данные в новое хранилище необязательно.

Обычно компании идут другим путем — оставляют в корпоративном хранилище то, что оно умеет делать лучше всего, а остальные данные постепенно выносят в Data Lakehouse.

Дальше остается только разобраться, что куда отправлять. На мой взгляд, если данные нужны бизнесу каждый день, им место в корпоративном хранилище.

Именно для таких задач DWH и создавалось. Оно хорошо справляется с высокой нагрузкой и быстрым откликом, поэтому здесь вполне ожидаемо увидеть аналитические СУБД вроде ClickHouse или Greenplum.

С Data Lakehouse история ровно противоположная.

Хороший пример — риск-менеджмент. Допустим, нужно посмотреть, что будет с портфелем активов после изменения ключевой ставки. Для этого нужны большие исторические выборки. Но такие расчеты не крутятся постоянно. Их запускают тогда, когда появляется конкретный вопрос.

И вот здесь становится ясно, зачем вообще разделять хранение и вычисления, потому что держать такие данные в DWH вместе с вычислительными ресурсами просто дорого.

Гораздо проще хранить их в объектном хранилище и подключать вычисления только тогда, когда они действительно нужны.

Например, аналитик решил проверить новую гипотезу, провести исследование или обучить модель. Для этого достаточно запустить Spark или обратиться к данным через Trino. Закончили работу — вычисления остановили, а данные остались лежать в объектном хранилище до следующего запроса.

Почему у миграции нет универсального сценария

На этом месте обычно хочется найти какой-нибудь понятный план действий: перенести данные, переключить нагрузку и закрыть проект.

К сожалению, так почти никогда не бывает. И я тоже не принес готовый пайплайн.

Даже если две компании используют одинаковый стек технологий, сами проекты могут различаться кардинально. Где-то вокруг DWH уже построены десятки витрин и интеграций, где-то хранилище только начинает развиваться. У кого-то основные данные лежат в одной системе, у кого-то распределены между несколькими источниками.

Поэтому миграция в Data Lakehouse всегда начинается с разных вводных.

Но есть и хорошая новость: несмотря на это, почти любой такой проект проходит через три этапа. Сейчас расскажу подробнее.

Этап 1. Разбираемся с данными

Самая частая ошибка — сразу бросаться переносить данные.

На практике миграция начинается с другого вопроса: а что именно мы собираемся переносить?

Если в существующем DWH уже есть дубликаты, проблемы со схемой данных или противоречия между разными источниками, то после миграции они никуда не денутся. Новая архитектура их не исправит. Скорее, наоборот, сделает более заметными.

Поэтому первый шаг — аудит данных. Нужно понять, насколько согласованы модели между старым и новым хранилищем, нет ли конфликтов между источниками и что придется привести в порядок еще до начала миграции.

На практике проблемы встречаются довольно приземленные. Где-то находятся дубликаты, которые годами искажали статистику. Где-то выясняется, что один и тот же показатель в разных системах считается по-разному. А иногда оказывается, что часть данных просто невозможно использовать: не хватает обязательных полей, нарушены правила целостности, формат записей вообще не соответствует ожиданиям.

Отдельная история начинается, когда данных много и они приезжают из разных источников. Формально все может выглядеть одинаково, но на уровне схем и конкретных записей будут расхождения: названия полей не совпадают, значения конфликтуют, а какие-то данные и вовсе теряются по пути.

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

И еще: разобраться с такими вещами до переезда намного проще, чем обнаружить их уже после запуска новой архитектуры.

Этап 2. Аккуратно (!) переключаем нагрузку

Когда новая архитектура уже готова, остается самый неприятный вопрос: в какой момент отключать старое хранилище?

На мой взгляд, самый безопасный вариант — какое-то время держать обе системы параллельно и постепенно переводить на новую сервис за сервисом. Да, это дороже. Несколько месяцев приходится поддерживать сразу две инфраструктуры. Зато, если что-то пойдет не так, всегда можно быстро откатиться.

Есть и другой подход — переключить все сразу. На бумаге он выглядит быстрее и дешевле. На практике именно здесь обычно и начинаются проблемы.

Иногда достаточно одной таблицы, которая после миграции начинает работать немного иначе, чтобы перестала собираться отчетность или остановился какой-нибудь критичный процесс.

Например, компания решила перенести все хранилище сразу и в тот же день отключить старую систему. Формально данные переехали, запросы работают, все выглядит нормально. А на следующий день выясняется, что забыли перенести несколько хранимых процедур, часть проливок из CRM и PostgreSQL, а еще пару скриптов, которые каждую ночь корректировали данные по продажам.

В результате цифры в отчетах начинают расходиться с реальностью. И самое неприятное здесь то, что проблема обнаруживается не сразу. Первые несколько часов или даже дней может казаться, что миграция прошла успешно.

Если речь идет о банковской системе, то в какой-то момент это перестает быть проблемой одной таблицы и превращается в проблему всего бизнеса.

Поэтому на этапе переключения я бы точно не пытался экономить. Из моего опыта, несколько месяцев параллельной работы двух систем почти всегда обходятся дешевле, чем разбор последствий неудачного перехода.

Этап 3. Быть готовым менять архитектуру по ходу проекта

Еще одна важная особенность: первоначальный план почти никогда не доживает до конца проекта.

Например, сначала кажется, что для работы с архивными данными хватит Spark. Но потом выясняется, что к ним хотят обращаться не только дата-инженеры, но и аналитики. Значит, нужен SQL-движок вроде Trino, чтобы работать с этими данными так же, как с привычными таблицами.

И таких примеров обычно много. Пока идет миграция, становится понятнее, какие сценарии действительно нужны бизнесу, а вместе с ними меняются и требования к самой архитектуре.

Поэтому я бы не воспринимал миграцию как проект, у которого есть четкое состояние готовности. Скорее это постепенная настройка платформы под реальные задачи, которые появляются по мере развития бизнеса.

Что мы получаем в итоге

Первый вывод довольно простой: Data Lakehouse само по себе не делает платформу быстрее, если данные оставить как есть, в одной куче, без ночных предагрегатов. Если их делать, скорость хранилища можно увеличить.

Если просто перенести туда данные и ничего больше не менять, можно получить обратный эффект. Поэтому здесь появляются современные форматы хранения вроде Apache Iceberg, которые позволяют эффективнее работать с большими объемами данных.

Как работает Apache Iceberg: он добавляет объектному хранилищу версионирование, управление схемами, поддержку ACID-операций и более эффективную работу с большими наборами данных. Благодаря этому данные в объектном хранилище перестают быть просто набором файлов и превращаются в полноценный слой хранения, с которым удобно работать аналитикам и их технологическому стеку.

Второй вывод — Data Lakehouse помогает перестать платить за вычисления там, где они не нужны.

Данные продолжают храниться в объектном хранилище, а вычисления подключаются только тогда, когда появляется конкретная задача. Нужно провести исследование — подняли Spark. Нужно дать аналитикам привычный SQL — добавили Trino. Появилась задача потоковой обработки — подключили Flink.

Третий вывод — вместе с Data Lakehouse появляются новые сценарии работы с данными.

Становится проще работать с документами, логами, изображениями и другими неструктурированными данными. Проще запускать ML-задачи, строить RAG-системы и экспериментировать с новыми подходами, не пытаясь каждый раз приспособить под них существующее DWH.

И пожалуй, главный (четвертый) вывод, который я для себя сделал: архитектура данных никогда не остается такой, какой ее придумали в первый день.

Пока строится платформа, бизнес продолжает жить своей жизнью. Появляются новые данные, новые требования и новые сценарии использования. Поэтому хорошая архитектура — это та, которая меняется вместе с бизнесом.

А может, оставить все как есть

И такое тоже может быть. 

Например, если компания работает в основном со структурированными данными, строит регулярную отчетность, а существующее DWH справляется со своими задачами, то переход в новую архитектуру вряд ли что-то изменит. Только если DWH компании не утилизировано полностью, отчего оно начинает тормозить и его масштабировать дороже, чем пересмотреть архитектуру и перейти на Data Lakehouse. 

То же самое, если единственная причина миграции — желание попробовать новую технологию. Data Lakehouse не делает платформу автоматически лучше. Оно решает вполне конкретные задачи: помогает снизить стоимость хранения, разделить вычисления и данные, работать с новыми типами информации. А также, хоть архитектура Data Lakehouse и сложная, но она позволяет хорошо масштабироваться на неоднородных данных. 

Если таких задач нет, усложнять архитектуру просто незачем. Или вы не согласны?