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

Тренды
2317
0
Александр Кондиайн, главный архитектор по хранилищам данных департамента аналитических систем, R-Style Softlab
До недавнего времени вендор заходил в банк с хранилищем данных и уже затем строил на его основе всевозможные аналитические и BI-приложения. Сегодня ситуация в корне изменилась, так как практически в каждом банке есть свое ХД, а иногда и не одно, и предложения построить рядом с ним еще одно ХД для решения какой-то специализированной задачи, например создания системы построения отчетности, встречают твердое сопротивление заказчика. В данной статье мы расскажем, как создать систему построения отчетности на базе уже имеющегося у заказчика хранилища данных.


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

Вариант № 1 — традиционный 

Первый вариант, который мы назвали традиционным, показывает, как обычно выглядит процесс (рис. 1). 

Рисунок1.jpg

Рис. 1. Схема передачи данных при реализации первого варианта 

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

Вариант № 2 — витринный подход 

Схема процесса реализации второго варианта представлена на рисунке 2. 

Рисунок2.jpg

 Рис. 2. Схема передачи данных при реализации второго варианта

Очевидно, что в данном случае шагов перекладывания данных гораздо меньше. А вот поддерживается ли при этом контроль качества входных данных — неизвестно (это остается на совести заказчика и поставщика хранилища). Особенности процессов загрузки и расчета конечных витрин также неизвестны (не исключены перекладывания данных через несколько слоёв). 
Реализованный нашей компанией проект по построению подобных витрин у одного из наших клеинтов, где RS-DataHouse являлась системой-источником данных, показал, что второй вариант также не обошелся без подводных камней. Так называемые «витрины» на деле представляют собой широкие таблицы, которые дублируют по сути все детальные данные, в том числе движения и графики. Отдельной незакрытой темой является инкрементальное обновление данных внутри витрин в середине месяца, так как некоторые отчеты строятся на ежедневной или произвольной основе. Как ведут себя в этом случае расшифровки показателей — неизвестно. 
Тем не менее, если заказчик готов гарантировать надлежащий уровень качества данных, этот подход к реализации может быть весьма перспективным. 

Вариант № 3 — построение виртуального детального слоя через представления (views) 

Данный вариант еще не применялся на практике, однако выглядит перспективным. Как следует из названия, при реализации данного варианта формируется виртуальный слой представлений (views). Его преимущества заключаются в том, что он не содержит данных и, следовательно, не занимает места. При этом для последующих процессов он неотличим от детального слоя данных (ДДС) и технологических витрин (рис. 3). 

Рисунок3.jpg

Рис. 3. Схема передачи данных при реализации третьего варианта

В данном случае процесс остается только один — расчет самих витрин ОЦБ. 
Суть подхода в том, что на системе-источнике реализуются так называемые views, которые полностью повторяют по структуре и семантике наполнения аналогичные таблицы из детального слоя RS-DataHouse. В RS-DataHouse сами таблицы удаляются либо переименовываются, а вместо них создаются объекты Oracle — Public Synonyms, которые указывают на views из системы-источника. Таким образом, для RS-DataHouse происходит незаметная подмена источника данных без необходимости переписывания какой-либо логики.
Здесь нужно сделать пару технических отступлений.

Техническое отступление 1:

Возможны ситуации, когда часть данных все-таки должна физически находиться в RS-DataHouse (например, данные из файлов Exel, введенные вручную, и т.д.). В этом случае таблицы сохраняются, но не в схеме DWH, а рядом. Конечно view объединяет данные из view слоя представлений и этой таблицы. 

Техническое отступление 2:

Возможно создание views не на стороне системы-источника, а непосредственно в RS-DataHouse. В данном случае потребуется регулировка того, не чьей стороне (в какой базе данных) будет выполняться запрос к данным и их трансформация.

Вариант № 3 имеет массу достоинств, перечислю наиболее очевидные:

  1. Существенная (минимум в два раза) экономия места по сравнению с другими подходами.
  2. Экономия времени на перекладывание данных — при условии нормальной производительности представлений.
  3. Отсутствие необходимости загружать (и перезагружать!) архивные данные, что обеспечивает экономию времени на старте проекта и при вводе в опытно-промышленную эксплуатацию.
  4. Качество данных строго соответствует качеству данных в системе-источнике — более четкое разграничение зон ответственности.
  5. Отсутствие необходимости в ETL (как в части организации его процессов, так и в части обслуживания).
  6. Для заказчика процесс реализации третьего варианта является не построением очередного ХД, а именно внедрением бизнес-приложения.

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

  1. Непредсказуемое поведение views в сложных запросах в разных условиях. Возможно падение производительности. 
  2. →Падение производительности может быть компенсировано экономией времени на многократном перекладывании данных. 
  3. В модели системы-источника может не найтись нужных суррогатных ключей для того, чтобы полностью соответствовать нашей модели данных. Например, в хранилище данных одного из производителей ПО ID счета является его 20-значный символьный номер, что не может быть простым образом трансформировано в 16-значный цифровой ID в RS-DataHouse
  4. →Тем не менее, возможны обходные решения, включая внесение изменений в модель RS-DataHouse. На данном этапе этот вопрос нужно прорабатывать.
  5. Остается проблема с «плавающими» детальными данными: при их изменении в системе-источнике расшифровка не будет соответствовать посчитанным ранее показателям.  
    1. →Справедливости ради замечу, что данная проблема так или иначе актуальна для всех рассматриваемых в этой статье вариантов реализации, в том числе для витринного подхода. Возможное решение видится в построении такой модели (структуры) технологических витрин, которая позволит полностью сохранять историчность и будет по запросу возвращать состояние данных на любой момент времени в прошлом.  
      →Другое возможное решение — хранить в агрегатах конечных отчетов ОЦБ всю необходимую информацию для расшифровки показателей.
Реализация варианта № 3


Лично для меня третий вариант представляется наиболее перспективным, поэтому хочу подробнее рассказать о его реализации. 
Для оценки работоспособности и возможных доработок был выполнен пилотный проект, воплощающий идею построения виртуального слоя представлений. В качестве внешней системы использовался тестовый стенд хранилища «Новой Афины», в котором была создана отдельная схема RSV для хранения представлений. 
В RS-DataHouse для примера была взята витрина по депозитам и выявлены все таблицы детального слоя, откуда она собирает данные. Таких таблиц оказалось 25, после анализа выяснилось, что для 18 из них необходимо построить views на стороне «Новой Афине», что и было сделано (рис. 4).

Рисунок4.jpg

Рис. 4. Пример view для лицевого счета

В базе RS-DataHouse соответствующая таблица переименована и сделан синоним на view из базы «Новой Афины» (рис. 5).

Рисунок5.jpg

Рис. 5. Необходимые манипуляции в базе RS-DataHouse



После создания необходимого слоя представлений была запущена процедура расчета витрины, которая успешно отработала и сохранила результаты в таблице. 
Однако интерфейсы «толстого» клиента требуют переработки, чтобы поддержать данный подход. Например, в центре управления метадаными для сложных представлений, которые соединяют несколько таблиц, появляется ошибка на закладке «Данные», связанная с неоднозначностью виртуального поля ROWID (рис. 6).

Рисунок6.jpg

Рис. 6. Ошибка в центре управления метадаными



В Аналитическом центре посчитанная витрина отображается корректно. Но встречаются ошибки при попытке отобрать элементы некоторых измерений (рис. 7).

 
Рисунок7.jpg

Рис. 7. Попытка отобрать измерение финансовых инструментов



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

Организационные особенности в реальных проектах  

Как было упомянуто выше, наша компания неоднократно применяла варианты 1 и 2 в реальных проектах у разных заказчиков, причем система RS-DataHouse выступала как в роли получателя данных (в варианте № 1), так и в роли поставщика данных (в варианте № 2). 
В завершение приведу основные моменты, которые стоит учесть, особенно на старте проекта реализации бизнес-приложения на базе хранилища данных от стороннего поставщика. 
  1. Традиционный вариант реализации (вариант № 1) при внедрении на внешнем хранилище данных мало чем отличается от внедрения на АБС. Возможно, качество данных будет немного лучше, чем в случае с АБС, и увеличится время конечной доставки на период обработки данных в хранилище (с Т+1 до Т+2). 
  2. Важно помнить, что, несмотря на все заверения, в начале проекта во внешнем хранилище не будет 100% необходимых для конечных задач данных. Поэтому необходимо быть готовым загружать их самостоятельно из файлов, других АБС и т.д. 
  3. Если в стороннем хранилище не окажется всех необходимых атрибутов и не будет возможности загрузить их самостоятельно, то сроки их получения увеличатся в два раза, так как будет выполняться двойная работа: выгрузка данных из АБС в ХД и выгрузка их же из ХД в конечную систему (включая анализ, написание маппингов, тестирование и прочие работы по выгрузке и загрузке данных). 
  4. Самое «тонкое» место, как всегда, — «стык» между системами. При выгрузке данных мало попасть в формат: необходимо соответствовать семантике той модели данных, в которую производится выгрузка. Например, в одной системе данные хранятся за каждый день, в другой — за период; в одной эквивалент считается на лету, в другой хранится явным образом; в одной есть проводки и полупроводки, в другой — только проводки. При перегрузке данных, особенно архивной, неверно выгруженный архив может отодвинуть проект на недели назад, и такие случаи были. 
  5. Исходя из предыдущего пункта, ключевым фактором становится квалификация команды, которая реализует выгрузку. В идеале она должна знать семантику хранения данных в обеих системах. В противном случае неизбежны итерации по массовой перезагрузке данных. Если же команда не знает ни одной из систем (например, привлекается внешний подрядчик), то это самый неудачный в плане организации вариант, приводящий к затягиванию сроков проекта и размытию зон ответственности. И такие случаи на практике тоже были. 
  6. Как показывает наш опыт, в варианте № 2 первоначальные требования к витринам данных частенько разрастаются. По мере построения системы пользователи осознают, что им необходима масса детальных данных для выверки отчетности, поэтому нужно быть готовыми к дополнительным затратам на реализацию выгрузки. 
В свете всего вышесказанного могу заверить, что построение СПО на базе уже имеющегося хранилища, задача вполне выполнимая. Главное, обратиться к профессионалам, которые помогут выбрать подходящий именно вам способ реализации и воплотить его в жизнь.

Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2017 2018 2020