Преамбула

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

Мне показалось забавным вырезать из заготовок ADR одного из модулей, и превратить в статью на habr. Тем более, что это решение может потенциально интересным многим в отрасли. Правда, про РФ не уверен, уж больно стремительно умирает отечественная авиация. Но кто знает, что будет завтра, а опыт интересный. Авиа проекты всегда интересные, хоть и не всегда денежные.

Посему прошу предлагаю свой труд, и не бейте меня сильно ?

Контекст

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

В чем тут загвоздка:

А. В самом понятии - рейс. Есть рейс, который летит в точную дату, по точному маршруту и исполняется определенной авиакомпанией (назовем такой рейс атомарным). Есть, такой же рейс, но исполняемый несколькими партнерскими компания (не стану вас утруждать тонкостями всяких авиационных код-шерингов). Есть, рейс который как мини расписание - например, рейс который летает по пятницам, с 20 февраля, по 8 мая, по точному маршруту и исполняется определенной авиакомпанией (назовем такой рейс строкой в расписании). И так же вариант с группой компаний. 

Во всех четырех данных мы имеет отличающуюся структуру данных.

Назовем их, в порядке описания выше:

• атомарный рейс АК;

• атомарный рейс партнерский;

• строка в расписании АК;

• строка в партнерском расписании.

В.Происхождение самих объектов данных. Их генерируют несколько разных систем:

• система ведения долгосрочного расписания;

• систему управление оперативным расписание (то есть вот прямо сегодня завтра, как летаем);

• система согласования расписания движения Воздушных Судов;

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

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

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

Поступление рейсов неравномерное, оперативные меняются по одному - руками. За день порядка тысячи рейсов. А вот строки в расписании генерируются bulk, до 100 000 за раз.

Планируемые объемы, за пять лет - 50 000 000 записей о рейсах разных типов.

Применение Хранилища рейсов: 

1. Увязка с рейсами событий в Системе;

2. Построение визуального графика событий, связанных с рейсов. Проще говоря - оператор зайдет в web  интерфейс, выберет параметры рейса, нажмет на кнопку “Найти” и в ему визуализируется временная шкала, по каждому найденному рейсу, на которой пометки о событиях.

Принятое решение

Использовать в качестве СУБД - OpenSearch (пока это все таки старый добрый ElasticSearch).Напоминаю, для тех кто не в курсе, вендор изменил условия лицензирования ElasticSearch. И тогда разработчики сделали клон, который будет далее развиваться самостоятельно, и который условно бесплатный.

Почему ElasticSearch?

1. Потому что он у нас уже был и мы умели с ним работать;

2. В OpenSearch данные хранятся в виде JSON-документов. 

   1. Основная DB Системы устроена ровно так, то есть мы сохраняем преемственность и единообразие подхода;

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

3. OpenSearch - это качественный и проверенный поисковик, то есть он заточен именно на ту задачу, которая стояла перед нами.

Архитектурная схема

Схема верхнеуровневая. Все тонкости ETL, авторизации потребителей, преобразования и прочее не расписаны. Совсем немного пояснений:

1. В качестве брокера сообщений и FlowFile NiFi используется KAFKA;

2. В качестве ETL движка, как вы догадались, NiFi;

3. База данных на OpenSearch;

4. В качестве подарка паранойи ИБ - специальный API шлюз и права аккаунта корпоративной Active Directory (AD).

Возможные альтернативы

Kafka

Apache Kafka — это свободно распространяемый брокер сообщений, про него, кто только на habr не писал, включая меня Флейт как KAFKA / Хабр (habr.com) . Так что, если кто не знает, почитайте. Но, полагаю, на habr, что есть Kafka знает большинство.

Преимущества инструмента

1. Этот брокер у нас уже был и мы умели с ним работать;

2. Не надо усложнять архитектуры, добавляя новые СУБД, и создавая ETL схемы загрузки из Kafka в OpenSearch.

Минусы инструмента

1. Мы никогда не делали из Kafka поисковик;

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

ClickHouse

ClickHouse — это свободно распространяемая колоночная аналитическая СУБД, имени Яндекса. 

Преимущества инструмента

1. Надпись “Сделано в России”, можно цинично продать заказчику, как импортозамещение и получить на ровном месте плюшки. Как и поступает значительная часть российского IT;

2. Очень хорошо и быстро выполняет поисковые запросы.

Минусы инструмента

1. В команде нет специалистов с опытом работы ClickHouse (ну не считая меня, но я как то не могу все роли исполнять);

2. Менять структуру данных в ClickHouse не так уж и просто. А, как мы уже знаем, с какой скоростью будут фантазировать разработчики четырех систем источников, неизвестно.

Последствия

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

Тонким местом остается построение ETL процедур, при передачи из Kafka в OpenSearch (а мы помним, рейсы могут приходить из внешних систем, как по одному, так и в результате массовой генерации).

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