Запуск C++ process-функций в companion

C++ companion SDK выполняет process-функции в отдельном процессе под управлением воркера Flow. Этот вариант подходит, когда пользовательскому коду нужен отдельный исполняемый файл и адресное пространство. Соберите companion отдельно от воркера и раннера; воркер передаёт ему батчи через протокол companion.

Этот справочник предполагает, что у вас уже есть C++ process-функция и вы знакомы с настройкой и развёртыванием пайплайна. Регистрация и подключение показаны в поддерживаемом тестовом companion с ресурсами, его сборочном файле и спецификации пайплайна.

Регистрация функций и ресурсов

Используйте NYT::NFlow::NCompanionServer::TPipeline из yt/yt/flow/library/cpp/companion/server/pipeline.h. Заполните его до запуска сервера:

  • AddTransform<TFunction, TStaticParameters, TDynamicParameters>(computationId) объявляет обслуживаемый компьютейшен преобразования и регистрирует его process-функцию и схемы параметров.
  • AddSource<TFunction, TStaticParameters, TDynamicParameters>(computationId) объявляет обслуживаемый компьютейшен источника. Оба типа параметров по умолчанию — TEmptyProcessFunctionParameters.
  • AddResource<TResource>() регистрирует класс ресурса, размещённого в companion. Идентификаторы ресурсов задаются в спецификации, а не в этом вызове.

Идентификатор компьютейшена должен совпадать со спецификацией. Поле processing_function по-прежнему выбирает зарегистрированную функцию по имени C++-типа. Для этой регистрации типизированный API заменяет YT_FLOW_DEFINE_PROCESS_FUNCTION, а AddResource — YT_FLOW_DEFINE_RESOURCE. Не регистрируйте один тип обоими способами. Повторяющиеся идентификаторы компьютейшенов отклоняются.

Передайте заполненный пайплайн в NYT::NFlow::NCompanionServer::RunCompanionMain(argc, argv, std::move(pipeline)) из companion_main.h. В ya.make исполняемого файла нужна зависимость от yt/yt/flow/library/cpp/companion/server; добавьте зависимости своих функций и ресурсов. В сборочном файле тестового companion выше приведён полный список зависимостей для этого примера.

Подключение исполняемого файла к воркеру

  1. Разместите исполняемый файл companion и его зависимости в окружении джоба-воркера. Используйте существующую инструкцию развёртывания; путь в спецификации сам по себе не загружает исполняемый файл.
  2. Объявите ресурс NYT::NFlow::NCompanion::TCompanionManager. В его parameters.entrypoint задайте executable — абсолютный путь к исполняемому файлу в этом окружении. Поле args задаёт аргументы командной строки, а env — дополнительные переменные окружения.
  3. Для каждого компьютейшена выберите класс companion-компьютейшена в computation_class_name, задайте processing_function и добавьте зависимость от менеджера на воркере под псевдонимом CompanionManager (worker = %true, controller = %false). Идентификатор компьютейшена должен совпадать с переданным в AddTransform или AddSource.
  4. Если стандартный раннер flow_server использует типы функций, зарегистрированные только в companion, задайте abort_on_specs_parseability_error = %false в конфигурации раннера. Раннер не может разобрать тип функции, которого нет в его реестре. Исполняемый файл companion всё равно должен корректно зарегистрировать выбранную функцию и схемы параметров.

В тестовом окружении C++ companion показано это разделение: раннером служит flow_server, а точка входа менеджера указывает на C++-файл. Интеграционный тест проверяет выходные данные со значениями, загруженными в обслуживающем процессе companion.

Запуск и границы выполнения

RunCompanionMain запускает сервер companion. Ему нужны переданные воркером YT_FLOW_MODE=Worker и YT_FLOW_COMPANION_CONFIG с положительным RPC-портом port. Пайплайн запускайте раннером; точка входа companion не реализует команду запуска пайплайна раннера.

C++ companion работает в одном многопоточном процессе. Обеспечьте безопасность конкурентного доступа к общим объектам.

Поддерживаемые интерфейсы и их границы описаны в разделе Ограничения C++ companion. Выбирайте режим размещения явно: не все возможности process-функций в воркере доступны в отдельном процессе.

Ресурсы companion и HTTP-клиенты

Зарегистрируйте классы ресурсов через AddResource<TResource>() и подключите прокси на воркере по общей схеме. В методе Init process-функции вызов IRuntimeInitContext::GetStaticResource(alias) возвращает привязанный ресурс на стороне companion. Этот путь показан в тестовой функции. Ресурс, существующий только в воркере, не переносится в companion автоматически.

IRuntimeInitContext::GetHttpClient() и GetHttpsClient() предоставляют общие HTTP-клиенты. Задайте http_client_config, https_client_config и http_poller_threads в блоке companion конфигурации воркера; см. TCompanionConfig.

Исходный код и тесты

Предыдущая
Ресурсы
Следующая
Тестирование