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

Говоря о качестве данных в контексте использования банками DWH (Data Warehouse), важно понимать, что в большей части случаев речь идет о достоверности создаваемой отчетности: управленческой (MIS), МСФО (IFRS) и регуляторной. И если первые два пункта зачастую предполагают некоторую степень допущения, то для регуляторной отчетности качество данных является критически важным условием, в случае несоблюдения которого последствия для банков могут быть самыми печальными. Кроме того, от недостоверности данных самым непосредственным образом страдают такие направления, как маркетинговые исследования, управление рисками, прогнозирование, скоринг и пр. Как результат — неверные управленческие решения, в итоге ведущие к убыткам.

Как системы-исходники влияют на качество данных?

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

Приведем пример проблемы, распространенной во многих банках. В системах учета предусмотрено поле, где указывается имя менеджера, который «привел» клиента и должен получить за это вознаграждение согласно имеющейся системе мотивации. Поэтому зачастую практикуются довольно неприглядные манипуляции или даже «Excel-войны», когда менеджеры пытаются приписать того или иного клиента себе ближе к концу отчетного периода. А все почему? Потому что поле «Клиентский менеджер» необязательно для заполнения и не связано внешним ключом с соответствующим справочником…

Но вернемся к DWH. Проблема архитектуры систем-источников увеличивается пропорционально их количеству. Редко встретишь банк из топ-20, который имел бы менее 5-6 значимых фронт-офисных систем, данные из которых загружаются в корпоративные хранилища в режиме хотя бы T-1¹ . При этом, наряду с тысячами мелких проблем с качеством данных, могут возникать и более глобальные, например, связанные с ETL, историзацией данных и интеграцией данных. Должен заметить, что названные проблемы имеются буквально во всех банках, с которыми мне приходилось взаимодействовать по работе. И именно об этих проблемах хотелось бы поговорить подробнее.

ETL

На всем процессе выгрузки-загрузки данных мы сейчас останавливаться не будем, поговорим лишь о так называемом «маппинге», проще говоря — о правилах перекладывания данных из системы-источника (хорошо, если это тоже реляционная БД) в DWH. Можно ли дать гарантии, что правильность данных будет безупречна и при их переносе не возникает ошибок? Боюсь, что нет, причем всевозможных ошибок может быть очень и очень много. Приведем наиболее вероятные и часто встречающиеся:

1. Изменение объектов или полей в системе-источнике. Банальная ситуация: вышла новая версия системы, а «маппинги» в DWH не изменили. Результат — полное или частичное падение загрузки.

2. Недоступность или частичная доступность системы-источника или его зеркального стенда. Загрузка данных обычно идет не из «боевой» системы, а из ее копии, причем не всегда самой свежей. Недоступность также может касаться настройки прав технической учетной записи, с помощью которой идет обращение к БД источника, — если, например, не прописали в роль один «GRANT…» (для Oracle).

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

Простой пример: данные по депозитам юридических лиц из АБС и данные по депозитам физических лиц из специализированных систем в хранилище зачастую лежат в универсальных структурах. То же самое можно сказать и про огромное количество статей баланса банка.

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

Историзация данных

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

Историзация нужна, чтобы быть уверенным в том, что, например: 1. Такого-то числа, год назад, остатки по счетам клиента ЗАО «Ромашка» были следующими, или что год назад формой собственности клиента было ЗАО, а не ОАО. 2. Перестроив конкретный отчет трехлетней давности, вы получите те же цифры и расшифровки, что и при первичном построении.

Некоторые виды отчетности строятся за довольно длительные периоды, особенно в МСФО, поэтому важно историзировать всю требуемую атрибутику полностью.

Однако в битве «ресурсы — историзация» не всегда побеждает последняя, и зачастую временные изменения того или иного параметра оказываются потерянными навсегда. Бывают компромиссы — выборочная, настраиваемая историзация. Итог известен — недостоверная отчетность или аналитика.

Интеграция данных

Выше мы затронули проблемы интеграции данных с позиции однообразности структур хранения информации.

Теперь хотелось бы обсудить ее консистентность и нормализацию. Представьте, что вы — клиент банка, и у вас есть кредит, депозит, дебетовая карта, какой-то продукт страховании, а еще вы открыли брокерский счет и приторговываете валютой на бирже. В итоге в своем банке вы как клиент пройдете через 5-6 учетных систем.

Если эти системы интегрированы с DWH, то при загрузке в режиме T-1 информация о вас пять или даже более раз попадет в хранилище отдельными записями. Заметьте, это только клиентская информация. Далее при составлении отчетности или некоей аналитической работе вы будете идентифицированы как несколько разных физических лиц, что, конечно же, в корне убивает саму идею хранилища данных.

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

Но вернемся к декартову произведению по клиентам. В некоторых банках эта проблема является настолько острой, что они открывают отдельные внутренние и внешние проекты на много тысяч человекодней с целью унифицировать клиента и создать так называемую «золотую запись» — сведенные данные по клиенту для дальнейшего использования их в отчетности. Какие только ухищрения не используются, начиная от простейшего объединения по ИНН и заканчивая методикой, применяемой в пограничной службой при проверке заграничных паспортов, — транслитерацией ФИО и иной текстовой информации во всех возможных вариантах и последующее посимвольное сравнение. Устанавливается порог, например при совпадении более 60% сведений производится ручная проверка на дубли или автоматическое слияние записей (что, кстати говоря, является довольно опасной практикой).

Хотя правильное решение гораздо проще: должна быть первичная централизованная система заведения клиентов, где каждому клиенту присваивается GCIF (Global Client Identifier), суть которого — сквозной первичный ключ клиента, который затем передается в фронт-офисную систему (или системы) и который позволяет однозначно идентифицировать клиента. Он же передается и в DWH. Другой вопрос, как определить, что конкретный клиент в системе еще не заведен и вы не присвоите ему GCIF дважды? Эта задача также решается путем задания ключевых полей, которые позволяют однозначно определить дубли.

Проблемы качества данных с точки зрения консистентности также ярко проявляются при сопоставлении данных сводного и аналитического учета.

Например, детальные данные по Вашей дебетовой карте хранятся в одной системе, а в АБС банка десятки тысяч остатков по счетам индивидуальных физических лиц представлены одним сводным счетом.

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

• разницы в регламенте закрытия дня (вы можете снять наличные с карты ночью или сделать покупки через интернет, в этих случаях не всегда можно определить однозначно, на какой отчетный день отнесутся деньги);
• отличия в учете;
• лаг (задержка между действиями пользователя и откликом приложения) при загрузке данных в DWH;
• отсутствие согласованной методики сверки и сведения данных.

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

К этой категории проблем можно отнести и бич всех банков — графики платежей по активам и выплат по депозитам.

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

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

Учитывая вышесказанное, правильные, взвешенные подходы к архитектуре могут предотвратить большинство проблем с качеством данных, хотя на практике это бывает не всегда.

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

---

¹ T-1 — это получение данных в КХД из систем-источников с задержкой в один день, то есть на утро рабочего дня в хранилище будут иметься данные за предыдущий день. (Прим. авт.)