Posts Tagged ‘Очистка данных’

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

Воскресенье, Июль 4th, 2010

Ларисса Мосс

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

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

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

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

Вторник, Июнь 22nd, 2010

Автор: Карина Доля
Опубликовано в журнале “CIO” №11 от 19 декабря 2007 года

offline.cio-world.ru

www.computerra.ru

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

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

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

Путь транзакции абонента

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

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

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

Информация о транзакциях абонентов может «испортиться» на любом этапе рассмотренного процесса. Это объясняется, во-первых, значительными объемами передаваемых данных – в хранилище мобильного оператора ежедневно попадает более 150 Гбайт данных; во-вторых, несовершенством процесса. Существует множество внешних факторов, которые могут негативно повлиять на работу системы. Несмотря на то что процесс автоматизирован, в любой системе случаются сбои. Например, по причине «неведомой силы» биллинговая система может выгрузить некорректные данные. Самый типичный «глюк» – задублированные строчки в файлах. Следует отметить, что автоматизация процесса загрузки данных не означает полного отсутствия контроля со стороны системных администраторов. Ведь при сбое работы системы, например, вследствие отключения электропитания, возобновить дальнейшую работу в большинстве случаев можно только вручную.

Крупнейшие сотовые операторы России (Источник: РБК)

Способы контроля данных

Теперь, зная, какой путь проходит каждая транзакция абонента и «уязвимые» места в цепи, рассмотрим возможные способы контроля качества данных.

Первый и самый простой способ – это считать данные корректными «по умолчанию». Однако сегодня подобный метод не имеет права на существование. Даже такая банальная проблема, как поломка сервера, способна остановить всю загрузку, и мобильный оператор потеряет данные за несколько дней. Это может привести к катастрофическим последствиям. Часть данных утеряна, следовательно, показатель ARPU (Average revenue per user – средняя выручка на одного пользователя) занижен, значит, компания теряет деньги. С другой стороны, абоненты не могут получить полную информацию о своих транзакциях. К тому же, если абонент не согласен с тарификацией своих звонков, мобильный оператор не сможет предоставить ему полную информацию о совершенных транзакциях.

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

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

Оптимальный вариант – контроль качества данных с помощью комбинации второго и третьего способов. Таким путем пошла группа компаний AT Consulting для контроля качества данных мобильного оператора «Вымпелком». В этом случае на этапе загрузки автоматически отсекаются задублированные строки в файлах, предоставленных биллинговой системой. Кроме того, установлен автоматический контроль размера получаемых данных, при этом количество строчек в файле может варьироваться достаточно сильно, чтобы учесть все возможные завышения и занижения вследствие внешних причин (например, праздники). Автоматизированный процесс непрерывно контролируется системными администраторами, которые в любое время дня и ночи могут сказать, на каком этапе находится процесс загрузки. Более того, после успешной загрузки данных в хранилище команда аналитиков ежедневно проверяет их корректность, используя, в том числе, специальное программное обеспечение для автоматического контроля.

Аутсорсинг качества данных

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

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

Однако большинство крупных телекоммуникационных компаний предпочитает отдавать на аутсорсинг контроль данных. Это позволяет компании-заказчику значительно уменьшить трудоемкость и затраты на создание, хранение и заботу о хранилище данных, сконцентрироваться на основных бизнес-процессах компании, не отвлекаясь на вспомогательные. Так, компании не придется расширять штат, организовывать новые рабочие места, арендовать помещения, искать при необходимости замену сотруднику, восстанавливать работу в случае ухода ведущего специалиста.

Все же наиболее весомым преимуществом аутсорсинга является повышение качества предоставляемых услуг. Например, когда контроль качества данных осуществляется оператором мобильной связи, за данный проект отвечает один конкретный менеджер (или группа менеджеров). Если вдруг критическая для бизнеса часть информации по каким-либо причинам будет потеряна, максимум, что может сделать компания, – это уволить нерадивого менеджера. Когда за контроль качества данных отвечает юридическое лицо, ситуация иная. Серьезная аутсорсинговая компания, которая дорожит своей репутацией, сделает все, чтобы не нарушить SLA (Service Level Agreement – соглашение об уровне услуг) и поддержать качество сервиса на должном уровне.

Сергей Шилов: «Большинство заказчиков опасаются, что они не смогут контролировать качество работы подрядчика».По мнению Сергея Шилова, генерального директора группы компаний AT Consulting, если просуммировать все плюсы и минусы аутсорсинга, то перед организацией-заказчиком чаще всего стоят три основных вопроса. «Во-первых, стоимость услуг. Понятно, что никто не хочет переплачивать за работу, которую можно выполнить самостоятельно. Однако в этом случае для эффективного поддержания качества данных компании придется сформировать дополнительный отдел сотрудников, закупить или разработать специальное программное обеспечение. Все это приведет к увеличению капитальных затрат без возможности экономии на масштабе, что является одним из основных аргументов в пользу аутсорсинга. Во-вторых, качество услуг. Большинство заказчиков опасаются, что они не смогут контролировать качество работы подрядчика. Тем не менее, на практике эту проблему можно решить с помощью грамотно составленного соглашения SLA. В нем определены все критерии качества и сроки сдачи регулярной отчетности, подтверждающей, что заданный уровень качества действительно достигнут. Наконец, в-третьих, проблема безопасности данных, передаваемых на аутсорсинг. Однако, на мой взгляд, утечка информации из аутсорсинговой компании может похоронить ее репутацию. Так что в интересах самого подрядчика обеспечить максимальный уровень конфиденциальности доверяемых ему данных».

* * *

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

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

Если компания принимает решение отдать контроль качества данных внешнему исполнителю, главное – правильно выбрать подрядчика. Наиболее важными критериями являются опыт аутсорсинговой компании и ее место на рынке ИT-услуг. После выбора внешнего исполнителя компании-заказчику нужно подойти со всей ответственностью к составлению SLA, чтобы поставленная задача была одинаково понятна как заказчику, так и подрядчику. Отдавать или не отдавать контроль качества данных на аутсорсинг – личное дело каждой компании. Самое главное – результат. Лучше позаботиться о качестве данных заранее, чем потом пытаться отыскать некорректные записи, на основании которых были приняты неверные стратегические или краткосрочные управленческие решения.

Предобработка и очистка данных перед загрузкой в хранилище

Среда, Март 24th, 2010

BaseGroup Labs
Алексей Арустамов

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

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

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

Типы ошибок

Мы не будем рассматривать ошибки такого рода как несоответствие типов, различия в форматах ввода и кодировках. Т.е. случаи, когда информация поступает из различных источников, где для обозначения одного и того же факта приняты различные соглашения. Характерный пример такой ошибки – обозначение пола человека. Где-то он обозначается как М/Ж, где-то как 1/0, где-то как True/False. С такого рода ошибками борются при помощи задания правил перекодировки и приведения типов. Такого рода проблемы худо-бедно сегодня решаются. Нас интересуют проблемы более высокого порядка, те, которые не решаются такими элементарными способами.

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

  1. Противоречивость информации;
  2. Пропуски в данных;
  3. Аномальные значения;
  4. Шум;
  5. Ошибки ввода данных.

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

Противоречивость информации

Для начала нужно решить, что именно считать противоречием. Как ни странно, это задача нетривиальная. Например, пенсионную карточку в России нужно менять в случае изменения фамилии, имени, отчества и пола. Оказывается, в том, что человек родился женщиной, а вышел на пенсию мужчиной, противоречия нет!

После того, как мы определимся с тем, что считать противоречием и найдем их, есть несколько вариантов действий.

  1. При обнаружении нескольких противоречивых записей, удалять их. Метод простой, а потому легко реализуемый. Иногда этого бывает вполне достаточно. Тут важно не переусердствовать, иначе мы можем вместе с водой выплеснуть младенца.
  2. Исправить противоречивые данные. Можно вычислить вероятность появления каждого из противоречивых событий и выбрать наиболее вероятный. Это самый грамотный и корректный метод работы с противоречиями.

Пропуски в данных

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

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

Аномальные значения

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

Есть метод борьбы и с этой напастью – это робастные оценки. Это методы устойчивые к сильным возмущениям. Мы оцениваем имеющиеся данные ко всему, что выходит за допустимые границы, и применяем одно из следующих действий:

  1. Значение удаляется;
  2. Заменяется на ближайшее граничное значение.

Шум

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

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

Ошибки ввода данных

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

Резюме

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

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

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

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

Четверг, Март 18th, 2010

Игорь Артамонов
artamonov.ru

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

В общем, расскажу на примере одной недавней задачки.

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

Начинаем разбирать… Фантазия людей безгранична: вот возьмем к примеру Евросеть, как название только не напишут, могут как «ЕВРОСЕТЬ ЦЕНТР», или «ЕВРОСЕТЬ (ООО ЦЕНТР ХАБАРОВСК)». Ну с этим все более понятно, есть вхождение слова Евросеть и значит нашли магазин.

Следующий вариант это написание типа «Evroset». Сразу не найдем, тут нам надо сделать обратную транслитерацию. А есть, кстати, тот же DIXIS, для которого получается надо делать обратную операцию.

С учетом транслитерации и самих ошибок начинаются проблемы, потому люди пишут и как «Evroset», и как «Euroset», как «euroset.ru», да и в общем-то тоже самое для русского. К тому же бывают опечатки, или просто незнания правильного написания. «Техносила» может быть написана как «TECHNOSILA», или как «TEHNO SILA» (буковки C вообще нет), и т.д. А как вам «ЦИФРАГАД»(видимо не угодил он покупателю) и «ЦИФР0ГРАД» (Ноль вместо О, не иначе как кулхаксор писал), или «ЦЫФРАГРАТ» (ага, афтар жжет)?
Вывод такой: искать по вхождению не имеет смысла. Перебирать все варианты возможных ошибок, фантазий и пр. для каждого магазина просто нереально. Итого остается вариант искать по близости написания. Т.е. строка сравнивается по написанию со всеми магазинами, и берется тот, который наиболее похож. Естественно нужно еще найти какой-то минимальный порог, меньший 100% совпадения, но очень высокий, чтобы «ТЕХНОМИКС» не совпадал с «ТЕХНОМИР».

Сравнивать полную строку нет смысла, потому что чисто символьная разница между «СВЯЗНОЙ В ОКЕЕ НА МАРШАЛА ЖУКОВА», «СЕТЬ МАГАЗИНОВ САТЕЛЛИТ» и пр. далека от написания самого названия магазина. Из первой фразы надо сразу убирать адрес, но это просто, мы убираем все окончания начинающиеся на «на», «у», «ул», «в», «пр». Второй случай содержит часто употребимые слова, их можно выделить даже мельком пробежав все названия, хотя лучше с этим справился простенький скрипт. Но, так как даже после этого, во фразе все равно может остаться невыловленный нами мусор, надо сравнивать слова по отдельности, а не всю фразу.

Думаете стало находить? А фиг то там! Потому что если мы начнем таким образом сравнивать «EURO SET» и «BETA LINK», или, что еще хуже, «ЗАОБЕТА ЛИНК СПБ», то они станут непохожи, ведь из слова «BETA LINK», что «бета» что «линк» лишь наполовину похожи на «беталинк»… Поэтому надо сравнивать слова не только по одному, но и группами близлежащих, и к тому же не учитывая пробелы…

А еще надо учитывать чтобы из-за этой похожести «ДОМ.ТЕХНИКА» не совпал с «ДОМОТЕХНИКА» :) Тут, на самом деле, начинается новая проблема. И если дальше копать, то выясняем что магазинов с элементами «техно/техника/техникс», «мир», «центр», «видео» и пр. просто немеряно :( А ведь чем длиннее строка тем меньшую непохожесть вносит всего одна опечатка. Поэтому подобные элементы нужно сразу учитывать, чтобы не вносили погрешности. Но, опять же, тут надо учитывать что есть «М-ВИДЕО», который почти полностью состоит из одного из этих самых частоупотребимых элементов. Т.е. в данном случае нельзя отбрасывать эту часть, как мы делали с простым мусором (который упомянул выше, как например «СЕТЬ МАГАЗИНОВ»). Эти элементы надо сравнивать как обязательную и неотемлимую часть. И в тоже время требовать, чтобы ничего лишнего не было, т.е. «МИР ВИДЕО И АУДИО» это уже должно подпадать под мусор.

Да, и еще, насчет этих частоупотребымих элементов и мусора. Есть не только магазины, который в офлайне, но и интернет-магазины. А уж они то любят занять распространенное слово. И если на сайте telephone.ru продается достаточно товаров чтобы быть заметным, то нужно уметь его выделять. Вы думаете что его пишут как название сайта? Фиг то там! Он и сам себя именует как телефон.ру, и поэтому его пишут например как: «РОСТОВ.ТЕЛЕФОН.РУ» и так далее с учетом всех возможных опечаток. И выделяя его, нам ни в коем случае нельзя ошибиться и выделить «СОТОВЫЕ ТЕЛЕФОНЫ». Хотя в действительности для подобных сайтов не требует внесения каких-то особо уникальных вещей в алгоритм, но иметь ввиду это надо.

Ладно, это мы чуток разобрались с общеизвестными брендами, написание которых, чаще все же уникально. А ведь есть некоторые «псевдобренды», или не знаю как назвать. В общем, суть в том, что многим нашим предпринимателям лень думать над уникальным названием, и очень многие берут себе название типа «МИР», «МИР ТЕХНИКИ», «БЫТОВАЯ ТЕХНИКА», «ЭЛЕКТРОНИКА». И этих название просто куча в анкетах, и хотя клиент прекрасно понимает, что как таковой сети магазинов с таким именем нет в природе, но учитывать надо, из-за того, что слишком часто упоминается. И ведь приходится :) И, с учетом всего вышенаписанного, «БЫТОВАЯ ТЕХНИКА» должна отличатся от «МИР БЫТОВОЙ ТЕХНИКИ», от «ВИДЕО И БЫТОВАЯ ТЕХНИКА», но совпадать с «БЫТОВАЯ ТЕХНИКА 4″, «БЫТОВАЯ ТЕХНИКА МАГАЗИН №12 ЧП СОКОЛОВ С.И.», а «МИР» не должен совпасть с «АПЕЛЬСИНОВЫЙ МИР», «МИР ТЕХНИКИ», но совпадать с «МИР В ГИПЕРМАРКЕТЕ СЕМЬЯ» ну и т.д. Т.е. мусор если и может присутствовать, то только указывающий на месторасположение или тип.

Вот примерно такими вещами я сейчас и занимаюсь, если кому не лень тот может попробовать реализовать такой алгоритм, он не такой уж и сложный :) Я привел на примере магазинов цифровой техники, но примерно также делается и для многих других вещей: для брендов, названий товаров, автомобилей и пр. что имеет конечный описанный объем названий. А вот когда требуется просто выделить что-то из фразы, к примеру адрес, то тут все гораздо хитрей.
А еще подумайте как вообще можно написать адрес, или телефон, и как же определить настоящие это данные или нет, и поверьте, фантазия людей похоже действительно не имеет границ.
А ведь мало написать выделение данных, нужно чтобы алгоритм сразу отбрасывал, как мусор, данные о человеке типа «Мери Попинс, ул. Ленина 1 кв. 1, тел. 123-12-34″ :)

Что дает очистка данных

Четверг, Март 11th, 2010

Игорь Артамонов
artamonov.ru

Расскажу немного о том зачем нужна очистка данных и CDI. Сейчас не буду углубляться в CDI, MDM, это потом, и будем считать что данные должны быть чистые, это вполне логично. Вопрос в другом, вот почистили мы наши клиентские базы, положили в некую CDI систему, а на что можно рассчитывать дальше? Т.е. как мы сможем их использовать, помимо того что теперь мы знаем что у нас не мусор в базе/CRM? Какие преимущества мы получим от очистки данных?

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

Основные блоки данных

Приведу список основных элементов данных и то что можно получить на из основе.

Адрес

  1. Дает возможность сделать географическую привязку клиента, для:
    1. Анализ эффективности деятельности филиалов, проанализировав объемы клиентов в различных зонах.
    2. Анализ действия рекламной компании, сравнивая области с различным уровнем объема уличной рекламы по разным частям города.
    3. Сегментация уровня дохода/социального положения клиентов по стоимости жилья. Как минимум можно составить характеристики по районам города, а по хорошему еще составить отдельный список элитного жилья, и наоборот.
    4. Обнаружение аномалий в распределении. К примеру повышенный объем страховок в одном из регионов относительно других регионов, при прочих равных факторах, возможно говорит о наличии неучтенного повышенного риска для жителей данной области (т.е. жители чего то опасаются, лучше узнать чего именно, пока не поздно).
    5. Определить где можно открыть новый филиал/банкомат/магазин и пр.
  2. Обнаружение связей:
    1. соседи и друзья
    2. семья
    3. коллеги, при анализе рабочего адреса
  3. Дополнение недостающей информации (например индекс,который, как известно, никто не заполняет правильно), что может устранять неоднозначности адреса, ускорять доставку корреспонденции и пр.
  4. Удаление из базы мусорных записей.

Имя

  1. Определение пола. Нужно для:
    1. Формировании исходящей корреспонденции. Может и мелочь, но меня лично раздражает эта запись в поздравительных письмах типа «уважаемый(ая)». Ты или определись с моим полом или не делай вид что письмо совсем уж персональное.
    2. Сегментация по полу при исследованиях
  2. Уточнение семейных связей (используя совместно со значениями адреса и возраста)

Телефон

  1. Дополнение недостающей информации (код города из адреса или наоборот)
  2. Обнаружение связей (по домашнему и рабочему телефонам)
  3. Определение сферы деятельности по рабочему телефону (используя справочники организаций)

Прочие поля

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

Связи между клиентами

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

  • Анализ нового клиента. Т.е. известное «скажи мне кто твой друг и я скажу кто ты» в действии.
    • К примеру у нас появляется новый клиент, молодой человек или девушка, по которому мы определили что он родственник нашего существующего vip клиента, и даже то что это сын или дочь. В таком случае нам лучше пометить и этого клиента как VIP, или ввести тип вроде VIP-related. Вполне возможно что если ему не понравится сервис, он может отговорит и своего отца пользоваться нашими услугами. Да, дети иногда имеют хорошее влияние на своих родителей, да еще и с учетом юношеского максимализма. В общем лучше подстраховаться сразу.
    • С другой стороны таким образом можно вычислить родственника (или соседа/друга) нежелательного клиента, или мошенника.
    • Ну конечно дополнительные критерии для скоринга.
  • Следующий вариант это коллеги. Если в одной организации есть несколько лояльных клиентов, то такую организацию будет гораздо проще поставить на какое либо корпоративное обслуживание. Опять же будет возможность улучшить лояльность компании, которой делается соответствующее предложение, предложив перед этим какой то бонус найденным (но ничего не подозревающим) «инсайдерам». Но это уже в сторону вирусного маркетинга и пр., тут главное что нашли точку куда можно приложить силу.

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

Да, и еще, тут еще интересный момент есть: для обнаружения связей между клиентами можно воспользоваться базами «Одноклассников» и «В Контакте». Если у нас не трудно достать базы не только всех гос. структур, но и вполне серьезных коммерческих организаций, банков и операторов сотовой связи, то база «Одноклассников» вообще не проблема, рано или поздно базы социальных сетей будут в продаже. Кстати, в случае БД социальных сетей типа «Одноклассников» все даже проще, так как доступ ко всем связям есть извне, через web, не надо прямого доступа к серверам. Я более чем уверен что уже есть софт который вытаскивает всю нужную информацию с этих сайтов и сохраняет ее в нужном виде. В конце концов вполне реально самостоятельно сделать парсинг подобных сайтов и последующее насыщение профайла, по мере надобности, так даже правильнее будет. Причем это будет вполне законно, в отличии от краденных баз.