Алексей, спасибо за комментарий, такой риск действительно есть. Это компромиссное решение. Накапливаем статистику, смотрим динамику. Меняем подход при необходимости.
Всем добрый день, хотим немного прояснить ситуацию: в заголовке статьи допущена неточность. Информация о том, что "Северсталь" "отключили от американского ПО" не соответствует действительности. Иностранные компании отказались от обслуживания и технической поддержки наших систем, но ПО продолжит работать. Мы накопили значительную экспертизу в этой области и сможем поддерживать промышленное ПО своими силами. Спасибо!
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 возникали проблемы (он потребляет намного больше памяти).
В рамках хакатона не разрабатывались промышленные решения, готовые к эксплуатации. Задачей хакатона было протестировать гипотезы бизнеса на предмет реализуемости и посоревноваться в подходах к решению. Оценка выполнялась по бизнес и по техническим показателям (для последнего запрашивался код, как и на любом хакатоне). Однако, как мы все знаем, от момента идеи/гипотезы до готового продукта долгий путь, требующий много ресурсов и времени. Поэтому говорить о ПО огромной стоимости на этом этапе не приходится)
Спасибо, мы действительно стараемся использовать современные практики и подходы в своей работе. Вы правы, рынок труда испытывает определенные сложности, особенно когда речь идет о квалифицированных кадрах, но это, увы, обусловлено ситуацией с подготовкой и развитием кадров в России в целом, а не проблемами в «Северстали». И все же так как мы считаем Хабр ИТ-ресурсом, давайте сфокусируемся на тех темах, ради которых создавалось это сообщество — ИТ новинки, разработки и прочее. Для других тем есть иные площадки
мы очень рады, что наш опыт полезен! сохраните, пожалуйста, в своей публикации ссылку на источник и все изменения, пожалуйста, не забудьте согласовать с нами. Спасибо!
Добрый день, огромное спасибо за комментарий - откорректировали неточность этого пункта
На самом деле это зависит от проекта и среды разработки.
спасибо за вопрос, у нас выбран корпоративным инструментом гитлаб, менять его пока не собираемся.
Пока выбираем инструменты, позже поделимся опытом.
Да, всё так, спасибо за рекомендацию!
Спасибо за то, что поделились мнением!
Алексей, спасибо за комментарий, такой риск действительно есть. Это компромиссное решение. Накапливаем статистику, смотрим динамику. Меняем подход при необходимости.
Сергей, спасибо большое, что поделились своим опытом! Очень интересно!
Спасибо за обратную связь!
Спасибо большое! Будем стараться!
Всем добрый день, хотим немного прояснить ситуацию: в заголовке статьи допущена неточность. Информация о том, что "Северсталь" "отключили от американского ПО" не соответствует действительности. Иностранные компании отказались от обслуживания и технической поддержки наших систем, но ПО продолжит работать. Мы накопили значительную экспертизу в этой области и сможем поддерживать промышленное ПО своими силами. Спасибо!
Добрый день!
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 возникали проблемы (он потребляет намного больше памяти).
Добрый день! Подскажите, каких именно деталей вам не хватило - в ИТ? По производственным процессам? Мы будем рады рассказать об дополнительно
В рамках хакатона не разрабатывались промышленные решения, готовые к эксплуатации. Задачей хакатона было протестировать гипотезы бизнеса на предмет реализуемости и посоревноваться в подходах к решению. Оценка выполнялась по бизнес и по техническим показателям (для последнего запрашивался код, как и на любом хакатоне). Однако, как мы все знаем, от момента идеи/гипотезы до готового продукта долгий путь, требующий много ресурсов и времени. Поэтому говорить о ПО огромной стоимости на этом этапе не приходится)