Дані запізнюються: контроль свіжості та відновлення завантажень

У корпоративному середовищі успішне завершення ETL-завдання часто плутають із наявністю актуальних даних. Проте статус "Success" у планувальнику лише підтверджує відсутність критичних технічних помилок, але не гарантує, що дані свіжі, повні чи коректні. Для надійної аналітики необхідно розділяти технічну оркестрацію та контроль свіжості (Data Freshness).

Технічний контекст та інструменти

На лютий 2019 року важливо використовувати інструменти з розумінням їхніх обмежень. Apache Airflow версії 1.10.2 дозволяє відстежувати SLA завдань через параметр sla, що допомагає сигналізувати про порушення часових меж. Однак SLA-попередження в Airflow прив'язане до логічного часу запуску DAG, а не до фактичного моменту появи даних у звіті. Apache NiFi версії 1.9.0, випущений 19 лютого 2019 року, розширив можливості роботи з даними через вдосконалені Record Readers, включаючи функціонал виведення схем, що полегшує обробку потоків, але не замінює потребу у жорстких бізнесових контрактах.

Практичний приклад відновлення

Уявіть ситуацію: нічний процес завантаження продажів з ERP завершився, але звіт порожній через збій у мережі під час передачі пакету.

• Виявлення: Моніторинг зафіксував відсутність нових записів у таблиці DWH при успішному завершенні процесу.
• Ізоляція: Використовуйте SELECT MAX(transaction_timestamp) FROM staging_table, щоб зрозуміти, на якому часі зупинився потік.
• Replay: Якщо ваш ETL реалізований як ідемпотентний (використовує UPSERT за бізнесовим ключем), ви можете безпечно перезапустити процес для діапазону [02:00, 04:00]. Система оновиться, не створюючи дублікатів.

Не покладайтеся виключно на MAX(updated_at), оскільки він показує лише останній рядок, а не повноту пакету. Завжди звіряйте source_count з ERP та loaded_count у DWH.

Створення надійного конвеєра

• Впроваджуйте контроль «водяних знаків» (watermarks) для кожного джерела.
• Використовуйте ідемпотентну логіку: незалежно від того, скільки разів перезапускається завдання, кінцевий результат має бути однаковим.
• Розділяйте технічні помилки (retry) та бізнесові порушення (оповіщення для Data Steward).

Перший тест відновлення завантаження

Щоб мінімізувати ризики простоїв даних, виконайте наступні кроки:

1. Ревізія SLA: Визначте критичні набори даних і встановіть для них часові ліміти, які виходять за межі простого «технічного часу».
2. Впровадження аудиту: Створіть таблицю etl_audit_log для фіксації source_watermark та count для кожного завантаження.
3. Тестування відновлення: Проведіть «симуляцію збою» для критичного ETL-процесу, щоб перевірити, чи здатна система на коректний повторний запуск (replay) без маніпуляцій вручну.
4. Моніторинг потреби: Налаштуйте алерти не лише на падіння процесів, а й на тривалу відсутність оновлення записів, навіть якщо процес «зелений».