Здавалося б, як можна через таку фанову тему, як меми, розповідати про серйозні речі на кшталт Data Analysis та Business Intelligence? Насправді складні поняття та процеси тут доволі просто пояснюються мемами. Зрозумілий усім формат жартів допомагає розібратися в багатьох нюансах Data-аналізу. Як саме — дізнаємось із лекції про Data Analysis, яка відбулась у межах IT-конференції NIX Multiconf.
Цей матеріал буде корисний для тих, хто хоче спробувати себе в якості аналітика. Спеціалісти, які вже мають практичний досвід, можуть поглянути на добре відому тему під незвичним кутом.
Зміст
1. Що таке big data
2. Як виглядає робота в Data-проєкті
3. Каталоги даних — в чому їхня користь для Data-аналітиків?
3.1 Легкий пошук
3.2 Генерування каталогами даних Connection Strings
3.3 Для кожного ресурсу даних є багато корисної інформації
3.4 Глосарій
4. Що важливо знати про дашборди
5. Робіть інтерактивні дашборди
6. Навчайте користувачів працювати з BI-інструментами
7. Як покращити командну роботу над дашбордом
8. Інструменти BI для Data-аналітика
9. Що ж робити, коли ваш інструмент BI не дозволяє досягти бажаного результату?
Існує багато концепцій, через які пояснюють цей термін. Експерти NIX віддають перевагу схемі 8V:
Схема 8V
На практиці найважливішими є обсяг, швидкість та різноманітність даних. Інші ж характеристики трохи подібні між собою і просто вносять більше деталей.
Коли ви чуєте про аналітика даних, насамперед очікуєте, що будете працювати з big data. В реальності ви можете отримати декілька великих файлів Excel, які потрібно об’єднати та використовувати як джерело даних. Однак операції можуть бути значно складнішими. Наприклад, включати чистку даних і встановлення зв’язків між файлами.
«Я працюватиму з бігдатою» — І тут тобі дають чотири ексельки як джерело даних — «Прийнятно»
Цікава яка тенденція. Пандемія COVID-19 викликала історичні зміни в роботі з big data, через що дані можуть дуже швидко старіти. Це порушує багато виробничих алгоритмів і моделей штучного інтелекту та машинного навчання. Як прогнозують у дослідженні Gartner, до 2025 року 70% світових компаній змінять фокус із великих даних на малі та широкі. Саме вони зменшують залежність компаній від big data.
Для того, щоб не виникла плутанина в поняттях, одразу визначимося зі значенням абревіатур DBA та BDA.
DBA (Database administrator) використовується для визначення ролі адміністратора бази даних. BDA (Big Data Analytics) стосується аналітики бізнес-даних.
Аналітика бізнес-даних — це набір методів, технік і практик, які застосовуються для безперервного вивчення, повторення та дослідження попередніх і поточних даних про бізнес. Ця інформація дозволяє зрозуміти, які дані та дії над ними можуть поліпшити процес ухвалення рішень.
Схожі абревіатури, але різні значення
Процес аналізу бізнес-даних включає шість етапів:
1) Визначити дослідницькі питання.
2) Знайти вихідні дані — так ми можемо отримати відповіді на первинні питання.
3) Власне аналіз даних, під час якого може з’явитися ще більше запитань. Можливо, ви повернетеся до другого пункту та зміните перші питання.
4) Інтерпретувати отримані результати. В цьому пункті також можна повернутися до витоків першого етапу.
5) Використати отримані результати для прийняття зваженого бізнес-рішення.
6) Управління стратегією бізнес-знань на рівні системи — цей етап проходить червоною ниткою крізь увесь флоу.
Після отримання всієї важливої інформації варто дізнатися, чи є в проєкті документація та моделі даних, схеми даних чи хоча б щось із переліченого?
Інколи аналітики відчувають себе персонажем мему, наведеного нижче.
Щоразу при старті нового проєкту вони схрещують пальці і думають: «Може, цього разу пощастить, і проєкт матиме актуальну документацію або ж принаймні деяку».
На жаль, на практиці доводиться стикатися з недостатньо задокументованими проєктами.
На проєкті буде документація. «Ми робимо проєкт вже два роки» — «Тож ви маєте документацію, правда?» — …
Якщо ви працюєте над проєктом від самого початку, скажімо, рік, і вам знадобиться змінити певні бізнес-правила чи бізнес-логіку — ви можете не запам’ятати, чому в тому чи іншому місці були застосовані якісь правила. Коли це задокументовано, питань не виникне. В іншому випадку доведеться витратити час та сили на відновлення цієї інформації.
Розглянемо основні типи документації, з якими ви можете мати справу на Data-проєкті:
У таблиці наведено приклад словника даних. Його шаблони можуть відрізнятися, але основними стовпцями зазвичай є назва, визначення, тип даних. Іноді навіть сховища даних можуть створити такий шаблон. Якщо у вас різні джерела даних, то вони напевно не матимуть однакової структури. Тому краще зберігати їх в одному місці та надавати колегам єдиний формат структури. І вже існує інструмент, який допоможе вам у цьому — каталоги даних.
Каталоги об’єднують метадані про наявні big data і допомагають налаштувати процес управління даними в компанії. Найкрутіше в каталогах те, що вони можуть створити частину документації для вас.
На цих скріншотах ви можете побачити кілька екранів з каталогу даних Azure. Пояснимо детальніше його можливості.
У каталозі є ресурси даних, за допомогою яких можна шукати інформацію, використовувати розширений пошук чи деякі фільтри і додавати теги, щоб полегшити пошук. Для кожного джерела даних можна знайти вікно запиту доступу і розмістити там інформацію про всі кроки для отримання доступу до цього джерела.
Якщо організація велика, інколи отримання доступу може бути проблемою — і може нагадувати пошук чорного кота в темній кімнаті. Якщо ж тримати всю інформацію в одному місці, у вас буде зрозуміла покрокова інструкція:
Ще одна цікава функція — каталоги даних можуть генерувати Connection Strings. У випадку з Azure можна під’єднатися до джерела даних, наприклад, в Excel або Power BI. Каталоги не завантажують дані безпосередньо в Excel, але створюють це з’єднання. Після того, як ви додасте облікові дані, зможете отримати й доступ до самих даних.
Наприклад, профілі даних, основні характеристики полів тощо. Ми можемо попередньо переглянути дані, тому не потрібно встановлювати з’єднання з джерелом і виконувати запит. Просто шукаємо потрібні нам дані і бачимо, які є типи даних, стовпців, значень. А ще одна цікава річ — походження даних. Ви можете крок за кроком йти від початкового джерела, де отримуєте дані, до дашборду, який створюєте.
Окремо хочу сказати про глосарій. Як ми вже згадували, це важливий тип документації. В ньому ви можете зберігати всі свої терміни, затверджувати їх в адміністратора, додавати батьківські терміни для створення певної ієрархії. Також можете зв’язати їх із дата-об’єктами і побачити поля, в яких можна об’єднати таблиці між собою.
Як бачите, каталоги даних — це дійсно зручний інструмент для роботи.
Одна з цілей роботи зі стейкхолдерами — зробити їх щасливими. Проте іноді, незважаючи на всі зусилля, цього досягти не вдається.
Стейкхолдер завжди буде щасливий — Ти робиш все по макету клієнта — Стейкхолдер: «Як потворно»
Пояснимо на прикладі поширеної ситуації. До команди звертається стейкхолдер із чимось на кшталт наведеного нижче мокапу дашборду. Він хоче бачити тут дані для всіх продуктів одночасно. І для кожного з них — KPI, стовпчасті діаграми, кругові діаграми тощо. Можете самі переконатися, що це не найкраще рішення…
Мокап дашборду клієнта
Проблема полягає в тому, що горизонтальна протяжність дашборду доволі велика. В ньому зібрано занадто багато всього. Зазвичай аналітики одразу говорять про це стейкхолдеру. Однак часто клієнт наполягає реалізувати все саме за таким макетом. Після завершення розробки під час демонстрації дашборду скоріш за все замовник не буде задоволений побаченим і пояснить це приблизно так: «Я думав, що все буде не так горизонтально».
Що робити в такій ситуації:
Погляньте, як це може виглядати:
Варіант, який можна створити
Дашборди мають бути зрозумілими і корисними для клієнтів. А візуально гарні дашборди ще й виглядають цікавіше. Інтерактивність дозволить зробити роботу з даними більш ефективною. Яким чином?
Дашборди будуть корисними — «Користуєтеся дашбордами?» — «Нє, лишень дивимося» — «Гарнезно»
Перейдемо до втілення інтерактивності на прикладі одного дашборду. Спробуйте такі популярні функції:
Уявіть, що раніше ваші користувачі працювали лише з деякими таблицями Excel чи слайдами та діаграмами PowerPoint. Тепер вони почали використовувати інструмент BI, наприклад, Power BI або Tableau. На цьому етапі їм не потрібні всі можливі функції. По суті для своїх цілей їм було б добре мати лише цифру, яку ви отримали зі звітів.
«Модні тулзи з чартами» — «Цифра»
Спершу функції дашбордів можуть приголомшити користувача. Тому будьте готові витратити чимало часу, щоб пояснити їм усі можливості інструментів. Головною метою ваших QA-сесій має стати показ переваг цих тулзів. Ви повинні, так би мовити, «продати» їм цей інструмент BI.
Також можна створювати посібники на допомогу користувачам. Знайомлячи їх з інструментами BI-аналітики, ви підвищуєте продуктивність їхньої роботи. Безумовно, багато в чому тут залежить від мотивації людей. Однак готовність інвестувати в них свої час та знання має бути в політиці компанії.
Чимало аналітиків хочуть самостійно працювати над дашбордами, але на практиці ви частіше будете співпрацювати з кількома фахівцями. Щоб робота виконувалась ефективно і всі бути задоволенні процесом та спільним результатом, наведу кілька життєвих порад.
Я самостійно працюватиму над дашбордами — Я: «Мої дашборди» — Мій тіммейт: «Маєш на увазі “наші”»?
Перша рекомендація — визначте правила щодо назв для папок, заголовків дашбордів, обчислень тощо. Якщо провести паралель із деякими методами розробки програмного забезпечення, ми могли б організувати сервери Power BI або Tableau в онлайні з папками dev, test та production. Це допоможе якісно проводити перевірку та розгортати проєкт у правильному середовищі, а потім переконатися, що все в порядку. Це також допомагає ділитися знання, особливо якщо в команді є новачок. Завдяки чітким назвам усіх елементів кожен впевнено працюватиме з готовими дашбордами і новими даними.
Також можете спробувати й інші методи програмної інженерії:
Одразу скажу: ідеального повнофункціонального інструмента не існує. Інколи під час роботи з якоюсь маловідомою тулзою ви не можете навіть змінити кольори категорій. Хоча й добре відомі інструменти мають слабкі сторони.
Наприклад, в Tableau практично немає ETL. Для цього потрібно використовувати окрему програму Tableau Prep. Або ж Looker, один із найдорожчих інструментів BI. В ньому ви не можете змінити спливаючі підказки. Отже, різні інструменти BI служать для різних цілей. Їхній вибір залежить від конкретних задач та умов проєкту.
Ідеальний функціональний BI-інструмент (якого не існує) — Маловідома тулза, де ти не можеш навіть змінити кольори
Ще одне марне сподівання початківців: достатньо опанувати один інструмент, щоб стати профі. Однак у різних проєктах ви можете зіткнутися з різними тулзами для BI. Коли добре розбираєтесь у принципах їх роботи, то швидко опануєте будь-який новий інструмент. Переважно всі вони мають одну логіку — на основі SQL та функцій перетягування.
Помилки у тулзах завжди будуть зрозумілими — «Ну добре. Бережи свої секрети!»
Наостанок — ще один мем, щоб ви посміхнулись. Як ви називаєте цей інструмент BI? Досвідчені аналітики можуть згадати багато версій: Таблу, Таблю, Табля і врешті — Табло.
Посміхніться! 🙂
Пошуткували, а тепер завершимо на серйозній ноті. Ось ще кілька корисних порад від експертів NIX для роботи у Data-проєктах:
Резиденти Дія.City сплатили до бюджету понад 8 млрд грн податків в І кварталі 2025 року.…
У Китаї закликають офісних працівників не працювати надто багато — держава сподівається, що вільний час…
Експерти звертають увагу на тривожну тенденцію: люди все частіше використовують ChatGPT, щоб визначити місцезнаходження, зображене…
Компанія JetBrains випустила нову версію мультимовного середовища розробки IntelliJ IDEA 2025.1. Оновлена IDE отримала численні…
Платформа обміну миттєвими повідомленнями Discord впроваджує функцію перевірки віку за допомогою сканування обличчя. Зараз вона…
Wikipedia намагається захистити себе від тисяч різноманітних ботів-скрейперів, які сканують дані цієї платформи для навчання…