Содержание


Выявление дубликатов в данных с помощью продукта InfoSphere QualityStage

Ускоренное выявление дубликатов в именах и адресах

Comments

Обзор

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

Продукт InfoSphere QualityStage® (компонент продукта InfoSphere Information Server), предоставляет функции очистки данных в виде простой в использовании схемы последовательности операций, упрощающей проектирование. Продукты InfoSphere QualityStage и InfoSphere DataStage® тесно связаны, совместно используя общую среду проектирования и исполнения. Это позволяет пользователю с легкостью встроить задачи по очистке данных в любой процесс интеграции информации. Продукт QualityStage помогает понять существующие источники данных, исправить и стандартизировать информацию и найти дубликаты перед доставкой очищенных данных в хранилище данных. После этого хранилище данных будет снабжать предприятие достоверной информацией. С помощью продукта InfoSphere QualityStage можно чистить данные в разных областях; в этой статье основное внимание уделяется очистке данных в индийских именах и адресах. Вы научитесь распознавать дубликаты в одном входном источнике. Продукт InfoSphere QualityStage предлагает готовые к применению правила для нескольких других стран; описываемые механизмы можно использовать для удовлетворения соответствующих потребностей этих стран.

Практические ситуации, связанные с отысканием дубликатов в данных

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

  • В Индии действует несколько телекоммуникационных компаний. Согласно Комиссии по регулированию в области телекоммуникаций Индии (Telecom Regulatory Authority Of India), пользователь может иметь не более девяти активных подключений к телекоммуникационной компании. Каким образом поставщик услуг может установить, что у пользователя есть более девяти подключений?
  • Правительство Индии разрешает каждому домохозяйству иметь не более одного подключения к источнику коммунально-бытового газа. Каким образом можно установить, что у домохозяйства имеется более одного подключения?
  • Государственные учреждения назначают пенсии пожилым людям, вдовам и инвалидам. Каким образом государственные учреждения могут пресекать попытки мошенников получить более одной пенсии?
  • Регулирующий орган в сфере страхования сопоставляет информацию о разных страховых претензиях от страховых компаний. Способна ли эта мера предотвратить мошенничество путем выявления дублирующихся страховых претензий по одной и той же проблеме со здоровьем?

Без инструмента для обеспечения качества данных организация может оказаться уязвимой перед мошенниками и может быть подвергнута существенным штрафам за несоблюдение государственных нормативных актов. Однако выявление дубликатов в вышеупомянутых ситуациях сопряжено с определенными трудностями.

  • Проверить миллионы записей на наличие дубликатов невозможно вручную.
  • Для обнаружения дубликатов может оказаться недостаточно простых SQL-выражений. Клиенты могут писать свои имена и адреса в разных форматах. В результате ошибок ввода данных или мошенничества могут возникать дубликаты, выглядящие как разные записи.
  • В разных регионах используется разная терминология. Так, в Северной Индии улицу можно назвать galli, а в Южной Индии – salai.
  • В некоторые поля — такие как дата рождения, идентификатор и номер телефона — операторы ввода данных могли ввести значение по умолчанию, чтобы упростить свою работу с системой. Это могло породить записи с неправильными данными. Например, несколько идентификационных номеров налогоплательщика могли быть введены как 9999999999. Отсутствие обнаружения этого факта на ранней стадии, в процессе очистки данных, может привести к группированию разных объектов в качестве дубликатов

Шаги для распознавания дубликатов в данных

Отыскание дубликатов включает в себя следующие шаги.

  1. Выполнение анализа данных для определения текущего состояния данных. Это шаг позволяет понять характер и объем аномалий данных, чтобы улучшить их сопоставление. Например, если в 97% записей адрес электронной почты неверен или имеет значение NULL, а штат пребывания одинаков во всех этих записях, можно не сопоставлять эти записи на основе адреса электронной почты или названия штата, а выбрать для сопоставления другие поля.
  2. Стандартизация отдельных полей на основе заранее созданных таблиц и правил данных, а также их унификация согласно стандартам бизнеса. Например, поле имени в записи "Mr. Gupta Akshay" и в записи "Akshay Gupta c/o Gopal Gupta". Обе эти записи являются представлениями имени одного и того же человека. В отсутствии стандартизации было бы сложно идентифицировать эти записи как дубликаты.
  3. Генерация частоты стандартизированных данных с целью нахождения частоты присутствия некоторого значения данных в определенном распределении. Это помогает сравнивать записи, обеспечивая улучшение результатов по сравнению с чисто детерминистическим сравнением. Например, можно быть более уверенными в совпадения двух записей, если они имеют одинаковый действительный налоговый идентификатор, чем в том случае, когда эти записи имеют одинаковое значение в поле " пол" или в поле "страна".
  4. Создание спецификации совпадения – шаблона для отыскания дубликатов в данных. Другие шаги, излагаемые в этой статье, достаточно просты; их можно спроектировать всего за несколько минут. Спецификации совпадения содержат основную логику для отыскания дубликатов; зачастую для создания спецификации совпадения в соответствии с конкретными потребностями требуется определенный опыт.
  5. Создание задания Match продукта InfoSphere QualityStage, на вход которого поступают стандартизированные данные, частоты присутствия и спецификации совпадения, созданные ранее для распознавания дублирующихся записей внутри данных.

Примечание. Отыскание дубликатов в данных – это итеративный процесс. Это типовая методика исполнения процесса на репрезентативной выборке из всех данных до его применения ко всем данных. Не существует систем выявления совпадений, которые всегда гарантировали бы точность 100%. Необходимо понять и определить устойчивость бизнеса к невыявленным совпадениями, а также к ложным совпадениям. Для этого нужно в итеративном режиме тестировать изменения, вносимые в спецификации совпадения. Наконец, чтобы гарантировать точность и полноту обработанных данных, распорядители данных (data steward) должны проинспектировать данные, оценить критерии совпадения и предоставить обратную связь по результатам.

Анализ данных

Анализ данных можно выполнить с помощью продукта InfoSphere Information Analyzer или с помощью стадии Investigate продукта InfoSphere QualityStage. Анализ данных играет важнейшую роль в обеспечении качества данных, помогая определить текущее состояние данных. Анализ данных способен определить выполнимость проекта и объем работы, который потребуется ETL-процессу для очистки данных. Анализ данных позволяет ответить на следующие вопросы.

  • Содержит ли столбец данных значения за пределами допустимого диапазона, значения по умолчанию или уникальные значения, например, телефонный номер 9999999999?
  • Содержит ли столбец данных текст в свободной форме, для извлечения ключевых компонентов из которого требуется синтаксический анализ? Например, представленный в свободной форме столбец адреса может содержать такие данные, как номер входа, название улицы, название города и т.д., которые можно извлечь в разные ыстолбцы с целью оптимизации сопоставления.
  • Содержит ли столбец данных значения, которые не соответствуют требуемому типу информации для определенного поля? Например, имеются ли в поле имени или адреса такие значения, как ученая степень, принадлежность к определенной организации, номер водительской лицензии или иная неуместная информация?
  • Содержит ли столбец данных значения, которые перекрываются со смежными полями и требуют повторного согласования содержимого полей? Например, не распространяется ли информация об имени на поле названия улицы/адреса?
  • Содержит ли столбец данных некорректные форматы, способные порождать проблемы преобразования, например, алфавитно-цифровые форматы в чисто числовых полях?
  • Имеются ли в столбце данных такие явления, как пустые места, недостающие данные или данные, требующие манипуляций со специальными символами или с пунктуацией?

Стандартизация данных

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

Рассмотрим процесс стандартизации на нескольких примерах.

Таблица 1. Нестандартизированные имя и адрес
СтолбецИмяАдрес
Add1Gupta AkshayD- 123,GREATER KAILASH II, New Delhi 110048
Add2Mr. Akshay GuptaD/123 GK 2, ND 110048

Эти два адреса соответствуют одному и тому же лицу, проживающему в одном и том же месте. Однако различия в форматировании и описании адресов препятствуют связыванию этой информации. Выполнение стадии Standardize (стандартизация) с использованием набора правил для имен и адресов дает следующие результаты.

Таблица 2. Стандартизированные имя и адрес
СтолбецИмяФамилияНомер входаРайонГородПочтовый индекс
Add1AkshayGuptaD 123Greater Kailash - 2New Delhi110048
Add2AkshayGuptaD 123Greater Kailash - 2New Delhi110048

Набор правил стандартизации выявляет следующую информацию и в случае необходимости вносит в нее изменения.

  • В строке Add1 слово Gupta – фамилия, а слово Akshay – имя.
  • D 123 – это номер входа; он преобразуется в единообразный формат.
  • Названия GK 2 и Greater Kailash II преобразуются в единообразный формат.
  • В строке Add2 город правильно идентифицируется как New Delhi по почтовому индексу.

Если алгоритм сопоставления с целью сравнения этих двух адресов выполняется после стандартизации, то вероятность обнаружения дубликатов повышается.

Примечание. Стадия Standardize не манипулирует исходными столбцами данных. Вместо этого на данной стадии добавляются новые столбцы для хранения нормализованного представления данных. Чтобы создать такое единообразное представление данных, применяются наборы правил стандартизации.

Наборы правил стандартизации

Процесс стандартизации продукта InfoSphere QualityStage использует наборы правил стандартизации для кондиционирования и стандартизации данных согласно требованиям конкретной области. Продукт InfoSphere QualityStage предоставляет широкий выбор встроенных правил, которые можно использовать или "как есть", или в качестве исходного пункта для адаптации и тонкой настройки стандартизации в соответствии с конкретными требованиями.

Наборы правил стандартизации производят вполне единообразную выходную информацию, однако возможны и исключения, например, когда вы сталкиваетесь с новыми данными, с неожиданными условиями, с данными по умолчанию или с данными тестирования, а также с необычными форматами. В таких случаях набор правил можно изменить с помощью инструмента Standardization Rules Designer продукта InfoSphere QualityStage. Инструмент Standardization Rules Designer предоставляет возможности для совершенствования наборов правил стандартизации.

Стандартизация индийских имен и адресов

Процесс ввода адресов в Индии не унифицирован в масштабе всей страны. Адрес может быть записан в разных форматах, а в одном и том же адресе может содержаться информация о нескольких улицах или о дополнительных ориентирах. Кроме того, могут иметь место лингвистические коннотации для ориентиров и лингвистические эквиваленты для названий улиц. Чтобы преодолеть эту проблему, продукт InfoSphere QualityStage использует различные методики распознавание образов и шаблоны. Адрес классифицируется по нескольким элементам, которые при вводе адреса могут встречаться неоднократно. Имеются встроенные наборы правил стандартизации для всей территории Индии.

INAREA

Любой индийский адрес сначала пропускается через набор правил INAREA. Набор правил INAREA идентифицирует во введенном адресе название города, название штата и почтовый индекс. Он также способен генерировать название города по введенному почтовому индексу. Вся прочая информация перемещается в столбец UnhandledData с целью последующей обработки набором правил для конкретного региона. На следующем рисунке показано применение набора правил INAREA к введенному адресу.

Рисунок 1. Обработка индийского адреса с помощью набора правил INAREA
Image depicts the processing of Indian address using INAREA rule set
Image depicts the processing of Indian address using INAREA rule set

Итак, мы видим, что происходит следующее.

  • В тексте, вводимом в форме сплошного потока, идентифицированы название города и почтовый индекс.
  • Название штата сгенерировано на основе названия города или почтового индекса.
  • Название города нормализовано из Calcutta в Kolkata.
  • Сгенерирован флаг валидации, означающий допустимость почтового индекса.
  • Необработанный фрагмент адреса перемещен в столбец UnhandledData. Эта информация будет на следующей стадии обработана с помощью набора правил для конкретного штата.

Исходя из идентифицированного выше названия штата, для обработки этих необработанных данных согласно специфике конкретного штата будет вызван набор правил для штата West Bengal (INWBAD). Выбор набора правил для конкретного штата осуществляется беспрепятственно, если для стандартизации адреса используется общий контейнер для наборов правил индийских адресов (Indian Address Shared Container). В следующем разделе показано использование набора правил для конкретного штата.

INWBAD

INWBAD – это набор правил для конкретного штата, выбранный на основе названия штата, который был идентифицирован на предыдущем шаге. Этот набор правил применяет форматы адреса, специфичные для данного штата. На следующем рисунке показано применение набора правил к фрагменту введенного адреса, который не был обработан при применении набора INAREA.

Рисунок 2. Обработка специфичных для региона данных с помощью набора правил для конкретного штата
Image demonstrates the standardization of state-specific data                     using state-specific rule set
Image demonstrates the standardization of state-specific data using state-specific rule set

Этот набор правил демонстрирует мощные возможности стандартизации данных. Данные из текста, введенного в форме сплошного потока, извлечены в соответствующие строки и столбцы.

  • Номер входа, номер этажа, названия здания, район и т.д., были идентифицированы правильно.
  • Слово Galli было идентифицировано как способ представления улицы.
  • Для важных столбцов были сгенерированы фонетические версии. Например, на показанной выше иллюстрации конкатенированное название здания RAMKRISHNA демонстрирует специфическую для региона стандартизацию. RANCRASN и R526 – это фонетические представления, сгенерированные с помощью популярных алгоритмов NYSIIS и SOUNDEX, соответственно. В случае ошибки при вводе названия, такие столбцы, как название здания и название улицы, можно сравнивать с использованием фонетических представлений.
  • В некоторых случаях сокращения также стандартизируются (так, FLR преобразуется в FLOOR, APT преобразуется в APARTMENT).
  • Если какой-либо фрагмент данных невозможно стандартизировать, он переводится в категорию UnhandledData (необработанные данные). Эти необработанные данные можно сгруппировать с целью распознавания шаблона, который на данный момент не обрабатывается текущим набором правил. После этого можно будет добавить несколько новых правил для обработки таких шаблонов, чтобы улучшить получаемые результаты. Обычно добавление всего лишь одного или двух дополнительных наборов правил позволяет охватить большую часть необработанных данных.

INAME

Набор правил INNAME предназначен для стандартизации индийских имен. На следующем рисунке показано применение набора правил INNAME к вводимым данным.

Рисунок 3. Стандартизация индийских имен
Image demonstrates the standardization of Indian names using INNAME rule set
Image demonstrates the standardization of Indian names using INNAME rule set

Стандартизация данных имени идентифицировала или сгенерировала следующую информацию.

  • Это имя человека, а не название организации.
  • Это человек мужского пола.
  • В данных присутствуют имя, второе имя, фамилия, префикс имени и дополнительное имя.
  • Сгенерировано фонетическое представление имени и фамилии.

Специальные наборы правил

С помощью продукта InfoSphere QualityStage можно создавать специальные наборы правил. Ниже показаны примеры специальных наборов правил. (Примечание. Эти дополнительные наборы правил предоставляются в комплекте с этим учебным пособием).

INTAXID

Набор правил INTAXID стандартизирует идентификационный номер налогоплательщика в Индии (PAN). На следующем рисунке показано применение набора правил INNAME к вводимым данным.

Рисунок 4. Стандартизация идентификационного номера налогоплательщика
Image demonstrates the standardization of an Indian PAN  using INTAXID rule set
Image demonstrates the standardization of an Indian PAN using INTAXID rule set

Стандартизация данных идентификационного номера налогоплательщика выявила или сгенерировала следующую информацию.

  • Идентификационный номер налогоплательщика представлен в надлежащем формате.
  • Этот идентификационный номер налогоплательщика принадлежит человеку, а не организации.
  • Первая буква фамилии держателя идентификационного номера налогоплательщика также установлена.

INPHONE

Набор правил INPHONE стандартизирует номера телефонов в Индии. На следующем рисунке показано применение набора правил INPHONE к вводимым данным.

Рисунок 5. Стандартизация номеров телефонов в Индии
Image demonstrates the standardization of an Indian phone number using INPHONE rule set
Image demonstrates the standardization of an Indian phone number using INPHONE rule set

Стандартизация данных телефонного номера идентифицировала или сгенерировала следующую информацию.

  • Название города и название зоны обслуживания было сгенерировано на основе кода автоматической междугородней телефонной связи.
  • Были установлены номер телефона и дополнительный номер телефона.
  • Номер телефона был идентифицирован как действительный.

INMOBILE

Рисунок 6. Стандартизация номера мобильного телефона в Индии
Image demonstrates the standardization of an Indian mobile phone number using INMOBILE rule set
Image demonstrates the standardization of an Indian mobile phone number using INMOBILE rule set

Показанная выше входная информация представляет собой десятизначный номер, тем не менее, набор правил пометил его как неверный, поскольку этот набор правил признает недействительными некоторые значения по умолчанию, которые обычно вводят пользователи. После стандартизации это значение не будет использовано для объединения в блоки или для сопоставления. Это уменьшает вероятность ложноположительного вывода на основе неверного номера.

Задание по стандартизации данных

На следующей схеме показано задание, которое стандартизирует индийские имена и адреса из файла с 52 строками.

Рисунок 7. Задание продукта InfoSphere QualityStage, стандартизирующее индийские имена и адреса
Image shows InfoSphere QualityStage job that standardizes 52 rows of Indian name and address
Image shows InfoSphere QualityStage job that standardizes 52 rows of Indian name and address

На показанной выше схеме элементы Name, PAN_Number и Phone стандартизируются на стадии Standardize_Name_PAN_Phone. Адрес стандартизируется на стадии StandardizeAddress, которая представляет собой общий контейнер для индийских адресов. После этого результаты обеих ветвей объединяются. Заданию Match (сопоставление) на входе требуются стандартизированные данные и частота (генерация этих данных производится здесь же).

Примечание. Контейнер IndiaAddressSharedContainer, используемый на стадии StandardizeAddress, входит в набор правил для Индии.

Генерация частоты

Продукт InfoSphere QualityStage работает по принципу вероятностного сопоставления двух записей. Если два поля совпадают, им присваиваются определенные весовые коэффициенты. Ниже показан пример сопоставления двух записей и присвоенных весовых коэффициентов.

Таблица 3. Стандартизированное представление имени и адреса
СтолбецИмяФамилияНомер входаРайонГородПочтовый индекс
Add1AkshayKazangianD 123Greater Kailash - 2New Delhi110048
Add2AkshayKazangianD 123Greater Kailash - 2New Delhi110048
Weight+4+20+7+4+3+5

Продукт InfoSphere QualityStage по частоте соответствующего значения данных выявляет степень его распространенности и присваивает повышенный весовой коэффициент (Weight), если совпадают редкие значения, и сниженный весовой коэффициент, если совпадающие значения встречаются чаще. В результате более низкий весовой коэффициент присваивается совпадениям с распространенными именами, а более высокий весовой коэффициент – совпадениям с необычными именами. Аналогично, совпадение по полу получает более низкий весовой коэффициент, чем совпадение по номеру социального страхования. В показанном выше примере предположим, что имеется 1 миллион записей и что существует только две записи с фамилией KAZANGIAN. Продукт InfoSphere QualityStage принимает это во внимание и на основе частоты автоматически увеличивает вероятность совпадения, присваивая результатам сравнения более высокий вес.

Задание по генерации частоты

На следующем рисунке показан фрагмент предшествующего задания стандартизации данных, генерирующий частоту. Стандартизированные данные пропускаются через стадию MatchFrequency, чтобы сгенерировать частоты для стандартизированных данных. Если спецификация сопоставления выбирается на стадии генерации частоты, то частота будет генерироваться только для тех столбцов, которые будут использованы для совпадающих записей.

Рисунок 8. Задание по генерации частоты
Mmage shows InfoSphere QualityStage job generating frequency
Mmage shows InfoSphere QualityStage job generating frequency

Создание спецификации сопоставления

Чтобы сравнивать записи, нужно с помощью инструмента InfoSphere QualityStage Match Designer сконфигурировать конкретные условия сопоставления. Инструмент Match Designer позволяет выбирать столбцы, подлежащие сравнению в процессе сопоставления. В состав инструмента Match Designer входит большое количество компонентов, которые можно настроить для получения оптимального результата. Самыми важными из них являются следующие: Blocking Column, Matching Column, Match Pass и Cutoff.

Столбцы типа Blocking Column

Термин blocking (объединение в блоки) в данном случае означает, что входная информация делится на взаимоисключающие группы (так называемые блоки). Этот подход подобен группированию носков одного цвета, которое сокращает количество пар, подлежащих сравнению для выявления дубликата.

Объединение в блоки обычно реализуется путем автоматического разделения файлов на основе значений одного или нескольких полей. Размер пула кандидатов, создаваемого в результате объединения в блоки, необходимо сбалансировать. Если сделать критерии объединения в блоки слишком консервативными (небольшие блоки), некоторые совпадения будут пропущены. Если сделать критерии объединения в блоки слишком свободными (большие блоки с тысячами записей в блоке), время исполнения увеличится. Рекомендуется, что любой блок содержал не более 1000 записей.

При выборе полей для объединения в блоки руководствуйтесь следующими инструкциями.

  • Выбирайте поля, которые содержат достоверные данные, надлежащим образом заполнены и имеют хорошее частотное распределение значений. Эту информацию можно получить в результате анализа данных.
  • Используйте несколько полей в блоке.
  • Продвигайтесь от самого специфического на первом проходе (Pass) к более "мягкому" в последующих проходах. Ваш первый проход должен распознать наиболее очевидные совпадения.

Команды типа Match Command

Вернемся к примеру с носками. После того, как вы объединили в блок все подобные носки, нужно сравнить каждый носок с каждым другим носком. Это сравнение носков производится лишь в пределах конкретного блока на основе размера, цвета, бренда и других атрибутов остальных носков. Аналогично, при сравнении двух адресов каждый выбранный столбец из сопоставляемых столбцов сравнивается с оставшимся адресом в пределах блока. Например, номер входа, название улицы и название города из одной записи сравнивается с номером входа, названием улицы и названием города из другой записи, а соответствующие весовые коэффициенты (так называемые веса согласованности или рассогласованности) генерируются на основе результата каждого сравнения.

При проведении сравнения эти команды Match Command могут использовать один из более 20 имеющихся типов сравнения, которые выбираются в инструменте Match Designer. Сравнение может осуществляться либо как сравнение по точному совпадению (exact-match comparison), при котором не допускается никаких различий, либо как устойчивое к ошибкам сравнение (error-tolerant comparison), при котором можно задать порог чувствительности, определяющий допустимые различия. После сравнения каждого выбранного столбца из разных записей стадия Match добавляет весовые коэффициенты, присваиваемые каждому сравнению столбцов, и генерирует составной весовой коэффициент для записи. Чем больше составной весовой коэффициент, тем лучше согласованность между двумя записями.

Сопоставление векторов

В редких случаях возникает необходимость сравнить значения в разных столбцах, чтобы найти совпадение. Например, в записи имеется два столбца телефонных номеров: Phone0 и Phone1. В этом случае вы улучшите получаемый результат, если сможете осуществлять сравнение между столбцами. Например, можно сравнить значение Phone0 из одной записи со значением Phone0, а также со значением Phone1 из второй записи. Продукт InfoSphere QualityStage обеспечивает эту возможность благодаря механизму под названием сопоставление векторов. С помощью стадии Make Vector можно создать вектор с именем PhoneNumber, содержащий элементы Phone0 и Phone1. Затем этот вектор можно использовать в команде Match Command.

В следующем задании стандартизации стадия Make Vector используется для создания вектора PhoneNumber из Phone0 и Phone1. Phone0 и Phone1 – это стандартизированные телефонные номера, сгенерированные из входной информации.

Рисунок 9. Задание стандартизации генерирует вектор для телефонного номера
Image shows InfoSphere QualityStage job demonstrating use of Make                     vector stage to create  vector for two phone numbers in the input
Image shows InfoSphere QualityStage job demonstrating use of Make vector stage to create vector for two phone numbers in the input

На показанном ниже холсте команды Match Command вектор PhoneNumber обрабатывается механизмом сопоставления векторов с целью сравнения между столбцами.

Рисунок 10. Команда Match Command для сравнения векторов
Image demonstrates the usage of match designer tool to compare two vector columns
Image demonstrates the usage of match designer tool to compare two vector columns

Проходы типа Match Pass

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

Cutoff-значения

Match cutoff (отсечка совпадения) и clerical cutoff (организационная отсечка) – это пороговые значения, которые определяют, как категоризировать "взвешенные" пары записи. Cutoff-значения (значения отсечки) основаны на составном весовом коэффициенте, присвоенном каждой паре записей. Присвоение этого весового коэффициента автоматически осуществляет механизм сопоставления (match engine). При желании это значение можно переопределить. Все пары записей, у которых составной весовой коэффициент равен значению отсечки сопоставления (Match cutoff) или превышает его, считаются дубликатами. Пары записи, у которых составной весовой коэффициент ниже организационной отсечки (clerical cutoff), считаются несоответствующими. Записи, у которых составной весовой коэффициент находится между этими двумя значениями, считаются организационными записями (clerical record).

Cutoff-значения оказывают непосредственное влияние на оценку пары записей на предмет совпадения. Поэтому практическая бизнес-цель состоит в определении того, насколько агрессивно или консервативно следует задавать эти значения. Например, если вы выполняете сопоставление с одним источником (one-source match) с целью создания списка адресатов для каталога товаров, то отсечке совпадения вполне можно присвоить менее высокое значение, чем в случае медицинских карт. При выполнении начального прогона обычно задается нулевая отсечка совпадения.

Спецификация сопоставления для индийских имен и адресов

Наша тестовая выборка индийских адресов содержала преимущественно городские адреса. Эти адреса включают хорошо заполненные поля с номером входа и почтовым индексом. На основе этой информации в инструменте Match Designer были созданы следующие столбцы типа Blocking Column. Обратите внимание, что результаты в правой части – это фактические результаты, сгенерированные, когда данные выборки были предоставлены в качестве входной информации. Записи группируются как дубликаты на основе ключа SetID, который задание Match продукта InfoSphere QualityStage автоматически генерирует для группирования дубликатов.

Проход 1

Рисунок 11. Проход 1 (Match Pass) создает блоки по имени, второму имени, фамилии, номеру входа и почтовому индексу
Image demonstrates the Pass 1 of the match specification that is                     created using the Match Designer tool
Image demonstrates the Pass 1 of the match specification that is created using the Match Designer tool

Необходимо отметить, что для того, чтобы значения FirstName, MiddleName, LastName, DoorNumber и PinCode стали частью одного и того же блока, они должны присутствовать и быть идентичными. Сравнения осуществляются в рамках каждого из этих блоков на основе команд Match Command. Данный проход способен сравнивать записи, у которых имеются значения FirstName (имя), MiddleName (второе имя) и LastName (фамилия) (например, Subhash Chandra Bose) и адреса которых имеют значения DoorNumber (номер входа) и PinCode (почтовый индекс). Если бы мы создавали блоки только по именам и фамилиям, то включение в блок распространенных индийских имен, таких как "Amit Gupta," могло бы потенциально привести к переполнению этого блока и к увеличению продолжительности исполнения. Начальные проходы рекомендуется осуществлять в более строгом режиме, чем последующие проходы.

Проход 2

Рисунок 12. Проход 2 создает блоки по имени, фамилии, номеру входа и почтовому индексу
Image demonstrates the Pass 2 of the match specification created                     using the Match Designer tool
Image demonstrates the Pass 2 of the match specification created using the Match Designer tool

Проход 1 требовал, чтобы запись содержала второе имя, потому нужен еще один проход для сопоставления записей, в которых отсутствует второе имя. Этот проход создает блоки по имени, фамилии, номеру входа и почтовому индексу. В связи с этим возникает вопрос, можно ли оставить только Проход 2 и отказаться от Прохода 1? Использование двух проходов сохраняет размеры блока на управляемом уровне. Кроме того, такие записи как "Mohammed Yonis Khan" и "Mohammad Asif Khan" имеют одинаковые имя и фамилию. В отсутствие Прохода 1 такие записи могли быть преждевременно расценены как дубликаты.

Проход 3

Рисунок 13. Проход 3 создает блоки по фонетической версии имени, номеру входа и почтовому индексу
Image demonstrates the Pass 3 of the match specification                      created using the Match Designer tool
Image demonstrates the Pass 3 of the match specification created using the Match Designer tool

В процессе стандартизации были сгенерированы фонетические версии важнейших полей. Проход 3 использует эти столбцы с фонетическими версиями имен и фамилий для объединения в блоки. Это обеспечивает обработку ситуаций с преднамеренными или случайными ошибками при вводе в запись имен и фамилий.

Проход 4

Рисунок 14. Проход 4 создает блоки по имени, номеру входа и почтовому индексу
Image demonstrates the Pass 4 of the match specification created                     using the Match Designer tool
Image demonstrates the Pass 4 of the match specification created using the Match Designer tool

Проход 2 создает блоки по записям, имеющим имя и фамилию. Однако некоторые имена в Южной Индии пишутся с инициалами перед именем. Например, P.J.V.S. Prasad. Для обработки таких записей создается Проход 4.

Проход 5

Рисунок 15. Проход 5 создает блоки по фамилии, номеру входа и почтовому индексу
Image demonstrating the Pass 5 of the match specification that is                     created using the Match Designer tool
Image demonstrating the Pass 5 of the match specification that is created using the Match Designer tool

В предшествующих проходах не сравнивались ситуации, когда кто-либо поместил инициалы перед фамилией — например, M.K. Agarwal. В данном проходе производится сравнение таких ситуаций, однако это создает иную проблему. В одной семье жена и мужа обычно имеют одинаковые фамилии, адрес и, возможно, номер телефона. Соответственно, это может порождать ложноположительные результаты, если в столбцы типа Blocking Column не включено имя. Эта проход потенциально способен посчитать дубликатами мужа и жену (например, Anirban Mandal и Nioti Mandal), которые имеют одинаковый адрес. Чтобы преодолеть эту проблему, можно увеличить весовой коэффициент рассогласованности имени в общей оценке сопоставления. Это также можно сделать в инструменте Match Designer. В показанном выше примере эти две сущности были признаны совпадающими, но лишь как пара типа clerical pair (организационная пара). Это означает, что инструмент нуждается во вмешательстве человека, чтобы принять решение о наличии/отсутствии реального совпадения.

Проход 6

Рисунок 16. Проход 6 создает блоки по уникальному идентификатору (в данном случае, по номеру PAN)
Image demonstrates the Pass 6 of the match specification created                     using the Match Designer tool
Image demonstrates the Pass 6 of the match specification created using the Match Designer tool

Как показано на рис. 16, Проход 6 создает блоки по уникальному идентификатору. Что произойдет, если многие из этих записей будут, например, иметь значение по умолчанию 99999999 или значение NULL? Не приведет ли это к неправильной группировке? Нет, поскольку используемый в данном случае идентификатор PAN имеет стандартизированное корректное значение. Неверные значения PAN были устранены на предшествующем шаге стандартизации. Но почему эти две записи, показанные на рис. 16, не были идентифицированы как дубликаты на предыдущих шагах? Причина этого состоит в том, что столбцы типа Blocking Column для предыдущих проходов исходили из предположения, что записи имеют значения номера входа и почтового индекса. Поскольку в одной из вышеуказанных записей отсутствовал номер входа или почтовый индекс, эти записи не были включены ни в один из блоков.

Из показанных выше представлений Match Designer очевидно, что этот инструмент используется не только для создания спецификации сопоставления, но и для тестирования каждого прохода. Исполнение этих проходов в задании Match продукта InfoSphere QualityStage позволяет обнаруживать дубликаты и отношения между данными, даже в отсутствие уникальных идентификаторов или значений других данных.

Создание задания Match продукта InfoSphere QualityStage

Задание Match продукта InfoSphere QualityStage принимает в качестве входной информации стандартизированные данные и распределения частот, а затем выполняет следующие действия.

  • Распознает дублирующиеся записи в одном или нескольких источниках данных
  • Распознает записи, который требуют процедуры clerical review (анализ, выполняемый человеком)
  • Генерирует статистику для сопоставления
  • Обеспечивает создание групп совпадений по нескольким источникам данных – как при наличии, так и при отсутствии у них заранее определенного ключа

Два типа стадии Match

Продукт InfoSphere QualityStage поддерживает два типа сопоставления. Один из этих типов находит дубликаты в одиночном источнике, а другой сравнивает два источника данных на предмет совпадений.

Рисунок 17. Выбор типа сопоставления в инструменте Match Designer
Image shows the various match types that you can select from match designer tool

Когда вы создаете спецификацию сопоставления, которая была описана ранее, можно выбрать любой из этих двух типов сопоставления, в том числе их разновидности.

Стадия One-Source Match

Стадия One-Source Match (сопоставление с использованием одного источника) работает с единственным набором входных данных. Она группирует записи со схожими атрибутами во входной информации. Спецификация сопоставления, созданная на предыдущем шаге, является примером сопоставления с использованием одного источника. Другой пример – необходимость устранения дубликатов при консолидации списков адресатов, полученных из нескольких источников. Имеется несколько типов сопоставления с использованием одного источника. В спецификации сопоставления, созданной на предыдущем шаге, используется тип по умолчанию, а именно: One-source Dependent. В этом случае дубликаты удаляются из кандидатов на сопоставление в последующих проходах. Например, если записи Record1, Record2 и Record3 считаются дубликатами в Проходе 1, то эти дублирующиеся записи не рассматриваются в последующих проходах, а записи типа Master Record и несовпадающие записи передаются на следующий проход.

Стадия Two-Source Match

Стадия Two-Source Match (сопоставление с использованием двух источников) сопоставляет данные из двух наборов данных (справочные данные и источник). При таком сопоставлении определяется, является ли объект из существующей базы данных организации дубликатом нового добавляемого объекта. Такие операции, как lookup, join и merge, также способны находить некоторые дубликаты, однако методики на их основе не обладают возможностями вероятностного сопоставления, которыми обладает стадия Two-Source Match.

При создании задания Match на стадии Match можно переопределить выбранный типа сопоставления, который был задан при создании спецификации сопоставления.

Задание Match

На следующем рисунке показано задание One-Source Match. На вход этого задания поступают стандартизированные данные и распределение частоты.

Рисунок 18. Задание One-Source Match продукта InfoSphere QualityStage
Image demonstrates one-source match job
Image demonstrates one-source match job

Задание One-Source Match генерирует сопоставленные данные, состоящие из следующих групп записей.

  • Match — Записи типа Master Record (главная запись), предназначаемые для последующих проходов.
  • Clerical— Дубликаты, которые нуждаются в анализе, выполняемом человеком.
  • Duplicate — Дубликаты, превышающие значение Match cutoff.
  • Nonmatched — Записи, не падающие в категории Match, Duplicate или Clerical. Они также называются остатками (residuals) и рассматриваются в качестве входных данных для каждого последующего прохода.

Кроме того, для каждого прохода Match Pass это задание генерирует статистику сопоставления, сводную статистику о результатах сопоставления и статистику о процессе сопоставления.

На следующем рисунке показаны свойства стадии One-source Match. На этом экране требуется указать значение Match Specification (спецификация сопоставления). Кроме того, на этом экране можно выбрать или переопределить тип сопоставления.

Рисунок 19. Свойства стадии One-source Match
Figure shows properties of one-source match stage
Figure shows properties of one-source match stage

Ниже показаны результирующие данные после исполнения задания One-source Match.

Рисунок 20. Результаты исполнения задания One-source Match
Image displays the                     result of one-source match job
Image displays the result of one-source match job

Первые четыре столбца выходных данных содержат важную информацию о процессе сопоставления:

  • qsMatchSetID — Значение в этом столбце будет идентично для каждой строки в наборе дубликатов. Это поле используется для группирования дубликатов.
  • qsMatchType — Это значение идентифицирует тип записи (match (MP), duplicate (DA), clerical (CP) или non-match (RA)).
  • qsMatchPassNumber — Это значение идентифицирует номер прохода, в котором был найден дубликат. Записям, не имеющим дубликатов, присваивается значение 0 (с помощью стадии Transformer в задании Match).
  • qsMatchWeight — Составной весовой коэффициент записи, подвергнутой сопоставлению.

Следующие шаги после обнаружения дубликатов

Продукт InfoSphere QualityStage предоставляет возможности очистки данных, помогающие гарантировать качество и непротиворечивость этих данных путем стандартизации, валидации, сопоставления и (опционально) слияния информации. Поля, не соответствующие стандартам загрузки, выявляются и, возможно, отфильтровываются, поэтому в главную запись данных (master data record) загружается только наилучшее представление данных. Отсутствующие значения в записи могут быть сгенерированы в ходе стандартизации данных. Кроме того, отсутствующие значения могут быть заполнены значениями из соответствующих записей, идентифицированных как группа на стадии Match. Все это позволяет сформировать всеобъемлющую и достоверную информацию для использования многочисленными потребителями, включая хранилища данных, или для загрузки в аналитические представлени.

Заключение

Из этого учебного пособия вы узнали о необходимости отыскания дубликатов в данных. Вы также изучили разные шаги по отысканию дубликатов в данных и узнали об их реализации с помощью продукта InfoSphere QualityStage. В разделе Загрузка представлена ссылка на акселераторы для Индии, Канады, Германии и Японии, которые вы можете использовать для быстрого начала своего проекта по обеспечению качества данных.

Благодарности

Создание акселератора для Германии осуществляет Манфред Водегел (Manfred Vodegel) из отделения IBM Germany. Создание акселератора для Японии осуществляет Юсуке Ниситани (Yusuke Nishitani) из отделения IBM Japan. Уолтер Крокетт мл. (Walter Crockett, Jr.) из отделения IBM US потратил много времени на редактирования данного материала, и я выражаю ему благодарность за его ценный вклад. Выражаю особую благодарность Хизер Симпсон (Heather Stimpson, руководитель разработки InfoSphere Data Quality) и Роберту Диксону (Robert Dickson, специалист по технической поддержке международных продаж) за их постоянное руководство и советы по формированию облика этого учебного пособия..


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=1032900
ArticleTitle=Выявление дубликатов в данных с помощью продукта InfoSphere QualityStage
publish-date=06022016