Клиентам требуется все больше и больше информации, основанной на их данных, но для этого необходимо наличие некоторых базовых ресурсов, позволяющих проводить более продвинутый анализ и методы. Существует множество инструментов и дисциплин, связанных с обработкой данных во всех аспектах, как локально, так и в виде облачных сервисов, но мы видим, что наши клиенты ценят сохранение определенного уровня владения всем процессом. В этом контексте Apache Airflow становится хорошим кандидатом на решение этой бизнес-задачи.

В этой статье описываются этапы проекта машинного обучения (ML) или науки о данных (DS) и исследуется, как решение рабочего процесса, такое как Apache Airflow, стоит рассматривать для хорошего конвейера данных.

Среды рабочих процессов для приложений машинного обучения и науки о данных

В настоящее время на рынке доступно множество различных решений для управления конвейерами и рабочими процессами с различными уровнями универсальности, сложности и адаптируемости. Среди множества функций и характеристик, которые они могут предоставить, важно проанализировать, как они поддерживают основные этапы проекта машинного обучения — не только окончательные рабочие процессы, но и то, как они поддерживают разработку и даже бесперебойную работу. переход от разведки к развертыванию, производству и обслуживанию.

Фаза исследования

Решение для рабочего процесса может не выглядеть как неотъемлемая часть этапа исследования, но есть два ключевых аспекта, которые они могут улучшить и поддержать как анализ данных, так и предварительные эксперименты:

  • Общие/универсальные подходы. После приема данные необходимо анализировать с помощью множества линз — от простого статистического анализа до более сложных шаблонов распределения, включая гистограммы по категориальным переменным, построение/визуализацию диаграмм и даже обучение. простых моделей для проверки основных свойств. Все эти шаги могут быть автоматически предоставлены в виде конвейера, который не только автоматически выполняет эти процессы, но также регистрирует и сохраняет результаты.
  • Простая интеграция с этапом разработки. После завершения первого начального анализа будет разработан более индивидуальный набор подходов к предварительной обработке и будут проведены эксперименты. Однако обычно либо повторно используют экспериментальный код (что обычно делается без всех шагов, необходимых для фактической разработки), либо запускают их полностью с нуля. Однако, если эксперименты уже выполняются внутри конвейера, может быть полезно медленное обновление их в контейнерном формате — как с концептуальной точки зрения (сохранение различных шагов независимыми друг от друга), так и с помощью таких структур, как контейнеры докеров в среде Kubernetes. Фактически, поскольку среда тестирования может быть также добавлена ​​в качестве еще одного рабочего процесса, тесты могут выполняться и сохраняться с самого раннего этапа и становятся сопоставимыми с решениями на этапе разработки, не вызывая повторного использования исследовательского кода в окончательной версии.

Этап разработки

Переход от исследования к разработке в проектах машинного обучения обычно является одним из самых радикальных и разрушительных изменений: путем объединения проверки концепции в реальный код необходимо решить многие характеристики и функции, которые могли быть проигнорированы на более ранних этапах.

Тремя основными областями, которые необходимо решить, являются нефункциональные требования (такие как безопасность и ведение журналов), соблюдение стандартов разработки (таких как модульное тестирование, шаблоны кодирования и структуры данных) и интеграция с решением в целом. На самом деле рекомендуется не использовать повторно какой-либо код из фазы исследования во время разработки, поскольку код исследования обычно нестабилен и не обязательно соответствует всем ожидаемым рекомендациям.

Решения для рабочих процессов очень полезны на этапе разработки по двум основным причинам:

  • Они позволяют сделать фактическую разработку и тестирование более интерактивными, с более короткими циклами кодирования и тестирования (что также включает бесшовную интеграцию, описанную в предыдущем разделе, поскольку большая часть кода, разработанного ранее, уже совместима с инфраструктурой разработки);
  • Поэтапная разработка: даже несмотря на то, что код этапа исследования не должен использоваться в окончательной версии продукта, благодаря естественному сегментированному модульному подходу рабочего процесса легче реализовать и заменить определенные фрагменты кода по мере их разработки, особенно когда интерфейсы фиксированы. Как объяснялось на предыдущем шаге, другие модули и задачи, которые были реализованы ранее, также можно легко интегрировать в рабочий процесс, избегая как повторной реализации, так и траты времени на интеграцию различных кодовых решений.

Этап развертывания

Развертывание часто упускается из виду при разработке решения для обработки данных или машинного обучения, но нередко развертывание решения требует значительного времени и усилий, особенно когда данные (или сама среда) являются конфиденциальными и хорошо защищенными. В этих случаях для развертывания часто требуется ручная настройка в локальной среде, которую затем необходимо снова протестировать.

Развертывание часто зависит от других инструментов и платформ, таких как API-интерфейсы REST или веб-серверы, которые должны быть доступны и обычно сильно отличаются от решения для данных. В то время как предыдущие этапы больше связаны с реальным приложением, во время развертывания будут учитываться другие внешние источники информации и управления, и эти среды могут быть очень разнородными. На самом деле, большинство из них будут за рамками приложения данных, поэтому эти коннекторы следует добавить в рабочий процесс на этом этапе.

В решении, основанном на рабочем процессе, не только фактическое развертывание и тестирование могут быть полностью автоматизированы с минимальным использованием дополнительного кода или без него, поскольку все шаги до сих пор могут быть повторно использованы, но также могут быть абстрагированы в многократно используемый рабочий процесс. После реализации общей задачи «от модели к производству» ее можно повторно использовать для различных моделей и приложений, просто заменив задачи в рабочем процессе, которые, например, будут генерировать модель запроса.

Фаза производства и обслуживания

Наконец, после того, как все шаги были реализованы и развернуты, пришло время поддерживать работоспособность системы. Это включает в себя отслеживание, регистрацию, непрерывное обучение, непрерывную оценку и, в конечном итоге, обновления программного обеспечения.

На данном этапе рабочие процессы уже являются очень распространенным решением, поскольку они позволяют четко отображать, отслеживать и планировать процессы. Основное преимущество в этом случае заключается в том, что все предыдущие шаги уже были реализованы в формате рабочего процесса, что позволяет избежать переделок и значительно упрощает обновление и доработку решений.

После разработки одного надежного рабочего процесса для непрерывного обучения и развертывания со всеми необходимыми инструментами ведения журналов и отслеживания простая замена задач может позволить его обновить, настроить на новые форматы вывода или даже повторно использовать для совершенно других решений для обработки данных. Поскольку каждая задача практически независима от других, интерфейсы — это единственное, что необходимо сохранять и поддерживать при переходе от одного рабочего процесса к другому.

Решения для рабочих процессов: основные характеристики

Помимо поддержки процессов машинного обучения, решение для рабочих процессов может улучшить разработку и производительность, обеспечивая интеграцию с инфраструктурой. Если такая интеграция существует, тесты производительности и стабильности могут быть выполнены на ранних стадиях разработки, а ресурсы могут использоваться оптимально.

Среди многих элементов инфраструктуры интеграция с облачными средами и кластерами, ориентированными на контейнеры (особенно Kubernetes), является одним из наиболее распространенных применений. Поскольку многие проекты машинного обучения имеют дело с защищенными данными, которые невозможно захватить, прочитать или обработать за пределами безопасной среды, следует рассмотреть возможность как облачной, так и локальной поддержки.

Интеграция с источниками данных и приемниками данных также имеет первостепенное значение — конвейерное решение, которое не обеспечивает такого рода интеграцию с широким спектром интерфейсов баз данных и сообщений, будет строго ограничено, как только проект выйдет из фазы разработки и достигнет систем в который он должен быть интегрирован.

Если среда рабочего процесса может обеспечить надежную готовую интеграцию с базами данных, а также может использовать как локальную, так и облачную инфраструктуру, время настройки будет сокращено, и многие проекты станут независимыми от этих внутренних решений. , значительно улучшая возможность обновления и скорость разработки.

Еще один ключевой аспект, который следует учитывать при разработке рабочего процесса для машинного обучения, — его интеграция с обслуживающими решениями. Модели имеют не более чем аналитическую ценность, когда они недоступны для использования конечными приложениями, и, даже если они не отображаются в режиме реального времени и не доступны конечным пользователям, время между разработкой решения и его использованием может быть сильно ограничено его возможностями. интеграция и доступность с другими системами.

Несмотря на то, что среда рабочего процесса не должна нести полную ответственность за окончательное развертывание, она должна предлагать инструменты для предоставления триггеров и результатов эффективным и модульным способом, который можно легко модифицировать и обновлять.

Наконец, структура рабочего процесса должна быть не только надежной, стабильной и хорошо связанной, но и помогать в разработке прототипов, новых проектах и ​​раннем анализе. Во многих случаях эти шаги выполняются полностью за пределами среды разработки и производства, поскольку это добавило бы ненужных накладных расходов на исследование и анализ. Если инфраструктура рабочего процесса может в то же время помочь в разработке ранних прототипов без дополнительных накладных расходов, а также обеспечить беспрепятственное продвижение других этапов разработки, она не будет препятствовать инновациям и не будет создавать ненужного компромисса между удобством использования и интеграцией.

Решения для рабочих процессов: варианты реализации

Решения для рабочих процессов могут показаться достаточно простыми, чтобы их можно было создавать на заказ, когда рассматриваются только функциональные возможности высокого уровня: простые последовательности задач могут быть определены путем объединения вызовов сценариев, а путем реализации всего с помощью языка сценариев можно было бы иметь легкий вес. решение, которое позволяет модульное определение и выполнение конвейеров. Однако более глубокий анализ выявит несколько ключевых проблем, связанных с этим подходом:

  • Интеграция с другими системами должна выполняться вручную и часто требует специалистов по каждой системе и технологии, включая базы данных, языки и системы сообщений.
  • Обслуживание системы, включая добавление новых функций и обновлений, потребуется каждый раз, когда одна из зависимостей получает крупное обновление. Хотя это не проблема для других типов решений, решение рабочего процесса, которое обеспечивает интеграцию, часто будет иметь дело с различными инструментами и технологиями, которые обновляются независимо.
  • Более сложные структуры рабочих процессов (которые предлагают несколько путей или условий) и оркестраторы должны быть реализованы с нуля и могут быть не такими тривиальными, как простые конвейеры.
  • Наконец, распределенное управление задачами — сложная операция, требующая не только опыта работы с такими платформами, как Kubernetes, но и значительного объема тестирования с учетом множества возможных конфигураций, системных ограничений и проблем.

Это означает, что, если ожидаемое решение не является достаточно простым и не требует надежной работы на различных платформах, индивидуальное решение для рабочего процесса может оказаться дорогостоящим для реализации и, особенно, для обслуживания.

Среди решений, доступных на рынке, можно найти две группы: специализированные фреймворки и универсальные фреймворки. Специализированные платформы включают в себя множество функций, помогающих решать определенные задачи, но им не хватает широкой интеграции с несколькими системами или гибкости для интеграции совершенно новых решений.

В качестве примера специализированной платформы для рабочих процессов Kubeflow представляет собой решение для рабочих процессов на основе kubernetes, основанное на Google Cloud Services (GCS) и ориентированное на приложения машинного обучения. Он предоставляет множество интересных функций, таких как встроенная интеграция с Jupyter Notebooks, отслеживание экспериментов и оптимизация гиперпараметров. С другой стороны, это также довольно тяжелое решение — для запуска всех его функций требуется 72 модуля, и оно лучше всего оптимизировано для работы именно на платформах GCS. Хотя они предлагают некоторые решения для других облачных провайдеров, таких как Azure и AWS, не все функции доступны во всех из них, а их поддержка локальных кластеров (которые распространены в проектах с очень конфиденциальными данными) ограничена.

В целом Kubeflow кажется хорошим решением для проектов, начинающихся с нуля, без необходимости интеграции в существующие системы и ориентированных на разработку моделей машинного обучения. Однако для проектов, которые уже хорошо консолидированы, с множеством требований и ограничений, уже определенных в среде kubernetes, интеграция может быть сложной и дорогостоящей. Хотя они обеспечивают хорошую интеграцию с очень специфическими инструментами, которые помогают на этапах исследования и разработки проекта данных, во многих проектах часто бывает так, что лучшим решением является то, которое поддерживает существующие системы и позволяет им расти и развиваться, охватывая множество этапы разработки (от исследования до обслуживания) и различные области (такие как испытания и развертывание).

С другой стороны, Apache Airflow — это легкое универсальное решение для рабочих процессов, которое предназначено для интеграции с существующими системами и предоставления им надежной платформы для конвейеров. Несмотря на то, что он не включает специализированные инструменты для ML, эта интеграция позволит этим рабочим процессам помочь не только во время исследования и разработки, но также во время развертывания, производства и обслуживания.

В следующем разделе более подробно рассматриваются ключевые характеристики Apache Airflow и то, как их можно использовать для поддержки всех этапов, описанных в предыдущих разделах.

Воздушный поток Apache

Apache Airflow — это универсальное конвейерное решение, предназначенное для поддержки различных типов задач и исполнителей в разнообразных средах — от локальных настроек до распределенных кластеров на основе Kubernetes. Он также предлагает надежную инфраструктуру, которая позволяет взаимодействовать и обслуживать конвейеры со встроенными планировщиками, веб-серверами и регистраторами. Наконец, он также обеспечивает высокий уровень интеграции со многими типами источников данных и механизмов выполнения, поддерживая широкий спектр приложений.

Эта структура основана на четырех ключевых понятиях: группы обеспечения доступности баз данных, задачи, операторы и исполнители:

  • DAG, сокращение от «направленные ациклические графы», являются конвейерами Apache Airflow. Их можно определить как ряд задач с отношением направленной зависимости, которые описывают рабочий процесс. Эти DAG могут быть определены явно — путем подключения Задач — или неявно, путем простого вызова аннотированных функций, которые позже будут преобразованы в граф. Группы DAG управляются Apache Airflow, от триггеров и API до передачи сообщений, а платформа также предоставляет метаданные, журналы и инструменты визуализации без дополнительной настройки.
  • Задачи – это строительные блоки, из которых формируются группы обеспечения доступности баз данных и которые определяют конкретные действия, которые необходимо выполнить. Их можно настраивать, параметризовать и совместно использовать в разных группах обеспечения доступности баз данных, что улучшает повторное использование и повышает гибкость разработки. Каждая задача построена поверх оператора.
  • Операторы — это базовые типы задач, которые позволяют Airflow выполнять все виды действий. Они переходят от операторов, выполняющих исходный код (таких как PythonOperator) и скриптов (таких как BashOperator), к наблюдателям за базой данных (таким как PostgresSensor) и даже генераторам модулей (таким как KubernetesOperator). Пользовательские операторы также могут быть определены путем выполнения задач в определенных или проприетарных системах, которые реализуют определенные интерфейсы Apache Airflow.
  • Исполнители, наконец, определяют, как и где будут выполняться задачи (которые являются экземплярами операторов в группе обеспечения доступности баз данных). Они варьируются от довольно простых LocalExecutors, которые будут выполнять каждую задачу одну за другой вместе с процессом планирования; вплоть до CeleryExecutors (которые используют Celery для создания модулей Worker и распределения задач между ними) и даже KubernetesExecutors, которые будут автоматически создавать новые модули в среде Kubernetes, предоставлять все необходимые данные, запускать задачи, возвращать результаты и, наконец, удалять созданные стручки.

Этот набор функций позволяет Apache Airflow изначально интегрироваться с другими решениями:

  • Источники данных могут быть подключены к Apache Airflow через модульные датчики — как те, которые уже реализованы в пакете, так и настраиваемые через предопределенные интерфейсы.
  • Аналогичным образом, внешние подключения можно установить через REST API Apache Airflow, который поставляется с контролем доступа и по умолчанию предоставляет как информацию, так и контроль над DAG и выполнением DAG.
  • Многие типы существующей инфраструктуры, включая кластеры Kubernetes, можно использовать с самого начала и совершенно незаметно для специалистов по данным. Исполнители могут быть настроены независимо от DAG и задач и настроены для оптимального использования ресурсов с помощью рабочих эфемерных модулей.
  • Регистрация, отслеживаемость и историческая информация также обеспечиваются Apache Airflow без необходимости дополнительной реализации или накладных расходов на стороне разработки. Доступ к зарегистрированным данным также можно получить через их пользовательский интерфейс, через REST API или напрямую из их базы метаданных.

Этот набор функций очень удобен для широкого круга приложений и не ограничивается проектами по науке о данных. Фактически универсальный подход Apache Airflow позволяет создавать различные типы проектов поверх его базовой структуры, а исполнители могут быть параметризованы, чтобы резервировать разные ресурсы для разных групп обеспечения доступности баз данных или приложений.

Эти характеристики, хотя и полезны для общего развития и желательны в среде науки о данных, сами по себе не покрывают полный набор требований, описанных в предыдущем разделе. Чтобы полностью улучшить проекты, связанные с данными, также ожидаются улучшения в разведке, разработке, развертывании и добыче — или, в более широком смысле, мощная поддержка как для создания прототипов новых решений, так и для поддержки полного жизненного цикла проекта, от концепции до производства. .

Первый момент, в котором может помочь Apache Airflow, заключается в его универсальном подходе: поскольку он основан на модульных задачах и настраиваемых DAG, отдельные задачи могут быть разделены между отдельными проектами, общие структуры DAG могут полностью использоваться повторно, а разработка может выполняться итеративно, заменяя конкретные задачи с совместимыми интерфейсами.

В качестве примера рассмотрим простой общий конвейер для раннего исследования модели:

Прежде всего, в Apache Airflow каждое выполнение этой DAG будет правильно записано в базу метаданных, что улучшит отслеживаемость и подотчетность.

Эта базовая структура может быть предопределена, и каждая из этих задач может сопровождаться любой необходимой предварительно реализованной логикой, которая подходит компании — дополнительные протоколы безопасности, конфигурации доступа по умолчанию, встроенные репозитории — которые всегда будут доступны по умолчанию.

Затем специалисты по данным могут сосредоточиться на задачах предварительной обработки, обучения и тестирования набора статических данных, просто заменив задачу LOAD (или ее реализацию) локальным вариантом. Позже, когда будут доступны фактические/живые данные, один модуль потребует замены — и этот модуль (который не нужно реализовывать в виде кода Python, поскольку Apache Airflow позволяет задачам иметь разные типы операторов) может быть управляются и внедряются специализированными командами Data Engineering независимо друг от друга.

По мере продвижения проекта реализация одной и той же задачи может быть улучшена по мере перехода от исследования к фактической разработке, включая группы обеспечения доступности баз данных с большим количеством задач и даже до развертывания. Поскольку все эти шаги можно выполнить в одной и той же структуре, ошибки интеграции будут сведены к минимуму и даже затраты на разработку снизятся, поскольку будет использоваться единая «прозрачная» среда.

Конфигурация исполнителя может быть изменена с локальной на рабочую или на основе Kubernetes без какого-либо прямого вмешательства в конкретные задачи, сохраняя полностью несвязанные задачи и инфраструктуру.

Более подробное описание операции машинного обучения в Apache Airflow можно найти в следующем разделе.

Воздушный поток для ETL и Data Lineage

ETL (аббревиатура от Extract, Transform and Load) — это процесс извлечения данных из разных источников, преобразования их с помощью фильтров, нормализации интервалов, вычислений (или даже получения новой информации из собранных данных), а затем загрузки преобразованных данных в уникальный и краткая система хранения данных (обычно хранилища данных). Поскольку ETL является одним из наиболее важных процессов в бизнесе, ориентированном на данные, крайне важно построить надежный и масштабируемый конвейер ETL.

Используя Apache Airflow, инженеры данных могут относительно просто создавать действительно сложные конвейеры ETL. Например, на этапе «Извлечение» мы можем воспользоваться несколькими операторами, разработанными сообществом, для одновременного извлечения данных из нескольких разных технологий, таких как PostgreSQL, Apache Cassandra, Amazon S3 и т. д. Если задача извлечения не удалась, мы может использовать механизм повтора для повторного запуска задачи через определенный период времени. Кроме того, в случае, если конвейер ETL может возникнуть только после того, как все данные будут доступны, мы можем использовать концепцию датчиков для автоматического запуска конвейера, как только будут обнаружены все необходимые данные. На этапе «Преобразование» мы можем воспользоваться параллелизмом планировщика Apache Airflow для одновременного выполнения нескольких задач преобразования по мере извлечения данных.

Специалистам по данным очень важно хорошо понимать данные и все изменения, которые они претерпели на этом пути, чтобы выявить возможные ошибки в обработке данных, исправить неправильные предположения о них, которые могут исказить анализ, и обеспечить высокое качество данных.

Благодаря гибкости Airflow мы можем определять новые операторы и пользовательские плагины для ведения полного журнала всех данных, включая источник данных, схему, владельца, когда они были извлечены, какие преобразования были применены, какие проблемы возникли во время извлечения и т. д. Кроме того, инженеры данных могут интегрировать Airflow с другими системами управления метаданными (такими как Marquez), чтобы обеспечить высокое качество передачи данных с меньшими усилиями по внедрению. Эти реализации можно сделать один раз и использовать модульным образом во многих рабочих процессах, обеспечивая повторное использование кода и высокую ремонтопригодность.

Воздушный поток для конвейеров машинного обучения

В дополнение к конвейерам данных огромные возможности Airflow делают его оптимальным вариантом для создания конвейеров машинного обучения как в среде разработки, так и в рабочей среде.

Например, представьте типичный конвейер машинного обучения, который начинается со сбора данных и заканчивается развертыванием. С помощью Airflow мы можем создавать надежные, масштабируемые и воспроизводимые конвейеры ML из централизованных исходных кодов, где каждый узел Airflow DAG является шагом в нашем конвейере ML, таким как обучение и проверка модели. Вместе с инструментами контроля версий и отслеживания экспериментов мы можем определить шаблон DAG, а затем автоматически отслеживать версию данных, используемых для обучения модели, изученные параметры и используемые гиперпараметры, время обучения и тестирования, двоичный формат модели и все необходимые зависимости. построить эту точную модель снова. Мы также можем использовать Airflow для реализации непрерывного обучения. Точнее, мы можем воспользоваться его датчиками, чтобы регулярно запускать конвейер переобучения для конкретной модели (например, каждую пятницу в 9 утра) или как только становятся доступны определенные данные.

Кроме того, существует несколько инструментов, предназначенных для создания конвейеров машинного обучения, которые используют Apache Airflow в качестве оркестратора. Классический пример — TensorFlow Extended (TFX), комплексная платформа для создания и развертывания готовых к работе конвейеров машинного обучения.

Ключевые выводы

Несмотря на многочисленные преимущества, использование Apache Airflow и оркестраторов рабочих процессов в целом не является бесплатным и не может быть рекомендовано для всех сценариев.

Во-первых, даже более легкие решения предназначены для выполнения в выделенных средах, поэтому их использование может оказаться нецелесообразным для проектов со строгими аппаратными ограничениями (например, для встроенных систем).

Во-вторых, рабочие процессы потребуют определенного уровня накладных расходов не только на реализацию, но и на экспертизу. Дополнительные затраты на реализацию обычно покрывают себя, если один или несколько проектов разрабатываются от начала до конца, но если прототипы никогда не разрабатывались, предварительное создание полной экосистемы выполнения может быть нежелательным. Решения для рабочих процессов требуют проектов с уровнем зрелости, в котором удобство обслуживания и воспроизводимость являются ключевыми интересами.

Также важно отметить, что, даже если разработка задач Apache Airflow и DAG довольно проста и обеспечивает интеграцию со многими различными технологиями, эти интеграции не всегда просты и могут потребовать дальнейшей специализации. Например, использование ресурсов на основе Kubernetes в Airflow требует некоторых знаний о конфигурации Kubernetes, по крайней мере, во время первоначальной настройки.

Наконец, Apache Airflow (и многие другие решения для рабочих процессов) не являются полными решениями, предназначенными для поддержки всех видов структур выполнения. Например, потоковая передача данных в реальном времени и конечные автоматы не полностью поддерживаются Apache Airflow и могут потребовать интеграции с другими решениями. Всегда можно использовать решения для рабочих процессов в качестве фреймворков высокого уровня, в которые интегрированы другие, более конкретные решения, но каждый случай следует изучать отдельно.

Выводы

Рабочие процессы — бесценный инструмент для обработки данных и, в частности, приложений машинного обучения — не только для обычных приложений автоматизации, но и как вспомогательный инструмент для исследования и разработки. Принятие рабочих процессов в качестве базовой структуры для разработки ML/DS может улучшить весь процесс и значительно сократить время от прототипа до развертывания продукта, а также полезно для создания пригодных для сопровождения, многократного использования и модульных исходных кодов.

Среди доступных технологий и сред для рабочих процессов, ориентированных на данные, Apache Airflow является наиболее универсальной и надежной реализацией благодаря легкости, гибкости и простой интеграции с другими технологиями. Большое сообщество и его встроенная поддержка множества других решений делают его хорошим выбором для проектов данных, которые предназначены для интеграции с другими уже существующими системами, в то время как специализированные решения, такие как Kubeflow, могут быть более полезными для новых проектов, которые не не полагаться на такие интеграции.

Подтверждение

Эта статья была написана Иваном Карамелло, специалистом по данным в Daitan. Спасибо Жоао Калеффи, Таллесу Сильве и Кэтлин Маккейб за обзоры и идеи.

Рекомендации