Ипатов Александр
Старший разработчик ГК Юзтех
Привет всем! Я, Ипатов Александр, backend-разработчик в ГК Юзтех. Сегодня хочу поделиться своим опытом создания (в комплексе с элементами ETL, DWH) и использования BI-инструментов, не затрагивая российский сегмент, о котором в последнее время слышно очень много, в связи с событиями, связанными с запретом использования западных продуктов. На мой взгляд, общие принципы разработки и использования везде идентичные, и хочется сделать обзор именно по глобальному игроку на рынке BI решений, о нём ниже.
Начать хочу с того, что же такое BI. Business Intelligence — это совокупность технологий, методов и процессов, предназначенных для анализа данных и предоставления информации, необходимой для принятия обоснованных бизнес-решений. Согласно рейтингу TAdvisor , в последние годы BI стал неотъемлемой частью любой успешной организации, независимо от её размера и отрасли.
Преимущества использования BI инструментов
BI инструменты предоставляют много преимуществ, которые могут значительно повысить эффективность работы компании:
Скорость принятия решений: BI позволяет быстро получать доступ к актуальной информации и анализировать данные в реальном времени.
Автоматизация процессов: Автоматизация рутинных задач снижает вероятность ошибок и ускоряет процесс принятия решений.
Разграничение доступа: BI инструменты позволяют контролировать доступ к данным, обеспечивая конфиденциальность и безопасность информации.
Интеграция данных: BI интегрирует данные из различных источников, предоставляя целостную картину бизнеса.
Оптимизация ресурсов: Анализ данных помогает выявить неэффективные процессы и оптимизировать использование ресурсов.
Обзор популярных BI инструментов
На рынке представлено много BI инструментов, каждый из которых имеет свои особенности и преимущества. Расскажу о некоторых из них:
Microsoft Power BI — один из лидеров на мировом рынке BI решений. Он предоставляет широкий спектр возможностей для анализа данных и создания дашбордов.
Tableau — ещё один популярный BI инструмент, известный своими мощными возможностями визуализации данных. Он предлагает широкий набор инструментов для анализа и визуализации данных.
QlikView — инструмент, ориентированный на создание интерактивных аналитических приложений. Он позволяет пользователям самостоятельно исследовать данные и строить отчёты.
SAP BusinessObjects — комплексное решение для бизнес-аналитики, включающее BI инструменты, средства для управления данными и приложения для мобильного доступа.
Выбор инструмента, в основном зависит от потребностей компании (или частного лица) и возможностей по приобретению лицензий в санкционном режиме. Если у компании не возникает проблем по приобретению лицензий продуктов - то я бы рекомендовал использовать Microsoft Power BI, поскольку является одним из самых проработанных и с самым мощным ETL функционалом внутри (язык M, Power Query и пр.). Если проблемы имеются -то можно рассмотреть 3 варианта: Российский BI — Visiology, Yandex DataLens; Западный Open-source — Apache Superset ; Азиатский аналог — FineBI.
Этапы реализации проекта по BI
Реализация проекта по внедрению BI системы включает несколько ключевых этапов:
Первым шагом является определение целей проекта и требований к системе. Это включает:
Сбор требований от ключевых заинтересованных сторон;
Определение ключевых показателей эффективности (KPI);
Анализ текущих процессов и выявление областей для улучшения.
На основе собранных требований и анализа рынка выбирается подходящий BI инструмент. При выборе важно учитывать:
Функциональные возможности;
Совместимость с текущими системами;
Стоимость и доступность;
Уровень поддержки и наличие документации.
Для успешного анализа данных необходимо обеспечить их качество и доступность. Это включает:
Очистку и преобразование данных;
Интеграцию данных из различных источников;
Создание витрин данных для быстрого доступа к необходимой информации.
Создание дашбордов и отчётов является ключевым этапом проекта. Это включает:
Определение структуры дашбордов и отчётов;
Выбор необходимых визуализаций;
Настройка автоматических обновлений данных.
Перед полным внедрением системы необходимо провести тестирование, чтобы убедиться в её корректной работе. Это включает:
Проведение тестовых запусков;
Сбор обратной связи от пользователей;
Внесение необходимых корректировок.
После успешного внедрения системы важно обеспечить обучение пользователей и предоставить им необходимую поддержку. Это включает:
Проведение тренингов и семинаров;
Создание документации и руководств;
Обеспечение технической поддержки.
Конечно, данный комплекс этапов можно сократить. Однако, по своему опыту, могу заметить, что отсутствие одного из указанных выше пунктов впоследствии приведут к увеличению сроков реализации, уточнению требований и, в крайнем случае, к пересмотру реализации в общем. Такой негативный момент возможен при недоработке изучения лицензий предоставляемых продуктами, а также при некой “железной” несовместимости (отсутствие поддержки некоторыми BI продуктами имеющихся подключений к источникам данных, первое, что приходит в голову - настройка подключения к базам программ 1С, с которыми зачастую связаны дашборды по кадровым службам, финансовым показателям компаний). Поэтому, на этапе формирования ТЗ желательно проработать все пункты и «построить BI продукт на бумаге».
В качестве примера реализации BI-продукта хочу рассказать об одном проекте в сфере логистики:
На начальном этапе заказчик контролировал свои рабочие процессы с помощью ежедневных excel/csv выгрузок, которые анализировались в Excel ответственными сотрудниками (то есть вручную аналитиками данных из разных отделов), которые в результате выдавали некие графики по динамике и приводящие в конечном счёте 5-7 агрегированных метрик.
Такой подход подразумевал 3 уязвимых места:
Человеческий фактор возникновения ошибок в расчетах;
Разные подходы по агрегации данных между отделами (разные методики расчетов иногда присутствовали в силу исторически сформировавшихся подходов в этих отделах);
Загрузка сотрудников такими одинаковыми действиями с четкой периодичностью (что было бы хорошо автоматизировать и снять нагрузку с сотрудников, у которых помимо этого много других задач и функционала).
Поэтому проект был разделен на несколько частей, которые хочу разделить на следующие этапы (на каждом этапе буду указывать проблемы, с которыми сталкивались):
-
Построение DWH:
Данные с файлового сервера (на который поступали excel/csv выгрузки) посредством ETL сервера записывались в хранилище сырых данных (staging), вся работа велась в Microsoft SQL Server. В качестве оркестратора был использован Dagster, однако можно использовать и более распространенный для таких задач Airflow;
Данные из staging агрегировались, преобразовывались и записывались ETL сервером в транзитное хранилище (эту операцию проводили лишь на тех данных, которые затем были нужны при расчетах показателей и метрик, необходимых на дашбордах);
Итоговые витрины данных для Power BI формировались вручную в SQL Server Management Studio на основе данных из транзитного хранилища.
Проблемы, с которыми столкнулись на этапе:
Проблема |
Решение |
«Грязные» данные на входе |
В ETL части предусмотреть проверку входных данных, определить с Заказчиком формат данных на вход и каким образом обрабатывать исключения, если такие данные всё-таки попали на Файловый сервер |
Отсутствие данных (файлы за предыдущий период не появились на сервере) |
Договорённость с Заказчиком по обработке таких сценариев (пометки в строках данных), определили принципы доливки данных за пропущенные дни |
Создание Табулярной модели (Tabular model) в SQL Server Analysis Services на основе разработанных витрин данных. Важно проследить связи между витринами, поскольку табулярная модель планировалась к широкому использованию в разных дашбордах для оптимизации времени корректировки данных во всех дашбордах сразу, при такой необходимости.
Подключение Power BI непосредственно к Табулярной модели из SQL Server Analysis Services в режиме «живого» подключения (Direct Query), что гарантирует наличие самых свежих данных в отчете на «сейчас». Данная Табулярная модель хороша тем, что изменения в данных можно реализвать внутри неё, не трогая дашборд. А дашборд получит уже изменённые актуальные данные – это приводит к ускорению разработки в случае правок плюс если на основе данной табулярной модели построены более чем 1 дашборд – все дашборды будут исправлены за одну итерацию, без дополнительной разработки каждого из дашбордов. На этом шаге активно использовались Tabular Editor (инструмент взаимодействия с табулярными моделями) + DAX-Studio (для работы с DAX-мерами для построения метрик, необходимых Заказчику).
Проблемы, с которыми столкнулись на этапе:
Проблема |
Решение |
Невозможность создания новых и доработок DAX-мер (метрик) внутри самого Power BI |
Проблема связана с тем, что табулярная модель не подразумевает работу с набором данных внутри Power BI в части написания DAX-мер, добавления настраиваемых столбцов и прочих элементов. Эта проблема решается с помощью Tabular Editor – специальной программы, внутри которой можно добавлять новые DAX-меры и, в принципе, работать с набором данных. Также одновременно использовалась программа DAX-Studio – инструмент написания мер, который помогает в разработке сложных метрик. |
Этап отрисовки визуальной части дашбордов в Power BI на основе подготовленных данных: установка неких «маячков» — интервалов оценок / метрик с положительными либо отрицательными результатами. Обычно такие критичные оценки отображаются в зеленых либо красных оттенках. На «визуале» это действительно помогает более быстро реагировать на возникновение проблемы в работе компании. Здесь важной особенностью Power BI является возможность использования нестандартных визуальных элементов (как своих разработок, так и open source визуальных решений, которых можно найти на форумах по Power BI).
В частности, в дашбордах по логистике очень хорошо показывает себя Санкей диаграмма (несмотря на небольшие недоработки в части реализации внутри Power BI):
Проблема |
Решение |
Отсутствие стандартных решений по «визуалу» по требованиям Заказчика |
Поиск альтернативных визуальных элементов с некими своими доработками. Создание собственных визуальных элементов. Общение с профильным сообществом на форумах, поиск лучших практик решения аналогичных задач. |
Практические приемы ускорения реализации проектов
Приведенный пример имеет много плюсов. Первый из них это наличие «dwh-подхода». Вторым плюсом является распределение ролей между инструментами: ETL-сервер отвечает за часть обработки данных и возникающих в случае чего исключений и ошибок. Третий важный момент это единая точка входа в данные – табулярная модель, которая может изменяться, не требуя изменений внутри BI-системы и другое.
Но есть одно большое «НО», которое зачастую может перевесить все остальные плюсы. Конечно же это время. Как зачастую бывает, для бизнеса самым важным является именно скорость реализации хотя бы MVP или полного решения. Ниже приведем 4 фактора, которые значительно ускорят процесс, но снизят качество подхода и, возможно, далее потребуют закрытия «технического долга» проекта:
1) Обработка excel/csv выгрузок непосредственно в BI среде (внутри Power BI реализуется с помощью подключения таких источников данных с дальнейшей пошаговой обработкой показателей – языком Power Query или просто кодом на языке M, с которыми люди, работающие в Excel, знакомы не понаслышке). Это очень неправильно с архитектурной стороны, но гораздо быстрее, так как пропускается полностью ETL часть, которая часто требует серьезных временных затрат;
2) Подключаться к базе данных напрямую, без использования предварительно подготовленных витрин данных. Тогда имеем внутри Power BI полноценные SQL-запросы, а не такие, которые обычно имеются после подключения нужной тебе витрины: SELECT * FROM View. Конечно, любая доработка запроса приведёт к доработке самого BI дашборда, но мы точно ускорились и нам не потребовалась доработка DWH в виде создания новой View;
3) Не тратить время на создание и поддержание табулярной модели в SSAS. Тогда мы подключаем все таблицы (наборы) данных отдельными единицами и сами (внутри Power BI) устанавливаем связи между ними: 1 к 1, 1 к N, N к N (чего при наличии «dwh-подхода» вообще не может и существовать, если мы имеем 3-ю нормальную форму).
4) При потребности создания новой метрики на дашборде (меры, если мы говорим про Power BI) – создавать её напрямую внутри BI дашборда (не в табулярной модели, так как мы уже отказались от неё). Это ускорит процесс тестирования и «выкатки» реализованной меры, причем DAX-Studio нам всё так же будет помогать в этом.
Заключение
По моему мнению, BI инструменты играют ключевую роль в современном бизнесе, предоставляя компаниям мощные инструменты для анализа данных и принятия обоснованных решений. Внедрение BI системы требует тщательной подготовки и планирования, но в конечном итоге позволяет значительно повысить эффективность работы компании и улучшить её конкурентоспособность.