Comments 6
А что с производительностью? Все записи ведь обрабатываются последовательно
Спасибо за вопрос. В данной статье рассматривается заготовок кода, который можно заполнить своей бизнес-логикой. Да, записи поступают в алгоритм последовательно (можно сделать пачками, но тоже последовательно). Идея этой статьи возникла после реализации промышленного ETL-процесса, в котором каждая команда представляла из себя обращение к другой БД и/или сторонней апишки, т.е. i/o операцию. Поэтому производительность можно получить при реализации данных команд асинхронным способом.
Сеейчас с телефона сложновато детально смотреть код. А что насчёт загрузки ВСЕХ процессорных ядер? Или предполагается поднимать копии скриптов?
В данной статье не рассматривается разработка многопоточных и многопроцессорных приложений. Поднимать копии скриптов не вариант, т.к. источник входных данных для etl-процесса один. Т.е. копии скрипта будут "брать на борт" одни и те же данные. А вот использовать многопоточную/многопроцессорную обработку для требовательных к вычислительным ресурсам функций вполне уместно.
Дело в том что у меня есть опыт разработки комбинирования конкуреной и многопроцессорной архитектуры. Собственно сбор данных для ETL порядка 2ТБ ежесуточно.
Вопросов к anyio не возникало, но хорошо и надежно нагрузить все ядра так и не удалось, нет-нет раз в неделю все подписало. В итоге переделал все на GO как итог скорость почти в 5 раз возросла и проблемы ушли.
Но вот ETL, он на другом сотруднике, остаётся на базовом питоне. И тут было бы неплохо нам расшить. Вот я и подумал может есть опыт )
Асинхронный ETL-процесс на Python