🤔Ограничения последовательного тестирования
Последовательная проверка гипотез — это статистический анализ, когда размер выборки заранее не фиксируется, а данные оцениваются по мере их сбора. Анализ прекращается в соответствии с заранее определенным правилом остановки, как только наблюдаются значимые результаты. Это позволяет сделать выводы на ранней стадии исследования, чем при более классическом 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/

👀ТОП-5 открытых инструментов для отслеживания происхождения данных
Происхождение данных (data lineage) позволяет компании соблюдать нормативные требования, лучше понимать и доверять своим данным, а также экономить время на ручном анализе возможных эффектов от их изменения. Для мониторинга происхождения данных на сегодняшнем рынке есть множество инструментов, открытых и проприетарных. Из инструментов с открытым исходным кодом наиболее популярными являются следующие:
• Tokern позволяет пользователям получать данные о происхождении данных на уровне столбцов из баз данных и хранилищ данных, размещенных в Google BigQuery, AWS Redshift и Snowflake. Tokern можно интегрировать и с другими системами, т.к. он хорошо работает с большинством каталогов данных с открытым исходным кодом и ETL-фреймворков. Tokern также позволяет пользователям создавать происхождение данных из истории запросов или сценариев ETL, что делает его идеальным для интеграции инструментов BI и ETL. В качестве своего локального хранилища Tokern использует PostgreSQL, а для визуализации Kedro-Viz и библиотеку анализа сетевых графов NetworkX. Эти библиотеки позволяют пользователям отслеживать, визуализировать и анализировать данные о происхождении на уровне столбцов. Кроме того, пользователи также могут взаимодействовать с данными о происхождении, используя SDK или API Tokern. Еще Tokern обеспечивает обнаружение PII (личной информации) и PHI (личной медицинской информации) с помощью PIICatcher, сочетая регулярные выражения с NLP-библиотеками Spacy и Stanford NER.
• Egeria – стандарт метаданных с открытым исходным кодом, обеспечивающий беспрепятственную интеграцию инструментов обработки данных для надежного и согласованного представления метаданных. Egeria позволяет пользователям создавать более совершенные решения для отслеживания происхождения данных, проверки качества данных, идентификации PII и т. д. в дополнение к каталогизации и поиску метаданных. Egeria основана на открытом стандарте сбора и хранения данных OpenLineage. Это позволяет пользователям получить более полное представление о данных, предоставляя горизонтальное и вертикальное их происхождение и трассировки. Чтобы получить информацию о происхождении данных, Egeria прослушивает события Kafka, создаваемые исходными системами.
• Pachyderm —инструмент сбора данных, позволяющий разработчикам создавать конвейеры машинного обучения независимо от языка и фреймворка, вместо фокуса на облачных хранилищах данных. Он использует систему контроля версий, такую как lakeFS или Git, фиксирует и сохраняет изменения, например, коммиты, сохраняя полный и неизменный контрольный журнал событий. Также Pachyderm имеет полный журнал аудита и использует центральный репозиторий на основе объектного хранилища в настраиваемой файловой системе Pachyderm File System, чтобы обеспечить отслеживание происхождения данных и контроль их версий. Pachyderm обеспечивает неизменность источника данных пользователя, позволяя назначать глобальные идентификаторы событиям происхождения и объектам данных. Pachyderm позволяет просматривать неизменяемый график происхождения данных как DAG в пользовательском интерфейсе, что особенно полезно при работе с конвейерами ML. Pachyderm отлично интегрируется со многими базами, хранилищами и озерами данных. Поэтому многие компании используют его для операций MLOps, неструктурированных данных ETL и рабочих нагрузок NLP.
• OpenLineage – проект Linux Foundation, основанный на интеграции с платформами ETL, механизмами оркестрации данных, каталогами метаданных, механизмами контроля качества данных, а также инструментами наследования данных. OpenLineage использует JSONSchema в качестве определения API и поддерживает различные языки и платформы. Ранее упомянутая Egeria имеет основной уровень метаданных, построенный поверх OpenLineage. Marquez от WeWork также лежит в основе архитектуры OpenLineage, предлагая репозиторий пользовательского интерфейса и метаданных, а также API для сбора метаданных, предоставляемый через GraphQL и REST API.

• TrueDat – комплексное решение для управления данными, которое позволяет детально классифицировать, искать и отслеживать их, а также визуализировать весь жизненный цикл данных. Инструмент создан в 2017 г. компанией BlueTab, входящей в состав IBM, и до сих пор активно развивается.
https://blog.devgenius.io/5-best-open-source-data-lineage-tools-in-2022-f8ef39a7d5f6

🚀Как ускорить Pandas с библиотекой Pandarallel
Каждый Data Scientist знает, что Python-библиотека Pandas работает довольно медленно и не предназначена для больших объемов данных. Тем не менее, каждый Data Scientist ее использует.🤷‍♀️ Чтобы сделать Pandas более быстрой, можно включить в свой проект Pandarallel — простой и эффективный инструмент для распараллеливания операций Pandas на всех доступных процессорах.
Pandas использует только одно ядро ЦП, а Pandarallel позволяет воспользоваться преимуществами многоядерного компьютера. Еще Pandarallel предлагает индикаторы выполнения программы, доступные на ноутбуке и терминале, чтобы получить приблизительное представление об оставшемся объеме вычислений, которые необходимо выполнить.
Библиотеку можно использовать на любом компьютере под управлением Linux и macOS, а в Windows есть небольшие особенности: из-за многопроцессорной системы функция, которая отправляется в Pandarallel, должна быть автономной и не должна зависеть от внешних ресурсов.
https://nalepae.github.io/pandarallel/

🤷‍♀️Не все отсутствующие данные одинаково отсутствуют
Отсутствующие данные — это проблема, которая часто возникает в Data Science и машинном обучении. Есть множество причин, по которым данные могут отсутствовать, в зависимости от их типа и методов сбора. Но не все отсутствующие данные одинаковы, их можно разбить на следующие категории:
• Отсутствующие по причине невозможности их сбора или дороговизне этой процедуры
• Структурно отсутствующие данные, которые не могут быть получены из-за особенностей объектов исследований;
• Отсутствующие по причине случайного сбоя;
• Отсутствующие по неочевидным или неизвестным причинам.
В зависимости от причины отсутствия данных в датасете, можно сгладить или вовсе устранить это. Например, структурно отсутствующие данные предполагают изменение структуры вопросов об объекте исследования, чтобы ответы на них были получены. Вместо сбора редких или дорогостоящих данных можно выбрать прокси-метрики, которые позволяют принять решение. Постоянно повторяющиеся сбои необходимо устранить, а также больше узнавать о причинах отсутствия ожидаемых данных.
https://medium.com/@nahmed3536/types-of-missing-data-e718e6ac2a55