14.09.2025 09:15
Arkronus 0 261 Источник

Одним из самых распространенных инструментов для внедрения аналитики является BI инструменты – Tableau, Superset, Datalens и многие другие, десятки их. Это отличные инструменты, но какие бы крутые и сложные визуализации традиционно у каждого из таких инструментов одной из важнейших фич является «Экспорт в Excel» - пользователям нужны выгрузки, детальные данные и т.д. На одном из проектов я обсуждал с заказчиком перспективы развития BI в компании – что уже сделано, что делаем дальше и менеджер задал коварный вопрос: «Артём, дашборды это конечно здорово, но можно ли сделать так, чтобы данные загружались к нам сразу в Excel, причем автоматически». И вот что вы придумали...

А зачем это всё-таки нужно?

Перед тем, как приступить к техническому решению мы с коллегами решили уточнить зачем бизнес-пользователям такое нужно, ведь традиционный ответ на такие запросы «А давайте мы сделаем вам новый дашборд, чтобы выгрузка была не нужна». И собрали такие возражения

  1. Форматы отчетов недостаточно гибкие с точки зрения визуала. Excel и Powerpoint разбаловали бизнес-пользователей (особенно топ-менеджмент) и принести им презентацию сделанную «не по шаблону» может привести к большим проблемам, вплоть до увольнения. Многие BI инструменты по гибкости не дотягивают до Excel и бедным аналитикам/менеджерам приходится вручную выгружать/верстать слайды.
    Мне рассказали страшную историю, как одном из отделов руководитель каждую неделю вынужден был тратить по 2 дня на ручную сборку данных и подготовку презентации

  2. BI не справляется с объемом работы и последующих доработок. Ситуации когда BI-специалисты могут сразу полностью быстро удовлетворить запросы пользователей встречаются очень редко. Обычно задача падает в бэклог, потом согласовывается, потом до неё доходит очередь и кто-то берёт её в работу. К этому времени задача может стать не актуальной.

  3. Excel так или иначе знают все специалисты в любом отделе - продажи, маркетинг, финансы. Им удобно получать и анализировать цифры в нём, не прибегая к сторонним инструментам, которые надо изучать дополнительно.

  4. Дашборды не работают для ad-hoc аналитики. Когда нужно быстро свести данные из разных отчетов, то всё равно приходится делать это вручную.

Мы пришли к выводу, что проблема действительно существует и её было бы здорово решить и сформулировали следующие требования

  • У пользователя должна быть возможность загружать данные напрямую в электронные таблички

  • Дальнейшая загрузка/обновление данных должны быть в автоматическом режиме (по таймеру) или вручную. Необходимо избежать ручных выгрузок/загрузок

  • Вся разработка своими силами, закупать коммерческое ПО нельзя – нет бюджета.

Как доставить данные в Excel

Основным инструментом работы аналитиков и менеджеров был Excel. В нём есть механизм импорта данных с помощью Power Query, который позволяет импортировать данные из табличек. Мы хотели воспользоваться им, но столкнулись с ограничениями

  • Из коробки доступны подключения только базам MySQL/SSAS. В компании использовались разные БД – PostgreSQL, Clickhouse, MySQL, поэтому такой подход не работал.

  • Можно было подключится через ODBC, но при этом невозможно было детально ограничить какие данные пользователь мог отбирать, невозможно сделать row-level security или column-level security.

Мы пришли к выводу что это не рабочий подход и стали искать другие варианты. В процессе поисков наткнулись на проект VulcanSQL (https://vulcansql.com/) который позволял создавать Data API – сервер состоящий из эндпоинтов и документации к ним. Бизнес логика формировалась с помощью комбинации SQL и Jinja. К сожалению проект с января 2024 года не обновлялся, поэтому мы решили сделать свою версию.

Создаём Data API сервис.

Свою версию Data API мы написали на Python. Технически он состоял из сервера на FastAPI, у которого каждый endpoint отвечал за доступ к определенному источнику – продажам, запасам и т.д. Перед началом работы мы думали над несколькими фреймворками и остановились на FastAPI по следующим причинам:

  • Высокая производительность и простота разработки. Каждая функция - отдельный эндпоинт для своего источника данных

  • Автоматическая документация Swagger и ReDoc, которую мы дополняли описанием на Markdown

  • Возможность валидировать входящие данные при необходимости

В результате разработчикам и начинающим аналитикам было достаточно просто создавать свои источники данных не прибегая к помощи старших разработчиков.

Логика работы для пользователя выглядела так:

  1. Пользователь направляет запрос на сервер, при необходимости указывает параметры, которые указаны в документации. Например если ему были нужны данные по продажам, то запрос мог выглядеть так

    data_api.company.ru/sales?category=Technology

  2. На основе полученных данных с помощью шаблона Jinja (пример ниже) формируется SQL запрос. В шаблоне мы кодируем всю необходимую логику фильтрации, группировки и обработки данных.

SELECT * 
FROM eu_superstore_orders
WHERE 1=1
{% if context.params.category -%} 
  AND "Category" = '{{ context.params.category }}'
{% endif -%}
{% if context.params.region -%} 
  AND "Region" = '{{ context.params.region }}'
{% endif -%}

  1. Запрос направляется в соответствующую БД, исполняется, результат возвращается пользователю в виду JSON или CSV.

  2. Пользователь может подключится к полученному источнику с помощью Power Query в Excel и таким образом получить прямой, обновляемый источник данных.

Итоги и планы

В итоге пользователи получили простой механизм автоматического обновления данных в Excel. Плюс они могут дорабатывать отчёты с помощью PowerQuery — этому пришлось обучать, но вложения окупились.

Дополнительный бонус — логирование всех действий. Теперь мы видим, кто и когда делает запросы, и можем показать реальную востребованность сервиса.

Что дальше:

  • реализовать row-level и column-level security для разных групп пользователей

  • добавить больше источников данных

  • внедрить слой кеширования, чтобы снизить нагрузку на БД.

Минусы подхода: плохо работает с очень большими объемами данных. При более чем миллионе строк скорость обновления падает. В таких случаях пользователей лучше переводить в классические self-service BI-инструменты.

Комментарии (0)