Наступна межа демократизації аналітики даних, ймовірно, не так вже й далеко.
Ідея «демократизації даних» в корпоративному середовищі існує вже деякий час. Вона приймала різні форми протягом років, такі як інструменти для самообслуговування BI, кращий доступ до команд даних та, нещодавно, AI-асистенти для тексту в SQL. Проте основна концепція залишалася незмінною: «Вашому бізнесу потрібні дані для роботи, і більше людей у вашій організації повинні мати можливість ефективно їх використовувати.»
Цей рух для того, щоб зробити дані корисними, призвів до численних покращень:
- Інструменти BI чудово підходять для аналізу чистих, добре структурованих даних.
- Добре підтримуваний стек даних дозволяє зберігати дані в належному вигляді — до того моменту, поки масштабування не перевищить здатність вашої команди управляти цими даними.
- Існує безліч AI-інструментів, які обіцяють демократизувати доступ до даних, і, хоча іноді вони справляються непогано, все ж таки є певні обмеження.
Але що відбувається, коли вам потрібно більше, ніж просто простий запит? Для більшості команд, які працюють з сирими або неповними даними, досягти того моменту, коли інструменти, такі як BI-дашборди або текст у SQL, зможуть продемонструвати свої переваги, все ще вимагає значної маніпуляції з даними та моделювання.
Ця прогалина — між неохайними джерелами даних та корисними, здатними до дії інсайтами — є тим, що ми будемо називати презентаційним шаром вашого сховища даних. Це відшліфована, готова до бізнесу версія ваших даних.
Проблема полягає в тому, що більшість інструментів «спілкування з вашими даними» припускають, що цей шар вже існує. Те, що вони насправді пропонують, це «спілкування з вашими чистими даними». Але те, що нам справді потрібно, — це здатність спілкуватися з усіма даними — де б вони не були і в якому б вигляді вони не знаходились.
Давайте подивимося, як це виглядає на практиці:
Кейс:
Припустимо, ви PM, який будує SaaS для планування корпоративних подій. Ви щойно вийшли з наради з вашим CEO, на якій він зробив кілька спостережень:
- Здається, обсяг квитків на підтримку збільшився в кількох областях нашого продукту
- Це можуть бути точки тертя, які збільшують відтік клієнтів
- Нам потрібно поглянути на те, де ці запити на квитки зростають, як вони пов'язані з використанням функцій і як це може вплинути на важливі акаунти.
Це хороші сигнали від боса, але нам потрібно детальніше розглянути ці питання. Давайте поглянемо на дані, які доступні нам. Наскільки це легко залежатиме від стану наших даних, давайте розглянемо чотири різні сценарії.
Рівень 1: Обіцяна Земля
Ласкаво просимо до даних Нірвани. Ваша команда з даних виконала основну роботу: чисті з’єднання, чітко визначені метрики та ідеальний презентаційний шар роблять ваше життя легким. Вони змогли зібрати точну таблицю, яку вам потрібно, де чітко вказано ваші акаунти, які функції вони використовують та кількість квитків на підтримку по кожній функції.
Зручно!
У цьому світі ми можемо додати одну допоміжну колонку, щоб обчислити кількість квитків на функцію, таким чином ми знатимемо, які функції використовуються найчастіше, але при цьому потребують найбільше підтримки. Тут, з відносно чистими даними, інструмент тексту в SQL сяє, без проблем генеруючи нижченаведене.
SELECT
feature_name,
SUM(num_tickets) AS total_tickets,
SUM(usage) AS total_usage,
CASE
WHEN SUM(usage) > 0 THEN CAST(SUM(num_tickets) AS FLOAT) / SUM(usage)
ELSE NULL
END AS tickets_per_usage
FROM
projection
GROUP BY
feature_name
ORDER BY
tickets_per_usage DESC;
Якщо у вас є ця таблиця, ви отримаєте відповідь дуже легко! Якщо ви ще не виконували цей запит, нам доведеться зробити трохи більше роботи.
Ми точно повинні подивитися на планування заходів у різних відділах
Рівень 2: Не погано, але...
Все не ідеально, але цілком керовано.
Ваша команда доклала зусиль, щоб помістити дані в сховище та здійснити базові трансформації, тож ви не починаєте з нуля. Однак, з’єднання (joins) не є бездоганними, а ваша бізнес-логіка не завжди чітко визначена. Спільні ключі, такі як account_id, можуть не збігатися в усіх таблицях, які вам потрібні.
Погляд на це займе хвилину…
Отже, спершу давайте визначимо відповідні таблиці та створимо правильні з’єднання (joins):
- Квитки підтримки для проблем за акаунтом і функцією
- Продуктові події для метрик використання функцій
- Таблиця акаунтів для зв'язку всього разом
Давайте напишемо запит для з’єднання цих даних. Ми можемо спробувати використовувати інструмент тексту в SQL, але ймовірно, нам знадобиться трохи переконання, щоб вибрати правильні стовпці та визначити правильні з’єднання. Сподіваємось, ми знайдемо щось на зразок цього.
WITH
-- Підтаблиця для обчислення використання
usage_table AS (
SELECT
a.account_name,
product_events.feature_name,
COUNT(product_events.user_id) AS usage
FROM
product_events
JOIN
analytics_to_support_user_mapping ON product_events.user_id = analytics_to_support_user_mapping.user_id
JOIN
customers c ON analytics_to_support_user_mapping.customer_id = c.customer_id
JOIN
accounts a ON c.account_id = a.account_id
GROUP BY
a.account_name, product_events.feature_name
),
-- Підтаблиця для обчислення кількості квитків
tickets_table AS (
SELECT
a.account_name,
st.feature_name,
COUNT(st.ticket_id) AS num_tickets
FROM
support_tickets st
JOIN
customers c ON st.customer_id = c.customer_id
JOIN
accounts a ON c.account_id = a.account_id
GROUP BY
a.account_name, st.feature_name
)
-- Об'єднуємо підтаблиці використання та квитків
SELECT
u.account_name,
u.feature_name,
u.usage,
t.num_tickets
FROM
usage_table u
LEFT JOIN
tickets_table t
ON
u.account_name = t.account_name AND u.feature_name = t.feature_name
UNION ALL
SELECT
t.account_name,
t.feature_name,
NULL AS usage,
t.num_tickets
FROM
tickets_table t
LEFT JOIN
usage_table u
ON
t.account_name = u.account_name AND t.feature_name = u.feature_name
WHERE
u.feature_name IS NULL
ORDER BY
account_name, feature_name;
Цей запит дещо складніший, але він дає чисту таблицю з Рівня 1, яку ми можемо легко запитувати і знаходити необхідні відповіді. Все ж, ця ситуація припускає, що наші дані були достатньо чистими для того, щоб знайти спільні ключі і написати чисті з’єднання.
Рівень 3: Боротьба реальна
Тут ви працюєте з сирими даними джерела з різних систем — аналітика продуктів, CRM та системи квитків підтримки. Хоча ви зробили базові кроки, такі як консолідація даних в сховище та вирішення кількох очевидних проблем, дані далеко не готові до аналітики. Перетворення цих неохайних, ізольованих даних у придатний для використання стан вимагає багато роботи, співпраці та технічної експертизи.
Ми не будемо проходити через кожен етап, оскільки вони можуть варіюватися залежно від того, звідки надходять ваші дані, але виділимо кілька постійних викликів.
По-перше, дані приходять у різних форматах, наприклад:
- Продуктова аналітика: Події у форматі JSON з полями, такими як userid, eventname і timestamp.
- CRM: Експорти CSV з акаунтами, користувачами та метаданими клієнтів.
- Квитки підтримки: Напівструктуровані дані, часто з вільними текстовими полями для описів квитків.
Далі нам потрібно буде очистити та стандартизувати дані між системами:
- Дедуплікація записів: Видалення дублікатів рядків у CRM та журналах подій.
- Стандартизація стовпців: Перейменування полів, які не збігаються, таких як acctid vs.
accountid.
Ми можемо почати агрегувати дані в значущі метрики:
- Створення таблиць довідників: Вручну відображати зв’язки між user_id і акаунтами, коли немає прямих посилань.
- Використання: Групувати дані аналітики продуктів за accountid і featurename для обчислення загальних показників використання.
- Квитки: Підраховувати кількість квитків підтримки за accountid і featurename для відстеження проблем.
Це все ще відносно обмежений список, але він дає уявлення про деякі кроки, необхідні для приведення ваших даних у форму, достатню для того, щоб почати знаходити потрібні інсайти. На жаль, текст у SQL не зможе допомогти з багатьма з цих задач.
Чи обов'язково так?
По суті, проблема демократизації даних зводиться до двох простих ідей:
- Зібрати дані разом, незалежно від того, в якому стані вони перебувають
- Надати кожному можливість знаходити відповіді на основі цих даних як джерела правди
Незалежно від того, чи працюєте ви з чистими даними, готовими до аналітики, чи з сирими, неохайними вихідними файлами, мета повинна полягати в тому, щоб надати командам доступ до даних і можливість їх використовувати без нескінченної попередньої обробки.
Залучаючи різницю між сирими даними та дієвими інсайтами, компанії можуть справжнім чином демократизувати дані та зробити їх інструментом для кожного — не лише для тих, хто має час і навички, щоб боротися з ними. Ми працюємо над проектом Astrobee, щоб зробити цю візію можливим, шляхом:
- Розбиття конвеєра даних на керовані частини
- Автоматизації кожної частини за допомогою AI агентів
- Надання вашим експертам можливості додавати нюансований контекст на кожному етапі, забезпечуючи спільне та точне джерело правди
Якщо це вам цікаво, ми будемо раді поспілкуватися.
Перекладено з: How much SQL can your Text-to-SQL SQL?