Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

Банковские технологии

Оценка производительности новой версии хранилища данных «Контур»

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

Наиболее заметное снижение производительности наблюдается обычно на процессах загрузки данных в хранилище, а также при построении индексов, расчете агрегатов, выполнении запросов и пакетных расчетов. Возникновение узких мест может быть связано как с ограничениями системных ресурсов (ресурсы процессора, системы хранения данных, систем ввода\вывода), так и с неоптимальным построением запросов или с недостаточной производительностью СУБД.

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

Компанией Intersoft Lab успешно завершен проект по продуктивному нагрузочному тестированию новой версии Хранилища данных "Контур Корпорация" 3.х. Это позволило провести прогнозирование быстродействия системы для различных нагрузок, соответствующих потребностям кредитных учреждений разного масштаба и профиля деятельности. В данной статье проводится подробное обсуждение методики и результатов тестирования.

Задачи тестирования

Для построения адекватной развитию бизнеса IT-инфраструктуры важно корректно оценить риски ограничения производительности при выполнении основных операций с данными и обеспечить гарантированный запас производительности на перспективу. Поэтому целью тестирования являлось исследование производительности новой версии Хранилища данных "Контур Корпорация" на больших объемах данных при выполнении наиболее ресурсоемких операций. За рамками данного проекта оставлены вопросы оптимального конфигурирования серверного оборудования, серверного ПО и системы хранения данных. Для ограничения числа факторов, влияющих на производительность, а также с целью получения сопоставимых результатов все тесты были проведены для неизменной программно-аппаратной конфигурации (см. раздел "Результаты нагрузочного тестирования").

Архитектура хранилища данных "Контур Корпорация"

При отсутствии ограничений со стороны аппаратных ресурсов скорость выполнения операций над данными определяется архитектурными возможностями платформы ХД. Хранилище данных "Контур Корпорация" 3.х обладает значительным потенциалом, поскольку использует в качестве СУБД Oracle Database 10g release R2 Enterprise Edition, ориентированную на работу с многотерабайтными объемами данных . По результатам эталонного теста TPC-H, являющегося фактическим стандартом для оценки производительности задач поддержки принятия решений, Oracle Database 10g демонстрирует лучшую производительность на базах данных объемом 300 ГБ, 1 ТБ и 3ТБ.

Для увеличения производительности хранилища данных "Контур Корпорация" в базовой конфигурации системы использованы дополнительные опции СУБД по расширению возможностей функционирования Хранилища данных:

  • Опция параллельного выполнения запросов (Parallel Query Option including bitmap indexes and parallel bitmap-star query), позволяющая значительно ускорить выполнение определенных видов запросов, в частности, запросов типа "звезда" и запросов, включающих столбцы с низкой кардинальностью.
  • Опция партиционирования (Partitioning), уменьшающая время обработки больших таблиц за счет физического деления больших таблиц на секции по логическому условию.

Особенностью архитектуры Хранилища данных "Контур Корпорация" 3.х является выделение двух физически изолированных областей (см. Рис. 1): области временного хранения (или Staging Area) и области постоянного хранения (собственно Хранилища данных).

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

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

При оценке производительности решения с новой архитектурой хранения данных, особое внимание следовало уделить пропускной способности подсистемы ввода данных.

Рис. 1. Архитектура системы на базе Хранилища данных "Контур Корпорация"

Сценарии тестирования, модели нагрузки и тестовая БД

Тестирование проводилось на модели данных бухгалтерского учета кредитной организации, содержащей более 30 взаимосвязанных объектов (планы счетов ЦБ РФ, символы ОПУ ЦБ РФ, лицевые счета, субсчета, бухгалтерские документы, операции по лицевым счетам и субсчетам, дневные, месячные, квартальные и годовые обороты по лицевым счетам и др.) Сценарии тестирования разрабатывались с таким расчетом, чтобы провести моделирование нагрузки на систему в процессе выполнения наиболее ресурсоемких операций над данными хранилища. В фокусе исследования оказались операции пакетной загрузки объектов и расчета агрегатов. Причиной повышенного внимания к этим операциям явилось и то, что время их выполнения не может быть сокращено путем оптимизации регламента эксплуатации системы.

Для создания нагрузки использовалось несколько нагрузочных профилей, каждый из которых соответствовал уровню нагрузки на подсистему ввода данных системы "Контур Корпорация" в процессе периодической загрузки данных. Объемы данных соответствовали реальным объемам данных для многофилиальных банков с количеством филиалов от нескольких единиц до нескольких десятков. Характеристики нагрузочных профилей приводятся в таблице 1.

Таблица 1. Профили нагрузки

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

  • Загрузка данных о контрагентах АБС (заполнение банка данных "Клиенты")
  • Загрузка лицевых счетов (заполнение банка данных "Лицевые счета")
  • Загрузка дневных остатков лицевых счетов (заполнение банка данных "Дневные остатки лицевых счетов")
  • Загрузка дневных оборотов лицевых счетов (заполнение банка данных "Дневные обороты лицевых счетов")
  • Загрузка операций по лицевым счетам (заполнение банка данных "Бухгалтерские операции")
  • Загрузка бухгалтерских документов (заполнение банка данных "Бухгалтерские документы")

Методика тестирования предполагала раздельную регистрацию времени выполнения операций загрузки данных в область временного хранения и операций переноса данных из Staging Area в хранилище для каждого загрузочного профиля.

Сценариями тестирования предусматривалась также регистрация времени расчетов агрегатов, выполняемых по следующим алгоритмам:

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

2. Агрегация дневных остатков лицевых счетов по плану показателей с расчетом остатков по статьям плана за период (день, месяц, квартал)

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

Результаты нагрузочного тестирования

Тестирование проводилось в Центре Высоких Технологий компании Hewlett-Packard в Москве, на оборудовании, предоставленном компанией Hewlett-Packard. В качестве сервера базы данных для проведения тестирования был выбран относящийся к среднему классу, оптимальный по соотношению цена/производительность сервер HP Integrity rx8640. Характеристика аппаратной платформы, использованной для замеров производительности, представлена в таблице.


Таблица 2. Характеристика аппаратной платформы

 

В ходе тестирования последовательно осуществлялась загрузка в Хранилище блоков данных объемом от 1,3 Гб до 25,5 Гб, соответствующих нагрузочным профилям. Окончательный размер БД составил около 100 Гб.

Загрузка в область временного хранения выполнялась с использованием утилиты массовой загрузки данных СУБД Oracle SQL*Loader. Исходные данные представляли собой текстовые файлы стандартизованного формата. Загрузка велась в один поток. Перенос данных из Staging Area в хранилище выполнялся штатными механизмами системы и включал обязательный этап системных проверок, выполняемых с целью очистки и верификации первичных данных.

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


Таблица 3. Результаты замеров времени выполнения операций по загрузке в ХД данных из внешних источников

В ходе выполнения операций пакетной загрузки не было зафиксировано падения производительности сервера БД на исследованных объемах данных. Этот вывод относится как к операциям загрузки данных в область временного хранения, так и к операциям переноса верифицированных данных в хранилище.

Зависимость времени загрузки от объема загружаемых данных представлена на Рис. 2. Линейный характер зависимости времени выполнения операций от нагрузки свидетельствует о хорошей масштабируемости программно-аппаратного комплекса. Коэффициенты множественной детерминации (R2) для соответствующих линейных трендов приводятся на Рис. 2.

Рис. 2. Зависимость времени загрузки данных от объема данных


Результаты тестов по замеру производительности процедур агрегации, относящиеся к 3,5 млн лицевых счетов, представлены в таблице 4. Очевидно, что система способна обеспечивать требуемое быстродействие при выполнении процедур агрегации данных.


Таблица 4. Результаты замеров времени расчета агрегатов

На основе времени выполнения операций и количества объектов вычислялся индекс производительности системы (количество объектов, обрабатываемых в секунду). Расчетные индексы производительности операций загрузки данных в Хранилище данных "Контур Корпорация" представлены в таблице 5.


Таблица 5. Расчетные индексы производительности операций загрузки данных в Хранилище данных "Контур Корпорация"

Усредненные индексы производительности операций загрузки данных из внешних источников в хранилище данных составили:

  • 17000±1000 объектов/с для загрузки в Staging Area,
  • 1900±200 объектов/с для переноса из в область постоянного хранения,
  • 1700±200 объектов/с для последовательного переноса из внешних источников в Staging Area и далее в область постоянного хранения.

Прогнозирование производительности

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

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

Для формирования комплекта типовых загрузочных пакетов данных проведена классификация кредитных учреждений на основании анализа специализации банков, размеров дистрибьюторской сети, объема и структуры клиентской базы. Выделено четыре группы банков:

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

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

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

4 группа - крупные розничные банки, клиентами которых являются более 1.5 млн. частных лиц.

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

По каждой группе банков на основании моделей производительности рассчитывалось:

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

Результаты моделирования представлены в таблицах 6 и 7.

Таблица 6. Расчетное время загрузки в ХД данных одного опердня


Таблица 7. Расчетное время загрузки в ХД данных архивного года

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

Подведение итогов

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

Испытания показали, что конфигурация системы, использующая в качестве сервера БД сервер компании Hewlett-Packard HP Integrity rx8640, обеспечивает высокий уровень производительности. Время выполнения ресурсоемких операций загрузки и обработки данных не превышает критических для бизнеса значений. Так, загрузка в хранилище 1 млн лицевых счетов или 1 млн бухгалтерских документов занимает менее 10 минут, загрузка 1 млн остатков лицевых счетов выполняется за 5 минут, агрегация остатков лицевых счетов по плану счетов ЦБ РФ выполняется менее, чем за 4 минуты для 3,5 млн лицевых счетов.

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

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

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

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