CC BY
45
Использованные источники:
1. Кальницкая И.В. Учетно-аналитическая концепция интегрированной информационной системы для целей управления организацией: теория и методология: автореф. дис. канд. экон. наук. Екатеринбург, 2011.
2. Тхагапсо М.Б. Комбинирование как эффективное направление диверсификации производства (по материалам сахарной промышленности Краснодарского края): дис. канд. экон. наук. Краснодар, 1997.
3. Вайкок М.А. Оценка влияния бизнес-процессов на эффективность деятельности промышленного предприятия // Российское предпринимательство. 2014. № 8. С. 71-82.
4. Тхагапсо М.Б., Галицкая Ю.Н. Методические основы прогнозирования финансовой устойчивости организации // Управление экономическими системами. 2014. № 4. С. 124-135.
5. Положение по бухгалтерскому учету «Оценочные обязательства, условные активы и условные обязательства» (ПБУ 8/10): приказ Минфина РФ от 13.12.10 г. №167н: [в ред. от 06.04.15 г.] // СПС КонсультантПлюс. М., 2015.
УДК: 004.62
Тазеева Д.Л. студент 4 курса
Институт цифровой экономики и информационных технологийРЭУ им. Г. В. Плеханова Российская Федерация, г. Москва ХРАНИЛИЩЕ ДАННЫХ В КОММЕРЧЕСКОМ БАНКЕ: ОСОБЕННОСТИ АРХИТЕКТУРЫ И ВОЗМОЖНОСТИ
ПРИМЕНЕНИЯ
Аннотация. В данной статье обозначены основные проблемы, возникающие в коммерческом банке из-за многообразия источников данных и их объема, а также рассмотрены пути решения данной проблемы на примере технологии хранилища данных. Рассмотрена подробная архитектура хранилища, взаимосвязь его уровней и применяемые программные продукты, представляющие собой один из возможных вариантов реализации архитектуры.
Ключевые слова: хранилище данных, архитектура систем хранения данных, большие данные, обработка данных, коммерческий банк
Tazeyeva D.L. Student
4th year, Institute of digital economy and information technology Plekhanov Russian University of Economics
Russia, Moscow
DATA WAREHOUSE IN A COMMERCIAL BANK: ARCHITECTURE AND APPLICATION CAPABILITIES
Abstract: The article outlines the main problems that arise in commercial banks due to the variety of data sources and their size, as well as possible solutions of this problem on the example of data storage technology. The detailed architecture of the storage, the relationship of its levels and the applied software products, which are one embodiment of the many possible, are considered.
Keywords: data storage, storage architecture, big data, data processing, commercial bank
Введение
На сегодняшний день объем получаемой и обрабатываемой информации в компаниях по всему миру постоянно увеличивается, а влияние «больших данных» на бизнес становится все более значимым. Хранение непрерывно увеличивающегося огромного массива данных, требует постоянно возрастающих затрат. Согласно информации, представленной The InfoPro, 1000 крупнейших компаний США в среднем увеличивают свои траты, связанные с хранением данных на более чем 50% в год. Условия жесткой конкуренции, а также возросшие риски, связанные с потерей данных позволяют экономически обосновать применение проектов на основе систем хранения данных - комплекса программно-аппаратных решений в части организации хранения данных, а также обеспечения гарантированного доступа к ним. Для успешного применения современных решений в сфере хранения и обработки данных, необходимо понять ее особенности, а также проанализировать существующие решения, предлагаемые поставщиками бизнесу.
Предпосылки использования хранилищ данных в банковской сфере
Большое количество банковских автоматизированных систем не только увеличивает скорость обслуживания клиентов и повышает качество предоставляемых услуг, но ежедневно создает огромное количество новых данных: как о новых клиентах, так и о финансовых операциях, прошедших через систему, будь то платеж или перечисление средств. В банковской сфере объемы хранимых и обрабатываемых данных ежегодно растут, а использование множества банковских информационных систем в отделениях, разделенных территориально и/или принадлежащих разным филиалам или бизнес-подразделениям, влечет за собой большое разнообразие хранимых данных, принадлежащих одному и тому же головному офису. Это порождает проблему использования этих данных, т.к. анализировать и строить отчетность с разрозненными данными (не только территориально, но и по используемому формату) достаточно затруднительно.
Реляционные СУБД, используемые информационными системами, обеспечивают транзакционность вносимых изменений и максимизируют скорость их выполнения, однако не способны предоставить пользователю
возможность формировать и отправлять произвольные запросы к системе и не имеют возможность хранить данные на большую глубину. Подобные ограничения делают невозможным анализ и эффективное использование данных, а также построение отчетности на их основе.
Решение перечисленных выше вопросов предоставляет новая технологии организации баз данных - технология хранилищ данных. Впервые определение понятия "хранилище данных" было дано Уильям Г. Инмоном, как «предметно-ориентированная, интегрированная, содержащая исторические данные, не разрушаемая совокупность данных, предназначенная для поддержки принятия управленческих решений».
Преобразование данных
Условно можно выделить 3 состояния, в которых могут находится данные с момента их появления до потребления конечными пользователями:
1. Источники данных.
На источниках данные могут храниться в виде неформатированных данных, т.е. иметь различное представление (например, для чисел это может означать разное количество разрядов после запятой)
2. ETL
ETL (с англ. Extarct, Transform, Load) - это процесс выгрузки данных из источника, их преобразование и последующая загрузка в хранилище данных. На данном этапе формируются сквозные уникальные суррогатные ключи над натуральными ключами, полученными из источников; производится унификация типов, определяется единый формат версионности хранения данных.
3. Хранилище данных
Непосредственно в самом хранилище данные лежат в унифицированном виде, все пользовательские запросы в качестве источника используют данные, находящиеся на данном этапе.
Архитектура хранилища данных
В хранилище данных выделяют три основных слоя:
ODS (Operational Data Storage) - Операционный слой данных. Источником этого уровня являются системы, работающих в режиме реального времени. Загрузка данных в ODS происходит с минимальной трансформацией данных из систем-источников. Слой необходим для того, чтобы получить срез аналитики в необходимый пользователю момент времени. При этом данный слой не хранит историю изменений и неактуальные данные. Для того, чтобы обеспечить доступ к данным, полученные, например, месяц назад, необходимо обратиться к основному хранилищу данных. Именно поэтому со слоя ODS берется ежедневный срез, выступающий в качестве одного из источников следующего уровня, и таким образом, данные из систем, работающих в режиме реального времени, также попадают в общее хранилище данных.
DDS (Detailed Data Storage) - Детальный слой данных. На этот уровень данные попадают после преобразования ETL-потоком. Однако использовать
таблицы DDS для аналитики и построения отчетности концептуально неверно, т.к. возможны расхождения из-за разной логики формирования объектов в разных системах-источниках. Более того, на данном слое данные хранятся в разрезе-систем источников, и для того, чтобы получить аналитику на уровне всей компании, сперва нужно эти данные объединить.
CDM (Common Data Model) - Унифицированный слой данных, объединяющий данные разных таблиц-источников воедино. Именно данные с этого уровня используются для построения
ежедневной/еженедельной/ежемесячной отчетности и используются подразделениями банка для аналитики.
Общая концептуальная схема ХД представлена на рис.1.
Рис.1. концептуальная схема хранилища данных коммерческого банка Данная схема наглядно демонстрирует взаимосвязь описанных выше слоев. Рассмотрим более подробно, каким образом взаимодействуют слои, а также изучим роль, которую выполняют указанные программные продукты при переходе данных с одного уровня на другой.
Первоначально выгрузка данных систем делятся на два потока: выгрузка on-line и off-line. On-line выгрузка происходит при помощи CDC (Change Data Capture) - захвата изменений. Суть CDC в том, что захватываются все изменения на источнике, произошедшие с момента последнего успешного построения объекта-приёмника. Данные систем через CDC попадают в оперативный клад (ODS), который обеспечивает данные для on-line сервисов и оперативной отчетности.
Как упоминалось выше, срезы ODS являются одним из источников слоя DDS, что и демонстрирует схема. Другим источником для наполнения уровня DDS выступают непосредственно данные систем, выгрузка которых происходит при помощи ETL. Детальный слой данных выступает в роли
источника для следующего слоя - CDM, области, которая используется наиболее активно. Вся управленческая и регуляторная отчетность для банка строится над этими двумя областями.
Однако помимо активно используемых данных, существует также пласт устаревших данных, которые необходимо хранить для архива. Здесь стоит отметить, что дополнительное дисковое пространство системы управления базами данных Teradata значительно дороже, чем хранение такого же объема данных в файловой системе Hadoop, поэтому данные, которые не используются в аналитике и отчетности, а также сами копии этих отчетов, переносятся для хранения на Hadoop при помощи ETL скриптов.
Data Lake или «озеро данных», располагающееся внизу схемы, представляет собой репозиторий, в котором хранятся архивные данные, выгруженные из Teradata и «сырые», необработанные данные в их исходном виде. Подобное «озеро» позволяет недорого хранить большие массивы данных, причем цель хранения может варьироваться от необходимости иметь все материалы на случай проверки до потенциальной ценности данных в будущем.
Возможности использования хранилищ данных в коммерческих банках
Как было упомянуто ранее, единое хранилище данных позволяет соединить данные, до этого хранившиеся в разных информационных системах, вследствие чего появляется возможность провести всесторонний анализ деятельности коммерческого банка. Так, данные эквайринговой системы могут быть сопоставлены данным, полученным по использованию мобильного приложение, ведущегося в другой системе. Это закладывает основу для более точного сегментирования клиентов, выявления типичных поведенческих шаблонов и определения наиболее
востребованных/прибыльных банковских продуктов. С учетом того, что в хранилище данных содержится информация за весь требуемый временной интервал - вплоть до нескольких десятилетий, создаваемые на их основе витрины данных - особые срезы хранилища, содержащие массив данных в необходимом для пользователя разрезе - позволяют проводить анализ данных, направленный на выявление трендов, сезонных зависимостей и позволяют рассчитать динамику эффективности функционирования отделений.
Автоматический расчет отчетности позволяет ускорить процесс принятия управленческих решений благодаря минимизации времени, прошедшего с момента получения данных до непосредственного выпуска отчета. Ускорение процесса выпуска отчетности происходит благодаря нескольким факторам. Во-первых, работа сервера хранилища не мешает работе операционистов, и получение новых данных не накладывает на работников отделений дополнительных трудозатрат. Во-вторых, в хранилище помимо детальной информации содержатся и заранее рассчитанные агрегированные значения, а содержащаяся в хранилище
архивная информация всегда доступна для включения в отчеты. Итогом выпуска отчетности по регламенту становится снижение риска ошибок, связанных с ручным расчетом и уменьшение транзакционных расходов на сбор информации за каждый отчетный период. Заключение
В статье были рассмотрены проблемы, возникающие с анализом и обработкой данных, получаемых коммерческими банками в процессе деятельности банковских автоматизированных систем. Описанная трехуровневая архитектуры хранилища данных представляет собой одно из возможных решений поставленной проблемы. Однако стоит отметить, что несмотря на обширные возможности, возникающие в результате построения хранилища, следует помнить о том, масштабы хранилищ данных достаточно велики, а наличие различных уровней сказывается не только на качестве поставляемых данных, но и стоимости поддержания всей системы, поэтому положительный эффект для бизнеса от масштабного и дорогостоящего проекта может быть получен только при его правильной организации.
Использованные источники:
1. Бирюков А. СХД в России: перспективы развития // Системный администратор. М.: ООО «Издательский дом «Положевец и партнеры», 2016.
2. Баженов Д., Золотухина Е. Применение технологий Big Data в банковской сфере // Международный научно-технический журнал «Теория. Практика. Инновации». М.: 2018.
3. Reinschmidt J., Francoise A. Business Intelligence Certification Guide. International Technical Support Organization, 2000.
4. Хранилища данных: основные архитектуры и принципы построения в реляционных СУБД // http://www.bipartner.ru URL: http://www.bipartner.ru/downloads/DW_Arch.pdf (дата обращения: 15.10.2018).
5. Дяченко О. Хранилище данных: позитивный опыт внедрения и развития // Национальный банковский журнал (NBJ). 2016. №6.
6. Ахватова И. Практический опыт организации аналитической обработки данных коммерческого банка // Банковские технологии. 2017.
