Руководство по таблицам Apache Doris

Последовательность проектирования

Превратите сведения о рабочей нагрузке в четыре решения.

Надёжный дизайн таблицы начинается с семантики строк, затем выбираются ключи сортировки, границы партиций и физическое распределение.

МодельПоведение повторяющихся ключей
Ключ сортировкиЛокальность чтения
ПартицияДиапазон + жизненный цикл
БакетРаспределение таблетов
ПроверкаРазмер + перекос + планы

Подсказка

Принимайте решения в порядке зависимостей.

Модель таблицы определяет смысл повторяющихся ключей. Столбцы ключа задают порядок сортировки. Партиции определяют границы логического отсечения и жизненного цикла. Бакеты определяют распределение таблетов и параллелизм.

Спросите себя перед написанием DDL

Данные только добавляются или изменяются? Какие фильтры используются чаще всего? Сколько данных поступает за период? Какие столбцы обеспечивают равномерное распределение строк?

Какое решение нужно принять первым?

Выберите ответ, чтобы проверить понимание.

Модели таблиц

Что должны означать повторяющиеся ключи?

Duplicate сохраняет каждую строку, Unique оставляет одну логическую строку на ключ, а Aggregate объединяет столбцы значений с помощью объявленных функций.

DUPDuplicate Key

Добавляйте факты, журналы и подробные события без объединения по ключу.

UNIUnique Key

Выполняйте UPSERT для изменяемых сущностей и сохраняйте последнюю логическую строку.

AGGAggregate Key

Объединяйте показатели с помощью SUM, MAX, MIN, REPLACE или связанных функций.

Подсказка

Модель — это выбор бизнес-семантики.

Используйте Duplicate для неизменяемых фактов и журналов, Unique — для CDC и записей о последнем состоянии, а Aggregate — когда агрегация во время записи существенно сокращает повторную работу запросов.

Сложно изменить

Модель таблицы нельзя изменить после создания. Для смены модели нужны новая таблица и перенос данных.

Какая модель подходит для потока кликов, в который данные только добавляются?

Выберите ответ, чтобы проверить понимание.

Ключи сортировки

Размещайте часто используемые фильтры там, где хранилище может их использовать.

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

Эффективный префикс

Компактные столбцы, соответствующие распространённым предикатам.

Часто фильтруется
Хорошо помогает отсечению
Стабильный и достаточно узкий

Слабый префикс

Широкие столбцы, не связанные с обычными путями доступа.

Редко фильтруется
Слабо помогает отсечению
Длинные строки в начале

Подсказка

Важны частота, селективность и ширина.

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

Дополнение индексами

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

Какой столбец обычно лучше выбрать первым в ключе сортировки?

Выберите ответ, чтобы проверить понимание.

Партиционирование

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

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

MANРучное

Явные границы RANGE или LIST с прямым управлением оператором.

DYNДинамическое

Запланированные временные партиции с последовательным созданием и истечением срока действия.

AUTOАвтоматическое

Создавайте партиции RANGE или LIST из значений во время загрузки.

Подсказка

Создавайте партиции для отсечения и обслуживания, а не для украшения.

Используйте ручные партиции для жёстко контролируемых границ, динамические — для запланированных временных окон, а автоматические — когда входящие значения должны автоматически создавать диапазоны или списки.

Контракт запроса

Отсечение партиций помогает только тогда, когда запросы ограничивают столбец партиционирования. Проверьте это на репрезентативных SQL-запросах и с помощью EXPLAIN.

Что делает партицию по дате полезной для запроса?

Выберите ответ, чтобы проверить понимание.

Бакетирование

Распределяйте каждую партицию по полезным таблетам.

Хеш-бакетирование детерминированно размещает данные по ключу; случайное бакетирование распределяет строки без ключа распределения.

Хеш-бакетирование

Одинаковые значения ключа отображаются детерминированным образом.

Выберите ключ с высокой кардинальностью и равномерным распределением
Поддерживает JOIN с учетом распределения
При неудачном выборе ключа возможен перекос

Случайное бакетирование

Строки распределяются без заданного ключа.

Простая равномерная загрузка данных
Подходит, если нет стабильного ключа
Меньшая локальность при распределении данных

Подсказка

Сбалансируйте локальность, перекос и параллелизм.

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

Сначала размер, потом количество

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

Каков основной риск хеш-ключа для бакетирования с низкой кардинальностью?

Выберите ответ, чтобы проверить понимание.

Шаблоны рабочих нагрузок

Объедините решения в согласованный шаблон таблицы.

Надежный DDL внутренне согласован: семантика строк, отсечение данных, распределение и поведение загрузки поддерживают рабочую нагрузку.

LOGАналитика событий

Дублирующиеся строки, отсечение по времени и равномерное параллельное сканирование.

CDCПоследнее состояние

Уникальные бизнес-ключи с загрузкой, ориентированной на UPSERT.

KPIАгрегирование показателей

Стабильные измерения с заданным агрегированием значений.

Подсказка

Шаблоны — это исходные гипотезы.

Таблица событий часто использует Duplicate Key, партицию по времени и ключ равномерного распределения. Сущность CDC часто использует Unique Key вместе с бизнес-ключом. Таблица сводных данных использует Aggregate Key только при стабильном уровне детализации агрегации.

Проверьте на реальной структуре данных

Используйте репрезентативный объем данных, кардинальность ключей, шаблоны фильтрации и частоту обновлений. Крошечные синтетические выборки скрывают перекос и проблемы с размером таблетов.

Что должно определять шаблон таблицы в рабочей среде?

Выберите ответ, чтобы проверить понимание.

Проверка и уточнение

Проверьте таблицу Doris, которую система действительно создала.

Перед масштабированием рабочей нагрузки проверьте отсечение партиций, размер таблетов, распределение строк, планы запросов и поведение загрузки.

ЗагрузкаРепрезентативный объем данных
ПроверкаПартиции + таблетки
EXPLAINОтсечение данных + план
ПрофилированиеДанные времени выполнения
ОптимизацияПерестроить при необходимости

Подсказка

DDL — это начало проектирования таблицы.

Используйте команды метаданных для проверки партиций и таблетов, сравнивайте число строк и размеры таблетов, чтобы выявить перекос, и применяйте EXPLAIN с профилями, чтобы подтвердить выполнение ожидаемых операций отсечения данных и JOIN.

Типичная проблема

Слишком большое число маленьких таблетов увеличивает накладные расходы на планирование и Compaction. Слишком малое число крупных или перекошенных таблетов ограничивает параллелизм и создает горячие точки.

Что следует проверить, если один BE выполняет значительно больше работы?

Выберите ответ, чтобы проверить понимание.

Doris 101: Руководство по таблицам Apache Doris

Превратите сведения о рабочей нагрузке в четыре решения.

Что должны означать повторяющиеся ключи?

Размещайте часто используемые фильтры там, где хранилище может их использовать.

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

Распределяйте каждую партицию по полезным таблетам.

Объедините решения в согласованный шаблон таблицы.

Проверьте таблицу Doris, которую система действительно создала.