VII. Три основных недостатка современных хранилищ данных

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

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

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

Проанализировать имеющиеся данные во всех источниках данных с целью инвентаризации семантики и контента.

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

Извлечь нужные данные, преобразовать извлеченные данные в соответствии проектом хранилища данных и загрузить преобразованные данные в хранилище.

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

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

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

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

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

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

Для того чтобы начать уделять необходимое внимание качеству данных в своих хранилищах, предприятиям, прежде всего, нужно разобраться в многообразии возможных грязных данных, источниках их появления и методах их обнаружения и очистки. Разумной стартовой точкой может служить. В этой статье представлена по существу исчерпывающая таксономия 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), предназначенного для отслеживания большинства типов грязных данных и приписывания разным типам грязных данных количественной меры качества данных в зависимости от особенностей приложений.