Комментарии 16
Мне очень странно видеть выбор не-кликхауса. В целом, с операторской точки зрения, у меня к нему одна претезия — плохо в маленькой памяти работает. Всё остальное настолько хорошо, насколько можно. Плюс, колоночное сжатие, от которого диску легчает.
Колоночное сжатие есть и в GP =) Все-таки полноценного ANSI https://clickhouse.tech/docs/ru/sql-reference/ansi/ нашим дата-инженерам в клике не хватает, поэтому он не для всех задач подходит. Сейчас тестируем его для быстрых слоев витрин, поделимся выводами, когда закончим
Попробуйте ETL на не сделать
Сейчас для таких задач у нас есть S3, туда мы сливаем необходимые данные из кафки, а потом уже спарком их обрабатываем и сгружаем в GP.
т.е. что бы начать анализ новых данных, вам надо пройти все квесты с очисткой и интеграцией этих новых данных в dwh и только после этого тянуть из dwh на анализ, где выяснится…
Основной экономический эффект дают продукты, созданные после появления платформы, т.н.дата-продукты. В больших компаниях внедрение даже крошечных оптимизаций и нововведений может приносить огромную прибыль (экономию). Конкретные цифры называть не могу, но могу сказать, что несколько наших дата-продуктов экономят компании несколько сотен миллионов рублей в год.
Эмм, те вы делали такую сложную платформу без понимания конечных инструментов и потребностей. Звучит странно. Те инженерам дали просто поиграться в технологии?)
«Основное влияние на производительность GP оказывает скорость дисковой подсистемы, в первую очередь — IOPS».
1. Ну не IOPS все же, а от скорости сканирования данных. Это разные понятия. Просто особенности облачной инфраструктуры таковы, что нарезая маунт в облаке, облачный провайдер ставит в прямую зависимость скорость и IOPS от размера маунта.
2. То что скорость GP зависит от скорости фулскана — известный факт. И тестировать тут было нечего. GP пока не умеет фильтровать данные на storage уровне (типа storage index) и любой запрос не попадающий под условие секционирования и индексирования всегда будет идти как fullscan. Поэтому чем быстрее диски или больше шпинделей тем выше скорость GP. Именно это все вендоры GP и проповедуют. Альтернативный подход — быстрые CPU и сжатие по максимуму (меньше сканируем, быстрее разжиамем). Ситуация изменится когда Tanzu впилят наконец фильтрацию на сканировании.
«Производительность кластера в облаке с большим количеством маленьких виртуалок выше, чем с малым количеством больших – лучше взять 18 виртуалок по 5 сегментов на каждой, чем 5 виртуалок по 18 сегментов.»
Ну это опять таки про скорость сканирования.
Если не ошибаюсь, то вы живете в облаке Яндекс. У них появилась возможность делать 6 маунтов на узел в IaaS. Пробуйте.
110TB это было с учетом мирроров. Сейчас у нас на ноду 10TB HDD + 10TB SSD, и весь кластер суммарно уже на 440TB вышел. Расточительство хранить сырые данные в GP, нужно укалдывать все 110 TB с компрессией полезными данными ODS/DDS.
В Я.Облаке в 19 году этой фичи не было, да и диски у нас максимального размера - 4TB, т.е. никаких зарезаний по дисковому QoS со стороны самого облака точно не было. Плюс, нужно понимать, что диски в облаке сетевые и живут не рядом с виртуалками и любой запрос в GP (обращение к диску) идет в сеть между гипервизорами и стораджем. Так что тут тесты были нужны, чтобы понять максимальные возможности сети яндекс облака. После этого мы начали запрашивать от Я.облака ускорение дисков, в прошлом году появились NRD диски - прирост производительности составил ~20%. Мы купили производительность за счет снижения надежности. Сейчас же у нас инсталляция живет на выделенных хостах с локальными дисками - там все намного лучше, чем на сетевых и NRD, получили мы в итоге порядка +50% производительности дисков в сравнении с 4TB сетевыми SSD.
Фуллскан - да, но в нашей железной инсталляции мы увидели, что на HDD (шпиндели) диски в RAID10 со скоростью чтения 4ГБ/с запросы работали ощутимо медленнее SSD с той-же максимальной скоростью чтения, но ощутимо большими IOPS. Среднее время выполнения мелких запросов по витринам и справочникам упало с ~16с до ~4c. Плюс хранение pg_catalog на SSD, что повышает общую отзывчивость базы. Сейчас у нас 2 тейблспейса в GP - дефолтный на SSD и теплый на HDD.
6 сетевых дисков в облаке пробовали - прироста не выявили, похоже упирались в сеть между гипервизорами.
Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей