Производительность хранилищ данных на 64-разрядной платформе
Требования к производительности хранилищ данных
Для хранилищ данных, где накапливаются огромные объемы информации, традиционно характерны проблемы производительности — как на этапе пакетной обработки данных, так и при выполнении сложных аналитических запросов, результатом которых становятся большие объемы детальной информации. Наиболее распространенный программный подход к построению информационных хранилищ — использовать реляционную базу данных в качестве «движка» системы. Однако даже наилучшей модели хранения данных недостаточно, чтобы обеспечить необходимые параметры производительности решения. Следует оптимизировать построение программно-аппаратного комплекса в целом.
Одно из важнейших требований к комплексному решению — его масштабируемость. Очевидно, что многие проблемы проявляются только в процессе многолетнего накопления данных в хранилище, поэтому при выборе ПО и соответствующей аппаратной платформы необходима достоверная оценка ожидаемых объемов данных. Масштабируемость позволяет эффективно решать проблемы роста объемов данных и служит основой для долгосрочного обеспечения производительности системы. С одной стороны, для оптимизации масштабируемости необходимо соотносить ожидания роста объемов данных с потребностями различных процессов их обработки: пакетной, выполнения аналитических запросов и даже онлайновой обработки транзакций. Одновременно, учитывая предполагаемый рост объемов обрабатываемых данных, можно прогнозировать потребность в вычислительных ресурсах аппаратной платформы (объем оперативной памяти сервера, число процессоров, объем и производительность дисковой подсистемы). При этом потребности роста не должны приводить к полной замене программно-аппаратной платформы в короткие промежутки времени. Их следует обеспечивать путем плавной модернизации существующей системы, чтобы максимизировать загрузку имеющихся ресурсов в любой промежуток времени.
Преимущества 64-разрядной архитектуры
Аппаратная платформа
Хорошую основу для решения перечисленных проблем создают платформы 64-разрядной архитектуры на базе процессоров Intel Itanium 2. Эти процессоры в настоящее время работают на частоте до 1,66 ГГц, используя 128-разрядную шину данных с частотой 667 МГц, имеют кэш L3 объемом до 9 Мбайт, что обеспечивает пропускную способность ввода-вывода до 10 Гбайт/с. К тому же в 64-разрядной архитектуре нет ограничений на объем напрямую адресуемой памяти, присущих 32-разрядным процессорам. Таким образом, больше памяти доступно для выполнения сложных запросов и поддержки основных операций с базой данных. Архитектуру EPIC характеризует и улучшенный параллелизм обработки данных, что обеспечивает более близкую к линейной масштабируемость.
Все это позволяет задействовать в обработке до 64 процессоров с лучшей отдачей в плане производительности от одного процессора, чем в 32-разрядных системах. Улучшенная архитектура шины повышает производительность за счет передачи большего количества данных между кэшем и процессорами за более короткий период времени. Больший объем кэша, в свою очередь, обеспечивает более эффективное использование ресурсов процессора. Потенциал для наращивания числа процессоров и объема оперативной памяти свыше 32 Гбайт в 64-разрядных платформах создает прекрасную основу для создания решения с высокой масштабируемостью.
Системное ПО
Возможности платформ на основе Intel Itanium 2 будут в полной мере задействованы при работе с системным ПО Microsoft 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-разрядной версией, когда многие ресурсы сервера ограничены лимитом памяти в 2—3 Гбайт (например, пространство для сортировки, хеш-таблицы, используемые при соединениях и агрегировании, память для создания индексов, кэш компилированных планов запросов). Производительность при исполнении очень больших и сложныx запросов, которые не могут разместиться в относительно небольшом виртуальном адресном пространстве 32-разрядной платформы, может резко упасть в связи с ожиданием ресурсов, вызванным обращениями к страничному файлу. Особенно это заметно при выполнении запросов к данным хранилища, которые затрагивают большие объемы информации. Большое виртуальное адресное пространство 64-разрядной системы позволяет полностью разместить эти же запросы в оперативной памяти, и в итоге они выполняются очень быстро.
Можно отметить еще ряд операций, выигрывающих в производительности от существенного увеличения объема доступной памяти в 64-разрядной системе. В частности, ускоряется создание индексов за счет выполнения сортировки в оперативной памяти. Во время исполнения сложных запросов, требующих сортировки, соединений и агрегаций на основе хеш-таблиц, оптимизатор запросов гораздо реже выбирает альтернативные, менее эффективные алгоритмы в случае недостатка памяти. За счет сохранения компилированных планов запросов в кэш-памяти убыстряется исполнение хранимых процедур. Наконец, обеспечивается выигрыш во времени при получении больших, в том числе сортированных, выборок за счет того, что их сохранение и обработка полностью происходит в оперативной памяти.
Существенное повышение производительности 64-разрядная система показывает и при исполнении ETL-процессов*, обрабатывающих большое количество строк с одновременной агрегацией и загрузкой данных во многие таблицы. Ускорение в этом случае связано с возросшими возможностями параллельной обработки данных сервером архитектуры IA64.
* ETL (Extract, Transformation, Loading) — общее название процессов извлечения данных из исходных систем, их преобразования, очистки и загрузки в хранилище.
Опыт портирования
В качестве иллюстрации преимуществ построения информационно-аналитических систем на базе 64-разрядной архитектуры рассмотрим практический опыт портирования финансового хранилища данных «Контур Корпорация» компании Intersoft Lab (http://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-витрин. Собранные в хранилище данные могут представляться в online-интерфейсах системы (например, для просмотра счетов, документов, проводок и финансовых показателей в различных разрезах), а в некоторых случаях выводятся типичным 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 поддерживает также платформу x64. В конце 2005 г. вышла версия Microsoft SQL Server 2005, в которой появилась полноценная поддержка архитектуры x64. Соответственно в планах 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 Server. Сервер был бы вынужден постоянно работать с жестким диском, что на порядки медленнее по сравнению с использованием оперативной памяти (кэша), которую обеспечивает 64-разрядная платформа.
Сравнительное тестирование
В ходе тестирования планировалось выяснить, как влияют на повышение производительности системы «Контур Корпорация» различные подходы при переходе на 64-разрядную платформу: портирование базы данных, портирование библиотеки классов, общая оптимизация системы.
В реальных условия функционирования кредитной организации допустимое время загрузки в хранилище данных из нескольких десятков филиалов (примерно 500 тысяч документов ежедневно), их выверки, консолидации, расчетов и выпуска основных форм обязательной отчетности Банка России (например, 101 и 102) составляет не более 5—6 ч. Эти требования были заложены в план тестирования системы.
Ниже обсуждаются результаты тестирования производительности системы «Контур Корпорация» на реальных данных кредитной организации, в которой имеется 30 филиалов и около 250 тыс. лицевых счетов. Ежемесячно в хранилище поступает несколько сотен тысяч документов. На момент тестирования глубина архивных данных достигала 1 года. Тестированию были подвергнуты основные процессы, характерные для хранилища данных, — первоначальная загрузка данных, их последующая обработка и использование данных. Сравнительное тестирование проводилось на двухпроцессорном сервере на базе 64-разрядной платформы и на четырехпроцессорном сервере на базе 32-разрядной платформы (см. врезку «Тестовый стенд»).
Тестовый стенд
|
Были выполнены стандартные настройки ОС и СУБД, рекомендуемые производителем. На обоих серверах была установлена одна и та же версия системы «Контур Корпорация». Как уже указывалось выше, функциональность серверной части системы «Контур Корпорация» реализована в двух видах: процедуры на языке Python и хранимые процедуры на SQL. Процедуры Python оформлены в виде сервера приложений и выполняются на том же сервере, что и хранимые процедуры. Распределение функциональности системы между процедурами приведено в табл. 1.
Таблица 1. Распределение функциональности системы между процедурами
| Процесс хранилища данных | Функция системы «Контур Корпорация» | Процедуры Python | Хранимые процедуры |
| Первоначальная загрузка данных | Загрузка лицевых счетов, их остатков и оборотов, клиентов, документов с проводками | Обработка входящих XML-файлов, выполнение логических проверок данных | Запись в таблицы новых записей, изменение (удаление) |
| Последующая обработка данных | Агрегация и консолидация данных бухгалтерского учета | Расчет оборотов и остатков за день, месяц, год по иерархиям ЦФО, планам счетов и валютам | Запись в таблицы новых записей, изменение (удаление) |
| Использование данных | Расчет форм: 101 (баланс, тыс. руб.), 102 (доходы и расходы), ФОР | Формирование параметров запросов к хранимым процедурам, выполнение алгоритмов округления, основных расчетов | Выборка групп записей, частичное выполнение расчетов |
Портирование базы данных
Результаты тестирования системы после портирования базы данных на 64-разрядную платформу, как видно из табл. 2, подтвердили преимущество применения 64-разрядной архитектуры. Время загрузки данных в хранилище и время агрегации и консолидации данных, поступающих в хранилище, уменьшилось в 2,5 раза, а время расчетов форм 101 и 102 — в 3 раза (рис. 3).
Таблица 2. Результаты тестирования системы после портирования базы данных
| Задача | 32-разрядная платформа Intel | 64-разрядная платформа Intel |
| Загрузка данных | 5—7 ч | 2,5—3 ч |
| Консолидация и агрегация | 20 ч | 8 ч |
| Расчет формы 101 | 30 мин | 10 мин |
| Расчет формы 102 | 30 мин | 10 мин |
| Расчет ФОР | Не измерялось | 15 мин |
Рис. 3. Журнал загрузки данных по филиалу: общее время загрузки и некоторые подробности процесса.
Рассмотрим подробнее, за счет чего достигнуто повышение производительности. Поскольку процедуры Python выполнялись на 64-разрядном сервере в режиме эмуляции 32-разрядного процесса, то общее повышение производительности можно считать полностью «заслугой» SQL. Несомненно, что на эти результаты существенным образом повлияло эффективное использование оперативной памяти большего объема (8 Гбайт против 3 Гбайт). Процедуры Python в лучшем случае «не портили» общую картину. Однако план загрузки процессоров свидетельствовал о том, что около 70% мощности 64-разрядного сервера использовалось именно 32-разрядными процедурами Python.
К сожалению, в результате проведенного тестирования не удалось в полной мере оценить возможности параллельной обработки данных сервером 64-разрядной архитектуры. Филиалы банка географически расположены в пяти часовых поясах, и данные от них поступали в хранилище не одновременно. Поэтому на обоих серверах параллельно выполнялось максимум три процесса. Но с учетом того, что 64-разрядный сервер имел вдвое меньше процессоров (два против четырех), по косвенным данным можно предположить, что улучшенный параллелизм 64-разрядных процессоров также отразился на общем повышении производительности системы.
Портирование библиотеки классов
После портирования библиотеки классов тестированию была подвергнута функциональность системы, реализованная в равной мере хранимыми процедурами и процедурами на языке Python, — агрегация и консолидация данных. Тестирование показало следующие результаты: если на 32-разрядной платформе время выполнения задачи составляло 20 ч, а на 64-разрядной платформе Intel после портирования базы данных — 8 ч, то в системе «64-разрядная платформа Intel + портирование базы данных + портирование библиотеки классов» оно сократилось до 2,5 ч.
Как видно, этот способ портирования тоже дает неплохие результаты: время агрегации и консолидации данных уменьшилось в 8 раз. При этом изменился план загрузки процессоров сервера. Процедуры Python и хранимые процедуры практически поровну поделили между собой ресурсы процессоров. Поэтому можно предположить, что увеличение производительности системы было обусловлено обоими факторами — повышенной скоростью обработки данных фиксированной точности 64-разрядными процедурами Python и высвобождением ресурсов сервера для функционирования СУБД.
Общая оптимизация системы
На следующем этапе тестирования процедура консолидации и агрегации первичных данных была реализована в виде хранимой процедуры (рис. 4). Тестирование показало следующие результаты: если на 32-разрядной платформе время выполнения задачи составляло 20 ч, а на 64-разрядной платформе Intel после портирования базы данных — 8 ч, то в системе «64-разрядная платформа Intel + портирование базы данных + общая оптимизация системы» оно сократилось до 45 мин.
Рис. 4. Макрос, выполняющий агрегацию планов показателей, до (а) и после (б) перевода агрегации на хранимую процедуру.
Таким образом, повторное тестирование системы показало, что время агрегации и консолидации данных уменьшилось в 26 раз. Несомненно, это самый эффективный способ оптимизации системы, но при решении практических задач он не всегда возможен. SQL не всегда способен обеспечить требуемую гибкость при реализации расчетных алгоритмов. Часть функциональности системы «обречена» на их выполнение в виде процедур Python. Поэтому реально стоит рассчитывать на повышение производительности в диапазоне от 8 до 26 раз, в зависимости от способа реализации конкретной функциональности системы.
Итоги тестирования
Результаты тестирования полностью подтвердили преимущество решений на базе 64-разрядной архитектуры:
- время выполнения операций после портирования базы данных уменьшилось в 2,5—3 раза;
- время выполнения операций после портирования базы и библиотеки классов данных уменьшилось в 5—8 раз;
- время выполнения операций после оптимизации системы сократилось в 8—26 раз.
При этом не до конца были протестированы возможности системы при интенсивной параллельной обработке данных. Однако полученные результаты уже сейчас показывают, что за счет использования 64-разрядной платформы Microsoft и Intel существенно сокращается время ежедневной загрузки исходных данных в хранилище. Время выполнения консолидации данных по всей структуре хранилища и расчетов показателей для выпуска отчетных форм измеряется минутами. Поэтому 64-разрядная архитектура может с успехом использоваться для построения больших хранилищ данных, обеспечивая требуемое время отклика системы.