Версия сайта для слабовидящих
Недавно мы рассматривали тонкости проектирования схем данных в Greenplum. Продолжая разбирать важные для обучения дата-инженеров и архитекторов DWH темы, сегодня поговорим о том, как разделение и распределение данных влияют на скорость выполнения SQL-запросов в этой MPP-СУБД.
Распределение данных
Напомним, MPP-СУБД Greenplum широко используется в качестве OLAP-системы и корпоративного хранилища данных. Поэтому она лучше всего работает с денормализованной схемой звезды или снежинки, с большими централизованными таблицами фактов, связанными с несколькими меньшими таблицами измерений.
В этой среде с массово-параллельной обработкой без общих ресурсов распределение (Distribution) определяет, в какие строки таблицы сегментов данные назначаются, а разделение (Partitioning) определяет, как они хранятся в каждом из сегментов. Distribution — это физическое разделение хранимых данных, а Partitioning — логическое.
Оптимальное, т.е. равномерное распределение данных, является самым важным фактором в Greenplum. В MPP-среде без разделения ресурсов общее время ответа на запрос измеряется временем завершения для всех сегментов. Таким образом, скорость системы равна скорости самого медленного сегмента. Если данные неравномерно распределены, сегменты с большим количеством данных будут выполняться дольше. Поэтому каждый сегмент должен иметь примерно равное количество строк и выполнять примерно одинаковый объем обработки. Низкая производительность и нехватка памяти могут возникнуть, если в одном сегменте Greenplum требуется обработать значительно больше данных, чем в других сегментах. Чтобы избежать этого, используется горизонтальное масштабирование (шардирование), о котором мы рассказываем здесь. А в этой статье вы узнаете, какие утилиты и команды помогут обнаружить перекосы данных.
В Greenplum 5 было 2 стратегии распределения: распределение хэша и случайное распределение. В 6-ой версии добавлена еще одна политика – копирование распределения. При выборе стратегии распределения рекомендуется явно определить столбец (distribution key) или задать случайное распределение для всех таблиц. Не следует использовать значение по умолчанию (хэш-распределение). В идеале надо выбрать один столбец, который будет равномерно распределять данные по всем сегментам. Не стоит распределять данные по столбцам, которые будут использоваться в фильтре через условии WHERE в SQL-запросе. Не рекомендуется распределять данные в Greenplum по датам или временным меткам, при этом данные столбца ключа распределения должны содержать уникальные значения или очень большое количество элементов.
Если один столбец не может обеспечить равномерное распределение, надо выбрать ключ распределения с двумя столбцами. Больше столбцов обычно не дают более равномерного распределения и требуют дополнительного времени в процессе хэширования. Если ключ распределения с двумя столбцами не может обеспечить равномерное распределение данных, можно использовать случайное распределение. Ключи распределения по нескольким столбцам в большинстве случаев требуют операций перемещения для соединения таблиц, поэтому они не имеют преимуществ перед случайным распределением.
Случайное распределение в базе данных Greenplum не является циклическим, поэтому оно не гарантирует равное количество записей в каждом сегменте. Случайные распределения обычно попадают в целевой диапазон вариации менее десяти процентов. Оптимальное распределение имеет решающее значение при объединении больших таблиц. Для выполнения соединения совпадающие строки должны располагаться вместе в одном сегменте. Если данные не распределяются по одному и тому же столбцу соединения, строки, необходимые из одной из таблиц, динамически перераспределяются в другие сегменты. В некоторых случаях выполняется широковещательное движение, при котором каждый сегмент отправляет свои отдельные строки всем другим сегментам вместо повторного хэширования и отправки строк в соответствующие сегменты в соответствии с хэш-ключом.
Разделение данных в Greenplum
Разделение в Greenplum выполняется с помощью предложения PARTITION BY в DDL-запросе на создание таблицы, которое позволяет разделить большую таблицу на несколько подтаблиц. Предложение SUBPARTITION BY может разделить дочерние таблицы на меньшие таблицы. Теоретически Greenplum не имеет ограничений на количество уровней или секционированных таблиц, которые может иметь корневая таблица, но для любого уровня разделения (иерархического уровня таблицы) партиционированная таблица может иметь до 32 767 дочерних партиционированных таблиц.
В случае распределения данных партиционированная таблица рассматривается как обычная. Для корневой таблицы ее данные сначала выделяются в партиционированную, а затем отдельная партиционированная таблица распределяется по сегментам Greenplum, как и любая таблица без разделов, в соответствии со стратегией распределения. Таблицы в Greenplum физически распределены по сегментам Greenplum, что делает возможной параллельную обработку запросов. Разделение таблиц — это инструмент для логического разделения больших таблиц для повышения производительности запросов и облегчения задач обслуживания хранилища данных. Разделение не меняет физического распределения данных таблицы между сегментами.
Greenplum поддерживает следующие типы разделов:
- RANGE – разделение данных на основе числовых диапазонов, таких как даты или цены;
- LIST – разделение данных на основе списка значений, таких как регионы продаж или линейки продуктов;
- сочетание этих двух типов.
Разделение больших таблиц повышает производительность запросов и упрощает задачи обслуживания базы данных, особенно извлечение старых данных. Хорошая стратегия партиционирования снижает объем сканируемых данных за счет чтения только тех разделов, которые нужны для выполнения SQL-запроса.
Каждый раздел представляет собой отдельный физический файл или набор файлов (в случае таблиц, ориентированных на столбцы) в каждом сегменте. Подобно тому, как чтение полной строки в широкой таблице столбцов требует больше времени, чем чтение той же строки из таблицы кучи, о которых мы писали здесь, чтение всех разделов в многораздельной таблице требует больше времени, чем чтение тех же данных из непартиционированной таблицы.
При разделении данных в Greenplum рекомендуется учитывать следующие рекомендации:
- разделять только большие таблицы и только в том случае, если устранение/сокращение разделов может быть достигнуто на основе критериев запроса и выполняется путем партиционирования таблицы на основе предиката запроса;
- применять стратегию разделения RANGE вместо LIST;
- планировщик запросов может выборочно сканировать партиционированные таблицы только в том случае, если запрос содержит прямое и простое ограничение таблицы с помощью неизменяемых операторов, таких как =, < , <=, >, >= и <>;
- выборочное сканирование распознает СТАБИЛЬНЫЕ и НЕИЗМЕНИМЫЕ функции, но не распознает ИЗМЕНЧИВЫЕ функции в запросе, например, такие фильтрация WHERE с условием data>CURRENT_DATE. Поэтому важно убедиться, что запросы выборочно сканируют партиционированные таблицы (разделы удаляются), изучив план запроса через команду EXPLAIN, о чем мы писали здесь и здесь.
- Не следует использовать разделы по умолчанию: они всегда сканируются и часто переполняются, что приводит к снижению производительности Greenplum;
- не следует разделять и распределять таблицы по одному и тому же столбцу, т.е. partition key должен всегда отличаться от distribution key;
- не рекомендуется применять многоуровневое разделение, поскольку подразделы обычно содержат мало данных или вообще не содержат их. Производительность Greenplum не сильно увеличивается по мере рост количества разделов или подразделов, а административные затраты на обслуживание множества разделов и подразделов перевесят любые преимущества в производительности. Для повышения производительности, масштабируемости и управляемости этой MPP-СУБД следует сбалансировать производительность сканирования разделов с общим количеством разделов.
- Не стоит использовать слишком много разделов с хранилищем, ориентированным на столбцы;
- Наконец, надо учитывать параллелизм рабочей нагрузки и среднее количество разделов, открытых и просканированных для всех одновременных запросов.
Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
