Зачем мы используем SQL в отчётах???

В IBM Cognos BI между БД и отчётом есть набор промежуточных слоёв — модель данных. Тем не менее, разработчики регулярно игнорировали её возможности и вставляли SQL-запросы непосредственно в отчёты.
Это была небольшая речь, призванная пресечь данную практику.
Слайды были оформлены в виде короткого видео (как современные сториз).

Достигнутый результат: SQL в отчётах был запрещён (с парой исключений). При проверке отчётов перед релизом — проверяется в т.ч. отсутствие SQL-запросов.

Оглядываясь назад: Использование SQL является симптомом, что в данном случае Cognos является неподходящим BI-инструментом, а промежуточная модель не требуется. Степень связанности данных между отчётами практически нулевая, и модель не решает никаких реальных проблем, а только усложняет архитектуру и требует дополнительных ресурсов и времени на разработку и поддержку.

Логическая модель начинает быть нужна, когда появляется какая-то единая система показателей, сквозных метрик и т.п. Следующий уровень зрелости. Чтобы дойти до него, требуется много времени и усилий. А потому, пока этой потребности нет, лучше выбирать более простой BI-инструмент. По моему опыту, аналитика в большинстве организаций до уровня потребности в промежуточной модели вообще никогда не дорастает.
Кроме того, та же единая система показателей может быть реализована на уровне витрин, и модель опять получается не нужна.

IBM Cognos также позволяет интегрировать между собой данные из нескольких источников (выполнять федеративные запросы). Однако такая обработка (соединения) происходит уже не на источниках (push-down), а на сервере Cognos. BI-сервер это не СУБД и не полноценный SQL-движок, и эта доп. обработка существенно замедляет запросы и нагружает сервер.
Получается, что эту функциональность можно использовать только на небольших объёмах. На которых модель не особо и требуется, можно обойтись чистым SQL.
А уже при средних объёмах надо делать полноценную интеграцию данных на уровне БД, строить хранилище, и модель опять становится не нужна.

В данном случае наличие модели было требованием заказчика. Заказчик преследовал две цели:
1) Строить отчёты самостоятельно — но фактически практически не строил
2) Искать показатели по бизнес-названиям — но для выполнения этой функции правильнее было бы реализовать каталог данных

Transcript

1. Зачем мы используем SQL в отчётах??? Василий Горохов-Апельсинов 2018-10-05
2. Кто мы?
3. Читаем классику
4. Interface vs Implementation
5. “API” разработчика отчётов Cognos • ПолучитьЗадачуНаРазработкуОтчёта • СообщитьСтатус • ВыдатьГотовыйОтчёт • ПолучитьЗарплату Картинка
6. Абстракция Каждый слой – зависит только от интерфейса слоя, лежащего ниже, и предоставляет интерфейс лежащему выше
7. Наша ситуация Горизонтально ?
8. Изменения • Меняются требования и окружение • Даже в константных условиях наивно думать, что кто-то с первого раза построит хорошую архитектуру • Не надо этого бояться, надо к этому готовиться Картинка
9. Рефакторинг
10. Минусы SQL в отчёте • Нарушение абстракции Требуется поддержка совместимости одновременно с двумя слоями • Справочники: • Добавились новые атрибуты – они не доступны. Требуется доработка • Невозможно переиспользовать • Пользователи не могут повторить / докрутить • Сложно тестировать и диагностировать • Сложно менять (патч Oracle vs Cognos)
12. Решения без SQL • Делать на существующей модели • Дорабатывать существующую модель: • добавлять недостающие связи и т.п. • Представления-витрины • Факты (без привязанных справочников!) • Специально обработанные справочники • Pipeline-функции • Предрассчитанные витрины
13. SQL в отчётах должен быть запрещён • См. минусы ранее • Нет ни одного случая, когда нельзя сделать через модель • Когда SQL используют пользователи – нам придётся поддерживать этот интерфейс SQL
14. Не хватает времени…
15. Технический долг & Скорость