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

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

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

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

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

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

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

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

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

Есть предположения?


data-warehouse etl dimensional-modeling data-quality
person Anand Kannan    schedule 14.10.2015    source источник
comment
Отправка оскорбительных записей в файл приостановки для последующей обработки и использование графического интерфейса для исправления оскорбительных записей кажется вашим лучшим выбором.   -  person Gilbert Le Blanc    schedule 14.10.2015

Ответы (1)


arrow_upward
1
arrow_downward

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

Есть много перестановок и комбинаций с вашим сценарием. Главный вопрос: Являются ли разные данные действительными или недействительными?, так как это изменит ваше отношение к ним.

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

Пример недопустимых данных. Однако, если данные НЕДЕЙСТВИТЕЛЬНЫ (например, ваша система каким-то образом неправильно создает повторяющиеся ключи), ваши варианты будут другими. Я сомневаюсь, что вы захотите обнародовать эти данные, поскольку в настоящее время они недействительны, и, как вы указали, у вас нет способа определить, какая дублирующаяся запись является «правильной». Но вы же не хотите, чтобы вся ваша загрузка вышла из строя/остановилась.

В этом случае вы обычно:

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

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

person mal-wan    schedule 15.10.2015