🔦📈 BI на максималках: 4 варианта ускорения реализации комплексных решений

Привет всем!

Я, Ипатов Александр, backend-разработчик в компании USETECH. Я уже написал несколько статей на тему BI разработки на всеми любимом и удобном ресурсе «Библиотека программиста» (proglib.io). В данном материале расскажу о практических приемах ускорения реализации BI проектов.

Почему это может быть важно и вообще, в чем смысл ускорять разработку?

Обычно, ускоряя разработку, мы снижаем качество решений. Но это со стороны разработки 😊. А со стороны бизнеса нужна скорость. Нужно, чтобы продукт был «уже вчера», так как конкуренты на рынке не спят, а ждут, когда мы опоздаем и примем неверное решение по направлению развития, или просто пропустим важный инсайт, который можно было увидеть из данных, благодаря использованию Business Intelligence. А это есть ничто иное, как совокупность технологий, методов и процессов, предназначенных для анализа данных и предоставления информации, необходимой для принятия обоснованных бизнес-решений. Интересно отметить, что согласно рейтингу TAdvisor, в последние годы BI стал неотъемлемой частью любой успешной организации, независимо от её размера и отрасли.

Выбор BI-инструмента в основном зависит от потребностей компании (или частного лица) и возможностей по приобретению лицензий в санкционном режиме. Если у компании не возникает проблем по приобретению лицензий продуктов — то я бы рекомендовал использовать Microsoft Power BI (по моему скромному и субъективному мнению), поскольку он является одним из самых проработанных и с самым мощным ETL функционалом внутри (язык M, Power Query и пр.). Если проблемы имеются, то можно рассмотреть три варианта: Российские BI — Visiology, Yandex DataLens; Западный Open-source — Apache Superset ; Азиатский аналог — FineBI. Но, как говорится, «на вкус и цвет — товарищей нет», и каждый найдет для себя конкретные большие плюсы в каждом из указанных инструментов. Например, многим очень нравится QlikSense за то, что внутри него можно удобно работать с разными «слоями» как-бы хранилища, организованного внутри него.

Подход к реализации работы с использованием BI систем

Кратко опишу классический и качественный подход к реализации работы с использованием BI систем так, чтобы все лежало на своих местах, «по полочкам».

Для начала нужно продумать, каким будет Data Warehouse (DWH, корпоративное хранилище данных) — выбрать технологии (OLAT / OLTP, Greenplum, Postgres, Clickhouse, Oracle, Microsoft), подобрать модель данных, определиться со слоями, проработать схему связей между сущностями и пр.

Также важно реализовать понятный ETL — инструментарий (Airflow, Dagster, Informatica), который можно будет поставить на расписание и отслеживать успехи / неудачи обработки и «перелива» данных по слоям. Еще нужно иметь возможность насыщать DWH новыми сущностями, то есть позволить расширять хранилище под бизнес-запросы.

В дополнение, можно упомянуть возможность реализации так называемых OLAP-кубов. Например, можно создать «Табулярную модель» (Tabular model) в Microsoft SQL Server Analysis Services, куда уже подключить подготовленную для конкретного дашборда модель данных, и непосредственно в дашборд (Power BI, как пример) подключать эту табулярную модель.

Приведенный вариант архитектуры решения имеет несколько плюсов. Первый из них — это наличие «dwh-подхода». Вторым плюсом является распределение ролей между инструментами: ETL-сервер отвечает за часть обработки данных и возникающих в случае чего исключений и ошибок. Третий важный момент — единая точка входа в данные (табулярная модель), которая может изменяться, не требуя изменений внутри BI-системы и другое.

Но есть одно большое «НО», которое зачастую может перевесить все остальные плюсы. Конечно же это время. Как часто бывает, для бизнеса самым важным является именно скорость реализации хотя бы MVP или полного решения. Ниже приведем четыре фактора, которые значительно ускорят процесс, но снизят качество подхода и, возможно, далее потребуют закрытия «технического долга» проекта:

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 системы требует тщательной подготовки и планирования, но в конечном итоге позволяет значительно повысить эффективность работы компании и улучшить её конкурентоспособность.