Добрый день. Помогите пожалуйста определиться - очень нужна рекомендация . У нас

кластер КХ 2 -> шарды + 4 реплики. (будет увеличен)

На кластере живут данные нескольких партнеров.

Источник данных - CRM система (MSSQL). данные загружаются по расписанию (каждые 20 минут - AirFlow + Python + MSSQLChangeTracker) - это ELT процесс. Сначала данные загружаются как есть в stage слой, затем трансформируются в витрины по расписанию. Каждый партнер имеет доступ только к своим данным в витринах (Row Level Security)

Поверх витрин висит SuperSet - для визуализации данных. И это все работает и проблем нет.

Проблема в том , что некоторые партнеры хотят забирать свои данные во внешние BI системы.

Данных достаточно много для того чтобы подвесить кластер на этапе выборки неаггрегированных данных ну например за месяц. Сейчас самая большая таблица - около 5 млрд записей и данные растут экспоненциально.

Посоветуйте пожалуйста - стоит ли тюнинговать КХ для выборки большого количества неаггрегированных данных наружу кластера, либо выбрать сторонние решения для внешних интеграций? Наша компания готова вкладываться в новое железо - ограниченно ))

Пока стоит вопрос между ХД для внешних интеграций на основе Hadoop либо key-value СУБД - например kassandra.

Выгружаете на С3 сырые данные, пусть партнер играет как хочет с ними

А для чего грузить целый месяц, если можно выгружать чаще? Почему нельзя отправлять им агрегаты? Если в лоб решать поставленныю проблему, то вы упретесь в сеть рано или поздно

Партнеров достаточно много для того чтобы создавать витрины для каждого. Это очень затратно. И еще - инициаторами выгрузок должен быть партнер, не мы

Создавать топики в кафке, сливать туда данные, а партнёры пускай собирают, но раз в месяц это явная боль

Для этого retention policy на Кафке нужно задрать до пары месяцев , это капец как много ))

Верно, но и клик всё-таки не брокер сообщений) Если инициатором должен быть партнёр, то можно считать, что в любой момент времени у вас клик встанет по передачи по сети/диску..., какие бы вы параметры не подтянули

1. теоретически кликхаус вроде подойдет для скана больших диапазонов данных и выгрузки их. Не вижу архитектурных причин почему он не прокатит. Мб кто поправит ? 2. если клиенты хотят забрать данные себе, то что кассандра тут в списке делает ? В ней базово нет опции скана диапазона ключей, т.к. все данные распределяются по шардам через мурмур хеши в LSM tree => у вас не будет индекса, по которому можно просканить диапазон. Мб есть специфичные опции, о которых я не знаю. Но базово не понятно как тут поможет любой keyvalue. 3. хадуп - хз Яб попробовал отдавать из кликхауса, если перфоманс тесты не пройдет. то сделал бы отдельную скульную базу(B-tree для скана клиентами), GRPC нтерфейс и пусть играются)

Егор, спасибо за замечание по key-value. Согласен. Сейчас 1 месяц данных ~ 100 Гб разжатых данных. Это среднее по больнице конечно. С отдачей такого объема сжатых данных из КХ возможно даже не стоит проводить тестирование - процессор улетит в потолок. Выходит S3 по совету @simpl1g - если других идей нет

выгрузка на S3 сейчас стандартная практика у многих SaaS решений. Сейчас это движется дальше и появляются опции автоматический выгрузки отчётов в Snowflake например. Кассандра вообще не понятно как в вашем списке очутилась. Кафка слишком геморно. Хадуп тоже не у всех есть + настроить его это надо постараться

Если у вас четыре реплики, нельзя ли одну из них отвести для отдачи данных? Ну или сделать пятую ;) Кажется, что все иные подходы либо ведут к потере качества сервиса, либо вынуждают сочинять middleware.