Calidad de datos y observabilidad: DQDL, cuarentena, linaje y SLOs

Las lecciones 01 to 14 construyeron algo que funciona: un prefijo bronze, tablas Iceberg, jobs de Glue, un catálogo, Athena y QuickSight, orquestación, concesiones de Lake Formation, controles de PII y un perímetro endurecido. Nada de eso responde a la pregunta que tus consumidores realmente harán: ¿puedes demostrar que las cifras de oro de hoy son correctas, y puedes decirme qué cambió cuando no lo son? Un lakehouse sin calidad y sin observabilidad es una forma muy rápida de mover datos incorrectos.

Esta lección construye la capa de prueba en el orden en que la propia guía de AWS la dispone: motores → reglas → runtimes → resultados y señales → cuarentena → SLOs → observabilidad por capa → auditoría → linaje → remediación. Dos ideas sostienen todo. Primero, la calidad es un paso del pipeline con una salida, no un cuadro de mando: o bien bloquea una escritura, o divide filas, o levanta una señal por la que alguien recibe un aviso. Segundo, la observabilidad tiene tres planos distintos que los equipos confunden sin parar: el catálogo de Glue guarda los metadatos técnicos y los permisos, DataZone guarda el significado de negocio y el linaje, CloudTrail guarda quién llamó a qué. Cada número de abajo está datado en octubre de 2026.

En esta lección vas a:

• elegir un motor de calidad a partir del propio mapa de Prescriptive Guidance de AWS, Glue Data Quality, DataBrew, Deequ o código a medida, y defender la opción por defecto;
• redactar DQDL: rulesets atados a una tabla, los cuatro modificadores (expresiones, where, reglas dinámicas, etiquetas), los 32 tipos de regla y cuáles de ellos pueden producir alguna vez una fila fallida;
• ejecutar la evaluación en ambos runtimes, la tarea del Data Catalog y EvaluateDataQuality dentro de un job de Glue, y saber exactamente qué puede y qué no puede hacer cada uno;
• aterrizar los resultados en tres destinos: JSON en S3, el almacén del servicio de Glue y tablas Iceberg en el Data Catalog, y luego leerlos en Athena;
• cablear las señales: eventos de EventBridge, métricas de CloudWatch en el espacio de nombres Glue Data Quality, alarmas, cuadros de mando: incluida la casilla que mata las alertas en silencio;
• construir el patrón de cuarentena de extremo a extremo: dividir filas, escribir el prefijo y la tabla de cuarentena, emitir la métrica, alertar y ejecutar un backfill que se mantiene idempotente;
• calcular un SLO de frescura en tres relojes y defender una cifra P95 con aritmética real;
• acotar los eventos de datos de CloudTrail por prefijo sensible para que la traza de auditoría no se convierta en la línea más grande de la factura;
• separar los tres planos, catálogo de Glue, catálogo de negocio y linaje de DataZone, auditoría de CloudTrail, y nombrar solo las fuentes de linaje que AWS realmente documenta;
• cablear una ruta de remediación EventBridge → SNS → Lambda que funcione con el IAM que le corresponde;
• estudiar dos casos de clientes de AWS, un recuadro de actualizaciones de octubre de 2026 con fuentes, once preguntas de estilo examen y cuatro comprobaciones interactivas.

---

1. Cuatro motores de calidad, una decisión

1.1 El propio mapa de AWS

AWS Prescriptive Guidance publica una tabla de mapeo de soluciones para los chequeos de calidad de datos. Es la respuesta correcta más rápida a «qué herramienta»:

(AWS Prescriptive Guidance: Data quality checks, consultado 2026-10-11.)

Para el lakehouse de este curso la respuesta es Glue Data Quality por defecto, DataBrew reservado para el perfilado de analistas de negocio sobre datasets CSV/JSON, y PyDeequ solo cuando la personalización al nivel de Deequ sea genuinamente necesaria. No es una contienda de popularidad: Glue DQ evalúa «tablas y vistas de Amazon Athena admitidas que están almacenadas en el AWS Glue Data Catalog» sobre «Amazon S3, Amazon Redshift, fuentes JDBC compatibles con el Data Catalog y formatos de lago de datos transaccionales como Apache Iceberg, Apache Hudi y Delta Lake»: que es exactamente el sustrato que construiste en las Lecciones 02 to 08 (Glue Developer Guide, consultado 2026-10-11).

• 📚 ¿Sabías que…? Glue Data Quality no es una reimplementación: AWS afirma que está «construido sobre el framework de código abierto DeeQu» y que hay «sin ataduras (No lock-in)… permitiéndote conservar las reglas que redactas en un lenguaje abierto» (Glue Developer Guide, consultado 2026-10-11). Por eso una regla DQDL se lee como el vocabulario de restricciones de Deequ, y por eso la librería de código abierto sigue siendo una válvula de escape legítima para los analyzers que el producto no expone.

1.2 Qué compra lo «gestionado», en una tabla

La última fila importa. Great Expectations aparece en esta lección solo como un framework que tú traes: AWS no publica ninguna oferta gestionada de GX, la documentación legada de GX propia fija la integración con Glue en «la versión más reciente de GX que soporta esta integración es GX 0.15.50», y el recorrido del conector de Glue Catalog es un post escrito por un partner. Trata GX como tu runner para versionar, parchear y soportar.

---

2. DQDL: el lenguaje, los modificadores, el contrato del ruleset

2.1 El contrato: Rules = [ ... ] atado a una tabla

Un ruleset es una lista entre corchetes, separada por comas, atada a exactamente una tabla del catálogo:

Esa es la forma de create_data_quality_ruleset (Glue Developer Guide: Using APIs to measure and manage data quality, consultado 2026-10-11). Dos límites definen lo grande que puede volverse un ruleset: 2,000 reglas por ruleset («si tus rulesets son mayores, te recomendamos dividirlos en varios rulesets») y un tamaño de ruleset de 65 KB. Las estadísticas son un presupuesto aparte: 100,000 estadísticas por cuenta, almacenadas gratis durante 2 años (precios de Glue, consultado 2026-10-11).

Una exclusión a nivel de lenguaje para memorizar: «DQDL no admite actualmente datos de columna anidados ni de tipo lista». Los structs y arrays anidados quedan fuera del alcance de las reglas directas: aplana, o usa CustomSql contra una vista preprocesada.

2.2 Los cuatro modificadores que cambian la semántica

(Notas de versión de Glue DQ y AWS What's New, 2025-11-25, consultado 2026-10-11.)

Tres rasgos de apoyo lo completan: las constantes (2025-11-21) te dejan definir un valor una vez y referenciarlo por todo el script, «preventing issues related to query size limits»; las consultas de preprocesado (GA 2025-11-25) ejecutan SparkSQL sobre la tabla antes de la evaluación mediante el campo PreProcessingQuery de DataQualityGlueTable, de modo que puedes derivar columnas, filtrar o validar relaciones entre columnas; y las reglas compuestas complejas (2024-11-22) te dejan anidar grupos AND/OR en lugar de apilar reglas planas.

Fíjate en la trampa de la columna with threshold: esa cláusula solo funciona con ColumnValues, ColumnDataType y CustomSql. Ponla sobre Completeness y estarás escribiendo una regla que DQDL no evaluará como tú crees.

2.3 Los 32 tipos de regla, y los que pueden nombrar una fila

La referencia de tipos de regla de DQDL lista exactamente 32 tipos de regla en octubre de 2026: AggregateMatch, AllStatistics, ColumnCorrelation, ColumnCount, ColumnDataType, ColumnExists, ColumnLength, ColumnNamesMatchPattern, ColumnValues, Completeness, CustomSql, DataFreshness, DatasetMatch, DistinctValuesCount, Distribution, Entropy, IsComplete, IsPrimaryKey, IsUnique, Mean, ReferentialIntegrity, RowCount, RowCountMatch, SchemaMatch, StandardDeviation, Sum, Uniqueness, UniqueValueRatio, DetectAnomalies, FileFreshness, FileMatch, FileUniqueness y FileSize.

Se agrupan en cuatro familias:

La propia documentación de Studio de AWS es tajante sobre la separación: las reglas a nivel de dataset «no pueden identificar registros de error porque se aplican a nivel de dataset» (Glue Developer Guide: Evaluating data quality with AWS Glue Studio, consultado 2026-10-11). Construye una cuarentena sobre RowCount y no pondrás en cuarentena absolutamente nada.

2.4 Ejemplo resuelto E1: el ruleset orders de silver

Objetivo: lakehouse_silver.orders, una tabla Iceberg particionada por dt, evaluada dentro del job bronze→silver y re-verificada cada día como tarea del catálogo.

Por qué cada línea se gana su sitio: IsPrimaryKey colapsa dos reglas en una; las formas con umbral sobre ColumnValues toleran suciedad por debajo del 1% sin hundir una ejecución entera; RowCount <= avg(last(10)) * 1.5 es una guarda de picos dinámica que no necesita una constante ajustada a mano; el CustomSql a nivel de fila es la única regla de aquí que puede darte una lista de IDs de pedido para poner en cuarentena; y DataFreshness … where "dt = current_date - 1" acota la obsolescencia a la partición que debería estar fresca en lugar de gritar sobre toda la historia.

El recorrido de introducción de AWS muestra la misma forma sobre su tabla de ejemplo de tickets, IsComplete "SET_FINE_AMOUNT", Uniqueness "TICKET_NUMBER" > 0.95, ColumnValues "PROVINCE" in [...], ColumnLength "INFRACTION_DESCRIPTION" between 15 and 31, con la advertencia importante de la documentación: las recomendaciones «facilitan empezar… sin escribir código», pero las reglas se generan a partir de las estadísticas actuales, así que trátalas como un borrador que apretar (consultado 2026-10-11).

2.5 Recomendaciones de reglas: BASIC y ADVANCED vía Bedrock

start_data_quality_rule_recommendation_run(DataSource={'GlueTable': {...}}, Role=role_arn) devuelve un RunId; recupera ResultIds de get_data_quality_ruleset_evaluation_run y después cada get_data_quality_result(ResultId=…). Las carreras de recomendación se borran automáticamente a los 90 días. Desde el 2026-09-18 / 2026-09-25, un modo ADVANCED usa Amazon Bedrock con los metadatos de la tabla más filas muestreadas para generar DQDL: un asistente de redacción, no una aprobación.

---

3. Dos runtimes: la tarea del Data Catalog y EvaluateDataQuality en el job

Comparten DQDL, EventBridge, métricas de CloudWatch, resultados en S3 y acciones de IAM. No son intercambiables.

(Glue Developer Guide: matriz de capacidades, consultado 2026-10-11.)

3.1 Dentro del job

La opción de salida de la transformación es la decisión que importa: «Original data» frente a «Add new columns to indicate data quality errors». La segunda añade cuatro columnas: DataQualityRulesPass, DataQualityRulesFail, DataQualityRulesSkip (arrays de cadena) y DataQualityEvaluationResult («Passed» o «Failed» a nivel de fila). La nota de AWS que hay que memorizar es esta: "tus resultados globales pueden ser FAIL, pero un registro en concreto puede pasar." Las reglas en Studio van «dentro de los corchetes y… separadas por comas»: Rules = [ Completeness "year" > 0.8, Completeness "month" > 0.8 ].

La calidad incremental llega por los bookmarks de job: para entradas de S3 la marca de agua es la hora de última modificación del objeto, con un maxBand por defecto de 900,000 ms (15 minutos) durante el cual el listado «is likely to be consistent». Los bookmarks exigen job.init al principio y job.commit al final, y se enganchan a un transformation_ctx único: si lo omites, el operador no se rastrea en absoluto (que es exactamente como relees a propósito una tabla de dimensión en cada ejecución).

3.2 Tres destinos de resultados, y desde julio de 2026 el catálogo es uno de ellos

1. Resultados JSON en S3 (opt-in mediante resultsS3Prefix o la ubicación de resultados de la tarea) → regístralos con un crawler, CREATE EXTERNAL TABLE con un JSON SerDe, MSCK REPAIR TABLE y después Athena. AWS entrega el DDL completo, particionado por year/month/day.
2. El almacén del servicio de Glue → legible mediante GetDataQualityResult / ListDataQualityResults y representado en la pestaña Data quality de la consola; la Data quality snapshot muestra por defecto las últimas 10 ejecuciones de cada ruleset.
3. Tablas Iceberg en el Data Catalog (GA 2026-07-27) → cuatro tipos de resultado opt-in, resultados de regla, de perfilado, a nivel de fila y de observación, configurados mediante --additional-run-options en StartDataQualityRulesetEvaluationRun o additional_options en un job ETL. No se escribe nada por defecto: «debes activar explícitamente cada tipo de resultado.»

Este es el cambio más grande de 2026 sobre el tema de esta lección: tu historial de calidad se convierte en una tabla Iceberg ordinaria, con las mismas herramientas de Athena, Lake Formation, time travel y QuickSight que el resto del lakehouse.

3.3 El contrato de alertas tiene una casilla oculta

Cada evaluación completada emite un evento de EventBridge:

La variante ETL usa contextType: "GLUE_JOB" con jobId, jobName y evaluationContext. La ruta paralela de CloudWatch es igual de simple: «Each AWS Glue Data Quality evaluation emits a pair of metrics named glue.data.quality.rules.passed… and glue.data.quality.rules.failed» bajo el espacio de nombres Glue Data Quality, publicadas por tabla y por ruleset.

La preferencia declarada de AWS: "nuestro enfoque recomendado es configurar las alertas de calidad de datos con Amazon EventBridge, porque Amazon EventBridge solo requiere una configuración única para alertar a los clientes." La alternativa de CloudWatch es una alarma estándar: glue.data.quality.rules.failed, estadística Sum, periodo 1 minuto, umbral ≥ 1, acción = tema de SNS.

• 📚 ¿Sabías que…? El score no es una nota de calidad que se pasa de mano en mano: AWS lo define como «el porcentaje de reglas de calidad de datos que superaron la entrada». Un ruleset con una sola regla débil puntúa 1.0 mientras el 40% de las filas son basura. Por eso existen las columnas a nivel de fila y las tablas de resultados: el score para la alerta, las filas para la arreglo (Glue Developer Guide, consultado 2026-10-11).

---

4. Deequ, PyDeequ y DataBrew: las rutas laterales verificadas

4.1 Deequ: el motor, y dónde sigue mereciendo la pena

El anuncio de PyDeequ de AWS describe el original: Deequ «is used internally at Amazon to verify the quality of many large production datasets… The system computes data quality metrics on a regular basis (with every new version of a dataset), verifies constraints defined by dataset producers, and publishes datasets to consumers in case of success. In error cases, dataset publication can be stopped, and producers are notified to take action.» Calcular → verificar → publicar-o-parar es el bucle que Glue DQ convirtió en producto en 2023 (AWS Big Data Blog, 2020-12-30, actualizado en junio de 2024).

Motivos legítimos que quedan para ejecutar Deequ tú mismo, según los propios posts de AWS:

PyDeequ «supports Spark up to version 3.3.0» según las notas de PyDeequ 1.1.x a las que AWS enlaza, y «puede funcionar dentro de Amazon EMR y SageMaker». El resumen honesto de 2026: casi todo el valor de Deequ ya está dentro de Glue Data Quality; recurre a la librería cuando el runtime sea exótico o la restricción no sea expresable.

4.2 DataBrew: reglas, pero no DQDL

La historia de calidad de DataBrew es un ruleset de CheckExpressions evaluado dentro de un job de perfilado: «si algún criterio de una regla no se cumple, el ruleset entero falla la validación», y la ejecución «produce un informe de validación además del perfil de datos» en la misma ubicación. Forma de la API: CheckExpression, ColumnSelectors (Name o Regex), Disabled, SubstitutionMap, Threshold (Type/Unit/Value). Restricciones que respetar: solo participan columnas de tipos simples (string, números, boolean), y las reglas viven en la pestaña Recommendations de la pantalla del ruleset.

Al terminar, «DataBrew envía un evento de Amazon CloudWatch con los detalles de esa ejecución de job… para cada ruleset validado… y el evento contiene su resultado (SUCCEEDED, FAILED o ERROR)» más un enlace al informe. Ese evento es tu patrón de EventBridge para los chequeos en manos de analistas. Las métricas viven en el espacio de nombres AWS/DataBrew: el ejemplo documentado es SessionCount.

4.3 Ejemplo resuelto E2: lo que cuesta un gate de calidad, y dónde ponerlo

El propio benchmark de AWS: 104 columnas, 1 millón de filas, 10 DPUs (AWS Big Data Blog, 2024-03-12):

Dos conclusiones sobreviven a la ambigüedad de precio: presupuesta por tamaño de tabla × frecuencia, no por número de reglas, y para un diseño de cuarentena la evaluación dentro del job domina porque es más barata y es la única vía que puede nombrar las filas.

---

5. Cuarentena: un patrón, no un producto

5.1 Tres acciones, dos puntos de control

La muestra InsuranceLake de la AWS Solutions Library formaliza lo que todo pipeline de producción necesita: tres acciones en dos puntos de control del pipeline:

Puntos de control: before_transform («justo después del mapeo de esquema… antes de que se ejecute cualquier transformación») y after_transform («justo antes de guardar los datos en el bucket Cleanse»). La regla que importa para tu diseño de ruleset: "La expresión de calidad de datos debe escribirse usando resultados a nivel de fila para evaluar y poner en cuarentena filas individuales" y "Las reglas que se apoyan en ratios o umbrales no están soportadas como reglas de cuarentena."

InsuranceLake muestra también cómo es un halt por frescura cuando quieres que el pipeline se detenga en lugar de dividir:

5.2 La división, en código

La guía de Studio de AWS ofrece además una variante propia: en Data quality actions, elige Fail job after loading target data, que aparece como AssertionError: The job failed due to failing DQ rules for node: …: halt sin cuarentena.

5.3 Ejemplo resuelto E3: el bucle de cuarentena con cifras reales

Las dos últimas líneas son el punto: una cuarentena sin una ruta de backfill es solo pérdida de datos con pasos de más. Y como los resultados son ahora tablas Iceberg, la pregunta «cómo estaba gold antes de la partición mala» se resuelve con time travel en lugar de con una restauración.

5.4 Write-Audit-Publish: la forma nativa de Iceberg

El patrón WAP de AWS sustituye la copia física de cuarentena por ramas: escribe todo en una rama stg → ejecuta Glue DQ sobre ella → filtra las filas superadas a una rama audit → fast_forward a main con el procedimiento fast_forward de Spark. El set de reglas de demo del blog verificaba la temperatura del sensor «between −10 and 50 °C», y nombra el compromiso con honestidad: "El principal reto del patrón WAP es la latencia adicional que introduce." El enfoque de cola de mensajes muertos (el prefijo de cuarentena en S3) es la otra opción documentada: elige según si puedes permitirte la latencia o el almacenamiento duplicado.

• 📚 ¿Sabías que…? Los bookmarks rastrean orígenes, no destinos. La documentación de AWS afirma sin rodeos que «cuando rebobinas o reinicias un bookmark, AWS Glue no limpia los ficheros de destino porque puede haber varios destinos y los destinos no se rastrean con los bookmarks de job.» Por eso el paso de backfill de arriba escribe a un prefijo nuevo o hace MERGE: reintentar en la misma ruta anexa duplicados que tu regla IsPrimaryKey se encargará de poner en cuarentena con toda corrección en la siguiente ejecución (Glue Developer Guide: job bookmarks, consultado 2026-10-11).

---

6. SLOs de frescura: tres relojes y la aritmética

6.1 Separa los relojes antes de fijar un objetivo

SLO de frescura = P95(disponibilidad − evento) ≤ objetivo. El pipeline aporta dos tramos: aterrizaje − evento (retraso de ingesta) y disponibilidad − aterrizaje (retraso de procesamiento + DQ + backfill). DQDL te da dos codificaciones: DataFreshness contra una columna de timestamp de la tabla («Checks if data is fresh», métrica Column.[Column].DataFreshness.Compliance, resultados a nivel de fila: sí) y FileFreshness contra los timestamps de los ficheros de S3 (ruta de fichero/carpeta + umbral, a nivel de fila: no).

6.2 Ejemplo resuelto E4: un SLO de 3 horas, aritmética P95

Suma los P95 de los componentes en lugar de promediar las medias: el P95 de una suma está acotado por la suma de los P95, así que 162 minutos es la cifra defendible para poner delante de un stakeholder, y los 18 minutos de holgura te dicen qué palanca tirar antes de romper el objetivo. La escalera de fallos es deliberadamente redundante: una regla de frescura atrapa datos obsoletos, una alarma de RowCount en cero atrapa un pipeline muerto, y un evento de job FAILED atrapa el crash: tres problemas distintos que todos se parecen a «el cuadro de mando está viejo».

6.3 Codificar volumen y deriva de esquema como alarmas

DetectAnomalies merece una mención especial: «checks for anomalies in another rule type's reported metrics», lo que convierte las reglas de umbral de ayer en una línea base autoajustable: a 1 DPU por estadística, por ejecución, y por eso AWS recomienda activarlo de forma selectiva.

---

7. Observabilidad operativa: un cuadro de mando por capa

7.1 Logs por capa

Las instalaciones multcuenta se centralizan con filtros de suscripción cross-account, un destino de logs de Firehose/Kinesis, o la centralización de datos de CloudWatch Logs a nivel de Organizations (los nombres del grupo de destino admiten ${source.accountId}, ${source.region}, ${source.logGroup}, ${source.org.id}).

7.2 El mapa de cuadros de mando

La recomendación de AWS Prescriptive Guidance es un cuadro de mando por preocupación: «un cuadro de mando de CloudWatch puede mostrar a los usuarios el estado de las cargas… o qué porcentaje de sus datos se descartó por baja calidad, o qué fuentes tienen el máximo de fallos.» Para este lakehouse eso se convierte en un cuadro de mando por capa medallón más un panel de operaciones de datos a nivel de cuenta:

Nivel gratuito en octubre de 2026: 10 métricas personalizadas, 3 cuadros de mando que referencian hasta 50 métricas cada uno, 10 métricas de alarma, 1 millón de peticiones de API y 5 GB de ingestión de logs al mes; las métricas personalizadas cuestan $0.30 por métrica-mes para las primeras 10,000, y después las escalas de $0.10 y $0.05. Los cuadros de mando y las alarmas se prorratean por hora desde su creación: una alarma sin uso no es gratis, y las alarmas de detección de anomalías «incurren costes por cada métrica que enumeres en la expresión de métrica de la alarma, más dos costes adicionales de métrica de alarma.»

---

8. Eventos de datos de CloudTrail: prefijos acotados y la factura

CloudTrail es la traza de auditoría del plano de datos, y, sin acotar, la factura sorpresa. «De forma predeterminada, los trails y los almacenes de eventos de datos no registran eventos de datos. Se aplican cargos adicionales por los eventos de datos.» Activarlos exige selectores de eventos avanzados con eventCategory Equals Data y resources.type Equals AWS:S3:Object, acotados con resources.ARN StartsWith, la barra final forma parte del ARN: arn:aws:s3:lakehouse-bronze/.

Reglas del camino:

• «Los selectores no admiten el uso de comodines como *»: enumeras prefijos, no haces glob.
• Selectores básicos: hasta 5 selectores de eventos y 250 recursos de datos por trail; los selectores avanzados permiten hasta 500 valores especificados entre condiciones, y los dos estilos no se pueden mezclar.
• Las exclusiones son filtros gratis: {"Field": "eventSource", "NotEquals": ["s3lifecycle.amazonaws.com"]} elimina el ruido de ciclo de vida; readOnly = false da auditoría de solo escritura para una landing zone.
• Precios: eventos de datos $0.10 por 100,000 entregados en S3 (agregaciones $0.03 por 100,000 analizados); eventos de gestión primera copia gratis, copias adicionales $2.00 por 100,000. Los eventos de gestión responden quién ejecutó StartJobRun / GrantPermissions / StartQueryExecution; los eventos de datos responden quién tocó qué objeto.

8.1 Ejemplo resuelto E5: tres selectores, una factura

---

9. Tres planos: DataZone, el catálogo de Glue, CloudTrail

9.1 Para qué sirve cada plano

El registro en Lake Formation autoriza el acceso a una ubicación, es un alcance de permiso, no una arista de linaje. CloudTrail registra actividad, no es un grafo de derivación. Presentar cualquiera de los dos como «linaje» es la confusión más común de todo este espacio.

9.2 Linaje: las fuentes que puedes nombrar de verdad

DataZone se sitúa encima del catálogo de negocio: creas fuentes de datos para Glue y Redshift, importas metadatos técnicos en un inventario de proyecto, los curas con nombres de negocio, términos de glosario y formularios de metadatos, y publicas: «solo la última versión del activo del inventario puede publicarse en el catálogo.» Un consumidor ve después «una vista del linaje de ese activo con 1 nivel aguas arriba y aguas abajo.» Es una capa de gobernanza y descubrimiento, no un sustituto del Glue Data Catalog que consultan Athena y Redshift Spectrum.

• 📚 ¿Sabías que…? El linaje de DataZone llegó a disponibilidad general el 2024-12-03, y el anuncio es explícito en que la captura es automática para Glue y Redshift y programática para todo lo demás: los productores «hidratan la información de linaje de forma programática creando nodos de linaje personalizados con APIs que aceptan eventos compatibles con OpenLineage de los componentes de pipeline existentes, como orquestadores, warehouses, herramientas de análisis y motores SQL.» Así que la prueba de integración de tu lakehouse es simple: publica un activo de Glue, ejecuta su fuente de datos y mira si aparece el nodo aguas arriba: antes de prometerle a nadie linaje de extremo a extremo (AWS News Blog, 2024-12-03).

Pie para memorizar: catálogo = metadatos técnicos y permisos (Glue + Lake Formation); DataZone = catálogo de negocio y linaje; CloudTrail = auditoría de acceso. Tres planos, tres herramientas.

---

10. Ejemplo resuelto E6: EventBridge → SNS → Lambda de remediación, cableado

10.1 La regla

10.2 Los destinos, en orden

Destino 1, tema de SNS dq-alerts (email / Chatbot para el canal humano). La entrega de SNS a Lambda y SQS está libre de cargo de entrega de SNS, «No charge for deliveries to SQS Queues. Standard SQS pricing applies», e igual para Lambda.

Destino 2: Lambda dq-remediate:

10.3 El IAM que le corresponde, y lo que cuesta

La moraleja es la economía: la ruta de alertas casi no cuesta; la ruta de datos es lo que cuesta dinero. Que es la forma correcta: un lakehouse que avisa a alguien por $1.80 al mes y gasta $21.90 al mes midiendo de verdad sus datos.

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

AWS publica cómo se ve esto a escala. Cada cifra de abajo es afirmación del cliente o de AWS y no auditada, con fuente y fecha indicadas: el punto examinable es el patrón.

Caso A, Siemens: logs centralizados que convirtieron días en 10 minutos

La lección para este curso es la forma de la respuesta: los 10 minutos de Siemens frente a varios días es lo que compran los grupos de log por capa, los selectores acotados y un cuadro de mando por capa: no diagnosticas más rápido porque la herramienta sea más lista, diagnosticas más rápido porque la evidencia ya estaba indexada y acotada. Fíjate en lo que el caso no afirma: Security Lake es un servicio de agregación de logs de seguridad, no AWS Lake Formation, y produce evidencia de auditoría, no linaje a nivel de columna.

Caso B, Vanguard: un «charco de datos» convertido en productos de datos con dueño

Lee los 600 jobs y las 500,000 consultas mensuales como una declaración de presupuesto de calidad: a ese volumen una partición mala silenciosa no es una molestia, es un mes de decisiones equivocadas. La frase «charco de datos» es la abreviatura de la propia industria para lo que pasa cuando un lago acumula ficheros sin curación, sin dueño y sin chequeos: que es exactamente el modo de falla para el que existen las reglas, la cuarentena y los SLOs de esta lección. (Las cifras de escala las reportan Vanguard/AWS en la publicación de marzo de 2026; son instantáneas, no garantías.)

---

Preguntas de Práctica (Practice Questions)