Comments 24
В чем смысл разделения КХД и Витрин в представленной архитектуре, с учётом того, что и Кликхаус и Гринплам OLAP базы, и там и там структурированная информация?
К тому же, Кликхаус,в отличие от Гринплама, имеет существенные ограничения по поддержке сложного SQL в кластере, если говорить про аналитические запросы, характерные для витрин данных.
да Кликхаус тут просто как быстрый кэш, никаких SQL трансформаций.
А вот к выбору BI тула вопросы. Нужен PowerBi
Смысл в том что так говорит делать аренадата :)
Всё-таки ClickHouse лучше работает с большим количеством подключений. Поэтому я бы начинал с Greenplum, а дальше при необходимости выносил нагрузку с витринами данных в ClickHouse.
Также раньше BI вроде Power BI, Tableu и Click подгружали периодически данные в себя и визуализация строилась из загруженных данных в своё хранилище. А вот Superset и Redash работают только по модели Direct Query и каждое изменение параметра в визуализации может создавать нагрузку на КХД. Когда её слишком много, лучше использовать промежуточный ClickHouse.
В конечном итоге я бы оставил ELT и хранилище в Greenplum, все данные в нормальной форме начиная с 3-ей. А вот в ClickHouse витрины в максимально плоском виде.
не раньше а и сейчас PowerBi и все продвинутые BI tools имею свою встроенную olap субд для кэшерования. А на счет подключений - опять же. PowerBi имеет один конекшен к субд, выкачивает данные, а пользуются им потом 100500 человек.
Clickhouse ничем не лучше GP по количеству подключений/запросов в сек и тп.
Обновление упомянутых плоских таблиц в кликхаусе на основе изменений данных в GP - это будет то еще приключение:
1) вычислить консистентный набор изменений в GP на точку во времени
2) нетривиальная задача заапдейтить данные в кликхаусе, набором из п1, так чтобы никто не прилёг и консистентность чтения из кликхауса была обеспечена в любой момент времени
Первое правило бойцовского клуба - не устанавливаете hadoop в облаке.
второе правило бойцовского клуба - вообще не устанавливайте hadoop
В целом Hadoop - вещь не для всех :) Лучше с S3 начать для хранения. На мой взгляд в облаке Hadoop можно использовать для обработки данных (Spark, Hive).
А какие минусы использования Hadoop в облаке? Интересно синхронизироваться)
Минус в том что HDFS в облаке звучит дико, учитывая требования к дисковой подсистеме, которые в облаке никак не обеспечишь и симметричность масштабирования Hadoop как такового (диски и вычислительные мощности заканчиваются по разному, а масштабируются всегда вместе)
Правильное решение:
S3 + managed k8s над которым compute сервисы в виде spark и чего то для SQL (Impala Presto\Trino, но конечно же не HIVE). В итоге честный pay as you go и стоимость вычислений самая низкая из тех что можно придумать. Ниже даже чем тот же GreenPlum в SaaS
Согласен! Не сравнивал бы Greenplum и Datalake на S3/HDFS, всё под свои задачи.
Такое решение предлагали, но для заказчиков требования оказываются довольно высокими к техническим компетенциями: spark, kuber.
Спасибо за развёрнутый ответ!
Ну потому что вы мыслите спарком. Если вы возьмете нормальный SQL like джижок, то узнаете что он не только быстрее чем GP в большинстве ETL, ad-hoc и BI задач, но и стоимость вычислений в облаке будет значительно ниже.
Hadoop в облаке никому не нужен, стораж - это s3 либо Azure DL, вычисления либо датабрикс либо сразу Snowflake. Администрирование в 100 раз проще, цены на хранение дешовые, порог входа для DE - минимальный. Проекты плодятся как грибы.
Рекомендую как отличный пример:
Гайд по созданию Big Data-проектов в облаке: технологический стек, этапы и подводные камни