Спільно написаний разом з Benedetta Cittadin
Протягом останнього десятиліття прийняття рішень на основі даних довели свою важливість для зростання будь-якої сучасної організації. У результаті, сучасні середовища обробки даних постійно еволюціонують і стають все більш складними. Цей приріст складності Сучасного Стеку Даних (Modern Data Stack) відповідає за збільшення непередбачуваності і ризику порушення роботи конвеєра даних (data pipelines). Ідея “сміття надходить, сміття й вийде (garbage in, garbage out)” все ще відноситься до сучасних середовищ даних, але оскільки проблеми з даними можуть виникати на будь-якому етапі конвеєра, ця концепція вже не є достатньою для ефективного вирішення питань якості даних. Проблеми з даними можуть виникати на будь-якому етапі, від включення через зберігання і обробку до BI-інструментів. Це може уповільнювати процес перетворення даних на дієві заключення(insights) і збільшувати витрати, що вимушає організації робити компроміси зі своїми даними. Зроблені компроміси з якістю даних і управління даними, однак, небезпечні для організацій з багатьох причин:
- Доступність даних вирішальна, і хоча стріми даних у реальному часі стають все популярнішими, документація ускладнена.
- Оскільки дані стають більш доступними, кількість джерел даних, від яких підприємство залежить, експоненційно зростає. Це може ускладнювати обробку даних і піддавати ризику якість даних, особливо коли джерела є зовнішніми.
- Із зростанням стеку даних зростає і Сучасна Команда Даних (Modern Data Team). Це створює великий шанс і виклик для вирішення, оскільки більше людей, які працюють з даними, означає більше ризику змін в даних, які можуть знизити якість даних. Ініціативи демократизації даних ймовірно зазнають невдачі без належного управління даними.
Загалом, більше даних означає кращі можливості для розуміння та виділення вашого бізнесу. Але більше даних також означає більше ризиків в даних і, отже, зниження якості даних, погане прийняття бізнес-рішень і, відповідно, зниження довіри до даних. На щастя, протягом останніх кількох років з’явився новий підхід до роботи з якістю даних, довірою та надійністю: спостереження за даними.
Мета цього блогу – представити концепцію Спостереження за даними(Data Observability) та роз’яснити, чому організаціям потрібно інтегрувати засіб Повного Спостереження за Стеком Даних(Full Data Stack Observability) у свій стек даних. Ми це зробимо, відповідаючи на наступні питання:
- Що таке спостереження за даними?
- Спостереження за даними проти тестування і моніторингу якості даних – в чому різниця?
- Повне спостереження за стеком даних – що це означає?
- Які найефективніші застосунки для спостереження за стеком даних?
1.Що таке спостереження за даними?
Початково термін “спостережливість” був позичений з теорії керування, а потім він розповсюдився в інженерію програмного забезпечення перед тим, як стати популярним в сфері обробки даних. Перші засоби спостереження за програмним забезпеченням виникли на основі фундаменту, закладеного хмарними службами, такими як AWS. Засоби спостереження за програмним забезпеченням, такі як Datadog і New Relic, надали інженерним командам змогу збирати метрики з усіх їхніх систем, щоб надати повне розуміння стану здоров’я цих систем. Основна ідея за спостереженням за програмним забезпеченням дуже проста: оскільки хмара дозволяє розміщувати все більше і більше компонентів інфраструктури – таких як бази даних, сервери та API-endpoints – важливо ретельно моніторити цю складну інфраструктуру, щоб знати, коли щось піде не так. Сьогодні інженери програмного забезпечення не можуть уявити, як би було без централізованого виду на всі їхні системи. Засоби спостереження за програмним забезпеченням кардинально змінили світ програмного забезпечення, визначивши важливість видимості на всі системи в центрі уваги.
Зараз галузь обробки даних проходить через той самий революційний процес. Як було зазначено в огляді, набір інструментів, які використовують команди для обробки даних, росте і стає все більш складним, що збільшує можливість руйнування даних і ускладнює отримання розуміння в різніих частинах конвеєра обробки даних. Ці проблеми стали загальними в організаціях, і користувачі даних не задоволені якістю даних.
У кінці кінців, нова категорія спостереження за даними спрямована на вирішення наступних проблем: моніторинг даних для швидкої оцінки можливих проблем, щоб надавати командам контекст для їх швидкого вирішення. Спостережність за даними, отже, можна визначити як здатність організацій отримувати дієві підказки стосовно стану їх даних.
Незважаючи на те, що спостережність за даними походить від спостерігання за програмним забезпеченням, існують деякі значущі відмінності, на які варто звернути увагу. Спостерігання за програмним забезпеченням ґрунтується на трьох стовпцях: Метрики, Траси та Логи (Metrics, Traces and Logs).
Ці стовпці, однак, не відповідають повністю важливим аспектам, які становлять робочий процес інженерії даних. Нам потрібна нова рамка, щоб зафіксувати всі складності Даних і Дата-інфраструктури, і ми пропонуємо наступне:
- Метрики (Metrics): вимірюють якість даних.
- Метадані (Metadata): надають доступ до інформації про дані.
- Лінійність (Lineage): відомі залежності між активами даних.
Про ці три стовпці буде розглянуто більше докладніше пізніше в цьому блозі.
2.Data observability проти тестування та моніторингу якості даних — Яка різниця?
Інженери даних часто використовують тести для виявлення та запобігання можливим проблемам з якістю даних. Цей підхід працював непогано, поки компанії не стали споживати настільки багато даних, що тестування вже не вистачало. Тестування стало неефективним, оскільки проблеми з якістю даних стали важчими для виявлення та передбачення. Незважаючи на те, що команди мають сотні тестів для виявлення передбачуваних проблем з даними, вони ще не охопили всі безкінечні можливості руйнування даних протягом всього конвеєра або не мають контексту для розуміння проблем з даними і навчання з них, залишаючи себе в постійному режимі гасіння пожежі. З іншого боку, спостережність масштабна, надає охоплення з кінця в кінець і забезпечує необхідний контекст (завдяки походженню), щоб запобігати катастрофам з даними та бути активними щодо DQ.
Спостережність за даними та моніторинг якості даних часто використовують як взаємозамінні поняття, але це дві різні речі. Або, краще кажучи, одне допомагає іншому. Спостережність за даними дозволяє моніторинг якості даних. Моніторинг якості даних сповіщає користувачів, коли дані або набори даних не відповідають заздалегідь встановленим метрикам або параметрам. Цей процес створює такі ж обмеження, як і тестування. Незважаючи на те, що ви можете отримати певну видимість стосовно статусу якості ваших активів та атрибутів даних при моніторингу якості даних, ви не знаєте, як швидко усунути можливі проблеми.
Отже, ні тестування, ні традиційний моніторинг якості даних не можуть самостійно впоратися з викликами Сучасного Дата Стеку. Саме тут входить спостережність за даними.
Спостережність за даними постійно збирає сигнали по всьому дата-стеку – логи, завдання, набори даних, конвеєри, BI-звіти, моделі наук про дані (data science models) і т. д., – забезпечуючи моніторинг та виявлення аномалій на масштабі. Іншими словами, спостерігання за даними діє як наглядовий шар для дата-стеку, забезпечуючи надійність та відстежуваність даних на кожному етапі конвеєра та незалежно від точки обробки, де вони розташовані.
3.Повна спостережність за дата-стеком — що це означає?
Систему спостереження за дата-стеком слід розглядати як наглядовий шар, що робить ваш сучасний дата-стек більш продуктивним і забезпечує надійність даних незалежно від їх місця розташування. Ми створили Sifflet — першу повну платформу спостереження за дата-стеком — щоб дозволити організаціям автоматизовану надійність даних на кожному етапі потоку даних.
У підході повної спостережності за дата-стеком кожен компонент сучасного дата-стеку розглядається як відділення, яке служить своєму призначенню в подорожі даними. Відділення мають логіку функціонування та вивільнюють інформацію, яку можна використовувати для розуміння та спостереження метаданих, самих даних, лінійності та результатів даних (метрики, графіки, інформаційні панелі тощо). У цьому контексті розгалужена лінійність між активами даних та об’єктами на всій структурі дата-стеку є основою каркасу повної спостережності за дата-стеком.
Джерело:Salma Bakouk, Sifflet
4.Які найпотужніші застосування повного спостереження стеку даних?
Додамо дещо контексту до цього визначення, розглянемо деякі з найважливіших випадків використання для повного спостереження стеку даних.
Виявлення аномалій: як на рівні метаданих, так і на рівні даних. Ідея полягає в тому, щоб ввести набір метрик, які можуть допомогти визначити стан здоров’я платформи для даних. Деякі стандартні метрики, які не залежать від галузі бізнесу, включають:
- Свіжість / Своєчасність (Метрика даних) (Freshness / Timeliness (Data metric)): чи є дані актуальними?
- Повнота / Обсяг (Метадані) (Completeness / Volume (Metadata metric)): чи є відсутні значення? Відсутні рядки? Відсутні записи даних? Неповні конвеєри?
- Дублювання (Метрика даних) (Duplication (Data metric)): чи є дублікати?
- Схема (Метадані) (Schema (Metadata metric)): чи змінилася структура даних? Чи змінився підтримуючий SQL-запит і викликав збої конвеєрів? Або призвів до застаріння інформації на інформаційних панелях?
- Точність (Метрика даних) (Accuracy (Data metric)), наприклад, чи відповідають дані певному діапазону? В певному форматі? Та інше.
Походження (Lineage): походження представляє собою залежності між ресурсами даних в організації. При зростанні обсягів даних і ускладненні платформ обробки даних важко відстежувати, як один ресурс пов’язаний з іншим. Але чому взагалі важливо відстежувати залежності? Розглянемо кілька сценаріїв, з якими щоденно стикається фахівець з обробки даних в середній за рівнем дозрілості організації:
- По-перше, доступ до наступних залежностей є критичним для ламання “silos” між відділами в організаціях. Представте собі компанію з командою з розробки програмного забезпечення та командою з обробки даних, які мало спілкуються одна з одною. Перші можуть навіть не знати, як вплинути на команду обробки даних випуск змін. Цей бар’єр між командами можна подолати завдяки походженню даних, іншими словами, завдяки доступу до наступних залежностей щодо дій команди за межами обсягу її діяльності.
- По-друге, походження дозволяє командам дізнатися кореневу причину проблеми з даними і вирішити її негайно. Уявіть собі організацію, яка має проблеми з веденням записів і документацією через швидкий ріст протягом останніх кількох років. Якщо показник на інформаційному табло не має сенсу, бізнес-лідери негайно вимагатимуть від команди обробки даних знайти кореневу причину. Те, що ці бізнес-лідери іноді не мають розуміня, полягає в тому, що для ручного визначення кореневої причини проблеми з даними може знадобитися години, якщо не дні. Саме тут вступає в гру походження даних. Доступ до попередніх залежностей дозволяє командам з обробки даних ідентифікувати та усунути проблему з даними, перш ніж вона перетвориться в бізнес-проблему.
Наступні сценарії використання тісно пов’язані з двома попередніми в тому сенсі, що вони є результатом комбінації двох вищезазначених. Іншими словами, скажімо, ви впровадили модель виявлення аномалій, яка також може споживати та генерувати інформацію про походження. Ви отримуєте сповіщення, що щось зламалося; що робити?
Управління інцидентами: Я б сказав, що перше, що ви хочете зробити, це оцінити вплив такої аномалії. Які це має наслідки для споживачів даних? Які її потенційні наслідки? До яких табло, графіків або моделей машинного навчання вона живиться? Кого ще слід сповістити? Розгалужене походження з деталями стовбців допомагає відповісти на ці питання. Подумайте, що міг зробити Браян, щоб уникнути кризи.
Аналіз кореневої причини: Інженерам даних, потрібно дізнатися суть проблеми, оскільки відповідні учасники вже знають, як їх робочі процеси постраждали. Гідна модель походження(lineage) покаже вам залежності вгору (ліворуч від сховища), щоб ви краще зрозуміли, звідки виникла проблема. Велика модель походження (lineage) також буде посилатися на програми, завдання та оркестратори, що призводять до аномального активу. Якби у Якоба та його команди була можливість швидко зрозуміти причину проблеми та виправити цифри до прес-конференції генерального директора.
Post-Mortem: Що сталося і як ми можемо навчитися з цього? Подумайте про інцидент з даними, як про пожежу, яка може швидко поширюватися і мати як матеріальні, так і нематеріальні наслідки. Коли ви впроваджуєте тестування та базовий моніторинг якості даних, ви опиняєтеся в режимі боротьби з пожежею, але коли ви приймаєте підхід повного спостереження за стеком даних, ви можете навчитися визначати пожежні небезпеки, як зупиняти випадкові пожежі, зменшувати можливі наслідки і переходити від боротьби з пожежею до її запобігання. Проведення цілеспрямованого аналізу післямортему є ключовим для досягнення сталої якості даних.
Висновок — Від боротьби з пожежею до її запобігання.
Складність платформи для обробки даних вже не є виправданням для поганої якості даних. Будь-який сучасний лідер повинен приймати цю зростаючу складність, оскільки це означає, що бізнес розвивається і є більше даних для використання. Однак будь-яка велика цінність, яку можна видобути з даних, знищується без належного програмного забезпечення та процесів.
Повние спостереження(observability) на стек даних – це наглядовий шар в стеці даних та забезпечує надійність даних на кожному етапі підприємницького конвеєра даних. Незважаючи на те, що структури Дати спостереження багато навчилися у сфері програмного забезпечення і APM, деякі фундаментальні відмінності вимагали визначальних для галузі структур і практик протягом останніх кількох років. Повний погляд на стек даних використовує комбінацію метрик, інгестії для лінійного від входу до бізнес-інтелекту, а також метаданих для надання інженерам даних та споживачам даних дієвих інформаційних відомостей для моніторингу та зменшення впливу подій і активного збільшення надійності даних.
Попередження: Я є співзасновником та генеральним директором компанії Sifflet, платформи повного погляду на стек даних https://www.siffletdata.com/
ОРИГІНАЛ СТАТТІ:Data Quality Monitoring is dead. Say Hello to Full Data Stack Observability
АВТОР СТАТІ:Salma Bakouk
Долучайтесь до нашої спільноти Telegram
* Data Life UA
* Data Analysis UA
* DATA ENGINEERING UA
Долучайтесь до нашої спільноти FaceBook
* Data-Life-UA