Комментарии 10
Спасибо за материал. Есть ли шанс, что через 10 лет появится новый подход полностью заменяющий эти три модели?
Просто придумали новое слово и теперь его нужно продать. Я так и не понял из статьи каким образом реализуется объединение dwh и lake, каковы эти самые "принципы" нового слова lakehouse? Что за технологии под катом?
То есть я могу любой datalake обозвать lakehouse добавив ему например структурированности или чего ему добавить из dwh, звезду?)))
Не понятно.
Нужно добавить «облачную эластичность» (сдувание/раздувание ресурсов), разделение уровня вычисления и хранения, умный SQL-оптимизатор и транзакционность — и тогда действительно получится Lakehouse. А то что Lakehouse «модное слово» — тут Вы абсолютно правы!
Хорошо, спасибо за ответ, я побуду занудой, как практик и очень нелюбящий всякие такие вот маркетинговое брендирование аля бигдата, лэйкхаус, даталэйк))) есть хранилище данных отвечающее потребностям бизнеса, теперь давайте по порядку
1. умный оптимизатор, он чем умнее? Оптимизатор, это тот который выбирает план выполнения запроса? Он не сможет выбрать умнее, он сможет хорошо выбрать если хранилище хорошо собрано под запросы которые туда отправляют и ему нужно выбрать лучше чем написал пока не очень опытный разработчик запросов. Нет индекса, оптимизатор его не создаст перед выполнением запроса, он хоть и умный но будет вынужден сканировать.
2 транзакционность - тут простите ни чего нового, оно и так есть как факт и там и там
3 облачная история, эластичность облачная ещё одна маркетинговая формулировка, облако это хорошо, экономит деньги для тех у кого их нет, вся любовь
Я к чему, адекватная, правильная работа с данными зависит от СУБД, это как то как хранятся данные физически, сжатие к примеру и как быстро она их отдаст, колоночные как пример.
И вы как хотите назовите свою архитектуру, физическую структуру, логическую, под катом она будет иметь все известные технологии работы с данными, и они либо хорошие либо нет. В какашку можно превратить любое хранилище. Важно
Грамотно организованное (спроектированное) хранилище данных, бд если короче
П1.Описанное понятно, для вновь зашедших
ETL ELT да хоть как буквы переставляй, инструменты транспорта данных, вообще стали критически важными и вышли на первое место, ввиду больших объемов передачи, не все справляются и идеальных нет, тут зоопарк, тут нужно поработать;)
СУБД - должна просто уметь быстро отдать данные для аналитики
И как вы не называйте, принципы одни и те же
Собери быстро
Разложи быстро
Отдай быстро
Три слона:)
СРО - просто такое слово не продается, а lakehouse и bigdata - да:)
Да и почему в таблице сравнения подходов только два субъекта сравнения?
Во-первых, спасибо за много пунктов — хочется ответить на каждый. Во-вторых, попробую ответить на самый, на мой взгляд, главный. Мы рассматриваем DWH и Data Lake, потому что знаем множество случаев, когда компании мучительно выбирали между ними, и немало примеров, где выбрать так и не смогли, в результате построив и то, и другое! Если тем, кто не смог выбрать, и тем, кто сейчас вынужден эксплуатировать две разные инфраструктуры (одну под DWH, другую под Data Lake, обе размером около петабайта), дать универсальное решение для хранилища — их жизнь станет значительно проще! А если это решение окажется ещё и дешевле — то вообще замечательно!
Спасибо за статью. После прочтения и общения с ллм по поводу уточняющих вопросов ± разобрался.
Очень не хватает дополнительных поясняющих схем
Hadoop, Cloudera, Hortonworks - это точно статья из 2025 года?
Как не утонуть в данных: выбираем между DWH, Data Lake и Lakehouse