Comments 4
Круто! Пара вопросов:
Оценивали ли вы накладные расходы (не знаю, правильное ли это слово - хотел написать тут overhead) вышего фреймворка? Если у меня простая модель которая выдает решение за 1-2 миллисекунды, то сколько мне прибавит blocks в простейшем конвеере (провалидировать данные, применить модель)?
Добрый день!
1. По Faust- в свое время смотрели на него, как на движок для моделей, но в первую очередь остановила aiokafka (по крайней мере на тот момент - поверх kafka-python, которая по нашим замерам была на порядки медленнее confluent-kafka). И несмотря на то, что репозиторий переехал в faust-streaming, кажется, это до сих пор так.- в faust нём больше движущихся частей и возможностей (и по синтаксису и по способам организации кода), поэтому, можно сказать, что он сложнее.- не совсем подходит под наши задачи: ML самодостаточно работает от топика до топика и асинхронность там попросту не нужна (например, если мы являемся частью управляющего контура). Поэтому нам редко нужно встраивать модели в какой-либо backend, что хорошо умеет faust;По Streamz- тоже смотрели на эту библиотеку. По большому счёту, наверное, всё-таки разница в организации кода и типовых аннотациях. В typed-blocks напрямую объединять части пайплайна всё-таки не нужно и фокус больше на то, чтобы было легко писать любые свои агрегации (в streamz есть стандартные из коробки). Из похожих библиотек ещё можно вспомнить fn_graph и там тоже композировать код нужно совсем явно.
2. Какого-то строгого измерения в попугаях и бенчмарка у нас нет.
В теории, в зависимости от того, насколько мельчить с эвентами - может появиться чувствительная задержка. Просто потому что интерпретатору нужно будет постоянно создавать новые объекты.
Наверное, с ходу основных три источника потенциальных проблем:
- сами процессоры. Тут всё "просто" и зависит от конкретного кода, всегда можно написать какой-нибудь стейт, в котором сложность операций с течением времени будет расти по экспоненте и все будет плохо).
- источник данных/транспорт. В случае с Kafka у нас используется librdkafka + fastavro, так что тут за нас всё сделали на С/С++ со всеми вытекающими. С Redis Streams всё проще, зависит там только зависит от наличия/способа (де)сериализации данных.
- сами события. Если брать накладные расходы на перепаковку в структуры, то тут есть выбор, что использовать в качестве базы для эвентов - namedtuple/датаклассы/обычные python-классы или pydantic. Соответственно иногда выбираем их в зависимости от задачи. Бывало, что на pydantic возникали проблемы (он потребляет намного больше памяти).
А это - реальный граф вычислений одной из управляющих агрегатом моделей
Как можно такой построить? App(blocks)._graph как-то визуализировать можно?
Почему в «Северсталь Диджитал» сделали свою библиотеку для организации кода в машинном обучении и к чему это привело