Очистка данных: проблемы и актуальные подходы

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

1. Введение

Очистка данных (data cleaning, data cleansing или scrubbing) занимается выявлением и удалением ошибок и несоответствий в данных с целью улучшения качества данных. Проблемы с качеством встречаются в отдельных наборах данных - таких, как файлы и базы данных, - например, как результат ошибок при вводе, утери информации и других загрязнений данных. Когда интеграции подлежит множество источников данных, например - в Хранилищах, интегрированных системах баз данных или глобальных информационных Интернет-системах, - необходимость в очистке данных существенно возрастает. Это происходит оттого, что источники часто содержат разрозненные данные в различном представлении. Для обеспечения доступа к точным и согласованным данным необходима консолидация различных представлений данных и исключение дублирующейся информации.

Хранилища данных требуют и одновременно обеспечивают всестороннюю поддержку очистки данных. Они загружают и постоянно обновляют огромные объемы данных из различных источников, поэтому вероятность попадания в них "грязных данных" весьма высока. Более того, Хранилища данных используются для принятия решений, следовательно, чтобы некорректные данные не привели к некорректным выводам, просто жизненно необходимо проводить корректировки таких данных. Например, дублирующаяся или утраченная информация может стать причиной некорректной или неадекватной статистики ("мусор на входе - мусор на выходе "). Ввиду большого спектра возможных несоответствий в данных и большого объема данных их очистка считается одной из самых крупных проблем в технологии Хранилищ данных. В процессе так называемого ETL (извлечения, преобразования, загрузки - extraction, transformation, loading), показанного на Рис. 1, дальнейшее преобразование данных связано с трансляцией схемы/данных и интеграцией, а также с фильтрацией и агрегацией данных, предназначенных для Хранилища данных. Как показано на Рис. 1, вся очистка данных обычно выполняется в отдельной области подготовки данных до загрузки преобразованных данных в Хранилище. Существует множество средств с различной функциональностью, предназначенных для поддержки подобных задач, однако часто достаточно большой объем работы по очистке и преобразованию приходится выполнять вручную или низкоуровневыми программами, трудными для написания и использования.

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

Метод очистки данных должен удовлетворять ряду критериев. Во-первых, он должен выявлять и удалять все основные ошибки и несоответствия, как в отдельных источниках данных, так и при интеграции нескольких источников. Метод должен поддерживаться определенными инструментами, чтобы сократить объемы ручной проверки и программирования, и быть гибким в плане работы с дополнительными источниками. Далее, очистка данных не должна производиться в отрыве от связанных со схемой преобразования данных, выполняемых на основе сложных метаданных. Функции маппирования для очистки и других преобразований данных должны быть определены декларативным образом и подходить для использования в других источниках данных и в обработке запросов. Инфраструктура технологического процесса должна особенно поддерживаться для Хранилищ данных, обеспечивая эффективное и надежное выполнение всех этапов преобразования данных для множества источников и больших наборов данных. Поскольку большая часть исследований касалась трансляции и интеграции схемы, исследовательское сообщество уделяло совсем мало внимания очистке данных. Ряд исследовательских групп занимаются общими проблемами, так или иначе связанными, в том числе, и с очисткой данных - например, специфическими подходами к data mining и преобразованию данных на основании сопоставления схемы. В последнее время ряд исследований коснулись более сложного единого подхода к очистке данных, касающегося ряда аспектов преобразования, специфических операторов и их реализации. В данной статье предлагается обзор проблем в области очистки данных и их решение. Следующий раздел посвящен классификации проблем, раздел 3 рассматривает основные подходы к очистке, использованные в современных средствах и исследовательской литературе. Раздел 4 представляет собой обзор коммерческих средств очистки данных, в том числе и инструментов ETL. Раздел 5 подводит итог изложенному.

2. Проблемы очистки данных

Этот раздел классифицирует основные проблемы в области очистки данных, подлежащие решению при очистке и преобразовании данных. Как будет видно далее, эти проблемы тесно связаны и поэтому должны решаться в комплексе. Преобразование данных требуется для поддержки любых изменений в структуре, представлении или содержании данных. Эти преобразования становятся необходимы в разных ситуациях, например при изменении структуры данных, переходе на новую информационную систему или в случае, когда нужно интегрировать множественные источники данных. Как показано на Рис. 2 мы проводим четкий водораздел между проблемами с одним и со множеством источников и между проблемами со схемой и с элементами данных. Проблемы уровня схемы, разумеется, отражаются и в элементах данных; они решаются с помощью ее улучшения, трансляции и интеграции схемы данных. С другой стороны, проблемы уровня элемента данных связаны с ошибками и несоответствиями в содержимом текущих данных, незаметных на уровне схемы. Они-то и являются основной целью очистки. Рис. 2 отражает также некоторые частичные проблемы для различных случаев. Хотя этого и нет на Рис. 2, проблемы в отдельных источниках с увеличивающейся вероятностью встречаются и в случае множества источников, - и это помимо специфических проблем, характерных для таких случаев.

2.1. Проблемы отдельных источников данных

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

Для проблем и уровня схемы и уровня элемента данных можно разделить различные проблемные области: атрибут (поле), запись, тип и источник записи; примеры для различных случаев показаны в Таблицах 1 и 2. Следует заметить, что уникальность ограничений, определенная на уровне схемы, не защищает от дублирования элементов данных, например, если информация по одному и тому же объекту реального окружения вводится дважды, но с различными значениями атрибута (см. пример в Таблице 2).

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

2.2. Проблемы множественных источников данных

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

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

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

Потребитель (источник 1)

Клиент (источник 2)

Потребители (объединение целевых данных с очищенными)

Хотя оба источника из примера на Рис. 3 представлены в реляционном формате, однако они отражают конфликты схемы и данных. На уровне схемы существуют конфликты имен (синонимы Потребитель/Клиент, Идентификатор/Номер, Пол/Род) и структурные конфликты (различные представления имен и адресов). На уровне элемента данных можно наблюдать различные представления рода ("0"/"1" против "F"/"M") и вероятно дублирующиеся записи (Кристен Смит). Последнее также позволяет увидеть, что, несмотря на то, что Идентификатор/Номер оба являются идентификторами, характерными для конкретных источников, их содержимое не сравнимо между собой; различные номера (11/493) могут относиться к одному и тому же лицу, а различные лица могут иметь один и тот же номер (24). Решение данных проблем требует одновременно и интеграции схемы и очистки данных; третья таблица демонстрирует возможное решение. Следует отметить, что конфликты схемы необходимо урегулировать в первую очередь, чтобы обеспечить возможность очистки данных, в особенности - выявление дубликатов на основе унифицированного представления имен и адресов и сопоставления значений Род/Пол.

3. Методы очистки данных

В целом, очистка данных включает несколько этапов:

• Анализ данных: для выявления подлежащих удалению видов ошибок и несоответствий, необходим подробный анализ данных. Наряду с ручной проверкой данных или их шаблонов, следует использовать аналитические программы для получения метаданных о свойствах данных и выявления проблем качества данных.
  
  
• Определение порядка и правил преобразования данных: В зависимости от числа источников данных, степени их неоднородности и загрязненности данных, они могут требовать достаточно обширного преобразования и очистки. Иногда для отображения источников для общей модели данных используется трансляция схемы; для Хранилищ данных обычно используется реляционное представление. Первые шаги по очистке данных могут скорректировать проблемы отдельных источников данных и подготовить данные для интеграции. Дальнейшие шаги должны быть направлены на интеграцию схемы/данных и устранение проблем множественных элементов, например - дубликатов. Для Хранилищ в процессе работы по определению ETL должны быть определены методы контроля и поток данных, подлежащий преобразованию и очистке (Рис. 1).
  
  Преобразования данных, связанные со схемой так же, как и этапы очистки, должны, насколько возможно, определяться с помощью декларативного запроса и языка маппирования, обеспечивая, таким образом, автоматическую генерацию кода преобразования. К тому же, в процессе преобразования должна существовать возможность запуска написанного пользователем кода очистки и специальных средств. Этапы преобразования могут требовать обратной связи с пользователем по тем элементам данных, для которых отсутствует встроенная логика очистки.
  
  
• Подтверждение: Правильность и эффективность процесса и определений преобразования должны тестироваться и оцениваться, например, на примере или копии данных источника, - чтобы выяснить, необходимо ли как-то улучишь эти определения. При анализе, проектировании и подтверждении может потребоваться множество итераций, например, ввиду того, что некоторые ошибки становятся заметны только после определенных преобразований.
  
  
• Преобразования: выполнение преобразований либо в процессе ETL для загрузки и обновления Хранилища данных, либо при ответе на запросы по множеству источников.
  
  
• Противоток очищенных данных: После того, как ошибки (отдельного источника) удалены, очищенные данные должны заместить загрязненные данные в исходных источниках, чтобы улучшенные данные попали и в унаследованные приложения и в дальнейшем при извлечении не требовали дополнительной очистки. Для Хранилищ данных очищенные данные находятся в области хранения данных (Рис. 1).

Процесс преобразования, очевидно, требует больших объемов метаданных - например, схем, характеристик данных уровня схемы, определений технологического процесса и др. Для согласованности, гибкости и упрощения использования в других случаях, эти метаданные должны хранится в репозитории на основе СУБД. Для поддержки качества данных подробная информация о процессе преобразования должна записываться как в репозиторий, так и в трансформированные элементы данных, в особенности информация о полноте и свежести исходных данных и происхождения информации о первоисточнике трансформированных объектов и произведенных с ними изменениях. Например, на Рис. 3 производная таблица Потребители содержит атрибуты Идентификатор и Номер, позволяя проследить путь исходных записей.

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

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

Метаданные, отраженные в схемах, обычно недостаточны для достижения качества данных, соответствующего источнику, особенно если ограничений целостности совсем немного. Поэтому для получения реальных (модернизированных) метаданных с характеристиками данных или необычными моделями значений важно анализировать реальные примеры. Такие метаданные облегчают поиск проблем с качеством данных. Более того, они могут эффективно способствовать идентификации соответствий атрибутов между исходными схемами (сопоставления схем) в зависимости от того, какие автоматические преобразования данных производятся. Существует два связанных между собою метода анализа: профилирование данных и data mining. Профайлинг данных ориентирован на примерный анализ отдельных атрибутов. При этом происходит получение такой информации, как тип, длина, спектр значений, дискретные значения данных и их частота, изменение, уникальность, наличие неопределенных значений, типичных строковых моделей (например, для номеров телефонов) и др., что позволяет обеспечить точное представление различных аспектов качества атрибута. Таблица 3 показывает примеры выявления проблем качества данных с помощью метаданных.

Data mining помогает найти специфические модели данных в больших наборах данных - например, отношения между несколькими атрибутами. Именно на это направлены так называемые описательные модели data mining, включая группировку, обобщение, поиск ассоциаций и последовательностей. При этом могут быть получены ограничения целостности в атрибутах - например, функциональные зависимости или характерные для конкретных приложений бизнес-правила, - которые можно использовать для восполнения утраченных и исправления недопустимых значений, а также для выявления дубликатов записей в источниках данных. Например, правило объединения с высокой вероятностью может предсказать проблемы с качеством данных в элементах данных, нарушающих это правило. Таким образом, 99%-ная вероятность правила "итого=количество*единицу " демонстрирует несоответствие и потребность в более детальном исследовании для 1% записей.

3.2. Определение преобразований данных

Процесс преобразования данных обычно состоит из множества шагов, каждый из которых может выполнять и преобразования уровня схемы и преобразования уровня элемента данных (маппирование). Чтобы обеспечить системе преобразования и очистки данных возможность генерации программного кода для преобразования и тем самым уменьшить объем самопрограммирования, следует описать необходимые преобразования на соответствующем языке, например, поддерживаемом графическим интерфейсом пользователя. Различные средства ETL (см. Раздел 4) содержат такую возможность, поддерживая собственные языки правил. Более общий и гибкий подход заключается в применении стандартного языка запросов SQL для выполнения преобразований данных и использования возможностей расширений языков приложений, в особенности функций, определенных пользователем (UDFs), поддерживаемых в SQL:99. UDFs могут быть реализованы в SQL или на языке программирования общего назначения, содержащем вложенные операторы SQL. Они позволяют реализовывать широкий спектр преобразований данных и поддерживают простое использование различных преобразований и обработки запросов. Более того, их выполнение СУБД может снизить стоимость доступа к данным. И, наконец, UDFs являются частью стандарта SQL:99 и должны (в конечном счете) быть переносимыми на множество других платформ и СУБД.

CREATE VIEW Customer2
(LName, FName, Gender,
Street, City, State, ZIP, CID)
AS
SELECT LastNameExtract(Name), FirstNameExtract (Name),
Sex, Street, CityExtract (City),
StateExtract (City),
ZIPExtract (City), CID
FROM Customer

Рис. 4 показывает один из шагов преобразования, определенный в SQL:99. Этот пример связан с Рис. 3 и охватывает часть необходимых преобразований данных, применяющихся к первому источнику. Эти преобразования определяют представление, согласно которому могут выполняться последующие маппирования. Преобразования выполняет изменение схемы, путем добавления новых атрибутов, полученных расщеплением имени и адреса источника. Необходимые извлечения данных достигаются с помощью UDFs (показаны жирным шрифтом). Реализации UDF могут содержать логику очистки, например, для удаления неверного написания наименований городов или восстановления утраченных индексов. UDFs по-прежнему могут предполагать существенные затраты на реализацию и не поддерживать все необходимые преобразования схемы. В особенности простые и часто используемые функции, - такие, как расщепление или слияние атрибутов, - поддерживаются не всегда, поэтому требуют повторной реализации в подходящем для приложения виде (см. специфические функции извлечения на Рис. 4). Более сложные реструктуризации схемы (например, свертывание и развертывание атрибутов) не поддерживаются вообще. Для полной поддержки связанных со схемой преобразований, необходимы расширения языка - такие, как предложение SchemaSQL. Очистка данных на уровне элемента данных может также выиграть от использования специализированных расширений языка - таких, как оператор Match, поддерживающий "приблизительные объединения" (см. ниже). Системная поддержка для таких мощных операторов может существенно упростить программирование преобразований данных.

3.3. Разрешение конфликтов

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

• Извлечение значений из атрибутов свободного формата (расщепление атрибутов): Атрибуты свободного формата часто содержат множество отдельных значений, подлежащих извлечению для повышения точности представления и поддержки последующих этапов очистки - таких, как сопоставление элементов данных и исключение дубликатов. Типичными примерами являются поля имен и адресов (Таблица 2, Рис. 3, Рис. 4). Необходимые на этом этапе преобразования перераспределяют значения в поле для получения возможности перемещения слов и извлекают значения для расщепленных атрибутов.
  
  
• Проверка допустимости и исправления: На этом этапе каждый элемент данных источника данных исследуется на наличие ошибок, а обнаруженные ошибки по мере возможности автоматически исправляются. Проверка орфографии на основе просмотра словаря нужна для идентификации и исправления ошибок в написании слов. Более того, словари географических наименований и почтовых индексов помогают корректировать адресные данные. Атрибутивные зависимости (дата рождения - возраст, общая стоимость - цена за шт., город - региональный телефонный код, и т.д.) могут использоваться для выявления проблем и замены утраченных или исправления неверных значений.
  
  
• Стандартизация: Для соотнесения и интеграции элементов данных, значения атрибутов следует преобразовать в согласованный и унифицированный формат. Например, записи о дате и времени должны быть оформлены в специальном формате, имена и другие символьные данные должны конвертироваться либо в прописные, либо в строчные буквы, и т.д. Текстовые данные могут быть сжаты и унифицированы с помощью выявления основы, удаления префиксов, суффиксов и вводных слов. Более того, аббревиатуры и зашифрованные схемы подлежат согласованной расшифровке с помощью специального словаря синонимов или применения предопределенных правил конверсии.

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

В простейшем случае для каждой записи существует идентификационный атрибут или комбинация атрибутов, которую можно использовать для сопоставления записей, например, если различные источники имеют общий первичный ключ или если существуют различные другие общие уникальные атрибуты. Сопоставление элементов данных между различными источниками достигается за счет стандартного объединения по идентифицирующему(им) атрибуту(ам). В случае отдельного набора данных сопоставления могут определяться сортировкой по идентифицирующему атрибуту и проверкой согласованности соседних записей. В обоих случаях эффективная реализация может достигаться даже для больших наборов данных. К сожалению, без общего ключа и при наличии загрязненных данных такие прямые методы часто слишком ограничены. Для определения большинства или даже всех сопоставлений в "нечетком сопоставлении" (приблизительном объединении) необходимо найти сходные записи, основанные на правиле сопоставления, например, декларативно определенные или реализованные с помощью определенных пользователем функций. Например, такое правило может утверждать, что записи по некоторому лицу, скорее всего, согласованы, если согласованы имя и фрагменты. Степень схожести между записями часто измеряется числовыми значениями между 0 и 1, обычно зависящими от характеристик приложения. Например, различные атрибуты в правиле сопоставления могут придавать различное значение общему уровню сходства. Для строковых компонент (например, имени потребителя, наименования компании и др.) могут оказаться полезными точное сопоставление и неявные методы, основанные на групповых символах, частоте знаков, редакторских расстояниях, расстояниях клавиатуры и фонетического сходства (soundex). Общим подходом к сопоставлению текстовых данных является использование общей метрики извлечения информации. WHIRL отражает многообещающее представление этой категории с использованием косинусного расстояния в модели векторного пространства для определения степени сходства между текстовыми элементами.

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

4. Поддержка инструментов

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

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

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

4.1. Средства анализа и модернизации данных

Согласно классификации, данной в разделе 3.1, средства анализа данных могут быть разделены на средства профайлинга данных и средства data mining.

4.2. Специальные средства очистки

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

• Очистка специфической области: Имена и адреса записаны в различных источниках и обычно имеют множество элементов. И поиск соответствий для потребителя имеет большое значение для управления отношениями с клиентами. Ряд коммерческих инструментов, - например, IDCENTRIC (FirstLogic), PUREINTEGRATE (Oracle), QUICKADDRESS (QASSystems), REUNION (PitneyBowes) и TRILLIUM (TrilliumSoftware), - предназначены для очистки именно таких данных. Они содержат методы - например, извлечение и преобразования имен и адресов в отдельные стандартные элементы, проверку допустимости названий улиц, городов и индексов, вместе с возможностями сопоставления на основе очищенных данных. Они включают огромную библиотеку предопределенных правил относительно проблем, часто встречающихся в данных такого рода. Например, модуль извлечение TRILLIUM (парсер) и модуль сопоставления содержат свыше 200000 бизнес-правил. Эти инструменты обеспечивают и возможности настройки или расширения библиотеки правил за счет правил, определенных пользователем для собственных специфических случаев.
  
  
• Исключение дубликатов: Примерами средств для выявления и удаления дубликатов являются DATACLEANSER (EDD), MERGE/PURGELIBRARY (Sagent/QMSoftware), MATCHIT (HelpITSystems) и MASTERMERGE (PitneyBowes). Обычно они требуют, чтобы источник данных уже был очищен и подготовлен для согласования. Ими поддерживается несколько подходов к согласованию значений атрибутов; такие средства, как DATACLEANSER и MERGE/PURGE LIBRARY позволяют также интегрировать правила согласования, определенные пользователем.

4.3. Инструменты ETL

Многие коммерческие инструменты поддерживают процесс ETL для Хранилищ данных на комплексном уровне, например, COPYMANAGER (InformationBuilders), DATASTAGE (Informix/Ardent), EXTRACT (ETI), POWERMART (Informatica), DECISIONBASE (CA/Platinum), DATATRANSFORMATIONSERVICE (Microsoft), METASUITE (Minerva/Carleton), SAGENTSOLUTIONPLATFORM (Sagent) и WAREHOUSEADMINISTRATOR (SAS). Для единообразного управления всеми метаданными по источникам данных, целевым схемам, маппированиям, скриптам и т.д. они используют репозиторий на основе СУБД. Схемы и данные извлекаются из оперативных источников данных как через "родной" файл и шлюзы СУБД DBMS, так и через стандартные интерфейсы - например, ODBC и EDA. Преобразовании данных определяются через простой графический интерфейс. Для определения индивидуальных шагов маппирования обычно существует собственный язык правил и комплексная библиотека предопределенных функций преобразования. Эти средства поддерживают и повторное использование существующих преобразованных решений, например, внешних процедур C/C++ с помощью имеющегося в них интерфейса для их интеграции во внутреннюю библиотеку преобразований. Процесс преобразования выполняется либо системой, интерпретирующей специфические преобразования в процессе работы, либо откомпилированным кодом. Все средства на базе системы (например, COPYMANAGER, DECISIONBASE, POWERMART, DATASTAGE, WAREHOUSEADMINISTRATOR), имеют планировщик и поддерживают технологические процессы со сложными зависимостями выполнения между этапами преобразования. Технологический процесс может также помогать работе внешних средств, например - в специфических задачах очистки - например, таких, как очистка имен/адресов или исключение дубликатов.

Средства ETL обычно содержат мало встроенных возможностей очистки, но позволяют пользователю определять функциональность очистки через собственный API. Как правило, анализ данных для автоматического выявления ошибок и несоответствий в данных не поддерживается. Тем не менее, пользователи могут реализовывать такую логику при работе с метаданными и путем определения характеристик содержимого с помощью функций агрегации (sum, count, min, max, median, variance, deviation,…). Поставляемая библиотека преобразований отвечает различным потребностям преобразования и очистки данных - например, конверсию типов данных (в частности - переформатирование данных), строковые функции (например, расщепление, слияние, замена, поиск по подстроке), арифметические, научные и статистические функции и т.д. Извлечение значений из атрибутов свободного формата автоматизировано не полностью, и пользователю приходится определять разделители, разграничивающие фрагменты значений.

Языки правил обычно охватывают конструкции if-then и case, способствующие обработке исключений в значениях данных - например, неверных написаний, аббревиатур, утраченных или зашифрованных значений и значений вне допустимого диапазона. Эти проблемы могут также решаться с помощью функциональных возможностей по выборке данных из таблиц. Поддержка согласования элементов данных обычно ограничена использованием возможностей объединения и нескольких простых строковых функций соответствия, Например, точного или группового соответствия или soundex. Тем не менее, определенные пользователем функции соответствия полей, так же, как и функции корреляции сходства полей, могут программироваться и добавляться во внутреннюю библиотеку преобразований.

5. Выводы

Несмотря на то, что описанные средства являются достаточно современными, они, тем не менее, не решают всех проблем и все еще требуют дополнительной обработки вручную или дополнительного программирования. Кроме того, они имеют весьма ограниченные возможности взаимодействия (собственные API и представления метаданных). Тем не менее, эти средства демонстрируют нам важность и сложность задач очистки данных.

Автор: Эрхард Рам (Erhard Ram),Хонг Хай До (Hong Hai Do)