На практике все 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 (так много за счет доп.тюнинга типа не резать границу если уж очень короткая часть останется а поискать границу чуть раньше)
Александр, отличная статья, спасибо! Начал после статьи знакомиться с Faiss и в чем-то это пересекалось с FastText от того же Facebook. Не понял зачем они сделали отдельную библиотеку вместо расширения функционала действующей (видимо были какие-то причины). Учитывая что он как раз про классификацию - пробовали его?
python дозрел до Rmarkdown . Делал когда-то на нем интерактивную регламентную отчетность, пока BI не пришел - бизнесу оч.нравилось. Если функционал этой библиотеки сопоставим - очередной плюс в карму питона.
Великий Хедли Викхам помимо своего влияния на развитие языка R еще и в визуализацию сложных вещей просто и наглядно умеет. https://r4ds.hadley.nz/joins.html
Во первых технологию Вам никто не навязывает, и если Вы спрашиваете "зачем" значит ещё не встретились по работе с кейсом когда Ваши традиционные подходы не укладываются в требуемые временные рамки по скорости выполнения на объемах данных
Во вторых прежде чем считать что-то хайпом, сначала ознакомьтесь хотя бы тестовыми запусками, пощупайте руками, и уже потом давайте оценки.
Я далёк от Spark/Java но и без них на практике меня arrow сильно выручал по работе. Моя статья про альтернативу питоновскому pandas и про использование в R
Я тестил комбинацию модели классификации (купит/не купит) * модель регрессии (если купит то сколько) по статье
В принципе на детальном уровне получается чуть лучше чем "голый" бустинг. Но в итоге все равно выбрал путь - подняться над магазинами и уже потом дробить прогнозы по ним. (И это R а не ETNA, хотя попробовать её наверно стоит)
Огромная боль - прогнозирование tweedie распределений с большим количеством 0й. Ничего нормального кроме Croston не выходит. Я так понимаю бустинг на таком уровне детализации (магазин-товар-дата) бесполезен, так что bottom-up отпадает. Может подскажете куда с бустингом двигаться? Middle-out? Как потом спускать прогнозы на детальный уровень?
На практике все 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 (так много за счет доп.тюнинга типа не резать границу если уж очень короткая часть останется а поискать границу чуть раньше)
Александр, отличная статья, спасибо! Начал после статьи знакомиться с Faiss и в чем-то это пересекалось с FastText от того же Facebook. Не понял зачем они сделали отдельную библиотеку вместо расширения функционала действующей (видимо были какие-то причины). Учитывая что он как раз про классификацию - пробовали его?
python дозрел до Rmarkdown . Делал когда-то на нем интерактивную регламентную отчетность, пока BI не пришел - бизнесу оч.нравилось. Если функционал этой библиотеки сопоставим - очередной плюс в карму питона.
Великий Хедли Викхам помимо своего влияния на развитие языка R еще и в визуализацию сложных вещей просто и наглядно умеет.
https://r4ds.hadley.nz/joins.html
https://r4ds.had.co.nz/relational-data.html#join-matches
One table has duplicate keys.
Both tables have duplicate keys
Отличная вводная в tidymodels. Хочется продолжения с recepies и тюнингом модели
Во первых технологию Вам никто не навязывает, и если Вы спрашиваете "зачем" значит ещё не встретились по работе с кейсом когда Ваши традиционные подходы не укладываются в требуемые временные рамки по скорости выполнения на объемах данных
Во вторых прежде чем считать что-то хайпом, сначала ознакомьтесь хотя бы тестовыми запусками, пощупайте руками, и уже потом давайте оценки.
Я далёк от Spark/Java но и без них на практике меня arrow сильно выручал по работе. Моя статья про альтернативу питоновскому pandas и про использование в R
Есть убийственно эффективный data.table на R (регулярно пользуюсь) и вариант его портирования на питоне datatable.
Насколько эффективен питоновский-сказать не могу, не использовал.
И помимо отличного arrow есть ещё и polars
И кстати arrow не менее прекрасен и в R тоже
Я тестил комбинацию модели классификации (купит/не купит) * модель регрессии (если купит то сколько) по статье
В принципе на детальном уровне получается чуть лучше чем "голый" бустинг. Но в итоге все равно выбрал путь - подняться над магазинами и уже потом дробить прогнозы по ним. (И это R а не ETNA, хотя попробовать её наверно стоит)
даже и не подозревал что функции R в той или иной комбинации могут стать коммерческой тайной
Огромная боль - прогнозирование tweedie распределений с большим количеством 0й. Ничего нормального кроме Croston не выходит. Я так понимаю бустинг на таком уровне детализации (магазин-товар-дата) бесполезен, так что bottom-up отпадает. Может подскажете куда с бустингом двигаться? Middle-out? Как потом спускать прогнозы на детальный уровень?