Словник для BI і аналітичних інженерів

Бізнес-інтелект і аналітична інженерія знаходяться на перехресті інженерії даних, статистики і бізнес-комунікації. Інженери BI будують моделі даних, панелі управління і звіти, які допомагають організаціям розуміти їхню продуктивність. Словник містить як технічні поняття (OLAP, схема зірок, DAX), так і терміни бізнес- комунікації (KPI, drill- down, slice- and- dice).

---

Використовується для моделювання даних

Схема зорі

** Star schema ** — це схема бази даних, яку використовують у сховищах даних. Вона складається з центральної ** таблиці фактів **, оточеної ** таблицями розмірів **, утворюючи форму, що нагадує зірку.

• “Наше сховище даних використовує зіркову схему: у центральній таблиці фактів зберігаються операції з продажу, а у таблицях розмірів міститься інформація про клієнтів, продукти, дати і магазини.” *
• “Схема зірок оптимізована для швидкодії запиту — більшість аналітичних запитів можна виконати шляхом приєднання таблиці фактів до таблиць одного або двох розмірів.” *

Таблиця фактів

Таблиця фактів містить вимірювані, кількісні дані — «факти» бізнес-процесу, який аналізується.

• “Таблиця фактів продажів містить один рядок для кожної операції, зі стовпчиками для кількості, доходу, знижки і вартості.” *

Таблиця розмірів

Таблиця ** розмірів ** містить описові атрибути, які нададуть контекст для фактів.

“Вимір клієнта включає ім’ я клієнта, сегмент, регіон, канал придбання і дату створення облікового запису.”

Схема сніжинок

Схема snowflake є варіацією схеми зірок, де таблиці розмірів далі нормалізуються до таблиць підрозмірів.

• “Ми обирали схему зірок замість схеми сніжинки для шару звіту, оскільки простота запиту має більше значення, ніж нормалізація зберігання для нашого випадку використання.” *

Дані Марта

** Data Mart ** є підмножина складу даних, зосереджена на певній бізнес-функції або відділі.

“Команда фінансів має власний ринок даних з попередньо агрегованими даними про прибуток, вартість і маржу — їм не потрібен доступ до повного складу даних на рівні транзакцій.”

---

О. О. Леніна та концепції

OLAP (Online Analytical Processing) — онлайнова аналітична обробка

** OLAP ** — це технологія для аналізу багатовимірних даних. Системи OLAP дозволяють користувачам швидко запитувати великі набори даних по декількох вимірах.

• “Куб OLAP дозволяє команді продажів одночасно аналізувати прибутки за продуктом, регіоном і періодом часу — без запуску повільних спецзапитів SQL.” *

Дриль-доун

** Дослідження даних ** — це дія навігації з перегляду резюме до більш докладного рівня даних.

• “Я можу перейти від загального річного доходу до щомісячного, потім до щотижневого, а потім до окремих транзакцій, якщо це потрібно.” *
• “Звіт підтримує зниження: натискання на країну показує прибуток за містом; натискання на місто показує прибуток за магазином.” *

Ролл-Ап

** Згортання ** є протилежним до розгортання — агрегування докладних даних до більш високого рівня резюме.

• “Ми складаємо щоденні дані про продажі в щотижневі та щомісячні підсумки для виконавчої панелі.” *

Порізати і нарізати кубиками

** Сліт ** означає фільтрування даних за однією вимірністю. ** Кісочка ** означає фільтрування за декількома вимірностями одночасно.

• “Я розрізав дані за сегментом клієнтів «Компанія», щоб побачити, як працює ця когорта.” * “Розділення даних на регіони, категорії продуктів і квартали дає керівництву продажів необхідний огляд для QBR.”

Pivot

** Поворот ** означає обертання даних так, щоб рядки стали стовпчиками (або навпаки), щоб показати їх у іншій орієнтації.

“Ми переглянули щомісячні доходи за категоріями продуктів — те, що було довгою, вузькою таблицею, стало широким звітом, що показує кожну категорію як окрему колонку.”

---

Метрики і KPIs

Ключеві показники ефективності (KPI)

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

• “Нашим основним показником зростання є щомісячна кількість активних користувачів (MAU). Наші вторинні KPI - це середня тривалість сеансу і рівень прийняття функцій. ”* “На панелі показано п’ ять KPI: коефіцієнт конверсії, середня вартість замовлення, вартість придбання клієнта, коефіцієнт відмови і NPS.”

Лідер vs. Індикатори відстань

• Віддалені показники передбачають майбутню ефективність (наприклад, кількість розпочати випробувань)
• ** Відстаючі показники ** вимірюють минулі показники (наприклад, щомісячний прибуток)

• “Рівень відходу клієнтів — це відстаючий показник — до того часу, коли він підвищується, клієнти вже залишили ваш сайт. Ми хочемо відстежувати провідні показники, які передбачають відтік, перш ніж це станеться.”*

---

Запитання мовами

DAX (Data Analysis Expressions) — аналіз даних

** DAX ** — це мова формул, яку використовують у Microsoft Power BI, Excel Power Pivot і Analysis Services. Його використовують для створення обчислюваних стовпчиків, мір і таблиць.

• “Я написав мірку DAX для обчислення доходу за 12- місячний період: у ній використовуються функції DATESINPERIOD і CALCULATE для агрегування даних за виміром дати.” *
• “Контекст DAX є одним з найважливіших поняттів, які слід розуміти — одна і та ж міра може повертати різні значення залежно від контексту фільтра, застосованого візуальним елементом.” *

MDX (багатовимірні вирази)

** MDX ** — це мова запиту для баз даних OLAP (наприклад, SQL Server Analysis Services).

• “Стара система звітів використовує запиту MDX для куба SSAS. Ми мігруємо ці звіти до моделей, заснованих на DAX в Power BI. “*

---

Архітектура сховища даних

В. І. Леніна

• ** ETL ** (Extract, Transform, Load) — дані перетворюються перед завантаженням у сховище
• ** ELT ** (Витяг, завантаження, перетворення) — спочатку завантажуються необроблені дані, а потім їх перетворюють у сховищі

• “Ми перейшли з ETL на ELT — необроблені дані тепер спочатку потрапляють на склад, а перетворення відбуваються в dbt. Це дає нам повний родовід і робить легшим переобробку історичних даних.”*

dbt (засіб збирання даних)

** dbt ** — це інструмент перетворення, який надає змогу інженерам з аналітики писати моделі SQL, перевіряти їх і документувати їх як частину потоку роботи з контролем версій.

• “Всі наші перетворення даних визначено як моделі dbt. Кожна модель перевіряється на нульові значення і посилання цілісності перед тим, як вона підвищується до рівня звітів. “*

---

Практичні фрази для інженерів

• • “Табліці фактів потрібно визначення зерна — що представляє один рядок?” *
• • “Це KPI є індикатором відставання. Ми повинні додати лідируючий індикатор, який прогнозує його.»*
• “Дозвольте мені проаналізувати цифри за 3 квартал — я бачу, що загальна сума неправильна, але мені потрібно знайти, який регіон є причиною дисперсії.”
• • « Куб OLAP автоматично агрегує цю вимірність — обробка знизу здійснюється кубом, а не нетиповим запитом. » *
• • “Відношення DAX обчислює відхилення від місяця до місяця за допомогою PREVIOUSMONTH.” *

---

BI і аналітичний словник перетинає прогалини між необробленими даними і прийняттям бізнес-рішень. Використання цих термінів допомагає вам спілкуватися як з командою інженерів з обробки даних, яка створює конвеєри, так і з бізнес- партнерами, які покладаються на звіти.

Забезпечення підтримки для нерідних мов

Термінологія навколо бізнес-інтелекту (BI) і аналітичної інженерії може бути неймовірно щільною. Для розробників, які походять з країн, де англійська мова не є основною мовою, навігація цими складними термінами - DAX, MDX, зіркові схеми, KPI - може бути приголомшливою. Це не просто про те, щоб знати визначення; це про те, щоб розуміти як ці терміни використовуються в практичних розмовах і документації. Ця частина розроблена з метою надання адресованої підтримки для цього переходу, зосередження уваги на типових сценаріях, з якими ви можете зіткнутися, і надання порад щодо вимови, які не обмежуються простим пошуком у словнику.

Однією з найбільших проблем часто є розуміння нюансів за запитами і відгуками. Розгляньте це повідомлення Slack під час перегляду коду: « Цей запит виглядає повільно — чи можете ви його оптимізувати? Можливо, варто розглянути можливість використання більш детального фільтра даних, щоб зменшити кількість оброблених даних?» Ключовим тут є не лише « фільтр даних », але і « як » це робити. Рецензент непрямо пропонує потребу у більшому скороченні даних, можливо, використовуючи щось на зразок попередньо агрегованої таблиці або кращого індексу. Аналогічно, у описі завдання на звантаження ви можете побачити: « Впровадити нову панель KPI для відстеження кількості відходів клієнтів. Візуалізація повинна надавати користувачам змогу * розрізати і розрізати на шматки * дані за регіоном і категорією продукту. » Фраза « розрізати і розрізати на шматки » є ідіоматичною; вона не означає буквально розрізати овочі. Це відноситься до здатності аналізувати дані з різних точок зору - розбиваючи їх на менші сегменти, а потім розглядаючи ці сегменти окремо, досліджуючи зв’язки між змінними. Це вимагає розуміння того, що запит не просто про створення панелі, а про надання користувачам інтерактивних аналітичних можливостей. Сфокусуйтеся на розумінні намірів за термінологією — яку проблему описують?

Інша поширена перешкода включає обговорення технічних специфікацій. Припустимо, що ви документуєте новий процес перетворення даних за допомогою SQL: SELECT DATE_TRUNC('year', order_date) AS year, COUNT(*) AS orders FROM orders GROUP BY year ORDER BY year; Коли ви пояснюєте це колегі, ви не просто скажете « Цей запит обрізає дату до рівня року ». Замість цього ви можете сказати: « Це перетворення витягує рік зі стовпчика order_date, а потім підраховує кількість замовлень у кожному році, упорядкованих за цим роком. Він розроблений для того, щоб надати загальний огляд тенденцій продажів за певний час. ” Метою є повідомлення про * мету * і * вплив * коду, а не тільки його механіки.

Нарешті, пам’ятайте, що активне слухання і запитання прояснюючих питань є ключовими. Не вагайтеся сказати: « Чи можете ви розібратися, що ви маєте на увазі під « оптимізацією цього запиту »? » або « Чи можете ви надати приклад того, як ми можемо « розрізати і розбити » ці дані? » Ці прості фрази демонструють бажання вчитися і заповнити будь- які прогалини у спілкуванні.

SELECT DATE_TRUNC('year', order_date) AS year, COUNT(*) AS orders
FROM orders
GROUP BY year
ORDER BY year;