---

На заре создания хранилищ данных Билл Инмон, автор концепции Data Warehouse, понимал под хранилищем "предметно ориентированное, интегрированное, неизменяемое, поддерживающие хронологию собрание данных, предназначенное для целей поддержки управления". С тех времен представление о предназначении хранилищ данных и подходах к их созданию значительно изменилось. В данной статье представлена эволюция хранилищ данных и описаны особенности современного этапа их развития на основе опыта компании РДТЕХ.

Этапы развития хранилищ данных

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

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

При решении типовых задач появилась идея использовать готовые западные решения, учитывающие стандартные потребности организаций. Так, компания РДТЕХ выбрала Oracle Financial Services Applications (OFSA) как одно из лучших решений, адаптированных под финансовый сектор, содержащее необходимые структуры, с использованием которых успешно решались задачи по бюджетированию, разнесению процентов доходов и расходов и т. д.

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

В данной статье описаны особенности локализации бизнес-приложений Oracle Financial Services Applications, проведенной компанией РДТЕХ. Основное внимание уделено отличиям локализованного хранилища данных в части методологии реализации системы загрузки данных и создании единой модели данных.

Особенности реализации методологии загрузки данных в хранилище

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

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

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

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

Поддержание историчности справочных данных
Если некоторые таблицы в хранилище еще могут функционировать без поддержки историчности, то ее обеспечение в части нормативно-справочной информации (НСИ) является жизненно важным. Компанией РДТЕХ реализован модуль управления нормативно-справочной информацией, который представляет собой систему класса Master Data Management (MDM), предусматривающую наличие главного экземпляра данных, по которому равняются локальные системы. Система интегрирована с хранилищем OFSA, адаптирована под крупные банки и предоставляет гибкий подход к количеству поддерживаемых источников для синхронизации, а также количеству потребителей синхронизированной информации. При этом модуль НСИ интегрирован с механизмом глобальных ключей хранилища, что позволяет отслеживать изменения информации непосредственно в нем, а хранилище получает финальные данные как потребитель.

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

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

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

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

Определить формат хранения информации помогают разработанные корпорацией Oracle методики в области управления жизненным циклом данных (Information Lifecycle Management Assistant).

Использование единой модели данных хранилища

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

Предотвратить возникновение подобных проблем и ускорить создание хранилища данных помогает использование централизованной архитектуры, когда модель в хранилище уже есть, и ее необходимо просто наполнить данными. При этом снижаются основные риски построения хранилища, упрощается реализация ETL и BI и создается единое восприятие предметной области.

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

Далее мы рассмотрим особенности локализации на примере единой модели данных, применяемой компанией РДТЕХ.

Независимость модели от приложений
В отличие от большинства западных решений, созданных для работы с приложениями самого вендора (это касается и Oracle, и SAP), локализованная модель данных не зависит от особенностей приложений и даже не ориентируется на них, что дает возможность сосредоточиться непосредственно на проработке российской специфики, в частности подготовке регламентной отчетности Банка России. Для ее построения требуется серьезно расширить атрибутный состав, в частности кредитная сделка должна иметь атрибут "Признак субординированного займа" (используется при расчете капитала Банка в форме 0409134), а проводки с типом СПОД должны быть связаны с символом отчета о прибылях и убытках (применяется при расчете отчета о прибылях и убытках за год с учетом СПОД).

Обеспечение межпортфельного переноса
Российской спецификой является требование по добавлению в хранилище данных о межпортфельных переносах. Допустим, банк вложил 100 ценных бумаг в торговый портфель, 20 продал, а 40 переложил в инвестиционный портфель. После очередной продажи 60 акций необходимо указать, из какого портфеля они были взяты: например, 40 из инвестиционного и 20 из торгового или наоборот. В системах-источниках российских банков данная функция реализована, однако заказчик часто желает видеть аналогичную информацию и в хранилище. Так как не все западные модели позволяют это делать, их локализация включает разработку подобных механизмов в хранилище.

Особенности покрытия предметных областей и банковских продуктов
В отличие от оригинальной архитектуры OFSA, в которой для каждого типа сделки имеется своя таблица, локализованная модель данных подразумевает для них несколько таблиц. Это объясняется тем, что на высоком уровне агрегации информация о различиях в сделках может быть излишней, однако по мере роста детализации такие сведения становятся важными и должны быть зафиксированы. Например, если для отчета нужны только дата срочной валютной сделки, ее сумма и с кем она заключена, то достаточно одной таблицы. Если же эта сделка - опцион, то она разбивается на саму сделку и стоимость права. Сделка swap также представляет собой две сделки с разными датами валютирования. Следовательно, одна таблица будет для сделок forward, где сделки swap представлены двумя записями, а для опционов будет создана другая таблица.

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

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

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

Сложности при реализации хранилищ данных

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

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

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