Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
Change types y versiones de commit
Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.
- Duración
- 17 min aprox.
- Objetivo
- Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Change Data Feed, CDC, AUTO CDC y SCD
Procesa inserciones, actualizaciones y borrados respetando clave, secuencia y retención.
- Consumir Change Data Feed
- Modelar CDC con AUTO CDC y reconocer APPLY CHANGES
- Elegir SCD tipo 1 o 2
02ImplementaciónChange types y versiones de commit
Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.
+
Change types y versiones de commit
Un feed CDC solo es determinista si define claves, una secuencia total por clave y semántica explícita para deletes y valores nulos.
La hora de llegada no es una secuencia fiable: un update antiguo puede llegar después de uno nuevo. `SEQUENCE BY` debe usar un LSN, número de versión u otra columna monotónica del origen. Si hay empates, un `struct` con campos de desempate produce un orden lexicográfico estable.
El pipeline también debe decidir si un `NULL` borra el valor o significa 'campo no enviado', y cómo identificar borrados. La clave no debe cambiar silenciosamente; una modificación de clave suele modelarse como delete de la antigua e insert de la nueva.
Modelo mental
Un feed CDC describe transiciones, no filas independientes. Para reconstruir una entidad se necesita una clave estable, una operación y una secuencia total por clave. El timestamp de llegada no suele bastar: dos actualizaciones pueden atravesar particiones o reintentos y aparecer fuera de orden. La secuencia debe provenir del log de origen —LSN, SCN, versión o una estructura compuesta— y resolver empates de forma determinista. Deletes deben representarse explícitamente, y los nulls requieren semántica: pueden significar establecer null o simplemente campo ausente en una actualización parcial. Antes de aplicar cambios se valida el contrato, se deduplican reenvíos y se conserva el raw feed. Una clave mutable se trata como delete más insert o mediante una identidad inmutable separada. Este modelo permite demostrar el estado final ante replay y es requisito conceptual tanto para un `MERGE` manual como para AUTO CDC.
Orden determinista que permite comparar cualquier par de cambios de la misma entidad, incluidos empates.
Hace que el estado reconstruido sea idéntico en ejecución normal, reintento y replay.Evento que representa la eliminación lógica de una clave sin depender de que la fila desaparezca físicamente del feed.
Permite propagar deletes y cerrar historia en vez de dejar entidades obsoletas downstream.Cambio que especifica solo algunos atributos y deja el resto sin modificar.
Obliga a distinguir null de campo ausente para no borrar datos accidentalmente al aplicar CDC.SELECT
customer_id,
operation,
sequence_number,
event_ts,
named_struct(
'sequence_number', sequence_number,
'event_ts', event_ts
) AS cdc_sequence
FROM STREAM(main.bronze.customer_cdc);El primer campo del struct debe representar el orden autoritativo del origen; el timestamp solo desempata si su calidad está garantizada.
Puntos clave
- La secuencia se evalúa por clave y debe resolver eventos fuera de orden.
- `APPLY AS DELETE WHEN` convierte una condición del feed en eliminación lógica del target.
- `IGNORE NULL UPDATES` solo es correcto cuando los nulos significan ausencia de cambio.
Evita
- Ordenar por `current_timestamp()` y permitir que el evento más tardío en llegar sobrescriba al más nuevo del origen.
- Activar `IGNORE NULL UPDATES` cuando un nulo representa realmente una eliminación de atributo.
Recuerdo activo