Як обговорювати якість даних англійською мовою

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

Ключовий словник

Рід даних Походження даних описує походження даних і подорож, яку вони здійснюють через конвеєр — кожне перетворення, з’ єднання і агрегування, яке вони проходять перед досягненням місця призначення. Зрозуміти походження допомагає інженерам відстежити джерело проблем з якістю.

• Приклад: « Ми відслідковували послідовність даних і виявили, що нульові значення у стовпчику доходів були введені умовою з’ єднання на кроці перетворення. » *

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

• Приклад: « На панелі показано дані, які мають 18- годинний термін дії — очікувана тривалість свіжості даних становила шість годин. Нам потрібно дослідити, чому трубопровід запізнюється.»*

Дрейф схеми Дрейф схеми відбувається, коли структура вхідного набору даних несподівано змінюється, наприклад, коли додається новий стовпчик, існуючий стовпчик перейменовується або змінюється тип даних. Дрейф схеми є поширеним джерелом помилок конвеєра.

• Приклад: « Конвейер зазнав невдачі сьогодні вранці через дрейф схеми — команда розробників додала потрібну колонку до таблиці подій без попередження нас. » *

Договор на передачу данных Договір з даними є формальною угодою між виробником даних і споживачем даних, яка визначає очікувану схему, семантику і гарантії якості набору даних. Контракти даних все частіше використовуються для запобігання дрейфу схем і проблем з якістю даних. Приклад: «Ми ввели контракти на дані для всіх наших критичних джерел — будь-які зміни в схемі повинні бути узгоджені перед розгортанням.»

Завершеність Повнота вимірює ступінь, у якій всі очікувані дані присутні. Набір даних вважається повним, якщо не вистачає жодного з необхідних записів або полів. Приклад: “Перевірка повноти позначила, що 3% записів не мають поля customer_email, яке необхідно для маркетингового сегмента.”

Поширені сценарії, де використовується ця мова

В обзоре инцидента качества данных: “Ми виявили проблему якості даних у наборі даних замовлень. Поле total_amount повертало від’ємні значення приблизно для 2% записів, що було викликано помилкою в логіці обчислення повернення, введеної в минулому тижневому випуску. ”

** Під час планування зустрічі для поліпшення якості даних: ** “Я пропоную впровадити автоматизовану перевірку якості даних на рівні поглинання. Ми повинні стежити за повнотою, дрейфом схеми і свіжістю всіх наших критичних наборів даних. Я можу встановити це в Великих очікуваннях до кінця спринту»

** При повідомленні зацікавленим сторонам про показники якості даних: ** “Минулого місяця, наш рейтинг якості даних по всіх моніторених наборах даних в середньому склав 97,3%. Основними областями, в яких ми впали нижче наших цілей, були свіжість набору даних про профілі клієнтів і повнота журналу транзакцій. “

Корисні фрази для обговорення якості даних

• «Ми виявили аномалію якості даних у продажах — рекордний показник на 40% нижчий, ніж вчора»
• «Свіжість SLA для цього набору даних становить чотири години, але його не оновлюють протягом 12 годин»
• «Schema drift caused the pipeline to fail — the upstream team added a non-nullable column without warning.» (англійською)
• «Ми автоматизували перевірки на повноту, унікальність і посилання цілісності на всіх критичних наборах даних»
• «Походження даних показує, що проблема почалася в системі джерела, а не в нашому трубопровіді»
• «Ми повинні укласти договір з командою, що розробляє дані, щоб запобігти такому типу зміни»
• «Дуплікати записів в цій таблиці вказують на відсутність кроку дедуплікації в процесі поглинання»
• Наша панель якості даних показує довірчий бал для кожного набору даних — все нижче 95% викликає попередження
• «Перед використанням цього набору даних в моделі, ми повинні перевірити, що розподіл відповідає нашим очікуванням»
• “Проблема якості даних була вирішена. Основною причиною було неправильне перетворення часового поясу в скрипту ETL»

Вимірювання якості даних

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

** Точність: ** Чи дані правильно представляють реальну сутність, яку вони описують? ** Повнота: ** Чи присутні всі очікувані записи і поля? ** Несуперечність: ** Чи є дані несуперечливими у різних системах або представленнях? ** Вчасність: ** Чи доступні дані, коли вони потрібні? ** Унікальність: ** Чи є дублікати записів, де їх не повинно бути? ** Коректність: ** Чи відповідають дані визначеним форматам, діапазонам і правилам?

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

Практичні рекомендації

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

Навигація по нумерації: пошук відомостей про значення номерів

Суть ефективного обговорення якості даних полягає у ретельному виборі ваших слів. Це не просто сказати «дані погані», але сформулювати * чому * це проблематично і запропонувати рішення з рівнем точності, який резонує з колегами - особливо з тими, хто звик до формального технічного спілкування. Поширеною пасткою для людей, для яких англійська мова не є рідною, є використання надто спрощеної мови, яка може зменшити вплив вашого зворотного зв’ язку або запитів. І навпаки, жаргон без контексту створює плутанину. Метою є чітке, коротке формулювання питань і запропонованих дій.

Розглянемо сценарій: Ви переглядаєте запит на збирання для нової збірки конвеєра даних. Сара надсилає PR- повідомлення з описом своєї роботи: « Виправлено деякі дані ». Як рецензент, ви повинні надати конструктивний зворотній зв’ язок. Просто сказати «Це потребує більшої деталізації» не допоможе. Замість цього використовуйте такі фрази, як: «Чи можете ви розібратися в очікуваних кроках перевірки даних в цьому конвеєрі? Зокрема, я турбуюся про потенційні невідповідності в полі ідентифікатора клієнта - чи ми захоплюємо всі записи з чинним форматом? “демонструє глибше розуміння і направляє Сару на надання необхідної інформації. Іншим підходом є використання мови, яка зосереджена на впливі: « Поточне відсутність профілю даних може призвести до проблем у наступному етапі; запропоновані активні перевірки на нульові значення або несподівані розподіли зміцнять цю збірку ». Сфокусування на тому, * чому * щось потребує поліпшення, зміцнить ваш аргумент, особливо коли мова йде про можливо незнайому термінологію. Пам’ ятайте, що завжди слід формулювати запити і відгуки як можливості для співпраці, сприяючи створенню більш сприймальної середовища.

Ключовим елементом, який часто пропущено, є визнання * джерела * проблеми, а не просто зазначення симптому. Замість того, щоб сказати « Дані неправильні », спробуйте сказати « Система джерела, здається, періодично повідомляє неточні дати відправлення — це може бути наслідком нещодавнього оновлення логістичного API ». Такий рівень деталізації показує ретельність і надає змогу більш цілеспрямованому дослідженню. Нарешті, при обговоренні показників якості даних використовуйте точні терміни, такі як « повність », « точність », « послідовність », « достовірність » і « своєчасність ». Не просто скажіть « дані є надійними »; кількісно виражте їх — « Поточне значення рівня повності записів для таблиці клієнтів становить 98%, з метою 99, 5% до кінця місяця »

Ось приклад, який показує, як позначати потенційні проблеми за допомогою jq під час перевірки даних:

jq '.[] | select(.status == "pending") | .timestamp' data.json

Ця команда, виконана на файлі JSON ( data.json ), демонструє практичний спосіб визначення проблем за допомогою фільтрування за певними критеріями (наприклад, затримки записів). Він надає конкретний приклад того, як сформулювати технічне спостереження в ясний і дієвий спосіб.