В чем устройство LakeHouse и отличие от баз данных?

В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки

Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)

Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).

Об естественных особенностях такого решения:

➕Удобно и гибко
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.

➕Дешевле
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд

➖Сильно медленнее чем классические базы данных
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.

➖Тяжело
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)

*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.

В Spark 4.1 появлся ... Airflow

В документации версии Spark 4.1-Preview появились так называемые Spark Declarative Pipelines (SDP)

На борту:

1️⃣ Несколько видов датасетов: Материализованные, Стриминговые, Временные
2️⃣ Пайплайн как объект. Описывается через YAML файл с SQL, Python кодом и необходимыми конфигами Спарка. Также объявляется каталог (Hive, Iceberg), с которым можно взаимодействовать и в который складывать результаты.
3️⃣ Команда spark-pipelines init с интерфейлом и аргементами как у Spark Submit. Отдельная команда spark-pipelines run.


Удобство

Пример нового кода на PySpark, который читает Kafka топик и складывает данные в таблицу в каталоге. По сути это декларативное описание (не как-сделать, а что-сделать) а-ля DAG.

from pyspark import pipelines as sdp

@sdp.table
def ingestion_st():
return (
spark.readStream.format("kafka")
.option("kafka.bootstrap.servers", "localhost:9092")
.option("subscribe", "orders")
.load()
)

К объявленной таким способом таблице можно обращаться дальше по пайплайну.

На SQL и того проще

CREATE STREAMING TABLE basic_st
AS SELECT * FROM STREAM samples.nyctaxi.trips;

Или пример с несколькими синками

-- create a streaming table
CREATE STREAMING TABLE customers_us;

-- add the first append flow
CREATE FLOW append1
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_west);

-- add the second append flow
CREATE FLOW append2
AS INSERT INTO customers_us
SELECT * FROM STREAM(customers_us_east);

Осталось разобраться, как в этом всем провязаны семантики доставки (exactly-once, at-least-once), и куда это все полетит при смене схемы источника (Dead Letter). И понять, как устроить мониторинги и алерты работающих или сломавшихся пайплайнов.

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

Насладиться примерами можно в офф доке превью версии

СУБД made in China
Пополнение в копилку необычных СУБД — AliSQL от Alibaba Group, которая владеет известным китайским маркетплейсом. Это форк от MySQL со всевозможными улучшениями производительности и стабильности. Полный список поддерживаемых фич в официальной документации выглядит очень внушительно.

🔵На Githab отдельно подсветили то, что AliSQL использует аналитическую DuckDB в качестве подсистемы хранения и поддерживает векторный поиск. За счет этого подходит для аналитических задач и работы с ИИ.
🔵В роадмапе — оптимизация DDL, RTP и репликации.

В Alibaba Group AliSQL использовали для своих внутренних нужд, но в конце 2025 поделились исходным кодом. Так что вы можете стать контрибьютором или просто потестить, как она работает.

Нестандартные способы оптимизировать PostgreSQL
Стандартные вы и так знаете — переписать запросы, добавить индексы, пройтись по базе VACUUM’ом. Но есть и менее очевидные подходы, которые могут дать прирост производительности. Принесли вам шпаргалку с 3 такими приемами (с примерами), которые особенно пригодятся в аналитике.

У автора все написано подробно, ниже — главное, чтобы понять, стоит ли читать целиком.

1️⃣Использовать constraint_exclusion, чтобы PostgreSQL не читал всю таблицу, если запрос заведомо не может вернуть данные.
Допустим, у вас есть столбец, в котором указан тарифный план, на который подписан каждый пользователь — free или pro. Если аналитик опечатается в запросе и напишет SELECT * FROM users WHERE plan = 'Pro', то он получит 0 результатов, но PostreSQL все равно старательно пройдется по всей таблице и потратит время. Чтобы он так не делал, нужно настроить параметр constraint_exclusion, чтобы он не пропускал такие запросы.

2️⃣ Создавать функциональные индексы.
Например, если у вас есть данные о дате и времени, когда была совершена продажа. Если в компании дела идут хорошо, то продаж будет много, а значит надо это дело как-то оптимизировать.

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

3️⃣ Использовать хеш-индексы для длинных строк.
Если нужно хранить уникальные длинные строки (например, URL), обычный индекс может разрастись до неприличных размеров. В таком случае можно использовать хеш-индекс, который хранит не сами значения, а короткие хеш-значения.