Преамбула
В исполнение NDA, для кого был проект, не скажу - то ли авиапредприятие, то ли авиакомпания (российская). Проект в разработку не пошел, ограничились концепцией, предварительным анализом и архитектурой.
Мне показалось забавным вырезать из заготовок ADR одного из модулей, и превратить в статью на habr. Тем более, что это решение может потенциально интересным многим в отрасли. Правда, про РФ не уверен, уж больно стремительно умирает отечественная авиация. Но кто знает, что будет завтра, а опыт интересный. Авиа проекты всегда интересные, хоть и не всегда денежные.
Посему прошу предлагаю свой труд, и не бейте меня сильно 🙂
Контекст
Планируется Система, которая будет в течении 5ти лет хранить события, привязанные к рейсам в расписании. То есть, ссылающиеся на один или несколько рейсов. для чего нам нужно хранить в Системе эти рейсы. Назовем это Хранилищем АР.
В чем тут загвоздка:
А. В самом понятии - рейс. Есть рейс, который летит в точную дату, по точному маршруту и исполняется определенной авиакомпанией (назовем такой рейс атомарным). Есть, такой же рейс, но исполняемый несколькими партнерскими компания (не стану вас утруждать тонкостями всяких авиационных код-шерингов). Есть, рейс который как мини расписание - например, рейс который летает по пятницам, с 20 февраля, по 8 мая, по точному маршруту и исполняется определенной авиакомпанией (назовем такой рейс строкой в расписании). И так же вариант с группой компаний.
Во всех четырех данных мы имеет отличающуюся структуру данных.
Назовем их, в порядке описания выше:
-
атомарный рейс АК;
-
атомарный рейс партнерский;
-
строка в расписании АК;
-
строка в партнерском расписании.
В.Происхождение самих объектов данных. Их генерируют несколько разных систем:
-
система ведения долгосрочного расписания;
-
систему управление оперативным расписание (то есть вот прямо сегодня завтра, как летаем);
-
система согласования расписания движения Воздушных Судов;
-
система согласования оперативных изменений (от смены борта, до переноса на несколько часов вылета);
-
а еще ручные изменения расписания в системе бронирования (да, бизнес имеет такую привычку лезть грязными лапками в продающую систему и править напрямую там…).
Структура данных в разных системах отличается, причем до конца унифицировать их невозможно, исходя из требований бизнеса.
Поступление рейсов неравномерное, оперативные меняются по одному - руками. За день порядка тысячи рейсов. А вот строки в расписании генерируются bulk, до 100 000 за раз.
Планируемые объемы, за пять лет - 50 000 000 записей о рейсах разных типов.
Применение Хранилища рейсов:
-
Увязка с рейсами событий в Системе;
-
Построение визуального графика событий, связанных с рейсов. Проще говоря - оператор зайдет в web интерфейс, выберет параметры рейса, нажмет на кнопку “Найти” и в ему визуализируется временная шкала, по каждому найденному рейсу, на которой пометки о событиях.
Принятое решение
Использовать в качестве СУБД - OpenSearch (пока это все таки старый добрый ElasticSearch).Напоминаю, для тех кто не в курсе, вендор изменил условия лицензирования ElasticSearch. И тогда разработчики сделали клон, который будет далее развиваться самостоятельно, и который условно бесплатный.
Почему ElasticSearch?
-
Потому что он у нас уже был и мы умели с ним работать;
-
В OpenSearch данные хранятся в виде JSON-документов.
-
Основная DB Системы устроена ровно так, то есть мы сохраняем преемственность и единообразие подхода;
-
Схему JSON менять проще, не жили структуру таблицу. А с какой скоростью будут фантазировать разработчики четырех систем источников, неизвестно.
-
-
OpenSearch - это качественный и проверенный поисковик, то есть он заточен именно на ту задачу, которая стояла перед нами.
Архитектурная схема
Схема верхнеуровневая. Все тонкости ETL, авторизации потребителей, преобразования и прочее не расписаны. Совсем немного пояснений:
-
В качестве брокера сообщений и FlowFile NiFi используется KAFKA;
-
В качестве ETL движка, как вы догадались, NiFi;
-
База данных на OpenSearch;
-
В качестве подарка паранойи ИБ - специальный API шлюз и права аккаунта корпоративной Active Directory (AD).
Возможные альтернативы
Kafka
Apache Kafka — это свободно распространяемый брокер сообщений, про него, кто только на habr не писал, включая меня Флейт как KAFKA / Хабр (habr.com) . Так что, если кто не знает, почитайте. Но, полагаю, на habr, что есть Kafka знает большинство.
Преимущества инструмента
-
Этот брокер у нас уже был и мы умели с ним работать;
-
Не надо усложнять архитектуры, добавляя новые СУБД, и создавая ETL схемы загрузки из Kafka в OpenSearch.
Минусы инструмента
-
Мы никогда не делали из Kafka поисковик;
-
Kafka в принципе не про это, есть подходы, как сделать из Kafka поисковик, но все таки лучше использовать каждый инструмент по прямому назначению.
ClickHouse
ClickHouse — это свободно распространяемая колоночная аналитическая СУБД, имени Яндекса.
Преимущества инструмента
-
Надпись “Сделано в России”, можно цинично продать заказчику, как импортозамещение и получить на ровном месте плюшки. Как и поступает значительная часть российского IT;
-
Очень хорошо и быстро выполняет поисковые запросы.
Минусы инструмента
-
В команде нет специалистов с опытом работы ClickHouse (ну не считая меня, но я как то не могу все роли исполнять);
-
Менять структуру данных в ClickHouse не так уж и просто. А, как мы уже знаем, с какой скоростью будут фантазировать разработчики четырех систем источников, неизвестно.
Последствия
Используя привычный, и специализированный инструмент мы получим быстрый инструмент, для поиска рейса, как при процессе построения связей при создании в Системе событий, так и при визуализации временной шкалы, по каждому найденному рейсу, на которой пометки о событиях.
Тонким местом остается построение ETL процедур, при передачи из Kafka в OpenSearch (а мы помним, рейсы могут приходить из внешних систем, как по одному, так и в результате массовой генерации).
Но зато мы получаем сразу единое хранилище рейсов, которое полезно для многих бизнес процессов авиапредприятия, например, для синхронизации расписания в разных системах. То есть получаем механизм поиска и схлопывания дублей.
Автор: Vlad64gven
