Мікробатчева обробка у Spark Streaming
Станом на середину 2016 року для потокової аналітики часто обирають Apache Spark Streaming 1.6.2. Його модель DStream (Discretized Stream) працює з потоком як із послідовністю невеликих пакетів (micro-batches). Це зручно для інтеграції з існуючим кодом Spark, але вимагає тонкого налаштування інтервалів обробки. Якщо час обробки пакету перевищує час його формування, виникне черга, що призведе до зростання затримки (latency). Використовуйте 'Direct Approach' для зчитування з Kafka — це дозволяє краще контролювати відповідність між зчитаними даними та результатами обробки.
Вирішення проблеми запізнілих даних та реплей
Одна з найбільших складнощів — це різниця між часом виникнення події (Event Time) та часом її обробки (Processing Time). Наприклад, через мережевий збій дані касового терміналу можуть надійти із запізненням. У вашому аналітичному застосунку необхідно передбачити логіку для обробки таких "пізніх" подій, щоб вони не порушували цілісність віконної статистики. Для коректного реплею (повторного розрахунку) даних, наприклад, при виявленні помилки в алгоритмі, зберігайте вхідні потоки в Kafka достатньо довго, щоб ви могли перерахувати показники за попередні періоди.
Reconciliation: поєднання потоків і DWH
Потокова аналітика — це оперативний контур для швидкого реагування. Проте вона не замінює корпоративне DWH, яке залишається джерелом істини для регламентованої звітності. Очікуйте, що цифри в оперативних панелях можуть відрізнятися від даних у звітах DWH через коригування, повернення товарів та фінансові закриття, що виконуються вже після завершення дня. Ваше завдання — задокументувати ці відмінності, щоб користувачі бізнес-звітів чітко розуміли природу даних. Працюйте над якістю даних на вході (Data Quality) та впроваджуйте автоматизоване звіряння потоків із даними в системі обліку, щоб виявляти невідповідності на ранніх етапах.
Автор матеріалу