Или что еще ближе к реальным бизнес задачам: прогноз разом N временных рядов с выбросами, пропусками (включая множественные последовательные), с разными длинами ряда и разной природой трендов и сезонности. А так получилось: смотрите на еще +1 библиотеку прогнозирования
В процессе приложения можно SQLite3 загрузить и пользоваться SQL для обработки. CSV грузит быстро, типы данных на уровне полей сохраняет, так что можно менять на лету, работает очень быстро.
Для ответа на ваш вопрос надо получить доступ именно к вашим исходным файлам и запускать код на вашей же машине. Будет точно быстрее лучшего результата не только за счёт отсутствия "джава-оверхеда", но и за счет использования более оптимальных библиотек чтения/записи (на плюсах, а там уже вызов хоть из питон хоть из R, не так важно, к обоим написаны).
Тут не про критику (если вы так это воспринимаете), а про то что у всех лоу-код есть границы применимости ограничивающие их масштабирование, и чем дальше нырять за такие границы тем будут страшнее велосипеды
С одной стороны хочется похвалить автора (всего месяц и без единой строки кода решает такие задачи, да еще бенчмарки и оптимизацию проводит), с другой - сильное ощущение что автор чем-то не тем занимается и вот здесь как раз бы Питон и R с удовольствием бы "пострадали", решив эту задачу в несколько потоков в несколько раз быстрее на том же железе
Ошибки начинающего аналитика при обработке данных на Python: учить пандас на табличках 3*33 вместо производительного и современного polars/pyarrow и потом на реальных бизнес задачах плакать натягивая свой пандас_код на даск
Твоего перечисленного стэка хватит с лихвой лишь на ETL и BI. То что ты забросил R и хорошо и плохо одновременно: в R есть всё необходимое для анализа данных , и каждый из этих тулзов гораздо производительнее и не менее функционален чем в python (а зачастую - более). Но если смотреть на рынок труда то питон у работодателей востребованней в анализе данных : заслуга чисто за счёт всей оставшейся инфраструктуры (бэкэнд, web, etc) на нём же.
Спасибо за статью. У нас прогнозирование идет по датам и в лаги идет продажа в тот же день недели но из прошедших недель. Ну то есть для даты пятницы 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 коннектами к той же "модельке". А вообще таких решений у нас много (под каждый департамент)
На практике все 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 с индексами по городам, а не регионам
Есть куча инструментов позволяющих гораздо большие объемы данных крутить значительно быстрее и комфортнее чем 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 удивила.
И бонус: если у вас в качестве источника csv или паркет - можно приятно крутить данные на чистых сводных таблицах (drag & drop) с DuckDB в качестве движка под капотом - TED
В статье все было бы прекрасно если бы автор просто применял фильтр Хэмпла к одномерной выборке а не к временным рядам.
Временной ряд обладает такими свойствами как тренд, сезонность (суточная, еженедельная, месячная, ...), и подверженность экзогенным факторам, таким как например промоакции, скидки в цене, знаковые события (черные пятницы, кубки мира, рождество,...), отсутствию товара на складе и каннибализациям по конкурентам. Хорошо что автор не занимается прогнозированием, иначе пришлось бы рассказывать рассерженным стейкхолдерам что в виновен в "аутоффстоке" (и упущенной выгоде бизнеса соответственно) не автор а фильтр Хэмпла.
Почему именно 3? Потому что этого с лихвой хватит для нашего временного ряда.
Спасибо за отличное настроение))
Мы считаем, что данные подчиняются распределению Гаусса, поэтому берём коэффициент равным 1,4826.
Если раскрыть аббревиатуру OLAP - online analytical processing. Т.е. это не технология, а парадигма хранения данных для работы с ними, это антоним OLTP (которя тоже не про технологию а парадигму).
То есть по большому счету пофигу что там под капотом, классический многомерный MDX куб с агрегатами или табулярная модель на основе колоночной аналитической СУБД, и то и другое это OLAP. Так что автор комментария выше прав, OLAP никуда не ушёл, он просто поменял тех.стек. Тот же Microsoft (о котором почему-то не упомянул автор статьи) являясь крупнейшим в мире поставщиком OLAP в аналитике (=доля рынка SQL Server Analysis Services в сравнении с оракловыми и IBM решениями+доля рынка Excel в котором Power Pivot уже на борту+ Power BI) - и тот отказался от развития классических многомерных кубов в пользу колоночных решений, но при этом это все еще OLAP.
В верхнем ряду временное прекращение поставок делает характер спроса гораздо более прерывистым, чем это есть в действительности – получаем сильный недопрогноз. Внизу пример того, что в юридической литературе называется внешними обстоятельствами непреодолимой силы
Я не знаю, есть ли серебряные пули от всех этих корнер-кейсов. Скорее всего, решение каждой этой проблемы потребует от вас построения системы, по сложности и громоздкости сравнимой со всей остальной архитектурой прогноза.
У себя решил, выдумав термин (хотя скорее всего уже до меня его выдумали) : "граница смены поведения ряда". Реализовал на этапах препроцессинга поиском максимальной правой значимой границы смены поведения и отрезанием ряда по этой границе : в прогнозирование идет конечная правая часть а левая - в мусорку. Ищу крайне просто по типу как задача в начальной школе "2 поезда поехали из пункта "А" и "В" навстречу друг другу, где встретятся? Только вместо поездов у меня скользящие сигмы (с окном 21 день) которые едут по временному ряду навстречу (один с конца в начало, другой от начала в конец) . 3-м вектором считаем отношение по этим двум, значимым переходом состояний считаем превышения фикс.% по модулю . Например в точке t сигма_1 отличается от сигма_2 на 85% (не важно в какую сторону) но это выше фикс. Х% порога - явно переход поведения ряда.
На все про все - 30 строк кода на R (так много за счет доп.тюнинга типа не резать границу если уж очень короткая часть останется а поискать границу чуть раньше)
Жаль нет сравнения с https://etna.tinkoff.ru/
Или что еще ближе к реальным бизнес задачам: прогноз разом N временных рядов с выбросами, пропусками (включая множественные последовательные), с разными длинами ряда и разной природой трендов и сезонности. А так получилось: смотрите на еще +1 библиотеку прогнозирования
Тогда уж 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 коннектами к той же "модельке". А вообще таких решений у нас много (под каждый департамент)
На практике все 1000 параметров мало кто использует ни в plotly ни в LightGBM ни где либо еще (всегда есть топ Х "фичей" инструмента по макс.востребованности, остальное - частные случаи). К примеру ничто не мешает запустить linechart с 2-мя аргументами XY так же как и в plot(), НО тут же под рукой все остальное чтобы добавить и красоты и фасетов по +1 атрибуту и тултипов если надо.
Под капотом там мало общего с 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. Это как автор данный статьи его обозвал "швейцарский нож" в котором понапихано все, но каждый элемент хуже чем его аналог в отдельности.
Хочешь полноценный инструмент доступа к БД - есть sqlAlchemy, хочешь нормальный перечень стат.методов - есть scipy, хочешь полноценной визулизации - есть seaborn & plotly, хочешь быстрой обработки табличных данных - уже писал выше по пакетам.
А делать все, но на "на минималках", мне кажется уже не тот век для полноценной работы с данными.
PS про индексы стало интересно, в чем их "+" в пандасе? Особенно учитывая что разработчики arrow, polars и data.table считают их "злом" и давно отказались от них, и даже автор статьи на простом кейсе предупреждает новоиспеченных аналитиков:
Согласен. Уже 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. Немного деталей
зашел прочитать про новый вид "многофакторного кластерного" анализа, ушёл - неудовлетворенным.
В статье все было бы прекрасно если бы автор просто применял фильтр Хэмпла к одномерной выборке а не к временным рядам.
Временной ряд обладает такими свойствами как тренд, сезонность (суточная, еженедельная, месячная, ...), и подверженность экзогенным факторам, таким как например промоакции, скидки в цене, знаковые события (черные пятницы, кубки мира, рождество,...), отсутствию товара на складе и каннибализациям по конкурентам. Хорошо что автор не занимается прогнозированием, иначе пришлось бы рассказывать рассерженным стейкхолдерам что в виновен в "аутоффстоке" (и упущенной выгоде бизнеса соответственно) не автор а фильтр Хэмпла.
Спасибо за отличное настроение))
2X-пасибки))))
Если раскрыть аббревиатуру OLAP - online analytical processing. Т.е. это не технология, а парадигма хранения данных для работы с ними, это антоним OLTP (которя тоже не про технологию а парадигму).
То есть по большому счету пофигу что там под капотом, классический многомерный MDX куб с агрегатами или табулярная модель на основе колоночной аналитической СУБД, и то и другое это OLAP. Так что автор комментария выше прав, OLAP никуда не ушёл, он просто поменял тех.стек. Тот же Microsoft (о котором почему-то не упомянул автор статьи) являясь крупнейшим в мире поставщиком OLAP в аналитике (=доля рынка SQL Server Analysis Services в сравнении с оракловыми и IBM решениями+доля рынка Excel в котором Power Pivot уже на борту+ Power BI) - и тот отказался от развития классических многомерных кубов в пользу колоночных решений, но при этом это все еще OLAP.
У себя решил, выдумав термин (хотя скорее всего уже до меня его выдумали) : "граница смены поведения ряда". Реализовал на этапах препроцессинга поиском максимальной правой значимой границы смены поведения и отрезанием ряда по этой границе : в прогнозирование идет конечная правая часть а левая - в мусорку. Ищу крайне просто по типу как задача в начальной школе "2 поезда поехали из пункта "А" и "В" навстречу друг другу, где встретятся? Только вместо поездов у меня скользящие сигмы (с окном 21 день) которые едут по временному ряду навстречу (один с конца в начало, другой от начала в конец) . 3-м вектором считаем отношение по этим двум, значимым переходом состояний считаем превышения фикс.% по модулю . Например в точке t сигма_1 отличается от сигма_2 на 85% (не важно в какую сторону) но это выше фикс. Х% порога - явно переход поведения ряда.
На все про все - 30 строк кода на R (так много за счет доп.тюнинга типа не резать границу если уж очень короткая часть останется а поискать границу чуть раньше)