Hologres:Suporte e limitações de Dynamic Table

Limitações

• Uso de recursos

  A partir do Hologres V3.1, novas tabelas usam recursos serverless por padrão para executar tarefas de atualização. Se a instância não tiver recursos serverless ativados, o sistema mudará automaticamente para recursos locais. Tabelas criadas no Hologres V3.0 continuam usando os recursos especificados originalmente e não migram automaticamente para recursos serverless.

• Limitações em tabelas base

  • O Hologres aceita apenas tabelas internas, tabelas externas Paimon e outras Dynamic Tables como tabelas base. Para criar uma Dynamic Table, você precisa ter permissões SELECT na tabela base.

  • Por padrão, o Hologres V3.1 consome dados da tabela base de forma incremental pelo método stream. Em comparação ao método Binlog, o método stream oferece melhor desempenho e não gera custos adicionais de armazenamento. Se sua tabela base usava o método Binlog antes da V3.1, desative o Binlog prontamente para evitar consumo extra de armazenamento. Para desativar o Binlog, consulte Subscribe to Hologres Binlog.

  • No Hologres V3.0, ao criar uma Dynamic Table no modo de atualização incremental, ative o Binlog na tabela base. No entanto, isso não é obrigatório para tabelas de dimensão. Para mais informações sobre como ativar o Binlog, consulte Subscribe to Hologres Binlog.

• Limitações em consultas

  • Cenários suportados

    • Qualquer expressão escalar

    • Condições WHERE

    • Subconsultas

    • Common Table Expressions (CTEs)

    • GROUP BY

    • CUBE

    • GROUPING SETS

    • Cláusulas HAVING

    • Filtros de agregação

    • UNION ALL

    • UNNEST

  • Funções de janela: apenas as funções listadas abaixo têm suporte. Todas as demais funções de janela, como dense_rank, first_value e last_value, além de janelas de agregação como SUM e COUNT, não são suportadas.

    • row_number e rank: suportadas no Hologres V4.2 e versões posteriores. A consulta deve incluir um filtro TopN na consulta externa (WHERE rownum <= N) e especifique tanto PARTITION BY quanto ORDER BY.

    • lead e lag: suportadas no Hologres V5.0 e versões posteriores. Especifique PARTITION BY e ORDER BY. Apenas as formas com argumento único lead(expr) e lag(expr) são suportadas.

    • Uma definição de janela única geralmente suporta apenas uma função de janela. As funções lead e lag são exceção: ambas podem ser usadas sob a mesma definição de janela.

    • Para sintaxe detalhada e limites, consulte Supported functions for incremental refresh.

  • Cenários não suportados

    • Subconsultas IN

    • EXISTS ou NOT EXISTS

    • EXCEPT ou INTERSECT

    • ORDER BY

    • LIMIT ou OFFSET

  • Junção de múltiplas tabelas:

    • O Hologres V3.0 suporta apenas equi-joins (INNER JOIN ou LEFT JOIN) em tabelas de dimensão. Essas junções devem usar a sintaxe FOR SYSTEM_TIME AS OF PROCTIME(). Junções de fluxo duplo com múltiplas tabelas não são suportadas. Para mais informações, consulte Lookup join statements.

      Nota

      Um lookup join associa cada registro à versão mais recente dos dados da tabela de dimensão no momento do processamento. Se os dados da tabela de dimensão forem alterados após a junção, os dados previamente unidos não serão atualizados.

    • A partir do Hologres V3.0.26, há suporte para junções de fluxo duplo com múltiplas tabelas. Elas equivalem a junções OLAP padrão ou junções de fluxo duplo no Flink, incluindo INNER JOIN e LEFT/RIGHT/FULL OUTER JOIN. Para mais informações, consulte CREATE DYNAMIC TABLE.

  • Funções: funções de agregação como COUNT, SUM, MIN/MAX e COUNT DISTINCT são suportadas. Funções executadas no Parallel Query Engine (PQE) não são suportadas. A tabela a seguir descreve outras funções suportadas.

    Função	Sintaxe	Exemplo	Versão suportada
    RB_BUILD_AGG	RB_BUILD_AGG(<column>) Nota O parâmetro column suporta os tipos de dados INT32 e INT64. Para mais informações, consulte RoaringBitmap functions.	CREATE DYNAMIC TABLE daily_uv PARTITION BY list (day) WITH ( freshness = '5 minutes', refresh_mode = 'incremental') AS SELECT day, game_id, gameversion, RB_BUILD_AGG(user_id) AS user_rb FROM base_table GROUP BY day, game_id, gameversion;	V3.1 e posteriores
    STRING_AGG	STRING_AGG([DISTINCT] column_expr, const_expr) Nota Tipos de dados: column_expr deve ser TEXT, CHAR ou VARCHAR. const_expr deve ser uma constante TEXT. A cláusula ORDER BY não é suportada. A partir do Hologres V3.1.10, há suporte para STRING_AGG([DISTINCT].	CREATE DYNAMIC TABLE string_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, STRING_AGG(gameversion, ',') AS gameversion_list FROM base_table GROUP BY day;	V3.1 e posteriores A partir da V3.1.10, há suporte para STRING_AGG([DISTINCT].
    ARRAY_AGG	ARRAY_AGG([DISTINCT] expr) Nota Tipos de dados: O parâmetro expr suporta BOOL, todos os tipos numéricos, TEXT e BYTEA. A cláusula ORDER BY não é suportada. A partir do Hologres V3.1.10, há suporte para ARRAY_AGG([DISTINCT].	CREATE DYNAMIC TABLE array_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, ARRAY_AGG(gameversion) AS gameversion_list FROM base_table GROUP BY day;	V3.1 e posteriores A partir da V3.1.10, há suporte para ARRAY_AGG([DISTINCT].
    ANY_VALUE	Em uma consulta de agregação que contém uma cláusula GROUP BY, esta função retorna de forma não determinística um valor de uma das linhas dentro de cada grupo. ANY_VALUE(expr) A função ANY_VALUE aceita apenas os tipos de dados INT e BINARY.	CREATE DYNAMIC TABLE dt_t0 WITH ( -- Properties of the dynamic table freshness = '1 minutes', auto_refresh_mode = 'auto' ) AS SELECT a, any_value(c), SUM(b) FROM t0 GROUP BY a;	V3.1.5 e posteriores

  • A partir do Hologres V3.1, configure uma Dynamic Table como partição lógica. As propriedades de partição associadas e configurações de gerenciamento também são suportadas.

Recursos suportados

• Tabelas base: A funcionalidade é a mesma das tabelas padrão do Hologres. Use tabelas internas e externas do Hologres, como as do MaxCompute, Data Lake Formation (DLF) e Paimon, como tabelas base. Você precisa ter as permissões adequadas na tabela base para criar uma Dynamic Table. Para mais informações, consulte Dynamic Table permissions.

• Consultas: Todas as funções, expressões SQL e tipos de dados atualmente suportados pelo Hologres também funcionam no modo de atualização completa.

• Recursos de atualização: Por padrão, as tarefas de atualização usam recursos serverless. Também é possível configurar as tarefas para utilizar os recursos da instância atual.

Limitações

• Não é possível alterar o modo de atualização de completa para incremental.

• No Hologres V3.0, se você criar uma VIEW em uma Dynamic Table que esteja no modo de atualização completa, o processo de atualização da Dynamic Table falhará. Esse problema foi corrigido na V3.1 e em versões posteriores. Atualize sua instância.

Limitações em Dynamic Tables

• Sua instância do Hologres deve ser V3.0 ou superior.

• Restrições de propriedades da tabela: Não defina chave primária ou valores padrão de campo. O mecanismo infere automaticamente o índice da tabela, mas você também pode defini-lo manualmente conforme suas necessidades de negócio.

• Apenas os modos de atualização completa e incremental são suportados. Os recursos e limitações variam conforme o modo. Para detalhes, consulte Full refresh e Incremental refresh.

• A atualização em cascata (freshness = 'upstream') possui os seguintes limites, aplicáveis tanto à atualização completa quanto à incremental:

  • Suportada apenas no Hologres V5.0 e versões posteriores.

  • Ao definir freshness = 'upstream', pelo menos uma das tabelas base deve ser uma Dynamic Table.

  • Dependências em cascata não podem formar ciclos.

  • Se uma atualização upstream falhar, as atualizações downstream não serão acionadas. Falhas não se propagam para downstream, e as tabelas downstream mantêm os dados da última atualização bem-sucedida.

  • Se uma Dynamic Table possuir dependências downstream, o comando DROP nessa tabela será rejeitado. Exclua primeiro as tabelas downstream ou remova as dependências.

  • Apenas uma atualização em cascata é executada por vez para uma determinada tabela downstream. Se os gatilhos upstream chegarem com muita frequência, rodadas intermediárias são ignoradas. O intervalo efetivo de atualização da tabela downstream corresponderá ao maior valor entre a duração de sua própria atualização de rodada única e o intervalo do gatilho upstream.

Limitações em operações DDL e DML