Хорошее исследование и статья, спасибо! Интересно, что везде мониторинг по CPU usage показывает полку в 93 процента где-то (думаю это из-за. vm.overcommit_ratio). Интересно бы поувеличивать ресурсы и посмотреть как будет отличаться разница в производительности. В целом видел рекомендацию вроде от amazon (внезапно), что лучше в облаках (где всегда HT) брать соотношение 1 сегмент - 4 vCPU. Надо поискать ссылку.
В целом Hadoop - вещь не для всех :) Лучше с S3 начать для хранения. На мой взгляд в облаке Hadoop можно использовать для обработки данных (Spark, Hive).
А какие минусы использования Hadoop в облаке? Интересно синхронизироваться)
Всё-таки ClickHouse лучше работает с большим количеством подключений. Поэтому я бы начинал с Greenplum, а дальше при необходимости выносил нагрузку с витринами данных в ClickHouse. Также раньше BI вроде Power BI, Tableu и Click подгружали периодически данные в себя и визуализация строилась из загруженных данных в своё хранилище. А вот Superset и Redash работают только по модели Direct Query и каждое изменение параметра в визуализации может создавать нагрузку на КХД. Когда её слишком много, лучше использовать промежуточный ClickHouse. В конечном итоге я бы оставил ELT и хранилище в Greenplum, все данные в нормальной форме начиная с 3-ей. А вот в ClickHouse витрины в максимально плоском виде.
По сути docker-compose включает в себя указанный контейнер + ещё несколько (redis, postgresql и ещё несколько). Это делает её более приближенной к продуктовой инсталляции, когда может быть отдельная инсталляция Redis для хранения кэша, отдельная инсталляция PostgreSQL для хранения метаданных. Детальные отличия лучше всего понять изучив docker-compose файл: https://github.com/apache/superset/blob/master/docker-compose.yml
Отличная статья, спасибо! Было полезно почитать: есть примеры, разбор того, что происходит на уровне файлов. Плюс написано понятным языком!
Хорошее исследование и статья, спасибо!
Интересно, что везде мониторинг по CPU usage показывает полку в 93 процента где-то (думаю это из-за. vm.overcommit_ratio). Интересно бы поувеличивать ресурсы и посмотреть как будет отличаться разница в производительности. В целом видел рекомендацию вроде от amazon (внезапно), что лучше в облаках (где всегда HT) брать соотношение 1 сегмент - 4 vCPU. Надо поискать ссылку.
Есть S3, Hadoop, Greenplum, ClickHouse, Kubernetes. Дальше уже выбор зависит от компетенций, задачи, объёма данных, структуры данных.
Согласен! Не сравнивал бы Greenplum и Datalake на S3/HDFS, всё под свои задачи.
Такое решение предлагали, но для заказчиков требования оказываются довольно высокими к техническим компетенциями: spark, kuber.
Спасибо за развёрнутый ответ!
Сейчас выбор ограничен)
Power BI - крутой инструмент, люблю его.
В целом Hadoop - вещь не для всех :) Лучше с S3 начать для хранения. На мой взгляд в облаке Hadoop можно использовать для обработки данных (Spark, Hive).
А какие минусы использования Hadoop в облаке? Интересно синхронизироваться)
Всё-таки ClickHouse лучше работает с большим количеством подключений. Поэтому я бы начинал с Greenplum, а дальше при необходимости выносил нагрузку с витринами данных в ClickHouse.
Также раньше BI вроде Power BI, Tableu и Click подгружали периодически данные в себя и визуализация строилась из загруженных данных в своё хранилище. А вот Superset и Redash работают только по модели Direct Query и каждое изменение параметра в визуализации может создавать нагрузку на КХД. Когда её слишком много, лучше использовать промежуточный ClickHouse.
В конечном итоге я бы оставил ELT и хранилище в Greenplum, все данные в нормальной форме начиная с 3-ей. А вот в ClickHouse витрины в максимально плоском виде.
По сути docker-compose включает в себя указанный контейнер + ещё несколько (redis, postgresql и ещё несколько). Это делает её более приближенной к продуктовой инсталляции, когда может быть отдельная инсталляция Redis для хранения кэша, отдельная инсталляция PostgreSQL для хранения метаданных.
Детальные отличия лучше всего понять изучив docker-compose файл: https://github.com/apache/superset/blob/master/docker-compose.yml