Привет, меня зовут Владимир Шилов, я руководитель направления в департаменте анализа данных Ростелекома. В мае 2019 года я пришёл в команду Business Intelligence (BI) и одной из первых задач была реализация отчётности по анализу посещаемости отчетов во всех BI-инструментах, установленных в компании.
Решение этой задачи позволило собрать любопытную статистику и
сделать выводы о востребованности BI-инструментов в Ростелекоме. В
этой статье я хочу поделиться следующими результатами нашего
анализа:
Какие BI системы наиболее востребованы в реалиях крупной
компании;
Какие критерии влияют на внутреннюю популярность решения;
Какие современные тенденции пользовательского поведения можно
наблюдать внутри компании и какие вопросы будут стоять перед
ИТ-подразделениями в ближайшее время.
Начну с общего описания ситуации и подходов к сбору информации.
У нас в компании целевыми BI-системами являются:
1.
Oracle BI
2.
Microsoft analysis services
3. Microsoft
Power BI
4. Qlik
Sense
5. Форсайт
Кроме перечисленных инструментов, у нас на разных уровнях также используются более узкоспециализированные и экзотические решения. Но для целей нашей статьи мы опустим эти нюансы, и далее речь пойдет именно о целевых BI-системах (за исключением Форсайта), так как именно они используются в масштабах всей компании, и на наш взгляд их обзор будет более интересен читателям.
Для сбора информации об использовании инструментов было
разработано специализированное решение, подход к реализации
которого можно представить в виде последовательности шагов:
1. Провести анализ логов BI-систем по запуску отчётов;
2. Спроектировать модель витрины данных;
3. Разработать ETL;
4. Реализовать отчет в Power BI;
Решение получилось примерно следующим:
Числа в зелёных стикерах обозначают общее количество инсталляций, в синих количество self-service инсталляций.Очевидно, что любая разработка в крупной компании с некоторой бюрократией превращается в нечто большее, чем просто Возьми и сделай! Ты же мужик! и выполнение простого алгоритма из четырёх шагов. Я довольно сильно погряз в разработку архитектурного решения и согласования его с архитекторами, а также предоставления доступов к логам и ETL. В этой статье описывать свои трудности я детально не буду и сконцентрируюсь на конечном результате.
Для начала предлагаю рассмотреть каждый BI-инструмент в отдельности.
На Oracle BI реализовано подавляющее большинство отчётности в
виду того, что Oracle BI является самым старым инструментом и у
него почти не было альтернативы очень долгое время. Ниже
представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.
На основе второго графика динамики уникальных пользователей
можно сделать вывод, что аудитория BI-системы стабилизировалась и
сильного роста в 2020 году не наблюдается. Этому есть ряд
причин:
Доступ к отчётности требует согласования, а прозрачность процесса
предоставления доступа очень низкая;
Новые предметные области появляются очень редко;
Нет возможности создавать дашборды с аналитикой.
Microsoft Analysis services в компании это тоже достаточно распространённый инструмент, что во многом обусловлено удобной для пользователей работой в Excel. Именно этот инструмент получил наибольшее распространение в компании: он даже более популярен в МРФ (макрорегиональных филиалах), чем в корпоративном центре. Это можно увидеть на следующей диаграмме по уникальным пользователям в разрезе территорий за последние 12 месяцев:
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных OLAP-кубов за период;
Количество уникальных пользователей.
Рост количества используемых OLAP-кубов за последний год не
наблюдается, а рост аудитории в BI-системе нестабильный со
значительными всплесками. У такой статистики несколько причин:
OLAP-кубы в основном дорабатываются, а новые кубы появляются очень
редко;
BI-система больше предназначена для аналитиков, умеющих работать с
данными, и она сложно продается широкой аудитории;
Доступ к отчётности требует согласования с владельцем
OLAP-куба.
BI-система Power BI от Microsoft появилась самой последней в
стеке инструментов компании, но именно к этой системе сейчас
приковано самое большое внимание со стороны бизнеса по следующим
причинам:
Базовый набор визуализаций имеет хороший дизайн;
Лицензирование осуществляется по ядрам на сервере, отсутствует
лицензирование по пользователям;
Скорость разработки отчётов довольно высокая, но стоит отметить,
что на полный цикл разработки это не сильно влияет.
Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:
Стоит отметить, что при относительно низком росте количества используемой отчётности аудитория продолжает расти. Это связанно в большей степени с тем, что доступ к отчётам предоставляется без выделения лицензий на каждого пользователя и изначально нет никаких ограничений по доступу, то есть оформлять заявку не нужно. Уже сейчас наблюдается тенденция перевода отчетов с Qlik sense на Power BI именно потому, что новые пользователи подключаются бесплатно.
Qlik sense была первой корпоративной BI-системой с возможностью
реализации полноценных дашбордов. Именно с Qlik sense связан
переход от предоставления табличных данных к графическим
визуализациям в компании.
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.
Казалось бы, перед нами современный BI-инструмент с высоким
спросом, в котором можно создавать красивые решения, но сильного
роста отчётности по сравнению с Oracle BI и Analysis services мы не
наблюдаем. Тут есть несколько причин, влияющие на аудиторию и
количество новых отчётов:
Лицензия на одного пользователя стоит существенных денег, и поэтому
бизнес отказывается заказывать отчетность в Qlik sense;
Длительный период реализации отчётов от подготовки данных до
реализации не позволяет быстро перенести все бизнес-процессы на
новый инструмент.
Теперь поговорим про инструменты Self-service.
В ноябре 2019 для бизнеса мы развернули self-service и
предложили бизнесу реализовывать свои отчеты на своих источниках
самостоятельно. С точки зрения лицензирования было одно изменение
разработчики лицензируются отдельно. С лицензиями пользователей
изменений не было по причине того, что сервера были объединены в
один кластер и лицензии, соответственно, тоже.
Графики динамик количества запускаемых отчётов и уникальных
пользователей в недельной динамике представлены ниже:
По графикам можно сделать вывод, что первоначальный рост аудитории и количества отчётов остановился в первом квартале 2020 года, а дальше наблюдается стагнация числа уникальных пользователей. Но стоит отметить, что с появлением новых отчётов в сентябре используемость отчётности вернулась на свой максимум, хотя роста аудитории не наблюдается. Основной причиной является высокая стоимость лицензий пользователей системы, что не позволяет делать отчёты для большой аудитории.
Вот мы и дошли к самому интересному. Power BI self-service появился примерно в то же самое время, что и Qlik Sense self-service, но у данных систем есть одно существенное отличие в лицензировании. Для подключения команды разработчиков от бизнеса в Power BI self-service надо разово заплатить за лицензию на 2 ядра, что примерно равняется 35 лицензиям пользователей в Qlik sense, но лимита на пользователей в Power BI нет.
То есть бизнес-подразделение разово платит за одну лицензию и
получает существенные возможности по реализации отчётности для
большой аудитории. Разумеется это позитивно повляло на показатели
используемости данной системы, стоит отметить, что цена вхождения
BI-разработчика в разработку базовых отчетов очень низкая.
Ниже представлены динамики показателей аудитории и количество
отчётов, которые она использует:
Ещё более наглядно всё выглядит если показать все рассматриваемые системы вместе:
В части развития отчетности в BI-системах стоит выделить следующие особенности, которые описаны в таблице:
Свойство\BI-система |
Power BI |
Power BI self-service |
Qlik sense |
Qlik sense self-service |
Analysis services |
Oracle BI |
Лицензирование |
Бесплатно для бизнеса |
Лицензия на 2 ядра на одну команду разработки. Для пользователей бесплатно. |
Лицензия на каждого пользователя |
Лицензия на каждого пользователя и разработчика |
Бесплатно для бизнеса |
Бесплатно для бизнеса |
Вид визуализации |
Дашборды |
Дашборды |
Дашборды |
Дашборды |
Excel таблицы |
Табличные отчеты без аналитики |
Требования к квалификации BI-разработчика |
Низкие |
Низкие |
Средние |
Средние |
Средние |
Выше среднего |
Качество дизайна базовых визуализаций |
Высокое |
Высокое |
Среднее |
Среднее |
Отсутствует |
Низкое |
Процесс подготовки данных |
Централизованное хранилище |
Собственные источники |
Централизованное хранилище |
Собственные источники |
Централизованное хранилище |
Централизованное хранилище |
Предоставление доступа |
Все отчеты публичные |
Все отчеты публичные |
По согласованию владельца лицензий |
По согласованию владельца лицензий |
По согласованию владельца куба |
По согласованию владельца области предметной области |
Исходя из результатов нашего анализа именно критерии, описанные в таблице, оказали самое большое влияние как на скорость создания новой отчетности, так и на востребованность отчетности пользователями компании. А ключевым фактором успеха Power BI self-service стала политика лицензирования и его условная бесплатность для разработчиков на стороне бизнеса.
Из выше сказанного можно сделать вывод, что ключевыми факторами
по использованию отчётности в различных BI-системах являются
(расположены по мере уменьшения значимости):
Стоимость подключения новых пользователей, особенно на большую
аудиторию;
Длительность полного цикла реализации отчёта от подготовки данных
до публикации;
Простота реализации отчётов в BI-системе.
Если бизнесу предоставить возможность самостоятельно заниматься подготовкой данных или предоставить доступ к уже подготовленным данным и дать простой и дешевый инструмент для анализа, то бизнес очень быстро начнёт самостоятельно удовлетворять свои потребности в аналитике данных. При таком подходе остаётся много открытых вопросов: Кто будет сопровождать отчёты и данные в них?, Каким отчётам можно доверять?, Как сделать единую систему отчётности с общей навигацией в едином стиле?.
Несмотря на то, что у ИТ сейчас нет однозначных ответов на эти вопросы, очевидно, что бизнес уже сделал свой выбор в пользу Self-service инструментов, и на эти вопросы нам придется отвечать. Будем рады присоединиться к обсуждению в комментариях. О том, какие решения мы нашли для self-service контура Ростелекома мы расскажем вам в наших будущих статьях.
Статья подготовлена командой управления данными Ростелекома
Добрый день, уважаемые читатели! Материал носит теоретический характер и адресован исключительно начинающим аналитикам, которые впервые столкнулись с BI-аналитикой.
Что традиционно понимается под этим понятием? Если говорить простым языком, то это комплексная система (как и, например, бюджетирование) по сбору, обработке и анализу данных, представляющая конечные результаты в виде графиков, диаграмм, таблиц.
Это требует слаженной работы сразу нескольких специалистов. Дата-инженер отвечает за хранилища и ETL/ELT-процессы, аналитик данных помогает в заполнении базы данных, аналитик BI разрабатывает управленческие панели, бизнес-аналитик упрощает коммуникации с заказчиками отчетов. Но такой вариант возможен, только если фирма готова оплачивать работу команды. В большинстве случаев небольшие компании для минимизации затрат делают ставку на одного человека, который зачастую вообще не обладает широким кругозором в области BI, а имеет лишь шапочное знакомство с платформой для отчетов.
В таком случае происходит следующее: сбор, обработка и анализ данных происходит силами единственного инструмента самой BI-платформой. При этом данные предварительно никак не очищаются, не проходят компоновки. Забор информации идет из первичных источников без участия промежуточного хранилища. Результаты такого подхода можно легко лицезреть на тематических форумах. Если постараться обобщить все вопросы касательно BI-инструментов, то в топ-3 попадут, наверное, следующие: как загрузить в систему плохо структурированные данные, как по ним рассчитать требуемые метрики, что делать, если отчет работает очень медленно. Что удивительно, на этих форумах вы практически не найдете обсуждений ETL-инструментов, описания опыта применения хранилищ данных, лучших практик программирования и запросов SQL. Более того, я неоднократно сталкивался с тем, что опытные BI-аналитики не очень лестно отзывались о применении R/Python/Scala, мотивируя это тем, что все проблемы можно решить только силами BI-платформы. Вместе с тем всем понятно, что грамотный дата инжиниринг позволяет закрывать массу проблем при построении BI-отчетности.
Дальнейший разговор предлагаю построить в форме разбора упрощенных блок-схем. Я сознательно не буду называть конкретные программы, а лишь укажу их класс. Во-первых, это не имеет принципиального значения для раскрытия темы, а, во-вторых, упоминание инструментов сразу приводит к ненужным спорам в комментариях.
Data BI Самый простой вариант. Именно с него начинается прототипирование управленческих панелей. В роли источника данных часто выступает отдельный (-ые) статичный файл (csv, txt, xlsx и т. д.).
Плюсы. Самый быстрый способ построения отчетности. Идеально подходит, для ситуационной аналитики или когда результат нужен был еще вчера. Не требует применения вспомогательных инструментов, следовательно, не нужно тратить ресурсы на их поддержание. Аналитик BI не обязан иметь компетенции в области дата инжиниринга или программирования.
Минусы. Далеко не изо всех источников можно забрать информацию напрямую (пример, прикладные решения на платформе 1С). Если массивы плохо структурированы, то это потребует много дополнительных шагов по их обработке. Качество данных никак не проверяется (проблема дубликатов, пустых строк, некорректного написания значений и т. д.). При большом количестве строк заметно замедляется работа самой BI-платформы, вплоть до полной невозможности перестраивать графики и диаграммы. Нет возможности составить расписание на обновление исходников.
Data DB BI Вариант похож на предыдущий за тем исключением, что первоначальный массив напрямую заливается в базу в неизмененным виде, а уже к ней идет подключение. База данных может быть как развернута локальна, запущена в контейнере, так и представлена облачным хранилищем.
Плюсы. Есть возможность агрегировать разрозненные, однотипные файлы. Нагрузку по хранению информации теперь несет хранилище. Есть возможность задействовать всю мощь языка запросов SQL (или его диалекта), чтобы отфильтровать или агрегировать сырые строки перед их передачей в BI-инструмент. Уменьшается размер файла с управленческими панелями.
Минусы. Нет контроля над первичными данными, поэтому в хранилище заливается большое количество ненужной информации. Качество загружаемых датасетов никак не контролируется. Добавление данных в базу осуществляется в ручном режиме. Аналитик должен на базовом уровне знать SQL.
Data ETL DB BI Частичная автоматизация. В качестве ETL-инструмента может выступать как программный продукт с графическим интерфейсом, так и код написанный на R/Python/Scala и т. д. Все данные проходят предварительный предпроцессинг. Структура наполняемых таблиц прописывается заранее.
Плюсы. Возможность загружать только хорошо структурированную информацию, которая прошла предварительную верификацию. Экономия места в базе данных. Снижается количество доработок на BI-платформе.
Минусы. Аналитик должен уверенно владеть ETL-инструментом и языком запросов SQL. Процесс разработки и тестирования скриптов требует времени. Если источников информации много, то затрудняется синхронизация получения информации.
Для иллюстрации этого варианта я решил написать простейшие скрипты. В рамках игрушечного примера я использую SQLite. Это позволит прикрепить базу данных к публикации, чтобы каждый желающий мог попрактиковаться в написании скриптов (архив). Датасет для разбора это E-Commerce Data с сайта Kaggle.
# импорт библиотекimport pandas as pd# опции отображенияpd.set_option('display.max_columns', 10)pd.set_option('display.expand_frame_repr', False)path_dataset = 'dataset/ecommerce_data.csv'# Предварительная обработка датасетаdef func_main(path_dataset: str): # Считываем датасет df = pd.read_csv(path_dataset, sep=',') # Приводим названия столбцов датасета к нижнему регистру list_col = list(map(str.lower, df.columns)) df.columns = list_col # Избавляемся от времени и трансформируем строку-дату в правильный формат df['invoicedate'] = df['invoicedate'].apply(lambda x: x.split(' ')[0]) df['invoicedate'] = pd.to_datetime(df['invoicedate'], format='%m/%d/%Y') # Рассчитываем сумму покупки по каждому товару df['amount'] = df['quantity'] * df['unitprice'] # Удаляем ненужные для дальнейшего анализа столбцы df_result = df.drop(['invoiceno', 'quantity', 'unitprice', 'customerid'], axis=1) # Задаем порядок вывода столбцов для визуального контроля результата df_result = df_result[['invoicedate', 'country', 'stockcode', 'description', 'amount']] return df_result# Таблица Продажиdef func_sale(): tbl = func_main(path_dataset) df_sale = tbl.groupby(['invoicedate', 'country', 'stockcode'])['amount'].sum().reset_index() return df_sale# Таблица Страныdef func_country(): tbl = func_main(path_dataset) df_country = pd.DataFrame(sorted(pd.unique(tbl['country'])), columns=['country']) return df_country# Таблица Товарыdef func_product(): tbl = func_main(path_dataset) df_product = tbl[['stockcode','description']].\ drop_duplicates(subset=['stockcode'], keep='first').reset_index(drop=True) return df_product
В коде сочетается Extract и Transform. Считываем датасет, парсим столбец с датами. Рассчитываем сумму покупки по каждой строке и удаляем ненужные для дальнейшего анализа колонки. Так как датафрейм записывается в базу данных не монолитом, а разбивается на таблицы, то готовим три вспомогательные функции.
# импорт библиотекimport pandas as pdimport sqlite3 as sqfrom etl1 import func_country,func_product,func_salecon = sq.connect('sale.db')cur = con.cursor()## Таблица Страны# cur.executescript('''DROP TABLE IF EXISTS country;# CREATE TABLE IF NOT EXISTS country (# country_id INTEGER PRIMARY KEY AUTOINCREMENT,# country TEXT NOT NULL UNIQUE);''')# func_country().to_sql('country',con,index=False,if_exists='append')## Таблица Товары# cur.executescript('''DROP TABLE IF EXISTS product;# CREATE TABLE IF NOT EXISTS product (# product_id INTEGER PRIMARY KEY AUTOINCREMENT,# stockcode TEXT NOT NULL UNIQUE,# description TEXT);''')# func_product().to_sql('product',con,index=False,if_exists='append')## Таблица Продажи (основная)# cur.executescript('''DROP TABLE IF EXISTS sale;# CREATE TABLE IF NOT EXISTS sale (# sale_id INTEGER PRIMARY KEY AUTOINCREMENT,# invoicedate TEXT NOT NULL,# country_id INTEGER NOT NULL,# product_id INTEGER NOT NULL,# amount REAL NOT NULL,# FOREIGN KEY(country_id) REFERENCES country(country_id),# FOREIGN KEY(product_id) REFERENCES product(product_id));''')## Таблица Продажи (временная)# cur.executescript('''DROP TABLE IF EXISTS sale_data_lake;# CREATE TABLE IF NOT EXISTS sale_data_lake (# sale_id INTEGER PRIMARY KEY AUTOINCREMENT,# invoicedate TEXT NOT NULL,# country TEXT NOT NULL,# stockcode TEXT NOT NULL,# amount REAL NOT NULL);''')# func_sale().to_sql('sale_data_lake',con,index=False,if_exists='append')## Перегружаем данные из вспомогательной таблицы (sale_data_lake) в основную (sale)# cur.executescript('''INSERT INTO sale (invoicedate, country_id, product_id, amount)# SELECT sdl.invoicedate, c.country_id, pr.product_id, sdl.amount# FROM sale_data_lake as sdl LEFT JOIN country as c ON sdl.country = c.country# LEFT JOIN product as pr ON sdl.stockcode = pr.stockcode# ''')## Очищаем вспомогательную таблицу# cur.executescript('''DELETE FROM sale_data_lake''')def select(sql): return pd.read_sql(sql,con)sql = '''select * from (select s.invoicedate, c.country, pr.description, round(s.amount,1) as amount from sale as s left join country as c on s.country_id = c.country_id left join product as pr on s.product_id = pr.product_id)'''print(select(sql))cur.close()con.close()
На следующем этапе (Load) мы создаем четыре таблицы. Две из них будут справочниками. Одна содержать сгруппированную информацию по продажам. Нам также потребуется вспомогательная таблица, в которую мы запишем строки с продажами до момента замены текстовых значений на числовые ид. На последнем шаге очистим ее от всех значений.
В заключении нам остается лишь выполнить тестовый запрос SQL, чтобы проверить корректность всех операций. Если все сделано правильно, запускаем BI-платформу.
Так как BI-инструмент не может из коробки напрямую подключиться к SQLite напишем простейший скрипт на Python.
import pandas as pdimport sqlite3 as sqcon = sq.connect('C:/Users/Pavel/PycharmProjects/test/sale.db')cur = con.cursor()def select(sql): return pd.read_sql(sql,con)sql = '''select * from (select s.invoicedate, c.country, pr.description, replace(round(s.amount,1),'.',',') as amount from sale as s left join country as c on s.country_id = c.country_id left join product as pr on s.product_id = pr.product_id)'''tbl = select(sql)print(tbl)
После загрузки данных в систему и проверки корректности распознанных форматов можно приступать к непосредственному построению дашборда.
Data Workflow management platform + ETL DB BI Полная автоматизация. Оркестратор скриптов берет на себя контроль за своевременным выполнением всех вспомогательных процессов в системе.
Плюсы. Возможность оптимально настроить время сбора данных из разрозненных источников. Можно мониторить ошибки и перезапускать упавшие задачи.
Минусы. Усложнение инфраструктуры. Рост требований к квалификации аналитика BI. Необходимо осваивать дополнительные инструменты или языки программирования.
Data Workflow management platform + ELT Data Lake Workflow management platform + ETL DB BI Самый сложный вариант, где информация проходит двухступенчатый конвейер: сначала это неструктурированные данные (Data Lake), а затем уже хранилище (DB), где информация отсортирована и преобразована к требуемому виду.
Плюсы. Возможность разнести во времени сбор информации и ее обработку. Если на этапе проектирования таблиц учтены не все требования, возможно обращение за дополнительными данными в Data Lake.
Минусы. Аналогичны предыдущему варианту. Если выбранная платформа Data Lake платная, как следствие рост расходов на аналитику компании.
Краткие выводы.
Построение BI-аналитики без даты инжиниринга возможно лишь на старте.
Если аналитик BI работает в единственном числе и система постоянно усложняется, то он обязан подменять собой сразу несколько специалистов.
Понимание базовых принципов построения хранилищ данных, уверенное владение SQL, программирование на каком-либо языке и, конечно, дизайнерские навыки вот далеко не полный перечень требований к сотруднику, которому делегируется проектировать управленческие панели.
На этом все. Всем здоровья, удачи и профессиональных успехов!