Une Delta Live Materialized View (Delta Live MV) permet de créer des pipelines de mise à jour incrémentielle simples. Cette rubrique explique comment utiliser les Delta Live MV dans MaxCompute.
Présentation
Contrairement aux vues matérialisées qui nécessitent une actualisation complète, une Delta Live MV équilibre la fraîcheur des données et le coût de calcul. Elle réutilise intelligemment les résultats de calcul existants et applique des algorithmes de calcul incrémentiel pour réduire les coûts tout en améliorant la fraîcheur des données.
Architecture

Principaux avantages
Les Delta Live MV de MaxCompute offrent les avantages suivants :
Structuration en couches de l'entrepôt de données grâce à des processus déclaratifs, entièrement gérés et automatisés.
Simplification de l'architecture de l'entrepôt de données : une seule logique de calcul et un seul moteur prennent en charge à la fois le calcul incrémentiel et complet, répondant ainsi aux exigences de faible latence et de haut débit.
Rentabilité : équilibre entre la fraîcheur des données et le coût de calcul, avec une gestion efficace du traitement incrémentiel et complet unifié.
Cas d'utilisation
La fonctionnalité Delta Live MV convient aux cas d'utilisation suivants :
-
Entrepôt de données quasi temps réel
Fait évoluer un entrepôt de données T+1 vers un entrepôt de données quasi temps réel avec une latence de l'ordre de la minute.
-
Traitement incrémentiel et complet unifié
Calcul incrémentiel quasi temps réel sur la partition du jour actuel pour garantir une grande fraîcheur des données et une meilleure rentabilité.
(Facultatif) Rétroalimentation des partitions historiques pour l'archivage des données, la correction et l'analyse de données à grande échelle.
-
Prise en charge complète du calcul incrémentiel avec diverses constructions SQL, y compris les opérateurs SQL courants suivants :
INNER JOIN à deux flux
LEFT/RIGHT OUTER JOIN à deux flux
Toutes les fonctions d'agrégation (à l'exception des UDAF), y compris celles sans GROUP BY ni AGG.
WINDOW
TableFunctionScan
UNION ALL
FILTER/Project
SUBQUERY
Prérequis
Vous disposez d'un projet MaxCompute.
-
La table source doit avoir la fonction Change Data Capture (CDC) activée. Les types de tables sources suivants sont pris en charge :
Une Delta Table avec la fonctionnalité CDC explicitement activée.
Une autre Delta Live MV. La fonction CDC est activée par défaut pour les Delta Live MV.
Une Delta Live MV ne peut pas contenir de calculs non déterministes, tels que la fonction RAND ou les UDF.
Créer une Delta Live MV
Syntaxe
CREATE MATERIALIZED VIEW [IF NOT EXISTS][<project_name>.]<mv_name>
[LIFECYCLE <days>] --Specify the lifecycle.
[BUILD DEFERRED] --Create only the table schema without populating data.
[(<col_name> [COMMENT <col_comment>],...)] --Column comment.
[DISABLE REWRITE] --Disables query rewrite for this view.
[COMMENT <table comment>] --Table comment.
[PARTITIONED ON/BY (<col_name> [, <col_name>, ...]) --Create the materialized view as a partitioned table.
[REFRESH EVERY <num> MINUTES/HOURS/DAYS] --Set the scheduled refresh interval for the materialized view.
TBLPROPERTIES(
"refresh_mode"="incremental"
[,"enable_auto_refresh"="true"] --Specify whether to enable auto-refresh.
[,"refresh_cron"="xx"] --Configure scheduled interval, point-in-time, or combined refreshes by using a cron expression.
[,"refresh_job_settings"="xx"]
)
AS <select_statement>;
La syntaxe d'une Delta Live MV est compatible avec celle d'une vue matérialisée standard, avec les différences suivantes :
Une Delta Live MV ne peut pas être créée en tant que table clusterisée.
Le paramètre
enable_auto_substitutene peut pas être défini sur true pour une Delta Live MV. Une Delta Live MV est une vue matérialisée asynchrone, ce qui signifie que les données de la table de base peuvent ne pas correspondre à la dernière version. Cela entre en conflit avec le comportement attendu lorsqueenable_auto_substituteest défini sur true.
Paramètres
Paramètre | Obligatoire | Description |
project_name | Non | Nom du projet. |
mv_name | Oui | Nom de la Delta Live MV. |
LIFECYCLE <days> | Non | Cycle de vie des données en jours. |
BUILD DEFERRED | Non | Crée le schéma de table sans générer de données. |
col_name | Non | Nom de la colonne. |
col_comment | Non | Commentaire de colonne. |
DISABLE REWRITE | Non | Désactive la réécriture de requête pour la vue. |
table comment | Non | Commentaire de table. |
REFRESH EVERY <num> MINUTES/HOURS/DAYS | Non | Spécifie l'intervalle d'actualisation planifiée. La valeur minimale est de 1 minute. |
enable_auto_refresh | Non | Indique si l'actualisation automatique est activée.
|
refresh_mode | Non | Mode d'actualisation.
|
refresh_cron | Non | Expression Cron QUARTZ pour définir la fréquence d'actualisation. Vous pouvez configurer des planifications d'actualisation basées sur un intervalle, à un moment précis ou une combinaison des deux. La valeur est une chaîne au format Cron QUARTZ. Pour plus d'informations, consultez les exemples d'expressions Cron. Voici un exemple : |
refresh_job_settings | Non |
|
select_statement | Oui | Instruction de requête SQL. |
Exemples
Exemple 1 : Créer une Delta Live MV simple
Définissez une Delta Live MV nommée mv1 qui effectue une actualisation incrémentielle automatique toutes les 5 minutes. La table source est une Delta Table avec la fonction CDC activée.
CREATE MATERIALIZED VIEW IF NOT EXISTS mv1
REFRESH EVERY 5 MINUTES
TBLPROPERTIES("enable_auto_refresh"="true", "refresh_mode"="incremental")
AS
SELECT name, COUNT(*) FROM source GROUP BY name;
Exemple 2 : Créer une vue avec des paramètres de réglage
SET odps.task.major.version=sql_flighting_dlmv;
CREATE MATERIALIZED VIEW IF NOT EXISTS part_dlmv_department
PRIMARY KEY(dept_id) -- The primary key can be inferred from the SQL logic. However, because partitioned MVs only support BUILD DEFERRED mode, which requires an explicitly declared primary key, you must declare it here.
LIFECYCLE 10
BUILD DEFERRED
PARTITIONED BY (pt)
TBLPROPERTIES('refresh_mode'='incremental',
'refresh_job_settings'='set odps.task.major.version=sql_flighting_dlmv;')
AS
SELECT *, get_setting('odps.custom.setting.department.pt') AS pt FROM t_department;
Exigences relatives à la clé primaire pour l'actualisation des MV :
Pour prendre en charge les actualisations, une Delta Live MV doit disposer d'une clé primaire (PK). La nécessité de déclarer explicitement une clé primaire dépend de la situation :
-
Lorsque la clé primaire peut être automatiquement déduite de la logique SQL
Par exemple, si le code SQL contient une clé GROUP BY, la clé primaire de la MV est automatiquement déduite en tant que clé, et vous n'avez pas besoin de la déclarer explicitement. Vous pouvez afficher la colonne de clé primaire déduite en exécutant la commande
DESC EXTENDED mvName;. -
Lorsque la clé primaire ne peut pas être automatiquement déduite de la logique SQL
Méthode 1 : Modifiez la logique SQL de la MV en ajoutant une clause GROUP BY pour satisfaire la condition de déduction automatique.
Méthode 2 : Déclarez explicitement la clé primaire. Les données elles-mêmes doivent respecter la contrainte d'unicité. Le système tente de vérifier l'unicité des données pour chaque actualisation incrémentielle. La vérification de l'unicité pour le chargement initial des données est en cours d'optimisation et sera disponible dans une prochaine version.
-
Exigences particulières pour les MV partitionnées
Une MV partitionnée prend actuellement en charge uniquement le mode BUILD DEFERRED, qui ne permet pas la déduction automatique de la clé primaire. Par conséquent, vous devez déclarer explicitement la clé primaire.
Delta Live MV partitionnée
Scénario 1 : Utilisez une Delta Live MV partitionnée pour représenter les données incrémentielles du jour actuel et les données complètes pour les enregistrements historiques.
SET odps.task.major.version=sql_flighting_dlmv;
CREATE MATERIALIZED VIEW IF NOT EXISTS part_dlmv_department
PRIMARY KEY(dept_id) -- The primary key can be inferred from the SQL logic. However, because partitioned MVs only support BUILD DEFERRED mode, which requires an explicitly declared primary key, you must declare it here.
LIFECYCLE 10
BUILD DEFERRED
PARTITIONED BY (pt)
TBLPROPERTIES('refresh_mode'='incremental',
'refresh_job_settings'='set odps.task.major.version=sql_flighting_dlmv;')
AS
-- t_department is a near-real-time ingestion table that mainly contains incremental data for the current day.
SELECT *, get_setting('odps.custom.setting.department.pt') AS pt FROM t_department;
UNION ALL
-- history_t_department is a historical partitioned table containing all historical data.
SELECT * FROM history_t_department;
Scénario 2 : Utilisez group by key pour déduire la colonne PK d'une dlmv.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
CREATE MATERIALIZED VIEW dlmv_pt
PRIMARY KEY(value) -- The primary key can be inferred from the SQL logic. However, because partitioned MVs only support BUILD DEFERRED mode, which requires an explicitly declared primary key, you must declare it here.
build deferred
partitioned BY (pt)
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS SELECT *, get_setting('odps.custom.setting.dlmv_pt.pt') AS pt FROM (SELECT value, MAX(value2) FROM dlmv_base_table GROUP BY value) t;
Scénario 3 : Déduisez la colonne de clé primaire de la Delta Live MV à partir de la clé primaire de la table de base.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
CREATE MATERIALIZED VIEW dlmv_pt
PRIMARY KEY(key) --The primary key can be inferred from the SQL logic. However, because partitioned MVs only support BUILD DEFERRED mode, which requires an explicitly declared primary key, you must declare it here.
build deferred
partitioned BY (pt)
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS
SELECT key, value, value2, get_setting('odps.custom.setting.dlmv_pt.pt') as pt FROM dlmv_base_table;
Scénario 4 : La colonne de clé primaire de la Delta Live MV ne peut pas être déduite.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
# 1. Explicitly declare the primary key column
CREATE MATERIALIZED VIEW dlmv_pt
primary key(value) -- The primary key column cannot be inferred as 'value' from the SQL logic, but the user knows the data itself satisfies the primary key uniqueness. The primary key must be explicitly declared.
build deferred
partitioned BY (pt)
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS
SELECT value, value2, get_setting('odps.custom.setting.dlmv_pt.pt') as pt FROM dlmv_base_table;
# 2. Modify the SQL logic to allow primary key inference.
-- If the uniqueness of the 'value' column cannot be guaranteed, the logic can be modified with a group by clause, as shown below:
CREATE MATERIALIZED VIEW dlmv_pt
primary key(value) -- The primary key can be inferred from the SQL logic. However, because partitioned MVs only support BUILD DEFERRED mode, which requires an explicitly declared primary key, you must declare it here.
build deferred
partitioned BY (pt)
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS SELECT value, MAX(value2), get_setting('odps.custom.setting.dlmv_pt.pt') as pt FROM dlmv_base_table GROUP BY value;
Delta Live MV non partitionnée
Scénario 1 : En utilisant group by key, vous pouvez déduire la colonne PK de la DLMV.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
CREATE MATERIALIZED VIEW dlmv
-- primary key(value) can be inferred from the SQL logic (group by value), so explicit declaration is not needed.
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS SELECT value, MAX(value2) FROM dlmv_base_table GROUP BY value;
Scénario 2 : Déduisez la colonne de clé primaire de la Delta Live MV à partir de la clé primaire de la table de base.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
CREATE MATERIALIZED VIEW dlmv
-- primary key(key) can be inferred from the SQL logic (derived from the base table's primary key), so explicit declaration is not needed.
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS
SELECT key, value, value2 FROM dlmv_base_table;
Scénario 3 : La colonne de clé primaire de la Delta Live MV ne peut pas être déduite.
// pk delta table
CREATE TABLE dlmv_base_table(
key STRING NOT NULL PRIMARY KEY,
value BIGINT,
value2 BIGINT
)
STORED AS ALIORC
TBLPROPERTIES (
'transactional' = 'true',
'cdc.insert.into.passthrough.enable' = 'true',
'acid.cdc.mode.enable' = 'true',
'acid.cdc.build.async' = 'false'
);
# 1. Explicitly declare the primary key column
CREATE MATERIALIZED VIEW dlmv
primary key(value) -- The primary key column cannot be inferred as 'value' from the SQL logic, but the user knows the data itself satisfies the primary key uniqueness. The primary key must be explicitly declared.
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS
SELECT value, value2 FROM dlmv_base_table;
# 2. Modify the SQL logic to allow primary key inference
-- If the uniqueness of the 'value' column cannot be guaranteed, the logic can be modified with a group by clause, as shown below:
CREATE MATERIALIZED VIEW dlmv
-- primary key(value) can be inferred from the SQL logic (group by value), so explicit declaration is not needed.
TBLPROPERTIES (
'refresh_mode' = 'incremental',
'enable_auto_refresh' = 'true'
)
AS SELECT value, MAX(value2) FROM dlmv_base_table GROUP BY value;
Exemple 3 : Actualiser une seule partition
Lorsque vous créez une Delta Live MV partitionnée, vous devez ajouter le mot-clé BUILD DEFERRED pour indiquer que seules les opérations DDL sont effectuées.
-- Create the Delta Live MV.
CREATE MATERIALIZED VIEW dlmv_pt
PRIMARY KEY(value) BUILD DEFERRED PARTITIONED BY (ds) TBLPROPERTIES
('refresh_mode'='incremental', 'enable_auto_refresh'='true')
AS SELECT value, AVG(value2), ds FROM dlmv_pt_src GROUP BY value, ds;
-- Refresh a single partition.
ALTER MATERIALIZED VIEW dlmv_pt REBUILD PARTITION(ds='20250730');
Pour plus d'informations sur l'actualisation d'une Delta Live MV, consultez la section Actualiser manuellement une Delta Live MV.
Exemple 4 : Utiliser des définitions paramétrées
L'utilisation de définitions paramétrées peut vous aider à migrer des jobs partitionnés hors ligne vers des jobs incrémentiels.
La fonction
get_settingest prise en charge pour obtenir les valeurs des paramètres définis dans l'indicateur de session. Les paramètres doivent être préfixés pardps.custom.setting.Remplacez
${biz_date}dans les jobs hors ligne traditionnels parget_setting(odps.custom.setting.xx)pour effectuer la paramétrisation.Ajoutez l'indicateur de session
set odps.custom.setting.xx=yyavant l'instruction d'actualisation de la Delta Live MV.Au moment de l'exécution, l'optimiseur MaxCompute remplace automatiquement
get_setting(odps.custom.setting.xx)dans une Delta Live MV paryy.
Exemple :
-- Create the Delta Live MV.
CREATE MATERIALIZED VIEW mv1
BUILD DEFERRED -- DDL only; no data is generated.
PARTITIONED BY (ds)
REFRESH EVERY 5 minutes
TBLPROPERTIES("enable_auto_refresh"="true", "refresh_mode"="incremental")
AS
SELECT A.* FROM A JOIN B ON A.c1 = B.c1
AND A.ds=get_setting('odps.custom.setting.bizdate.a')
AND B.ds=get_setting('odps.custom.setting.bizdate.b');
-- Refresh logic: DataWorks scheduling automatically replaces ${biz_date} and ${yesterday}.
SET odps.custom.setting.bizdate.a=${biz_date};
SET odps.custom.setting.bizdate.b=${yesterday};
ALTER MATERIALIZED VIEW mv1 REBUILD PARTITION(ds=${biz_date});
Gérer une Delta Live MV
Supprimer une Delta Live MV
DROP MATERIALIZED VIEW [IF EXISTS] [<project_name>.]<mv_name>;
Actualisation manuelle
Vous pouvez actualiser manuellement une Delta Live MV. Les actualisations manuelles ne prennent en charge que des partitions uniques.
ALTER MATERIALIZED VIEW [<project_name>.]<mv_name>
REBUILD [PARTITION(<ds>=max_pt(<table_name>),<expression1>...)];
Dans cette syntaxe, ds représente la colonne de partition.
Désactiver l'actualisation automatique
Pour désactiver la fonction d'actualisation automatique, exécutez la commande suivante :
ALTER MATERIALIZED VIEW <mv_name> SET TBLPROPERTIES("enable_auto_refresh"="false");
Reprendre l'actualisation automatique
Exécutez la commande suivante pour modifier les TBLPROPERTIES de la vue matérialisée afin d'activer ou de reprendre l'actualisation automatique.
ALTER MATERIALIZED VIEW <mv_name> SET TBLPROPERTIES("enable_auto_refresh"="true");
Modifier la fréquence d'actualisation
Exécutez la commande suivante pour modifier la fréquence d'actualisation d'une Delta Live MV.
ALTER MATERIALIZED VIEW <mv_name>
SET TBLPROPERTIES("refresh_interval_minutes"="xx");
La valeur minimale du paramètre refresh_interval_minutes est 1. Nous vous recommandons de définir cette valeur à un niveau inférieur au cycle de vie CDC de la table de base.
Consulter une Delta Live MV
Consulter l'historique des modifications de données
Exécutez la commande suivante pour consulter les enregistrements de modification des données d'une Delta Live MV.
SHOW HISTORY FOR TABLE <mv_name>;
Résultat exemple :
ObjectType ObjectId ObjectName VERSION(LSN) Time Operation
TABLE d95ec7015e8b432e8e0092d01da962a9 incremental_mv 0000000000000001 2024-08-18 21:06:32 CREATE
TABLE d95ec7015e8b432e8e0092d01da962a9 incremental_mv 0000000000000002 2024-08-18 21:11:13 UPDATE
Consulter l'historique des actualisations
Exécutez la commande suivante pour consulter l'historique des actualisations d'une Delta Live MV.
SELECT * FROM
Delta_Live_MV_Refresh_History(['<project_name>', '<schema_name>',]'<table_name>');
Paramètres
|
Paramètre |
Description |
|
project_name |
Nom du projet. |
|
schema_name |
Nom du schéma. |
|
table_name |
Nom de la table. |
Valeurs de retour
Champ | Description |
project_name | Projet contenant la Delta Live MV. |
schema_name | Schéma contenant la Delta Live MV. |
name | Nom de la Delta Live MV. |
refresh_start_time | Heure de début de l'actualisation. |
refresh_end_time | Heure de fin de l'actualisation. Si l' |
instance_id | ID du job. Vous pouvez utiliser cet ID pour ouvrir Logview. |
duration_in_seconds | Durée de l'actualisation. |
state | État du job.
|
refresh_trigger | Méthode d'actualisation.
|
refresh_mode | Mode d'actualisation.
|
error_message | Informations sur un échec d'actualisation. Si l'actualisation réussit, cette valeur est NULL. |
source_tables | Noms et versions des tables de base utilisées pour l'actualisation. |
numInsertedRows | Nombre de lignes insérées. |
numDeletedRows | Nombre de lignes supprimées. |
Facturation
Les Delta Live MV entraînent des frais de calcul et de stockage. La méthode de facturation est identique à celle des opérations de vue matérialisée standard.
-
Frais de calcul
Lorsque vous créez ou actualisez une Delta Live MV, si un job est lancé pour calculer les données, il consomme des ressources de calcul et engendre des frais de calcul. Les règles de facturation sont les mêmes que pour les jobs SQL standard.
Si une actualisation automatique est déclenchée mais qu'il n'y a aucune modification de données, MaxCompute ne lance pas de job d'actualisation et aucun frais ne vous est facturé.
Nous vous recommandons de placer les Delta Live MV dans un projet dédié pour suivre facilement les jobs d'actualisation automatique, l'utilisation des ressources de calcul et les coûts.
-
Frais de stockage
Les Delta Live MV sont facturées pour le stockage de la même manière que les vues matérialisées standard et les tables régulières.
Pour certains opérateurs, une Delta Live MV peut utiliser un algorithme de calcul incrémentiel basé sur l'état, qui génère des tables d'état internes et consomme du stockage supplémentaire.
Une Delta Live MV entraîne des frais de stockage pour CDC et Time Travel. Ces frais sont similaires à ceux d'une Delta Table standard.