Обработка дубликатов в хранилище данных

Question

Я прошел через приведенную ниже ссылку для обработки проблем с качеством данных в хранилище данных. .

http://www.kimballgroup.com/2007/10/an-architecture-for-data-quality/

" Отвечая качества События Я уже заметил, что каждый экран качества должен решить, что происходит, когда выдается ошибка Возможны следующие варианты: 1) прекращение процесса, 2) направление обижая записи (ей) в неизвестности файл для последующей обработки, и 3) просто мечения данные и передать его через к следующему шагу в трубопроводе. третьего варианта является самым лучшего выбора. "

В (например, список клиентов), иногда мы получаем один и тот же Клиент дважды (две записи имеют разницу в определенных атрибутах). Какое наилучшее решение в этом сценарии?

1. Я не хочу отклонять обе записи (так как это означает неполные данные клиента).

2. Исходные системы очень медленно фиксируют проблему, поэтому каждый день мы получаем одни и те же проблемы. Это означает, что исправление вручную проблемы также является жестким, поскольку это нужно делать каждый день (каждый день мы получаем список клиентов).

3. Выбор одной записи невозможен, так как мы не знаем, что такое правильное значение.

4. Имея обе записи на нашем складе, наши соединения разрушены. Из-за двух строк для одного и того же идентификатора строки таблицы фактов удваиваются (в соединении).

Любые мысли?

Answer 1

Какое наилучшее решение в этом случае?

В вашем сценарии много перестановок и комбинаций. ? Большие вопросы есть «Являются ли различные детали действительной или недействительной как это будет меняться, как вы справляетесь с ними

Действительно данные Пример:. Запись 1 имеет Джон Смит живущий в 12 Main St, Record 2 имеет Джон Смит живет в 45 Main St. Это справедливо, потому что Джон Смит переместил адрес между первой и второй записью. Это пример Действительных данных. Если данные действительны, у вас есть такие параметры, как создание медленно изменяющегося измерения и отслеживание изменений (

Недопустимые данные Пример: Однако, если данные НЕВЕРНЫ (например, ваша система каким-то образом создает дублирование cate keys неправильно), тогда ваши варианты разные. Я сомневаюсь, что вы захотите обработать эти данные, поскольку в настоящее время они недействительны и, как вы указали, у вас нет способа определить, какая дублирующая запись является «правильной». Но вы не хотите, чтобы вся ваша нагрузка потерпела неудачу/остановилась.

В этом случае вы, как правило:

1. Нажмите эти повторяющиеся строки в области «Карантин»
2. Push-оповещения для людей, которые имеют власть, чтобы исправить это оперативно
3. При необходимости выберите один из записей случайным образом, как запись «золотая деталь» (поэтому ваша система по-прежнему будет насчитывать итоговые значения) и отметьте атрибут в записи, в котором говорится, что он «недействителен» и находится под следствием.

Точка зрения, которую Kimball пытается сделать, заключается в том, что вариант 1 не является желательным, поскольку он останавливает всю вашу систему на наличие ошибок, вариант 2 не идеален, потому что это означает, что ваши агрегаты будут отображаться не синхронизированными с ваши исходные системы, поэтому вариант 3 является наиболее желательным, поскольку он по-прежнему приводит к исправлению данных, но не останавливает процесс или использование данных (но он предупреждает пользователей о том, что эти данные являются подозрительными).