Информационный обмен или как реализовать транспорт данных?

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

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

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

Рассмотрим простой кейс:

  1. Клиент оставил заявку на сайте банка – включилась передача данных с веб-формы в базу данных на бэк;
  2. Он запросил большой кредит: надо передать его персональные данные в сервис скоринга и получить решение;
  3. Банк готов сотрудничать с этим клиентом – необходимо передать статус по заявке для отображения личном кабинете;
  4. Кредит выдан, теперь его надо включить в отчетность, значит, он попадет в регулярные обновления данных в DWH.

Схема транспорта данных

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

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

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

Прежде всего, разделим интеграции на две категории:

  • онлайн-интеграции;
  • интеграции с задержкой во времени.

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

А вот когда тот же клиент совершает покупку на борту самолёта, моментального обмена данными быть не может, поскольку отсутствует подключение к сети. Все операции накапливаются в POS-терминале, а по приземлении самолёта происходит процессинг всех оффлайновых операций. В данном случае это интеграция с задержкой во времени. Как правило, передача данных с лагом во времени допускается при невозможности получить моментальный ответ от смежной системы, или при передаче больших объемов данных (например, в DWH и BI-системы).

Онлайн-интеграции

Самый распространенный способ моментального обмена данными – через API (Application Programming Interface).

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

Схема сервис-ориентированной архитектуры

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

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

К преимуществам SOAP относится использование XML для кодирования запросов и ответов, а также строгую типизацию данных, гарантирующую их целостность при передаче между клиентом и сервером. В свою очередь, в модели REST отсутствуют встроенные требования к типизации данных, поэтому пакеты запросов и ответов в REST имеют намного меньшие размеры, чем SOAP. Благодаря скорости обмена данными именно REST API предоставляется такими соцсетями, как VK, Facebook, Twitter.

Обмен данными с задержкой

В ряде случаев данные могут попадать в систему-потребитель актуальными на момент времени в прошлом. Например, система-потребитель может разом забрать данные, накопленные в системе-источнике за определенный период. Схема обмена данными выглядит так: «оставьте мне данные в таком-то месте, я заберу их, когда мне будет удобно». Такая схема обмена удобна, когда изменения в системе-источнике происходят слишком часто и в больших количествах, и моментальный обмен невозможен из-за большой нагрузки на базы данных и транспортное ПО. Поэтому система-источник накапливает изменения данных и затем передает эту дельту всем заинтересованным сторонам.

Существует несколько подходов к такому обмену данными.

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

Вариант 1

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

Вариант 2

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

Еще один из способов «оставить» где-то данные для потребителя – сложить их в очередь (наиболее популярны на рынке сейчас kafka и rabbitmq). На самом деле, очереди могут быть использованы как для моментальной передачи (можно передавать сообщения в очереди с высокой пропускной способностью, где они быстро будут вычитаны подписчиком), так и для передачи больших пакетов данных, которые подписчик вычитывает не в моменте, а по определенному таймингу.

Вариант 3

Что же выбрать?

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

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

Валерия Новицкая

Магистр бизнес-информатики Высшей школы экономики (направление моделирования и оптимизации бизнес-процессов). Ведущий системный аналитик, эксперт по системным интеграциям.
1 reply on “ Информационный обмен или как реализовать транспорт данных? ”
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *