MPP подход к DLH против DataLake Тут как. По сути есть 2 подхода к Лейкхаусу 1. Со стороны MPP - взять готовую транзакционную машину и привести ее к хранению данных отдельно от движка в S3/HDFS. Потом придумать переиспользование этих же данных другими кластерами и другими движками. 2. Со стороны Лейка - взять (почти) готовое разделение Compute-Storage и привети к транзакционной машине. Первый подход делают в Яндексе и Cloudberry c Гринпламом. Не сказать чтоб без успеха, но пока не довели. Doris идет тем же путем. Второй подход реализовали быстрее. Я связываю это с тем, что в лейковом сценарии уже было много готового. - уже распределенные движки Spark, Flink, Trino, которые приспособлены к работе отделенными от себя данными - уже реализованный принцип один датасет + много разных движков чтения. В Хадупе так работает уже десяток лет. То есть Лейк оказался архитектурно сильно ближе к лейкхаусному сценарию. МРР слишком заперт в архитектуре классических БД, из которых они эволюционно возникли. Там надо побороть жесткое шардирование, там все расчитано, что с файлами можно работать на уровне блочки - в любой момент в любое место дописать или переписать. По итогу - даже запишет Greenplum в S3 данные через драйвер-враппер (Yezzey). Как потом это прочитает другой кластер гринплмам, у которого другое число сегментов? И получился вроде и лейк, но в то же время это просто МРР с одной вынесенной куда-то таблицей, от которой другим чтецам пользы никакой. А сдвинуть МРР с этой точки это переписать само ядро так что это будет уже что-то совсем другое. Долгий путь.