Прием данных с помощью Kafka и Hadoop - как избежать дублирования данных, которое может возникнуть в результате сбоя проверки качества?

Question

Вот упрощенный сценарий:

N бизнес-потоков, которым нужны одинаковые исходные данные из одного источника. Данные загружаются с использованием Kafka (обычные конвейеры Kafka) и помещаются в HDFS, где автоматическая проверка качества запускается на необработанных данных для каждого потока. Все N потоков могут иметь разные стандарты качества данных. Например, они могут потребовать применения различных форматов даты и времени к необработанным данным, когда они преобразуются в желаемые схемы.

Каков наилучший подход к решению проблемы несоблюдения KPI тестов качества бизнес-потока?

Варианты:

1. Fail all - уведомить провайдера исходных данных и дождаться фиксированных данных. Затем снова проглотите и запустите все N наборов проверок качества.
2. Создайте ветвь - это означает, что K из N бизнес-потоков, которые не прошли проверки качества, будут ожидать своего фиксированного набора данных, в то время как переданный NK будет работать с текущим набором данных.
3. Отметьте записи, которые не прошли проверку качества для определенных бизнес-потоков, и поместите их в специальную очередь для обработки / исправления вручную. Примените некоторые правила и пороговые значения для количества ошибочных записей (просто с точки зрения осведомленности о способности команды, которая должна будет пройти через эту очередь, проанализировать и исправить проблемные записи)

Какой подход (если есть) из вышеперечисленного является наиболее разумным? Существуют ли какие-либо модели или лучшие практики для обработки ситуации, когда одни и те же данные используются многими потребителями, которые имеют разные стандарты качества? В идеале, я бы избегал дублирования тех же данных, что означает повторный прием фиксированного набора данных для каждого потребителя (N - не худший случай, поскольку исправление для одного из N может привести к проблемам для остальных, которые были в порядке заранее. Так что теоретически этот процесс может быть бесконечным).

Answer 1

Мы

1. Входные данные в базе данных
2. Никогда не удаляйте данные, однако дубликаты имеют версию hbase.
3. Запуск ежечасного экспорта из hbase в секционированную таблицу кустов (только последняя версия hbase)
4. Разделение основано на метке времени приема в hbase. Это означает, что разбиение является детерминированным, а разделы закрыты.
5. Почасовой экспорт может маршрутизироваться в несколько таблиц на основе правил. Это может быть из-за нескольких схем в одной теме / хранилище или из-за неверного сообщения, в этом случае оно передается в таблицу пустых букв.

Это добавляет час задержки для потребителей, но дает нам возможность маршрутизировать и перенаправлять сообщения в детерминированные закрытые разделы. Для наших клиентов 1 час задержки не является проблемой.

Мы можем запустить несколько заданий на экспорт для одной и той же темы / хранилища в зависимости от требований различных потребителей.