Статистический анализ данных на этапе формирования фичей, а также анализ полученных кластеров даст ответ на вопрос в каких интервалах находятся экстремальные значения признаков. Кроме того, общение со специалистом по fraud анализу может прояснить ситуацию
Как-то опасно все это прибито гвоздями. Дрейф данных (data drift) и привет...
Так же вызывает недоумение использование kmeans для поиска аномалий - видимо индусы в своих многочисленных статьях формируют тренды)))
Автор видимо не в курсе - какие ограничения есть у kmeans и насколько сами аномалии аффектят на него в процессе его работы. Это как искать аномалии по 2-м/3-м сигмам в одномерном пространстве забыв как аффектят аномалии на саму среднеарифметическую в процессе расчета. Хотя бы предварительно ознакомились с более робастными алгоритмами, например.
Статью смело можно сжать в несколько строк production-ready кода более уместными алгоритмами (например этим) , вызвав его хоть из R хоть из питона.
не лишён смысла в контексте этой строчки кода , так как переменные там вполне могут быть.
То что вполне могут у Вас быть это понятно, я писал о том что конкретно в строке df[val < 0.5 | val2 == 7] нет никаких неопределенных ситуаций, val и val2 не могут быть переменными иначе фильтрация не имеет смысла.
Только теперь непонятно, что в выражении df[val < threshold] — переменная, а что — кусок датафрейма.
Для кого не понятно? Для автора кода который сам задекларировал threshold ? Если val не в списке переменных окружения то явно что это из датафрейма. Для код-ревьювера? Если есть практика ревьювить в команде (где это кому-то не понятно) - значит в таких командах есть и правила написания кода. В таком случае никто не мешает писать код как "деды на R в универах" или питонисты:
df[df$val < threshold]
Hidden text
(надеюсь знаком $ вместо "." не задел тонкую душевную натуру какого-нибудь питон-снобиста, если так - будет новый повод обсудить какого цвета фломастеры вкуснее)
На самом деле когда у тебя в скрипте 200+ строк кода и на каждый шаг обработки надо раз 5 повторить название фрейма перед каждым столбцом - начинаешь ценить возможность писать более лаконичный код.
Тут тоже не понятно что имел в виду автор коммента:
и такой код хрупок по отношению к переименовыванию колонок.
А что питоновкий код становится мегазащищенным при переименовании колонок при явном написании датафрейма?
1) Python настоящий "универсальный клей", среди его 400k+ библиотек найдутся тысячи, которых нет в R.
R - настоящий "универсальный клей", среди его 19 тысяч пакетов абсолютно все пакеты предназначены для анализа данных, ML, статистики и богатой визуализации. А сколько из 400К питоновских для этого? Какой процент? Давайте откровенно, он даже в статистике и визуализации по числу пакетов/алгоритмов до сих пор отстает. А то что какого-то питоновского пакета нет в R - значит это к аналитике данных не имеет отношения (иначе давно бы в нём было)
Решил всё таки накомментарить, простите за то что не удержался....
Чуть разговор заходит про BI все начинают отчего-то думать про визуализацию, тайлы, тултипчики да про кроссфильтрацию. Ну и про дизайн ессно.
А в это время "русский биай" на хайпволне импортозамещений конечно пошел во все тяжкие: рвут и мечут в сторону эксплуатации джаваскрипт библиотек, как говорится с "миру-по-нитке" лишь бы побыстрей.
Задумайтесь, почему Qlick, Табло и PowerBI шли к зрелости своих продуктов чуть ли не 10-к лет? Ну серьезно, они все там тупые што-ле?
Да потому что то что пытается предложить сейчас русский биай вендор(ы) - это самый последний слой нормального готового BI продукта, визулизация, рисовалка, раскраска. Зачастую этого достаточно в надежде на то что бизнес или тупой или в шоке от санкций - большая вероятность что купит.
Но продолжительные периоды зрелости той большой тройки как раз связаны не со слоем визуализации а то что идет до этого слоя, а это слой получения данных (коннекторов должно быть 100500 примерно ко всему, включая вашу стиральную машинку), слой ETL (не только No-code но и Low-Code а у некоторых капот при желании легко открывается и там либо свой диалект SQL либо функциональщина для упоротых разрабов) и грааль быстрых откликов на клики юзеров - движок исполнения запросов. Колоночный и бИстрый! И до кучи со своим языком моделирования чтобы самыми извращенными метриками бизнесам наносить пользу.
Но русский биай не имеет столько времени на все это, да и не надо: бизнес лишь потом поймет что что-то пошло не так, но будет уже поздно...........................................................
Я не к тому что продукт Visiology плохой, может и хороший, "книгу не читал но осуждаю" - не про меня. Но то что массово повылезали за 1,5 месяца русские сырые "полубиаи" - печально все это.
Есть еще много других тонкостей, которые полезно знать про Pandas, но это уже совсем другая история.
Так веб разработчики в 90-х говорили про Internet Explorer: "Это не баг, это фича, просто надо их всех помнить..."
Надо не помнить - а просто сдать пандас в музей и пользоваться более современными и эффективными инструментами обработки данных, иначе эти толпы джунов обученных на курсах а-ля "DS за 7 дней на питоне" подрастут и в следующем поколении будут писать очередные статьи в духе "что обязательно надо помнить про пандас. том 7 с редакциями"
Так как Power BI работает не напрямую с источником данных, а создает “набор данных” для кеширования и оптимизации запросов это работает дольше даже на небольших наборах данных.
не хочу топить за майкрософт и рекламировать power bi т.к. за рекламу мне они к сожалению не платят (просто создаю дашборды на pbi уже лет 5 где-то). Но тезис выше странный. Любое кеширование в in-memory всегда быстрее формирует отчёт и это справедливо для любого размера данных влезающих в оперпамять, у вас это звучит как будто pbi тупит на малых данных в кэше.
Кстати, на случай если не в курсе: PBI имеет возможность подключения в режиме Direct Query к источникам вообще не храня в себе данные и транслируя запросы с дашбордов в тот же OLAP, MS SQL или даже SAP HANA
А еще любопытный факт : тот самый режим импорта который вы помянули, позволяет заливать одновременно 100500 разных источников (от монги до спарка, от SAP до Vertica) в один дашборд и построить не один уровень кэширования а в несколько слоёв по каждый уровень требуемой агрегации, и его оптимизатор крайне быстро решает - к какому слою кэша направить запрос с клика пользователя на визуале.
И еще один любопытный факт - самый самый нижний слой данных этой закэшированной пирамиды может быть угадайте чем? Direct Query Mode, что позволяет детальный срез на самом атомарном уровне гранулярности (в который юзер например попал через Drill Down или Drill Trough) отправить на исполнение напрямую в СУБД!
Это называется в PBI - композитная модель и появилась она в pbi не вчера а в 2018м, т.е. технология зрелая
Конечно в Data Science / Machine learning решения open source давно обогнали все проприоритарное, но вот на BI арене всё это пока на зачаточном уровне ещё.
У меня частая задачка (раза 2 в неделю точно)- найти в одном массиве адресов наиболее близкий по написанию адрес другого массива (нечеткий поиск). Чтобы не множить декартово произведенеие в массиве 10К на масссив 200К занимаюсь похожей оптимизацией: на регулярках извлекаю из адресов обоих массивов области РФ и вторым проходом (на более замороченных регулярках) извлекаю номер дома. Далее декартово произведенеие по этим связям дает на порядки меньший объём вычислений -обычный системник под столом особо не напрягаясь тратит минут 5. (Косинусное расстояние по очищенным регулярками адресам вышепомянутого пакета stringdist от Марка Ва Дер Ло)
Быстрее у Вас потому что тест не жизненный. Не в том смысле что датасеты не те (они такие же как и у меня) а в том что такие штуки как arrow / columnar dbms - это не про то чтобы посоревноваться на небольшом датасете в оперпамяти (заметьте, я arrow сравниваю с duckdb под dplyr соусом а не с чистым dplyr в качестве движка)
Чтобы приземлить Ваш бенчмарк чуть ближе к реальности, попробуйте накопировать 200 файлов flights на жёсткий диск в виде 200 паркетов (>60млн.записей), это будет датасет для arrow или duckdb. Затем rbind в оперпамяти (если ее хватит) -это будет датасет для dplyr. Вот теперь если сравнивать на фильтрации и группировках выясниться что даже на 8гб оперативы с чистым dplyr будет гораздо менее комфортно, потому что перегружена оперпамять и один поток а в arriw/duckdb -многопоточность на быстрых ssd и размер оперативы не так критичен. Тут я конечно немного лукавлю в том смысле что если оперпамяти ну прям дофига то на тех же h2o бенчмарках по ссылке в конце статьи data.table уделывает и dplyr и arrow и утку.
И еще одна ремарка: если совсем уж жизненно делать- то 200 паркетов сохраняют не в кучу а по поддиректриям (партициям) где название каждой такой папки так же участвует в фильтрации и arrow/duckDB понимает в какие папочки лезть или идти мимо и разница с data.table в оперпамяти будет не столь разительна (пример про это есть у arrow в виньетках)
В области анализа больших данных рулят Spark, H2O, всякие колоночные СУБД а-ля Clickhouse и прочие серьезные штуки. Python - лишь обёртка для обращения к ним. С тем же успехом можно писать про то что R рулит в анализе больших данных ибо имеет все те же самые инструменты взаимодействия с ними и заслуженно "примеряет корону в анализе".
А про печаль от питоновского пандас в анализе данных лучше всего написал сам создатель Pandas
Какая-то магия для меня, какое сообщество суперсет пилят, и далеко не два месяца а тут один человек...
Понятно что пока дэшей тут нет но такой скоуп работ проделан по no-code ETL с отдельной отдачей в графики что магия прям. Автора инопланетяне точно стероидами подкачали
Это конечно убиться на DAX'е всё запихать в вычислемую меру чтобы на каждый клик юзера делать пересчет ресурсоемких (в сравнении с простыми агрегациями) статистик. Если настолько "термины в ней истолкованы достаточно вольно " что не было проверки на нормальность распрделения / t-распрделения, то проще было не городить многоэтажной формулы, а подставлять в if какой-нибудь PERCENTILE.EXC на уровне 99% - меньше жрать ресурсов, код читать сильно проще и примерно те же градации цвета на выходе.
А еще проще - прологарифмировать вашу переменную и ее отправить в цветовые градации, а в tooltips - отражать исходные факты.
Отличная статья, согласен что интеграторы зачастую не заморачиваться с оптимизацией вычислений, дешевле (для них) запульнуть +1 машинку. А data.table как всегда хорош!
Знакомая ситуация. Недавно пришлось делать RFM анализ, пришлось руками воспроизвести весь одноименный пакет, также все банально но визуализация требовалась интерактивная.
Можно увидеть код раз уж помечено тэгом R?
Как-то опасно все это прибито гвоздями. Дрейф данных (data drift) и привет...
Так же вызывает недоумение использование kmeans для поиска аномалий - видимо индусы в своих многочисленных статьях формируют тренды)))
Автор видимо не в курсе - какие ограничения есть у kmeans и насколько сами аномалии аффектят на него в процессе его работы. Это как искать аномалии по 2-м/3-м сигмам в одномерном пространстве забыв как аффектят аномалии на саму среднеарифметическую в процессе расчета. Хотя бы предварительно ознакомились с более робастными алгоритмами, например.
Статью смело можно сжать в несколько строк production-ready кода более уместными алгоритмами (например этим) , вызвав его хоть из R хоть из питона.
То что вполне могут у Вас быть это понятно, я писал о том что конкретно в строке
df[val < 0.5 | val2 == 7]нет никаких неопределенных ситуаций, val и val2 не могут быть переменными иначе фильтрация не имеет смысла.Для кого не понятно? Для автора кода который сам задекларировал
threshold? Если val не в списке переменных окружения то явно что это из датафрейма. Для код-ревьювера? Если есть практика ревьювить в команде (где это кому-то не понятно) - значит в таких командах есть и правила написания кода. В таком случае никто не мешает писать код как "деды на R в универах" или питонисты:Hidden text
(надеюсь знаком $ вместо "." не задел тонкую душевную натуру какого-нибудь питон-снобиста, если так - будет новый повод обсудить какого цвета фломастеры вкуснее)
На самом деле когда у тебя в скрипте 200+ строк кода и на каждый шаг обработки надо раз 5 повторить название фрейма перед каждым столбцом - начинаешь ценить возможность писать более лаконичный код.
Тут тоже не понятно что имел в виду автор коммента:
А что питоновкий код становится мегазащищенным при переименовании колонок при явном написании датафрейма?
Очень даже "очень". Аргумент что это может быть переменная вообще лишен смысла в контексте этой строчки кода
R - настоящий "универсальный клей", среди его 19 тысяч пакетов абсолютно все пакеты предназначены для анализа данных, ML, статистики и богатой визуализации. А сколько из 400К питоновских для этого? Какой процент? Давайте откровенно, он даже в статистике и визуализации по числу пакетов/алгоритмов до сих пор отстает. А то что какого-то питоновского пакета нет в R - значит это к аналитике данных не имеет отношения (иначе давно бы в нём было)
Отличная статья
По всем этим пунктам все в полном порядке и даже более того : там где на поляне царствовал питон (deep learning) - всё тоже ок!
Вот еще ссылка где автор не поленился и сравнил "влоб" нечитабельность Python и лаконичность R
https://github.com/IyarLin/R-advantages-over-python
Решил всё таки накомментарить, простите за то что не удержался....
Чуть разговор заходит про BI все начинают отчего-то думать про визуализацию, тайлы, тултипчики да про кроссфильтрацию. Ну и про дизайн ессно.
А в это время "русский биай" на хайпволне импортозамещений конечно пошел во все тяжкие: рвут и мечут в сторону эксплуатации джаваскрипт библиотек, как говорится с "миру-по-нитке" лишь бы побыстрей.
Задумайтесь, почему Qlick, Табло и PowerBI шли к зрелости своих продуктов чуть ли не 10-к лет? Ну серьезно, они все там тупые што-ле?
Да потому что то что пытается предложить сейчас русский биай вендор(ы) - это самый последний слой нормального готового BI продукта, визулизация, рисовалка, раскраска. Зачастую этого достаточно в надежде на то что бизнес или тупой или в шоке от санкций - большая вероятность что купит.
Но продолжительные периоды зрелости той большой тройки как раз связаны не со слоем визуализации а то что идет до этого слоя, а это слой получения данных (коннекторов должно быть 100500 примерно ко всему, включая вашу стиральную машинку), слой ETL (не только No-code но и Low-Code а у некоторых капот при желании легко открывается и там либо свой диалект SQL либо функциональщина для упоротых разрабов) и грааль быстрых откликов на клики юзеров - движок исполнения запросов. Колоночный и бИстрый! И до кучи со своим языком моделирования чтобы самыми извращенными метриками бизнесам наносить пользу.
Но русский биай не имеет столько времени на все это, да и не надо: бизнес лишь потом поймет что что-то пошло не так, но будет уже поздно...........................................................
Я не к тому что продукт Visiology плохой, может и хороший, "книгу не читал но осуждаю" - не про меня. Но то что массово повылезали за 1,5 месяца русские сырые "полубиаи" - печально все это.
Так веб разработчики в 90-х говорили про Internet Explorer: "Это не баг, это фича, просто надо их всех помнить..."
Надо не помнить - а просто сдать пандас в музей и пользоваться более современными и эффективными инструментами обработки данных, иначе эти толпы джунов обученных на курсах а-ля "DS за 7 дней на питоне" подрастут и в следующем поколении будут писать очередные статьи в духе "что обязательно надо помнить про пандас. том 7 с редакциями"
Wes McKinney:10 Things I Hate About pandas
Утиные истории со стрелами на паркете
Илья, спасибо за коммент. К сожалению тег #пихтон только разъярит адептов секты отсутствием в коде
не хочу топить за майкрософт и рекламировать power bi т.к. за рекламу мне они к сожалению не платят (просто создаю дашборды на pbi уже лет 5 где-то). Но тезис выше странный. Любое кеширование в in-memory всегда быстрее формирует отчёт и это справедливо для любого размера данных влезающих в оперпамять, у вас это звучит как будто pbi тупит на малых данных в кэше.
Кстати, на случай если не в курсе: PBI имеет возможность подключения в режиме Direct Query к источникам вообще не храня в себе данные и транслируя запросы с дашбордов в тот же OLAP, MS SQL или даже SAP HANA
А еще любопытный факт : тот самый режим импорта который вы помянули, позволяет заливать одновременно 100500 разных источников (от монги до спарка, от SAP до Vertica) в один дашборд и построить не один уровень кэширования а в несколько слоёв по каждый уровень требуемой агрегации, и его оптимизатор крайне быстро решает - к какому слою кэша направить запрос с клика пользователя на визуале.
И еще один любопытный факт - самый самый нижний слой данных этой закэшированной пирамиды может быть угадайте чем? Direct Query Mode, что позволяет детальный срез на самом атомарном уровне гранулярности (в который юзер например попал через Drill Down или Drill Trough) отправить на исполнение напрямую в СУБД!
Это называется в PBI - композитная модель и появилась она в pbi не вчера а в 2018м, т.е. технология зрелая
https://radacad.com/power-bi-fast-and-furious-with-aggregations
А вот тут видосик где рассказывается как крутить наборы данных петабайтного масштаба в Azure с помощью агрегирования в Power BI
https://youtu.be/OUf-kSWhcOM
Конечно в Data Science / Machine learning решения open source давно обогнали все проприоритарное, но вот на BI арене всё это пока на зачаточном уровне ещё.
А рост всходов можно фиксировать на бересте. Так родится Beresta BI - ещё один "аналог" западного ПО:)
У меня частая задачка (раза 2 в неделю точно)- найти в одном массиве адресов наиболее близкий по написанию адрес другого массива (нечеткий поиск). Чтобы не множить декартово произведенеие в массиве 10К на масссив 200К занимаюсь похожей оптимизацией: на регулярках извлекаю из адресов обоих массивов области РФ и вторым проходом (на более замороченных регулярках) извлекаю номер дома. Далее декартово произведенеие по этим связям дает на порядки меньший объём вычислений -обычный системник под столом особо не напрягаясь тратит минут 5. (Косинусное расстояние по очищенным регулярками адресам вышепомянутого пакета stringdist от Марка Ва Дер Ло)
Быстрее у Вас потому что тест не жизненный. Не в том смысле что датасеты не те (они такие же как и у меня) а в том что такие штуки как arrow / columnar dbms - это не про то чтобы посоревноваться на небольшом датасете в оперпамяти (заметьте, я arrow сравниваю с duckdb под dplyr соусом а не с чистым dplyr в качестве движка)
Чтобы приземлить Ваш бенчмарк чуть ближе к реальности, попробуйте накопировать 200 файлов flights на жёсткий диск в виде 200 паркетов (>60млн.записей), это будет датасет для arrow или duckdb. Затем rbind в оперпамяти (если ее хватит) -это будет датасет для dplyr. Вот теперь если сравнивать на фильтрации и группировках выясниться что даже на 8гб оперативы с чистым dplyr будет гораздо менее комфортно, потому что перегружена оперпамять и один поток а в arriw/duckdb -многопоточность на быстрых ssd и размер оперативы не так критичен. Тут я конечно немного лукавлю в том смысле что если оперпамяти ну прям дофига то на тех же h2o бенчмарках по ссылке в конце статьи data.table уделывает и dplyr и arrow и утку.
И еще одна ремарка: если совсем уж жизненно делать- то 200 паркетов сохраняют не в кучу а по поддиректриям (партициям) где название каждой такой папки так же участвует в фильтрации и arrow/duckDB понимает в какие папочки лезть или идти мимо и разница с data.table в оперпамяти будет не столь разительна (пример про это есть у arrow в виньетках)
Илья, спасибо. Долго откладывал статью, и тут как вернулся- выяснилось что с того момента уже вышло еще 2 версии и много чего нового))
В области анализа больших данных рулят Spark, H2O, всякие колоночные СУБД а-ля Clickhouse и прочие серьезные штуки. Python - лишь обёртка для обращения к ним. С тем же успехом можно писать про то что R рулит в анализе больших данных ибо имеет все те же самые инструменты взаимодействия с ними и заслуженно "примеряет корону в анализе".
А про печаль от питоновского пандас в анализе данных лучше всего написал сам создатель Pandas
10 Things I Hate About pandas
Отличная копипаста из гугл-транслэйт
Какая-то магия для меня, какое сообщество суперсет пилят, и далеко не два месяца а тут один человек...
Понятно что пока дэшей тут нет но такой скоуп работ проделан по no-code ETL с отдельной отдачей в графики что магия прям. Автора инопланетяне точно стероидами подкачали
Это конечно убиться на DAX'е всё запихать в вычислемую меру чтобы на каждый клик юзера делать пересчет ресурсоемких (в сравнении с простыми агрегациями) статистик. Если настолько "термины в ней истолкованы достаточно вольно " что не было проверки на нормальность распрделения / t-распрделения, то проще было не городить многоэтажной формулы, а подставлять в if какой-нибудь PERCENTILE.EXC на уровне 99% - меньше жрать ресурсов, код читать сильно проще и примерно те же градации цвета на выходе.
А еще проще - прологарифмировать вашу переменную и ее отправить в цветовые градации, а в tooltips - отражать исходные факты.
Отличная статья, согласен что интеграторы зачастую не заморачиваться с оптимизацией вычислений, дешевле (для них) запульнуть +1 машинку. А data.table как всегда хорош!
Знакомая ситуация. Недавно пришлось делать RFM анализ, пришлось руками воспроизвести весь одноименный пакет, также все банально но визуализация требовалась интерактивная.