В последние несколько лет многие предприятия создают хранилища (и киоски) данных, чтобы выполнять над ними приложения. Используемые технологии хранилищ данных опираются, прежде всего, на средства ETL (extract-transform-load - <<извлечение-преобразование-загрузка>>), моделирование и проектирование баз данных, а также на системы реляционных баз данных. Сегодняшним хранилищам данных присущи три основных недостатка. Это неудовлетворительная обработка <<грязных>> данных, неудовлетворительные производительность и масштабируемость при выполнении операций, основанных на сканировании, а также неудовлетворительный выбор источников данных для загрузки в хранилище данных. В статье анализируются эти три проблемные области и приводятся основные черты подходов к решению проблем.

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

Для создания хранилища данных предприятию в общем случае нужно выполнить следующие шаги:

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

Для хранения информации и управления хранилищами и киосками данных, как правило, используются системы реляционных баз данных (РБД). После создания стабильного хранилища его необходимо регулярно обновлять, чтобы отражать в нем обновления данных в источниках.

После создания хранилища данных предприятие может выполнять над ним одно или несколько приложений. В число приложений обычно входят средства поддержки запросов для генерации отчетов, приложения для управления связями с заказчиками (например, отслеживание маркетинговых кампаний, сегментация заказчиков и анализ поведения заказчиков при совершении покупки и т.д.), анализаторы данных, содержащихся в Web-журналах, приложения добычи данных (например, средства выявления попыток мошенничества), бизнес-аналитика (например, анализ рентабельности) и т.д. Приложения генерируют SQL-запросы, которые передаются системе РБД, управляющей хранилищем данных.

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

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

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

Очевидно, что результаты запросов, добычи данных или бизнес-анализа над хранилищем, содержащим большое число грязных данных, не могут считаться надежными и полезными. Только сейчас предприятия начинают внедрять инструменты очистки данных. Представленные сегодня на рынке средства очистки данных (например, продукты компаний Vality/Ascential Software, Trillium Software и First Logic) помогают выявлять и автоматически корректировать некоторые наиболее важные типы данных, в особенности, имена и адреса людей (с использованием национального каталога имен и адресов). Однако этим средствам предстоит пройти еще долгий путь, поскольку сегодня они не умеют работать со всеми типами грязных данных, и далеко не все компании используют даже имеющиеся средства. Более того, большинство предприятий не внедряет надежные методики и процессы, гарантирующие высокое качество данных в хранилище. Недостаточное внимание, уделяемое качеству данных, обусловлено отсутствием понимания типов и объема грязных данных, проникающих в хранилища; влияния грязных данных, принятие решений и выполняемые действия; а также тем фактом, что продукты очистки данных, представленные на рынке, не слишком хорошо рекламируются или слишком дорого стоят.

Для того чтобы начать уделять необходимое внимание качеству данных в своих хранилищах, предприятиям, прежде всего, нужно разобраться в многообразии возможных грязных данных, источниках их появления и методах их обнаружения и очистки. Разумной стартовой точкой может служить [1]. В этой статье представлена по существу исчерпывающая таксономия 33 типов грязных данных и также разработана таксономия методов предотвращения или распознавания и очистки. Таксономия грязных данных демонстрирует многие типы грязных данных, с которыми не справляются сегодняшние средства очистки. В ней также указываются различные типы грязных данных, которые могут быть автоматически обнаружены и очищены, или даже появление которых может быть предотвращено. Однако, к сожалению, в статье демонстрируется большое число видов грязных данных, которые непригодны для автоматического обнаружения и очистки, и появление которых невозможно предотвратить. Например, по ошибке в базу данных вводятся данные о том, что возраст некоторого человека составляет 26 лет, в то время как в действительности ему 25 лет; или вводится имя человека Larry Salcow, а на самом деле оно пишется как Larry Salchow; или же адреса <> и <> являются старым и новым адресами одного и того же человека. Эти грязные данные появляются по причинам ошибки при вводе данных, неудачным обновлением адреса человека или неудачной стандартизации представления имени. Понятно, что никакое программное средство (и даже человек) не смогут обнаружить, что эти данные являются грязными. Конечно, теоретически можно произвести дорогостоящую перекрестную проверку данных из разных источников (файлов или таблиц), которые содержат информацию о возрасте, имени и адресе одного и того же человека.

Далее, предприятиям требуется оценить стоимость наличия грязных данных; другими словами, наличие грязных данных может действительно привести к финансовым потерям и юридической ответственности, если их присутствие не предотвращается, или они не обнаруживаются и не очищаются. Предположим, что компания осуществляет рассылку рекламных материалов на 100 тыс. адресов по цене 2 долл. за адрес. Если 2% адресов являются грязными, доставить по ним материалы не удастся. Две тыс. почтовых отправлений обойдутся в 4 тыс. долл. (Для простоты проигнорируем тот факт, что на самом деле 98% массовых почтовых отправлений, даже доставленных должным образом, все равно останутся без ответа.)

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

Проанализируем стоимость предотвращения, обнаружения и очистки грязных данных. Появление грязных данных любого типа можно предотвратить или распознать и очистить (автоматически или вручную), но это влечет расходы. В общем случае для каждого типа грязных данных имеется несколько, отличающихся по цене, способов предотвращения или обнаружения и очистки недействительных данных. К примеру, средства управления транзакциями в системах РБД предотвращают появление некоторых типов грязных данных, обуславливаемых потерянными обновлениями, а также грязным и неповторяемым чтением [1]. Определение ограничений целостности, таких как типы данных, ограничения уникальности, запрета наличия неопределенных значений и внешних ключей заставляет систему РБД автоматически поддерживать целостность данных при выполнении операций вставки, обновления и удаления. Эти средства являются частью системы РБД, и их выполнение занимает относительно небольшую часть машинного времени. Для выявления неправильно написанных слов имеет смысл запустить процедуру проверки орфографии. Для исправления неверно написанных имен и адресов можно использовать справочник, из которого можно почерпнуть и дополнительную информацию, в частности, почтовый индекс, название административного округа и т.д. Для принятия рекомендаций программных средств обычно требуется вмешательство человека. Можно обеспечить в значительной степени автоматическое обнаружение грязных данных некоторых типов, но гарантировать абсолютную корректность можно не всегда. Например, можно использовать средство автоматической проверки вхождения числового значения в указанный диапазон, для гарантии того, что возраст человека находится в диапазоне от 18 до 67 лет. Чтобы гарантировать отсутствие ошибок ввода, можно поручить нескольким людям проверку и перепроверку вводимых данных.

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

Несомненно, что большинство предприятий сегодня не предпринимает достаточных усилий для обеспечения высокого качества данных в своих хранилищах. Для обеспечения высокого качества данным предприятиям нужно иметь процесс, методологии и ресурсы для отслеживания и анализа качества данных, методологию для предотвращения или обнаружения и очистки грязных данных и методологии для оценки стоимости грязных данных и затрат на обеспечение высокого качества данных. В Ewha Women's University разработан прототип инструментального средства DAQUM (Data Quality Measurement), предназначенного для отслеживания большинства типов грязных данных и приписывания разным типам грязных данных количественной меры качества данных в зависимости от особенностей приложений [2]. В этом направлении нужно предпринимать дополнительные усилия.

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

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

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

В исследовательской литературе описано много предложений по моделированию хранилища данных в виде репозитария результатов всех выполняемых запросов [4-6]. Авторы этих предложений пытаются найти алгоритмы, которые будут выбирать(для загрузки в хранилище данных) подмножество исходных данных, минимизирующее общее время ответов на запросы. Некоторые из авторов пытаются также минимизировать стоимость обновления хранилища данных. Другими словами, они основываются на предположении, что все запросы к хранилищу данных можно заранее узнать или предсказать и что можно заранее узнать или предсказать все возможные изменения хранилища данных, а следовательно, и исходных источников данных.

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

Потенциально полезным и практичным является средство, которое анализирует потребности приложений в данных, автоматически сопоставляет эти потребности со схемами источников данных и выдает рекомендации по составу оптимального поднабора источников данных, которые нужно загрузить в хранилище данных, чтобы в нем находились все нужные данные и не находились какие-либо ненужные. Таким средством является MaxCentra, коммерческая версия которого была выпущена совсем недавно [3]. Функционирование MaxCentra опирается на наличие предварительно построенной базы знаний ключевых слов, которая представляет потребности приложений в данных. Ключевые слова в основном представляют собой неявные указания таблиц и полей, к которым будет осуществляться доступ при выполнении запросов, генерируемых приложением. Такой список ключевых слов может быть обеспечен бизнес-аналитиками или разработчиками приложений, или же он может быть получен автоматически путем анализа запросов от приложений, выполняемых над неоптимизированным хранилищем данных. MaxCentra отталкивается именно от этого и при поддержке и содействии проектировщиков позволяет получить оптимальную схему базы данных для хранилища данных. Работа MaxCentra включает несколько вычислительных этапов, и проектировщик хранилища данных может подтвердить или скорректировать результаты выполнения каждого этапа. Если выполнение MaxCentra основывается только на ключевых словах без учета зарегистрированных запросов, то программа производит стандартную обработку ключевых слов (морфологический анализ, разбиение составных слов, выявление одинаковых слов и т.д.). Затем производится упорядочение таблиц и полей в источниках данных с учетом их релевантности потребностям приложений в данных, группируются таблицы и поля, которые являются избыточными или могут быть порождены одно другим (так что избыточные или несущетственные таблицы и поля могут быть удалены), и группы упорядочиваются с учетом их релевантности потребностям приложений в данных.

Проблемы производительности и масштабируемости

В системах РБД для выборки небольшого количества нужных записей без полного сканирования таблицы или базы данных используются различные методы доступа, такие как индексы на основе хеширования или B+-деревьев. Такие методы доступа весьма эффективны при выборке по одному ключевому полю (или небольшому числу полей), когда результаты представляют собой малую часть таблицы. Примерами подобных запросов являются: <<найти всех 25-летних людей>>, <<найти всех инженеров-программистов>> или <<найти всех 25-летних инженеров-программистов>>. Для быстрого ответа на такие запросы можно создать индексы: на столбце <<Возраст>> таблицы <<Сотрудники>>, на столбце <<Занимаемая должность>> таблицы <<Сотрудники>> и на столбцах <<Возраст>> и <<Занимаемая должность>> таблицы <<Сотрудники>> соответственно.

Однако методы доступа в общем случае не помогают при ответе на запросы, результатами которых является значительная часть таблицы. Примерами являются запросы: <<найти всех сотрудников женского пола>>, <<найти всех некурящих сотрудников>> и <<найти молодых сотрудников>>. Кроме того, методы доступа не приносят пользы, если значения столбца часто изменяются, поскольку такие изменения требуют перестройки методов доступа. Это примеры <<простых>> запросов, для выполнения которых методы доступа в системах РБД оказываются бесполезными.

Помимо подобных <<простых>> запросов существуют два класса операций, для которых методы доступа в системах РБД становятся бессильными. К первому классу относятся операции <<агрегации>>, предусматривающие группировку всех записей таблицы и применение к сгруппированным записям агрегатных функций (среднего значения, общего числа, суммы, минимального или максимального значения). Этот тип операций важен в таких приложениях как анализ данных Web-журналов, сегментации данных о заказчиках и т.д. Различные методы, связанные с проблемой эффективности операций этого класса, анализируются в [7], включая сжатие данных, метод хранения таблицы по полям (хранение каждого поля таблицы как отдельного файла), предварительные вычисления (гиперкубов OLAP, сводных таблиц) на основе детализированных данных, нормализацию (разбиение таблицы на несколько более мелких таблиц) и параллельную обработку. На рынке имеются продукты MaxScan и Ab Initio, предназначенные для решения проблем производительности и масштабируемости при выполнении данного типа операций. В MaxScan применяется метод хранения таблиц по полям, методы хеширования для группировки и агрегирования записей, а также методы параллельной обработки. Производительность и масштабируемость при выполнении агрегатных операций в 10-20 раз превышают показатели систем РБД. Ab Initio является средством ETL, в котором в механизме трансформации данных используются методы повышения производительности.

К другому классу относится операции <<перемещения файлов>>, читающие и/или записывающие файл(ы) целиком. Этот тип операций важен на этапе требующем больших временных затрат <<преобразования данных>> при создании хранилища данных или на этапе <<подготовки данных>> при автоматическом извлечении знаний (добыче данных) из имеющихся источников [8]. Этап преобразования данных включает трансформацию формата и представления данных в заданных полях (изменение единицы измерения, изменение формата даты и времени, изменение аббревиатуры и т.д.), слияние двух или более полей в одно, расщепление поля на два или более полей, сортировку таблицы, построение обобщенной таблицы из таблиц, содержащих детализированные данные, создание новой таблицы путем соединения двух или более таблиц, слияние двух или более таблиц в одну, расщепление таблицы на две или более и т.д. К этапу подготовки данных относятся преобразование данных заданного поля в цифровой код (в нейронных сетях), преобразование непрерывных цифровых данных в заданном поле в категорические данные (например, возраст, превышающий 60 лет, считается <<пожилым>>), добавление к записи нового поля, взятие из таблицы образцов данных, репликация в таблице некоторых записей (для достижения желаемого распределения записей) и т.д. Более подробное обсуждение этих операций приводится в [9].

Сегодня операции перемещения файлов находятся в почти полной зависимости от последовательных операций систем РБД над файлами, т.е. чтения одного или более файлов, создания временного файла и записи результирующего файла или файлов. Частота выполнения подобных операций и объем используемых данных может сделать оправданным применение сервера преобразования/подготовки данных. В идеале такой сервер может состоять из нескольких параллельно работающих процессоров. Независимо от конфигурации процессора на нем должны выполняться программные средства преобразования/подготовки данных, спроектированные для параллельной обработки. Когда это оправданно, нужно применять конвейерную параллельную обработку, при которой получение частичных результатов одной операции инициируют выполнение другой операции без потребности ожидания завершения первой операции. Конвейерная параллельная обработка устраняет потребность в записи во временный файл полных результатов одной операции и в их чтении следующей операцией, что позволяет сэкономить два ввода-вывода файла. Для создания сводных таблиц вместо <<родных>> функций системы РБД имеет смысл использовать механизм быстрой сортировки, такой как SyncSort, или механизм быстрого агрегирования, такой как MaxScan. Кроме того, для выполнения вычислений <<запись за записью>> (выборка образцов, преобразование формата или представления данных и т.д.) имеет смысл разбить файл на несколько подфайлов и назначить каждому из них отдельный процессор для обеспечения параллельной обработки.

Заключение

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

Литература

1. W. Kim, B. Choi, E. Hong, S. Kim, D. Lee. "A Taxonomy of Dirty Data", Journal of Data Mining and Knowledge Discovery, the Kluwer Academic-Publishers, 2003.
2. W. Kim, et al. "The Chamois Component-Based Knowledge Engineering Framework", IEEE Computer, 2002, May, IEEE CS Press.
3. W. Kim, E. Hong, K. Kim, D. Lee. "A Component-Based Architecture for Preparing Data in Data Warehousing", Journal of Object-Oriented Programming, 2000 March/April.
4. H. Gupta. Selection of Views to Materialize in a Data Warehouse. In Proceedings of the Intl. Conf. on Database Theory, 1997 January.
5. J. Yang, K. Karlapalem, and Q. Li. Algorithms for Materialized View Design in Data Warehousing Environment. In Proc. of the 23th VLDB Conference, 1997 August.
6. Yannis Kotidis and Nick Roussopoulos. DynaMat: A Dynamic View Management System for Data Warehouses. In Proc. of ACM SIGMOD Conference, 1999 June.
7. W. Kim. "Business Intelligence at Top Speed", Intelligent Enterprise, Miller Freeman, Inc., 1998, Dec. 15.
8. D. Pyle. Data Preparation for Data Mining, Morgan Kaufmann Publishers, 1999.
9. W. Kim. "I/O Problems in Preparing Data for Data Warehousing and Data Mining - Part 1", Journal of Object-Oriented Programming, 101 Communications, 1999. Feb.

Вон Ким - президент и генеральный директор компаний Cyber Database Solutions (www.cyberdb.com) и MaxScan (www.maxscan.com). В 2001 году был удостоен премии ACM 2001 Distinguished Service Award.

Translated from <> by Won Kim in Journal of Object Technology (JOT), vol.1, No. 4, pages 39-47. Translated into Russian for Open Systems Journal under special permission of the original publisher. Copyright JOT September-October 2002. Original article at http://www.jot.fm/issues/issue_2002_09/column3.