🍁У нас в октябре планируются следующие DS-ивенты:
• 4-7 октября - конференция «Аналитика и управление данными в областях с интенсивным использованием данных» («Data Analytics and Management in Data Intensive Domains» — DAMDID). В этом году ее местом проведения станет Университет ИТМО, СПб https://news.itmo.ru/ru/announce/76547/
• 5 октября - Fin.Bot 2023 - 3-я профессиональная кейс-конференция о чат-ботах, роботах в голосовых каналах и виртуальных помощниках, а также лучших инструментах создания диалоговых роботов на основе технологий AI, ML и BigData в финансовом секторе Москва, Holiday Inn Moscow Lesnaya https://finbot-forum.ru/
• 17-18 октября -конференция по инженерии данных SmartData в онлайн-формате https://smartdataconf.ru/
• 29 октября - конференция по инженерии данных SmartData в Санкт-Петербурге, Park Inn by Radisson Pulkovskaya: пл. Победы, 1 https://smartdataconf.ru/

🚀Тонкости Pandas: at и iat вместо iloc и loc для ускорения циклов
В популярной Python-библиотеке Pandas есть функции iloc и loc для доступа к значениям датафрейма с помощью индекса строки и индекса или имени столбца. Но их выполнение внутри циклов требует много времени. Если заменить loc на at или iloc на iat, время выполнения for-цикла может снизиться в 60 раз!
Такая разительная разница в скорости обусловлена характером самих функций: at и iat предназначены для доступа к скаляру, то есть к одному элементу датафрейма. А loc и iloc используются для одновременного доступа к нескольким элементам (рядам, датафреймам), т.е. они изначально они нужны для выполнения векторизованных операций.
Поскольку at/iat используются для доступа к скалярному значению, они является более быстрыми по сравнению с loc/iloc, предназначенными для доступа к ряду/датафрейму и занимающими больше места и времени. Поэтому использование loc/iloc внутри циклов в Python не оптимально, и его лучше заменить на at/iat, которые выполняются быстрее. Однако, loc и iloc отлично работают вне циклов Python для векторизованных операций.
https://medium.com/codex/dont-use-loc-iloc-with-loops-in-python-instead-use-this-f9243289dde7

👍🏻PRegEx для работы с регулярными выражениями
Регулярные выражения для поиска и замены текста в строке, одном или нескольких файлах, активно используются разработчиками и тестировщиками. Однако, читать и писать их довольно сложно. Упростить работу с регулярными выражениями на Python поможет пакет с открытым исходным кодом PRegEx (Programmable Regular Expressions), который имеет синтаксис, напоминающий императивный способ программирования. С PRegEx не нужно группировать шаблоны или экранировать метасимволы, поскольку они отлично обрабатываются внутри пакета.
Благодаря модульному принципу создания шаблонов в регулярных выражениях, PRegEx позволяет разбить сложный шаблон на несколько более простых, которые затем можно объединить. А высокоуровневый API поверх встроенного Python-модуля re, обеспечивающий доступ к его основным функциям и многому другому, избавит от необходимости работать с экземплярами re.Match.
Примеры использования: https://towardsdatascience.com/pregex-write-human-readable-regular-expressions-in-python-9c87d1b1335

👌Low Code/No Code для данных с Superblocks
Идея быстрой разработки приложений без написания кода активно используется при автоматизации офисных бизнес-процессов с помощью BPMS (ELMA, Camunda и пр.). В области анализа данных тоже появляются подобные решения, позволяющие из готовых блоков собрать рабочее приложение, как из кубиков конструктора. Например, Superblocks – Low Code платформа интеграции данных и конвейеров их обработки с возможностями BI-системы.
Как создать и развернуть аналитическое веб-приложение с созданием отчетов, используя Superblocks и MongoDB, за пару минут, читайте здесь: https://yaakovbressler.medium.com/next-generation-data-dashboards-reimagined-meet-superblocks-2d316cb3597c

🤔Что такое последовательное тестирование и чем оно полезно
Общей проблемой при проведении онлайн-тестов A / B является проблема просмотра, представление о том, что принятие ранних решений о доставке, как только наблюдаются статистически значимые результаты, приводит к завышенным показателям ложноположительных результатов. Это происходит из-за противоречия между двумя аспектами онлайн-экспериментирования:
• Текущие обновления метрик - современные платформы онлайн-экспериментов используют потоки данных в реальном времени и могут немедленно отображать результаты. Затем эти результаты могут быть обновлены, чтобы отражать самую последнюю информацию по мере продолжения сбора данных.
• Ограничения базового статистического теста - при проверке гипотез обычно используется заранее определенный уровень ложноположительных результатов, так называемый альфа-уровень, равный 0,05 (5%). Когда p-значение меньше 0,05, принято отклонять нулевую гипотезу и приписывать наблюдаемый эффект тестируемому эксперименту. При этом существует 5%-ная вероятность того, что статистически значимый результат на самом деле является просто случайным шумом.
Однако постоянный мониторинг в ожидании значимости приводит к усугублению эффекта 5% ложноположительных результатов. Поэтому в онлайн-тестировании пригодится последовательная проверка гипотез — статистический анализ, в котором размер выборки заранее не фиксируется. Вместо этого данные оцениваются по мере их сбора, и дальнейшая выборка прекращается в соответствии с заранее определенным правилом остановки, как только наблюдаются значимые результаты. Таким образом, последовательное тестирование позволяет сократить время и затраты на эксперимент благодаря возможности сделать выводы на ранней стадии исследования.
В последовательном тестировании вычисление p-значения изменяется таким образом, чтобы снизить более высокий риск ложноположительных показателей, связанных с подглядыванием. Поэтому важно обеспечить раннее принятие решений без увеличения количества ложноположительных результатов путем корректировки порога значимости, чтобы эффективно поднять планку того, что представляет собой статистически значимые результаты на раннем этапе.
Часть разработки экспериментов включает в себя предварительную установку целевой продолжительности. Это количество дней, необходимое для определения желаемого размера эффекта, при условии, что эффект есть. Обычно есть несколько представляющих интерес показателей с разной дисперсией и величиной эффекта, которые требуют разных размеров выборки и продолжительности. Лучше выбирать продолжительность, которая дает достаточную статистическую мощность для всех ключевых показателей.
При просмотре эксперимента до даты завершения доверительные интервалы расширяются, чтобы отразить более высокую неопределенность в этот момент времени. Если скорректированный доверительный интервал пересекает ноль, это означает, что данных еще недостаточно для принятия решения на основе этой метрики, даже если традиционное значение p является статистическим. Корректировка уменьшается по ходу эксперимента и исчезает, когда достигается целевая продолжительность.
https://blog.statsig.com/sequential-testing-on-statsig-a3b45dd8ab72

🤔Ограничения последовательного тестирования
Последовательная проверка гипотез — это статистический анализ, когда размер выборки заранее не фиксируется, а данные оцениваются по мере их сбора. Анализ прекращается в соответствии с заранее определенным правилом остановки, как только наблюдаются значимые результаты. Это позволяет сделать выводы на ранней стадии исследования, чем при более классическом A/B-тестировании, снизив финансовые и временные затраты на эксперимент.
Чтобы лучше понять прогресс последовательного тестирования в ходе эксперимента, полезно подумать о пороговых значениях, которые определяют, является ли эффект значительным или нет. Их обычно называют границами эффективности. Когда Z-оценка, рассчитанная для метрической дельты, выше верхней границы, эффект статистически положительный. И наоборот, Z-оценка ниже нижней границы означает отрицательный результат статистического сигнала. В начале эксперимента границы эффективности высоки. Это значит, что необходимо пересечь гораздо более высокий порог значимости, чтобы принять раннее решение, когда размер выборки еще невелик. Границы корректируются с каждым днем. В конце заранее определенной продолжительности они достигают стандартного Z-показателя для выбранного уровня значимости, например: 1,96 для двусторонних тестов с 95% доверительными интервалами.
Хотя «подглядывание» в A/B-тестирование не одобряется, ранний мониторинг тестов важен для максимальной отдачи от программы экспериментов. Если эксперимент приводит к измеримой регрессии, не стоит ждать до конца, чтобы принять меры. При последовательном тестировании можно отличить статистический шум от сильных эффектов, которые значимы на ранней стадии. Еще последовательное тестирование пригодится, когда есть альтернативные издержки для проведения эксперимента на протяжении всей его продолжительности. Например, отказ в улучшении от подмножества пользователей сопряжен с большими инженерными или бизнес-затратами, или когда завершение эксперимента открывает путь для дальнейших испытаний.
Однако, прежде чем принимать раннее решение, стоит вспомнить, что даже если одна метрика пересекла границу эффективности, другие метрики, которые пока кажутся нейтральными, могут оказаться статистически значимыми в конце эксперимента. Граница эффективности полезна для раннего определения статистических результатов, но не различает отсутствие истинного эффекта и недостаточную мощность до достижения целевой продолжительности.
Также следует учитывать недельную сезонность экспериментов. В частности, даже когда все интересующие показатели выглядят отлично на раннем этапе, рекомендуется подождать не менее 7 полных дней, прежде чем принимать решение. Это связано с тем, что на многие показатели влияет еженедельная сезонность, когда конечные пользователи продукта ведут себя по-разному в зависимости от дня недели.
Наконец, если важна хорошая оценка размера эффекта, лучше довести эксперимент до конца, т.к. скорректированные доверительные интервалы последовательного тестирования шире, поэтому диапазон вероятных значений больше при принятии раннего решения. Это означает низкую точность. Кроме того, больший измеренный эффект с большей вероятностью будет статистически значимым на раннем этапе, даже если истинный эффект на самом деле меньше. Регулярное принятие ранних решений на основе положительных результатов статистики может привести к систематической переоценке влияния запущенных экспериментов, что также снижает точность.
https://blog.statsig.com/sequential-testing-on-statsig-a3b45dd8ab72

🤔UDF в SQL: за и против
Data Scientist’ы и аналитики данных часто пишут SQL-запросы, что порой занимает очень много времени. Пользовательские функции (UDF) могут повысить скорость написания SQL-запросов. UDF на базовом уровне похожа на типичную функцию SQL, но определяется пользователем. С технической точки зрения UDF — это функция, которая принимает набор типизированных параметров, применяет некоторую логику, а затем возвращает типизированное значение. UDF-функции имеют широкий спектр применений, включая оптимизацию повторяющегося кода и централизацию бизнес-логики, что помогает писать SQL-запросы более эффективно. Использование UDF может быть полезным, но имеет и свои недостатки. Главные достоинства UDF:
• позволяет заменять части сложного или повторяющегося SQL-кода простыми однострочными строками, делая код более читабельным. Например, сложный оператор CASE занимает много строк. С помощью UDF его можно сократить до одной строки.
• поощряет централизованные определения процессов, позволяя заключать их в скобки, чтобы далее повторно использовать в новых запросах.
Таким образом, UDF ускоряет разработку кода, но и имеет и ряд минусов:
• слишком много неясных UDF-функций могут сделать код менее читаемым, особенно, если они названы непонятно вроде «func1» - не ясно, что функция на самом деле делает, и читатель должен искать ее определение, что занимает больше времени, чем просто чтение его в коде.
• нужно будет вести учет всех пользовательских функций, которые созданы, что сложно при их большом количестве. Для этого рекомендуется сохранить словарь с созданными UDF и поделиться им с командой. Также можно создавать более общие функции, чтобы избежать переделок.
https://towardsdatascience.com/save-time-writing-sql-with-udfs-24b002bf0192

🍨🍧🍡Упрощаем отладку Python-кода с библиотекой IceCream
IceCream — это библиотека Python, которая делает отладку легкой и читабельной с минимальным кодом. Она включает печать выражений, имена переменных, имена функций, номера строк, имена файлов и многое другое, что пригодится разработчику при поиске ошибок и их устранении. Вместо использования print() или log() для отладки кода в библиотеке IceCream есть аналогичные функции. В частности, ic() похож на print(), но он выводит имена выражений, переменных и их значения, причем работает на 60% быстрее. Библиотека IceCream более полно отображает исследуемые структуры данных, имеет богатый синтаксис вывода, а также может включать контекст программы: имя файла, номер строки и родительскую функцию.
Открытый код IceCream представлен на Github. Библиотека поддерживает Python 2, Python 3, PyPy2 и PyPy3, а также может использоваться и в других языках программирования: Dart, Rust, Node.js, C++, PHP, Go, Ruby, Java, R, Lua, Clojure(Script) и Bash.
Примеры использования: https://towardsdatascience.com/introducing-icecream-never-use-print-to-debug-your-python-code-again-d8f2e5719f8a

💥3 достоинства и пара недостатков PySpark перед Pandas
Хотя Python-библиотека Pandas очень популярна у начинающих Data Scientist’ов, она не предназначена для работы с по-настоящему большими данными, т.к. может обрабатывать без проблем с памятью объемы до 10–12 ГБ. Хотя есть инструменты, которые могут распараллелить работу Pandas, например, Dask, Swift, Ray и пр., это лишь ускоряет работу библиотеки, но не устраняет причин главной проблем, т.к. Pandas всегда загружает датафрейм в память.
Поэтому при работе с большим объемом данных следует выбирать что-то быстрее, например, PySpark – Python API в Apache Spark, распределенном вычислительном движке. Будучи распределенным по своей природе, Spark также применяет т.н. ленивые или отложенные вычисления, выполняя операции с данными не во время их объявления, а при непосредственном вызове. Это устраняет многие ограничения памяти. В отличие от PySpark, Pandas придерживает Eager Execution, выполняя задачи выполняются как можно раньше, а PySpark следует концепции Lazy Execution, когда задача не выполняется до тех пор, пока не будет выполнено действие. PySpark отлично подходит для разработки масштабируемых приложений и гарантирует отказоустойчивость.
Однако, из-за передачи данных по сети в рамках распределенных вычислений, PySpark потенциально имеет более высокую задержку по сравнению с локальным Pandas, что приводит к снижению пропускной способности приложения. Кроме того, PySpark остается требовательным к памяти, поскольку все задачи MapReduce выполняются в оперативной памяти, без записи предварительных результатов на диск, в отличие от классических вычислений в Hadoop. Наконец, в PySpark меньше специализированных для Data Science алгоритмов.

🍁🌨ТОП-7 DS-событий ноября:
• 10 ноября - Innopolis meetup: Data Science и ML - Иннополис, Университетская, 5 (Технопарк им.Лобавчевского), Коворкинг https://innopolis.timepad.ru/event/2217002/
• 11-12 ноября – Матемаркетинг 2022, онлайн-дни, https://matemarketing.ru/
• 15-17 ноября – Big Data & Analitics Day 2022 – большая конференция – Москва, технопарк «Сколково» https://techweek.moscow/data_day
• 17-18 ноября – Матемаркетинг 2022, офлайн-дни. Москва, кампус Сколково https://matemarketing.ru/
• 23 ноября - Искусственный интеллект: от пилота к промышленной эксплуатации - Конференция от CNews - https://events.cnews.ru/events/iskusstvennyi_intellekt_2022_2022-09-29.shtml
• 23-24 ноября - Международная конференция Сбера по искусственному интеллекту AI Journey https://ai-journey.ru/
• 29 ноября – DataStart, бесплатная Онлайн-конференция Data Science, машинное обучение и нейросети - https://datastart.ru/

🚀Python 3.11.0: главные новинки для разработчика
24 октября 2022 г. вышла новая версия Python 3.11.0 со следующими ключевыми фичами и исправлениями ошибок:
• исправлено умножение списка на целое число (список *= int), что приводило к целочисленному переполнению, когда новая выделенная длина близка к максимальному размеру;
• изменен код метода запуска forkserver - в Linux модуль многопроцессорности теперь снова использует сокеты домена unix, поддерживаемых файловой системой, чтобы работать с процессом forkserver вместо пространства имен абстрактных сокетов Linux. Абстрактные сокеты не имеют разрешений и могут позволить любому пользователю в системе в том же сетевом пространстве имен (часто всей системе) вводить код в многопроцессорный процесс forkserver. Это существенная уязвимость типа превышение привилегий и устранено в новой версии Python.
• исправлена проблема, из-за которой несколько объектов фрейма могли поддерживаться одним и тем же фреймом интерпретатора, что могло привести к повреждению памяти и серьезным сбоям интерпретатора;
• исправлено возможное повреждение данных или сбои при доступе к элементу f_back вновь созданного генератора или фреймов сопрограммы;
• исправлен сбой, возникающий при вызове PyEval_GetFrame(), когда самый верхний фрейм Python находится в частично инициализированном состоянии;
• исправлен синтаксический анализ командной строки: параметр reject -X int_max_str_digits без значения недействителен, когда для переменной среды PYTHONINTMAXSTRDIGITS установлено допустимое значение;
• исправлено неопределенное поведение в _testcapimodule.c;
• обновлены связанные копии pip и setuptools до версий 22.3 и 65.5.0 соответственно;
• ранее объявленный устаревшим метод asyncio.Task.cancel("message") теперь снова работает и не считается устаревшим;
• семафоры работают быстрее, что важно для многозадачных программ;
• исправлен флаг для использования границы CONFORM, что позволяет объединять флаги с непоследовательными значениями;
• в Windows, когда набор тестов Python запускается с параметром -jN, для временного файла stdout вместо UTF-8 теперь используется кодировка ANSI;
• исправлена ошибка, из-за которой многопроцессорность из виртуальной среды порождала дочерние процессы в Windows, когда это было не нужно;
• исправлена обработка программой запуска py.exe параметра -V:<company>/, когда в переменных среды или файлах конфигурации были установлены предпочтения по умолчанию;
• SDK macOS 13 включает поддержку системных вызовов mkfifoat и mknodat. Ранее использование параметра dir_fd с os.mkfifo() или os.mknod() приводило к segfault, если cpython собран с помощью SDK macOS 13, но работал в более ранней версии macOS.

https://www.python.org/downloads/release/python-3110/
https://docs.python.org/release/3.11.0/whatsnew/changelog.html#python-3-11-0-final

🌞Простое прогнозирование с Lazy Predict
Продолжая знакомиться с полезными для Data Science библиотеками Python, разберем, что такое Lazy Predict и где это пригодится. Это библиотека для сравнения производительности различных моделей машинного обучения в наборе данных. По сути, это обертка, которая позволяет быстро подогнать все ML-модели под набор данных и сравнить их производительность буквально за пару строчек кода. Lazy Predict отлично работает с классификацией и регрессией, позволяя сравнить результаты обучения ML-моделей по самым важным метрикам: R-Squared, RMSE, точность (Accuracy), F1 Score, и время обучения.
Библиотека имеет открытый исходный код и отлично совместима со sklearn, numpy и другими Python-библиотеками, которые используются в задачах Data Science.
https://lazypredict.readthedocs.io/en/stable/readme.html

🐍Python вместо Cypher в Neo4j с Py2neo
Манипуляции с данными в графовой базе Neo4j выполняются средствами SQL-подобного языка запросов Cypher. Он оптимизирован для графов, определяет и использует отношения данных, исследуя взаимосвязи во всех направлениях, чтобы обнаружить ранее невидимые отношения и кластеры. Однако, Python дает большую гибкость в работе с данными. Поэтому многие Data Scientist’ы предпочитают его для различных программ, включая автоматизацию процесса создания узлов и связей.
В этом случае отлично пригодится библиотека Py2neo – Python-пакет, который работает с Neo4j. Его можно установить его с помощью менеджера пакетов pip через всем известную команду pip install py2neo в командной строке. Далее можно открывать любимый Python-редактор и запускать граф в Neo4j.
Py2neo включает набор инструментов для работы с Neo4j из приложений Python и из командной строки. Библиотека поддерживает как Bolt, так и HTTP и предоставляет высокоуровневый API, OGM, инструменты администрирования, интерактивную консоль, лексический шифратор Cypher для Pygments и многие другие функциональные возможности, которые пригодятся для анализа графов. Начиная с версии 2021.1, Py2neo содержит полную поддержку маршрутизации, представленную кластером Neo4j, что можно включить с помощью URI neo4j://... или путем передачи параметра routing=True в конструктор класса Graph.
https://py2neo.org/2021.1/