👀Наглядный ETL с VDP
VDP (Visual Data Preparation) — это инструмент ETL визуальных данных с открытым исходным кодом для оптимизации сквозного конвейера обработки визуальных данных. Он включает извлечение неструктурированных визуальных данных из предварительно созданных источников данных, таких как облачное/локальное хранилище или устройства IoT, их преобразование в анализируемые структурированные данные с помощью моделей Vision AI и загрузку обработанных данные в хранилища, приложения или другие места назначения.
VDP оптимизирует сквозной конвейер обработки визуальных данных, позволяя разработчикам не создавать свои собственные коннекторы, платформы обслуживания моделей и инструменты автоматизации ELT. С VDP интеграция визуальных данных становится проще и быстрее. VDP выпущена под лицензией Apache 2.0, доступна для локального и облачного развертывания в Kubernetes. VDP построен с точки зрения управления данными, чтобы оптимизировать сквозной поток визуальных данных с помощью компонента преобразования, который может гибко импортировать модели Vision AI из разных источников. Построение ETL-конвейера становится похоже на сборку из готовых блоков, как в детском конструкторе. А высокая производительность обеспечивается бэкэндом на Go с Triton Inference Server с мощными архитектурами графических процессоров NVIDIA, поддерживающими TensorRT, PyTorch, TensorFlow, ONNX и Python.
VDP также соответствует идеям MLOps, позволяя импортировать и развертывать ML/DL-модели одним щелчком мыши из GitHub, Hugging Face или облачного хранилища, управляемого инструментами контроля версий, такими как DVC или ArtiVC. Стандартизированные форматы вывода CV Task упрощают работу с хранилищем данных, а готовые ETL-коннекторы обеспечивают расширенный доступ к данным благодаря интеграции с Airbyte.
VDP поддерживает различные сценарии исполььзования: синхронный режим для логических выводов в реальном времени и асинхронный - для рабочей нагрузки по запросу. Масштабируемый микросервисный дизайн на основе API удобен для разработчика за счет бесшовной интеграции с современным стеком данных. NoCode/Low Code интерфейсы снижают порог входа в технологию, предоставляя Data Scientist’у и аналитику независимость от инженерии данных.
https://github.com/instill-ai/vdp

🥒7 причин не использовать Pickle для сохранения ML-моделей
Data Scientist часто пишет код в блокнотах типа Jupyter Notebook, Google Colab или специализированных IDE. Чтобы перенести этот код в производственную среду, его надо преобразовать в легковесный формат обмена, сжатый и сериализованный, который не зависит от языка разработки. Одним из таких форматов является Pickle – бинарный вариант Python-объекта для сериализации и десериализации его структуры, преобразующий иерархию объектов Python в поток байтов и наоборот. Формат Pickle довольно популярен за счет своей легковесности. Он не требует схемы данных и весьма распространен, но имеет ряд недостатков:
• Небезопасно. Можно распаковывать только те pickle-файлы, которым вы доверяете. Злоумышленник может создать вредоносные данные, которые будут выполнять произвольный код во время распаковки. Смягчить этот риск можно через подписи данных с помощью hmac, чтобы убедиться, что они не были подделаны. Ненадежность связана не с тем, что Pickle содержат код, а с тем, что они создают объекты, вызывая конструкторы, упомянутые в файле. Любой вызываемый объект может использоваться вместо имени класса для создания объектов. Вредоносный код будут использовать другие вызываемые объекты Python в качестве конструкторов.
• Рассогласование кода. Если код изменится за время между упаковкой ML-модели в Pickle-файл и моментом его использования, объекты могут не соответствовать коду. Они по-прежнему будут иметь структуру, созданную старым кодом, но пытаться работать с его новой версией. Например, если атрибут был добавлен после создания Pickle, объекты из Pickle-файла не будут иметь этого атрибута. А если в новой версии кода предполагается его обработка, возникнут проблемы.
• Неявная сериализация. С одной стороны, формат Pickle удобен тем, что он сериализует любую структуру Python-объекта. Но при этом нет возможности указать предпочтения по сериализации того или иного типа даны. Pickle сериализует все в объектах, даже данные, которые не нужно сериализовать. Но пропустить сериализацию того или иного атрибута в Pickle нет возможности. Если объект содержит атрибут, который нельзя упаковать, например, объект с открытым файлом, Pickle не пропустит его, настаивая на попытке его упаковать, а затем выдаст исключение.
• Отсутствие инициализации. Pickle хранит всю структуру объектов. Когда модуль Pickle воссоздает объекты, он не вызывает метод init, поскольку объект уже создан, считая инициализацию вызванной, когда объект был впервые создан в процессе создания Pickle-файла. Но метод init может выполнять некоторые важные действия, например открывать файловые объекты. В этом случае необработанные объекты будут находиться в состоянии, несовместимом с методом init. Или инициализация может регистрировать информацию о создаваемом объекте. Тогда невыбранные объекты не будут отображаться в общем логе.
• Нечитаемый. Pickle — это поток двоичных данных, т.е. инструкции для абстрактного механизма выполнения. Открыв Pickle как обычный файл, его содержимое нельзя прочитать. Чтобы узнать, что находится в нем, придется использовать модуль Pickle для загрузки. Это может затруднить отладку, поскольку сложно искать нужные данные в двоичных файлах.
• Привязка к Python. Будучи Python-библиотекой, Pickle специфичен для этого языка программирования. Хотя сам формат может использоваться для других языков программирования, найти пакеты, обеспечивающие такие возможности, довольно трудно. Кроме того, они будут ограничены межъязыковыми общими структурами объектов list/dict. Pickle без проблем сериализует объекты, содержащие вызываемые функции и классы. Но формат не хранит код, а только имя функции или класса. При распаковке данных имена функций используются для поиска существующего кода в запущенном процессе.
• Медленный. Наконец, по сравнению с другими методами сериализации, Pickle работает намного медленнее.
Поэтому MLOps-инженеру для переноса ML-моделей лучше рассмотреть другие универсальные форматы упаковки алгоритмов машинного обучения: JSON, marshal, cattrs и protocol buffers, ONNX, PMML или NNEF.

🌴🌲🌳Деревья решений: краткий ликбез
Деревья решений – это один из наиболее широко используемых и практичных методов обучения с учителем. Они строятся с помощью алгоритмического подхода, который определяет способы разделения набора данных на основе различных условий. Деревья решений являются непараметрическими контролируемыми методами обучения и отлично подходят для работы с табличными данными, задач классификации и регрессии. Они помогают создать модель, которая предсказывает значение целевой переменной, изучая простые правила принятия решений, выведенные из характеристик данных.
Дерево решений работает как для непрерывных, так и для категориальных выходных данных. Алгоритм учится на простых правилах принятия решений, используя различные функции данных. В деревьях решений для классификации модель задает правильные вопросы в нужном узле, чтобы дать точную и эффективную классификацию с использованием энтропии и прироста информации. Энтропия — это мера неопределенности или случайности в наборе данных. Энтропия обрабатывает то, как дерево решений разбивает данные. Прирост информации измеряет снижение энтропии после разделения набора данных. Индекс Джини используется для определения правильной переменной для разделения узлов. Он измеряет, как часто случайно выбранная переменная будет неправильно идентифицирована.
Корневой узел всегда является верхним узлом дерева решений. Он представляет всю совокупность или выборку данных и может быть дополнительно разделен на различные наборы. А дочерние узлы решений содержат не менее двух ветвей. Листовой узел в дереве решений содержит окончательные результаты. Эти узлы, также известные как конечные узлы, не могут быть разделены дальше.
Метод применим для определения вероятности дефолта заявителя по кредиту, развития у человека определенного заболевания, определения показателей оттока клиентов и предсказания покупки товаров.
Преимущества использования деревьев решений:
• просты для понимания, интерпретации и визуализации.
• могут эффективно обрабатывать как числовые, так и категориальные данные.
• могут определить наихудшие, наилучшие и ожидаемые значения для нескольких сценариев.
• требуют небольшой подготовки данных и нормализации данных
• работают хорошо, даже если фактическая модель нарушает предположения
Недостатки метода:
• Переобучение, которое случается, когда алгоритм обучения продолжает разрабатывать гипотезы, снижающие ошибку обучающего набора данных за счет увеличения ошибки тестового датасета. Эту проблему можно решить, обрезав и установив ограничения на параметры модели.
• нельзя использовать с непрерывными числовыми переменными.
• Небольшое изменение данных приводит к большим различиям в древовидной структуре, что вызывает нестабильность.
https://blog.devgenius.io/decision-tree-regression-in-machine-learning-3ea6c734eb51

👍ETL и интеграция данных с Airbyte
Ключевым компонентом любого конвейера данных является извлечение данных. После извлечения данных их необходимо загрузить и преобразовать, выполнив все операции ELT. Сделать это проще с Airbyte — платформой интеграции данных с открытым исходным кодом, целью которой является стандартизация и упрощение процесса извлечения и загрузки. Airbyte работает по принципу ELT, извлекая необработанные данные и загружая их в места назначения. Также Airbyte позволяет выполнять преобразование данных, отделяя их от фаз EL. Это упрощает процесс, создавая коннекторы между источниками данных и местами их назначения. Airbyte является системой на основе плагинов, где можно быстро создать собственный настраиваемый коннектор с помощью CDK.
Если не хватает готовых 170+ коннекторов и 25+ мест назначения, можно разработать собственный. В Airbyte есть встроенный планировщик, обеспечивающий различную частоту синхронизации, поддерживается интеграция с AirFlow и dbt. Он доступен на платформе K8s, включает octavia-cli с шаблоном YAML для развертывания и поддерживает CDC почти в реальном времени.
Однако, фреймворк все еще находится в альфа-версии, не поддерживает аутентификацию на основе ролей IAM в сервисах AWS. Нет встроенной поддержки Prometheus, хотя недавно добавлена Open Telemetry. В Airbyte нет поддержки управления доступом пользователей и воспроизведения конкретного экземпляра выполнения задания. А также работа может замедляться при 2000+ одновременных заданий.
https://airbyte.com/

🤔Как извлечь таблицы из PDF? Попробуй Camelot!
Open-source библиотека Camelot помогает извлекать таблицы из PDF-файлов. Перед ее установкой нужно поставить библиотеки Tkinter и Ghostscript. Установить эти библиотеки можно через менеджеры пакетов pip или conda:
pip install camelot-py
conda install -c conda-forge camelot-py
Далее нужно, как обычно, импортировать нужный модуль из библиотеки, чтобы использовать его методы:
import Camelot
tables = camelot.read_pdf('foo.pdf', pages='1', flavor='lattice')
Параметр flavor по умолчанию настроен на решетку (lattice), но его можно перенастроить на поток (stream). Решетка более детерминирована по своей природе и отлично подходит для анализа таблиц, где есть разграничительные линии между ячейками. Это позволяет автоматически анализировать несколько таблиц, присутствующих на странице. Решетка преобразует страницу PDF в изображение с помощью библиотеки ghostscript, а затем обрабатывает его, чтобы получить горизонтальные и вертикальные линейные сегменты, применяя набор морфологических преобразований с помощью OpenCV.
Для извлечения таблицы из PDF используется метод export(), чтобы затем распечатать ее как датафрейм или экспортировать в файл CSV:
tables.export('foo.csv', f='csv', compress=True)
tables[0].to_csv('foo.csv') # to a csv file
print(tables[0].df) # to a df
https://camelot-py.readthedocs.io/en/master/user/install.html

Одна из крутых способностей DALL-E — возможность удалять объекты на фотографии так, будто их там и не было.

@aitspace

🍁У нас в октябре планируются следующие 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 алгоритмов.