Перейти к содержимому
Последнее обновление

Формат хранения широких таблиц V3

подсказка

Эта возможность поддерживается начиная с Apache Doris 4.1.0. Чтобы включить её, укажите "storage_format" = "V3" в предложении PROPERTIES при создании таблицы.

Формат хранения широких таблиц V3 меняет структуру метаданных Segment для таблиц с очень большим количеством столбцов. Благодаря вынесению метаданных столбцов из Footer и их загрузке по требованию V3 значительно сокращает время открытия Segment и потребление памяти.

Сценарии применения​

Если при выполнении запросов этап «открытие Segment» занимает очень много времени, а потребление памяти необычно высоко и ваш случай соответствует одному из сценариев в таблице ниже, рекомендуется включить формат хранения V3:

Сценарий использованияТипичный симптомРекомендуется V3?
Широкие таблицы (от сотен до тысяч столбцов)Открытие Segment требует много времени и памяти, даже если запрос обращается лишь к нескольким столбцамРекомендуется
Таблицы со столбцами VARIANTПосле динамического раскрытия подстолбцов фактическое количество хранимых столбцов значительно превышает количество явно заданныхРекомендуется
Размещение в объектном или многоуровневом хранилищеДанные находятся в удалённом хранилище, например S3 или OSS, и время выполнения холодных запросов критичноРекомендуется
Обычные таблицы (несколько десятков столбцов или меньше)Накладные расходы на открытие Segment незначительныПереход не требуется

Пример типичной проблемы: для широкой таблицы с 7,000 столбцов и общим количеством Segment 10,000 их открытие занимает около 65 секунд, а пиковое потребление памяти в процессе достигает 60 GB. Эти накладные расходы возникают независимо от того, использует ли запрос эти столбцы: это своего рода «плата за вход».

Причина проблемы​

Старый формат размещает метаданные всех столбцов (ColumnMetaPB) вместе внутри Footer в конце файла Segment. Это приводит к следующим проблемам:

  1. Загрузка всех метаданных: для открытия Segment сначала необходимо десериализовать весь Footer. Даже если запрос использует только два столбца, накладные расходы остаются в полном объёме.
  2. Увеличение размера Footer: когда количество столбцов достигает нескольких тысяч, размер самого Footer может вырасти до нескольких MB.
  3. Усиление эффекта при работе с удалённым хранилищем: сетевая задержка и высокая стоимость чтения из объектного хранилища дополнительно увеличивают эти накладные расходы.

Иными словами, даже если SQL-запрос обращается только к 2 столбцам, перед началом сканирования Doris всё равно должен прочитать в память и десериализовать метаданные всех столбцов в Segment. Чем больше столбцов и Segment, тем ощутимее эти накладные расходы.

Основные оптимизации V3​

V3 меняет формат хранения по трём направлениям:

Оптимизация 1: загрузка метаданных столбцов по требованию​

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

Формат хранения широких таблиц: сравнение структуры файлов Segment

При открытии Segment система читает только компактный Footer; метаданные фактически используемых столбцов извлекаются лишь по мере необходимости. Это основной источник прироста производительности при работе с широкими таблицами, особенно заметный при использовании объектного хранилища.

Оптимизация 2: простое кодирование по умолчанию для числовых типов​

В V3 кодирование по умолчанию для числовых типов, таких как INT и BIGINT, меняется с BitShuffle на PLAIN_ENCODING (двоичные данные без преобразования). В сочетании со сжатием LZ4 / ZSTD это ускоряет чтение и снижает нагрузку на CPU при сканировании больших объёмов данных.

Оптимизация 3: более компактное простое кодирование строк​

Для строк и JSONB в V3 введено BINARY_PLAIN_ENCODING_V2, использующее потоковую структуру [length(varuint)][raw data]. Оно устраняет необходимость в таблице смещений в конце, обязательной для старого кодирования, и обеспечивает более компактное хранение.

Результаты измерений​

Условия тестирования: широкая таблица с 7,000 столбцов и общим количеством Segment 10,000.

Формат хранения широких таблиц: эффективность открытия метаданных

МетрикаСтарый форматФормат V3Улучшение
Время открытия Segment65 s4 sВ 16 раз быстрее
Потребление памяти при открытии60 GB< 1 GBВ 60 раз меньше

Как включить​

Явно задайте значение storage_format как V3 в предложении PROPERTIES оператора CREATE TABLE:

CREATE TABLE table_v3 (
    id BIGINT,
    name VARCHAR(128),
    attrs VARIANT
)
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
    "storage_format" = "V3"
);

Рекомендации​

  • Рекомендуется включить: для широких таблиц с большим количеством столбцов (сотни и более), таблиц со столбцами VARIANT, а также таблиц, размещённых в объектном или многоуровневом хранилище.
  • Переход не требуется: для обычных таблиц с небольшим количеством столбцов (несколько десятков или меньше); старого формата уже достаточно.
  • Сжатие данных: подробнее о совместной оптимизации кодирования и сжатия числовых и строковых типов в V3.
Report issue