Delta Table - MaxCompute - Centro de documentación de Alibaba Cloud

Una Delta Table es un formato de tabla de alto rendimiento en MaxCompute, diseñado para conjuntos de datos analíticos a gran escala. Incluye dos tipos: Append Delta Table, para tablas sin clave primaria, y PK Delta Table, para tablas con clave primaria. Este tema describe las funciones y operaciones básicas de las Delta Tables.

Descripción general

Una Delta Table es un formato de tabla de alto rendimiento en Alibaba Cloud MaxCompute. Admite funciones como transacciones ACID (atomicidad, consistencia, aislamiento y durabilidad), consultas incrementales, time travel, agrupación dinámica de buckets en clústeres, actualizaciones de datos en tiempo real y evolución del esquema. Las capacidades nativas de data lakehouse y de cómputo casi en tiempo real de MaxCompute le permiten usar SQL estándar para crear, actualizar y consultar Delta Tables. No necesita gestionar el almacenamiento subyacente ni los metadatos complejos. MaxCompute los mantiene y optimiza automáticamente para ofrecer un equilibrio entre facilidad de uso y rentabilidad.

Funciones

Categoría	Función	Append Delta Table	PK Delta Table
DML básico	Insert, Update, Delete y Merge Into.	Compatible	Compatible
Transacciones ACID	Read Committed/Snapshot Isolation. Para obtener más información, consulte ACID transaction management.	Compatible	Compatible
Clave primaria	Define una clave primaria.	No compatible	Admite actualizaciones parciales de columnas
Evolución del esquema	Agregue, elimine, cambie el nombre, reordene y modifique el tipo de datos de las columnas. Para obtener más información, consulte ALTER TABLE.	Compatible	Compatible
Importación de datos	Admite escrituras de streaming para importar datos incrementales de forma escalable y con alta concurrencia mediante herramientas como Write data to MaxCompute with Flink, la integración de datos de DataWorks y DataHub. Admite escrituras por lotes incrementales y completas.	Carga de streaming o por lotes Los datos son visibles inmediatamente después de una carga de streaming.	Upsert
Time travel	Permite consultar instantáneas históricas por punto en el tiempo o número de versión para reproducir resultados o ejecutar análisis de auditoría. Para obtener más información, consulte Time Travel.	Compatible	Compatible
Cómputo incremental	Delta Live Materialized View (MV) e Incremental Read. Para obtener más información, consulte Incremental computing y Incremental queries.	Compatible (La vista materializada incremental se encuentra en proceso de adaptación).	Compatible
Optimización de la organización de datos	Mantiene automáticamente los archivos de datos incrementales. Incluye optimizaciones como la fusión de archivos pequeños, COMPACTION multinivel y la ordenación de datos, lo que mantiene el almacenamiento y el cómputo en un estado estable y eficiente. Para obtener más información, consulte Optimize data organization for Append Delta Tables y Data organization optimization for PK Delta tables.	Compatible No necesita configurar el número de buckets. Dynamic Bucketing se adapta automáticamente a la distribución de los datos.	Compatible
Optimización del rendimiento de consultas	Estadísticas a nivel de partición y de archivo (como Min/Max), eliminación de particiones, eliminación de columnas y pushdown de predicados.	Compatible	Compatible
Seguridad y cumplimiento	Storage encryption / Dynamic data masking / Row-level access control.	Compatible	Compatible
Recuperación ante desastres y copia de seguridad	Table snapshots / Backup and restoration / Zone disaster recovery.	Compatible	Compatible
Costo	Compresión de almacenamiento en columnas AliORC y almacenamiento por niveles.	Compatible	Compatible

Experiencia del usuario

Actualizaciones de datos en tiempo real para servicios en tiempo real

Las Delta Tables admiten escrituras y actualizaciones de datos en tiempo real (upserts) mediante Stream Upload. Los datos se vuelven visibles inmediatamente después de escribirse. Para equilibrar el rendimiento en tiempo real de las escrituras con el rendimiento de las consultas, MaxCompute utiliza una estrategia de almacenamiento y optimización por niveles:

Garantizar escrituras en tiempo real: los datos nuevos se escriben primero rápidamente en buckets no agrupados, sin ordenarlos. Este proceso garantiza baja latencia y alto throughput para las escrituras de datos.
Mejorar el rendimiento de las consultas SQL: el servicio en segundo plano Incremental Reclustering reorganiza y optimiza de forma asíncrona los datos incrementales en buckets agrupados y ordenados. Al ejecutar una consulta, el motor de consultas elimina eficientemente los datos base ordenados y examina solo una pequeña cantidad de datos incrementales. Este enfoque equilibra la actualización de los datos con la eficiencia de las consultas.

Procesamiento y análisis eficiente de datos incrementales

Con base en sus capacidades subyacentes de lectura y escritura de datos incrementales, MaxCompute ofrece un amplio conjunto de funciones de alto nivel para mejorar la oportunidad de los análisis de datos de extremo a extremo. Puede combinar funciones avanzadas, como Incremental computing y Delta Live Materialized View (Delta Live MV) (Invitational Preview), para construir pipelines de procesamiento de datos en tiempo real eficientes y acelerar la transformación de los datos en información útil para el negocio.

Adaptación al crecimiento del negocio y superación de los límites de los formatos de tabla anteriores

Asignación dinámica de buckets: las Append Delta Tables admiten la asignación dinámica de buckets. No necesita especificar el número de buckets en la instrucción de lenguaje de definición de datos (DDL). Tampoco necesita estimar el volumen futuro de datos de cada partición para determinar un número adecuado de buckets. A medida que escribe más datos, el servicio Dynamic Bucketing divide automáticamente los buckets existentes o crea otros nuevos. Esta función se adapta dinámicamente a los cambios en el volumen de datos del negocio y resuelve problemas como la desviación y la fragmentación de datos, causados por buckets demasiado grandes o demasiado pequeños.
Evolución del esquema: las Delta Tables admiten la evolución del esquema para satisfacer los requisitos cambiantes del negocio en cuanto al ajuste de campos de datos y la mejora de la precisión de los datos. Esta función admite adding, deleting, modifying, and renaming columns, ofrece compatibilidad total con versiones anteriores y evita la eliminación o pérdida accidental de datos.
Superación de las limitaciones de las tablas tradicionales: una sola Delta Table admite operaciones como INSERT INTO, UPDATE, DELETE y MERGE INTO, además de agrupación y almacenamiento ordenado en una misma tabla. Las tablas particionadas tradicionales, las tablas agrupadas y las Transaction Tables no pueden admitir todas estas capacidades al mismo tiempo.
Admite cómputo multimotor, incluidos MaxCompute SQL, MaxFrame y Spark on MaxCompute. Los motores de código abierto como Flink, Spark y StarRocks también pueden acceder a las Delta Tables mediante Spark Connector y las API de almacenamiento abierto.

Equilibrio entre rendimiento y confiabilidad

Las Delta Tables son adecuadas para gestionar volúmenes masivos de datos, desde terabytes hasta petabytes. Incluso con volúmenes de datos extremadamente grandes, las operaciones de metadatos siguen siendo rápidas. Las consultas admiten funciones como la eliminación de particiones, la eliminación de columnas y el pushdown de predicados para evitar exámenes de datos innecesarios.
Gestión de transacciones ACID: las Delta Tables utilizan control de concurrencia optimista para admitir operaciones simultáneas de varios escritores. Los conflictos de escritura se detectan y se reintenta la operación para garantizar la consistencia de los datos.
Seguridad y cumplimiento: las Delta Tables cumplen con los requisitos de seguridad y cumplimiento de datos. Admiten cifrado de almacenamiento, listas de control de acceso (ACL) a nivel de tabla y de columna, permisos a nivel de fila y enmascaramiento dinámico de datos.
Copia de seguridad y reversión: el mecanismo de copia de seguridad y reversión con control de versiones, que utiliza un modo de papelera de reciclaje, garantiza que, si se produce corrupción o eliminación accidental de datos, pueda revertir rápidamente la tabla a un estado anterior saludable. Esto reduce los riesgos de operación y mantenimiento (O&M) y de gestión.

Operaciones SQL

DDL

Crear una Append Delta Table

-- 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>];

A continuación se describen los parámetros TBLPROPERTIES.

Parámetro	Obligatorio	Descripción	Notas
"table.format.version"="2"	Sí	Declara el formato de la tabla como Delta Table.
acid.data.retain.hours	No	El valor predeterminado es 24. El rango de valores es `[24, 168]`.	El rango de tiempo, en horas, durante el cual se pueden consultar los estados históricos de los datos mediante Time Travel. Un valor de 0 indica que los estados históricos de los datos no se conservan y que las consultas de Time Travel no son compatibles. Si un estado histórico de datos existe durante más tiempo que el valor de este parámetro, se puede eliminar o compactar. Si una consulta de Time Travel especifica una hora anterior al valor de este parámetro, se reporta un error. Por ejemplo, si este parámetro se establece en 72 horas, se reporta un error si intenta consultar un estado histórico de datos de hace más de 72 horas.
acid.incremental.query.out.of.time.range.enabled	No	El valor predeterminado es `false`.	Si se establece en true, el endTimestamp especificado en una consulta incremental puede ser posterior a la hora de confirmación más reciente de la tabla. Si el endTimestamp es posterior a la hora actual, varias consultas podrían devolver resultados distintos porque se pueden insertar datos nuevos. Puede modificar el valor de este parámetro para una tabla.

Crear una PK Delta Table

-- 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>];

A continuación se describen los parámetros:

PRIMARY KEY (PK): obligatorio. Debe especificar este parámetro cuando cree una PK Delta Table. La clave primaria puede contener una o más columnas, y la combinación de valores en estas columnas debe ser única dentro de la tabla. La sintaxis sigue la sintaxis estándar de clave primaria de SQL. Las columnas de clave primaria deben establecerse como NOT NULL y no se pueden modificar.

Después de establecer la clave primaria, los datos de la tabla se deduplican con base en las columnas de clave primaria. La restricción de unicidad es efectiva dentro de una sola partición o para una tabla completa no particionada.
A continuación se describen los parámetros TBLPROPERTIES.

Parámetro	Obligatorio	Descripción	Notas
"table.format.version"="2"	Sí	Declara el formato de la tabla como Delta Table.	Anteriormente, las PK Delta Tables se declaraban al establecer "transactional"="true" y especificar una PRIMARY KEY. Ahora puede declararlas al establecer "table.format.version"="2" y especificar una PRIMARY KEY.
write.bucket.num	No	El valor predeterminado es 16. El rango de valores es `(0, 4096]`.	El número de buckets para cada partición o para una tabla no particionada. También indica el número de nodos concurrentes para las escrituras de datos. Puede modificar este parámetro para tablas particionadas y, de manera predeterminada, el cambio surte efecto en las particiones nuevas. No puede modificar este parámetro para tablas no particionadas. Considere las siguientes sugerencias cuando utilice este parámetro: Si importa datos mediante Tunnel, este parámetro especifica el número de nodos de Tunnel concurrentes. La configuración afecta el tráfico de importación y está limitada por el número máximo de nodos de Tunnel concurrentes. Si escribe datos mediante SQL, este parámetro especifica el grado de paralelismo de los Reducers que escriben los datos. Está limitado por el número máximo de nodos Reducer concurrentes. Se recomienda que el tamaño de los datos escritos en cada bucket sea de aproximadamente 500 MB. Por ejemplo, si el tamaño estimado de la partición es de 500 GB, el número de buckets debe establecerse en aproximadamente 1,000. De esta forma, el tamaño promedio de cada bucket será de unos 500 MB. Para tablas muy grandes, se puede superar el límite de 500 MB. Un tamaño de bucket de entre 2 GB y 3 GB resulta más apropiado.
acid.data.retain.hours	No	El valor predeterminado es 24. El rango de valores es `[24, 168]`.	El rango de tiempo, en horas, durante el cual se pueden consultar los estados históricos de los datos mediante Time Travel. Un valor de 0 indica que los estados históricos de los datos no se conservan y que las consultas de Time Travel no son compatibles. Si un estado histórico de datos existe durante más tiempo que el valor de este parámetro, se puede eliminar o compactar. Si una consulta de Time Travel especifica una hora anterior al valor de este parámetro, se reporta un error. Por ejemplo, si este parámetro se establece en 72 horas, se reporta un error si intenta consultar un estado histórico de datos de hace más de 72 horas.
acid.incremental.query.out.of.time.range.enabled	No	El valor predeterminado es `false`.	Si se establece en true, el endTimestamp especificado en una consulta incremental puede ser posterior a la hora de confirmación más reciente de la tabla. Si el endTimestamp es posterior a la hora actual, varias consultas podrían devolver resultados distintos porque se pueden insertar datos nuevos. Puede modificar el valor de este parámetro para una tabla.
acid.write.precombine.field	No	Puede especificar el nombre de una columna.	Si se especifica un nombre de columna, el sistema deduplica los datos con base en las columnas de clave primaria (PK) y en la columna especificada durante el procesamiento de archivos para la misma confirmación. Esto garantiza la unicidad y consistencia de los datos. Nota Si el volumen de datos de una sola confirmación supera los 128 MB, se generan varios archivos. Este parámetro no aplica a varios archivos.
acid.partial.fields.update.enable	No	Cuando se establece en `true`, puede usar SQL o Tunnel para ejecutar partial column updates en una Delta Table.	Establezca este parámetro cuando cree la tabla. No puede modificarlo después de crear la tabla.

Notas

Elemento	Append Delta Table	PK Delta Table	Tabla agrupada
Número de buckets	No necesita especificar write.bucket.num. El número de buckets cambia dinámicamente según el volumen real de datos.	Debe especificar el número de buckets en la instrucción DDL. El valor predeterminado es 16.	/
Directiva de organización de datos	RANGE CLUSTERED BY. No es compatible con CLUSTERED BY. No necesita especificar un campo SORT BY. Los datos dentro de un bucket se ordenan de manera predeterminada según los campos especificados en RANGE CLUSTERED BY.	No puede establecer CLUSTERED BY. De manera predeterminada, se crea un clúster hash con base en la clave primaria.	CLUSTERED BY
Ciclo de vida	Debe ser mayor o igual que el ciclo de vida de las consultas de Time Travel. Es decir, `lifecycle >= acid.data.retain.hours / 24`. Esto se comprueba cuando se crea la tabla. Se reporta un error si no se cumple la condición.	/	/

No puede convertir directamente una tabla estándar existente en una Delta Table.
Las PK Delta Tables no admiten la evolución del esquema para las columnas de clave primaria (PK).
Actualmente, las PK Delta Tables no admiten el tipo de datos JSON.
No es compatible con CREATE TABLE AS.

DML

Las Delta Tables admiten sintaxis de lenguaje de manipulación de datos (DML) como Insert or overwrite data (INSERT INTO | INSERT OVERWRITE), UPDATE | DELETE y MERGE INTO.

DQL

Las Delta Tables admiten análisis de consultas de propósito general. Para obtener más información, consulte DQL operations (SELECT).

Importación de datos

Dado que las Append Delta Tables no tienen clave primaria, no admiten operaciones upsert ni delete durante la importación de datos. Admiten la importación de datos mediante cargas de datos por lotes (Upload) y cargas de datos de streaming (Stream Upload).
Las PK Delta Tables admiten la escritura de datos mediante la API Tunnel Upsert/Delete. Si una clave primaria no existe, una operación upsert inserta una fila nueva. Si existe, la operación upsert actualiza los campos que no forman parte de la clave primaria.

Optimización de la organización de datos

Una Append Delta Table utiliza una estructura subyacente de Range Clustering para organizar los datos. Para obtener más información sobre esta optimización, consulte Optimize data organization for Append Delta Tables. De manera predeterminada, se usa Row_ID como clave de agrupación y el número de buckets se asigna dinámicamente a medida que crece el volumen de datos. Después de especificar una Cluster Key, un trabajo de agrupación en segundo plano ejecuta una reagrupación incremental de los datos para mantener su orden general.
Para obtener información sobre la estructura de organización de datos de una PK Delta Table, consulte Data organization optimization for PK Delta tables. La tabla utiliza una estructura subyacente de Hash Clustering para habilitar escrituras y actualizaciones de datos eficientes mediante la agrupación por hash del campo de clave primaria (PK).