Data Lineage Vocabulary: Як говорити про походження даних і аналіз впливу

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

Поняття лінії

** Походження даних ** — це можливість відстежувати дані від їх походження через кожне перетворення і пересування до кінцевого призначення. Він відповідає на питання: “Як це число опинилося на цій панелі?”

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

** Графік лінії ** є візуальним представленням цих зв’ язків. У ній показано вузли (набори даних, таблиці, завдання) і межі (потоки даних між ними). Ви почуєте: * « Витягнути графік послідовності для таблиці замовлень — я хочу побачити повний ланцюг залежностей перед запуском перенесення. » *

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

Процес управління та управління даними

** Походження даних ** — це ширша концепція запису повної історії частини даних — де вони були створені, хто їх змінив, коли і як. У той час як лінія фокусується на потоці, походження фокусується на підзвітності і аудиторії.

** Каталог даних ** — це система, яка зберігає і виводить метадані щодо ваших даних — схеми, прикладних даних, власника і попередника. Такі інструменти, як DataHub, Atlan, OpenMetadata і Alation, є поширеними в індустрії. ** Словник даних ** визначає значення кожного поля у наборі даних. ** Бізнес- глосарій ** відображає бізнес- терміни (наприклад, « активний клієнт ») до їх технічних визначень.

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

Аналітичний аналіз і зміна цін

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

** Зміна, що перериває роботу ** це будь- яка модифікація схеми набору даних або семантики, яка призведе до того, що нижні користувачі не зможуть виконати завдання або отримають неправильні результати. Серед прикладів, які часто використовуються, можна назвати перейменування стовпчика, зміну типу даних або вилучення поля. Інструменти, такі як Monte Carlo і Great Expectations, можуть виявити їх автоматично.

У контексті GDPR, послідовність даних є необхідною для реалізації ** права на вилучення ** (право бути забутим). Коли користувач надсилає запит на вилучення, вам слід відстежити всі системи, які зберігають або отримують дані з його записів. Без родослов’я, стерти - це догадка.

Фрази в лінії дискусій

• “У нас немає послідовності на рівні стовпчиків у цій частині сховища — це всі недокументовані перетворення SQL.”
• • “У каталогу це поле показано як застаріле, але три активні моделі все ще посилаються на нього.” *
• • “Ми повинні автоматично перенести метадані про попередників з моделей dbt до DataHub.” *
• • “Чи можете ви додати запис у діловий словник для « перетворення »? Маркетинг і інженерія використовують різні визначення.”*

Practice

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

Поняття мови: поняття, поняття і поняття

Будьмо чесними – технічний жаргон може бути справді дивним, коли ви вивчаєте нову мову. Такі терміни, як «лінія даних» або «аналіз впливу» не завжди перекладаються безпосередньо, і навіть якщо вони це роблять, спосіб, в який рідні носії англійської мови використовують їх, може звучати зовсім по-іншому, ніж те, як ви можете виразити ту ж саму ідею своєю першою мовою. Це не про те, щоб бути неправим; це про розуміння контексту і вивчення тонких відмінностей у фразуваннях, які демонструють глибший рівень технічного спілкування.

Однією з поширених областей, де виникає плутанина, є опис змін потоків даних. Уявіть, що ви переглядаєте запит на витягування, надісланий колегою, назовемо його Alex, який змінив скрипт SQL, який оновлює адреси клієнтів. У описі PR, Алекс пише: «Ця зміна покращує перевірку адреси і забезпечує відповідність з GDPR регламентами». Хоча технічно точна, їй бракує специфічності. Природніша фраза для рідного мовця буде щось на зразок: «Оновлення процесу оновлення адреси для включення суворіших правил перевірки на основі останніх рекомендацій GDPR. Це зменшує потенційний вплив на панелі управління, які покладаються на ці дані. Зауважте, як додавання фраз на зразок « вплив на нижні рівні » і « зменшує » негайно підвищує комунікацію від простого опису зміни до оцінки її наслідків.

Інша часта ситуація виникає в розмовах Slack про вирішення проблем з даними. Припустимо, хтось повідомляє: « У звіті про продажі показано неправильні цифри! » Людина, для якої мова не є рідною, може просто вказати на проблему безпосередньо. Однак, досвідчені колеги, ймовірно, відповіли б щось на зразок: «Чи можете ви відстежити походження впливу елемента даних назад до його джерела? Нам потрібно зрозуміти, де почалася невідповідність - можливо, крок трансформації або обчислення вгору по течії. “Використання “слідкувати за лінією” є дуже поширеним ідіомом в цій області, і розуміння того, що це не просто про * знайти * дані, але про * зрозуміти його подорож * є ключовим.

Нарешті, пам’ ятайте, що точність є ключовим моментом при обговоренні метаданих і впливу змін на системи. Не достатньо сказати « Я оновив метадані ». Замість цього вам слід пояснити, * що * було оновлено, * чому * і * як * ця зміна може вплинути на інші інструменти або процеси. Наприклад, якщо до DataHub додано нове поле, що представляє стан згоди клієнта, опис його як просто «додано поле згоди» не обрізає його. Ефективнішим твердженням було б: «Додано атрибут customer_consent_status до сутності «Клієнт» в DataHub, пов’язуючи його з процесом відповідності GDPR і запускаючи автоматизовані попередження про зміни даних, що впливають на правила конфіденційності»

Ось приклад того, як ви можете використовувати atlan query для дослідження проблеми з попередником:

atlan query --entity Customer --fields "lineage.source" --limit 10

Ця команда отримує інформацію про похідність, зокрема показує джерело( ла) всіх об’ єктів Customer, обмежуючи вивід до 10 найкращих результатів. Це практичний спосіб для того, щоб почати візуалізацію і розуміння того, звідки у вашій системі походять дані, що безпосередньо пов’ язано з обговореннями щодо походження і аналізу впливу.