Table Delta - MaxCompute - Centre de documentation Alibaba Cloud

Présentation

La table Delta est un format de table haute performance disponible sur Alibaba Cloud MaxCompute. Elle prend en charge des fonctionnalités telles que les transactions ACID (atomicité, cohérence, isolation et durabilité), les requêtes incrémentielles, le voyage dans le temps (Time Travel), le regroupement dynamique par buckets, les mises à jour de données en temps réel et l'évolution du schéma. Grâce aux capacités natives de data lakehouse et de calcul quasi temps réel de MaxCompute, vous pouvez utiliser le SQL standard pour créer, mettre à jour et interroger des tables Delta. Vous n'avez pas besoin de gérer le stockage sous-jacent ni les métadonnées complexes. MaxCompute assure automatiquement leur maintenance et leur optimisation, offrant ainsi un équilibre entre facilité d'utilisation et rentabilité.

Fonctionnalités

Catégorie	Fonctionnalité	Table Delta Append	Table Delta PK
Opérations DML de base	Insert, Update, Delete et Merge Into.	Prise en charge	Prise en charge
Transactions ACID	Read Committed / Snapshot Isolation. Pour plus d'informations, consultez Gestion des transactions ACID.	Prise en charge	Prise en charge
Clé primaire	Définit une clé primaire.	Non pris en charge	Prend en charge les mises à jour partielles des colonnes
Évolution du schéma	Ajout, suppression, renommage, réorganisation et modification du type de données des colonnes. Pour plus d'informations, consultez ALTER TABLE.	Prise en charge	Prise en charge
Importation de données	Prend en charge les écritures en flux continu pour l'importation incrémentielle de données à haute concurrence et évolutive, à l'aide d'outils tels que Écrire des données dans MaxCompute avec Flink, l'intégration de données DataWorks et DataHub. Prend en charge les écritures par lots incrémentielles et complètes.	Chargement en flux continu / par lots Les données sont visibles immédiatement après un chargement en flux continu.	Upsert
Voyage dans le temps (Time Travel)	Permet d'interroger des instantanés historiques par point dans le temps ou par numéro de version afin de reproduire des résultats ou d'effectuer des analyses d'audit. Pour plus d'informations, consultez Voyage dans le temps (Time Travel).	Prise en charge	Prise en charge
Calcul incrémentiel	Vue matérialisée Delta Live (MV) et lecture incrémentielle. Pour plus d'informations, consultez Calcul incrémentiel et Requêtes incrémentielles.	Prise en charge (La vue matérialisée incrémentielle est en cours d'adaptation.)	Prise en charge
Optimisation de l'organisation des données	Maintient automatiquement les fichiers de données incrémentielles, notamment via des optimisations telles que la fusion des petits fichiers, la COMPACTION multiniveaux et le tri des données, garantissant ainsi un état stable et efficace du stockage et du calcul des données. Pour plus d'informations, consultez Optimiser l'organisation des données pour les tables Delta Append et Optimisation de l'organisation des données pour les tables Delta PK.	Prise en charge Vous n'avez pas besoin de configurer le nombre de buckets. Le regroupement dynamique (Dynamic Bucketing) s'adapte automatiquement à la distribution des données.	Prise en charge
Optimisation des performances de requête	Statistiques au niveau des partitions et des fichiers (telles que Min/Max), élagage des partitions, élagage des colonnes et propagation des prédicats.	Prise en charge	Prise en charge
Sécurité et conformité	Chiffrement du stockage / Masquage dynamique des données / Contrôle d'accès au niveau des lignes.	Prise en charge	Prise en charge
Reprise après sinistre et sauvegarde	Instantanés de table / Sauvegarde et restauration / Reprise après sinistre inter-zones.	Prise en charge	Prise en charge
Coût	Compression en colonne AliORC et stockage hiérarchisé.	Prise en charge	Prise en charge

Expérience utilisateur

Mises à jour de données en temps réel pour les services en temps réel

Les tables Delta prennent en charge l'écriture et la mise à jour des données en temps réel (upserts) via Stream Upload. Les données deviennent visibles immédiatement après leur écriture. Pour équilibrer les performances d'écriture en temps réel avec les performances de requête, MaxCompute utilise une stratégie de stockage hiérarchisé et d'optimisation :

Garantir les écritures en temps réel : les nouvelles données sont d'abord écrites rapidement dans des buckets non clusterisés, sans être triées. Ce processus garantit une faible latence et un débit élevé pour les écritures de données.
Améliorer les performances des requêtes SQL : le service Incremental Reclustering en arrière-plan réorganise et optimise de manière asynchrone les données incrémentielles dans des buckets clusterisés et triés. Lors de l'exécution d'une requête, le moteur de requête peut élaguer efficacement les données de base triées et ne scanner qu'une petite quantité de données incrémentielles. Cette approche équilibre la fraîcheur des données avec l'efficacité des requêtes.

Traitement et analyse efficaces des données incrémentielles

S'appuyant sur ses capacités sous-jacentes de lecture et d'écriture incrémentielles des données, MaxCompute propose un ensemble riche de fonctionnalités de haut niveau pour améliorer la rapidité de l'analyse de données de bout en bout. Vous pouvez combiner des fonctionnalités avancées, telles que le calcul incrémentiel et la vue matérialisée Delta Live (Delta Live MV) (aperçu sur invitation), afin de construire des pipelines de traitement de données en temps réel efficaces et d'accélérer la transformation des données en informations métier.

S'adapter à la croissance de l'entreprise et dépasser les limites des formats de table précédents

Allocation dynamique des buckets : les tables Delta Append prennent en charge l'allocation dynamique des buckets. Vous n'avez pas besoin de spécifier le nombre de buckets dans l'instruction DDL (Data Definition Language). Vous n'avez pas non plus besoin d'estimer le volume futur de données de chaque partition pour déterminer un nombre approprié de buckets. À mesure que vous écrivez davantage de données, le service Dynamic Bucketing divise automatiquement les buckets existants ou en crée de nouveaux. Cette fonctionnalité s'adapte dynamiquement aux changements du volume de données métier et résout les problèmes, tels que le skew des données et la fragmentation, causés par des buckets trop grands ou trop petits.
Évolution du schéma : les tables Delta prennent en charge l'évolution du schéma pour répondre aux exigences métier changeantes concernant l'ajustement des champs de données et l'amélioration de la précision des données. Cette fonctionnalité permet d'ajouter, de supprimer, de modifier et de renommer des colonnes, offre une rétrocompatibilité totale et empêche la suppression ou la perte accidentelle de données.
Dépasser les limitations des tables traditionnelles : une seule table Delta prend en charge des opérations telles que INSERT INTO, UPDATE, DELETE et MERGE INTO, ainsi que le clustering et le stockage trié au sein d'une même table. Les tables partitionnées traditionnelles, les tables clusterisées et les tables de transaction ne peuvent pas prendre en charge toutes ces capacités simultanément.
Prend en charge le calcul multi-moteurs, y compris MaxCompute SQL, MaxFrame et Spark on MaxCompute. Les moteurs open source tels que Flink, Spark et StarRocks peuvent également accéder aux tables Delta via le connecteur Spark et les API de stockage ouvertes.

Équilibrer performance et fiabilité

Les tables Delta conviennent à la gestion de volumes de données massifs, allant de plusieurs téraoctets à plusieurs pétaoctets. Même avec des volumes de données extrêmement importants, les opérations sur les métadonnées restent rapides. Les requêtes prennent en charge des fonctionnalités telles que l'élagage des partitions, l'élagage des colonnes et la propagation des prédicats afin d'éviter les scans de données inutiles.
Gestion des transactions ACID : les tables Delta utilisent le contrôle de concurrence optimiste pour prendre en charge les opérations concurrentes de plusieurs rédacteurs. Les conflits d'écriture sont détectés et font l'objet de nouvelles tentatives afin de garantir la cohérence des données.
Sécurité et conformité : les tables Delta répondent aux exigences de sécurité et de conformité des données. Elles prennent en charge le chiffrement du stockage, les listes de contrôle d'accès (ACL) au niveau des tables et des colonnes, les autorisations au niveau des lignes et le masquage dynamique des données.
Sauvegarde et restauration : le mécanisme de sauvegarde et de restauration versionné, qui utilise un mode de corbeille, garantit qu'en cas de corruption des données ou de suppression accidentelle, vous pouvez rapidement restaurer la table à un état sain précédent. Cela réduit les risques liés aux opérations et à la maintenance (O&M) ainsi qu'à la gestion.

Opérations SQL

DDL

Créer une table Delta Append

-- Create an Append Delta Table
CREATE TABLE <table_name> (
  <col_name <data_type> [NOT NULL] [DEFAULT <default_value>] [comment <col_comment>], ...   
) 
[comment <table_comment>]
[RANGE CLUSTERED BY (<col_name> [, <col_name>, ...]) ]
TBLPROPERTIES (
  "table.format.version"="2" 
  ["acid.data.retain.hours"="hours"...]
)
[LIFECYCLE <days>];

Le tableau suivant décrit les paramètres TBLPROPERTIES.

Paramètre	Obligatoire	Description	Notes
"table.format.version"="2"	Oui	Déclare le format de table comme étant une table Delta.
acid.data.retain.hours	Non	La valeur par défaut est 24. La plage de valeurs est `[24, 168]`.	Plage de temps en heures pendant laquelle les états historiques des données peuvent être interrogés à l'aide du voyage dans le temps (Time Travel). Une valeur de 0 indique que les états historiques des données ne sont pas conservés et que les requêtes de voyage dans le temps ne sont pas prises en charge. Si un état historique des données existe depuis plus longtemps que la valeur de ce paramètre, il peut être supprimé ou compacté. Si une requête de voyage dans le temps spécifie une heure antérieure à la valeur de ce paramètre, une erreur est signalée. Par exemple, si ce paramètre est défini sur 72 heures, une erreur est signalée si vous tentez d'interroger un état historique des données datant de plus de 72 heures.
acid.incremental.query.out.of.time.range.enabled	Non	La valeur par défaut est `false`.	Si la valeur est définie sur true, le endTimestamp spécifié dans une requête incrémentielle peut être postérieur à la dernière heure de validation (commit) de la table. Si le endTimestamp est postérieur à l'heure actuelle, plusieurs requêtes peuvent renvoyer des résultats différents car de nouvelles données peuvent être insérées. Vous pouvez modifier la valeur de ce paramètre pour une table.

Créer une table Delta PK

-- Create a PK Delta Table
CREATE TABLE <table_name> (
  <col_name <data_type> [NOT NULL] [DEFAULT <default_value>] [comment <col_comment>], ...   
  PRIMARY KEY (<pk_col_name>[, <pk_col_name2>, ...] )
) 
[comment <table_comment>]
TBLPROPERTIES (
  "table.format.version"="2" 
  [, "write.bucket.num" = "N", "acid.data.retain.hours"="hours"...]
)
[LIFECYCLE <days>];

Les paramètres sont décrits ci-dessous :

PRIMARY KEY (PK) : obligatoire. Vous devez spécifier ce paramètre lors de la création d'une table Delta PK. La clé primaire peut contenir une ou plusieurs colonnes, et la combinaison des valeurs de ces colonnes doit être unique au sein de la table. La syntaxe suit la syntaxe standard SQL pour les clés primaires. Les colonnes de clé primaire doivent être définies sur NOT NULL et ne peuvent pas être modifiées.

Après avoir défini la clé primaire, les données de la table sont dédupliquées en fonction des colonnes de clé primaire. La contrainte d'unicité est effective au sein d'une seule partition ou pour l'ensemble d'une table non partitionnée.
Le tableau suivant décrit les paramètres TBLPROPERTIES.

Paramètre	Obligatoire	Description	Notes
"table.format.version"="2"	Oui	Déclare le format de table comme étant une table Delta.	Auparavant, les tables Delta PK étaient déclarées en définissant "transactional"="true" et en spécifiant une PRIMARY KEY. Désormais, vous pouvez les déclarer en définissant "table.format.version"="2" et en spécifiant une PRIMARY KEY.
write.bucket.num	Non	La valeur par défaut est 16. La plage de valeurs est `(0, 4096]`.	Nombre de buckets pour chaque partition ou pour une table non partitionnée. Cela indique également le nombre de nœuds concurrents pour les écritures de données. Vous pouvez modifier ce paramètre pour les tables partitionnées, et la modification prend effet par défaut pour les nouvelles partitions. Vous ne pouvez pas modifier ce paramètre pour les tables non partitionnées. Tenez compte des suggestions suivantes lors de l'utilisation de ce paramètre : Si vous importez des données à l'aide de Tunnel, ce paramètre spécifie le nombre de nœuds Tunnel concurrents. Le réglage affecte le trafic d'importation et est contraint par le nombre maximal de nœuds Tunnel concurrents. Si vous écrivez des données à l'aide de SQL, ce paramètre spécifie le degré de parallélisme des Reducers qui écrivent les données. Il est contraint par le nombre maximal de nœuds Reducer concurrents. Nous recommandons que la taille des données écrites dans chaque bucket soit d'environ 500 Mo. Par exemple, si la taille estimée de la partition est de 500 Go, le nombre de buckets doit être défini sur environ 1 000. Cela permet d'obtenir une taille moyenne d'environ 500 Mo par bucket. Pour les très grandes tables, la limite de 500 Mo peut être dépassée. Une taille de bucket d'environ 2 Go à 3 Go est plus appropriée.
acid.data.retain.hours	Non	La valeur par défaut est 24. La plage de valeurs est `[24, 168]`.	Plage de temps en heures pendant laquelle les états historiques des données peuvent être interrogés à l'aide du voyage dans le temps (Time Travel). Une valeur de 0 indique que les états historiques des données ne sont pas conservés et que les requêtes de voyage dans le temps ne sont pas prises en charge. Si un état historique des données existe depuis plus longtemps que la valeur de ce paramètre, il peut être supprimé ou compacté. Si une requête de voyage dans le temps spécifie une heure antérieure à la valeur de ce paramètre, une erreur est signalée. Par exemple, si ce paramètre est défini sur 72 heures, une erreur est signalée si vous tentez d'interroger un état historique des données datant de plus de 72 heures.
acid.incremental.query.out.of.time.range.enabled	Non	La valeur par défaut est `false`.	Si la valeur est définie sur true, le endTimestamp spécifié dans une requête incrémentielle peut être postérieur à la dernière heure de validation (commit) de la table. Si le endTimestamp est postérieur à l'heure actuelle, plusieurs requêtes peuvent renvoyer des résultats différents car de nouvelles données peuvent être insérées. Vous pouvez modifier la valeur de ce paramètre pour une table.
acid.write.precombine.field	Non	Vous pouvez spécifier le nom d'une colonne.	Si un nom de colonne est spécifié, le système déduplique les données en fonction des colonnes de clé primaire (PK) et de la colonne spécifiée lors du traitement des fichiers pour la même validation (commit). Cela garantit l'unicité et la cohérence des données. Remarque Si le volume de données d'une seule validation (commit) dépasse 128 Mo, plusieurs fichiers sont générés. Ce paramètre ne s'applique pas à plusieurs fichiers.
acid.partial.fields.update.enable	Non	Lorsque la valeur est définie sur `true`, vous pouvez utiliser SQL ou Tunnel pour effectuer des mises à jour partielles des colonnes sur une table Delta.	Définissez ce paramètre lors de la création de la table. Vous ne pouvez pas le modifier après la création de la table.

Remarques

Élément

Table Delta Append

Table Delta PK

Table clusterisée

Nombre de buckets

Vous n'avez pas besoin de spécifier write.bucket.num. Le nombre de buckets change dynamiquement en fonction du volume réel de données.

Vous devez spécifier le nombre de buckets dans l'instruction DDL. La valeur par défaut est 16.

/

Politique d'organisation des données

RANGE CLUSTERED BY. CLUSTERED BY n'est pas pris en charge. Vous n'avez pas besoin de spécifier un champ SORT BY. Les données au sein d'un bucket sont triées par défaut en fonction des champs spécifiés dans RANGE CLUSTERED BY.

Vous ne pouvez pas définir CLUSTERED BY. Par défaut, un cluster de hachage est créé en fonction de la clé primaire.

CLUSTERED BY

Cycle de vie

Doit être supérieur ou égal au cycle de vie des requêtes de voyage dans le temps (Time Travel). Autrement dit, lifecycle >= acid.data.retain.hours / 24. Cette condition est vérifiée lors de la création de la table. Une erreur est signalée si la condition n'est pas remplie.

/

Vous ne pouvez pas convertir directement une table standard existante en table Delta.
Les tables Delta PK ne prennent pas en charge l'évolution du schéma pour les colonnes de clé primaire (PK).
Les tables Delta PK ne prennent actuellement pas en charge le type de données JSON.
CREATE TABLE AS n'est pas pris en charge.

DML

Les tables Delta prennent en charge la syntaxe DML (Data Manipulation Language) telle que Insérer ou remplacer des données (INSERT INTO | INSERT OVERWRITE), UPDATE | DELETE et MERGE INTO.

DQL

Les tables Delta prennent en charge l'analyse de requêtes polyvalente. Pour plus d'informations, consultez Opérations DQL (SELECT).

Importation de données

Étant donné que les tables Delta Append ne possèdent pas de clé primaire, elles ne prennent pas en charge les opérations upsert ou delete lors de l'importation de données. Elles prennent en charge l'importation de données via les chargements de données par lots (Upload) et les chargements de données en flux continu (Stream Upload).
Les tables Delta PK prennent en charge l'écriture de données à l'aide de l'API Tunnel Upsert/Delete. Si une clé primaire n'existe pas, une opération upsert insère une nouvelle ligne. Si elle existe, l'opération upsert met à jour les champs autres que la clé primaire.

Optimisation de l'organisation des données

Une table Delta Append utilise une structure sous-jacente de clustering par plage (Range Clustering) pour l'organisation des données. Pour plus d'informations sur cette optimisation, consultez Optimiser l'organisation des données pour les tables Delta Append. Par défaut, Row_ID est utilisé comme clé de clustering, et le nombre de buckets est alloué dynamiquement à mesure que le volume de données augmente. Après avoir spécifié une clé de cluster, un travail de clustering en arrière-plan effectue un reclustering incrémentiel des données afin de maintenir leur ordre global.
Pour obtenir des informations sur la structure d'organisation des données d'une table Delta PK, consultez Optimisation de l'organisation des données pour les tables Delta PK. La table utilise une structure sous-jacente de clustering par hachage (Hash Clustering) pour permettre des écritures et des mises à jour efficaces des données en appliquant un hachage par buckets au champ de clé primaire (PK).