Комментарии 11
Для начала:
Cubes - OLAP Framework
https://pythonhosted.org/cubes/
Спасибо за статью. На мой взгляд золотые времена OLAP прошли, теперь это не воспринимается как чудо-технология. Дaже в pandas/numpy не стали развивать и таки-выпилили многослойные таблицы (по сути тот же OLAP), логично предположив что многоуровневая индексация (pd.Multiindex) нагляднее и проще в восприятии (она легко визуализируется в плоскую таблицу, просто купите монитор пошире).
TinyOLAP действительно заброшен, в свежей среде он не запустится (нужна env) и это сильно ограничивает энтузиазм. В то же время новый движок DuckDB - очень перспективен, поражает скоростью работы, примиряет адептов Pandas и SQL за счет равнозначно удобного использования лучшего из двух миров. К.м.к. это и есть замена OLAP. поскольку поколоночное, а не хранение "измерений", дает наибольшую скорость в i/o и вычислениях, в т.ч. в RAM.
Спасибо, посмотрю, что за «зверь»
Вы знаете, совсем не соглашусь, я пока за всю свою практику гибче и удобнее инструменты не находил.
Естественно можно накидать сложные дашборды и т.д, но с точки зрения гибкости и скорости, то найти сложно ( + само понятие self service)
Пока вижу, как наилучшее решение прикручивать CH и Утку как ядро аналитическое.
Есть очень интересное решение kylin (на текущий момент часть этого продукта - динозавр от яндека), и его старший брат - уже корпоративный продукт.
Но так и не хватило терпения его запустить полноценно.
Верно пишете, симбиоз ClickHouse для "болота" и DuckDB для "аналитической" БД - об этом говорят аналитики на каждом углу, семинаре и даже там, у них. Зрелые, ультимативно быстрые инструменты.
Добавлю что все это нужно обязательно "обмазать" оркестратором из тех что попроще (Dagster) или престижнее (AirFlow).
Но при этом нельзя не уходить с максимально отзывчивых инструментов (JupyterLab + Pandas), поскольку возвращаться к ним приходится буквально еженедельно даже в хорошо отлаженных конвейерах (мир меняется слишком быстро).
Обмен py-скриптами между Pandas и оркестратором (и многим другим) - легко организуем в обе стороны парой простых UDF, все никак не допишу статью об этом сюда. Можно сказать что озвученный программный стек наконец-то ознаменовал собой завершение "поиска идеала" (шучу, это неизлечимо в отрасли). Но чувство надежности выросло.
Вроде в clickhouse можно в OLAP
Да, ClickHouse специализируется на аналитической обработке. Возможно, ее можно использовать в связке с OLAP.
Если воспринимать природу OLAP как способ хранения (измерений) и способ организации данных - то он реализуем в любой БД и ее суррогатах (встраиваемые БД, Excel, TXT-файлы).
Колоночные хранилища перевернули страницу OLAP как самостоятельной технологии: прирост скорости колоночных БД полностью нивелировал все плюсы OLAP. Теперь OLAP это заурядный, один из видов анализа по срезам.
Для максимизации скорости отборов (напр. для дэшборда) - нужно десять раз подумать и проверить что "быстрее": хранить аналитическую БД строками, колонками, измерениями OLAP, с крутыми индексами итд. Готовых рецептов нет, потому что действия юзеров хаотичны и непостижимы.
На практике IN MEMORY данные с булевыми готовыми колонками (после one hot encoding) в той же Pandas часто оказываются самыми быстрыми, но нужно много RAM.
Как быстро собрать кубик для простых задач: играемся с TinyOLAP