`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Расчищаем авгиевы конюшни корпоративных данных

Статья опубликована в №23 (689) от 30 июня

+33
голоса

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

Ошибки в заполнении полей форм документов, множественные дубликаты записей, отсутствие необходимых атрибутов приводят к тому, что получаемые аналитические отчеты и ключевые показатели деятельности имеют слишком высокую погрешность. В результате реальная польза от BI-системы оказывается значительно меньше ожидаемой. Недаром среди BI-разработчиков со стажем популяр-но выражение: garbage in – garbage out (т. е. «ерунда на входе – ерунда и на выходе»). Впрочем, аналитические инструменты винить в этом несправедливо – их задача всего лишь визуализировать те данные, которые имеются в наличии. Так что рано или поздно перед ИТ-архитекторами встает вопрос повышения качества данных, который по своей сложности впору сравнивать с проблемой очистки авгиевых конюшен, поставленной перед мифическим героем Гераклом.

Ближе к делу

Не секрет, что плохое качество корпоративных данных часто имеет заметное негативное влияние на бизнес в целом. Как может, например, банк получить правильный «портрет» клиента, если в записях БД в одном случае его имя пишется как «Сергей Иванов», а в другом – как «Сегрей Иванов», и он, соответственно, проходит в системах как совсем другой потребитель? Или если при вводе номера паспорта в форму операционист банка по ошибке переставил символы? Или, скажем, каким образом розничная торговая сеть может узнать правильные и точные показатели о реализации продукта, если в полях с его штрихкодом, кроме цифр, встречаются буквы, добавленные по невнимательности? Погрешности в первичных данных мешают увидеть точную картину бизнеса. Просчеты в получении правильного профиля клиента могут приводить к неверному выбору целевых сегментов маркетинговых компаний, к некорректным оценкам кредитных рисков для банков, доходности клиента и групп и т. д. В случае торговой сети опечатки в коде продукта приводят к излишним складским остаткам, ошибочной оценке объемов реализации и прибыльности продуктовых групп, некорректностям в ценовой политике и пр. К сожалению, все это стоит денег. Если в докризисные времена бурный рост доходов позволял игнорировать затраты такого рода, то сейчас когда каждая копейка на счету – цена и значимость таких проблем возрастает многократно. Ситуация усугубляется тем, что если не предпринимать никаких мер в отношении качества корпоративных данных, его уровень будет постоянно снижаться – по некоторым оценкам, оно ухудшается в среднем на 2,5–3% ежемесячно.

Некоторые украинские компании уже осознали важность корректности информации, используемой для работы организации, и сформировали отделы по обеспечению качества данных – шаг насколько вынужденный, настолько же и прогрессивный. Задачей таких подразделений является как непосредственно очистка, так и формирование рекомендаций по минимизации случаев появления неправильных сведений в учетных системах. Однако исправление ошибок в исходной информации вручную с помощью подручных офисных средств в виде Microsoft Office Excel (или Access) может служить лишь временной мерой – трудоемкая и рутинная подготовительная работа по корректировке данных увеличивает затраты на подготовку отчетности в разы и повторяется из месяца в месяц. Как результат разрастается штат сотрудников, вовлеченных в процедуры построения отчетов, снижается оперативность их подготовки – информация, необходимая для принятия решений, предоставляется с опозданием.

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

Следует отметить, что задача повышения качества данных имеет несколько аспектов – методологический, технологический и административный. Рассмотрим их.

Пример профилирования с лексическим разбором поля ФИО
Шаблон Количество Процент Пример имени
F?? 1930 62,86 Вячеслав Николаевич Жуков
?F? 630 20,52 Антонов Андрей Станиславович
II? 100 3,257 С Ю Комиссарова
F? 91 2,93 Влад Дэнов
??? 62 1,95 Калерия Владимировна Ипатенко
?F 60 1,95 Солонцов Вова
FI? 51 1,62 Галина А Раткевич
?,F? 30 0,977 Андриенко, Александр Владимирович
?II 30 0,977 Корненков Д Ф
I? 20 0,651 А Михайловский
?? 11 0,32 Пользователь Системный
?FF 10 0,32 Маслова Лариса Влад
CI? 10 0,32 И В Веткасов
F??-? 10 0,32 Валерий Петрович Окулич-Казарин
F?F 10 0,32 Сергей Сергеевич Сергеев
FC? 10 0,32 Александр И Савельев
FF? 10 0,32 Медина Ксения Геннадьевна

Методологический аспект

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

1. Профилирование. Его задача – оценить «масштабы бедствия». Для этого определяют, в каких форматах данные присутствуют в учетных системах, а также каков процент ошибочных сведений. Здесь выявляют основные ошибки и расхождения, и ранжируют их по тому, насколько часто они встречаются. Находят также взаимосвязи между полями, в том числе и в разных системах (кросс-системные связи). Проводится проверка на соответствие стандартным справочникам – например, имен и населенных пунктов (таблица).

2. Стандартизация. Следующий этап – унификация и очистка информации на уровне полей, т. е. данные в полях приводятся к стандартному виду. Выполняется изменение форматов, исправление наиболее часто встречающихся погрешностей («Сегрей» -> «Сергей»), лексический разбор полей (например, выделение в адресах типов населенных пунктов и замена их на стандартные). Здесь могут использоваться справочники для коррекции данных, например добавление телефонного кода по справочнику населенных пунктов.

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

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

Вероятностный подход несколько сложнее, но дает обычно лучшие результаты. Он оценивает вероятность совпадения исходя из уникальности значения. Например, если совпадают имена «Сергей» и «Сергей», то шанс того, что речь идет об одном и том же человеке, невелик – ведь имя достаточно популярное. А вот если сходятся имена «Евлампий» и «Евлампий», то степень совпадения высока, так как это имя довольно редкое. При этом чем больше полей используется для сравнения, тем лучше. Для каждого из них может быть задействован разный весовой коэффициент, чтобы сделать алгоритм более точным (рис. 1). Так как при вероятностном подходе результатом сравнения является некий взвешенный балл, то требуется определить порог, выше которого балл будет обозначать гарантированное совпадение, а ниже которого – гарантированное различие. На практике сделать это невозможно, потому, как правило, задают два порога – верхний и нижний. То, что выше верхнего, – совпадение, а то, что ниже нижнего, – различие. Область между верхним и нижним порогами называют «серой» зоной, и значения сравнений, попадающие в нее, обычно отправляют на разборку вручную оператором. Если хорошо подобраны веса и коэффициенты, то в «серой» зоне оказывается не более 3–7% общего количества записей (рис. 2).

4. Удаление дубликатов. После сопоставления и обогащения остается некоторое количество идентичных записей, поэтому на последнем этапе производится устранение дубликатов для получения уникальных записей (рис. 3).

Технологический аспект

Расчищаем авгиевы конюшни корпоративных данных
Рис 1. Подходы к сопоставлению и обогащению

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

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

Требования к инструментарию для очистки данных

Расчищаем авгиевы конюшни корпоративных данных
Рис 3. Пример данных до и после очистки

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

  • визуальная среда разработки – практика использования для процедур очистки данных скриптов на SQL или других языках программирования приводит к увеличению затрат на построение и сопровождение DQ-подсистемы;
  • профилирование данных – хороший DQ-инструмент должен уметь выявлять шаблоны в полях БД и строить частотное распределение по ним, это существенно сокращает время на приоритезацию и разработку процедур очистки;
  • поддержка распространенных методов сопоставления;
  • интеграция с ETL-инструментами – так как очистка информации часто является одним из этапов в процедурах выгрузки и преобразования данных (Extract, Transform, Load), то достоинством считается наличие единого интерфейса для разработки ETL-процедур и процессов очистки данных; при этом первые могут являться частью вторых и наоборот;
  • параллелизм вычислений – очистка данных может быть достаточно ресурсоемким процессом, поэтому хороший DQ-инструмент должен поддерживать возможность распараллеливания обработки;
  • поддержка гетерогенных систем-источников и систем-приемников – желательно, чтобы DQ-инструмент был универсален и позволял применять любые СУБД в качестве источников и приемников, также немаловажно иметь поддержку работы с текстовыми файлами и XML, веб-сервисами;
  • интеграция метаданных с BI-инструментами – желательно, чтобы описание DQ-сведений было доступно из BI-системы; пользователи часто хотят видеть, какие DQ-процедуры использовались при очистке данных, на которых построен отчет, – это повышает доверие к отчетам;
  • возможность работы в сервис-ориентированной среде (service-oriented architecture) – так как архитектуры, в которых различные системы организации связаны между собой через сервисную шину, становятся все более популярными, то желательно, чтобы DQ-средство могло полноценно использоваться в такой системе; при этом вызов DQ-процедур будет возможен из других приложений через сервисную шину в любой момент времени, что позволяет очищать данные в учетных системах в режиме реального времени;
  • возможность интеграции с системами управления мастер-данными (Master Data Management, MDM), которые могут проводить очистку с помощью внешних DQ-средств через сервисную шину; если DQ-средство может интегрироваться с MDM, это позволит сэкономить при внедрении последних, так как будут использоваться уже наработанные алгоритмы очистки данных, реализованные в DQ-инструменте.

На сегодняшний день в мире есть несколько поставщиков ПО, предлагающих решения для очистки информации, которые часто являются составляющими приложений для интеграции данных. Например, инструмент для очистки данных IBM QualityStage является одним из ключевых компонентов ETL-сервера IBM Information Server.

Административный аспект

И наконец, административный аспект – пожалуй, ключевая составляющая для успеха инициатив по повышению качества данных. Важно четко установить, кто отвечает за определение бизнес-правил качества данных, кто занимается их внедрением и поддержкой, порядком взаимодействия подразделений в организации в случае необходимости внесения изменений в учетные системы. В проектах по повышению качества также важно определить так называемых владельцев данных (data steward), которые принимают окончательные решение по модификации тех или иных областей сведений. Эти шаги могут являться частью более глобальной инициативы по управлению метаданными в организации и недопущению бесконтрольного внесения изменений в структуру и форматы данных. Такая инициатива в англоязычных источниках называется Data Governance.

Иные применения

Область применения инициатив по качеству данных не ограничивается только инструментами бизнес-аналитики. Подсистемы качества данных реализуются в рамках CRM-внедрений, а также в проектах по их переносу из одних учетных решений в другие. Еще одна сфера, где активно применяются средства очистки данных, – проекты по централизованному управлению мастер-данными, являющиеся логическим развитием инициативы по обеспечению качества данных. Задача MDM – централизованное формирование единых для всей организации справочников клиентов и продуктов в режиме реального времени, такие системы, как правило, взаимодействуют с другими решениями организации через сервисную шину, и для очистки данных в режиме реального времени вызывают DQ-инструменты.

Вместо заключения

И напоследок о стоимости проектов по повышению качества данных. Зарубежная пресса оценивает средние проекты в 200–400 тыс. долл. Учитывая, что украинские компании имеют менее развитые и разнообразные учетные системы, бюджет инициатив по очистке данных может начинаться с отметки 100 тыс. долл. или даже меньше. С одной стороны, эта сумма достаточно большая, тем более для кризисного периода, с другой – возврат от инвестиций происходит довольно быстро, а экономический эффект может в десятки раз превосходить первоначальные инвестиции и наблюдаться на протяжении длительного периода. Причем чем хуже была картина с качеством данных изначально, тем быстрее и сильнее отдача. Так что компаниям, планирующим воспользоваться послерецессионным перераспределением рынка, стоит включить подобные инициативы в свой стратегический антикризисный план действий уже сейчас. Потом будет некогда.

+33
голоса

Напечатать Отправить другу

Читайте также

Аналитика, это конечно круто, и во многих случаях незаменимо.
Но прежде чем начинать "вычищать" неправильные данные с помошью бизнес-аналитики, гораздо эффективнее внедрять системы, которые позволяют избежать ошибок ввода, те же сканеры штрих-кода.
Банки в России и в Украине уже умеют обрабатывать платежки с помощью сканеров 1D и 2D штрих-кодов, аналогично поступает УкрПошта.
Пример с "если в полях с его штрихкодом, кроме цифр, встречаются буквы, добавленные по невнимательности" меня сразил наповал. Если такая ситуация и произойдет - очень маловероятно (чтобы не писать "никогда"), что такой товар будет принят или списан/продан. Я даже позвонил некоторым нашим партнерам, которые опросили ритейлеров на предмет таких ситуаций. Угадайте, каков был ответ? :)

Дмитрий, если у вас есть такие клиенты - ведите их к нам, тем более что IBM - один из крупнейших партнеров Motorola в этом секторе.

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

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

Интересно бы узнать об этом побольше. Особенно о вопросе выбора. Дело в том, что наша "сторона медали" - как раз автоматизация/оптимизация этапов ввода. Для полного понимания хочется заглянуть и на другую сторону - с чего порекомендуете начать, Дмитрий (<=40 страниц)?

Черканите мне письмецо на dmitry.gudkov [собака] gmail [дот] com - я вышлю почитать пару whitepapers (на англ.).

Дмитрий,

как можно с Вами связаться? Есть предложение.
Напишите на ibobak [at] bitimpulse [dot] com

P.S. Простите, что здесь пишу - но не вижу на сайте что-то типа "отправить личное сообщение".

Написал. Можете мне также звонить на O67-5O3-8I89

Тема действительно актуальная. Серьёзные ETL-решения только-только начинают появляться и перспективы могут быть весьма привлекательными.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT