Hologres:Prise en charge et limites des Dynamic Tables

Limites

• Utilisation des ressources

  À partir de Hologres V3.1, les nouvelles tables utilisent par défaut des ressources serverless pour exécuter les tâches d'actualisation. Si l'instance n'a pas activé les ressources serverless, elle bascule automatiquement vers les ressources locales. Les tables créées dans Hologres V3.0 continuent d'utiliser les ressources initialement spécifiées et ne basculent pas automatiquement vers les ressources serverless.

• Limites relatives aux tables de base

  • Seules les tables internes Hologres, les tables externes Paimon et les autres Dynamic Tables sont prises en charge comme tables de base. Pour créer une Dynamic Table, vous devez disposer des autorisations SELECT sur la table de base.

  • Par défaut, Hologres V3.1 consomme les données de la table de base de manière incrémentielle via la méthode stream. Par rapport à la méthode Binlog, la méthode stream offre de meilleures performances et n'engendre aucun coût de stockage supplémentaire. Si votre table de base utilisait la méthode Binlog avant la version 3.1, nous vous recommandons de désactiver rapidement le Binlog afin d'éviter une consommation de stockage additionnelle. Pour désactiver le Binlog, consultez la section Souscription au Binlog Hologres.

  • Dans Hologres V3.0, lors de la création d'une Dynamic Table en mode d'actualisation incrémentielle, le Binlog doit être activé pour la table de base. Cela n'est toutefois pas requis pour les tables de dimension. Pour plus d'informations sur l'activation du Binlog, consultez la section Souscription au Binlog Hologres.

• Limites relatives aux requêtes

  • Scénarios pris en charge

    • Toute expression scalaire

    • Conditions WHERE

    • Sous-requêtes

    • Expressions de table communes (CTE)

    • GROUP BY

    • CUBE

    • GROUPING SETS

    • Clauses HAVING

    • Filtres d'agrégation

    • UNION ALL

    • UNNEST

  • Fonctions de fenêtrage : seules les fonctions suivantes sont prises en charge. Toutes les autres fonctions de fenêtrage, telles que dense_rank, first_value et last_value, ainsi que les fenêtres d'agrégation comme SUM et COUNT, ne sont pas prises en charge.

    • row_number et rank : pris en charge à partir de Hologres V4.2. La requête doit inclure un filtre TopN dans la requête externe (WHERE rownum <= N) et spécifier à la fois PARTITION BY et ORDER BY.

    • lead et lag : pris en charge à partir de Hologres V5.0. Vous devez spécifier à la fois PARTITION BY et ORDER BY, et seules les formes à argument unique lead(expr) et lag(expr) sont prises en charge.

    • Une définition de fenêtre unique ne prend généralement en charge qu'une seule fonction de fenêtrage. lead et lag constituent une exception : les deux peuvent être utilisées sous la même définition de fenêtre.

    • Pour la syntaxe détaillée et les limites, consultez la section Fonctions prises en charge pour l'actualisation incrémentielle.

  • Scénarios non pris en charge

    • Sous-requêtes IN

    • EXISTS ou NOT EXISTS

    • EXCEPT ou INTERSECT

    • ORDER BY

    • LIMIT ou OFFSET

  • Jointure multi-tables :

    • Hologres V3.0 prend uniquement en charge les jointures équivalentes (INNER JOIN ou LEFT JOIN) sur les tables de dimension, et ces jointures doivent utiliser la syntaxe FOR SYSTEM_TIME AS OF PROCTIME(). Les jointures double flux multi-tables ne sont pas prises en charge. Pour plus d'informations, consultez la section Instructions de jointure de recherche.

      Remarque

      Une jointure de recherche associe chaque enregistrement à la dernière version des données de la table de dimension au moment du traitement. Si les données de la table de dimension changent après la jointure, les données précédemment jointes ne sont pas mises à jour.

    • À partir de Hologres V3.0.26, les jointures double flux multi-tables sont prises en charge. Elles équivalent aux jointures OLAP standard ou aux jointures double flux dans Flink et incluent INNER JOIN ainsi que LEFT/RIGHT/FULL OUTER JOIN. Pour plus d'informations, consultez la section CREATE DYNAMIC TABLE.

  • Fonctions : les fonctions d'agrégation telles que COUNT, SUM, MIN/MAX et COUNT DISTINCT sont prises en charge. Les fonctions s'exécutant sur le moteur Parallel Query Engine (PQE) ne sont pas prises en charge. Le tableau suivant décrit les autres fonctions prises en charge.

    Fonction	Syntaxe	Exemple	Version prise en charge
    RB_BUILD_AGG	RB_BUILD_AGG(<column>) Remarque Le paramètre column prend en charge les types de données INT32 et INT64. Pour plus d'informations, consultez la section Fonctions RoaringBitmap.	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 et versions ultérieures
    STRING_AGG	STRING_AGG([DISTINCT] column_expr, const_expr) Remarque Types de données : column_expr doit être de type TEXT, CHAR ou VARCHAR. const_expr doit être une constante TEXT. La clause ORDER BY n'est pas prise en charge. À partir de Hologres V3.1.10, STRING_AGG([DISTINCT] est pris en charge.	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 et versions ultérieures À partir de V3.1.10, STRING_AGG([DISTINCT] est pris en charge.
    ARRAY_AGG	ARRAY_AGG([DISTINCT] expr) Remarque Types de données : Le paramètre expr prend en charge les types BOOL, tous les types numériques, TEXT et BYTEA. La clause ORDER BY n'est pas prise en charge. À partir de Hologres V3.1.10, ARRAY_AGG([DISTINCT] est pris en charge.	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 et versions ultérieures À partir de Hologres V3.1.10, ARRAY_AGG([DISTINCT] est pris en charge.
    ANY_VALUE	Dans une requête d'agrégation contenant une clause GROUP BY, cette fonction renvoie de manière non déterministe une valeur issue de l'une des lignes de chaque groupe. ANY_VALUE(expr) La fonction ANY_VALUE accepte uniquement les types de données INT et BINARY.	CREATE DYNAMIC TABLE dt_t0 WITH ( -- Propriétés de la 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 et versions ultérieures

  • À partir de Hologres V3.1, vous pouvez configurer une Dynamic Table en tant que partition logique. Les propriétés de partition associées et les paramètres de gestion sont également pris en charge.

Fonctionnalités prises en charge

• Tables de base : la fonctionnalité est identique à celle des tables Hologres standard. Vous pouvez utiliser des tables internes Hologres et des tables externes, telles que celles provenant de MaxCompute, Data Lake Formation (DLF) et Paimon, comme tables de base. Vous devez disposer des autorisations requises sur la table de base pour créer une Dynamic Table. Pour plus d'informations, consultez la section Autorisations Dynamic Table.

• Requêtes : toutes les fonctions, expressions SQL et types de données actuellement pris en charge par Hologres sont également pris en charge en mode d'actualisation complète.

• Ressources d'actualisation : par défaut, les tâches d'actualisation utilisent des ressources serverless. Vous pouvez également configurer les tâches pour qu'elles utilisent les ressources de votre instance actuelle.

Limites

• Vous ne pouvez pas modifier le mode d'actualisation de l'actualisation complète vers l'actualisation incrémentielle.

• Dans Hologres V3.0, si vous créez une VIEW sur une Dynamic Table en mode d'actualisation complète, le processus d'actualisation de la Dynamic Table échoue. Ce problème est résolu dans les versions V3.1 et ultérieures. Nous vous recommandons de mettre à niveau votre instance.

Limites relatives aux dynamic tables

• Votre instance Hologres doit être en version 3.0 ou ultérieure.

• Limites relatives aux propriétés de table : vous ne pouvez pas définir de clé primaire ni de valeurs de champ par défaut. Le moteur déduit automatiquement l'index de la table, mais vous pouvez également le définir manuellement selon vos besoins métier.

• Seuls les modes d'actualisation complète et incrémentielle sont pris en charge. Les fonctionnalités prises en charge et les limites varient selon le mode. Pour plus de détails, consultez les sections Actualisation complète et Actualisation incrémentielle.

• L'actualisation en cascade (freshness = 'upstream') présente les limites suivantes, qui s'appliquent à la fois à l'actualisation complète et à l'actualisation incrémentielle :

  • Pris en charge uniquement dans Hologres V5.0 et versions ultérieures.

  • Lorsque vous définissez freshness = 'upstream', au moins l'une des tables de base doit être une dynamic table.

  • Les dépendances en cascade ne peuvent pas former de cycle.

  • Si une actualisation en amont échoue, les actualisations en aval ne sont pas déclenchées. Les échecs ne se propagent pas en aval et les tables en aval conservent les données de leur dernière actualisation réussie.

  • Si une dynamic table possède des dépendances en aval, l'opération DROP sur cette table est rejetée. Vous devez d'abord supprimer les tables en aval ou supprimer les dépendances.

  • Une seule actualisation en cascade s'exécute à la fois pour une table en aval donnée. Si les déclencheurs en amont arrivent trop fréquemment, les tours intermédiaires sont ignorés et l'intervalle d'actualisation effectif de la table en aval équivaut à la durée d'un tour d'actualisation propre ou à l'intervalle de déclenchement en amont, selon la valeur la plus élevée.

Limites relatives aux opérations DDL et DML