frog2

Рабочее

Датасаентистам на заметку:

groupby('index').sum() - использует cython

а

groupby('index').sum(axis=0) сваливается в python и при большом числе столбцов проигрывает в сотни раз.

колдовство уровня .agg(pd.np.sum) vs .agg(sum)

frog2

(no subject)

А я теперь EY работаю.

По этому поводу решил померить - в какой формат Pandas быстрее пишет\читает датафреймы.
На 100000 записей cо строками, числами и датами, сжатие отключено

```
format | time write | time read | size
csv | 4.112719535827637 | 1.0176215171813965 | 51.43MB
json | 0.7032690048217773 | 3.6434662342071533 | 68.03MB
avro | 14.251639604568481 | 8.565718412399292 | 25.78MB
parquet | 0.27165746688842773 | 0.2584848403930664 | 30.29MB
pickle | 0.27146458625793457 | 0.10584211349487305 | 28.61MB
```

Связано с тем, что AVRO строковый формат с возможностью хранения сложных иерархий, что влечёт за собой большие накладные расходы на переупаковку колоночных датафреймов.

Когда будет свободное время добавлю в него транспонирование что бы не отставать в бессмысленных соревнованиях.

frog2

СlickHouse

Решил тут погрузится в СlickHouse от Яндекса и для разминки задал простой для БД вопрос: Пускай у нас есть таблица числами (пускай натуральным рядом). Чему равна сумма чисел из этой таблицы - которых в ней нет (например сумма отрицательных)?

Обычно БД на такое честно отвечают NULL что в общем-то правильно.

Кликхаус отвечает 0, и это в общем-то правильно.

frog2

Рабочее

Уже год отработал в банке(TM).

И по этому поводу хочу сказать что все мейнстрим форматы передачи данных - плохи. На уровне железхок и байтосодомии - ASN.1 норм. Но как только хочется что то высокоуровневое передать - начинаются пляски с отображением абстракций либо в куцый JSON, либо в избыточный XML. Хотя, казалось бы, - для хорошего описания формата данных достаточно алгебрических типов, а для отличной - зависимых. Но вместо этого нескончаемым потоком создаются варианты ASN.1.

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



PS: XML-WSDL умеет многое, но практически никакая поддержка вне Java и килобайты XML на малейший чих заставляют страдать.
frog2

Система массового унижения.

Строю систему на 100500 микросервисах и питоне. Как обычно всё готовое - плохое и нужно делать своё.

План таков:

1) Для надежности - сервисы общаются через очереди Кафки - Послал и забыл (а если нужно вспомнить - пункт 3).
2) Что бы никто не шалил - очереди типизируются схемами Avro (пришлось в мейнтейнеры записаться и сделать чтоб работало).
3) Что бы распутать граф с циклами - каждое сообщение снабжается вариацией векторных часов, которые на самом деле не часы, а список UUID превращений, которые претерпело сообщение по пути на графе + тайминги начала\конца обработки.
3) Что бы мониторить - Из концевых вершин графа сообщения дублируются в агрегатор, который складывает Часы (которые не часы) в influxdb


Прототип этой красоты на рабоче-домашнем нуоте показывает 5-6 тыс сообщений\сек в 1 поток на каждый из 4 эзрац-сервиса.
frog2

В защиту питона.

В питоне мне нужны random и uuid - они есть в стандартной библиотеке и в 99.99% проектах в гитхабе люди их и используют.

А в хаскеле в https://hackage.haskell.org/packages/search?terms=random и вижу 158 рандомов. Беру Sytem.Random и расстраиваюсь из за скорости, пробую System.Random.Mersenne.Pure64 - вроде норм, но остается еще 100+ не проверенных

Или вот дата-время (питонячий datetime.dateime). Изобретать ли мне свой тип, или брать чужой(какой, их там штук 10)
frog2

О рисовании

Строю систему на микросервисах. Для передачи сообщений - кафка, т.е. pub-sub. Дополнительно жизнь усложняется циклами на графе и наличием нескольких (1-6) связей между компонентами

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

Фактически это "подпись" ребра с помощью дополнительной вершины.