. PDW позволяет масштабировать решения корпоративных хранилищ данных до сотен терабайтов и даже до петабайтов данных для самых требовательных сценариев заказчиков. Кроме того, поскольку параллельные вычислительные узлы работают одновременно, зачастую требуются считанные секунды для получения результатов запросов к таблицам, содержащим триллионы строк. Для многих заказчиков большие наборы данных и минимальное время реакции на запросы к ним являются ключевыми возможностями для получения конкурентных преимуществ.
Проще всего представлять хранилище PDW как слой интегрированного программного обеспечения, который логически формирует некий «зонтик» над параллельными вычислительными узлами. Каждый вычислительный узел — это отдельный физический сервер, на котором работает свой экземпляр SQL Server 2008 в архитектуре «без разделения ресурсов», shared-nothing. Другими словами, вычислительный узел 1 не разделяет процессор, память или дисковую подсистему с вычислительным узлом 2.
Самое маленькое хранилище PDW будет занимать две полные стойки в центре обработки данных, и вы можете добавлять устройства хранения и вычислительные мощности к PDW по целой стойке за один прием. Стойка с данными содержит от 8 до 10 серверов от таких производителей как Bull, Dell, HP и IBM, а также дисковые массивы на базе интерфейса Fibre Channel от EMC, HP и IBM. Комплект поставки хранилища PDW включает в себя заранее настроенное и протестированное оборудование и программное обеспечение, которые настроены для достижения баланса пропускной способности и операций ввода/вывода для очень больших баз данных. Microsoft и производители оборудования предоставляют полную поддержку планирования, развертывания и настройки PDW.
Весь набор физических серверов и дисковых массивов, которые формируют хранилище данных с архитектурой MPP, часто обозначается термином «устройство» (appliance). И хотя под устройством обычно понимают отдельную коробку или отдельный сервер баз данных, типичное устройство PDW состоит из десятков физических серверов и дисковых массивов, совместно работающих под управлением отдельного сервера, называемого управляющим узлом. Управляющий узел принимает запросы клиентов, создает план выполнения MPP, который передается одному или более вычислительным узлам для исполнения различных частей запроса, зачастую параллельно. Полученные результаты возвращаются клиенту как единый набор результатов.
Более пристальный взгляд
Давайте заглянем поглубже в архитектуру хранилища PDW, показанную на рисунке. Как упоминалось ранее, в составе PDW есть управляющий узел, к которому подключаются клиенты для выполнения запросов к базе данных PDW. На управляющем узле работает экземпляр SQL Server 2008 для хранения метаданных хранилища PDW. Он также используется для хранения промежуточных результатов выполнения запросов в базе данных TempDB для некоторых типов запросов. Управляющий узел может получать промежуточные результаты частных запросов от разных вычислительных узлов для выполнения единого запроса, сохраняя эти результаты во временных таблицах SQL Server, а затем объединяя их в общий результирующий набор для итоговой доставки клиенту.
.jpg) |
| Рисунок. Архитектура стойки PDW |
Управляющий узел — это серверный кластер с узлами «активный/пассивный». Кроме того, имеется запасной вычислительный узел для обеспечения избыточности и отказоустойчивости.
Стойка с данными PDW содержит от 8 до 10 вычислительных узлов и соответствующие узлы хранения, в зависимости от производителя оборудования. Каждый вычислительный узел — это физический сервер с изолированным экземпляром SQL Server 2008. Узлы хранения — дисковые массивы с интерфейсом Fibre Channel, содержащие от 10 до 12 дисковых накопителей.
Емкость можно увеличить путем добавления стоек. В зависимости от размера дисков стойка данных может содержать от 30 до 40 Тбайт используемого дискового пространства. Эти объемы могут значительно возрасти, если производитель будет использовать диски по 750 Гбайт или еще большего размера. Используемое дисковое пространство полностью реализовано в виде массива RAID 1 на аппаратном уровне, при этом применяется сжатие страниц SQL Server 2008. Так, если в вашем устройстве PDW имеется 10 полных стоек данных, у вас будет от 300 до 400 Тбайт используемого дискового пространства и от 80 до 100 параллельных вычислительных узлов. Каждый вычислительный узел — двухпроцессорный сервер, при этом в каждом процессоре имеется минимум 4 ядра. В нашем примере — от 640 до 800 процессорных ядер и огромное дисковое хранилище с интерфейсом Fibre Channel. Я не знаю наверняка, скольким организациям сегодня необходимы такие процессорные и дисковые мощности для корпоративных хранилищ данных, однако они уже существуют!
Помимо управляющего узла, в хранилище PDW имеются дополнительные узлы.
- Узел загрузки данных (Landing zone node). Этот узел используется для запуска утилиты dwloader, ключевой утилиты для высокоскоростной параллельной загрузки в базы данных больших файлов данных с минимальным влиянием на выполняющиеся в PDW параллельные запросы. С помощью этой утилиты можно загружать данные с диска или из конвейера служб интеграции SQL Server Integration Services (SSIS) на все вычислительные узлы параллельно. Для SSIS был разработан новый высокоскоростной адаптер загрузки данных. Поскольку адаптер загрузки данных является загруженным в памяти процессом, данные для SSIS не обязательно перед загрузкой размещать на узле загрузки.
- Узел резервного копирования (Backup node). Данный узел используется для резервного копирования пользовательских баз данных, которые физически распределены по всем вычислительным узлам и относящимся к ним узлам хранения. При резервном копировании отдельной пользовательской базы данных каждый вычислительный узел в параллельном режиме архивирует свою часть этой базы данных. Для выполнения архивации пользовательские базы данных используют стандартную функциональность резервного копирования SQL Server 2008 на каждом вычислительном узле.
- Узел управления (Management node; не путать с управляющим узлом Control Node). На этом узле функционирует контроллер домена Windows Active Directory (AD) для данного устройства PDW. Он также используется для развертывания исправлений на все узлы и хранит образы на случай переустановки какого-либо узла.
Типы таблиц
Хранилище PDW имеет два основных типа таблиц: реплицируемые и распределенные. Реплицируемые таблицы хранятся на каждом вычислительном узле. Этот тип таблиц чаще всего используется для таблиц измерений. Таблицы измерений обычно невелики, и хранение их копий на каждом вычислительном узле нередко улучшает производительность объединений запросов, так как нет необходимости перемещать данные между вычислительными узлами для обработки некоторых типов параллельных запросов или запросов к измерению (dimension-only queries). Очень большие таблицы измерений могут быть кандидатами на роль распределенных таблиц.
Распределенные таблицы обычно используются для больших таблиц фактов или транзакций, которые содержат миллиарды строк. PDW автоматически создает разделы для распределенных таблиц. Разделы — это отдельные физические таблицы на уровне экземпляра SQL Server на вычислительном узле. В метаданных на управляющем узле отслеживается сопоставление отдельной распределенной таблицы и всех ее компонентов раздела по вычислительным узлам.
PDW автоматически создает для распределенной таблицы восемь разделов на каждом вычислительном узле. Во время написания данной статьи настраивать количество разделов было невозможно. Таким образом, устройство PDW с 10 вычислительными узлами имеет в сумме 80 разделов для распределенной таблицы. Загрузка 100 миллиардов строк в распределенную таблицу приведет к тому, что таблица будет распределена по всем 80 разделам, при условии выбора подходящего ключа распределения.
В качестве ключа распределения используется столбец с одиночным атрибутом из распределенной таблицы. PDW хеширует распределенные строки из распределенной таблицы по всем разделам настолько равномерно, насколько это возможно. Выбор правильного столбца в распределенной таблице — очень важная часть процесса проектирования, и, вероятно, это послужит темой многих статей в будущем. Сейчас достаточно сказать, что здесь не обойтись без метода проб и ошибок. К счастью, утилита dwloader может быстро перезагрузить 5 Тбайт и более данных, которых зачастую достаточно для тестирования нового проекта.
Создание баз данных и таблиц
Для создания баз данных и таблиц в PDW используется код, соответствующий стандарту ANSI SQL 92, но имеющий элементы, специфичные для PDW. Для создания базы данных используется команда CREATE DATABASE. Она имеет четыре аргумента:
- AUTOGROW, используется для разрешения автоматического увеличения файлов баз данных и журналов транзакций по мере необходимости;
- REPLICATED_SIZE, определяет размер пространства, изначально резервируемого для реплицируемых таблиц на каждом вычислительном узле;
- DISTRIBUTED_SIZE, определяет размер пространства, резервируемого для распределенных таблиц; это пространство поровну распределяется между всеми вычислительными узлами;
- LOG_SIZE, определяет размер пространства, резервируемого для журнала транзакций; это пространство поровну делится между всеми вычислительными узлами.
Например, следующая команда, CREATE DATABASE, создает пользовательскую базу данных с именем my_DB, для которой выделяется 16 Тбайт для распределенных данных, 1 Тбайт для реплицируемой таблицы и 800 Гбайт для журнала транзакций на устройстве PDW с восемью вычислительными узлами:
CREATE DATABASE my_DB WITH (AUTOGROW = ON , REPLICATED_SIZE = 1024 GB , DISTRIBUTED_SIZE = 16,384 GB , LOG_SIZE = 800 GB)
Суммарное пространство объемом 8 Тбайт (8 вычислительных узлов по 1024 Гбайт) будет использовано под реплицируемые таблицы, так как каждому вычислительному узлу необходимо пространство для хранения копии каждой реплицируемой таблицы. Два терабайта дискового пространства будет использовано каждым из 8 вычислительных узлов (16384 Гбайт/8 вычислительных узлов) для распределенных таблиц. Каждый вычислительный узел также будет использовать 100 Гбайт дискового пространства (800 Гбайт/8 вычислительных узлов) для журнальных файлов. По общему правилу суммарное пространство для файлов журналов нужно задавать в два раза больше размера самого объемного загружаемого файла данных.
При создании новой пользовательской базы данных вы не сможете создавать файловые группы. PDW делает это автоматически во время создания базы данных, так как настройка файловых групп тесно связана с настройкой хранилища для достижения общей производительности и балансировки операций ввода/вывода по совокупности всех вычислительных узлов.
После создания базы данных можно использовать команду CREATE TABLE для создания как реплицируемых, так и распределенных таблиц. Команда CREATE TABLE в PDW похожа на обычную команду CREATE TABLE в SQL Server и даже включает возможность разделения на секции как распределенных, так и реплицируемых таблиц. Наиболее существенное отличие этой команды в PDW — создание таблицы либо как реплицируемой, либо как распределенной.
Пример инструкции CREATE TABLE, в которой создается реплицируемая таблица с именем DimAccount, представлен в листинге 1. Как мы видим, аргументу DISTRIBUTION присвоено значение REPLICATE.
Вообще, распределенные таблицы используются для таблиц транзакций или данных, объем которых чаще всего превышает 1 Гбайт. В некоторых случаях большие таблицы измерений — например, таблица счетов клиентов из 500 миллионов строк — наилучший кандидат для распределенной таблицы. В листинге 2 приведен код для создания распределенной таблицы с именем FactSales.
Как было замечено выше, в качестве ключа распределения должен быть выбран столбец из одного атрибута, так чтобы загрузка данных могла быть распределена с помощью хеш-функции как можно более равномерно по всем вычислительным узлам. Для торговой компании с большой таблицей данных в пункте продаж (point of sale, POS) и большой таблицей данных складских запасов подходящим кандидатом на роль ключа распределения может быть столбец с идентификатором склада (store ID). Вычисляя хеш-функцию для этих таблиц по идентификатору склада, можно создать довольно равномерное распределение строк по всем вычислительным узлам. Более того, PDW будет размещать в одном и том же разделе строки из таблицы пункта продаж и из таблицы складских запасов, имеющие одинаковый идентификатор склада. Эти совмещенные данные взаимосвязаны, поэтому запросы на доступ к данным пункта продаж и связанным с ними данным складских запасов должны выполняться очень эффективно.
Для полного использования преимуществ PDW ключевую роль играет проектирование баз данных и таблиц для высокоприоритетных запросов. PDW имеет преимущество при просмотре и объединении больших распределенных таблиц, а зачастую критичными являются запросы именно к этим таблицам. Качественное проектирование баз данных для PDW часто идет путем проб и ошибок. Все, чему вы научились в мире баз данных на отдельном сервере, не всегда пригодно в мире хранилищ данных MPP. Например, кластеризованные индексы могут подойти для больших распределенных таблиц, но некластеризованные индексы в некоторых случаях могут существенно снизить производительность выполнения запросов по причине создаваемых ими произвольных запросов на операции ввода/вывода на дисковых хранилищах. PDW создан и настроен для достижения высокой скорости последовательных операций ввода/вывода с большими таблицами. Для многих запросов последовательный ввод/вывод для распределенной таблицы может выполняться быстрее, чем при использовании некластеризованных индексов, особенно при выполнении параллельных заданий. В мире хранилищ данных с архитектурой MPP эта технология известна как проектирование с легким индексом, или облегченное индексирование (index-light design).
Запросы к таблицам
После загрузки данных в таблицы клиенты могут подключаться к управляющему узлу и выполнять запросы SQL к таблицам PDW. Например, следующий запрос применяется к таблице, созданной с помощью листинга 2, с использованием всех параллельных вычислительных узлов и кластеризованного индекса для этой распределенной таблицы:
SELECT StoreIDKey, SUM (SalesQty) FROM dbo.FactSales WHERE DateKey >= 20090401 AND DateKey <= 20090408 AND ProductKey = 2501 GROUP BY StoreIDKey
Этот запрос выполняется чрезвычайно эффективно для очень больших распределенных таблиц. Он подходит как для распределений, так и для агрегирования, так как каждый вычислительный узел может во всей полноте получить свою часть ответа для параллельного запроса, не обращаясь к данным на других вычислительных узлах и не объединяя промежуточные результаты на управляющем узле.
Как только управляющий узел получает такой запрос, MPP-механизм устройства PDW начинает свою работу. Необходимо выполнить следующие действия.
- Разбор текста SQL-запроса.
- Подтверждение и авторизация всех объектов (проверка подлинности и авторизация).
- Построение плана исполнения MPP.
- Параллельное исполнение MPP-плана с помощью команд SQL SELECT на всех вычислительных узлах.
- Сбор и объединение параллельных результатов со всех вычислительных узлов.
- Возврат клиенту единого набора результатов.
Таким образом, хотя все выглядит так, как будто запросы применяются к одной таблице, в действительности они применяются ко множеству таблиц.
Механизм MPP отвечает за множество возможностей и функций в устройстве PDW. Они включают в себя управление настройкой устройства, проверку подлинности, авторизацию, управление схемой, оптимизацию MPP-запросов, управление выполнением MPP-запросов, взаимодействие с клиентом, управление метаданными и сбор информации о статусе оборудования.
Мощь PDW
Мощь PDW заключена в больших распределенных таблицах и параллельных вычислительных узлах, просматривающих эти таблицы для получения ответов на запросы. Таким образом, PDW подходит для вертикальных отраслей (например, розничная торговля, телекоммуникации, логистика, гостиничный бизнес), в которых имеются большие объемы транзакционных данных. Также можно считать PDW подходящими к приложениям для критически важных задач (например, в вооруженных силах), где от возможностей системы зависит жизнь человека. Я надеюсь, что вам, как и мне, придется по душе работа с решениями для реальной жизни и важнейших задач с применением этой новой технологии.
Рич Джонсон (richjohn@microsoft.com) — архитектор систем бизнес-аналитики в подразделении Microsoft по связям с государственным сектором США. Менеджер по разработке и построению решений OLTP и хранилищ данных на базе SQL Server
CREATE TABLE DimAccount ( AccountKey int NOT NULL, ParentAccountKey int NULL, AccountCodeAlternateKey int NULL, ParentAccountCodeAlternateKey int NULL, AccountDescription nvarchar(50) , AccountType nvarchar(50) , Operator nvarchar(50) , CustomMembers nvarchar(300) , ValueType nvarchar(50) , CustomMemberOptions nvarchar(200) ) WITH (CLUSTERED INDEX(AccountKey), DISTRIBUTION = REPLICATE);
CREATE TABLE FactSales ( StoreIDKey int NOT NULL, ProductKey int NOT NULL, DateKey int NOT NULL, SalesQty int NOT NULL, SalesAmount decimal(18,2) NOT NULL ) WITH (CLUSTERED INDEX(DateKey), DISTRIBUTION = HASH(StoreIDKey));