Последние 12 месяцев много обсуждается тема миграции с ИТ‑систем, которые оказались недоступны в России. Во всех компонентах ИТ‑инфраструктуры появились критические зоны, которые раньше закрывались международными продуктами и которые нужно срочно переводить на работающие платформы. Не исключением стала и область бизнес‑аналитики. Иностранные BI‑системы ушли с российского рынка и компании начали интересоваться, на что можно перенести свою аналитическую отчетность.

Меня зовут Александр Гончар и работаю в консалтинговой компании A2 Consulting и для нас тема миграции с зарубежных BI‑решений не является новой. За последние пять лет мы реализовали десяток проектов, в которых осуществляли миграцию из аналитических платформ в другие решения, прежде всего, в части хранилищ данных (ХД). Расскажу сегодня об опыте миграции с такого известного BI‑инструмента, как Qlik.

Зачем мигрировать с Qlik?

Актуальность миграции данных с платформ QlikView и Qlik Sense, в которых основные данные хранятся в файловом хранилище в виде QVD‑файлов, а весь ETL выполняется средствами Qlik, сохранялась из‑за нескольких факторов.

Первая причина — желание заказчиков глубже анализировать клиентские данные и пользоваться преимуществами предиктивной аналитики. Параллельно, у компаний из других отраслей существовало несколько систем бизнес‑аналитики, и им хотелось пользоваться данными из единого источника.

Для реализации этой задачи данные должны лежать в отдельном хранилище, а не в системе бизнес‑аналитики. Поэтому мы часть данных выгружали из Qlik в хранилище, а затем постепенно выносили их все больше и больше. При этом QVD‑файлы в системе остаются, но используются только для последнего слоя, витрины данных.

Дополнительно, ETL выполняется другими инструментами, например, Python, а оркестрация данных — AirFlow. Теперь данными из ХД может пользовать не только QlikView/Qlik Sense, но и другие информационные системы.

Вторая причина того, что мы начали организовывать ХД отдельно от Qlik, связана с бурным развитием Microsoft Power BI (PBI). У многих заказчиков вставал вопрос о миграции с Qlik на Power BI или с дополнением существующей бизнес‑аналитики еще и отчетами в PBI. Это связано с тем, что у компаний в подписку Microsoft обычно включается большое количество лицензий на PBI и это хороший повод для того, чтобы расширить количество пользователей системы бизнес‑аналитики, не увеличивая число лицензий.

При миграции хранилища в этом случае мы часть данных выносили в Microsoft Azure и обрабатывали их MS SQL Server либо Synapse. Данные шли и в Qlik, и в PBI. Новые пользователи работали с более простыми отчетами, но количество пользователей росло.
Следующая причина популярности миграции ХД из систем Qlik — это рост количества приложений и нагрузки на сервер BI‑системы. Традиционно по утрам пользователи сталкивались с пиком нагрузки обновления данных, и вся система бизнес‑аналитики начинала тормозить. Логичным шагом было вынести хранилище, в котором данные в том числе и обновляются, в другой инструмент.

Как мигрировать?

Первый шаг, с которого надо начинать проекты по миграции, это выбрать формат: экспресс‑миграция или создание полноценной новой BI‑системы. Экспресс‑миграция означает, что мы выбираем самый простой инструмент, копируем в него данные из Qlik, а ETL и ХД реализуем на технологиях open source. Цель такого проекта — обезопасить свою BI‑систему, в условиях, когда ее могут отключить, например, и снизить нагрузку на Qlik.

Полноценное создание BI‑решения предполагает более длительный подготовительный этап проектирования системы в формате Data World. В связи с этим нужно будет сделать не просто ETL и ХД, а разработать полноценное хранилище и далее его наполнять данными.

А что на практике?

Разберем несколько реальных проектов.

Игрок рынка eCommerce использовал BI‑систему QlikView для аналитики по продажам, финансам, остаткам и закупкам. Кроме 50 пользователей QlikView маркетологи компании использовали Tableau и для них требовалось построить хранилище данных на Snowflake. Параллельно группы data scientist‑ов компании испытывала трудности с неудобной выгрузкой данных из Qlik через Excel.

Наше решение включало в себя два этапа, первый из которых занял всего 3–4 недели, а второй около 3 месяцев. Мы создали базу в MySQL, с помощью Python вынесли туда ETL, обработку, QVD‑файлы и всю их цепочку преобразования — слой выгрузки, хранения и конечные витрины для каждого приложения, сделав отдельные SQL схемы под каждое приложение.

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

В результате компания сэкономила на стоимости владения Snowflake и ускорила работу BI‑систем за разгрузки QlikView.

Еще один проект мы реализовали в розничной сети. Ритейлер работал одновременно с QlikView и Qlik Sense, у которых были общие QVD файлы. ETL и подготовка QVD‑файлов реализовывалась на QlikView, а визуализация — в Qlik Sense. В будущем сеть планировала полную миграцию на Qlik Sense. Объем данных постоянно рос, росло и количество пользователей, а ИТ‑отдел устал от постоянной необходимости увеличивать мощности.
Мы предложили альтернативное решение. Чтобы не переносить данные из QlikView в Qlik Sense, мы создали data lake на Greenplum. Из этой среды обе BI‑системы стали брать данные. Таким образом была снижена нагрузка на ночную работу систем и ускорена работа приложений за счет предварительных расчетов, которые ведутся в ХД.

Через год сеть начала полноценный проект по внедрению ХД по модели Data World и выяснилось, что значительная часть работ уже сделана, так как создан data lake. А в прошлом году этот же ритейлер всего за три месяца смог мигрировать полностью на другую BI‑систему.

В третьем случае крупный дистрибутор столкнулся с ситуацией, когда через 30 дней он терял доступ к Qlik Sense. В системе работали 100 пользователей и была реализована аналитика по продажам и управлению дебиторской задолженностью. Причем данные для Qlik Sense собирались из систем 1С из различных филиалов, расположенных в разных городах.

Здесь мы пошли по схеме экспресс‑миграции. В течение двух недель мы вынесли основной ETL и QVD‑файлы в отдельную базу данных на PostgreSQL, настроили обновление данных с помощью AirFlow и таким образом получили копию данных, которые были в Qlik Sense в отдельной базе. Далее мы сохранили технические задания по всем расчетам и полное описание демоверсии.

За это время ИТ‑служба дистрибутора нашла BI‑систему, в которой было решено работать в дальнейшем. В течение трех недель мы повторили аналитику для продаж в ней, а затем в спокойном режиме мигрировали другие приложения.

Завершу свой рассказ кейсом клиента, у которой хранилище было реализовано на AWS, а QlikView использовался для визуализации данных. При этом cервер Qlik был зашифрован и было отключено его бэкапирование. Пришлось в экспресс‑режиме за несколько недель перерабатывать все приложения. Но так как в Qlik была только визуализация, нам удалось оперативно все скопировать.

Неужели проекты по миграции с Qlik так просты?

С одной стороны, да. Но с другой, в них есть ряд сложностей. И это не развертывание ХД, хотя этот процесс может быть трудоемким или длительным. Важным моментом при реализации таких проектов является понимание специфики технологии Qlik. Из‑за нее часть процессов необходимо проектировать по‑другому — например, модели данных и работу с правами доступа.

Важным фактором является запуск проекта миграции и обучение пользователей работе с новой системой, так как логика анализа и работы поменяется. Важно заранее продумать визуализацию — будет ли это интерфейс новой BI‑системы от вендора или вы готовы дописывать собственную визуализацию на JS.

Еще один вопрос связан с выбором конкретной технологии — open source или проприетарного решения. Здесь выбор зависит от текущей инфраструктуры компании — если кто‑то работает на технологиях Microsoft, логичнее использовать программные компоненты этого вендора. Но безусловно текущая ситуация в России заставляет все чаще делать выбор в пользу платформ с открытым кодом.

Логика бизнес‑пользователя Qlik в self‑service и цепочках анализа отличается от возможностей текущих BI‑инструментов — российских или других. Но мы понимаем, в чем именно заключаются эти отличия и готовы делиться этими знаниями.

P. S. Отдельная тема — это миграция Qlik NPrinting, но об этом я расскажу в следующей статье.

Источник: Хабр