Две копии одних данных
Классическая раскладка, из которой вырос лейкхаус, выглядит так: сырые данные падают в дешёвое файловое хранилище («озеро»), а конвейер переносит из них аккуратную выжимку в склад — дорогой, транзакционный, со строгой схемой. Одна и та же информация живёт дважды, и между копиями стоит ETL. В складе к тому же хранение обычно связано с движком: нельзя докупить место, не докупив вычисления.
Болеть начинают предсказуемые места. Свежесть ограничена конвейером: цифры для аналитика не существует, пока она не прошла перенос. Деньги — та же история: за хранение платят дважды, плюс платят за сам перенос. И копии расходятся: склад можно подлатать руками, а озеро лежит таким, каким его записали. Чинить отчёты на выходе можно бесконечно — мы спорили об этом в материале о контрактах данных.
Отсюда вопрос, который породил лейкхаус: можно ли получить складские гарантии там, где данные уже лежат, не плодя вторую копию?
Если совсем коротко, что это такое: лейкхаус — дешёвое объектное хранилище с открытыми файлами, поверх которого стоит слой метаданных, превращающий каталог файлов в таблицу с транзакциями. Дальше — зачем нужен этот слой и во что он обходится.
Тупик, который пробуют первым
Первый ответ на тот вопрос пробуют почти все, потому что он выглядит бесплатным: подключить движок склада к файлам в озере напрямую. Внешняя таблица поверх каталога — ни нового софта, ни конвейера, ни второй копии. На демо это даже работает.
Дальше — нет. Задание, которое «пишет таблицу», на самом деле пишет файлы в каталог. Упало на середине — в каталоге лежит половина таблицы, и читатели видят её немедленно. Момента, в котором таблица стала целой, в этой конструкции не существует.
Схема не проверяется нигде: любой файл, попавший в каталог, становится частью таблицы. Один файл с лишней колонкой — и отчёт падает на чтении; узнаете об этом из тикета, а не из логов записи.
Обновление — это перезапись. Колоночные файлы (типичный пример — открытый формат вроде Parquet) не редактируют на месте: поменять одну строку — значит переписать файл целиком. Два писателя, взявшиеся за одни и те же файлы, тихо портят друг друга; побеждает последний, потери не оставляют следа.
Планировщику, наконец, нечего читать: он не знает, что лежит в каком файле, и вынужден читать всё. Ручное партиционирование немного спасает, но это ручной труд, который надо поддерживать.
Вывод из тупика: дело не в файлах — для аналитических сканов колоночный формат отличный. Дело в том, что у каталога нет транзакции. Лечить надо не файлы, а способ объявлять таблицу. Это и есть лейкхаус.
Как это устроено: таблица — это указатель
Ход лейкхауса: перестать считать таблицу каталогом. Таблица — это снапшот, список файлов плюс журнал коммитов. Запись делается в два шага: сначала рядом со старыми файлами кладутся новые, потом указатель на текущий список атомарно переключается на свежий. Читатель берёт текущий список и не видит ничего, кроме него — смеси состояний не бывает.
Из этой пары шагов вырастает всё, за что платят. У коммита появилось место, где записанное сверяется с объявленной схемой: мусор не доезжает до таблицы. Старые списки никуда не деваются — ткните в позавчерашний снапшот и читайте таблицу той давности; для разбора «когда именно сломалось» это подарок. И главное: формат открыт, поэтому одни и те же файлы читают разные движки. Данные перестают быть заложником одной системы, а конвейер «озеро → склад» исчезает как класс.
Теперь честная часть. Атомарность переключения откуда-то надо взять: объектные хранилища атомарных операций над каталогами не умеют. Поэтому в архитектуре появляется либо отдельный регистратор — маленькая база, чья единственная работа быть арбитром указателя, либо условные операции записи, если хранилище их поддерживает. В любом случае транзакция не исчезла из мира — она переехала из недр закрытого движка в слой метаданных. И этот механизм — ваш новый критический компонент: лежит арбитр, и не пишет никто; тормозит — коммиты стоят в очереди. Файлы здесь открыты, а вот регистратор — не обязательно: открытость лейкхауса кончается ровно там, где начинается его транзакция.
Второе фундаментальное решение — иммутабельность: файлы не редактируются на месте, только заменяются новыми. И ещё одна трещина: самих табличных форматов несколько, и метаданные у них несовместимы — файлы под ними те же, а «таблицей» их делает несовместимый слой. Запомните пару решений — файлы неизменяемы, таблица есть указатель на список: каждая поломка ниже прямиком из них.
Почему ломается именно так
Мелкие файлы. Потоковой загрузке нужна свежесть, значит — частые коммиты; каждый коммит рождает новые файлы, а объектное хранилище ходит по каждому файлу отдельным запросом. Каталог распухает, перечисление перестаёт укладываться в разумное время, чтения деградируют. Лечение — компакция: фоновый процесс, сливающий мелкие файлы в крупные. Проблема — в арифметике; посчитайте сами: частота коммитов, помноженная на число файлов в коммите, даст число файлов, рождающихся за сутки; сравните его с тем, сколько ваш компактор успевает слить за те же сутки. Если рождается больше, чем сливается, кэш не спасёт — планировщику всё равно придётся открывать каждый файл.
Записи в параллель. Атомарность здесь оптимистичная: два писателя ответвились от одного снапшота, оба сделали работу, оба пришли переключать указатель — арбитр пропускает одного, второго отправляет переделывать. Если пайплайны пересекаются по разделам, они будут сталкиваться регулярно, и разметка разделов из вопроса удобства запросов превращается в вопрос параллелизма. В классическом складе записи сериализовал сам движок, думать об этом не приходилось. Здесь — приходится.
Снапшоты не бесплатны. Путешествие во времени означает: файлы живут, пока на них ссылается хоть один снапшот. Окно хранения, умноженное на частоту коммитов, — вот сколько списков и файлов болтается в хранилище. Подчищать редко — стоимость ползёт вверх; подчищать жадно — долгий батч, читающий старый снапшот, внезапно обнаруживает, что файлов под ним больше нет. Ещё одна фоновая работа, ещё одна ручка.
Эволюция схемы со звёздочкой. Добавить nullable-колонку — коммит только по метаданным, дёшево. Переименовать колонку, поменять тип, удалить поле — правила зависят от формата и от того, умеет ли каждый читатель эти правила применять. Спецификации табличных форматов живут своей жизнью, движки реализуют их неравномерно, и инцидент «этот движок не читает эту таблицу» — не экзотика, а будни: матрица «возможности движка × возможности формата» теперь ваша забота.
И главное. Транзакции — не про правду. ACID гарантирует, что закоммиченное есть целостный снимок хранилища; о том, верны ли числа внутри снимка, он не говорит ничего. Атомарно и красиво закоммиченная ошибка остаётся ошибкой. Именно поэтому лейкхаус не отменяет контракты данных: он отвечает за атомарность доставки, контракт — за то, что именно доставляется. Это разные проблемы, и живут они в разных слоях.
Позиция редакции
Что реально поменялось — не «склады умерли». Транзакция и схема переехали из закрытого движка в открытый слой над файлами, и из-за этого данные перестали принадлежать одному инструменту: одну копию читают несколько движков, вторая копия и конвейер между системами исчезают. Всё остальное в лейкхаусе — маркетинг.
Мы считаем: лейкхаус оправдан, когда у данных несколько потребителей с разными инструментами — от дашбордов до обучения моделей — и когда стоимость дубля и переноса реально давит. Когда потребитель один и движок один, он не оправдан: вы берёте на себя каталог, компакцию, матрицу совместимости и платите этим за открытость, которой не пользуетесь. Склад одним куском даст то же самое проще.
Условие, при котором мы неправы: если эксплуатация слоя метаданных перестанет быть вашей работой — каталог, компакция и совместимость уйдут в управляемые сервисы и перестанут требовать людей, — тогда наш аргумент «это дорого в эксплуатации» исчезает даже для одного потребителя, и позиция неверна. Условие второе, тоньше: если выгружать данные из закрытых складов в открытые форматы станет так же просто, как читать, аргумент «нет привязки к вендору» ослабнет — и тут мы тоже пересмотрим.
Практическая проверка: посчитайте писателей, потребителей и частоту коммитов, прикиньте арифметику компакции из раздела выше. Если после этого аргумент за лейкхаус не выжил — он вам не нужен. Если выжил — вы хотя бы знаете, за что платите.