Всем привет! На связи Никита Скирдин, программист 1С ИТ-интегратора «Белый код». Статья появилась как результат небольшого исследования для одного из наших клиентов. Заказчик обратился с вопросом выбора интеграционного решения. Здесь оставляю результаты.

Дано: 2 самописные системы на JS и PHP (операционный контур), «1С:ERP» (учет и финконтур), «Битрикс24» (для работы с лидами и сделками), Postgress (DWH), Power BI (аналитика).

Задачи для интеграционного решения:

  • перевод интеграций точка-точка -> звезда;

  • возможность, отправив данные один раз, обработать в нескольких получателях;

  • возможность прочитать отправленные пакеты еще раз;

  • гарантированная доставка данных.

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

Пока подписывали документы клиент вернулся с вопросом: можем ли мы использовать open source интеграционное решение Apache NiFi для решения обозначенных задач?

Разбираемся в этом вопросе.

ESB vs ETL

Строго говоря, DATAREON и NiFi продукты разного класса и разного назначения. 

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

В основе DATAREONESB-решение, основная функция которого — обеспечивать событийный обмен сообщениями. 

Если погуглить тему ESB vs ETL, попадется много холиварных статей, продукты развиваются, границы стираются. NiFi вполне способна организовать событийный обмен. DATAREON вообще давно уже не только ESB, но и КХД, местами DATAREON можно использовать как ETL. Поэтому не будем придираться к аббревиатурам, назовем все это интеграционными решениями и посмотрим доступный функционал. 

Функции интеграционного решения

Для себя мы выделили следующие функции, которые важны для интеграционного решения:

  1. Маршрутизации сообщений

  2. Очереди сообщений

  3. Возможность повторной отправки сообщения в случае ошибки

  4. Валидация данных (контракты)

  5. Готовые коннекторы

  6. Средства мониторинга

  7. Отказоустойчивость

Пройдемся по пунктам.

Маршрутизация сообщений

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

Apache NiFi

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

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

Процессоры маршрутизации могут определять логику маршрута как на основании атрибутов, так и по телу сообщения. 

DATAREON

DATAREON в качестве сообщения оперирует переменными. У каждой переменной есть тип, который может быть примитивным или сложным. Для простоты понимания, сложный тип можно представить в виде JSON — все, что можно описать в JSON (структуры, массивы), тоже самое можно описать в типе данных. Чтобы не заводить типы данных вручную, их можно импортировать из JSON, СУБД или из метаданных 1С. 

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

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

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

Очереди сообщений

Apache NiFi

В NiFi очереди образуются на стыках между процессорами. Сами процессоры — это блоки, которые что-то делают с данными (извлекают из внешней системы, обрабатывают или передают во внешнюю систему). Процессоры соединяются между собой стрелками и таким образом формируется поток данных. Стрелки бывают двух типов: 

  1. От одного процессора к другому. Отмечено цифрой 1 на рисунке. 

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

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

Отображаются метаданные сообщения, атрибуты сообщения (полезная нагрузка). Есть возможность скачать или посмотреть само сообщение. 

DATAREON

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

Очереди в DATAREON доступны во внешних системах (1), в сервисе обработки (2) и в разделе «Сервер» (3). Во внешней системе отображаются очереди, образовавшиеся при чтении или вставке во внешнюю систему. На сервисе обработки очередь образуется в случае задержки обработки между шагами процесса или между процессами. Очередь на сервере аккумулирует информацию со всех очередей (внешних систем и сервиса обработки) именно этого сервера. 

В сообщение также можно провалиться, посмотреть и скачать метаданные и содержимое сообщения.

Возможность повторной отправки сообщения в случае ошибки

В обоих сервисах есть возможность повторной отправки сообщений.

Apache NiFi

В меню NiFi есть отдельная вкладка под названием Data Provenance, которая позволяет просмотреть все события, связанные с каждым файлом потока.

Каждое событие можно раскрыть, чтобы просмотреть детальную информацию или происхождение (Lineage) данных.

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

DATAREON

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

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

Для отправки одного сообщения проще провалиться в сообщение и нажать кнопку отправки в повторную обработку. 

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

Валидация данных

Apache NiFi

В NiFi существуют широкие возможности по валидации данных различными способами. Формат JSON можно валидировать с помощью спецификаций JSON Schema. XML валидируется с помощью XSD-документа. Также есть возможность использовать Avro-схему или писать собственные валидаторы на скриптовых языках Groovy или Clojure для любых форматов данных.

DATAREON

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

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

Готовые коннекторы

Apache NiFi

NiFi (версия 2.2.0) предоставляет в общей сумме 274 различных процессоров для получения, обработки и отправки данных. Коннекторов для получения данных (тег consume) — 20. Есть возможность получать данные по таким распространенным протоколам, как WebSocket, IMAP, MQTT, HTTP, POP3, AMQP, JMS. Также реализованы процессоры для получения данных из поддерживающих JDBC-драйвер баз данных, Elasticsearch, Kafka.

Помимо вышеперечисленного есть коннекторы к различным западным системам, например, Azure, Amazon, Google Cloud, Slack.

В случае, если готовых коннекторов не хватает, можно разработать собственные процессоры на языке Java или Python.

DATAREON

В DATAREON из коробки доступны коннекторы к распространенным системам и протоколам: СУБД (MS SQL, PostgreSQL, Oracle DB2), HTTP (коннектор для REST или SOAP), SMTP. Помимо подключения по распространенным протоколам, возможно подключение к DATAREON ESB для коммуникации с другими серверами, а также к 1С, что будет полезно для отечественных компаний, ведущих учет в данной системе.

Возможно приобретение за дополнительную плату программируемых коннекторов к таким протоколам, как LDAP, ADO.Net или ODBC (базы данных), AMQP, JMS, FTP, AS2, IBM MQ, TCP Bridge и Apache Kafka. При этом DATAREON активно развивается и добавляет новые коннекторы в свою поставку.

Если готовых коннекторов недостаточно, есть возможность разработать собственный коннектор на языке C#.

Средства мониторинга

Apache NiFi

Для мониторинга происходящих в процессе отладки процессов интеграции ошибок можно использовать бюллетень (NiFi Bulletin Board), на котором отображаются все ошибки, произошедшие за последнее время. Важно отметить, что все сообщения, которые собираются в бюллетене, также попадают в лог NiFi, расположенный в ${NIFI_DIR}/logs/nifi-app.log.

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

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

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

DATAREON

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

Всего в DATAREON около 42 различных показателей, которые можно вывести на графики в Центре мониторинга и администрирования. При этом по сравнению с NiFi, где возможно выбрать и смотреть только один из графиков, в DATAREON возможно составить Dashboard под собственные нужды.

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

Отказоустойчивость

Apache NiFi

Одним из способов обеспечения отказоустойчивости в NiFi является хранение данных Файлов на жестком диске. Хранится каждая версия Файла, т. е. при каждом изменении Файла старые данные не удаляются. В случае остановки сервера NiFi необработанные Файлы не будут утеряны.

Дополнительно отказоустойчивость достигается за счет кластеризации. Есть возможность подключить несколько серверов NiFi к Apache ZooKeeper. ZooKeeper автоматически выберет узел-координатор, который затем будет контролировать доступность других узлов, актуальность потока обработки у каждого узла и распределять данные по узлам.

Если один из узлов перестает отправлять узлу-координатору heartbeat-запросы, то координатор отключает узел от кластера. Если же сам узел-координатор выходит из строя, то с помощью ZooKeeper автоматически выбирается новый основной узел.

В NiFi доступна гибкая настройка выполнения каждого процессора: есть возможность настроить выполнение отдельных процессоров только на основном узле, чтобы избежать, например, чтения одного и того же файла с FTP-сервера.

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

DATAREON

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

Количество узлов в кластере в рамках одного информационного контура не ограничено и не требует дополнительных лицензий.

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

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

Результаты тестирования HTTP-сервера

Для тестирования производительности систем были созданы HTTP-сервера в NiFi и DATAREON. На эти сервера была отправлена нагрузка с разным целевым количеством запросов в секунду (RPS). Оба сервера возвращали ответ на запрос с данными сразу, а сами данные помещали в очередь на обработку, это позволяет использовать интеграционную систему в качестве буфера сообщений. Также для проверки времени, затраченного на вставку данных в БД, в таблицы было добавлено поле, содержащее время обновления записи.

Целевые значения RPS варьировались от 100 до 1500 с шагом 100. На каждое целевое значение отправлялись асинхронные запросы к интеграционной системе в течение 10 секунд.

По результатам тестирования получили:

  • Средний RPS. NiFi: 266.25 (пиковый 636), Datareon: 195.44 (пиковый 281).

  • Количество принятых и обработанных системой объектов. NiFi: 47600, Datareon: 34499.

  • Время, затраченное на вставку данных в PostgreSQL. NiFi: 7:24, Datareon: 7:51.

  • Скорость вставки упиралась в скорость СУБД, а не интеграционных систем.

Результаты тестирования представлены на рисунках ниже:

Выводы

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

В первую очередь нужно смотреть на перечень интегрируемых систем и возможности шины по интеграции с этими системами. Причем желательно провести небольшой пилот, пощупать руками, как эта связка работает. Дьявол кроется в деталях, наличие коннектора к какой-либо системе, еще не означает, что этот коннектор удобно использовать для ваших целей. Да и в целом стоит оценить подходы к решению задач. В DATAREON больше структурности, подход «по умолчанию» предполагает укладывание всех транслируемых данных в структуры. В NiFi нет такой необходимости, flowfile может содержать все, что угодно, у разработчика полная свобода и отсутствии границ в творчестве. Это, с одной стороны, хорошо, хотя бы потому, что не нужно тратить время на описание этих структур. С другой стороны, полная свобода может привести к тому, что проект, созданный одним сотрудником, будет сложно передать другому. 

Разумеется, при выборе шины данных важен и денежный вопрос. DATAREON требует оплаты лицензий и ежегодной поддержки в размере 15% от стоимости лицензий. NiFi поставляется бесплатно. Но как и со всеми open source продуктами нужно понимать, что NiFi решает одну узкую задачу — позволяет настроить интеграционные потоки. Хотите кластер — нужно разобраться с ZooKeeper. Хотите мониторинг — добро пожаловать в Kibana и ELK-стек. В общем open source позволяет решить все задачи, главное, чтобы в компании была команда, готовая решать эти задачи. Ну и раз уж начали о денежном вопросе, не стоит забывать о ФОТ этой команды. 

Мы часто проводим пилоты для разных компаний и помогаем в выборе ESB. Также есть сообщество в Телеграме «Шины на для машины», там в первую очередь публикуются обзоры на отечественные интеграционные платформы и шины данных. Кстати, там же можно пообщаться напрямую с вендорами, например, с представителями DATAREON, Factor-ESB, USEBUS и другими.

Комментарии (0)