MPP подход к DLH против DataLake

Тут как. По сути есть 2 подхода к Лейкхаусу

1. Со стороны MPP - взять готовую транзакционную машину и привести ее к хранению данных отдельно от движка в S3/HDFS. Потом придумать переиспользование этих же данных другими кластерами и другими движками.

2. Со стороны Лейка - взять (почти) готовое разделение Compute-Storage и привети к транзакционной машине.

Первый подход делают в Яндексе и Cloudberry c Гринпламом. Не сказать чтоб без успеха, но пока не довели. Doris идет тем же путем.

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

- уже распределенные движки Spark, Flink, Trino, которые приспособлены к работе отделенными от себя данными
- уже реализованный принцип один датасет + много разных движков чтения. В Хадупе так работает уже десяток лет.

То есть Лейк оказался архитектурно сильно ближе к лейкхаусному сценарию.

МРР слишком заперт в архитектуре классических БД, из которых они эволюционно возникли. Там надо побороть жесткое шардирование, там все расчитано, что с файлами можно работать на уровне блочки - в любой момент в любое место дописать или переписать.

По итогу - даже запишет Greenplum в S3 данные через драйвер-враппер (Yezzey). Как потом это прочитает другой кластер гринплмам, у которого другое число сегментов? И получился вроде и лейк, но в то же время это просто МРР с одной вынесенной куда-то таблицей, от которой другим чтецам пользы никакой.

А сдвинуть МРР с этой точки это переписать само ядро так что это будет уже что-то совсем другое. Долгий путь.