ETL-компонента хранилища данных часто оказывается в тени самого хранилища и ей уделяется меньше внимания, чем главной базе данных или фронт-компоненте, BI, формировании отчётов. При этом с точки зрения механики наполнения хранилища данными, ETL играет ключевую роль и требует не меньше внимания администраторов, чем остальные компоненты. Меня зовут Александр, сейчас я администрирую ETL в Ростелекоме, и в данной статье я постараюсь немного поделиться тем, с чем приходится сталкиваться администратору одной известнейшей ETL-системы в крупном хранилище данных компании Ростелеком.

Если уважаемые читатели уже знакомы в целом с нашим проектом хранилища данных и с продуктом Informatica PowerCenter, то можно сразу перейти к следующему разделу.

Несколько лет назад в Ростелекоме вызрела и стала воплощаться в жизнь идея единого корпоративного хранилища данных. Ряд хранилищ, решавших отдельные задачи, уже был создан, но количество сценариев росло, затраты на поддержку также увеличивались, и стало понятно, что будущее за централизацией. Архитектурно это само хранилище, состоящее из нескольких слоёв, реализованное на Hadoop и GreenPlum, вспомогательные БД, ETL механизмы и BI.

При этом из-за большого количества территориально распределённых, разнородных источников данных был создан специальный механизм выгрузки данных, работа которого управляется Informatica. В результате пакеты с данными оказываются в интерфейсной области Hadoop, после чего начинаются процессы прогрузки данных по слоям хранилища, в Hadoop и GreenPlum, а управляются они так называемым управляющим механизмом ETL, реализованным в Informatica. Таким образом, система Informatica является одним из ключевых элементов, обеспечивающих работу хранилища.

Более подробно о нашем хранилище будет рассказано в одном из следующих постов.

Informatica PowerCenter/Big Data Management на сегодняшний момент считается лидирующим ПО в сфере инструментов интеграции данных. Это продукт американской компании Informatica, являющейся одним из сильнейших игроков ETL (Extract Transform Load), управления качеством данных, MDM (Master Data Management), ILM (Information Lifecycle Management) и прочее.

Используемый нами PowerCenter представляет собой интегрированный сервер приложений Tomcat, в котором работают сами приложения Informatica, реализующие её сервисы:

Domain, по сути это базис для всего остального, в рамках домена работают сервисы, пользователи, компоненты GRID.

Administrator Console, web-инструмент управления и мониторинга, помимо клиента Informatica Developer, основной инструмент для взаимодействия с продуктом

MRS, Model Repository Service, хранилище метаданных, представляет собой прослойку между базой, в которой метаданные хранятся физически, и клиентом Informatica Developer, в котором идёт разработка. Репозитории хранят и описание данных, и другую информацию, в том числе, для ряда других сервисов Infromatica, например, расписание запусков заданий (Schedules) или данные мониторинга, а также parameterset’ы приложений, в частности позволяющие использовать одно и то же приложение для работы с различными источниками и приёмниками данных.

DIS, Data Integration Service, это сервис, в котором происходят основные функциональные процессы, в нём работают приложения и происходят собственно запуски Workflows (описания последовательности mappings и их взаимодействия) и Mappings (трансформаций, блоков, в которых происходят сами преобразования, обработка данных).

Конфигурация GRID – по сути, вариант построения комплекса с использованием нескольких серверов, когда нагрузка, запускаемая DIS, распределяется по нодам (то есть серверам, входящим в состав домена). В случае такого варианта, кроме распределения в DIS нагрузки через дополнительный слой абстракции GRID, объединяющий несколько нод, на котором и работает DIS вместо работы на конкретной одной ноде, также могут быть созданы дополнительные резервные экземпляры MRS. Можно даже реализовать высокую доступность, когда внешние обращения могут осуществляться через резервные ноды при отказе основной. От такого варианта построения мы пока отказались.


Informatica PowerCenter, схематично

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


Прежний логотип Informatica

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

Как так получилось

В 2016-м году, когда мы стали отвечать за работу Informatica, она уже достигла версии 10.0, и для оптимистически настроенных коллег, принимавших решение о применении в серьёзном решении продукта с минорной версией .0, всё казалось очевидным — использовать нужно новую версию! С точки зрения аппаратных ресурсов всё было на тот момент отлично.

С весны 2016-го за работу Informatica отвечал подрядчик, и со слов немногочисленных пользователей системы «она работала пару раз в неделю». Тут нужно пояснить, что хранилище было де-факто на этапе PoC, администраторов в команде не было и система постоянно падала по разным причинам, после чего инженер подрядчика её поднимал заново.

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

Первое, что нам пришлось делать для разработчиков нашей команды и подрядчика — стабилизировать работу самой Informatica, добиться работоспособности web-консоли администрирования (Informatica Administrator).


Так у нас зачастую встречала разработчиков Informatica

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


Одна из попыток добиться работы Informatica Monitor

С консолью администрирования ситуация также была критической. Поскольку шла активная разработка прямо на условно продуктивной среде, коллегам постоянно было необходимо анализировать работу mappings, workflow «на ходу». В новой Informatica, в Data Integration Service нет отдельного инструмента для такого мониторинга, но в web-консоли администрирования появился раздел мониторинга (Informatica Administrator Monitor), в котором можно наблюдать работу приложений, workflow и mappings, запуски, логи. Периодически консоль становилась недоступной полностью, либо переставали обновляться сведения о текущих процессах в DIS, либо возникали ошибки при загрузке страниц.


Подбор параметров java для стабилизации работы

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

В первую очередь был создан отдельный MRS для мониторинга, как потом оказалось, это один из основных потребителей ресурсов у нас в средах, поскольку запуски mappings происходят очень интенсивно. Были изменены параметры, касающиеся java heap, и ряд других.
В результате к следующему обновлению Informatica 10.1.1 работу консоли и монитора удалось стабилизировать, разработчики стали работать эффективнее, а регулярные процессы становились всё более регулярными.

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

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

Из заметных препятствий, связанных с Informatica, можно вспомнить эпичное сражение с растущими java-потоками. В какой-то момент пришло время тиражирования, то есть распространить налаженные процессы на большое количество систем источников. При этом оказалось, что далеко не все процессы в 10.1.1 работали хорошо, и спустя какое-то время DIS становился неработоспособен. Обнаруживались десятки тысяч потоков, число их росло особенно заметно при процедуре деплоя приложений. Порой приходилось делать рестарт несколько раз в сутки для восстановления работоспособности.

Тут нужно поблагодарить поддержку, сравнительно оперативно проблемы были локализованы и исправлены с помощью EBF (Emergency Bug Fix) – после этого у всех появилось ощущение, что инструмент действительно работает.

Оно всё-таки работает!

К моменту начала работы в целевом режиме Informatica выглядела следующим образом. Версия Informatica 10.1.1HF1 (HF1 это HotFix1, вендорская сборка из комплекса EBF-ов) с установленными дополнительно EBF, исправляющим наши проблемы с масштабированием и некоторые другие, на одном сервере из трёх, входивших в состав GRID, 20 ядер x86_64 и хранилище, на огромном медленном массиве локальных дисков — это конфигурация сервера для Hadoop кластера. На другом таком же сервере — СУБД Oracle с которым работает и домен Informatica и управляющий механизм ETL. Всё это мониторится штатными средствами мониторинга, используемыми в команде (Zabbix + Grafana), двух сторон — и сама Informatica с её сервисами, и идущие в неё процессы прогрузки. Сейчас и производительность и стабильность работы без учёта внешних факторов, зависит сейчас от настроек, ограничивающих нагрузку.

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

Прямо сейчас остаётся сложность связанная с падением производительности при регулярной очистке схемы монитора — при одновременно идущих процессах в ЧНН и запущенной очистке могут возникать сбои в работе управляющего механизма ETL. Решается это пока «костыльно» — ручной очисткой схемы монитора, с потерей всех предыдущих его данных. Это не слишком критично для продуктива, при нормальной штатной работе, но пока идёт поиск нормального решения.

Из этой же ситуации вытекает и ещё одна проблема — порой происходят множественные запуски нашего управляющего механизма.


Множественные запуски приложения, приводящие к поломке механизма

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

В целом можно резюмировать, что при большой нагрузке очень важно предоставить адекватные ей ресурсы, это касается и аппаратных ресурсов для самой Informatica, и то же самое для её БД-репозитория, а также обеспечить для них оптимальные настройки. Кроме того, остаётся открытым вопрос по тому, какая схема размещения БД лучше — на отдельном хосте, или на том же, где работает ПО Informatica. С одной стороны, на одном сервере получится дешевле, и при совмещении практически снимается возможная проблема с сетевым взаимодействием, с другой — нагрузка на хост от БД дополняется нагрузкой от Informatica.

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


Временной дуализм в логах MRS “by design”

Оказалось, что временные метки пишутся в формате 12 часов, без указания AM/PM, то есть до полудня или после. Была даже открыта заявка по этому поводу, и получен официальный ответ — так и было задумано, в лог MRS отметки пишутся именно в таком формате. То есть остаётся порой некоторая интрига относительно времени возникновения какого-нибудь ERROR-а…

Стремиться к лучшему

Сегодня Informatica — это достаточно стабильный инструмент, удобный для администратора и пользователей, чрезвычайно мощный по текущим возможностям и потенциалу. Он многократно превышает функционально наши потребности и де-факто сейчас используется в проекте не самым характерным и типовым образом. Сложности отчасти связаны с тем, как работают механизмы — специфика в том, что за короткий промежуток времени запускается большое количество потоков, которые интенсивно обновляют parameterset’ы и работают с БД репозитория, при этом аппаратные ресурсы сервера утилизируются по ЦПУ практически полностью.

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

Само собой, предстоит тестирование, проверка совместимости, и возможно, архитектурные изменения в части HA GRID. Развитие в рамках Informatica будет идти, поскольку в краткосрочной перспективе что-то поставить на замену системе мы не можем.
И те, кто в дальнейшем будут отвечать за данную систему, обязательно сумеют довести её до требуемых показателей надёжности и производительности выдвигаемых заказчиками.

Статья подготовлена командой управления данными «Ростелекома»


Актуальный логотип Informatica