Как стать автором
Обновить
21
0
Генрих @Ananiev_Genrih

аналитика и визуализация данных

Отправить сообщение

Вопрос на миллион: что с производительностью, каким движком выполняется проверка? Если там под капотом а-ля пандас, то возможно на игрушечных датасетах - норм. А на нагрузке как все это у вас работает? Успевают данные прокачиваться в регламентные окна при этом DQ?

Спасибо за статью.

Насколько это решение применимо в классификации для такого рода задач когда классов трейнсета примерно 70000, документов (текстовых наименований продукции ) в среднем по 4 на класс (т.е. документов около 300_000 в трейне) ?

Это пример из реальности где я в том числе делал стемминг https://habr.com/ru/articles/658501/

Статья хорошая и сервис получился интересный, видно что ваша команда вложила силы и душу в проект. Не понятна только цель у вашего заказчика. Получить многопользовательской файловый data swamp чтобы потом утонуть в нём же?

Или что еще ближе к реальным бизнес задачам: прогноз разом N временных рядов с выбросами, пропусками (включая множественные последовательные), с разными длинами ряда и разной природой трендов и сезонности. А так получилось: смотрите на еще +1 библиотеку прогнозирования

В процессе приложения можно SQLite3 загрузить и пользоваться SQL для обработки. CSV грузит быстро, типы данных на уровне полей сохраняет, так что можно менять на лету, работает очень быстро.

Тогда уж DuckDB

Для ответа на ваш вопрос надо получить доступ именно к вашим исходным файлам и запускать код на вашей же машине. Будет точно быстрее лучшего результата не только за счёт отсутствия "джава-оверхеда", но и за счет использования более оптимальных библиотек чтения/записи (на плюсах, а там уже вызов хоть из питон хоть из R, не так важно, к обоим написаны).

Тут не про критику (если вы так это воспринимаете), а про то что у всех лоу-код есть границы применимости ограничивающие их масштабирование, и чем дальше нырять за такие границы тем будут страшнее велосипеды

С одной стороны хочется похвалить автора (всего месяц и без единой строки кода решает такие задачи, да еще бенчмарки и оптимизацию проводит), с другой - сильное ощущение что автор чем-то не тем занимается и вот здесь как раз бы Питон и R с удовольствием бы "пострадали", решив эту задачу в несколько потоков в несколько раз быстрее на том же железе

И с tune race ANOVA неплохо было бы сравнить по скорости (не знаю есть ли в python)

Ошибки начинающего аналитика при обработке данных на Python: учить пандас на табличках 3*33 вместо производительного и современного polars/pyarrow и потом на реальных бизнес задачах плакать натягивая свой пандас_код на даск

Твоего перечисленного стэка хватит с лихвой лишь на ETL и BI. То что ты забросил R и хорошо и плохо одновременно: в R есть всё необходимое для анализа данных , и каждый из этих тулзов гораздо производительнее и не менее функционален чем в python (а зачастую - более). Но если смотреть на рынок труда то питон у работодателей востребованней в анализе данных : заслуга чисто за счёт всей оставшейся инфраструктуры (бэкэнд, web, etc) на нём же.

Реально, это уже стандарт, стандарт просто так уже не умрет.

Если что, статья от Веса Маккини, создателя пандас

Apache Arrow and the "10 Things I Hate About pandas"

а здесь можно полюбоваться на горячо_любимый_пандас в бенчмарках от h2o

https://h2oai.github.io/db-benchmark/

надеюсь панда умрёт от старости в скором будущем освободив поляну для polars/arrow/DuckDB

Спасибо за статью. У нас прогнозирование идет по датам и в лаги идет продажа в тот же день недели но из прошедших недель. Ну то есть для даты пятницы LAG-1= пятница прошлой недели, LAG-2 = пятница позапрошлой и т.д. до LAG-4.

Прогнозирование требуется с горизонтом до последней даты следующего месяца так же по датам (т.е. от 4 до 9 недель вперед в зависимости от того в какую дату запускаю модели)

Пробовал рекурсивный подход - ошибка прогнозов копилась в лагах и нехорошо влияла на следующие итерации. В итоге вернулся к прогнозу за один шаг одной моделью но с таким сдвигом лагов чтобы их хватило покрыть весь горизонт прогнозирования из прошлого факта.

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

Видно что при таких лагах начало каждого временного ряда (1 TS=1 продукт) остается пустым но градиентный бустинг на это не жалуется потому что есть еще доп.предикторы на весь временной ряд (средняя всех сред, сигма всех сред, медиана всех сред, средняя всех сред категории этого продукта, медиана всех сред категории этого продукта и т.д.)

В итоге получаю прогноз на 1-2 месяца вперед (в зависимости от даты запуска) за одну итерацию без рекурсивного прогнозирования и одной моделью. При этом пропуски в лагах модель не смущают и сами лаги по Feature Importance занимают далеко не последнее место.

Куда вписывается такая стратегия?

не хочется отвечать здесь ибо оффтоп, но если кратко: крутить в сводной 60-80млн без особых тормозов на 8гб оперативки достаточно для локальной книги Excel с Power Pivot, главный секрет - никаких плоских портянок, только схема "звезда" с большими (план)фактовыми таблицами в центре из одних чиселок (ID+фактовые числа максимально стараться в Integer8/32/64 + расчетные меры на DAX) и текстовые справочники вокруг (Dimensions). В пределе терпимо крутит даже 100млн локальной книги на "звезде" . Табулярные модели у нас на SSAS серверах (перешли на них с OLAP кубов) >2 млрд.записей ритейл данных (уже агрегированных) в моменте обслуживают до 150 пользователей с клиентскими подключениями сводных табличек в Excel + юзеры из PowerBI с DirecrQuery коннектами к той же "модельке". А вообще таких решений у нас много (под каждый департамент)

а не plotly с его тысячей параметров.

На практике все 1000 параметров мало кто использует ни в plotly ни в LightGBM ни где либо еще (всегда есть топ Х "фичей" инструмента по макс.востребованности, остальное - частные случаи). К примеру ничто не мешает запустить linechart с 2-мя аргументами XY так же как и в plot(), НО тут же под рукой все остальное чтобы добавить и красоты и фасетов по +1 атрибуту и тултипов если надо.

Вот почему в 98% проектов с Polars и Arrow мы неизменно найдем остаточные следы Pandas

Под капотом там мало общего с pandas , как раз из-за такой разобщенности механизмов и виден прирост производительности в сравнении с pandas (с его numpy и Blockmanager). Собственно сам Вес Маккини и пишет о том что из-за такой огромной разницы он не видел способов изменить "легаси"-код pandas настолько кардинально, поэтому родился arrow (и впоследствии polars, так же использующий arrow - но не pandas).

Мне кажется народная популярность pandas сейчас не только в Ваших аргументах, а больше из серии "сначала ты работаешь на свою популярность а потом популярность работает на тебя". То есть сначала для обработки табличных данных не было в python альтернатив, пришел pandas и занял свою нишу, создал "вау"-эффект в свое время, сообщество начало впиливать в него куски какой то статистики и визуализации (ибо на то время что-то нормальное только зарождалось параллельно), потом он достиг пика популярности и на вершине славы остановился с точки зрения тех.развития.

Теперь, все курсы аналитиков /сайнтистов содержат pandas (назовите хоть один без него), студенты сдают проект на нем, приходят джунами указав его в резюме, дорастают до мидла на нем, как случаются неизбежные затыки - одна часть идет на поклон к вечно загруженным дата-инженерам перекладывать РАЗОВУЮ задачу в Airflow/Spark/... , другая часть пытается натянуть pandas на dask, но все равно использовать pandas.

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

В 2023 году данных для анализа даже у рядового аналитика стало существенно больше чем в 2008 когда pandas создавался, и все что смогли в pandas за это время - натянуть его на dask (со своими особенностями и новыми требованиями к железу).

метод .plot() с разными бэкендами для графиков.

Я не то чтобы придираюсь, но и это мне видится никаким не плюсом - не понятно зачем в него понапичкано всяких читалок к БД, корреляций и каких-то там методов .plot. Это как автор данный статьи его обозвал "швейцарский нож" в котором понапихано все, но каждый элемент хуже чем его аналог в отдельности.

Хочешь полноценный инструмент доступа к БД - есть sqlAlchemy, хочешь нормальный перечень стат.методов - есть scipy, хочешь полноценной визулизации - есть seaborn & plotly, хочешь быстрой обработки табличных данных - уже писал выше по пакетам.

А делать все, но на "на минималках", мне кажется уже не тот век для полноценной работы с данными.

PS про индексы стало интересно, в чем их "+" в пандасе? Особенно учитывая что разработчики arrow, polars и data.table считают их "злом" и давно отказались от них, и даже автор статьи на простом кейсе предупреждает новоиспеченных аналитиков:

Что-то не так с индексами, попробуем создать pivot с индексами по городам, а не регионам

Согласен. Уже 15 лет прошло а с этими пандасом все носятся как с писанной торбой. Даже сам разработчик pandas Вес Маккини писал Apache Arrow and the "10 Things I Hate About pandas"

Есть куча инструментов позволяющих гораздо большие объемы данных крутить значительно быстрее и комфортнее чем pandas на том же железе. Приходилось крутить сводными табличками по 60-80 миллионов записей в Excel'вском Power Pivot (лимит в 1 миллион строчек Excel тут не преграда) +комфортная low code etl предоработка в том же Excel'вском Power Query- на таких объёмах разница на том же железе была не в пользу pandas . А есть еще и колоночные СУБД типа DuckDB- зверь похожий на Clickhouse с API под Python и R. (На DuckDB приходилось анализировать на локальной машине 150 csv файлов общим весом более 10Gb предварительно перегнав их в в parquet, и настолько приятно что даже помыслов не было поюзать в таком кейсе пандас). А есть еще (py)arrow, которую продвигает Маккини как замена pandas. И помимо субд в том же python такая библиотека как polars легко обойдет pandas на любых операциях.

Ниже по ссылке бенчмарки производительности основных инструментов которые периодически проводит H2O ,так же интересно как обходит пандас R'вский пакет data.table (которым тоже часто пользуюсь), ну и Julia удивила.

Database-like ops benchmark

И бонус: если у вас в качестве источника csv или паркет - можно приятно крутить данные на чистых сводных таблицах (drag & drop) с DuckDB в качестве движка под капотом - TED

Спасибо за статью, но Вы как-то очень бегло упомянули TabNet, хотелось бы больше сравнения с прямым "конкурентом" а не с random forest

TabNet: The End of Gradient Boosting?

TabNet. Немного деталей

зашел прочитать про новый вид "многофакторного кластерного" анализа, ушёл - неудовлетворенным.

1
23 ...

Информация

В рейтинге
5 364-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Data Analyst, BI Developer
Lead