Me like, tnx

Наверное уместно эту беседу в скала чаты перенести

https://t.me/scala_learn

https://t.me/scala_ru

Ну а вообще какаянить circe юзает котов)

Есть ещё библиотечка тофу - она это тулинг вокруг тф, кото и зио зависимости есть

Scalaz не моден сейчас

Like thx me

Спасибо! Сорян, что слегка не по теме чата. Просто тут часто про скалу, что на автомате кинул вопрос

Проведите ликбез для меня 😁
В Pyspark ищу эффективный способ фильтрации супербольшого датафрейма big_df по полю из другого датафрейма (небольшого или среднего размера- до 10 тысяч записей) medium_df.
Оба датафрейма вытягиваются из паркет файлов из S3, никаких баз данных.

Моя идея перевести поле pids=medium_df.select("product_id") в список, потом этот список broadcast и потом фильтровать по нему
big_df.select(col1,col2,col3).where(big_df.product_id.isin(pids)). Будет ли это быстрее left join?

Хочется понять насколько хорош оптимизатор запросов и сможет ли он уменьшить количество shuffles.

Ребята, изучаю Flink. Много всего... А можете подсказать, если я собираю некий стэйт. Можно ли к нему обращаться именно sql-подобными запросами? Как бы в таблицу его абстрагировать.. или доступ по ключу только? Суть в том, что нужно по записям, у которых время записи + X (период ожидания), выполнять реакцию. Не перебирать же все хранилище...

а сча коты на 11 джаве или в 8 есть кроссбилд?

11

очень плохо, так как экосистема сейчас вся на 8 джаве

Ну касаемо апач хадуп стека, на 11 только недавно завезли хадуп

а я кстати не обращал внимания что коты на 11

но хайва нет к примеру

драйвер для вертики к примеру вышел для 3 спарка вот только недавно

Коллеги, всем привет!

Есть желание анализировать кликстрим по компании. Сейчас развернут Clickhouse под кликстрим, но пока еще есть возможность выбрать другие решения.

Общий продукт комплексный, состоит из множества микросервисов, кучи поддоменов, над каждым работает отдельная команда. В рамках каждого события существует довольно обширный контекст (к примеру, если клиентом А был куплен продукт X, то для итоговой аналитики важно знать и все параметры клиента А, и все параметры продукта X, чтобы строить метрики в самых разных разрезах).

У каждого сервиса набор атрибутов в контексте свой. К примеру, region у одного сервиса - это регион, с которого клиент зашел в веб, а у другого сервиса region - это регион, где клиент купил продукт. Команды по сервисам хотят иметь возможность сами добавлять атрибуты, но очевидно, что это может привести к коллизиям в названиях атрибутов.

Соответственно, возникают вопросы:
1) стоит ли весь кликстрим по всем сервисам писать в одну таблицу и пытаться как-то разруливать (путем контроля) проблемы с «похожестью» названий атрибутов?
2) если пишем в одну таблицу, насколько правильно, что для одного сервиса будут использоваться первая половина атрибутов, а вторая будет «пустой», а для другого сервиса первая будет «пустой», а вторая заполнена?
3) стоит ли плодить множество таблиц в кликхаусе (для каждого сервиса - своя, со своим набором атрибутов контекста)?
4) стоит ли вообще писать контекст (обогощать сам факт события) в таблицу с событиями или лучше для аналитики обогащать уже после записи, например, в отдельной базе через ETL процессы?
5) если хранить в разных таблицах (каждый сервис в своей), то насколько удобно/правильно потом будет проводить какую-то сквозную аналитику между сервисами?

Примерное кол-во сервисов (доменов) - 70
Среднее кол-во атрибутов в контексте - 100

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

Народ, а как в паркете называется аналог страйдов?

RowGroup?

если ты про stripe из орка, то в паркете это page

stride — минимальная пропускаемая единица )

orc.row.index.stride вот этой пропертью занимается