Обзор моделей таблиц StarRocks

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

StarRocks реализует концепцию моделей таблиц через набор ключей и режимов агрегации. В зависимости от задачи можно выбрать: DUPLICATE KEY для фактов с возможными дубликатами и простонеперекрывающимися обновлениями, AGG_KEYS для предагрегированных фактов с поддержкой агрегаций на вставку, а также UNIQUE KEY для поддержания уникальности по заданным ключам. Важной частью выбора является понимание того, как эти ключи сочетаются с методами распределения данных, сортировкой и обновлением метаданных. Архитектура StarRocks строится вокруг колонночного хранения, разделов таблиц и «таблеток» (tablets), что позволяет эффективно сканировать столбцы и применять агрегации на уровне сервера без значительных затрат на копирование данных между узлами.

Справочная картина архитектуры предполагает, что каждая таблица имеет набор ключевых столбцов, определённый тип ключа и стратегию распределения. Различия между моделями проявляются в том, как обрабатываются дубликаты, как выполняются агрегации и как формируются результаты запросов. В современных дата-сквозных пайплайнах это позволяет достигать баланса между скоростью записи, объёмом памяти и скоростью анализа. Ниже приведены ключевые особенности каждой модели и принципы их выбора в зависимости от характера данных и целей аналитики.

Архитектура и концепции хранения в StarRocks

В основе всех моделей лежит колонночное хранение и разбиение данных на разделы. Это позволяет ускорить сканирование колонок, использовать компрессию и эффективные кэширования. В процессе загрузки данные сортируются в соответствии с определённой сортировкой (SORT KEY) и ключами, которые определяют семантику агрегаций и уникальности. Разделение по партициям (PARTITION BY) облегчает prune-запросы и ускоряет агрегации на больших объёмах.

Ключевые концепции:

Ключи (keys): в StarRocks ключами могут выступать разные комбинации столбцов, которые определяют уникальность данных и поведение агрегаций.
Типы ключей: DUPLICATE KEY, AGG_KEYS, UNIQUE KEY. Каждый тип задаёт уникальный режим обработки вставок и последующих обновлений.
Агрегации: для некоторых моделей можно определить агрегации на уровне столбцов (например, SUM, MAX, MIN). Это позволяет суммировать значения при вставке дубликатов и достигать предагрегированных таблиц.
Распределение и сортировка: распределение по хэш-значениям и сортировка по SORT KEY влияют на локализацию данных и скорость выполнения запросов.
Интеграции: модель таблицы должна хорошо сочетаться с пайплайнами загрузки данных (потоковая и пакетная загрузка), а также с инструментами обработки потоков (например, Flink, Spark) и коннекторами к источникам.

Понимание этих принципов становится основой для выбора правильной модели под конкретную предметную область: факты продаж, событие активности пользователей или справочные таблицы. Для фактов и больших объёмов данных, где важна предагрегация, разумно рассмотреть AGG_KEYS; для измерений, где критична уникальность и простая инкрементальная загрузка - UNIQUE KEY; для потоковых потоков и событий с возможными дубликатами - DUPLICATE KEY.

Типы моделей таблиц: DUPLICATE KEY, AGG_KEYS, UNIQUE KEY

Ниже рассмотрены три базовых типа моделей. В примерах DDL мы используем упрощённые синтаксические конструкции, характерные для большинства версий StarRocks. Обратите внимание: точный синтаксис может слегка варьироваться между версиями продукта; используйте официальную документацию вашей версии для подтверждения.

DUPLICATE KEY

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

CREATE TABLE sales_events (
  event_date DATE,
  product_id INT,
  region_id INT,
  amount BIGINT
) DUPLICATE KEY (event_date, product_id, region_id)
DISTRIBUTED BY HASH(product_id) BUCKETS 16;

Особенности и критерии выбора:

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

Эта модель служит для предагрегированных фактов. Вставляемые строки могут дублироваться по ключу, но значения по столбцам аггрегируются согласно определённым правилам (например, сумма рекламных расходов по дате и товару суммируется). Это позволяет существенно сокращать объём хранения и ускорять аналитические запросы за счёт предагрегирования на запись.

CREATE TABLE daily_sales (
  sale_date DATE,
  product_id INT,
  city_id INT,
  qty INT SUM,
  revenue DECIMAL(18,2) SUM
) AGG_KEYS (sale_date, product_id, city_id)
DISTRIBUTED BY HASH(product_id) BUCKETS 16;

Ключевые моменты:

агрегации задаются на уровне столбцов (например, SUM, MAX, MIN). Это позволяет автоматически сводить дубликаты по ключу к агрегированному значению.
слой агрегации экономит место на диске и ускоряет запросы на подписи и сводки.
рекомендуется для часто запрашиваемых сводок, где важна скорость ответа и минимизация обработки повторной агрегации во время выполнения запросов.
UNIQUE KEY

Модель уникальных ключей обеспечивает строгую уникальность по заданным столбцам. Обычно применяется для измерительных и справочных таблиц, где каждый ключ должен существовать единожды. В рамках этой модели могут использоваться обновления в виде upsert-операций, если таковая функциональность поддерживается версиями StarRocks, и запросы работают на чтении с гарантией отсутствия дубликатов.

CREATE TABLE customer_dim (
  customer_id INT,
  customer_name VARCHAR(100),
  country_code VARCHAR(3),
  LAST_UPDATED TIMESTAMP
) UNIQUE KEY (customer_id)
DISTRIBUTED BY HASH(customer_id) BUCKETS 8;

Замечания:

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

Влияние на запросы и оптимизацию

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

Семантика агрегаций: AGG_KEYS позволяет выполнять агрегации на уровне вставляемых данных. Это особенно ценно для фактов, где часто запрашиваются сводки по времени и по ключам. DUPLICATE KEY не выполняет агрегации автоматически, поэтому запросы часто требуют явной агрегации по нужным группирующим полям. UNIQUE KEY обеспечивает отсутствие дубликатов, что упрощает прогнозируемые результаты по уникальным ключам.
Объём данных и хранение: AGG_KEYS сокращает объём за счёт предагрегирования. DUPLICATE KEY может потребовать большего объёма памяти и диска из-за сохранения всех вставленных строк, включая дубликаты. UNIQUE KEY может снизить число записей, если данные регулярно попадают под уникальные ограничения.
Скорость чтения: при агрегации в AGG_KEYS многие вычисления могут быть выполнены на этапе записи, что уменьшает нагрузку на движок анализа. Это особенно эффективно в сценариях, где часто запрашиваются сводки по ключам и времени.
Производительность обновлений: DUPLICATE KEY обладает преимуществом в сценариях потоковой загрузки, где заливаются бесконечные потоки данных, но ценой на последующую агрегацию. UNIQUE KEY требует корректной стратегии обновлений для обеспечения согласованности и устранения конфликтов. AGG_KEYS обеспечивает предагрегирование, что может уменьшить необходимый объём вычислений на запросах.
Распределение и сортировка: выбор схемы DISTRIBUTED BY HASH(...) и указание SORT KEY для таблицы влияет на локализацию данных и эффект от коллабораций. Правильная балансировка по узлам и устойчивое распределение улучшают параллелизм выполнения запросов.

Практически это означает следующее: для аналитики, где ключевые метрики требуют регулярных сумм и быстрых сводок по времени, AGG_KEYS часто выбирается как наиболее эффективная модель. Для потоковых потоков, где данные приходят в большом количестве с возможными повторными вставками, DUPLICATE KEY обеспечивает простоту загрузки. Для справочных и измерительных таблиц, где критична уникальность, применяется UNIQUE KEY, чтобы исключить дубликаты и гарантировать целостность набора ключей.

Интеграции и практические сценарии внедрения

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

Потоковая загрузка и дубликаты: если ваш пайплайн использует потоковую загрузку (например, через Kafka + Flink), DUPLICATE KEY может быть естественной моделью. Дубликаты часто встречаются в реальном времени, и простота вставки без агрегаций по ключу позволяет снизить задержку на записи. Однако для аналитических запросов потребуется последующая агрегация в момента анализа.
Пакетная загрузка и предагрегации: если ваш пайплайн ориентирован на пакетную обработку, AGG_KEYS часто представляет оптимальный выбор. Вставляемые данные накапливаются и агрегируются по ключам, что сокращает размер хранимых данных и ускоряет последующий анализ.
Обновления измерений: уникальные таблицы особенно полезны для справочных и размерных измерений, где критично сохранить уникальные записи. Внесение изменений требует аккуратного подхода к загрузке и обновлениям, чтобы сохранить целостность и избежать конфликтов.
Интеграции с инструментами вроде Flink и Spark: StarRocks может работать в связке с этими инструментами для подготовки данных. Важно согласовать модель таблицы с логикой агрегаций на входе и стратегией конвертации на выходе. В некоторых случаях оптимально держать данные в AGG_KEYS на входе и использовать внешние агрегации на этапе анализа, если необходима дополнительная гибкость.
Миграции и эволюция моделей: миграция между моделями требует планирования и тестирования в тестовой среде. В тех случаях, когда требуется переход от DUPLICATE KEY к AGG_KEYS, можно рассмотреть промежуточные этапы: копирование данных в staging-таблицу с новой моделью, проверку консистентности и затем миграцию в продакшн. Внесение изменений в схему лучше проводить в периоды минимальной нагрузки и с проверкой на полноту и корректность агрегаций.

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

Эволюция схемы и миграция между моделями

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

Оценка текущих потребностей: анализ текущего набора запросов, частоты обновлений и требований к уникальности. Это позволяет определить целесообразность перехода между моделями или сохранение текущей конфигурации.
Планирование миграции: создание тестовой среды, где можно проверить поведение новых агрегаций, объём и корректность результатов. Включите тестовые сценарии на реальных данных и нагрузочные тесты.
Пошаговая миграция: по возможности избегайте резкой смены модели. Рассмотрите тестовую миграцию, копирование части данных, валидацию и постепенное заменение таблиц в продакшене.
Совместимость запросов: обновление моделей часто требует адаптации запросов. В некоторых случаях достаточно изменений в агрегатах или группировках, в других - потребуются дополнительные представления (views) и материализованные представления (materialized views).
Мониторинг и качество данных: после миграции внимательно следите за точностью агрегаций, полнотой данных и латентностью. Включите пороги отклонений и автоматическое оповещение при несоответствиях.

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

Key takeaways

StarRocks поддерживает три базовые модели таблиц: DUPLICATE KEY, AGG_KEYS и UNIQUE KEY, каждая из которых определяет уникальность ключей и поведение агрегаций.
AGG_KEYS оптимальна для предагрегированных фактов и ускорения сводок за счёт агрегаций на вставке, что уменьшает объём данных и ускоряет аналитику.
DUPLICATE KEY удобна для потоковых сценариев с возможными дубликатами и высокой скоростью загрузки, где агрегации выполняются на уровне запроса.
UNIQUE KEY полезна для справочных и измерительных таблиц, где требуется явная уникальность записей и предсказуемость результатов.
Выбор модели влияет на стратегию распределения и сортировки, а также на архитектуру пайплайна загрузки и дальнейшей аналитики.
Миграции между моделями требуют планирования, тестирования и тщательного контроля качества данных.
В интеграционных сценариях важно согласовать модель таблицы с пайплайнами обработки (Flink, Spark) и с требованиями к обновлениям и агрегациям.
Учитывайте требования к ресурсам: AGG_KEYS снижает объём хранения за счёт предагрегирования, DUPLICATE KEY может увеличить объём при большом числе дубликатов.
Для сложных аналитических сценариев может быть эффективной гибридная архитектура, когда разные таблицы в пайплайне используют разные модели в соответствии с их задачами.
Регулярно пересматривайте модель данных по мере роста объёмов, изменений в бизнес-логике и появлению новых сценариев анализа.

FAQ

Какие факторы следует учитывать при выборе между DUPLICATE KEY, AGG_KEYS и UNIQUE KEY?

Рассматривайте характер данных: факты с повторными вставками и потоковую загрузку - DUPLICATE KEY; частые сводки и предагрегированные показатели - AGG_KEYS; справочные и уникальные измерения - UNIQUE KEY. Также учитывайте требования к скорости выполнения запросов, объём данных и частоту обновлений.

Что произойдёт с данными при переходе от DUPLICATE KEY к AGG_KEYS?

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

Как модель влияет на обновления в таблицах?

DUPLICATE KEY допускает повторные вставки без автоматической агрегации. AGG_KEYS выполняет агрегацию на вставку, уменьшая размер данных и ускоряя запросы. UNIQUE KEY требует управления уникальностью на уровне загрузки и обновлений, чтобы избежать конфликтов позиций по ключам.

Какие практики по распределению данных следует учитывать?

Выбор HASH-распределения по ключам помогает сбалансировать нагрузку между узлами. Важно подбирать количество_BUCKETS и включать подходящую сортировку (SORT KEY), чтобы улучшить локализацию чтения и эффективное сканирование по диапазонам.

Какие ограничения и риски связаны с AGG_KEYS?

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

Какие инструменты и пайплайны лучше всего работают с этими моделями?

Стандартные решения потоковой обработки (Flink, Spark) хорошо интегрируются с StarRocks. Важно синхронизировать логику агрегаций между процессами загрузки и запросов анализа и обеспечить согласованность между источниками данных и целевыми таблицами.

Какие критерии подходят для миграций в продакшене?

Определитесь с бизнес-целями миграции, подготовьте staging-окружение, проведите нагрузочные тесты и сравнение результатов. Введите поэтапную миграцию, чтобы снизить риск простоев и конфликтов данных.

Какие примеры практических сценариев помогают выбрать модель?

Кейсы с ежедневными сводками продаж и меры по регионам чаще выбирают AGG_KEYS. Таблички клиентов и справочные справочники часто держат UNIQUE KEY, чтобы сохранить целостность. Потоковые журналы событий, где встречаются дубликаты, обычно используют DUPLICATE KEY для упрощения загрузки и анализа на уровне запросов.

Какую роль играет сортировка в производительности?

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

Какие ограничения могут быть у конкретной версии StarRocks?

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

В чем преимущество использования нескольких моделей в одном проекте?

Это позволяет изолировать бизнес-логики. Например, базовый набор измерений хранится как UNIQUE KEY, факт-таблицы - DUPLICATE KEY, а сводные таблицы - AGG_KEYS. Такой гибридный подход может предоставить оптимизацию по памяти и скорости анализа, сохранив при этом нужную степень целостности и детальности данных.

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

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

Какие практики по миграции в реальном окружении вы можете порекомендовать?

Работайте в окружении staging, применяйте поэтапную миграцию, тестируйте во всех типах запросов (EQ, полной агрегации и детальном просмотре данных) и обеспечивайте откатные планы. Включите автоматическое тестирование консистентности на каждом этапе.

Как сочетать Open Source и локальные решения в рамках моделирования?

В рамках данного раздела рекомендуется упоминать 1-2 примера на раздел, например Apache Flink или Apache Spark как инструменты обработки данных, если они действительно усиливают смысл. При этом не перегружайте текст перечнями. Обосновывайте выбор и приводите контекст внедрения.

Что считать «лучшей практикой» в рамках StarRocks?

Выбор модели должен отражать бизнес-логики и требования к скорости анализа. Рекомендуется начинать с AGG_KEYS для предагрегированных фактов, рассмотреть DUPLICATE KEY для потоковой загрузки и обратиться к UNIQUE KEY для справочных измерений. Проводите регулярную ревизию моделей по мере роста данных и изменений бизнес-логики.

← Предыдущая статья

Настройка параметров кластера StarRocks

Следующая статья →

Типы данных в StarRocks