Тестування сховищ даних

Публікується від імені IvanovAleksey.

В інтернеті мало інформації по тестуванню Data Warehouse.
Можна знайти загальні вимоги: повнота даних, якість і т. п.
Але ніде немає опису організації процесу, і якими перевірками можна покрити ці вимоги.
В цій статті спробую розповісти: як ми тестуємо Сховище даних "Тінькофф Банк".
Наш Data Warehouse
Спочатку коротко опишу наше Сховище.
Процеси завантаження і обробки даних реалізовано у вигляді джобов. Джобы запускаються на планувальнику зазвичай вночі, коли ніхто не використовує зовнішні системи (навантаження на них мінімальна), і після закриття бізнес дня.
Структура бази — це безліч таблиць різного об'єму (від декількох рядків до 3 млрд. і більше), з різною кількістю колонок (від 1 до 200), з історичністю і без неї. Розмір бази близько 35Тб.
Використовуються зовнішні джерела даних: oracle, CSV/XLS файли, MySql, Informix, BIN файли, CDH – Cloudera(Hadoop). Вивантажуємо дані у зовнішні системи також через oracle, SAS таблиці і у вигляді CSV/XLS файлів.
Об'єкти сховища (опис баз, джобов, таблиць, в'юх і. т. п) розробляються в SAS Data Integration Studio і зберігаються на SAS сервері у вигляді метаданих. Фізично таблиці знаходяться в базах Greenplum і SAS.
Для запуску джобов, по метаданих генерується код і переноситься на деплоймент сервер. Після чого вони можуть бути запущені на планувальнику.
Зміни середовища, переносяться у вигляді пакетів, що складаються з метаданих і скриптів (на створення/редагування фізики, даних). Для зручності перенесення розробниками була написана спеціальна програма «Авторелиз». 
Для ручного запуску джобов є веб портал. Там же можна побачити запущені планувальники та статуси, які працюють на них джобов.
Об'єкти тестування
Будь-яка доопрацювання DWH являє собою створення/зміна фізики і метаданих таблиць і джобов. Або це коригування скриптами вже завантажених даних.
Наприклад, створюється нова вітрина. В пакеті будуть метадані нового джоба і таргету і скрипт на створення фізики нової таблиці в базі даних.
Таким чином, об'єкт тестування – це змінений/створений по завданню джоб, дані в його таблиці і дані в цільових таблицях залежних джобов (якщо вони є).
Рівні і види тестування
Наш тестовий контур повністю повторює продуктивний: теж залізо, ті ж дані, того ж обсягу, завантажуються і обробляються з допомогою таких же процесів. Враховуючи цю особливість, а так само те, що завдання розробляються, коли в джерелах вже є всі необхідні дані, можна без втрати якості скоротити обсяг перевірок.
Навантажувальне тестування(Performance testing) і тестування на великих обсягах даних(Volume testing) проводимо тільки при перенесенні завдання на тест: перевіряємо час роботи джоба, навантаження на стенд і обсяг ворков (не буду ці перевірки докладно описувати в цій статті).
На системному рівні робота джобов і якість даних перевіряється автоматично. За джобами стежить сам нічний планувальник і скрип контролю обсягів ворков. А дані після завантаження, перевіряються з допомогою Data Quality Daemon (про нього нижче). Якщо щось не так з даними, відповідальним приходять листи з помилками.
З «білого ящика» дивимося тільки правильне вказівку середовища (були помилки з хардкодом схем test і dev). В майбутньому планується перевіряти це автоматом, при пакета розробником.
Основними у нас є функціональне тестування («чорний ящик») і перевірка регресії, на рівнях: компонентів та інтеграції.
З урахуванням визначених у попередньому абзаці об'єктів тестування, повний набір перевірок виглядає так:
  • Модульне тестування. Перевіряємо сам новий/змінений джоб і дані в його таблиці.
    Функціональне тестування: будуємо прототип і порівнюємо зі значеннями в нових/змінених колонках цільових таблиць.
    Регрессионное тестування: виконуємо порівняння з бекапом, незачеплені доопрацюванням дані, повинні збігатися.
  • Інтеграційне тестування. Перевіряємо якість даних на виході залежних джобов (які не вносилися зміни) і в зовнішніх системах.
    Функціональне тестування: якість порушених доопрацюванням даних має відповідати ТЗ.
    Регрессионное тестування: якість незачеплених опрацюванням даних, не повинно зміниться.
Під «порівнянням з бекапом» мається на увазі звірка результатів роботи нової і попередньої версії джоба. Тобто старий і новий джоб запускаються на однакових даних. Порівнюються їх цільові таблиці.
«Прототип» — набір даних, зібраний по ТЗ, і який повинен бути у вітрині після доопрацювання. Це може бути макет або повністю нової таблиці, або тільки змінених колонок в старій таблиці.
Залежно від завдання, деякі з цих перевірок можуть бути надмірними. Визначивши типи доопрацювання, можна позбавиться від надмірних перевірок і скоротити час тестування.
Види змін і перевірки
Проект Data Warehouse в банку постійно розвивається, створюються нові вітрини, допрацьовуються старі, оптимізуються процеси завантаження. Але в дійсності всі завдання можна розділити на чотири групи зі своїм достатнім набором тестів:
  1. Технічні.
    Оптимізація, міграція і т. п. – то є завдання, де алгоритм не змінюється. І дані в таблиці теж не повинні змінитися.
    Досить виконати перевірку регресії: порівняти таргет зміненого джоба з бекапом. Залежні джобы можна не перевіряти, оскільки якщо таргет збігається з бекапом – залежний джоб його так само обробить.
  2. Зміна старого функціоналу.
    Змінюється алгоритм, фільтри (змінюється кількість рядків), додаються нові поля, джерела. Тобто, змінюється набір даних у таблиці.
    Необхідно виконати всі перевірки: порівняти дані в таблиці зміненого джоба з бекапом і прототипом, перевірити якість даних в таблицях залежних джобов і зовнішніх системах.
  3. Розробка нових вітрин.
    Створюються нові таблиці і джобы, які їх завантажують.
    Виконуємо тільки функціональне тестування: звіряємо цільові таблиці з прототипами.
    Якщо вивантаження йде в зовнішню систему, додатково перевіряємо інтеграцію — дивимося, як у зовнішній системі відображаються завантажені дані.
  4. Редагування даних.
    Видалення дублів, старих записів, виправлення версійності, проставлення коректних значень.
    Перевірка цих змін досить складна і описати її в двох реченнях не вийде. Докладно розповім в наступній статті
Якщо в рамках проекту/завдання присутні відразу кілька видів змін, то в тестовий набір беремо перевірки по кожному з них.
Цих перевірок достатньо, щоб гарантувати відповідність вимог і результатів розробки в більшості завдань.
Бліц перевірки
Побудова прототипу і виконання порівняння може зайняти багато часу (залежить від продуктивності середовища і обсягу даних). Ми зіткнулися з цією проблемою, коли тестовий контур був слабшим продуктивного. Щоб не втратити даремно час на порівнянні і відразу виловити критичні дефекти, використовувалися швидкі перевірки.
Підходять для будь-якого типу завдань і виконуються перед початком тестування:
  • Завдання прийшла на тест і джоб відпрацьовує (так, це іноді забувають перевірити)
  • Не повинно бути null і дублів по ключу (якщо ТЗ не вказано протилежне). Версійність таблиці повинна бути дотримана.
  • За новими полями приходять дані: select count(new_field) from table1 повинно бути більше 0.
  • Нові записи завантажуються в таблицю: порівнюємо кількість записів в бекапе і таргете.
Якщо вони завершилися невдало – можна відразу повернути завдання на розробку/завести дефект Critical.
Інструменти
Основні дії під час тестування: накат завдань на тест, порівняння таблиць. І вони підходять для автоматизації.
Як я вже казав, для перенесення використовується власна розробка, програма «Авторелиз». Що дозволяє заощадити час і уникнути помилок при ручному перенесенні.
Робота програми виглядає приблизно так:
  • Знімаються бекапи фізики таблиць і метаданих змінених об'єктів.
  • Виконуються скрипти, які повинні виконатися до імпорту нових метаданих
  • Імпорт метаданих.
  • Виконуються скрипти, які повинні виконатися після імпорту метаданих і перед запуском джобов на планувальнику.
  • Деплой джобов і запуск на планувальнику.
  • Виконуються скрипти, які повинні виконатися після завершення роботи джоба.
Запускається через консоль. На вхід подається номер завдання, ім'я середовища та додаткові параметри(наприклад робити паузу після кожного кроку).
Для порівняння таблиць (таргет з прототипом/бекапом) використовується спеціальний макрос, який звіряє значення в рядках за вказаною ключу і зіставляє заповнюваність полів.
На вхід макросу передаються імена таблиць і ключ порівняння.
Приклад результату роботи:
Кількість розбіжностей по колонках. Самі розбіжності дивіться у difference.






Примітка column_name differ_base_to_comp 1 column_1 0 2 column_2 20 3 column_3 0
Кількість розбіжностей в угрупованнях за _cd і _flg полях.







Примітка column_name column_group base_groups compare_groups diff base_group_pct compare_group_pct diff_group_pct 1 column_2 A 18743 63 18680 0.0021 0.0024 -0.0003 2 column_2 B 4451740 17756 4433984 0.4897 0.6877 -0.1980 3 column_2 C 4619311 7813 4611498 0.5082 0.3026 0.2056 4 column_2 null 191 188 3 0.0000 0.0073 -0.0073
Для перевірки якості даних використовується макрос профайлінгу. Який вважає кількість та відсоток записів з null по кожній колонці, дублі і ннл по ключу, рядків в угрупованні з прапорів і значенням, min/max/avg за сумами в колонках.
На вхід подається назва таблиці і ключ.
На виході отримуємо звіт, з табличками по кожному з розрахунків.
Приклад:
Кількість миссингов по колонках.








Примітка column_name base_nulls nulls_pct 1 column_1 0 0.00 2 column_2 0 0.00 3 column_3 7 0.03 4 column_4 0 0.00 5 column_5 0 0.00
Так само є макрос для порівняння профайлингов двох таблиць між собою (або з таблицею на продуктиве). Принцип роботи той же: виконуються профайлинги для кожної таблиці, і отримані результати порівнюються.
Звіт на виході схожий на звичайний профайлинг, лише до даних з двох таблиць.
Контроль якості даних
Для контролю якості даних у всьому сховище використовується самописний Data Quality Daemon (DQD), який перевіряє всі таблиці на відповідність правилам, складеними аналітиками і фахівцями відділу контролю якості даних.
DQD являє собою процес, який кожні 10 хвилин знаходить оновилися таблиці і виконує задані SQL запити. Результати порівнюються з еталонними показниками (передвстановлені значення) і розсилає звіт з відхиленнями.
Приклад звіту:




Constraint Definition SQL Script Corrupted Rows Cnt test_schema.table1 / Unique Entity Key [id] select sum(cnt) as cnt from ( select 0 as cnt union all select 1 as cnt from test_schema.table1 group by id having count(*) > 1 union all select 1 as cnt from test_schema.table1 where not ((id ) is not null) ) sq 15
Оформлення тест кейсів
У нашому банку тестування живе в Zephyr (надбудова Jira). Самі завдання на доопрацювання оформляються як тікети в Jira, а тест кейси та тестраны в Zephyr.
Спробувавши кілька варіантів, зупинилися на тому, що заводимо по кейсу на кожен змінений, в рамках завдання, джоб. Кейс називаємо: «<номер завдання в jira>: <ім'я джоба>». І линкуем до тікети.
Основні переваги такого підходу:
  1. У задачі видно покриття кейсами (які джобы перевірятимуться).
  2. Можна легко порахувати відсоток run/pass/failed.
  3. Простий пошук по імені джоба повертає всі написані кейси, їх статус, хто і коли написав, виконував і за якою задачі.
  4. Знову ж таки, з назви кейса, можна дізнатися номер завдання на доопрацювання. А відкривши його знайти за лінком.
Що далі?
Завжди можна щось покращити! Докладно вивчивши особливості об'єктів і процесів сховища, можна оптимізувати складені нами набори перевірок, придумати як їх автоматизувати.
Наприклад, не для всіх верств потрібно перевіряти якість даних у вітрині — досить збігу з бекапом.
Так само сховище саме по собі містить безліч механізмів: инкрементальная завантаження, різні типи завантаження даних (replace, insert/update і т. д.), різні типи завантажувачів даних (звичайні/для вітрин з версионностью). Їх особливості треба враховувати при написанні тестових сценаріїв.
На цьому поки все.
Сподіваюся, стаття вийшла цікавою та корисною. Якщо відгуки будуть позитивними, а тема тестування DataWarehouse виявиться затребуваною – напишу продовження.
Інші наші статті про Сховище Даних "Тінькофф Банк":
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.