Побудова аналітичної звітності

1. Вступ

Побудова аналітичних звітів на Платформі є можливою завдяки сервісу Redash — інструменту для візуалізації даних, призначеного для вивчення, запита, візуалізації та обміну даними з будь-яких джерел даних та побудови відповідних інформаційних панелей (дашбордів) за цими даними.

Процес побудови аналітичних звітів у Redash поділяється на декілька основних етапів:

  1. Підключення до Redash джерела даних, тобто, підключення БД, звідки Redash отримуватиме дані для аналітики (див. https://redash.io/help/user-guide/getting-started#1-Add-A-Data-Source).

  2. Створення (написання) пошукових запитів до БД (див. https://redash.io/help/user-guide/querying).

  3. Створення візуалізацій (візуальних зображень отриманих даних) на основі запитів (див. https://redash.io/help/user-guide/visualizations).

  4. Побудова інформаційних панелей (дашбордів) — поєднання візуалізацій та текстових полів, що надають контексту даним, що візуалізуються Redash (див. https://redash.io/help/user-guide/dashboards).

2. Загальний опис

Функціонування аналітичної звітності забезпечують два екземпляри Redash, що вибудовують систему звітності на базі репліки операційної бази даних реєстру.

Один екземпляр — admin — розгортатиметься в мінімальному об’ємі для адміністрування, розробки та публікування звітності. З міркувань безпеки його відокремлено від іншого — viewer, що міститиме опублікований контент для потреб користувачів.

Доступ до контенту серверів Redash розмежовується за приналежністю користувача до групи, що, своєю чергою, асоційована із джерелом даних.

Розмежування доступу до даних реалізується за допомогою користувачів бази даних, що використовуються відповідним джерелом даних для виконання запитів до репліки БД.

2.1. Архітектурна діаграма

data analytics architecture

3. Розділення Redash на екземпляри

На етапі ініціалізації екземплярів Redash необхідно створюються наступні службові Джерела Даних (Data Source) та безпекові групи та права доступу, які асоціюються їх між собою:

Таблиця 1. Статичні об’єкти, що створюються під час первинного розгортання Redash
Redash Instance Group Permissions Data Source Access Level

admin

-

"create_dashboard", "create_query", "edit_dashboard", "edit_query", "view_query", "view_source", "execute_query", "list_users", "schedule_query", "list_dashboards", "list_alerts", "list_data_sources"

registry

Full Access

viewer

auditor

"view_query", "execute_query", "list_dashboards", "list_alerts", "list_data_sources"

registry_auditor

View Only

Користувачі реєстру мають використовувати ролі Keycloak для доступу до звітів Redash. Для кожної такої ролі слід створювати відповідну вертикаль об’єктів на рівні Redash та БД.

Регламентні ролі описані у файлі roles/officer.yaml відповідного Gerrit-репозиторію. Тому для кожної регламентної ролі Jenkins створює наступні об’єкти:

Таблиця 2. Динамічні об’єкти, що створюються після внесення змін до файлу roles/officer.yaml
Redash Instance Group Permissions Data Source Access Level

viewer

<назва ролі>

"view_query", "execute_query", "list_dashboards", "list_alerts", "list_data_sources"

registry_<назва ролі>

View Only
Приклад створення групи auditor для екземпляра viewer
curl --location --request POST 'http://{{Redash URL}}/api/groups' \
--header 'Content-Type: application/json' \
--header 'Authorization: {{API Key}}' \
--data-raw '    {
        "permissions": [
            "view_query",
            "execute_query",
            "list_dashboards",
            "list_alerts",
            "list_data_sources"
        ],
        "name": "auditor"
    }'
Наразі відсутня можливість надавати дозволи (permissions) при створенні групи через ендпоінт */api/groups.
API приймає зазначену структуру та все одно використовує повний набір дозволів. Тому обмеження прав для груп, створених за регламентними ролями, можливе лише через CLI.
Після створення групи отримуємо group_id для подальшого використання.
Приклад створення джерела даних registry для екземпляра admin
curl --location --request POST 'http://{{Redash URL}}/api/data_sources' \
--header 'Content-Type: application/json' \
--header 'Authorization: {{APY KEY}}' \
--data-raw '{
    "name": "Admin Registry",
    "queue_name": "queries",
    "syntax": "sql",
    "options": {
        "host": "citus-master-rep",
        "password": "--------",
        "dbname": "registry",
        "user": "registry"
    },
    "type": "pg"
}'
Після створення джерела даних отримуємо data_source_id для подальшого використання.
Приклад асоціювання джерела даних registry_db з групою Registry Admins для екземпляра admin
curl --location --request POST 'http://{{Redash URL}}/api/groups/{{Group ID}}/data_sources' \
--header 'Content-Type: application/json' \
--header 'Authorization: {{API Key}}' \
--data-raw '{"data_source_id": {{Data Source ID}}'

Останнім кроком є налаштування рівня доступу до джерела даних з боку користувачів групи.

За замовчуванням рівень доступу — Full Access, тому для екземпляра admin цей крок не потрібний.
Приклад налаштування рівня доступу View Only для групи registry_officer джерела даних registry_db на екземплярі officer
curl --location --request POST 'http://{{Redash URL}}/api/groups/{{Group ID}}/data_sources/{{DS ID}}' \
--header 'Content-Type: application/json' \
--header 'Authorization: {{API Key}}' \
--data-raw '{
    "view_only": true
}'

4. Надання прав доступу до звітності

Область видимості доступних об’єктів Redash визначається джерелом даних — користувач бачить ті запити (Queries) та інформаційні панелі (dashboards), що утилізують доступне користувачеві джерело даних.

Рівень прав доступу до об’єктів системи звітності регулюється групами. На етапі первинного розгортання системи, групи асоціюються з відповідними джерелами даних.

5. Доступ до даних та розмежування прав

Для кожного джерела даних, доданого на Redash-екземплярах, необхідно створити також відповідного користувача бази даних. Представлена нижче таблиця задає назву користувача бази даних для кожного джерела даних Redash:

Data source Database User

registry

analytics_admin

registry_auditor

analytics_auditor

registry_<назва ролі>

analytics_<назва ролі>
<назва ролі> — змінна, що потребує значення для назви ролі.
Користувачі бази даних створюються лише в репліці операційної бази даних, не в операційній БД!
Створення користувачів відбувається за фактом внесення змін до файлу roles/officer.yaml Gerrit-репозитарію реєстру.

Доступ до даних реєстру має надаватися через окремий прошарок представлень (view).

Для цього в моделі даних, з використанням шаблону Liquibase, необхідно створити відповідний критерій пошуку в БД (Search Condition). Liquibase створить представлення лише на репліці операційної бази даних, що також дозволить уникнути створення API для об’єктів аналітики.

Приклад створення представлення для подальшого використання при побудові звітності:
    <changeSet author="registry owner" id="create report_ownership view">
        <ext:createAnalyticsView name="report_ownership">
            <ext:table name="ownership">
                <ext:column name="ownership_id"/>
                <ext:column name="name"/>
            </ext:table>
        </ext:createAnalyticsView>
    </changeSet>
Вихідний SQL-запит на базі XML-шаблону
SELECT ownership.ownership_id,
       ownership.name
FROM ownership;
Назва аналітичного представлення має починатися префіксом 'report_'.
За детальною інформацією щодо створення моделі даних за допомогою шаблонів Liquibase зверніться до сторінки Перелік розширених тегів Liquibase.

Після створення представлення, необхідно відповідній ролі надати доступ до створеного об’єкта, в залежності від того, які ролі мають право доступу до звітів, що будуватимуться на створених представленнях.

Надавати доступ користувачеві до представлення необхідно через окремий тег в XML-шаблоні Liquibase, що детально описано на сторінці Права доступу до аналітичних даних.

6. Дизайн та розробка звітності

6.1. Передумови

Передумовою для розробки звітів в системі Redash є виконання всіх описаних вище кроків, а саме:

  • В репліці операційної БД створено користувача analytics_admin.

  • Створено Search Condition та надано права доступу на запит даних із відповідного представлення (view) користувачу analytics_admin.

  • На екземплярі Redash admin створено Джерело Даних — Admin Registry.

  • На екземплярі Redash admin створено Групу — Registry Admins.

  • Користувача, що розроблятиме звіт, додано до Групи Registry Admins.

6.2. Створення інформаційної панелі (дашборду)

Кінцевим продуктом, що можна опублікувати для використання користувачами, є інформаційна панель (дашборд).

Нижче подано порядок кроків, які необхідно виконати для створення інформаційної панелі.

6.2.1. Створення Запита (Query)

  1. Натисніть кнопку Create → Query.

  2. Введіть запит до бази даних.

  3. Збережіть Запит, натиснувши кнопку Save.

  4. Змініть назву New Query на потрібну.

При створенні Запита можна вказати необхідні параметри.
Якщо перейти до секції Редагувати джерело, натиснувши відповідну кнопку, параметр за замовчуванням матиме наступний формат: '{{ parameter_name }}'.
У разі, якщо значення параметра міститимуть в собі апостроф (наприклад, ПІБ, назва тощо), потрібно використовувати особливий формат Dollar-Quoted String Constants у вигляді: $quote${{ parameter_name }} $quote$.

6.2.2. Створення Візуалізації (Visualization)

  1. Відкрийте необхідний Запит.

  2. Натисніть кнопку New Visualization.

  3. Оберіть тип візуалізації та зазначте необхідні параметри.

  4. Збережіть візуалізацію, натиснувши кнопку Save.

6.2.3. Створення інформаційної панелі (дашборда)

  1. Натисніть кнопку Create → Dashboard.

  2. Введіть назву дашборда.

  3. Натисніть кнопку Add Widget.

  4. Введіть назву Запита.

  5. Оберіть необхідну візуалізацію.

  6. Додайте обрану візуалізацію до дашборда, натиснувши кнопку Add to Dashboard.

  7. Розмістіть доданий елемент у потрібному місці та зазначте необхідний розмір.

За необхідності, виконайте пункти c-g для всіх візуалізацій, що мають бути включені до інформаційної панелі.

Після завершення редагування натисніть кнопку Done Editing.
Опублікуйте дашборд — натисніть кнопку Publish.