En pocas palabras
Formato de lago de datos que combina tablas analíticas y actualizaciones continuas por clave.
Qué problema resuelve
Ingesta de cambios y mantenimiento de estado mutable difíciles de gestionar en archivos analíticos.
Cuándo utilizarlo
Lakehouses con streaming y CDC. Ejemplo: mantener el estado actual de pedidos desde eventos.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
En el Radar compartido: Trial (valoración de la edición aportada).
Cómo funciona
Sus tablas de clave primaria utilizan una estructura LSM para fusionar versiones. Motores como Flink procesan inserciones, actualizaciones y eliminaciones mediante distintas políticas de merge.
Ejemplo de uso
Ingerir cambios de pedidos con pedido_id como clave y un campo de secuencia. Consultar el estado consolidado y verificar el resultado ante eventos duplicados o fuera de orden.
Tipos de tabla
| Tipo | Uso |
|---|---|
| Primary key table | Upserts y borrados por clave; estado actual de entidades (CDC) |
| Append table | Solo inserciones: logs, eventos; alternativa a una cola con consulta SQL |
Motores de fusión (merge engines)
| Motor | Comportamiento ante dos filas con la misma clave |
|---|---|
deduplicate |
Conserva la última (por defecto) |
partial-update |
Combina columnas no nulas: varias fuentes completan la misma fila |
aggregation |
Agrega por columna (sum, max, last_non_null_value…) |
first-row |
Conserva la primera y descarta las siguientes |
Con sequence.field se decide cuál es «la última» por una columna de negocio, no por el orden de llegada; así se resuelven eventos desordenados.
Ejemplo en Flink SQL
CREATE TABLE pedidos (
pedido_id BIGINT,
estado STRING,
importe DECIMAL(12, 2),
actualizado TIMESTAMP(3),
PRIMARY KEY (pedido_id) NOT ENFORCED
) WITH (
'merge-engine' = 'deduplicate',
'sequence.field' = 'actualizado',
'changelog-producer' = 'lookup',
'bucket' = '4'
);
-- Ingesta CDC desde MySQL con Flink CDC
INSERT INTO pedidos SELECT pedido_id, estado, importe, actualizado FROM mysql_pedidos;
-- Lectura en streaming de los cambios consolidados
SELECT * FROM pedidos /*+ OPTIONS('scan.mode' = 'latest') */;
Changelog producers
Para que consumidores en streaming reciban cambios correctos (antes y después de cada actualización), Paimon genera un changelog. input lo toma de la fuente CDC; lookup lo calcula al escribir consultando el valor anterior (más coste, baja latencia); full-compaction lo genera en las compactaciones completas (más barato, más latencia).
Paimon frente a otros formatos de tabla
| Formato | Fortaleza principal |
|---|---|
| Apache Iceberg | Estándar abierto amplio, analítica batch, muchos motores |
| Delta Lake | Integración con Databricks y Spark |
| Apache Hudi | Upserts e ingesta incremental en Spark |
| Paimon | Streaming con Flink, actualizaciones por clave de alta frecuencia |
Paimon puede generar metadatos compatibles con Iceberg, de modo que otros motores lean las tablas como Iceberg. Se consulta también desde Spark, Trino, StarRocks y Doris.
Criterios de implementación
Evaluar amplificación de escritura, archivos pequeños y latencia de visibilidad. Confirmar compatibilidad de los motores consumidores y las capacidades de cada modo de tabla.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.