Примерный алгоритм
 Если есть возврат с клиента , но нет продаж в этом периоде то этот возврат аллоцировать на продуктовую группу а если и там нет продаж то на  группу где есть этот клиент

т.е. в начале бежим по массиву - собираем все "потеряшки " на агрегаты
потом проходимся по потеряшкам и все распределяем

проблема только в том , что очень сильно не хочется писать тупые формулы для каждого индикатора , ну или хоть как то уменьшить эту боль

оконные функции + case when в основе решения, как генерализовать до произвольного показателя пока не понимаю, но вообще, если описать их как граф, то может получится выстроить формулу из вершин и связей

Это я, конечно, очень расплывчатый совет дал. Вообще, решения из чата надо рассматривать внимательно, ведь никто не в курсе постановки задачи. Понятно, что это пилот, но должно быть проектирование, аналитическая работа, не просто же так решили из одного сделать другое))

Всем привет! Подскажите пожалуйста касательно компрессии: есть одна таблица, размером 14тб, в неё ежедневно пишутся данные(один день - одна партиция). Формат - orc. Пишу спарком в директорию, не в хайв, использую snappy компрессию. Метрики по таблице строятся редко. Появилась идея переписать партиции из этой таблицы с уровнем компрессии zlib вместо snappy.
Вопрос: Может быть есть еще каки-то варианты сжатия, кроме этих двух, которые максимально сожмут орк и при этом оставят возможность читать данные через хайв? если получится освободить хотя-бы 1-2 терабайта, будет уже хорошо.

zstd?

bzip2 всё жмёт! Поддерживается ли в hive (версия?) не знаю

Вы главное сортируйте данные правильно перед записью в орк. Получалось уменьшать размер более чем в 3 раза.

+1

Подскажите пожалуйста, каким принципом руководствоваться?

Очень похожие данные (строки) друг за другом. К примеру, если это посещение сайта пользователями за день - то есть смысл сортировать по пользователю, т. к. часть данных(ip адрес к примеру) будет одинаково и сожмет лучше. Можете просто поэксперементировать с дневной партицией с разной сортировкой, что лучше сжимает то и оставляйте. Но принцип в целом тот же.

Премного благодарен, сейчас буду пробовать)

В общем оказалось все на много проще, это баг в текущей версии sparklig water если запускать на nightly релизе все работает как надо

версия пакету нужна не ниже чем 3.34.0.1-1.33-2.4, для 3 версии спарка к сожелению билда пока нету

Кто-нибудь знает причину, почему параметр shuffle partition нельзя устанавливать для конкретного запроса или его части, по аналогии с repartition/coalesce?  Мне кажется, это было бы гораздо удобней и гибче, чем для сессии

Интересный вопрос.Давайте обсудим.  Наример, вы установили для одного DS в 17, а для другого в 19, а потом их джойните.

сейчас параметр сессии так же можно установить после создания 1 DS и 2 DS, тогда применится последний. В этом случае тоже можно применить одно из правил: больше/меньше или последнее

а где его хранить тогда. это значение?

сейчас оно в своеобразной глобальной переменной. надо придумать куда его положить тогда вместо конфига и что бы в нужный момент оно там было.. и что бы этот нужный момент согласовывался с другими местами.

@pomadchin что-то новенькое