Разработчик универсального движка для платформы Knowledge Space, лидирующей в рейтинге IBP CNewsMarket, и один из топ-40 диджитал-экспертов России о том, почему отечественные платформы обработки данных редко становятся универсальными и почему универсальность — это не плохо.
Объемы корпоративных данных в России растут, а вместе с ними растет и потребность в программном обеспечении по их обработке. Так, ComNews утверждает, что после 2022 года более 50% ИТ-бюджетов российских компаний направлено на разработку аналогов западных моделей интеграции данных или, иначе говоря, ETL-систем. Однако проблема в том, что подобные продукты создаются под конкретный бизнес — из-за этого рынок получает десятки кастомных и дорогих проектов, вместо тиражируемого и универсального решения.
Причина подобной ситуации — отсутствие продуктового подхода к создаваемым ETL-системам, считает Артем Мирошниченко, разработчик ETL-движка Integrator российской платформы для создания корпоративных систем интегрированного бизнес-планирования, которая третий год подряд занимает первое место в рейтинге IBP CNewsMarket. Работая с заказчиками из разных отраслей он сформулировал подход к построению архитектуры ETL-систем, при котором ядро движка остается единым, а отраслевая специфика выносится в слой настроек, что делает решение универсальным без переписывания кода. Опыт кросс-отраслевой работы позволил Мирошниченко войти в жюри международного конкурса ECDMA Global Awards, где наравне с экспертами Microsoft и Adidas он оценивал, насколько эффективно e-commerce-проекты превращают данные в измеримый бизнес-результат. О том, как устроен универсальный ETL-движок изнутри и почему качество интеграции данных определяет успех бизнеса в любой отрасли — в этом материале.
Артем, вы прошли путь от консультанта и backend-инженера до технического лидера и руководителя направления в «ИСУ», где развиваете ETL-платформу, получившую высокую оценку CNewsMarket в том числе за функциональность для пользователей из разных отраслей. Для отечественных решений это считается скорее редкостью, чем нормой. Как думаете, почему — что говорит ваш опыт?
На мой взгляд, дело не в отсутствии компетенций, а в самом подходе к разработке. Компании работают на решение проблемы конкретного заказчика, не задумываясь, как проект будет работать вне его бизнеса и целей. Кроме того, в большинстве команд тот, кто пишет архитектуру, и тот, кто понимает, зачем она нужна бизнесу — это разные люди. А значит, решение о том, как будет устроен движок, принимается без оглядки на то, как продукт будет масштабироваться через год. Поэтому, когда возникает необходимость, например, адаптировать решение уже под другую отрасль все приходится переделывать заново.
Вы инициировали создание и проектировку движка, которым сейчас пользуются крупные банковские, металлургические и нефтегазовые компании — например, «Газпром нефть» и сербская NIS. Что именно вы изменили в подходе к разработке, чтобы одним решением закрыть потребности компаний с разной спецификой данных?
Я разделил движок на два уровня: ядро, которое отвечает за скорость и надежность транспортировки данных, и слой настроек, где задается отраслевая специфика — источники данных, форматы, правила валидации. Тогда стало понятно, что, по сути, задачи у всех заказчиков похожи: например, «Газпром нефть» собирает данные с месторождений и связывает их с корпоративным хранилищем, а Газпромбанк стягивает макроэкономические показатели из десятка источников в аналитическую витрину. Звучит по-разному, но движок делает одно и то же. Ядро ETL-системы не должно знать работает оно с нефтегазом или с банком — оно просто забирает данные из точки А, очищает и доставляет в точку Б. Такой подход позволяет перевести интеграцию движка в новую отрасль из плоскости разработки в плоскость настройки.
Кстати, о настройках: ваш движок обрабатывает до пяти тысяч запросов в секунду и более 1 миллиона записей в минуту. Это огромные объемы данных, справиться с которыми сложно даже инженерной команде, не говоря уже о бизнес-пользователях. За счет чего удалось передать клиенту контроль над данными?
Надо признаться, у нас была проблема с репрезентацией клиентских данных и обслуживанием движка — до 2025 года его настройка шла через конфигурационные файлы, а мониторинг осуществлялся через логи. Поэтому, когда что-то ломалось, клиент звонил в поддержку, и наши инженеры часами искали причину, что было неудобно ни нам, ни бизнесу. Поэтому я предложил руководству добавить визуальный слой — сделать интерфейс, в котором ETL-процессы, конфигурации интеграций и статус обработки данных отображаются на экране в реальном времени. В результате, командой из пяти человек мы довели его до промышленной эксплуатации, что дало результаты — время диагностики сократилось на 50%, нагрузка на поддержку упала на 35%, но главное — клиент перестал зависеть от нас в повседневном мониторинге и получил возможность видеть, что происходит с его данными.
Ваш проект для «Норильского никеля» ежегодная деловая премия в области цифровых технологий CIPR Digital-2025 назвала лучшим в номинации «Промышленный масштаб», а вас включили в топ-40 диджитал экспертов России. Выходит, бизнес-мышление при создании технических решений сейчас приобретает особую ценность?
Безусловно. Если архитектура позволяет подключать новую отрасль через настройку, то компания-разработчик перестает зависеть от одного рынка. Причем каждый шаг в новой отрасли дается быстрее предыдущего, потому что ядро уже проверено, а отраслевые правила — это конфигурация. По сути, продуктовый подход к архитектуре превращает ETL-движок из статьи расходов в инструмент роста: чем больше отраслей он покрывает, тем шире рынок сбыта для компании и тем дешевле обходится каждое следующее внедрение.
У вас есть возможность смотреть на рынок глобально — вы учились по совместной программе ВШЭ и Лондонского университета и входите в международное сообщество Hackathon Raptors, где оцениваете технологические проекты специалистов из десятков стран. Несколько, на ваш взгляд, сегодняшние российские ETL-решения готовы конкурировать с зарубежными аналогами?
По функциональности да. Например, наш движок обрабатывает объемы, сопоставимые с тем, что дают западные аналоги, и при этом работает в нескольких отраслях без переписывания кода — при этом на рынке есть и другие успешные разработки. Это уровень, который два-три года назад в России просто отсутствовал. Но чего пока не хватает, так это зрелости экосистемы вокруг продуктов: документация, сообщество разработчиков, готовые коннекторы к международным системам, но разрыв сокращается быстро. Поэтому думаю, что через пару лет вопрос будет не «готовы ли российские решения конкурировать», а «в каких нишах они уже выигрывают».
