Очистка данных: дихотомия (противоречия) Хранилищ данных?

Ларисса Мосс

“Грязные данные” – это настолько распространенная проблема в каждой компании, в каждом производстве! Но мы же жили с “грязными данными” десятилетия. Почему же сейчас это вдруг стало такой проблемой? Не потому ли, что мы обещаем поставлять Хранилища данных с “чистыми, интегрированными историческими данными в сжатые сроки за невысокую цену”, хотя все еще неспособны справиться с преобладанием “грязных данных” в рамках этого обещания? Некоторые Хранилища терпят неудачу ввиду невозможности предоставления обещанных “чистых”, “интегрированных”, “исторических” данных. Другие не достигают успеха потому, что обещанные “сжатые” сроки и “низкая” цена выходят за указанные пределы при попытке очистить данные. Другими словами, они терпят неудачу из-за противоречивости нашего обещания.

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

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

Фиктивные значения

Сколько раз мы видели фиктивные значения, такие, как номер социального страхования 999-99-9999, или возраст клиента 999, или почтовый индекс 99999? В таких случаях наличие редакторских проверок выглядит преступлением, поскольку сотрудники, вводящие данные, чувствуют, что вынуждены выдумывать значения в тех местах, где реальные значения неизвестны. Но такие значения просто выявить, а как насчет несколько более творческих подходов к необходимости обойти обязательные поля? Что, если лицо, вводящее данные, всегда использует свой номер социального страхования или возраст или почтовый индекс?

В ряде примеров мы находим фиктивные значения, которые действительно имеют некий смысл (например, номер социального страхования 888-88-8888 для указания на статус клиента-иностранца “нерезидент”, или месячный доход в размере $99,999.99 для указания на то, что клиент имеет работу). Если бы вам пришлось подсчитывать среднемесячный доход ваших клиентов, результаты были бы некорректны.

Отсутствие данных

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

Многоцелевые поля

Чтобы сделать жизнь разработчиков еще интереснее, два кредитных отдела из приведенного выше примера, возможно, имеют общие системы для выдачи и обслуживания своих кредитов. Это не так редко встречается, особенно когда OLTP-системы приобретаются как пакеты и 80% потребностей в данных являются общими для обоих типов кредитов. Проблема состоит в использовании тех 20% не являющихся общими полей, по которым часто можно определить силу творческого начала персонала, работающего в сфере информационных технологий. Здесь мы находим поля данных, использующиеся для множества целей, где одно и то же значение в некотором поле в итоге означает много различных вещей в зависимости от (1) того, какой отдел его ввел и (2) наличия конкретных значений в одном, или даже лучше, в нескольких полях данных. Многие из нас видели группы данных или даже целые записи, переопределяемые, и переопределяемые и переопределяемые снова и снова, около 25 раз, без составления какой-либо документации для отслеживания истории этих переопределений.

При более близком рассмотрении, размер и содержимое таких записей может быть чем угодно, начиная со строки дат, переопределенной как строка сумм, переопределенной как смесь текста и цифр, переопределенной как… Как что-то может породить такие, похожие на содержимое канализационной трубы, записи? С помощью Малых Величин, конечно, или, быть может, используя Пробелы? “Не имеет значения,”- можете сказать вы, поскольку переопределенные поля всегда заполнены как полагается, согласно правилам типа записи. “Да нет, имеет,”- говорю я, потому что они никогда так не заполняются!

Но давайте не будем останавливаться на этом. Реальность такова, что как только мы приближаемся к 25 переопределениям, многие из нескольких первых значений данных больше неприменимы; и, во многих случаях, не осталось никого, кто хотя бы помнил, что они означали когда-то. Тогда вы запускаете “кампанию по очистке”, сообщая всем пользователям системы, что вы удалите эти плохие значения в какой-то конкретный момент времени. К вашему большому удивлению, раздается два панических телефонных звонка и один растерянный отклик по электронной почте от людей, о которых вы даже не знали, что они использовали эту систему. Вы обнаруживаете, что кто-то использовал это поле совсем с другой целью для выполнения своих функциональных обязанностей, не информируя об этом кого-либо, и удаление “плохих значений” просто-напросто прикроет всю работу. Кто-то еще не был в курсе 25 различных значений это поля и выдавал важную финансовую информацию на основании этих “плохих значений”.

Непонятные (кодированные) данные

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

Например, скажем, наша гипотетическая кредитная система изначально отслеживала, производятся ли с ипотечного кредита налоговые отчисления. Код “I” мог использоваться для обозначения “Нет, налоговые отчисления со счета отсутствуют”. Скажем, годы спустя, мы начали взимать страховые взносы. Поскольку код “I” уже использовался для термина “Налоговые отчисления отсутствуют”, код “T” представлялся чем-то вроде “логической альтернативы” для использования в качестве “Страховые отчисления отсутствуют”. Все, что нам надо было помнить, это то, что оба они представляют собой отрицание и являются переключаемыми. Еще через несколько лет мы захотели отслеживать некоторые ипотечные кредиты, застрахованные Федеральным жилищным управлением и не требующие обычного страхования. Код “T” уже использовался для обозначения отсутствия страховых отчислений, однако он имеет другое значение с точки зрения новых требований, поэтому был добавлен новый код “F”. И поскольку мы собираемся отслеживать в этом поле “исключения из обработки платежей”, давайте добавим “E” в качестве общего обозначения всех и любых исключений. Так, есть кредиты, для которых нам необходимо знать, что ни налогов, ни страховых отчислений с них не производится. Хотя мы еще не исчерпали алфавит, давайте оставим поле пустым и напишем логику для опроса поля Сальдо Отчислений; и если там стоит значение, большее НУЛЯ, давайте проверим, существует ли заключительная запись об отчислениях. В противном случае поле Сальдо отчислений имеет совершенно другое значение. Проходит еще несколько лет, и: все мы видим ту самую картину. ПОЧЕМУ, можете спросить вы? Скорее всего, в свое время была некая логичная причина, но только те, кто работал над ней 20-30 лет назад, знают, что она собой представляла.

Противоречивые данные

Когда пролетают недели, и мы действительно начинаем заниматься анализом этих “грязных данных”, мы обнаруживаем противоречивую информацию между двумя или более полями. Например, адрес недвижимости в нашем файле показывает Техасский почтовый индекс и Нью-Йорк в качестве города и штата. К этому времени мы уже не верим ничему, что видим, поэтому решаем проверить адрес улицы. Глядь, а такой улицы в Нью-Йорке нет! Более серьезным примером может быть случай, когда недвижимость закодирована как Жилье для одной семьи и под той же характеристикой помещено в отчет для руководства, а мы показываем, что при оценке использовался рентный доход от 10 различных составляющих.

Несоответствующее использование адресных полей

Перед тем, как мы отойдем от темы адресов, вспомним, как все мы видели адреса, построенные по принципу: Address line 1, Address line 2, 3 и так далее, где Address line 1 была изначально предназначена для личного Ф.И.О. или наименование компании, возможно, предваряемого звездочкой для указания на то, что это бизнес-адрес (не слишком хорошая идея!), Address line 2 – для номера, направления и названия улицы, и так далее. Достаточно сложно разобрать это все на отдельные атрибуты данных для Хранилища без того, чтобы натолкнуться на вот такой “бриллиант”:

Address line 1: ROSENTAL, LEVITZ,

AT

Address line 2: TORNEYS

Address line 3: 10 MARKET, SAN

FRANC

Address line 4: ISCO, CA 95111

Нарушение правил (логики) бизнеса

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

Повторное использование первичных ключей

Одним из наиболее критичных случаев “грязных данных”, с которым сталкиваются разработчики Хранилища данных, является повторное использование первичных ключей. Поскольку OLTP-системы редко хранят историю дольше 90 или 180 дней, значения первичных ключей часто используются повторно. Например, отделение банка, будем называть его отделением № 84, выдавшее и обслуживающее более 1,000 ипотечных кредитов на общую сумму $800,000,000, закрывается и передает обслуживание этих кредитов отделению № 207. В течение одного года номер 84 присваивается новому отделению, которое расположено в менее населенной местности и поэтому сталкивается с высоким процентом лишений права выкупа закладной по выданным кредитам. Обычно исходные 1,000 кредитов продолжают указывать на отделение № 84 как на выдавшее их, и все эти ошибочно приписываются новому отделению № 84. На первый взгляд и без дальнейшего детального анализа это нельзя считать свидетельством нерентабельности нового отделения № 84.

Неуникальные идентификаторы

Еще более интересная путаница возникает в случае, когда физическое отделение имеет два или более идентификатора. Например, отделение, находящееся по адресу Главная улица, дом 10, может быть обозначено как отделение № 65 в кредитной и инвестиционной системах и как отделение № 389 в чековой и депозитной системах. Другим примером может служить ситуация, когда один клиент обозначен множеством различных номеров клиента. Многие из нас сталкивались с такой ситуацией в своем банке или телефонной компании, где мы многократно получаем одну и ту же почту.

Проблемы интеграции данных

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

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

Теперь, когда мы разоблачили все эти ужасы “грязных данных”, давайте воздержимся от линчевания виновного и вместо этого будем справедливы к пользователям и специалистам по информационным технологиям, которые своим творческим подходом породили всю эту неразбериху. В большинстве случаев этот тип творческой активности был и, под давлением обстоятельств, возможно, должен оставаться поощряемым. Серьезно, каковы очевидные альтернативы? Изменить файлы и программы, конечно! Тем не менее, если система была приобретена как пакет программ или если созданная своими силами система старше 30 лет, и, возможно даже, написана на Ассемблере, это “простое” решение может оказаться и совсем не простым и неэффективным с точки зрения цены.

Очищать или не очищать

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

Следующий вопрос сложнее: СЛЕДУЕТ ли это очищать? И здесь также ответом часто является НЕТ. Для большинства из нас работающих в сфере управления данными, такой ответ имеет оттенок ереси. Какую цель преследует извлечение “грязных данных” из OLTP-систем и втыкание их в Хранилище в том виде, в каком они есть? Ясно, никакую. Очевидно, что должна производиться некоторая очистка. Тем не менее, всем нам приходится сталкиваться лицом к лицу с реалиями сегодняшнего бизнеса и его ожиданиями предоставления дополнительной информации в относительно короткий срок за низкую цену. Хотя “короткий срок” и “низкая цена” субъективны для каждой компании и могут представлять собой широкий спектр интерпретаций. Должно быть очевидным, что время и усилия, требующиеся для создания и тестирования длинной и сложной логики для исправления некоторых наших наихудших случаев “грязных данных”, выйдут за указанные рамки.

Как только мы решили, какие данные должны быть очищены, появляется вопрос: ГДЕ мы их очищаем? Очищаем ли мы наши оперативные данные в рамках OLTP-систем? Или, производим ли мы очищающие преобразования в течение нашего процесса извлечения и загрузки в Хранилище данных? Обычно нашей первой реакцией является очистить наши OLTP-системы; и, в ряде случаев, это может и должно быть сделано. Тем не менее, всегда слишком часто те, кто использует OLTP-системы для оперативных целей, не нуждаются в более чистых данных, чем есть на данный момент, и будут сопротивляться любым попыткам изменить их. И, во многих случаях, это достаточно трудоемкая задача, к тому же неэффективная с точки зрения цены или просто нереализуемая; и таким образом в итоге мы возлагаем бремя очистки на наш процесс извлечения и загрузки.

Последний вопрос, конечно: КАК мы очищаем то, что можно приемлемо очистить? Могут ли имеющиеся сегодня на рынке продукты для очистки данных справиться с большим количеством обычных проблем с качеством данных, общих для большинства организаций? Довольно очевидно, ответом будет ДА. Но способны ли эти продукты урегулировать все очень сложные и очень специфичные ситуации с “грязными данными”? Довольно очевидно, что ответ – НЕТ. Если вы действительно серьезно настроены на создание дополнительной информации и знаний, независимо от состояния ваших оперативных данных, придется ли вам прыгать выше головы и писать процедурный код? Ответ определенно ДА.

Какие шаги предпринять?

Так как все же выглядит правильный ответ для вашей компании? Как вы решите, какие “грязные данные” очищать и почему? Кто принимает эти решения? Давайте начнем с наиболее фундаментальных вопросов и посмотрим, станут ли ответы очевиднее:

  • Почему мы ставим Хранилище данных на первое место?
  • Каковы специфические вопросы бизнеса, на которые мы пытаемся ответить?
  • Почему мы не в состоянии ответить на них сегодня?

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

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

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

Затем начинается поиск компромиссов. Если выгоды превышают стоимость таких усилий, данные определенно должны быть очищены. Далее должно быть принято решение, вносить или нет необходимые изменения в OLTP-системы для (a) очистки существующих данных и (б) для предотвращения ввода “грязных данных” в будущем. Должны быть предприняты все усилия для улучшения OLTP-систем, если только такие усилия не настолько безосновательно велики (например, в случае многолетних архивных данных или когда это просто невозможно сделать ввиду того, что исходные источники данных больше не существуют). Реальность такова, что чаще всего большая часть очистки в итоге производится во время процессов извлечения и загрузки.

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

Это возвращает нас обратно к самой сути процесса, а также к дихотомии технологии построения Хранилищ данных: обещанию предоставить “чистые”, “интегрированные”, “исторические” данные в “сжатые” сроки за “небольшую” цену. Теперь, когда мы полностью осознаем “реалистичные” сроки и “реалистичную” цену, необходимые для достижения первой части нашего обещания, мы понимаем, что мы были сбиты с толку его второй частью.

Оригинальный текст статьи можно посмотреть здесь:
DMReview: “Data Cleansing: A Dichotomy of Data Warehousing?”

iso.ru

Tags: ,

Leave a Reply