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

Публикации

Byte

Производительность хранилищ данных на 64-разрядной платформе

Требования к производительности хранилищ данных

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

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

Преимущества 64-разрядной архитектуры

Аппаратная платформа

Хорошую основу для решения перечисленных проблем создают платформы 64-разрядной архитектуры на базе процессоров Intel® Itanium® 2. Эти процессоры в настоящее время работают на частоте до 1.66ГГц, используя 128-разрядную шину данных с частотой 667МГц, имеют кеш L3 объемом до 9Мбайт, что обеспечивает пропускную способность ввода/вывода до 10Гбайт/с. К тому же в 64-разрядной архитектуре нет ограничений на объем напрямую адресуемой памяти, присущих 32-разрядным процессорам. Таким образом, больше памяти доступно для выполнения сложных запросов и поддержки основных операций с базой данных. Архитектуру EPIC характеризует улучшенный параллелизм обработки данных, что обеспечивает более близкую к линейной масштабируемость. Все это позволяет задействовать в обработке до 64 процессоров с лучшей отдачей производительности от одного процессора, чем в 32-разрядных системах. Улучшенная архитектура шины повышает производительность за счет передачи большего количества данных между кэшем и процессорами за более короткий период времени. Больший объем кэша, в свою очередь, обеспечивает более эффективное использование ресурсов процессора. Потенциал для наращивания количества процессоров и оперативной памяти свыше 32Гбайт в 64-разрядных платформах создает прекрасную основу для создания решения с высокой масштабируемостью.

Системное ПО

Возможности платформ на основе Intel® Itanium® 2 будут в полной мере задействованы при работе с системным ПО Windows Server 2003 Enterprise Edition for 64-Bit Itanium-based Systems, Datacenter x64 Edition и SQL Server 2000 IA64 (64-bit) Enterprise Edition.

ОС Windows Server 2003 для платформы Itanium оптимизирована для исполнения 64-разрядных приложений. Эта система поддерживает до восьми (Enterprise Edition) или 64 (Datacenter Edition) процессоров в режиме симметричного мультипроцессирования и до 1 Тбайт оперативной памяти. Данная редакция Windows имеет в настоящее время наилучшие параметры масштабируемости.

Microsoft SQL Server 64-bit Edition использует радикальное преимущество доступа к большим объемам оперативной памяти и возможностям параллельной обработки, которое предоставляет 64-разрядная платформа по сравнению с 32-разрядной. Это обеспечивает существенный выигрыш в производительности и масштабируемости решений.

Процессы реляционной обработки данных - это та область, где в полной мере проявляются плюсы SQL Server 64-bit Edition по сравнению 32-разрядной версией, когда многие ресурсы сервера ограничены лимитом памяти в два-три Гбайт (например, пространство для сортировки, хеш-таблицы, используемые при соединениях и агрегировании, память для создания индексов, кэш компилированных планов запросов). Производительность при исполнении очень больших и сложныx запросов, которые не могут разместиться в относительно небольшом виртуальном адресном пространстве 32-разрядной платформы, может резко упасть в связи с ожиданием ресурсов, вызванным обращениями к страничному файлу. Особенно это заметно при выполнении запросов к данным хранилища, которые затрагивают большие объемы информации. Большое виртуальное адресное пространство 64-разрядной системы позволяет эти же запросы полностью разместить в оперативной памяти, и в итоге они выполняются очень быстро.

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

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

Опыт портирования

В качестве иллюстрации преимуществ построения информационно-аналитических систем на базе 64-разрядной архитектуры рассмотрим практический опыт портирования финансового хранилища данных "Контур Корпорация", компании Intersoft Lab (www.iso.ru), с 32-рязрядной на 64-разрядную программно-аппаратную платформу Microsoft и Intel.

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

Архитектура системы

В архитектуре финансового хранилища данных Контур Корпорация можно выделить серверную и клиентскую части (рис.1).

Основа серверной части - база данных, работающая под управлением Microsoft SQL Server. В ней, кроме самих таблиц данных, сосредоточена основная бизнес-логика системы, реализованная в хранимых процедурах. Это, например, процедуры, создающие новые данные в хранилище, обеспечивающие целостность данных с точки зрения бизнес-объектов (выполнение двусторонних проводок) и выборку данных, некоторые расчеты, преобразующие первичные данные. К серверной части системы также относится библиотека прикладных классов на языке Python. На нем разработаны процедуры загрузки данных в хранилище, очистки первичных данных, выполнения расчетов. Методы классов библиотеки представляют более высокоуровневый и предметный интерфейс, чем хранимые процедуры базы данных. При этом фактически они выступают как оболочка для вызова хранимых процедур.


Рис. 1. Архитектура финансового хранилища данных "Контур Корпорация"

Клиентская часть представляет собой набор экранных интерфейсов для пользователей системы. Этот слой реализован как приложение на языке Borland C++ Builder. Часть отчетных форм представляется пользователям при помощи средств Microsoft Office (Excel, Word). Клиентская часть взаимодействует с серверной как посредством прямых вызовов хранимых процедур, так и используя объекты библиотеки прикладных классов.

Данные поступают в Хранилище в виде XML-файлов, основанных на схеме универсальных форматов хранилища. Загрузка информации обеспечивается пакетными ETL-процессами, к которым предъявляются высокие требования по производительности. Как следствие, они требуют от платформы эффективной параллельной обработки данных.

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

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

Выбор платформы

Около двух лет назад в компании Intersoft Lab было принято решение о портировании системы "Контур Корпорация" на 64-разрядную платформу. На тот момент времени единственной 64-разрядной платформой Intel была платформа Intel Itanium 2. Эта платформа уже прошла период "ошибок молодости", была выпущена вторая "мажорная" версия процессоров и появилась серьезная софтверная поддержка в виде ОС Microsoft Windows 2003 и сервера базы данных Microsoft SQL Server 2000 IA64.

Несколько позже на рынке появился 64-разрядный процессор от фирмы AMD, имеющий принципиально другую архитектуру. Но реальной поддержки этой аппаратной платформы в СУБД от Microsoft в то время не было. Поэтому все работы проводились на платформе Intel Itanium 2 и SQL Server 2000 IA64.

В настоящее время Intel поддерживает также платформу х64. В конце 2005 года вышла версия Microsoft SQL Server 2005, в которой появилась полноценная поддержка архитектуры х64. Соответственно в планах Intersoft Lab - портирование системы на новую версию SQL Server (2005) и поддержка обеих 64-разрядных аппаратных платформ.

Элементы портирования системы

Исходя из архитекутры системы "Контур Корпорация" были выявлены следующие возможности по портирования на платформу IA64 (рис.2):

  • портирование базы данных;
  • портирование интерпретатора Python и библиотеки классов системы;
  • общая оптимизация системы на новой платформе.


Рис. 2. Портирование системы на 64-разрядную платформу


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

Интерпретатор Python представляет собой свободно распространяемое ПО (open software), основные работы по его портированию его на платформу IA64 были выполнены разработчиками этого языка программирования. Поэтому для выполнения процедур Python на 64-разрядном сервере достаточно было установить на нем соответствующую версию интерпретатора. Дополнительно было проведено портирование библиотеки классов, что диктовалось особенностями реализации системы "Контур Корпорация". В библиотеке классов системы присутствует ряд расширений языка Python, реализованных на языке С++, в частности, собственный драйвер работы с базой данных. Портирование этих расширений заняло основное время. При этом активно использовались средства разработки компании Intel (компилятор, VTune и другие), с помощью которых позволили провести отладку и оптимизацию кода на новой платформе.

Последним шагом в портировании системы стала общая ее оптимизация для использования мощности, предоставляемой платформой. С этой целью некоторые расчеты, которые ранее выполнялись на Python, были реализованы в виде хранимых процедур SQL Server. Эти расчеты требуют обработки объемов данных в несколько гигабайт, включая данные, индексы, временные данные расчетов. На 32-разрядной платформе такой перенос не дал бы большого эффекта из-за ограничений на размер оперативной памяти, используемой SQL-сервером. Сервер был бы вынужден постоянно работать с жестким диском, что на порядки медленнее по сравнению с использованием оперативной памяти (кэша), которую обеспечивает 64-разрядная платформа.

Сравнительное тестирование

В ходе тестирования планировалось выяснить, как влияют на повышение производительности системы "Контур Корпорация" различные подходы при переходе на 64-разрадную платформу: портирование базы данных, библиотеки классов, общая оптимизация системы.

В реальных условиях функционирования кредитной организации допустимое время загрузки в Хранилище данных из нескольких десяткой филиалов (примерно 500 тысяч документов ежедневно), их выверки, консолидации, расчетов и выпуска основных форм обязательной отчетности Банка России (например, 101 и 102), составляет не более 5-6 часов. Эти требования были заложены в план тестирования системы.

Ниже обсуждаются результаты тестирования производительности системы "Контур Корпорация" на реальных данных кредитной организации, которая имеет 30 филиалов и около 250 тыс. лицевых счетов. Ежемесячно в хранилище поступает несколько сот тысяч документов. На момент тестирования глубина архивных данных достигала 1 года. Тестированию были подвергнуты основные процессы, характерные для хранилища данных, - первоначальная загрузка данных, их последующая обработка и использование данных. Сравнительное тестирование проводилось на двухпроцессорном сервере на базе 64-разрядной платформы и на четырехпроцессорном сервере на базе 32-разрядной платформы.

Тестовый стенд

  Сервер на 32-рязрядной платформе Intel HP Ptoliant DL380 Сервер на 64-разрядной платформе Intel HP Integrity rx2600
Процессоры Intel@ Xeon@ 2,8 ГГц, количество - 4 шт. Intel Itanium@2 1,3 ГГц, количество - 2 шт.
ОЗУ 3 Гб 8 Гб
Диск 1 диск SCSI 98 ГБ 1 диск SCSI 68 ГБ
ОС Windows 2003 Server 32-bit Windows 2003 Server 64-bit
Сервер БД MS SQL Server 2000 32-bit Enterprise Edition MS SQL Server 2000 IA64 (64-bit) Enterprise Edition

Были выполнены стандартные настройки ОС и СУБД, рекомендуемые производителем.

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

Распределение функциональности системы между процедурами

Процесс Хранилища данных Функция системы "Контур Корпорация" Процедуры Python Хранимые процедуры
Первоначальная загрузка данных Загрузка лицевых счетов, их остатков и оборотов, клиентов, документов с проводками Обработка входящих XML-файлов, выполнение логических проверок данных Запись в таблицы новых записей, изменение (удаление)
Последующая обработка данных Агрегация и консолидация данных бухгалтерского учета Расчет оборотов и остатков за день, месяц, год по иерархиям ЦФО, планам счетов и валютам Запись в таблицы новых записей, изменение (удаление)
Использование данных Расчет форм: 101 (баланс в тысячах руб), 102 (доходы и расходы), ФОР Формирование параметров запросов к хранимым процедурам, выполнение алгоритмов округления, основных расчетов Выборка групп записей, частичное выполнение расчетов

Портирование базы данных

Тестирование системы после портирования базы данных
Задача 32-разрядная платформа Intel 64-разрядная платформа Intel
Загрузка данных 5-7 часов 2,5-3 часа
Консолидация и агрегация 20 часов 8 часов
Расчет 101 формы 30 минут 10 минут
Расчет 102 формы 30 минут 10 минут
Расчет ФОР Не измерялось 15 минут

Результаты тестирования системы после портирования базы данных на подтвердили преимущество применения 64-разрядной архитектуры. Время загрузки данных в хранилище и время агрегации и консолидации данных, поступающих в хранилище сократилось в 2,5 раза, а время расчетов форм 101 и 102 - в 3 раза (рис. 3).


Рис. 3. Журнал загрузки данных по филиалу: общее время загрузки и некоторые подробности процесса.

Рассмотрим подробнее, за счет чего было достигнуто это повышение производительности. Поскольку процедуры Python выполнялись на 64-разрядном сервере в режиме эмуляции 32-разрядного процесса, то общее повышение производительности можно считать полностью "заслугой" SQL. Несомненно, что на эти результаты существенным образом повлияло эффективное использование большего размера оперативной памяти (8 Гб против 3Гб). Процедуры Python в лучшем случае "не портили" общую картину. Однако план загрузки процессоров свидетельствовал о том, что около 70% мощности 64-разрядного сервера были использованы именно 32-разрядными процедурами Python.

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

Портирование библиотеки классов

После портирования библиотеки классов тестированию была подвергнута функциональность системы, реализованная в равной мере хранимыми процедурами и процедурами на языке Python, - агрегация и консолидация данных. Тестирование показало следующие результаты: если на 32-разрядной платформе время выполнения задачи составляло 20 ч., а на 64-разрядной платформе Intel после портирования базы данных - 8ч., то в системе "64-разрядная платформа Intel + портирование базы данных + портирование библиотеки классов" оно сократилось до 2, 5 ч.

Как видно, этот способ портирования дает неплохие результаты: время агрегации и консолидации данных уменьшилось в 8 раз. При этом изменился план загрузки процессоров сервера. Процедуры Python и хранимые процедуры практически поровну поделили между собой ресурсы процессоров. Поэтому можно предположить, что увеличение производительности системы было обусловлено обоими факторами - повышенной скоростью обработки данных фиксированной точности 64-разрядными процедурами Python и высвобождением ресурсов сервера для функционирования СУБД.

Общая оптимизация системы

На следующем этапе тестирования процедура консолидации и агрегации первичных данных была реализована в виде хранимой процедуры (рис.4).

Рис. 4. Макрос, выполняющий агрегацию планов показателей, до (слева) и после (справа) перевода агрегации на хранимую процедуру

Тестирование показало следующие результаты: если на 32-разрядной платформе время выполнения задачи составило 20 ч, а на 64-разрядной платформе Intel после портирования базы данных - 8 ч, то в системе "64-разрядная платформа Intel + портирование базы данных + общая оптимизация системы" оно сократилось до 45 мин.

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

Итоги тестирования

Результаты тестирования полностью подтвердили преимущество решений на базе 64-разрядной архитектуры:

  • время выполнения операций после портации базы данных уменьшилось в 2,5-3 раза;
  • время выполнения операций после портации базы и библиотеки классов данных уменьшилось в 5-8 раз;
  • время выполнения операций после оптимизации системы сократилось в 8-26 раз.

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