Перейти к основному содержимому
Версия: 2.0.x

CREATE MATERIALIZED VIEW

CREATE MATERIALIZED VIEW создает материализованное представление. Информацию об использовании материализованных представлений см. в разделах Синхронное материализованное представление и Асинхронное материализованное представление.

ПРЕДУПРЕЖДЕНИЕ

  • Только пользователи с привилегией CREATE MATERIALIZED VIEW в базе данных, где находится базовая таблица, могут создавать материализованное представление.
  • Начиная с версии v1.5.2, Selena поддерживает создание синхронных материализованных представлений в shared-data кластерах.

Создание материализованного представления — это асинхронная операция. Успешное выполнение этой команды означает, что задача создания материализованного представления успешно отправлена. Вы можете просмотреть статус сборки синхронного материализованного представления в базе данных с помощью команды SHOW ALTER MATERIALIZED VIEW, а асинхронного материализованного представления — путем запроса метаданных представлений tasks и task_runs в Information Schema.

Selena поддерживает асинхронные материализованные представления начиная с версии v1.5.2. Основные различия между асинхронными и синхронными материализованными представлениями в предыдущих версиях следующие:

Агрегация по одной таблицеМноготабличный joinПереписывание запросовСтратегия обновленияБазовая таблица
ASYNC MVДаДаДа
  • Асинхронное обновление
  • Ручное обновление
Множество таблиц из:
  • Каталога по умолчанию
  • Внешних каталогов (v1.5.2)
  • Существующих материализованных представлений (v1.5.2)
  • Существующих представлений (v1.5.2)
SYNC MV (Rollup)Ограниченный выбор агрегатных функцийНетДаСинхронное обновление при загрузке данныхОдна таблица в каталоге по умолчанию

Синхронное материализованное представление​

Синтаксис​

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [database.]<mv_name>
[COMMENT ""]
[PROPERTIES ("key"="value", ...)]
AS
<query_statement>

Параметры в квадратных скобках [] являются необязательными.

Параметры​

mv_name (обязательный)

Имя материализованного представления. Требования к именованию следующие:

  • Имя должно состоять из букв (a-z или A-Z), цифр (0-9) или символов подчеркивания (_) и может начинаться только с буквы.
  • Длина имени не может превышать 64 символа.
  • Имя чувствительно к регистру.

COMMENT (необязательный)

Комментарий к материализованному представлению. Обратите внимание, что COMMENT должен быть размещен после mv_name. В противном случае материализованное представление не может быть создано.

query_statement (обязательный)

Запрос для создания материализованного представления. Его результат — это данные в материализованном представлении. Синтаксис следующий:

SELECT select_expr[, select_expr ...]
[WHERE where_expr]
[GROUP BY column_name[, column_name ...]]
[ORDER BY column_name[, column_name ...]]

  • select_expr (обязательный)

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

    • Простые столбцы или агрегированные столбцы, такие как SELECT a, abs(b), min(c) FROM table_a, где a, b и c — имена столбцов в базовой таблице. Если вы не укажете имена столбцов для материализованного представления, Selena автоматически назначит имена столбцам.
    • Выражения, такие как SELECT a+1 AS x, b+2 AS y, c*c AS z FROM table_a, где a+1, b+2 и c*c — выражения, которые ссылаются на столбцы в базовых таблицах, а x, y и z — псевдонимы, назначенные столбцам в материализованном представлении.

    ПРИМЕЧАНИЕ

    • Вы должны указать хотя бы один столбец в select_expr.
    • При создании синхронного материализованного представления с агрегатной функцией необходимо указать предложение GROUP BY и указать хотя бы один столбец GROUP BY в select_expr.
    • Синхронные материализованные представления не поддерживают предложения, такие как JOIN и предложение HAVING в GROUP BY.
    • Начиная с версии v1.5.2, каждое синхронное материализованное представление может поддерживать более одной агрегатной функции для каждого столбца базовой таблицы, например, запросы такие как select b, sum(a), min(a) from table group by b.
    • Начиная с версии v1.5.2, синхронные материализованные представления поддерживают сложные выражения для SELECT и агрегатных функций, например, запросы такие как select b, sum(a + 1) as sum_a1, min(cast (a as bigint)) as min_a from table group by b или select abs(b) as col1, a + 1 as col2, cast(a as bigint) as col3 from table. Следующие ограничения накладываются на сложные выражения, используемые для синхронных материализованных представлений:
      • Каждое сложное выражение должно иметь псевдоним, и разные псевдонимы должны быть назначены разным сложным выражениям среди всех синхронных материализованных представлений базовой таблицы. Например, запросы select b, sum(a + 1) as sum_a from table group by b и select b, sum(a) as sum_a from table group by b не могут использоваться для создания синхронных материализованных представлений для одной и той же базовой таблицы. Вы можете установить разные псевдонимы для сложного выражения.
      • Вы можете проверить, переписаны ли ваши запросы синхронными материализованными представлениями, созданными со сложными выражениями, выполнив EXPLAIN <sql_statement>. Для получения дополнительной информации см. Анализ запросов.

  • WHERE (необязательный)

    Начиная с версии v1.5.2, синхронные материализованные представления поддерживают предложение WHERE, которое может фильтровать строки, используемые для материализованного представления.

  • GROUP BY (необязательный)

    Столбец GROUP BY запроса. Если этот параметр не указан, данные не будут группироваться по умолчанию.

  • ORDER BY (необязательный)

    Столбец ORDER BY запроса.

    • Столбцы в предложении ORDER BY должны быть объявлены в том же порядке, что и столбцы в select_expr.
    • Если запрос содержит предложение GROUP BY, столбцы ORDER BY должны быть идентичны столбцам GROUP BY.
    • Если этот параметр не указан, система автоматически дополнит столбец ORDER BY в соответствии со следующими правилами:
      • Если материализованное представление имеет тип AGGREGATE, все столбцы GROUP BY автоматически используются в качестве ключей сортировки.
      • Если материализованное представление не имеет типа AGGREGATE, Selena автоматически выбирает ключи сортировки на основе префиксных столбцов.

Запрос синхронного материализованного представления​

Поскольку синхронное материализованное представление по сути является индексом базовой таблицы, а не физической таблицей, вы можете запросить синхронное материализованное представление только с помощью подсказки [_SYNC_MV_]:

-- Не опускайте квадратные скобки [] в подсказке.
SELECT * FROM <mv_name> [_SYNC_MV_];

ПРЕДУПРЕЖДЕНИЕ

В настоящее время Selena автоматически генерирует имена для столбцов в синхронном материализованном представлении, даже если вы указали для них псевдонимы.

Автоматическое переписывание запросов с синхронным материализованным представлением​

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

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

агрегатная функция в исходном запросеагрегатная функция материализованного представления
sumsum
minmin
maxmax
countcount
bitmap_union, bitmap_union_count, count(distinct)bitmap_union
hll_raw_agg, hll_union_agg, ndv, approx_count_distincthll_union
percentile_approx, percentile_unionpercentile_union

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

-- Создать синхронное материализованное представление test_mv1 для хранения агрегатных состояний.
CREATE MATERIALIZED VIEW test_mv1
AS
SELECT
    dt,
    -- Исходные агрегатные функции.
    min(id) AS min_id,
    max(id) AS max_id,
    sum(id) AS sum_id,
    bitmap_union(to_bitmap(id)) AS bitmap_union_id,
    hll_union(hll_hash(id)) AS hll_union_id,
    percentile_union(percentile_hash(id)) AS percentile_union_id,
    -- Функции состояния общих агрегатных функций.
    ds_hll_count_distinct_union(ds_hll_count_distinct_state(id)) AS hll_id,
    avg_union(avg_state(id)) AS avg_id,
    array_agg_union(array_agg_state(id)) AS array_agg_id,
    min_by_union(min_by_state(province, id)) AS min_by_province_id
FROM t1
GROUP BY dt;

Асинхронное материализованное представление​

Синтаксис​

CREATE MATERIALIZED VIEW [IF NOT EXISTS] [database.]<mv_name>
[COMMENT ""]
-- Вы должны указать либо `distribution_desc`, либо `refresh_scheme`, либо оба.
-- distribution_desc
[DISTRIBUTED BY HASH(<bucket_key>[,<bucket_key2> ...]) [BUCKETS <bucket_number>]]
-- refresh_desc
[REFRESH
-- refresh_moment
    [IMMEDIATE | DEFERRED]
-- refresh_scheme
    [ASYNC | ASYNC [START (<start_time>)] EVERY (INTERVAL <refresh_interval>) | MANUAL]
]
-- partition_expression
[PARTITION BY
  [ <partition_column> [,...] ] | [ <date_function_expr> ]
]
-- order_by_expression
[ORDER BY (<sort_key>)]
[PROPERTIES ("key"="value", ...)]
AS
<query_statement>

Параметры в квадратных скобках [] являются необязательными.

Параметры​

mv_name (обязательный)

Имя материализованного представления. Требования к именованию следующие:

  • Имя должно состоять из букв (a-z или A-Z), цифр (0-9) или символов подчеркивания (_) и может начинаться только с буквы.
  • Длина имени не может превышать 64 символа.
  • Имя чувствительно к регистру.

ПРЕДУПРЕЖДЕНИЕ

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

COMMENT (необязательный)

Комментарий к материализованному представлению. Обратите внимание, что COMMENT должен быть размещен после mv_name. В противном случае материализованное представление не может быть создано.

distribution_desc (необязательный)

Стратегия bucketing асинхронного материализованного представления. Selena поддерживает hash bucketing и random bucketing (начиная с версии v1.5.2). Если вы не указываете этот параметр, Selena использует стратегию random bucketing и автоматически устанавливает количество buckets.

ПРИМЕЧАНИЕ

При создании асинхронного материализованного представления необходимо указать либо distribution_desc, либо refresh_scheme, либо оба.

  • Hash bucketing:

    Синтаксис

    DISTRIBUTED BY HASH (<bucket_key1>[,<bucket_key2> ...]) [BUCKETS <bucket_number>]

    Для получения дополнительной информации см. Распределение данных.

    ПРИМЕЧАНИЕ

    Начиная с версии v1.5.2, Selena может автоматически устанавливать количество buckets (BUCKETS) при создании таблицы или добавлении раздела. Вам больше не нужно вручную устанавливать количество buckets. Подробную информацию см. в разделе установка количества buckets.

  • Random bucketing:

    Если вы выбираете стратегию random bucketing и разрешаете Selena автоматически устанавливать количество buckets, вам не нужно указывать distribution_desc. Однако, если вы хотите вручную установить количество buckets, вы можете воспользоваться следующим синтаксисом:

    DISTRIBUTED BY RANDOM BUCKETS <bucket_number>

    ПРЕДУПРЕЖДЕНИЕ

    Асинхронные материализованные представления со стратегией random bucketing не могут быть назначены группе colocation.

    Для получения дополнительной информации см. Random bucketing

refresh_moment (необязательный)

Момент обновления материализованного представления. Значение по умолчанию: IMMEDIATE. Допустимые значения:

  • IMMEDIATE: Обновить асинхронное материализованное представление немедленно после его создания.
  • DEFERRED: Асинхронное материализованное представление не обновляется после создания. Вы можете вручную обновить материализованное представление или запланировать регулярные задачи обновления.

refresh_scheme (необязательный)

ПРИМЕЧАНИЕ

  • При создании асинхронного материализованного представления необходимо указать либо distribution_desc, либо refresh_scheme, либо оба.
  • Материализованные представления внешних таблиц не поддерживают автоматическое обновление по триггеру изменения данных базовой таблицы. Они поддерживают только асинхронное обновление с фиксированным интервалом и ручное обновление.

Стратегия обновления асинхронного материализованного представления. Допустимые значения:

  • ASYNC: Режим автоматического обновления. Каждый раз, когда изменяются данные базовой таблицы, материализованное представление автоматически обновляется.
  • ASYNC [START (<start_time>)] EVERY(INTERVAL <interval>): Режим регулярного обновления. Материализованное представление обновляется регулярно с указанным интервалом. Вы можете указать интервал как EVERY (interval n day/hour/minute/second) с использованием следующих единиц: DAY, HOUR, MINUTE и SECOND. Значение по умолчанию — 10 MINUTE. Вы можете дополнительно указать время начала обновления как START('yyyy-MM-dd hh:mm:ss'). Если время начала не указано, используется текущее время. Пример: ASYNC START ('2023-09-12 16:30:25') EVERY (INTERVAL 5 MINUTE).
  • MANUAL: Режим ручного обновления. Материализованное представление не будет обновляться, если вы не запустите задачу обновления вручную.

Если этот параметр не указан, используется значение по умолчанию MANUAL.

partition_expression (необязательный)

Стратегия разделения асинхронного материализованного представления. Если этот параметр не указан, стратегия разделения по умолчанию не применяется.

Допустимые значения:

  • partition_column: Столбец(ы), используемые для разделения. Выражение PARTITION BY dt означает разделение материализованного представления в соответствии со столбцом dt.
  • date_function_expr: Сложное выражение с функциями дат, используемое для разделения.
    • Функция date_trunc: Функция, используемая для усечения единицы времени. PARTITION BY date_trunc("MONTH", dt) означает, что столбец dt усекается до месяца в качестве единицы для разделения. Функция date_trunc поддерживает усечение времени до единиц, включая YEAR, MONTH, DAY, HOUR и MINUTE.
    • Функция str2date: Функция, используемая для преобразования разделов типа string базовой таблицы в типы дат. PARTITION BY str2date(dt, "%Y%m%d") означает, что столбец dt является типом даты STRING, формат даты которого "%Y%m%d". Функция str2date поддерживает множество форматов дат, вы можете обратиться к str2date для получения дополнительной информации. Поддерживается с версии v1.5.2.
    • Функция time_slice: Начиная с версии v1.5.2, вы можете дополнительно использовать эти функции для преобразования указанного времени в начало или конец временного интервала на основе указанной временной детализации, например, PARTITION BY date_trunc("MONTH", time_slice(dt, INTERVAL 7 DAY)), где time_slice должен иметь более тонкую детализацию, чем date_trunc. Вы можете использовать их для указания столбца GROUP BY с более тонкой детализацией, чем у ключа разделения, например, GROUP BY time_slice(dt, INTERVAL 1 MINUTE) PARTITION BY date_trunc('DAY', ts).

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

Примечания для многостолбцовых выражений разделов:

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

  • Поскольку выражения разделов Iceberg поддерживают функцию transform, требуется дополнительная обработка при сопоставлении выражений разделов Iceberg с выражениями разделов материализованных представлений Selena. Соотношение сопоставления следующее:

    Iceberg TransformВыражение раздела IcebergВыражение раздела материализованного представления
    Identity<col><col>
    hourhour(<col>)date_trunc('hour', <col>)
    dayday(<col>)date_trunc('day', <col>)
    monthmonth(<col>)date_trunc('month', <col>)
    yearyear(<col>)date_trunc('year', <col>)
    bucketbucket(<col>, <n>)Не поддерживается
    truncatetruncate(<col>)Не поддерживается

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

См. Пример -5 для подробных инструкций по многостолбцовым выражениям разделов.

ПРЕДУПРЕЖДЕНИЕ

Начиная с версии v1.5.2, Selena поддерживает создание асинхронных материализованных представлений со стратегией разделения List Partitioning.

  • Вы можете создавать материализованные представления с разделением списка на основе таблиц, созданных со стратегией разделения List Partitioning или Expression partitioning.
  • В настоящее время при создании материализованных представлений со стратегией разделения List Partitioning можно указать только один ключ раздела. Вы должны выбрать один ключ раздела, если базовая таблица имеет более одного ключа раздела.
  • Поведение обновления и логика переписывания запросов материализованных представлений со стратегией разделения List Partitioning согласуются с теми, которые имеют стратегию разделения Range Partitioning.

order_by_expression (необязательный)

Ключ сортировки асинхронного материализованного представления. Если вы не указываете ключ сортировки, Selena выбирает некоторые из префиксных столбцов из столбцов SELECT в качестве ключей сортировки. Например, в select a, b, c, d ключами сортировки могут быть a и b. Этот параметр поддерживается начиная с Selena v1.5.2.

ПРИМЕЧАНИЕ Существует два разных использования ORDER BY в материализованных представлениях:

  • ORDER BY в операторе CREATE MATERIALIZED VIEW определяет ключ сортировки материализованного представления, что помогает ускорить запросы на основе ключа сортировки. Это не влияет на способность материализованного представления к прозрачному ускорению на основе SPJG, но не гарантирует глобальную сортировку результатов запроса материализованного представления.
  • ORDER BY в определении запроса материализованного представления гарантирует глобальную сортировку результатов запроса, но предотвращает использование материализованного представления для прозрачного переписывания запросов на основе SPJG. Поэтому ORDER BY не следует использовать в определении запроса материализованного представления, если MV используется для переписывания запросов.

INDEX (необязательный)

Асинхронные материализованные представления поддерживают индексы ​Bitmap​ и ​BloomFilter​ для ускорения производительности запросов, и их использование такое же, как и в обычных таблицах. Подробности об использовании и информацию об индексах ​Bitmap​ и ​BloomFilter​ см. в разделах Индекс Bitmap и Индекс Bloom filter.

Использование индексов Bitmap:

-- Создать индекс
CREATE INDEX <index_name> ON <mv_name>(<column_name>) USING BITMAP COMMENT '<comment>';

-- Проверить прогресс создания индекса
SHOW ALTER TABLE COLUMN;

-- Просмотреть индексы
SHOW INDEXES FROM <mv_name>;

-- Удалить индекс
DROP INDEX <index_name> ON <mv_name>;

Использование индексов BloomFilter:

-- Создать индекс
ALTER MATERIALIZED VIEW <mv_name> SET ("bloom_filter_columns" = "<col1,col2,col3,...>");

-- Просмотреть индексы
SHOW CREATE MATERIALIZED VIEW <mv_name>;

-- Удалить индекс
ALTER MATERIALIZED VIEW <mv_name> SET ("bloom_filter_columns" = "");

PROPERTIES (необязательный)

Свойства асинхронного материализованного представления. Вы можете изменить свойства существующего материализованного представления с помощью ALTER MATERIALIZED VIEW.

  • session.: Если вы хотите изменить свойство, связанное с переменной сеанса, материализованного представления, вы должны добавить префикс session. к свойству, например, session.insert_timeout. Вам не нужно указывать префикс для свойств, не связанных с сеансом, например, mv_rewrite_staleness_second.

  • replication_num: Количество реплик материализованного представления для создания.

  • storage_medium: Тип носителя хранения. Допустимые значения: HDD и SSD.

  • storage_cooldown_time: Время охлаждения хранилища для раздела. Если используются носители хранения HDD и SSD, данные в хранилище SSD перемещаются в хранилище HDD после времени, указанного этим свойством. Формат: "yyyy-MM-dd HH:mm:ss". Указанное время должно быть позже текущего времени. Если это свойство не указано явно, охлаждение хранилища не выполняется по умолчанию.

  • bloom_filter_columns: Массив имен столбцов, которые включают индексацию Bloom filter. Подробности об индексах Bloom filter см. в разделе Индекс Bloom filter.

  • partition_ttl: Время жизни (TTL) для разделов. Сохраняются разделы, данные которых находятся в пределах указанного временного диапазона. Просроченные разделы удаляются автоматически. Единица: YEAR, MONTH, DAY, HOUR и MINUTE. Например, вы можете указать это свойство как 2 MONTH. Это свойство рекомендуется вместо partition_ttl_number. Оно поддерживается с версии v1.5.2.

  • partition_ttl_number: Количество самых последних разделов материализованного представления для сохранения. Для разделов со временем начала, ранним, чем текущее время, после того, как количество этих разделов превысит это значение, менее недавние разделы будут удалены. Selena периодически проверяет разделы материализованного представления в соответствии с временным интервалом, указанным в элементе конфигурации FE dynamic_partition_check_interval_seconds, и автоматически удаляет просроченные разделы. Если вы включили стратегию динамического разделения, разделы, созданные заранее, не учитываются. Когда значение равно -1, все разделы материализованного представления будут сохранены. По умолчанию: -1.

  • partition_refresh_number: В одном обновлении максимальное количество разделов для обновления. Если количество разделов для обновления превышает это значение, Selena разделит задачу обновления и завершит ее партиями. Только когда предыдущая партия разделов успешно обновлена, Selena продолжит обновлять следующую партию разделов, пока все разделы не будут обновлены. Если какой-либо из разделов не удастся обновить, последующие задачи обновления не будут созданы. Когда значение равно -1, задача обновления не будет разделена. Значение по умолчанию изменено с -1 на 1 с версии v1.5.2, что означает, что Selena обновляет разделы один за другим.

  • partition_refresh_strategy：Стратегия обновления для материализованного представления во время одной операции обновления. Когда установлено значение adaptive, количество разделов для обновления будет автоматически определяться на основе объема данных в разделах базовой таблицы, что значительно повышает эффективность обновления. Если это свойство не указано, стратегия по умолчанию — strict, что означает, что количество разделов, обновленных за одну операцию, строго контролируется partition_refresh_number.

  • excluded_trigger_tables: Если базовая таблица материализованного представления указана здесь, задача автоматического обновления не будет запущена при изменении данных в базовой таблице. Этот параметр применяется только к стратегии обновления, вызванной загрузкой, и обычно используется вместе со свойством auto_refresh_partitions_limit. Формат: [db_name.]table_name. Когда значение — пустая строка, любое изменение данных во всех базовых таблицах вызывает обновление соответствующего материализованного представления. Значение по умолчанию — пустая строка.

  • excluded_refresh_tables: Базовые таблицы, перечисленные в этом свойстве, не будут обновлены в материализованное представление при изменении их данных. Формат: [db_name.]table_name. Значение по умолчанию — пустая строка. Когда значение — пустая строка, любое изменение данных базовой таблицы вызовет обновление соответствующего материализованного представления.

    подсказка

    Разница между excluded_trigger_tables и excluded_refresh_tables:

    • excluded_trigger_tables контролирует, запускать ли обновление, а не участвовать ли в обновлении. Например, разделенное материализованное представление получается путем соединения двух разделенных таблиц A и B, и разделы двух таблиц A и B соответствуют один к одному. excluded_trigger_table содержит таблицу A. В течение периода времени таблица A обновила разделы [1,2,3], но поскольку это excluded_trigger_table, обновление материализованного представления не запускается. В это время таблица B обновляет раздел [3], и материализованное представление запускает обновление, которое обновит три раздела [1, 2, 3]. Здесь вы можете видеть, что excluded_trigger_table только контролирует, запускать ли обновление. Хотя обновление таблицы A не может запустить обновление материализованного представления, когда обновление таблицы B запускает обновление материализованного представления, раздел, обновленный таблицей A, также будет добавлен в задачу обновления.
    • excluded_refresh_tables контролирует, участвовать ли в обновлении. В приведенном выше примере, если таблица A существует как в excluded_trigger_table, так и в excluded_refresh_tables, когда обновление таблицы B запускает обновление материализованного представления, будет обновлен только раздел [3].

  • auto_refresh_partitions_limit: Количество самых последних разделов материализованного представления, которые должны быть обновлены при запуске обновления материализованного представления. Вы можете использовать это свойство для ограничения диапазона обновления и снижения затрат на обновление. Однако, поскольку не все разделы обновляются, данные в материализованном представлении могут не соответствовать базовой таблице. По умолчанию: -1. Когда значение равно -1, все разделы будут обновлены. Когда значение является положительным целым числом N, Selena сортирует существующие разделы в хронологическом порядке и обновляет текущий раздел и N-1 самых последних разделов. Если количество разделов меньше N, Selena обновляет все существующие разделы. Если в вашем материализованном представлении есть динамические разделы, созданные заранее, Selena обновляет все предварительно созданные разделы.

  • mv_rewrite_staleness_second: Если последнее обновление материализованного представления находится в пределах временного интервала, указанного в этом свойстве, это материализованное представление может использоваться непосредственно для переписывания запросов, независимо от того, изменяются ли данные в базовых таблицах. Если последнее обновление было до этого временного интервала, Selena проверяет, были ли обновлены базовые таблицы, чтобы определить, может ли материализованное представление использоваться для переписывания запросов. Единица: Секунда. Это свойство поддерживается с версии v1.5.2.

  • colocate_with: Группа colocation асинхронного материализованного представления. См. Colocate Join для получения дополнительной информации. Это свойство поддерживается с версии v1.5.2.

  • unique_constraints и foreign_key_constraints: Ограничения Unique Key и ограничения Foreign Key при создании асинхронного материализованного представления для переписывания запросов в сценарии View Delta Join. См. Асинхронное материализованное представление - Переписывание запросов в сценарии View Delta Join для получения дополнительной информации. Это свойство поддерживается с версии v1.5.2.

  • excluded_refresh_tables：Базовые таблицы, перечисленные в этом свойстве, не запускают обновление данных в материализованное представление при изменении их данных. Это свойство обычно используется вместе со свойством excluded_trigger_tables. Формат: [db_name.]table_name. Значение по умолчанию — пустая строка. Когда значение — пустая строка, любое изменение данных во всех базовых таблицах вызовет обновление соответствующего материализованного представления.

    ПРЕДУПРЕЖДЕНИЕ

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

  • resource_group: Группа ресурсов, к которой принадлежат задачи обновления материализованного представления. Значение по умолчанию этого свойства — default_mv_wg, которая является системной группой ресурсов, специально используемой для обновления материализованных представлений. cpu_core_limit группы default_mv_wg равен 1, mem_limit равен 0.8. Для получения дополнительной информации о группах ресурсов см. Группа ресурсов.

  • query_rewrite_consistency: Правило переписывания запросов для асинхронных материализованных представлений. Это свойство поддерживается с версии v1.5.2. Допустимые значения:

    • disable: Отключить автоматическое переписывание запросов асинхронного материализованного представления.

    • checked (Значение по умолчанию): Включить автоматическое переписывание запросов только тогда, когда материализованное представление соответствует требованию своевременности, что означает:

      • Если mv_rewrite_staleness_second не указан, материализованное представление может использоваться для переписывания запросов только тогда, когда его данные согласованы с данными во всех базовых таблицах.
      • Если mv_rewrite_staleness_second указан, материализованное представление может использоваться для переписывания запросов, когда его последнее обновление находится в пределах временного интервала устаревания.

    • loose: Включить автоматическое переписывание запросов напрямую, и проверка согласованности не требуется.

    • force_mv: Начиная с версии v1.5.2, материализованные представления Selena поддерживают TTL выражения общего раздела. Семантика force_mv специально разработана для этого сценария. Когда эта семантика включена:

      • Если материализованное представление не имеет свойства partition_retention_condition, оно всегда будет принудительно использовать материализованное представление для переписывания запросов, независимо от того, была ли обновлена базовая таблица.
      • Если материализованное представление имеет свойство partition_retention_condition:
        • Для разделов в пределах диапазона TTL переписывание запросов на основе материализованного представления всегда доступно, независимо от того, была ли обновлена базовая таблица.
        • Для разделов вне диапазона TTL требуется компенсация Union между материализованным представлением и базовой таблицей, независимо от того, была ли обновлена базовая таблица.

      Например, если материализованное представление имеет определенное свойство partition_retention_condition, и раздел для 20241131 истек, но данные базовой таблицы для 20241203 были обновлены, в то время как данные материализованного представления для 20241203 не были обновлены, применяется следующее, когда свойство query_rewrite_consistency установлено в force_mv:

      • Материализованное представление гарантирует, что запросы к разделам в пределах диапазона TTL (например, с 20241201 по 20241203), определенного в partition_retention_condition, всегда могут быть прозрачно переписаны.
      • Для запросов к разделам вне диапазона partition_retention_condition компенсация будет происходить автоматически на основе Union материализованного представления и базовой таблицы.

      См. Пример 6 для подробных инструкций по семантике force_mv и partition_retention_condition.

  • storage_volume: Имя тома хранения, используемого для хранения асинхронного материализованного представления, которое вы хотите создать, если вы используете shared-data кластер. Это свойство поддерживается с версии v1.5.2. Если это свойство не указано, используется том хранения по умолчанию. Пример: "storage_volume" = "def_volume".

  • force_external_table_query_rewrite: Включить ли переписывание запросов для материализованных представлений на основе внешнего каталога. Это свойство поддерживается с версии v1.5.2. Допустимые значения:

    • true(Значение по умолчанию с версии v1.5.2): Включить переписывание запросов для материализованных представлений на основе внешнего каталога.
    • false: Отключить переписывание запросов для материализованных представлений на основе внешнего каталога.

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

  • enable_query_rewrite: Использовать ли материализованное представление для переписывания запросов. Когда существует много материализованных представлений, переписывание запросов на основе материализованных представлений может повлиять на время, затрачиваемое оптимизатором. С помощью этого свойства вы можете контролировать, может ли материализованное представление использоваться для переписывания запросов. Эта функция поддерживается с версии v1.5.2. Допустимые значения:

    • default (По умолчанию): Система не будет выполнять семантические проверки материализованного представления, но только материализованные представления типа SPJG могут использоваться для переписывания запросов. Обратите внимание, что если включено переписывание запросов на основе текста, материализованные представления не типа SPJG также могут использоваться для переписывания запросов.
    • true: Система будет выполнять семантические проверки при создании или изменении материализованного представления. Если материализованное представление не подходит для переписывания запросов (то есть определение материализованного представления не является запросом типа SPJG), будет возвращен сбой.
    • false: Материализованное представление не будет использоваться для переписывания запросов.

  • [Preview] transparent_mv_rewrite_mode: Указывает режим прозрачного переписывания для запросов непосредственно к материализованному представлению. Эта функция поддерживается с версии v1.5.2. Допустимые значения:

    • false (По умолчанию, совместимо с поведением в более ранних версиях): Запросы непосредственно к материализованному представлению не будут переписаны и возвращаются только с существующими данными в материализованном представлении. Их результаты запроса могут отличаться от результатов запросов, основанных на определении материализованного представления, в соответствии со статусом обновления (согласованность данных) материализованного представления.
    • true: Запросы непосредственно к материализованному представлению будут переписаны и возвращены с самыми обновленными данными, которые согласуются с результатом запроса определения материализованного представления. Обратите внимание, что когда материализованное представление неактивно или не поддерживает прозрачное переписывание запросов, эти запросы будут выполняться как запрос определения материализованного представления.
    • transparent_or_error: Запросы непосредственно к материализованному представлению будут переписаны, когда они подходят. Если материализованное представление неактивно или не поддерживает прозрачное переписывание запросов, эти запросы будут возвращены с ошибкой.
    • transparent_or_default Запросы непосредственно к материализованному представлению будут переписаны, когда они подходят. Если материализованное представление неактивно или не поддерживает прозрачное переписывание запросов, эти запросы будут возвращены с существующими данными в материализованном представлении.

  • partition_retention_condition: Начиная с версии v1.5.2, материализованные представления Selena поддерживают TTL выражения общего раздела. Это свойство — выражение, которое объявляет разделы, которые должны быть сохранены динамически. Разделы, которые не соответствуют условию в выражении, будут регулярно удаляться. Пример: 'partition_retention_condition' = 'dt >= CURRENT_DATE() - INTERVAL 3 MONTH'.

    • Выражение может содержать только столбцы разделов и константы. Столбцы, не являющиеся разделами, не поддерживаются.
    • Выражение общего раздела применяется к разделам List и Range по-разному:
      • Для материализованных представлений с разделами List, Selena поддерживает удаление разделов, отфильтрованных выражением общего раздела.
      • Для материализованных представлений с разделами Range, Selena может фильтровать и удалять разделы только с использованием возможности обрезки разделов FE. Разделы, соответствующие предикатам, которые не поддерживаются обрезкой разделов, не могут быть отфильтрованы и удалены.

    См. Пример 6 для подробных инструкций по семантике force_mv и partition_retention_condition.

query_statement (обязательный)

Запрос для создания асинхронного материализованного представления. Начиная с версии v1.5.2, Selena поддерживает создание асинхронных материализованных представлений с Common Table Expression (CTE).

Запрос асинхронного материализованного представления​

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

Автоматическое переписывание запросов с асинхронным материализованным представлением​

Selena v1.5.2 поддерживает автоматическое и прозрачное переписывание запросов на основе асинхронных материализованных представлений типа SPJG. Материализованные представления типа SPJG относятся к материализованным представлениям, план которых включает только операторы типов Scan, Filter, Project и Aggregate. Переписывание запросов материализованных представлений типа SPJG включает в себя переписывание запросов к одной таблице, переписывание запросов Join, переписывание запросов агрегации, переписывание запросов Union и переписывание запросов на основе вложенных материализованных представлений.

См. Асинхронное материализованное представление - Переписывание запросов с асинхронным материализованным представлением для получения дополнительной информации.

Поддерживаемые типы данных​

  • Асинхронные материализованные представления, созданные на основе каталога Selena по умолчанию, поддерживают следующие типы данных:

    • Date: DATE, DATETIME
    • String: CHAR, VARCHAR
    • Numeric: BOOLEAN, TINYINT, SMALLINT, INT, BIGINT, LARGEINT, FLOAT, DOUBLE, DECIMAL, PERCENTILE
    • Semi-structured: ARRAY, JSON, MAP (с версии v1.5.2), STRUCT (с версии v1.5.2)
    • Other: BITMAP, HLL

ПРИМЕЧАНИЕ

BITMAP, HLL и PERCENTILE поддерживаются с версии v1.5.2.

  • Асинхронные материализованные представления, созданные на основе внешних каталогов Selena, поддерживают следующие типы данных:

    • Hive Catalog

      • Numeric: INT/INTEGER, BIGINT, DOUBLE, FLOAT, DECIMAL
      • Date: TIMESTAMP
      • String: STRING, VARCHAR, CHAR
      • Semi-structured: ARRAY

    • Hudi Catalog

      • Numeric: BOOLEAN, INT, LONG, FLOAT, DOUBLE, DECIMAL
      • Date: DATE, TimeMillis/TimeMicros, TimestampMillis/TimestampMicros
      • String: STRING
      • Semi-structured: ARRAY

    • Iceberg Catalog

      • Numeric: BOOLEAN, INT, LONG, FLOAT, DOUBLE, DECIMAL(P, S)
      • Date: DATE, TIME, TIMESTAMP
      • String: STRING, UUID, FIXED(L), BINARY
      • Semi-structured: LIST

Примечания по использованию​

  • Текущая версия Selena не поддерживает одновременное создание нескольких материализованных представлений. Новое материализованное представление может быть создано только после завершения предыдущего.

  • О синхронных материализованных представлениях:

    • Синхронные материализованные представления поддерживают только агрегатные функции на одном столбце. Запросы в форме sum(a+b) не поддерживаются.
    • Синхронные материализованные представления поддерживают только одну агрегатную функцию для каждого столбца базовой таблицы. Запросы, такие как select sum(a), min(a) from table, не поддерживаются.
    • При создании синхронного материализованного представления с агрегатной функцией необходимо указать предложение GROUP BY и указать хотя бы один столбец GROUP BY в SELECT.
    • Синхронные материализованные представления не поддерживают предложения, такие как JOIN, и предложение HAVING в GROUP BY.
    • При использовании ALTER TABLE DROP COLUMN для удаления определенного столбца в базовой таблице необходимо убедиться, что все синхронные материализованные представления базовой таблицы не содержат удаляемого столбца, в противном случае операция удаления не удастся. Прежде чем удалить столбец, вы должны сначала удалить все синхронные материализованные представления, которые содержат этот столбец.
    • Создание слишком большого количества синхронных материализованных представлений для таблицы повлияет на эффективность загрузки данных. При загрузке данных в базовую таблицу данные в синхронном материализованном представлении и базовой таблице будут обновляться синхронно. Если базовая таблица содержит n синхронных материализованных представлений, эффективность загрузки данных в базовую таблицу примерно такая же, как эффективность загрузки данных в n таблиц.

  • О вложенных асинхронных материализованных представлениях:

    • Стратегия обновления для каждого материализованного представления применяется только к соответствующему материализованному представлению.
    • В настоящее время Selena не ограничивает количество уровней вложенности. В производственной среде мы рекомендуем, чтобы количество уровней вложенности не превышало ТРЕХ.

  • О асинхронных материализованных представлениях внешнего каталога:

    • Материализованное представление внешнего каталога поддерживает только асинхронное обновление с фиксированным интервалом и ручное обновление.
    • Строгая согласованность не гарантируется между материализованным представлением и базовыми таблицами во внешнем каталоге.
    • В настоящее время создание материализованных представлений на основе внешних ресурсов не поддерживается.
    • В настоящее время Selena не может определить, изменились ли данные базовой таблицы во внешнем каталоге, поэтому все разделы будут обновлены по умолчанию при каждом обновлении базовой таблицы. Вы можете вручную обновить только некоторые разделы с помощью REFRESH MATERIALIZED VIEW.

Примеры​

Примеры синхронных материализованных представлений​

Схема базовой таблицы следующая:

mysql> desc duplicate_table;
+-------+--------+------+------+---------+-------+
| Field | Type   | Null | Key  | Default | Extra |
+-------+--------+------+------+---------+-------+
| k1    | INT    | Yes  | true | N/A     |       |
| k2    | INT    | Yes  | true | N/A     |       |
| k3    | BIGINT | Yes  | true | N/A     |       |
| k4    | BIGINT | Yes  | true | N/A     |       |
+-------+--------+------+------+---------+-------+

Пример 1: Создать синхронное материализованное представление, которое содержит только столбцы исходной таблицы (k1, k2).

create materialized view k1_k2 as
select k1, k2 from duplicate_table;

Материализованное представление содержит только два столбца k1 и k2 без какой-либо агрегации.

+-----------------+-------+--------+------+------+---------+-------+
| IndexName       | Field | Type   | Null | Key  | Default | Extra |
+-----------------+-------+--------+------+------+---------+-------+
| k1_k2           | k1    | INT    | Yes  | true | N/A     |       |
|                 | k2    | INT    | Yes  | true | N/A     |       |
+-----------------+-------+--------+------+------+---------+-------+

Пример 2: Создать синхронное материализованное представление, отсортированное по k2.

create materialized view k2_order as
select k2, k1 from duplicate_table order by k2;

Схема материализованного представления показана ниже. Материализованное представление содержит только два столбца k2 и k1, где столбец k2 является столбцом сортировки без какой-либо агрегации.

+-----------------+-------+--------+------+-------+---------+-------+
| IndexName       | Field | Type   | Null | Key   | Default | Extra |
+-----------------+-------+--------+------+-------+---------+-------+
| k2_order        | k2    | INT    | Yes  | true  | N/A     |       |
|                 | k1    | INT    | Yes  | false | N/A     | NONE  |
+-----------------+-------+--------+------+-------+---------+-------+

Пример 3: Создать синхронное материализованное представление, сгруппированное по k1 и k2, и с агрегацией SUM на k3.

create materialized view k1_k2_sumk3 as
select k1, k2, sum(k3) from duplicate_table group by k1, k2;

Схема материализованного представления показана ниже. Материализованное представление содержит три столбца k1, k2 и sum (k3), где k1, k2 — сгруппированные столбцы, а sum (k3) — сумма столбцов k3, сгруппированных в соответствии с k1 и k2.

+-----------------+-------+--------+------+-------+---------+-------+
| IndexName       | Field | Type   | Null | Key   | Default | Extra |
+-----------------+-------+--------+------+-------+---------+-------+
| k1_k2_sumk3     | k1    | INT    | Yes  | true  | N/A     |       |
|                 | k2    | INT    | Yes  | true  | N/A     |       |
|                 | k3    | BIGINT | Yes  | false | N/A     | SUM   |
+-----------------+-------+--------+------+-------+---------+-------+

Поскольку материализованное представление не объявляет столбец сортировки и использует агрегатную функцию, Selena дополняет сгруппированные столбцы k1 и k2 по умолчанию.

Пример 4: Создать синхронное материализованное представление для удаления дублирующихся строк.

create materialized view deduplicate as
select k1, k2, k3, k4 from duplicate_table group by k1, k2, k3, k4;

Схема материализованного представления показана ниже. Материализованное представление содержит столбцы k1, k2, k3 и k4, и нет дублирующихся строк.

+-----------------+-------+--------+------+-------+---------+-------+
| IndexName       | Field | Type   | Null | Key   | Default | Extra |
+-----------------+-------+--------+------+-------+---------+-------+
| deduplicate     | k1    | INT    | Yes  | true  | N/A     |       |
|                 | k2    | INT    | Yes  | true  | N/A     |       |
|                 | k3    | BIGINT | Yes  | true  | N/A     |       |
|                 | k4    | BIGINT | Yes  | true  | N/A     |       |
+-----------------+-------+--------+------+-------+---------+-------+

Пример 5: Создать неагрегированное синхронное материализованное представление, которое не объявляет столбец сортировки.

Схема базовой таблицы показана ниже:

+-------+--------------+------+-------+---------+-------+
| Field | Type         | Null | Key   | Default | Extra |
+-------+--------------+------+-------+---------+-------+
| k1    | TINYINT      | Yes  | true  | N/A     |       |
| k2    | SMALLINT     | Yes  | true  | N/A     |       |
| k3    | INT          | Yes  | true  | N/A     |       |
| k4    | BIGINT       | Yes  | true  | N/A     |       |
| k5    | DECIMAL(9,0) | Yes  | true  | N/A     |       |
| k6    | DOUBLE       | Yes  | false | N/A     | NONE  |
| k7    | VARCHAR(20)  | Yes  | false | N/A     | NONE  |
+-------+--------------+------+-------+---------+-------+

Материализованное представление содержит столбцы k3, k4, k5, k6 и k7, и столбец сортировки не объявлен. Создайте материализованное представление со следующим оператором:

create materialized view mv_1 as
select k3, k4, k5, k6, k7 from all_type_table;

Selena автоматически использует k3, k4 и k5 в качестве столбцов сортировки по умолчанию. Сумма байтов, занимаемых этими тремя типами столбцов, составляет 4 (INT) + 8 (BIGINT) + 16 (DECIMAL) = 28 < 36. Поэтому эти три столбца добавляются в качестве столбцов сортировки.

Схема материализованного представления следующая.

+----------------+-------+--------------+------+-------+---------+-------+
| IndexName      | Field | Type         | Null | Key   | Default | Extra |
+----------------+-------+--------------+------+-------+---------+-------+
| mv_1           | k3    | INT          | Yes  | true  | N/A     |       |
|                | k4    | BIGINT       | Yes  | true  | N/A     |       |
|                | k5    | DECIMAL(9,0) | Yes  | true  | N/A     |       |
|                | k6    | DOUBLE       | Yes  | false | N/A     | NONE  |
|                | k7    | VARCHAR(20)  | Yes  | false | N/A     | NONE  |
+----------------+-------+--------------+------+-------+---------+-------+

Можно заметить, что поле key столбцов k3, k4 и k5 — true, что указывает на то, что они являются ключами сортировки. Поле key столбцов k6 и k7 — false, что указывает на то, что они не являются ключами сортировки.

Пример 6: Создать синхронное материализованное представление, которое содержит предложение WHERE и сложные выражения.

-- Создать базовую таблицу: user_event
CREATE TABLE user_event (
      ds date   NOT NULL,
      id  varchar(256)    NOT NULL,
      user_id int DEFAULT NULL,
      user_id1    varchar(256)    DEFAULT NULL,
      user_id2    varchar(256)    DEFAULT NULL,
      column_01   int DEFAULT NULL,
      column_02   int DEFAULT NULL,
      column_03   int DEFAULT NULL,
      column_04   int DEFAULT NULL,
      column_05   int DEFAULT NULL,
      column_06   DECIMAL(12,2)   DEFAULT NULL,
      column_07   DECIMAL(12,3)   DEFAULT NULL,
      column_08   JSON   DEFAULT NULL,
      column_09   DATETIME    DEFAULT NULL,
      column_10   DATETIME    DEFAULT NULL,
      column_11   DATE    DEFAULT NULL,
      column_12   varchar(256)    DEFAULT NULL,
      column_13   varchar(256)    DEFAULT NULL,
      column_14   varchar(256)    DEFAULT NULL,
      column_15   varchar(256)    DEFAULT NULL,
      column_16   varchar(256)    DEFAULT NULL,
      column_17   varchar(256)    DEFAULT NULL,
      column_18   varchar(256)    DEFAULT NULL,
      column_19   varchar(256)    DEFAULT NULL,
      column_20   varchar(256)    DEFAULT NULL,
      column_21   varchar(256)    DEFAULT NULL,
      column_22   varchar(256)    DEFAULT NULL,
      column_23   varchar(256)    DEFAULT NULL,
      column_24   varchar(256)    DEFAULT NULL,
      column_25   varchar(256)    DEFAULT NULL,
      column_26   varchar(256)    DEFAULT NULL,
      column_27   varchar(256)    DEFAULT NULL,
      column_28   varchar(256)    DEFAULT NULL,
      column_29   varchar(256)    DEFAULT NULL,
      column_30   varchar(256)    DEFAULT NULL,
      column_31   varchar(256)    DEFAULT NULL,
      column_32   varchar(256)    DEFAULT NULL,
      column_33   varchar(256)    DEFAULT NULL,
      column_34   varchar(256)    DEFAULT NULL,
      column_35   varchar(256)    DEFAULT NULL,
      column_36   varchar(256)    DEFAULT NULL,
      column_37   varchar(256)    DEFAULT NULL
  )
  PARTITION BY date_trunc("day", ds)
  DISTRIBUTED BY hash(id);

  -- Создать материализованное представление с предложением WHERE и сложными выражениями.
  CREATE MATERIALIZED VIEW test_mv1
  AS
  SELECT
  ds,
  column_19,
  column_36,
  sum(column_01) as column_01_sum,
  bitmap_union(to_bitmap( user_id)) as user_id_dist_cnt,
  bitmap_union(to_bitmap(case when column_01 > 1 and column_34 IN ('1','34')   then user_id2 else null end)) as filter_dist_cnt_1,
  bitmap_union(to_bitmap( case when column_02 > 60 and column_35 IN ('11','13') then  user_id2 else null end)) as filter_dist_cnt_2,
  bitmap_union(to_bitmap(case when column_03 > 70 and column_36 IN ('21','23') then  user_id2 else null end)) as filter_dist_cnt_3,
  bitmap_union(to_bitmap(case when column_04 > 20 and column_27 IN ('31','27') then  user_id2 else null end)) as filter_dist_cnt_4,
  bitmap_union(to_bitmap( case when column_05 > 90 and column_28 IN ('41','43') then  user_id2 else null end)) as filter_dist_cnt_5
  FROM user_event
  WHERE ds >= '2023-11-02'
  GROUP BY
  ds,
  column_19,
  column_36;

Примеры асинхронных материализованных представлений​

Следующие примеры основаны на базовых таблицах ниже:

CREATE TABLE `lineorder` (
  `lo_orderkey` int(11) NOT NULL COMMENT "",
  `lo_linenumber` int(11) NOT NULL COMMENT "",
  `lo_custkey` int(11) NOT NULL COMMENT "",
  `lo_partkey` int(11) NOT NULL COMMENT "",
  `lo_suppkey` int(11) NOT NULL COMMENT "",
  `lo_orderdate` int(11) NOT NULL COMMENT "",
  `lo_orderpriority` varchar(16) NOT NULL COMMENT "",
  `lo_shippriority` int(11) NOT NULL COMMENT "",
  `lo_quantity` int(11) NOT NULL COMMENT "",
  `lo_extendedprice` int(11) NOT NULL COMMENT "",
  `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
  `lo_discount` int(11) NOT NULL COMMENT "",
  `lo_revenue` int(11) NOT NULL COMMENT "",
  `lo_supplycost` int(11) NOT NULL COMMENT "",
  `lo_tax` int(11) NOT NULL COMMENT "",
  `lo_commitdate` int(11) NOT NULL COMMENT "",
  `lo_shipmode` varchar(11) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`lo_orderkey`)
COMMENT "OLAP"
PARTITION BY RANGE(`lo_orderdate`)
(PARTITION p1 VALUES [("-2147483648"), ("19930101")),
PARTITION p2 VALUES [("19930101"), ("19940101")),
PARTITION p3 VALUES [("19940101"), ("19950101")),
PARTITION p4 VALUES [("19950101"), ("19960101")),
PARTITION p5 VALUES [("19960101"), ("19970101")),
PARTITION p6 VALUES [("19970101"), ("19980101")),
PARTITION p7 VALUES [("19980101"), ("19990101")))
DISTRIBUTED BY HASH(`lo_orderkey`);

CREATE TABLE IF NOT EXISTS `customer` (
  `c_custkey` int(11) NOT NULL COMMENT "",
  `c_name` varchar(26) NOT NULL COMMENT "",
  `c_address` varchar(41) NOT NULL COMMENT "",
  `c_city` varchar(11) NOT NULL COMMENT "",
  `c_nation` varchar(16) NOT NULL COMMENT "",
  `c_region` varchar(13) NOT NULL COMMENT "",
  `c_phone` varchar(16) NOT NULL COMMENT "",
  `c_mktsegment` varchar(11) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`c_custkey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`c_custkey`);

CREATE TABLE IF NOT EXISTS `dates` (
  `d_datekey` int(11) NOT NULL COMMENT "",
  `d_date` varchar(20) NOT NULL COMMENT "",
  `d_dayofweek` varchar(10) NOT NULL COMMENT "",
  `d_month` varchar(11) NOT NULL COMMENT "",
  `d_year` int(11) NOT NULL COMMENT "",
  `d_yearmonthnum` int(11) NOT NULL COMMENT "",
  `d_yearmonth` varchar(9) NOT NULL COMMENT "",
  `d_daynuminweek` int(11) NOT NULL COMMENT "",
  `d_daynuminmonth` int(11) NOT NULL COMMENT "",
  `d_daynuminyear` int(11) NOT NULL COMMENT "",
  `d_monthnuminyear` int(11) NOT NULL COMMENT "",
  `d_weeknuminyear` int(11) NOT NULL COMMENT "",
  `d_sellingseason` varchar(14) NOT NULL COMMENT "",
  `d_lastdayinweekfl` int(11) NOT NULL COMMENT "",
  `d_lastdayinmonthfl` int(11) NOT NULL COMMENT "",
  `d_holidayfl` int(11) NOT NULL COMMENT "",
  `d_weekdayfl` int(11) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`d_datekey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`d_datekey`);

CREATE TABLE IF NOT EXISTS `supplier` (
  `s_suppkey` int(11) NOT NULL COMMENT "",
  `s_name` varchar(26) NOT NULL COMMENT "",
  `s_address` varchar(26) NOT NULL COMMENT "",
  `s_city` varchar(11) NOT NULL COMMENT "",
  `s_nation` varchar(16) NOT NULL COMMENT "",
  `s_region` varchar(13) NOT NULL COMMENT "",
  `s_phone` varchar(16) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`s_suppkey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`s_suppkey`);

CREATE TABLE IF NOT EXISTS `part` (
  `p_partkey` int(11) NOT NULL COMMENT "",
  `p_name` varchar(23) NOT NULL COMMENT "",
  `p_mfgr` varchar(7) NOT NULL COMMENT "",
  `p_category` varchar(8) NOT NULL COMMENT "",
  `p_brand` varchar(10) NOT NULL COMMENT "",
  `p_color` varchar(12) NOT NULL COMMENT "",
  `p_type` varchar(26) NOT NULL COMMENT "",
  `p_size` int(11) NOT NULL COMMENT "",
  `p_container` varchar(11) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`p_partkey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`p_partkey`);

create table orders (
    dt date NOT NULL,
    order_id bigint NOT NULL,
    user_id int NOT NULL,
    merchant_id int NOT NULL,
    good_id int NOT NULL,
    good_name string NOT NULL,
    price int NOT NULL,
    cnt int NOT NULL,
    revenue int NOT NULL,
    state tinyint NOT NULL
)
PRIMARY KEY (dt, order_id)
PARTITION BY RANGE(`dt`)
( PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')) )
DISTRIBUTED BY HASH(order_id)
PROPERTIES (
    "replication_num" = "3",
    "enable_persistent_index" = "true"
);

Пример 1: Создать неразделенное материализованное представление.

-- создать неразделенное материализованное представление, отсортированное по lo_custkey
CREATE MATERIALIZED VIEW lo_mv1
DISTRIBUTED BY HASH(`lo_orderkey`)
ORDER BY `lo_custkey`
REFRESH ASYNC
AS
select
    lo_orderkey,
    lo_custkey,
    sum(lo_quantity) as total_quantity,
    sum(lo_revenue) as total_revenue,
    count(lo_shipmode) as shipmode_count
from lineorder
group by lo_orderkey, lo_custkey;

Пример 2: Создать разделенное материализованное представление.

-- создать разделенное материализованное представление, разделенное по `lo_orderdate` и отсортированное по `lo_custkey`.
CREATE MATERIALIZED VIEW lo_mv2
PARTITION BY `lo_orderdate`
DISTRIBUTED BY HASH(`lo_orderkey`)
ORDER BY `lo_custkey`
REFRESH ASYNC START('2023-07-01 10:00:00') EVERY (interval 1 day)
AS
select
    lo_orderkey,
    lo_orderdate,
    lo_custkey,
    sum(lo_quantity) as total_quantity,
    sum(lo_revenue) as total_revenue,
    count(lo_shipmode) as shipmode_count
from lineorder
group by lo_orderkey, lo_orderdate, lo_custkey;

-- Использовать функцию date_trunc() для разделения материализованного представления по месяцам.
CREATE MATERIALIZED VIEW order_mv1
PARTITION BY date_trunc('month', `dt`)
DISTRIBUTED BY HASH(`order_id`)
REFRESH ASYNC START('2023-07-01 10:00:00') EVERY (interval 1 day)
AS
select
    dt,
    order_id,
    user_id,
    sum(cnt) as total_cnt,
    sum(revenue) as total_revenue,
    count(state) as state_count
from orders
group by dt, order_id, user_id;

Пример 3: Создать асинхронное материализованное представление.

CREATE MATERIALIZED VIEW flat_lineorder
DISTRIBUTED BY HASH(`lo_orderkey`)
REFRESH MANUAL
AS
SELECT
    l.LO_ORDERKEY AS LO_ORDERKEY,
    l.LO_LINENUMBER AS LO_LINENUMBER,
    l.LO_CUSTKEY AS LO_CUSTKEY,
    l.LO_PARTKEY AS LO_PARTKEY,
    l.LO_SUPPKEY AS LO_SUPPKEY,
    l.LO_ORDERDATE AS LO_ORDERDATE,
    l.LO_ORDERPRIORITY AS LO_ORDERPRIORITY,
    l.LO_SHIPPRIORITY AS LO_SHIPPRIORITY,
    l.LO_QUANTITY AS LO_QUANTITY,
    l.LO_EXTENDEDPRICE AS LO_EXTENDEDPRICE,
    l.LO_ORDTOTALPRICE AS LO_ORDTOTALPRICE,
    l.LO_DISCOUNT AS LO_DISCOUNT,
    l.LO_REVENUE AS LO_REVENUE,
    l.LO_SUPPLYCOST AS LO_SUPPLYCOST,
    l.LO_TAX AS LO_TAX,
    l.LO_COMMITDATE AS LO_COMMITDATE,
    l.LO_SHIPMODE AS LO_SHIPMODE,
    c.C_NAME AS C_NAME,
    c.C_ADDRESS AS C_ADDRESS,
    c.C_CITY AS C_CITY,
    c.C_NATION AS C_NATION,
    c.C_REGION AS C_REGION,
    c.C_PHONE AS C_PHONE,
    c.C_MKTSEGMENT AS C_MKTSEGMENT,
    s.S_NAME AS S_NAME,
    s.S_ADDRESS AS S_ADDRESS,
    s.S_CITY AS S_CITY,
    s.S_NATION AS S_NATION,
    s.S_REGION AS S_REGION,
    s.S_PHONE AS S_PHONE,
    p.P_NAME AS P_NAME,
    p.P_MFGR AS P_MFGR,
    p.P_CATEGORY AS P_CATEGORY,
    p.P_BRAND AS P_BRAND,
    p.P_COLOR AS P_COLOR,
    p.P_TYPE AS P_TYPE,
    p.P_SIZE AS P_SIZE,
    p.P_CONTAINER AS P_CONTAINER FROM lineorder AS l
INNER JOIN customer AS c ON c.C_CUSTKEY = l.LO_CUSTKEY
INNER JOIN supplier AS s ON s.S_SUPPKEY = l.LO_SUPPKEY
INNER JOIN part AS p ON p.P_PARTKEY = l.LO_PARTKEY;

Пример 4: Создать разделенное материализованное представление и использовать str2date для преобразования ключа раздела типа STRING базовой таблицы в тип даты для материализованного представления.


-- Таблица Hive со столбцом раздела string.
CREATE TABLE `part_dates` (
  `d_date` varchar(20) DEFAULT NULL,
  `d_dayofweek` varchar(10) DEFAULT NULL,
  `d_month` varchar(11) DEFAULT NULL,
  `d_year` int(11) DEFAULT NULL,
  `d_yearmonthnum` int(11) DEFAULT NULL,
  `d_yearmonth` varchar(9) DEFAULT NULL,
  `d_daynuminweek` int(11) DEFAULT NULL,
  `d_daynuminmonth` int(11) DEFAULT NULL,
  `d_daynuminyear` int(11) DEFAULT NULL,
  `d_monthnuminyear` int(11) DEFAULT NULL,
  `d_weeknuminyear` int(11) DEFAULT NULL,
  `d_sellingseason` varchar(14) DEFAULT NULL,
  `d_lastdayinweekfl` int(11) DEFAULT NULL,
  `d_lastdayinmonthfl` int(11) DEFAULT NULL,
  `d_holidayfl` int(11) DEFAULT NULL,
  `d_weekdayfl` int(11) DEFAULT NULL,
  `d_datekey` varchar(11) DEFAULT NULL
) partition by (d_datekey);


-- Создать материализованное представление с `str2date`.
CREATE MATERIALIZED VIEW IF NOT EXISTS `test_mv`
PARTITION BY str2date(`d_datekey`,'%Y%m%d')
DISTRIBUTED BY HASH(`d_date`, `d_month`, `d_month`)
REFRESH MANUAL
AS
SELECT
`d_date` ,
  `d_dayofweek`,
  `d_month` ,
  `d_yearmonthnum` ,
  `d_yearmonth` ,
  `d_daynuminweek`,
  `d_daynuminmonth`,
  `d_daynuminyear` ,
  `d_monthnuminyear` ,
  `d_weeknuminyear` ,
  `d_sellingseason`,
  `d_lastdayinweekfl`,
  `d_lastdayinmonthfl`,
  `d_holidayfl` ,
  `d_weekdayfl`,
   `d_datekey`
FROM
 `hive_catalog`.`ssb_1g_orc`.`part_dates` ;

Пример 5: Создать разделенное материализованное представление с многостолбцовым выражением раздела на основе базовой таблицы из Iceberg Catalog (Spark).

Определение базовой таблицы в Spark:

-- Выражение раздела базовой таблицы содержит несколько столбцов и преобразование `days`.
CREATE TABLE lineitem_days (
      l_orderkey    BIGINT,
      l_partkey     INT,
      l_suppkey     INT,
      l_linenumber  INT,
      l_quantity    DECIMAL(15, 2),
      l_extendedprice  DECIMAL(15, 2),
      l_discount    DECIMAL(15, 2),
      l_tax         DECIMAL(15, 2),
      l_returnflag  VARCHAR(1),
      l_linestatus  VARCHAR(1),
      l_shipdate    TIMESTAMP,
      l_commitdate  TIMESTAMP,
      l_receiptdate TIMESTAMP,
      l_shipinstruct VARCHAR(25),
      l_shipmode     VARCHAR(10),
      l_comment      VARCHAR(44)
) USING ICEBERG
PARTITIONED BY (l_returnflag, l_linestatus, days(l_shipdate));

Создать материализованное представление со столбцами разделов, сопоставленными один к одному с теми из базовой таблицы:

CREATE MATERIALIZED VIEW test_days
PARTITION BY (l_returnflag, l_linestatus, date_trunc('day', l_shipdate))
REFRESH DEFERRED MANUAL
AS
SELECT * FROM iceberg_catalog.test_db.lineitem_days;

Пример 6: Создать разделенное материализованное представление, определить TTL выражения общего раздела для него и включить семантику force_mv для переписывания запросов.

CREATE MATERIALIZED VIEW test_mv1
PARTITION BY (dt, province)
REFRESH MANUAL
PROPERTIES (
    "partition_retention_condition" = "dt >= CURRENT_DATE() - INTERVAL 3 MONTH",
    "query_rewrite_consistency" = "force_mv"
)
AS SELECT * from t1;

Пример 7: Создать разделенное материализованное представление с определенным ключом сортировки:

CREATE MATERIALIZED VIEW lo_mv2
PARTITION BY `lo_orderdate`
DISTRIBUTED BY HASH(`lo_orderkey`)
ORDER BY `lo_custkey`
REFRESH ASYNC START('2023-07-01 10:00:00') EVERY (interval 1 day)
AS
select
    lo_orderkey,
    lo_orderdate,
    lo_custkey,
    sum(lo_quantity) as total_quantity,
    sum(lo_revenue) as total_revenue,
    count(lo_shipmode) as shipmode_count
from lineorder
group by lo_orderkey, lo_orderdate, lo_custkey;