Databricks Lakehouse: когда data lake наконец встречается с warehouse

Десять лет любая серьёзная платформа данных работала на двух системах. Data lake, куда сваливалось всё подряд в дешёвое объектное хранилище, и data warehouse, который отдавал чистые, смоделированные таблицы, к которым бизнес на самом деле обращался. Две копии данных, два набора пайплайнов, два счёта и вечный спор о том, где же лежит истина.

Lakehouse — это попытка схлопнуть это разделение в одно целое. Databricks не изобрёл ни хранилище, ни формат файла, но упаковал этот паттерн во что-то, что команда может эксплуатировать в проде. После нескольких таких проектов вот что здесь реально, а что маркетинг.

Два мира и почему команды держали оба

Data lake — это объектное хранилище — Azure Data Lake Storage Gen2, S3, GCS — с сырыми файлами в любом формате. Оно дешёвое, масштабируется до бесконечности и работает по принципу schema-on-read: структуру ты определяешь при запросе, а не при записи. Плата за это в том, что lake без дисциплины превращается в болото. Ни транзакций, ни проверки схемы, ни простого способа обновить одну строку.

Warehouse — это противоположность. Структурированные таблицы, гарантии ACID, быстрый SQL, настоящее управление. Плата за это — негибкость и цена: ты платишь за загрузку данных, платишь за проприетарное хранилище, а нагрузки machine learning, которым нужны сырые файлы, в эту модель не вписываются.

Держать оба означает вечно копировать данные между ними и сверять копии. Вопрос lakehouse прост: что, если бы lake мог вести себя как warehouse без второй копии?

Что такое lakehouse на самом деле

Трюк в открытом табличном формате поверх файлов в объектном хранилище. В Databricks это Delta Lake: файлы данных Parquet плюс лог транзакций. Этот лог решает всё. Он даёт тебе:

• Транзакции ACID — конкурентные записи больше не портят таблицу.
• Проверка и эволюция схемы — плохие данные отклоняются, хорошие изменения версионируются.
• Time travel — запросить таблицу такой, какой она была в прошлый вторник, или откатить неудачную загрузку.
• Upsert и удаление — MERGE работает, а это важно для удаления по GDPR и для change-data-capture.

Поскольку данные остаются в открытом Parquet в твоём собственном аккаунте хранилища, одна копия обслуживает всё: SQL-дашборды, стриминговые задачи и обучение ML читают одни и те же таблицы. Никакого lock-in на байтах, никакого шага экспорта. В этом и весь выигрыш.

Архитектура medallion

Lakehouse даёт тебе примитивы; архитектура medallion — это то, как ты держишь их в порядке. Данные текут через три уровня качества:

1. Bronze — сырой приём, ровно как пришло. Только-append, аудируемый, никогда не редактируется.
2. Silver — очищенный, дедуплицированный, приведённый к единому виду. Соединённый и типизированный, но всё ещё детальный.
3. Gold — агрегаты бизнес-уровня и схемы «звезда», которые потребляют дашборды и отчёты.

Дисциплина важнее инструмента. Bronze — это твоя страховка: если преобразование в silver сделано неправильно, ты переобрабатываешь из bronze, а не заново принимаешь из источника. Пропусти его — и потеряешь возможность починить историю.

Unity Catalog: управление, которое нельзя прикрутить потом

Unity Catalog — это та часть, которую большинство недооценивает. Это единый слой управления над всеми workspace: детальный контроль доступа, маскирование столбцов и строк и — то, что спасает тебя на аудите — автоматический lineage. Ты видишь, какой отчёт зависит от какой gold-таблицы, которая зависит от какой silver-задачи, вплоть до сырого файла.

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

Производительность: Photon и SQL warehouse

Старое возражение против lake было в скорости: запросы к файлам не могли тягаться с настроенным warehouse. Две вещи закрыли разрыв. Photon — это векторизованный движок запросов, написанный на C++, который ускоряет нагрузки SQL и DataFrame без изменения твоего кода. А SQL warehouse в Databricks дают аналитикам привычный endpoint: они подключают BI-инструмент и запрашивают gold-таблицы, не подозревая, что под ними объектное хранилище.

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

Когда lakehouse — неверный ответ

Это не универсальный апгрейд. Будь честен насчёт масштаба:

• Маленькие, чисто реляционные данные. Если всё удобно помещается в Postgres и ты обслуживаешь только BI, управляемый warehouse проще и дешевле. Lakehouse — это машинерия, которая тебе не нужна.
• Нет инженерной ёмкости. Delta, кластеры и поток medallion — это реальная операционная поверхность. Крошечная команда тонет.
• Чистые, стабильные схемы «звезда» без ML и стриминга. Lakehouse блистает, когда нагрузки смешанные. Если у тебя они никогда такими не станут — гибкость становится мёртвым грузом.

---

Lakehouse заслуживает своё место, когда у тебя действительно есть оба мира — сырые и стриминговые данные, питающие ML, и чистые таблицы, питающие бизнес, — и ты устал платить дважды, чтобы держать их синхронными. Начни с Delta и уровней medallion, сразу включи Unity Catalog и дай Photon позаботиться о скорости. Дальше в этой серии: как Microsoft играет в ту же игру с Fabric, OneLake и Copilot Studio.