Комментарии 6
Не совсем по теме, но по примеру. Иногда покупатели разбивают одну покупку на несколько чеков (оплата с разных карт, повторный заход в магазин, так как что-то забыли, ребенок на кассе что-то тянет к покупке, а вы уже в процессе оплаты). Полагаю, такие чеки можно объединять в один виртуальный.
"В Клик загружается, так сказать, широкая таблица с транзакциями. Копия этих данных сохранена в HDFS для Спарка. "
Время загрузки данных в КХ какое?
ТСО считали? Сколько вам стоит содержать КХ рядом с Hadoop?
Ведь внезапно может выясниться, что поставив рядом с Hadoop кластером кубер кластер в котором вы поднимите Impala или Trino, будет выгоднее с тз cost per performance, да еще и данные переливать никуда не надо будет.
"Время загрузки данных в КХ какое?"
Время загрузки в КХ является крайне не существенной величиной. Да, первоначальное наполнение требует ощутимого времени. Но ежедневно загружаются только последние данные - чеки за последний день и возможные долёты в глубине пары недель. Непосредственно дозагрузка чековых транзакций длится порядка получаса в утренние часы, и происходит она прозрачно для сервиса, который работает с Кликом.
"ТСО считали? Сколько вам стоит содержать КХ рядом с Hadoop?"
Короткий ответ - цена приемлемая.
Стоит уточнить, кого следует иметь в виду под "вам". Железный кластер Hadoop - это слишком дорогая игрушка, развитием и поддержкой которой занимается вся корпорация во благо множества продуктов, среди которых и CVM, у которого возникла потребность в сервисе гибких фильтров. Таким образом, для решения задачи есть две опции: использовать облако, либо закупать отдельные сервера. Цена и уровень поддержки в облаке для бизнеса, стоящего за CVM - более чем приемлемы как сейчас, так и особенно в период проведения RnD.
"Ведь внезапно может выясниться ... рядом с Hadoop ... кубер кластер"
Полагаю, что такого волшебства не случится. В ходе сравнения Spark vs ClickHouse было выявлено, что важным фактором, влияющим на скорость выполнения метода, оказалось время чтения из HDFS. Полагаю, что Spark, нативно запускаемый в кластере, имеет большую Data Locality (близость к данным), чем что-либо во вне кластера. Таким образом, любой процесс, запущенный на удалённых от HDFS машинах, будет ещё дольше ждать нужных данных.
Со спаром то все понятно. Чудес не бывает :)
В вот указанные мною движки читают из Parwuet HDFS только то что удовлетворяет условию запроса (динамические фильтры + parquet storage index + parquet page index). Те они не будут понимать в compute среду весь массив, а будут поднимать только то что нужно для получения результата на выходе. Поэтому и работают то быстрее спарка в очень многих задачах на порядок быстрее. Можно полагать, а можно и проверять.
Что такое цена приемлема? Любое вычисление имеет свою стоимость.
Про облако вы хорошо упомянули. Все современные облачные вычисления как раз и основаны на разделении storage и compute и никакой data locality и тем более bring calculations to data нет и в помине/
В моём понимании приемлемая - это цена, не выделяющаяся от содержания прочей обширной инфраструктуры, которой обладает продукт. ;) Да, возможно, другие движки покажут более эффективный результат, но это вопрос к будущим исследованиям.
В любом случае, спасибо за информацию и совет - обязательно более пристально присмотрюсь к движкам, вроде Impala. В следующий раз будет более широкий выбор решений.
ClickHouse в ритейловом проекте