Лінія даних та управління: Відстеження номера дашборду до його джерела

Питання про походження існує для відповіді

Керівник дивиться на дашборд доходів і запитує, чому цього кварталу число виглядає на 8% вищим за підтверджені фінансовою командою дані. Щоб добре відповісти на це питання, потрібно вміти відстежувати походження числа дашборда назад через кожну трансформацію, що його створила: які базові таблиці були використані, які з’єднання та фільтри, а також агрегації застосовувалися на кожному етапі, який конкретний запуск конвеєра згенерував поточну відображену версію та на якому етапі цієї ланцюжка було введено розбіжність з фінансовими даними. Походження даних – це дисципліна та інструменти для відповіді саме на це питання – записуючи, за можливості автоматично, повну залежність від графіку від необробленого надходження через кожну проміжну трансформацію до всіх кінцевих споживачів, щоб будь-яке число в системі можна було відстежити як назад до своїх джерел, так і вперед до всього, що на нього покладається.

Без походження цього виду налагодження перетворюється на археологічну експедицію: хтось повинен вручну читати SQL скрипти, моделі dbt, роботи Spark та визначення дашбордів, перевіряючи назви таблиць і сподіваючись, що людина, яка написала конвеєр три роки тому, залишила коментарі, пояснюючи незвичайну умову з’єднання. У будь-якій організації розміром понад певний поріг, з десятками або сотнями конвеєрів, що живлять спільний сховище даних, цей ручний підхід просто не масштабується, і вартість проявляється в сесіях налагодження, які тривають дні замість хвилин, а також у ширшій організаційній проблемі: аналітики та керівники, які колись були обдурені незрозумілою розбіжністю, починають недовіряти цифрам в цілому, що є набагато складніше вирішити, ніж початкова помилка, оскільки відновлення довіри до платформи даних після втрати займає набагато більше часу, ніж інцидент, який її зруйнував.

Лінія даних на рівні таблиць проти лінія даних на рівні стовпців

Інструменти відстеження лінії даних працюють на двох окремих рівнях деталізації, і ця різниця має величезне значення для корисності отриманої графіка. Лінія даних на рівні таблиць записує, що таблиця B була створена з таблиці A, зазвичай випливає з аналізу SQL або визначень завдань, які матеріалізують кожну таблицю та витягують, з яких джерельних таблиць читаються запити. Це відносно легко побудувати (більшість сучасних інструментів каталогу даних, таких як DataHub, Amundsen або OpenLineage, можуть автоматично робити це, аналізуючи журнали SQL-запитів або метадані оркестровки), і добре відповідає на грубі запитання: "з чого залежить таблиця revenue_summary" або "що станеться, якщо я видалю цю таблицю staging".

Лінія даних на рівні стовпців відстежує більш детальний аргумент про те, що конкретний вихідний стовпець походить від конкретного набору вхідних стовпців через конкретне перетворення — наприклад, revenue_summary.total_revenue дорівнює сумі orders.amount після об'єднання з валютною ставкою fx_rates.rate, фільтрованого за orders.status = 'completed'. Це значно складніше автоматично витягувати, оскільки потрібно фактично аналізувати та семантично розуміти логіку перетворення (SQL SELECT з десятками об'єднань і CASE-висловлюваннями або будь-яке Python-перетворення в роботі Spark), а не просто записувати, які таблиці були посилання, і стає справді складним, коли перетворення проходить через код, відмінний від SQL, зовнішні API або прозору бізнес-логіку, вбудовану в код програми, а не декларативні визначення конвеєрів. Оплата за додаткові зусилля велика: лінія даних на рівні стовпців дозволяє дійсно відповісти на питання "яке конкретнеupstream поле спричинило цю конкретну downstream цифру", а не просто звузити пошук до "десь в цих одинадцять таблиць", що часто все ще занадто широке, щоб бути корисним у справжній ситуації під тиском часу"]} self.paragraphs} self.heading}

Автоматичне захоплення інформації проти ручного документування

Системи ліній розгортання отримують інформацію двома способами, і різниця в надійності між ними є найважливішим фактором того, чи залишається система ліній розгортання достовірною з часом. Ручне документування ліній розгортання — це сторінка вікі або електронна таблиця, де інженери записують, що живить щось, — погіршується в момент зміни основних конвеєрів і ніхто не пам’ятає (або не турбується) оновити документацію, що відбувається напрочути регулярно, тому ручне документування ліній розгортання в більшості організацій надійно застаріває протягом місяців після написання, що унеможливлює весь сенс її існування. Автоматичне захоплення ліній розгортання замість цього виводить графік залежностей безпосередньо з систем, які фактично запускають конвеєри: аналіз записів SQL-запитів з сховища, підключення до інструментів оркестрування, таких як Airflow або dbt, для запису залежностей завдань при виконанні конвеєрів і використання стандартизованих відкритих протоколів, таких як OpenLineage, для випромінювання подій ліній розгортання безпосередньо з обчислювальних двигунів (Spark, Flink, dbt) під час виконання завдань, щоб графік ліній розгортання був побічним продуктом виробничого виконання, а не окремим артефактом, який може відхилитися від синхронізації. Цей автоматизований підхід є набагато більш надійним, оскільки він не може застаріти так, як це робить ручне документування — якщо конвеєр змінюється, наступне виконання автоматично випромінює оновлені дані ліній розгортання, хоча для інструментації кожного етапу неоднорідного конвеєра все одно потрібен справжній інженерний вкладений вклад (Python-скрипт, який виконує одноразову трансформацію поза стандартним фреймворком оркестрування, невидимий для автоматичного захоплення ліній розгортання, якщо хтось навмисно інструментує його), що пояснює, чому більшість великих організацій запускають суміш: сильне автоматизоване покриття для трансформацій у стилі сховища (SQL, dbt) і менший набір вручну документованих крайніх випадків для спадкових або спеціальних конвеєрів, які виходять за межі стандартного інструменту.

Чому регулятори та аудитори піклуються про походження даних саме

Крім внутрішнього налагодження, походження даних стало конкретним вимогою в кількох основних нормативних рамках, оскільки твердження «ми створили це число» недостатньо для регулятора; «ми можемо довести, з якого джерела було створено це число та що процес є повторюваним і належним чином затвердженим», – це те, що вимагає відповідність. Принципи BCBS 239 ради з управління ризиками, які застосовуються до системно важливих банків, чітко вимагають від установ мати можливість відстежувати фігури ризиків до їх джерел даних та демонструвати точність процесу агрегації, що неможливо забезпечити без справжнього, аудитованого походження, а не лише пам’яті установи. Право на видалення персональних даних GDPR створює пов’язану, але відмінну потребу в походженні: коли суб'єкт даних вимагає видалення, організація повинна знати всі таблиці, моделі та похідні набори даних, які використовували їх особисті дані, а не лише оригінальний запис – це саме перевірка походження вперед (від джерела до всього, що залежить від нього), а не перевірка походження назад для налагодження номера дашборду.

Двостороння ця концепція варта чіткого пояснення, оскільки ці дві сфери справді потребують різних проходжень через одну й ту ж схему: налагодження – це запити в обернене положення (враховуючи цей вихід, що його живило), а вимоги відповідності, такі як видалення GDPR або аналіз впливу перед зміною схеми («якщо я видалю цю колонку, що зламається вниз»), – це запити в пряме положення (враховуючи цей джерельний запис, що залежить від нього). Система походження даних, яка підтримує лише одну сторону добре, вирішує лише половину проблеми, тому що це є несумірним елементом нормативних та управлінських інфраструктур у галузях з великою кількістю даних та регулювання.

Часті запитання

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте the simulation і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.