Меня зовут Олег Ладыгин, я – главный специалист Лаборатории по инфраструктуре в компании Nexign. За 20 лет карьеры я успел поработать в телекоме, разрабатывал continuous integration, корпоративные соцсети и потом опять вернулся в телеком. Я был одним из ключевых архитекторов системы предбиллинга Nexign Mediation, и в этой статье хочу поделиться, какими принципами мы руководствовались, чтобы разработать универсальный импортозамещающий инструмент для сбора и трансформации данных – настолько удобный и понятный, что с ним могли бы работать инженеры заказчика без навыков программирования.
Статья может быть полезна как специалистам, планирующим разработку современной ETL-платформы или любой системы, занимающейся обработкой данных, так и тем, кто интересуется, как устроены системы предбиллинга в телекоме.
Что такое система предбиллинга
Ежедневно сети любого российского оператора из «большой четверки» генерируют и обрабатывают миллиарды CDR-записей (Call Detail Record) с информацией о потреблении услуг абонентами. Эти данные поступают из распределенных локаций, с различного сетевого оборудования, в разных форматах. Задача системы предбиллинга, или Mediation-системы, — консолидировать данные со всех источников, отфильтровывать, унифицировать, агрегировать и приводить в вид, в котором они становятся понятны для бизнес-систем оператора (систем тарификации и биллинга, а также мониторинга, аналитики, интерконнекта и т.д.). От надежной работы предбиллинга зависит корректность выставленных оператором счетов за услуги связи и стабильность его операционной деятельности. Основные пользователи системы предбиллинга — это инженеры эксплуатации сети, занимающиеся настройкой сетевого оборудования и отслеживающие его работу.
«Больше, чем предбиллинг»: наши критерии хорошей Mediation-системы
Основная сложность выработки критериев состояла в том, что разрабатываемая система должна быть лучше аналогов: мы не могли сделать красивый интерфейс в ущерб скорости или добавить универсальности в ущерб надежности. Для объяснения преимуществ нашего решения были сформулированы основные критерии оценки:
Универсальность. Идея была в том, чтобы создать универсальную платформу для сбора, трансформации и интеграции данных, которая могла бы выполнять широкий круг задач за пределами предбиллинга и даже за пределами телекома. Другими словами, мы хотели сделать максимально гибкий движок, который умеет собирать данные из любого набора систем-источников, преобразовывать их и надежно рассылать по заданным сценариям в любые системы-получатели.
Low-code. Большинство legacy-систем предбиллинга, даже от глобальных поставщиков, предлагают очень слабые возможности визуализации, все конфигурируется файлами, и эксплуатация системы часто затруднительна без привлечения вендора или внутренней команды разработки. Нашей целью было сделать систему, в которой даже бизнес-пользователи смогут и настраивать сценарии обработки данных, и понимать, как они работают.
Удобство для инженеров по эксплуатации. Система должна быть понятной и приятной в управлении — здесь речь даже не о первоначальном конфигурировании, а о возможностях мониторинга, наблюдении за тем, что происходит при обработке данных, о быстром нахождении ошибок. Когда внезапно происходит сбой — будь то смена формата кодирования данных или авария на линии связи, — инженеру должно быть достаточно посмотреть на экран, чтобы в общих чертах понять, где и что именно произошло. Комфорт работы команды эксплуатации — это базовая, человеческая ценность, которую мы хотим разделить с нашими заказчиками.
Производительность и поддержка больших объемов данных. Поскольку Nexign работает в первую очередь с операторами связи уровня Tier-1 и Tier-2, то новое решение должно гарантировать высокую производительность и при этом быть масштабируемым — горизонтально и вертикально. Каким бы красивым и удобным ни было решение, бизнес всегда выберет самый мощный и дешевый вариант. Нам было необходимо обеспечить производительность хотя бы не хуже, чем у конкурентов.
Быстрый запуск. Мы стараемся делать новые продукты так, чтобы после установки у заказчика они могли заработать через несколько дней. О месяцах внедрения, как в случае с тяжелыми legacy-системами, не может идти речи.
Основные этапы разработки Nexign Mediation
Мы писали платформу Nexign Mediation не с нуля. За основу был взят другой продукт, который уже несколько лет используется инженерами по эксплуатации у одного из операторов «большой четверки» для решения повседневных задач: миграции и сверки данных бизнес-систем, устранения рассинхрона между данными в региональных базах или в партнерских сервисах, создания сценариев исправления аварий. Возникла идея взять визуальный конструктор от существующего решения, а исполнительную часть переписать под новые задачи. Прежний движок был разработан на базе библиотеки Apache Spark для последовательного решения сценариев: задача запускалась, завершалась, по расписанию запускалась вновь — и так далее. А Mediation-система должна работать непрерывно в режиме параллельной обработки потоков.
Таким образом, на первом этапе создания платформы мы выработали концепцию и реализовали непрерывное, потоковое выполнение сценариев. Можно сказать, что мы написали некоторый аналог Apache Spark, работающий по концепции непрерывности обработки данных. К примеру, обычная задача обогащения данных может сводиться к простому JOIN между двумя таблицами, однако придумать, как этот JOIN должен выглядеть в ситуации, когда таблиц нет, а есть только несколько «вечных» потоков данных, которые должны смешиваться по выраженным в SQL-синтаксисе правилам, оказалось очень интересной задачей.
На втором этапе мы реализовали модульность в ядре и перешли к разработке функций чтения данных с оборудования, декодирования основных форматов (ASN.1, бинарные форматы различных вендоров, csv) и базовых функций трансформации, необходимых для выполнения задач предбиллинга (агрегация CDR по временному окну или иным признакам, дедупликация CDR или файлов). Помня об универсальности, мы постарались сделать настроечные параметры достаточно умными, не заточенными под конкретного производителя или модель оборудования. К примеру, декодер ASN.1 принимает на входе стандартную спецификацию и список требуемых для обработки полей. Такая универсальность обеспечивает быструю поддержку нового оборудования. В целом наше решение уже поддерживает все типы оборудования, используемые в России и выдающие ASN.1 или бинарный формат данных. Также на втором этапе мы работали над улучшенным UI и метриками мониторинга.
На третьем этапе мы будем расширять и усложнять логику работы продукта, реализуем поддержку брокеров (Kafka, RabbitMQ) и добавим более ёмкие возможности трансформации данных, в частности, обогащение. К концу 2023 года платформа будет полностью готова.
При создании Nexign Mediation мы использовали только внутренние разработки и open source решения. Такой подход позволяет избежать проблем с лицензированием, версионностью, уязвимостью. С технической точки зрения платформа реализована на Java, конфигурации и метаданные хранятся в PostgreSQL или Oracle, а web-часть — это приложение Spring Boot.
«Квадратики и стрелочки»: как мы делали low-code конструктор сценариев
Конструктор и исполнитель сценариев для пользователей без навыков кодирования — это, можно сказать, ключевая функциональность Nexign Mediation. В графическом интерфейсе мы визуализировали все алгоритмы работы с данными. Пользователь берет операторы — готовые блоки функциональности — и перетаскивает их в нужную часть сценария, настраивает параметры и логические взаимосвязи, отображаемые в виде стрелочек различного цвета. Другими словами, чтобы забрать данные с коммутатора, разобрать их по каким-то признакам и выгрузить, скажем, в базу данных PostgreSQL, не нужно писать ни одной строчки кода.
В плане реализации low-code конструктора аналогов нашего решения на российском рынке мы не нашли. Есть похожие решения на том же Apache Spark, но там пользователь с помощью визуального конструктора лишь генерирует исходный код, который потом запускается на кластере. У нас же противоположный подход: наши операторы — это уже готовый код, готовые программные модули, которые умеют взаимодействовать между собой, имеют встроенные метрики мониторинга и могут управляться со стороны. К примеру, работающий сценарий можно притормозить через веб-интерфейс и начать выполнять по шагам, то есть по каждой строчке входных данных, просматривая данные на каждом этапе.
Грубо говоря, у нас используется модель акторов. Есть акторы, которые создают данные, есть те, которые преобразуют. На основании указанных пользователем взаимосвязей между ними образуются каналы, по которым передаются данные с различными ограничениями. Мы следим, чтобы каналы не перегружались, контролируем память, можем измерять и управлять скоростью и задержками в передаче данных. Если канал забивается, то есть источник данных создает данные быстрее, чем приемник их обрабатывает, мы можем приостановить источник до тех пор, пока данные не будут обработаны.
Поскольку базовым элементом ELT-платформ в целом (и Mediation-систем в частности) являются механизмы гарантии обработки данных, мы также реализовали распределенные транзакции. Когда источник данных (например, оператор чтения с оборудования или приемник RabbitMQ) создает пакет данных, ему присваивается уникальный номер. По мере прохождения всех преобразований, этот пакет обогащается различной метаинформацией, а в самом конце, когда он полностью обработан или просто потерян, на акторе-источнике вызывается финализатор, который определяет, как поступить с исходными данными.
К примеру, файл будет удален с коммутатора только тогда, когда он пройдет всю цепочку — от декодирования до экспорта всем получателям — или будет перемещен в хранилище ошибок в случае получения ошибки. Пользователь, создающий сценарий обработки данных, самостоятельно указывает, где проходит граница транзакции. Для этого достаточно поместить операторы в пределах транзакционного региона.
Универсальная ETL-платформа
Как и планировалось, на текущий момент у нас готова платформа для предбиллинга Nexign Mediation. Особенность решения в том, что кроме предбиллинга (отправки обработанных данных CDR в биллинг) его можно использовать для других кейсов: например, для отправки оперативных данных в системы гарантирования доходов (revenue assurance) и риск-мониторинг, организации обмена файлами для взаиморасчетов и сверок с роуминговыми и интерконнект-партнерами, первичной обработки данных мониторинга сети (аварии, счетчики, KPI).
На базе платформы, созданной для задач Nexign Mediation, мы разработали более общий, универсальный продукт — Nexign Data Integration. Это low-code платформа для извлечения, трансформации и интеграции данных, которую можно использовать в любой отрасли: обрабатывать банковские транзакции, консолидировать и преобразовывать данные с умных счетчиков и датчиков в сфере ЖКХ и на производствах. Мы видим, что области применения новой платформы очень широки, а настроить ее под нужды конкретного заказчика можно всего за несколько дней. Таким образом, мы готовы к внедрениям этого решения для поддержки разных бизнес-кейсов.
Мы изначально сделали продукт модульным, где каждый модуль — это набор операторов или частей веб-интерфейса. Разработчик на стороне клиента при необходимости может добавить собственные операторы, реализующие произвольную логику, просто написав их на Java. Для этого надо оформить код согласно нашим аннотациям, собрать jar-файл и добавить его в продукт. Мы постепенно будем расширять доступные для установки модули, например, готовится модуль поддержки репликации БД и модуль работы с Apache Spark.
Кстати, платформа Nexign Data Integration скоро станет доступна в Nexign Store — там можно будет как скачать бесплатную версию, так и приобрести лицензию. Также будет доступна документация разработчика, а это значит, что пользователи смогут создавать модули с нужной им функциональностью своими силами.
Про работу команды
В современной разработке ПО принято учитывать потребности пользователей, поскольку это помогает создавать продукты, которые будут полезны, удобны и, следовательно, успешны. Но именно в телекоме и в тяжелых бизнес-системах о пользователях обычно забывают, и мне хотелось исправить эту ситуацию. На протяжении всего процесса разработки Nexign Mediation мы говорили с инженерами эксплуатации, консультировались с дизайнерами, показывали наброски и собирали обратную связь.
В разработке была задействована вся команда, и мы старались не разделять по ролям дизайнеров, frontend- или backend-разработчиков. Для меня командная работа — это не про взаимозаменяемость, а про профессиональный и личностный рост. Разработчик поговорил с техподдержкой и понял, что надо улучшить в логах. Поговорил с владельцем продукта и дизайнером — стал больше задумываться о том, зачем вообще пишет код, и что с этим кодом будет через год.
По моему мнению, разработка программного обеспечения — это процесс, который требует не столько технических навыков, сколько уважительного отношения к нуждам пользователей. Только так возможно создать продукт, который будет успешен на рынке и принесет пользу бизнесу. Это особенно важно сейчас, когда вендоры крупных B2B-систем ушли из России. А что вас мотивирует при разработке enterprise-решений? Поделитесь, как у вас идет процесс импортозамещения иностранного ПО?