Вы сравниваете теплое с мягким. Iceberg вообще никак не влияет на подходы к построению хранилища и не мешает строить звезды Кимбала или DataVault, это просто ортогональные вещи.
Подход "бизнес хочет?" - "на держи" - это так вообще лет 10 уже как, и например, Data Vault ровно для этого.
В целом, простите, я пока наблюдаю какой то сумбур, не с точки зрения подхода, а с точки зрения уровней абстракции, вы скачeте и путаете вместе физическое хранение, движки, подходы к проектированию слоев, сами слои и методологии построения.
Попробуйте для себя разделить эти вещи и тогда народ к вам потянется, идеи интересные, но плохо сформулированные.
Странная статья, с одной стороны интересный практический опыт, с другой стороны своя терминология. Например, Stage слой в терминологии автора, очень похож на детальный (Core) слой.
Так же не понятно зачем структуру/количество слоев противопоставлять технологиям представления данных внутри слоя (тот же Data Vault). Нормальная ситуация, когда ядро делают по Инмону (тот же Data Vault его вариация), а слой витрин по Кимбалу.
Тут конечно можно ответить, что Инмон и Кимбал это именно технологии построения всего хранилища, но они давно уже стали нарицательными именно для подходов организации таблиц внутри слоев.
Ну и привязка к технологиям мне кажется в теории построения хранилища не очень уместна, я конечно понимаю, что "clickhouse не тормозит, но" заставляет специфично строить DWH, но при этом сравниваются именно технологические подходы к проектированию в которых конкретные технологии не заложены.
P.S. Автор часто пишет "мы", хотелось бы понять опыт какой компании тут изложен
Все же мои вопросы не поняли: 1. Сравнивая себя с чем-то, вы как бы помещаете два решения на одну доску, у меня вопрос корректно ли сравнивать решение с Exadata если у него нет Smart Scan ... Хотелось бы понять почему данное решение сравнивается именно с Exadata если ключевая технология Exadata не реализована?
2. Безусловно я понимаю разницу между OLAP и HTAP, но в любом случае читая статью, я понимаю архитектуру решения, но хотелось бы понять позиционирование решения относительно движков которые также могут выполняют часть функций, и мне этого в статье не хватило. Иными словами где применить, скажем PostgreSQL или GreenPlum, а где ваше решение? Что лучше для решения задач аналитики? Или тут ниша именно когда хочется навернуть немого OLAP к OLTP? Претендуете ли вы на нишу чистого OLAP как это делала Exadata?
Прошу прощения на акценте на OLAP, но я больше этой нагрузкой занимаюсь.
P.S. Вы пишите "это HTAP, а не MPP система" и тут же в сравнении "Yes: PX Engine with cluster-wide MPP (compute-driven parallelism across RW + RO nodes)". Это опять же о подборе вопросов в сравнении и позиционировании решения.
P.P.S. Со StaRocks не аффинирован, просто модная технология.
Статья хорошая, автор раскрыл тему. Огромное ему спасибо.
Но тут есть три НО: 1. Автор рассматривает всего одно соединение, а если их несколько потребление памяти растет пропорционально
2. Если таких запросов в системе не один, а скажем 100 или больше, то внезапно память уже кончилась, а если еще несколько джойнов в одном запросе (смотри пункт первый)
3. Ну и наконец добавляем шарды, и тут становится совсем весело, так как если мы отказываемся от локальных джойнов, то при джойне 2 больших таблиц все данные едут на один шард и там кончается память
Собственно пока clickhouse не научится писать на диск информацию для джойна при нехватке памяти (пункты 1-2) и нормальную обработку джойнов шардированных таблиц не таща вся на один шард (пункт 3), для меня это система на которой нормального функционала джойнов нет.
Тут вопросов больше чем ответов: 1. Сравнение с Exadata без Smart Scan зачем кроме кликбейтного заголовка? По факту же прелесть Exadata в вычислениях на storage нодах.
2. Не будет ли затыком одна пишущая нода?
3. Чем это лучше скажем того же StarRocks, где можно вынести слой хранения во вне и все ноды могут писать, а не только читать?
В целом, тут видимо, мне не хватило отстройки позиционирования, скажем преимущество над:
1. просто Postgres c репликацией и чтением с реплик
2. MPP (Greenplum, StarRocks и ко.)
3. LH варинтов включая тот же StarRocks в таком режиме работы.
DuckDB и Ducklake это разное. Разница такая же как между Icеberg и скажем Trion его использующим.
В Ducklake полноценные транзакции включая DDL, и не на одну операцию, а на сколько угодно и над сколько угодно таблиц. В параллельной сессии до коммита не видно изменений, включая вставленные строики или вновь созданные обькеты схемы.
Если серьезно хотите говорить про ACID то отсылайте хоть к тому кто эти принципы сформулирвал, а не к пересказчикам.
Оно, как с любой зрелой технологией, она работает, завышенные ожидания ушли. Нашло свою нишу.
Проблема в том, что все пытаются найти серебряную пулю которая решит все проблемы, вместо того что бы сочетая технологии строить взвешенное решение.
По рынку бегает 100500 20-30 летних CDO, которые за плечами не имеют ни одного реализованного хранилища и кричат, что лейкхаус все полечит. Ударятся лбом, часть повзрослеют и будут выбирать не "универсальное спасение" а технологии подходящие для задачи.
Еще не вспомнили про FOR NO KEY UPDATE?! Значит я первый. Почитайте, тут было пару статей в том числе и про паттерн очередей в PostgreSQL, и почему нужно использовать именно FOR NO KEY UPDATE, а не FOR UPDATE...
Раньше инструменты Low-Code и No-Code ETL использовали в основном технические энтузиасты — аналитики или инженеры, которым было интересно попробовать новый подход для себя или в рамках пилотных проектов.
Вот тут смешно прям, Informatica, ODI, и прочие NiFi, давно корпоративные стандарты.
В целом статья слишком высокоуровневая, для каждого из видов платформ не хватает примеров реальных систем.
Ну и рекламируете свой LowCode - так картинок хоть накидайте. Оно же про визуальное программирование.
Да, через row_number(). На больших сателлитах появляются проблемы. В нашем случае, например, это сателлит с объявлениями, где нужно хранить всю историю.
Вы сравниваете теплое с мягким. Iceberg вообще никак не влияет на подходы к построению хранилища и не мешает строить звезды Кимбала или DataVault, это просто ортогональные вещи.
Подход "бизнес хочет?" - "на держи" - это так вообще лет 10 уже как, и например, Data Vault ровно для этого.
В целом, простите, я пока наблюдаю какой то сумбур, не с точки зрения подхода, а с точки зрения уровней абстракции, вы скачeте и путаете вместе физическое хранение, движки, подходы к проектированию слоев, сами слои и методологии построения.
Попробуйте для себя разделить эти вещи и тогда народ к вам потянется, идеи интересные, но плохо сформулированные.
Странная статья, с одной стороны интересный практический опыт, с другой стороны своя терминология. Например, Stage слой в терминологии автора, очень похож на детальный (Core) слой.
Так же не понятно зачем структуру/количество слоев противопоставлять технологиям представления данных внутри слоя (тот же Data Vault). Нормальная ситуация, когда ядро делают по Инмону (тот же Data Vault его вариация), а слой витрин по Кимбалу.
Тут конечно можно ответить, что Инмон и Кимбал это именно технологии построения всего хранилища, но они давно уже стали нарицательными именно для подходов организации таблиц внутри слоев.
Ну и привязка к технологиям мне кажется в теории построения хранилища не очень уместна, я конечно понимаю, что "clickhouse не тормозит, но" заставляет специфично строить DWH, но при этом сравниваются именно технологические подходы к проектированию в которых конкретные технологии не заложены.
P.S. Автор часто пишет "мы", хотелось бы понять опыт какой компании тут изложен
Саша, серьезно миграция с GP на Clickhouse?!
Пока StarRocks будет в списке рядом с Clickhouse, GP может спать спокойно ;-)
Это не про фичи, это про позиционировании. В остальном статья понравилась, хорошее сравнение.
Интересная статья, спасибо.
Поскольку статья называется "StarRocks вместо Oracle" хотелось бы цифры для Oracle увидеть, что бы с чем сравнивать.
Добрый день, для raid допускающих потерю данных, время восстановления (rebuild) не тестировали?
Очень интересны эти цифры...
Все же мои вопросы не поняли:
1. Сравнивая себя с чем-то, вы как бы помещаете два решения на одну доску, у меня вопрос корректно ли сравнивать решение с Exadata если у него нет Smart Scan ...
Хотелось бы понять почему данное решение сравнивается именно с Exadata если ключевая технология Exadata не реализована?
2. Безусловно я понимаю разницу между OLAP и HTAP, но в любом случае читая статью, я понимаю архитектуру решения, но хотелось бы понять позиционирование решения относительно движков которые также могут выполняют часть функций, и мне этого в статье не хватило.
Иными словами где применить, скажем PostgreSQL или GreenPlum, а где ваше решение? Что лучше для решения задач аналитики? Или тут ниша именно когда хочется навернуть немого OLAP к OLTP? Претендуете ли вы на нишу чистого OLAP как это делала Exadata?
Прошу прощения на акценте на OLAP, но я больше этой нагрузкой занимаюсь.
P.S. Вы пишите "это HTAP, а не MPP система" и тут же в сравнении "Yes: PX Engine with cluster-wide MPP (compute-driven parallelism across RW + RO nodes)". Это опять же о подборе вопросов в сравнении и позиционировании решения.
P.P.S. Со StaRocks не аффинирован, просто модная технология.
Статья хорошая, автор раскрыл тему. Огромное ему спасибо.
Но тут есть три НО:
1. Автор рассматривает всего одно соединение, а если их несколько потребление памяти растет пропорционально
2. Если таких запросов в системе не один, а скажем 100 или больше, то внезапно память уже кончилась, а если еще несколько джойнов в одном запросе (смотри пункт первый)
3. Ну и наконец добавляем шарды, и тут становится совсем весело, так как если мы отказываемся от локальных джойнов, то при джойне 2 больших таблиц все данные едут на один шард и там кончается память
Собственно пока clickhouse не научится писать на диск информацию для джойна при нехватке памяти (пункты 1-2) и нормальную обработку джойнов шардированных таблиц не таща вся на один шард (пункт 3), для меня это система на которой нормального функционала джойнов нет.
Тут вопросов больше чем ответов:
1. Сравнение с Exadata без Smart Scan зачем кроме кликбейтного заголовка? По факту же прелесть Exadata в вычислениях на storage нодах.
2. Не будет ли затыком одна пишущая нода?
3. Чем это лучше скажем того же StarRocks, где можно вынести слой хранения во вне и все ноды могут писать, а не только читать?
В целом, тут видимо, мне не хватило отстройки позиционирования, скажем преимущество над:
1. просто Postgres c репликацией и чтением с реплик
2. MPP (Greenplum, StarRocks и ко.)
3. LH варинтов включая тот же StarRocks в таком режиме работы.
DuckDB и Ducklake это разное. Разница такая же как между Icеberg и скажем Trion его использующим.
В Ducklake полноценные транзакции включая DDL, и не на одну операцию, а на сколько угодно и над сколько угодно таблиц. В параллельной сессии до коммита не видно изменений, включая вставленные строики или вновь созданные обькеты схемы.
Если серьезно хотите говорить про ACID то отсылайте хоть к тому кто эти принципы сформулирвал, а не к пересказчикам.
Вот это крайне интересно, как будет выглядеть в этом свете статья или презентация в ИТ сфере?
Ну так, ACID не равно транзакции. Lakehouse дает большую консистентность, чем Data Lake и это плюс.
Хочется полноценных транзакций в Lakehouse так их есть, скажем в DuckLake.
Оно, как с любой зрелой технологией, она работает, завышенные ожидания ушли. Нашло свою нишу.
Проблема в том, что все пытаются найти серебряную пулю которая решит все проблемы, вместо того что бы сочетая технологии строить взвешенное решение.
По рынку бегает 100500 20-30 летних CDO, которые за плечами не имеют ни одного реализованного хранилища и кричат, что лейкхаус все полечит. Ударятся лбом, часть повзрослеют и будут выбирать не "универсальное спасение" а технологии подходящие для задачи.
Еще не вспомнили про FOR NO KEY UPDATE?!
Значит я первый. Почитайте, тут было пару статей в том числе и про паттерн очередей в PostgreSQL, и почему нужно использовать именно FOR NO KEY UPDATE, а не FOR UPDATE...
Я ожидал от статьи объяснения исходя из внутреннего устройства PG, а получил мы померили своей измерялкой, эмпирическое правило не догма.
Иными словами я эмпирическое правило поменял не на знания, а на 3 эмпирических правила из вывода в конце статьи.
А указанные в статье доработки Impala доступны в OpenSource или только вашим заказчикам?
Так tpc тесты так и задумывались, только это превратилось в спорт, а со стороны покупателя в шараду, что накрутил вендор, что бы выиграть.
Мне такого форматы статьи гораздо больше нравится, когда не про цифры, а про реальные планы запросов и косяки оптимизатора.
Он бы на join слился, не его это
Вот тут смешно прям, Informatica, ODI, и прочие NiFi, давно корпоративные стандарты.
В целом статья слишком высокоуровневая, для каждого из видов платформ не хватает примеров реальных систем.
Ну и рекламируете свой LowCode - так картинок хоть накидайте. Оно же про визуальное программирование.
Очередной ChatGPT текст от автора...
Вот тут PITR должен помочь...