Последние 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, но об этом я расскажу в следующей статье.
