Qué le sigue faltando a Kiosko

Descripción

El lakehouse que existe al cerrar la lección 6 es real: cinco tablas Iceberg —fact_orders, dim_store, dim_product, dim_date, fact_orders_at_scale— conviviendo en el mismo catálogo, con ACID de verdad, time travel sin columnas de historia, partición oculta y evolucionada, y dos vías de escritura nativas que convergen en el mismo resultado. Y, al mismo tiempo, sigue siendo un lakehouse de laboratorio en un sentido muy concreto: corre en tu laptop, sobre un archivo kiosko_catalog.db de unos pocos megabytes, con cada operación disparada a mano desde tu propia terminal, sobre un cambio de P002 que sigue siendo un valor fijo escrito en Python. Esta lección no es una crítica a lo que construiste — es el mapa honesto de las siete fronteras exactas que esta guía, desde su propio diseño, decidió no cruzar, y el nombre preciso de la guía hermana que sí las cruza, cada una con evidencia concreta de este mismo lakehouse como punto de partida.

Conexión con el módulo. El DISEÑO de esta guía nombró estas siete fronteras desde su primera línea, en la sección "NO entra en" — esta lección es el cierre explícito de ese contrato: cada frontera nombrada ahí, ahora con la evidencia exacta de este capstone que la motiva.

Una analogía: la maqueta terminada, con la lista de "lo que la maqueta no simula"

Un estudio de arquitectura que entrega una maqueta a escala perfectamente terminada —con sus cinco piezas ensambladas, cada detalle correcto— entrega también, si es honesto, una lista clara de lo que la maqueta no simula: no tiene cableado eléctrico funcional, no resiste un sismo real, no tiene plomería que corra agua de verdad. Ninguna de esas ausencias significa que la maqueta esté mal construida — significa que cada una de esas piezas es un oficio especializado, con su propio ingeniero, que se contrata por separado cuando el edificio pasa de maqueta a construcción real. Este lakehouse de Iceberg es esa maqueta: bien ensamblada, con las cinco piezas encajando exactamente como debían. Esta lección es la lista de ingenieros especializados que Kiosko va a necesitar contratar después, cada uno nombrado con precisión, ninguno improvisado.

Frontera 1: streaming y CDC como fuente real del cambio → streaming-with-kafka-and-flink-guide

Qué resuelve. El cambio de P002 —snacks/0.60 a health-snacks/0.68, vigencia 2026-08-15— llegó, en toda esta guía, como dos listas de diccionarios fijas en Python: DIM_PRODUCT_V1 y DIM_PRODUCT_V2, escritas a mano, cargadas con table.overwrite() o table.upsert() en el momento exacto que tú elegiste correr el script. streaming-with-kafka-and-flink-guide enseña el mundo opuesto: change data capture (CDC), donde ese mismo cambio llega como un evento de Kafka en el instante exacto en que ocurrió en el sistema de origen de Kiosko —el sistema de inventario que decidió recategorizar la barra energética—, sin que nadie escriba una segunda lista de Python ni ejecute un script a mano.

La evidencia de este lakehouse. La lección 4 de este módulo capturó snap_v1 inmediatamente antes de aplicar V2 — una secuencia perfectamente controlada, porque tú decidiste cuándo ocurría cada paso. En un sistema con CDC real, Iceberg seguiría creando un snapshot nuevo por cada escritura —esa parte no cambia—, pero la escritura misma llegaría disparada por un consumidor de Kafka, procesando eventos a medida que el sistema de origen los produce, sin que ningún humano ejecute python3 kiosko_dim_product_time_travel.py en el momento correcto.

Frontera 2: contratos y linaje publicados → data-reliability-and-governance-guide

Qué resuelve. Este lakehouse tiene, gracias a Iceberg, algo que ninguna guía anterior del ecosistema tuvo con la misma fuerza: una historia auditable — cada snapshot de kiosko.dim_product es un registro inmutable de qué cambió y cuándo, consultable con table.history(). Pero esa historia vive únicamente dentro del catálogo kiosko, sin ningún contrato publicado que le diga a un equipo consumidor —el de BI, el de finanzas— qué columnas puede esperar, con qué tipos, con qué garantías de calidad. data-reliability-and-governance-guide enseña contratos de datos versionados independientemente, observabilidad con alertas automáticas, y linaje formal entre sistemas — mecanismos que operan sobre un catálogo como este, no dentro de él.

La evidencia de este lakehouse. kiosko.dim_product nunca tuvo, en ningún módulo de esta guía, una validación explícita de que unit_cost sea siempre positivo, o de que category pertenezca a una lista cerrada de valores permitidos — Iceberg garantiza que el tipo de cada columna es correcto (DoubleType, StringType), pero no garantiza nada sobre el contenido de negocio. Un contrato de datos publicado, en el sentido de data-reliability-and-governance-guide, haría esa garantía explícita y verificable de forma independiente, sin que un consumidor tenga que leer el código fuente de este capstone para confiar en los datos.

Frontera 3: catálogos gestionados con credenciales reales → aws-core-services-guide

Qué resuelve. Los ocho módulos completos de esta guía corrieron sobre un catálogo SqlCatalog respaldado por SQLite, en el filesystem local — perfecto para aprender, perfecto para $0 de costo, y exactamente lo que el módulo 7 nombró, sin implementar, como la distancia real hasta producción. aws-core-services-guide enseña los catálogos que sí operan en producción con credenciales reales: AWS Glue Data Catalog, S3 Tables — con permisos IAM, control de acceso multi-tenant, y un único puntero al metadata vigente compartido entre motores distintos (Spark, Trino, Athena) de verdad, no solo declarado como posible.

La evidencia de este lakehouse. kiosko_catalog.db es un único archivo SQLite en tu disco — si dos procesos en dos máquinas distintas necesitaran escribir en kiosko.dim_product al mismo tiempo, no hay ningún mecanismo de este lakehouse que lo resuelva; el módulo 7 ya nombró esto como la garantía exacta que un catálogo REST o Glue sí ofrece, con control de concurrencia real entre escritores distribuidos.

Frontera 4: orquestación programada → airflow-and-declarative-orchestration-guide

Qué resuelve. Cada operación de este capstone —cada append(), cada overwrite(), cada upsert()— la disparaste tú, corriendo un script desde tu terminal, en el orden que tú elegiste. El MERGE INTO/upsert() de la lección 6 de este módulo no corrió como una tarea programada de ningún pipeline — corrió porque tú ejecutaste python3 kiosko_native_merge_check.py en este momento específico. airflow-and-declarative-orchestration-guide toma exactamente este mismo código, sin cambiarle una línea a la lógica de Iceberg, y lo convierte en una tarea de un DAG: reintentos gestionados si una escritura falla a mitad de camino, sensores que esperan a que el archivo de origen realmente exista antes de disparar la carga, y alertas si algo sigue fallando después de los reintentos.

La evidencia de este lakehouse. Nada en el código de la lección 6 de este módulo impide que dos personas, sin coordinarse, corran kiosko_native_merge_check.py dos veces el mismo día — cada corrida crearía su propia tabla kiosko.dim_product_merge_check desde cero, o fallaría con TableAlreadyExistsError si la tabla ya existe. Un DAG de Airflow resolvería esa ambigüedad con una sola fuente de verdad sobre cuándo y cuántas veces corre cada tarea — la misma disciplina operativa que ninguna guía de este ecosistema construyó todavía por sí sola, sin excepción.

Frontera 5: dbt versionando esta misma transformación como código → dbt-analytics-engineering-guide

Qué resuelve. El cambio de V1 a V2 de dim_product está escrito, en este capstone, como Python imperativo dentro de un script — no como un modelo declarativo versionado, con tests automáticos y documentación generada. dbt-analytics-engineering-guide ya enseñó cómo automatizar exactamente este mismo problema con dbt snapshot; lo que esa guía no pudo enseñar todavía —porque Iceberg era, en ese momento del ecosistema, terreno de esta guía— es el adaptador dbt-iceberg, que le permite a un proyecto dbt escribir directamente sobre tablas Iceberg, con ref(), tests genéricos y dbt docs generate operando sobre el mismo kiosko.dim_product de este capstone, en vez de una tabla DuckDB corriente.

La evidencia de este lakehouse. El script de la lección 4 de este módulo repite, cada vez que corre, la misma lógica de negocio —cargar V1, capturar snap_v1, aplicar V2— sin ningún test declarativo que confirme, de forma automática, que unit_cost de P002 cambió exactamente de 0.60 a 0.68 y no a otro valor por error de tipeo. Un modelo dbt sobre dbt-iceberg, con un test genérico accepted_values o un test singular equivalente, convertiría esa verificación manual —hoy resuelta con assert escritos a mano en cada proyecto de cierre— en parte de la infraestructura declarativa del propio proyecto, versionada junto al modelo.

Frontera 6: SQL de rendimiento a fondo → advanced-sql-querying-guide

Qué resuelve. Cada consulta de este capstone —el JOIN en memoria de la lección 4, el filtro store_id == 'S01' de la lección 5— corrió sin que ninguna lección de esta guía midiera, con EXPLAIN o una herramienta equivalente, el plan de ejecución real detrás de esas operaciones. advanced-sql-querying-guide enseña ese tema a fondo: planes de ejecución, tuning de índices, la teoría de conjuntos detrás de cada tipo de JOIN — herramientas que se vuelven indispensables en cuanto el volumen de un lakehouse real supera lo que una demo de aprendizaje necesita medir.

La evidencia de este lakehouse. La lección 5 de este módulo sí midió algo relacionado —files_touched_s01 contra files_touched_all, la poda real de archivos por partición oculta—, pero esa medición es específica de Iceberg (qué archivos toca un scan), no un análisis de plan de ejecución SQL general. Sobre kiosko.fact_orders_at_scale, con diez millones de filas, cualquier consulta más compleja que un filtro simple por store_id —un JOIN con agregación, por ejemplo— se beneficiaría exactamente del tipo de análisis que advanced-sql-querying-guide enseña, y que esta guía, por diseño, nunca profundizó.

Frontera 7: FinOps de datos a fondo → cost-optimization-caching-guide

Qué resuelve. El módulo 7 de esta guía ya midió, con evidencia real, que cinco noches de un pipeline redundante multiplicaron por más de cuatro el número de snapshots de kiosko.dim_product — un problema de higiene operativa, resuelto con expire_snapshots(). Lo que ese módulo no hizo, a propósito, fue traducir ese crecimiento a un costo en dólares: cuánto cuesta, en un bucket S3 real, mantener esos snapshots redundantes durante un mes, o con qué frecuencia correr el mantenimiento según un presupuesto específico. cost-optimization-caching-guide enseña ese ángulo completo: FinOps de datos, no solo higiene técnica.

La evidencia de este lakehouse. kiosko.fact_orders_at_scale, con diez millones de filas y dos esquemas de partición conviviendo, es exactamente el tipo de tabla donde una decisión de mantenimiento mal calibrada —expirar snapshots con demasiada frecuencia, o no expirarlos nunca— tiene un costo real medible en almacenamiento. Esta guía midió esa tabla en filas y en archivos tocados; nunca la midió en dólares, porque ese cálculo específico —tarifas de almacenamiento por GB, costos de lectura por request— pertenece, por diseño, a cost-optimization-caching-guide.

El mapa completo

flowchart TD
    K["Lakehouse de Kiosko\n5 tablas Iceberg, 1 catalogo\nejecutado a mano, en tu laptop"]

    K -->|"P002 sigue llegando como\nvalor fijo, no CDC real"| A["streaming-with-kafka-\nand-flink-guide"]
    K -->|"historia auditable sin\ncontratos ni linaje publicado"| B["data-reliability-and-\ngovernance-guide"]
    K -->|"catalogo local, sin\ncredenciales reales"| C["aws-core-services-guide"]
    K -->|"cada operacion disparada\na mano, no programada"| D["airflow-and-declarative-\norchestration-guide"]
    K -->|"dbt-iceberg versionaria\nesta misma transformacion"| E["dbt-analytics-\nengineering-guide"]
    K -->|"sin EXPLAIN ni tuning\nde planes de ejecucion"| F["advanced-sql-\nquerying-guide"]
    K -->|"snapshots medidos en\nfilas, nunca en dolares"| G["cost-optimization-\ncaching-guide"]

Por qué ninguna de estas siete fronteras invalida lo que ya construiste

Vale la pena cerrar esta lección con la misma disciplina que ya usó el módulo 7 de esta guía: nombrar una limitación no es señalar un error. Cada patrón que construiste en esta guía —tablas Iceberg reales con ACID verificado, snapshots automáticos en cada commit, time travel sin ninguna columna de historia, evolución de esquema y de partición sin reescribir un solo archivo, dos vías nativas de merge convergiendo en el mismo resultado— es el mismo patrón que un lakehouse de producción usa a cualquier escala, sobre cualquier catálogo, orquestado por cualquier sistema. Ninguna de las siete guías de esta lección reemplaza lo que aprendiste — cada una asume que ya lo sabes, y construye sobre esa base exactamente como este módulo construyó sobre los siete anteriores.

Errores comunes

Pensar que estas siete fronteras significan que hay que aprenderlas todas antes de usar Iceberg en un trabajo real. Qué pasa: alguien termina esta lección sintiendo que el lakehouse de Kiosko es "incompleto" hasta dominar las siete guías hermanas, y pospone cualquier uso real de Iceberg hasta entonces. Por qué pasa: ver siete fronteras nombradas de una sola vez se siente abrumador, como si fueran siete prerrequisitos en vez de siete caminos posibles. Cómo detectarlo: pregúntate si un data engineer júnior, en su primer trabajo real, necesita saber CDC con Kafka o FinOps de datos antes de escribir su primera tabla Iceberg productiva — la respuesta, con la evidencia de mercado que el DISEÑO de esta guía citó desde el principio (Niuro pidiendo literal "Apache Iceberg or Delta Lake table formats on AWS S3"), es que no: Iceberg con un catálogo gestionado es, por sí solo, una habilidad contratable. Cómo corregirlo: estas siete guías son caminos que se recorren cuando el problema específico aparece —cuando de verdad hace falta CDC, cuando de verdad hace falta orquestación—, no una lista de prerrequisitos que hay que agotar antes de usar lo que ya aprendiste.

Confundir "esta guía no lo cubre" con "esta guía lo hizo mal". Qué pasa: alguien nota que el catálogo kiosko/SQLite "no es tan robusto como Glue", o que el cambio de P002 "no es tan realista como CDC", y concluye que el diseño de esta guía tiene un defecto. Por qué pasa: cada frontera nombrada en esta lección suena, a primera lectura, como una carencia — es fácil leer "esto no lo resuelve" como "esto está mal resuelto". Cómo detectarlo: revisa si el patrón en sí —no la infraestructura— es correcto: table.overwrite() y table.upsert() aplican el cambio de P002 de forma ACID, con la evidencia exacta que verificaste en las lecciones 4 y 6; que un catálogo Glue resuelva la misma necesidad de coordinación con una infraestructura distinta no hace que el mecanismo de Iceberg esté mal, solo que opera a una escala y con una gobernanza distintas. Cómo corregirlo: separa siempre "¿el patrón de Iceberg es correcto?" de "¿esta infraestructura específica escala al contexto de producción que yo necesito?" — las siete fronteras de esta lección son, en su mayoría, la segunda pregunta, no la primera.

Buscar las siete guías hermanas en el orden en que aparecen en esta lección, como si fuera un temario obligatorio. Qué pasa: alguien decide que el siguiente paso correcto es leer streaming-with-kafka-and-flink-guide primero, después data-reliability-and-governance-guide, en el mismo orden exacto de esta lección, como si existiera una secuencia única correcta. Por qué pasa: cualquier lista numerada se lee, por instinto, como una secuencia — es fácil olvidar que el orden de esta lección es solo el orden en que el DISEÑO original de la guía las nombró, no una progresión pedagógica obligatoria. Cómo detectarlo: pregúntate qué problema específico tienes hoy, en tu propio trabajo o proyecto — si tu catálogo local ya no alcanza porque necesitas compartirlo entre varios motores, aws-core-services-guide es tu siguiente paso; si necesitas programar corridas automáticas, es airflow-and-declarative-orchestration-guide. Cómo corregirlo: elige la guía hermana según el problema real que tengas enfrente, no según el orden en que esta lección las mencionó — las siete son independientes entre sí, sin ninguna dependencia declarada unas de otras.

Ejercicios

Ejercicio 1 — Relaciona cada frontera con la evidencia específica de este lakehouse que la motiva. Sin mirar las secciones de esta lección, para cada una de las siete guías hermanas, escribe en una frase qué parte específica del lakehouse de Kiosko (una lección, una tabla, un comando) sirve de evidencia de por qué esa frontera existe.

Ver solución

streaming-with-kafka-and-flink-guide → DIM_PRODUCT_V1/DIM_PRODUCT_V2, dos listas fijas en Python, en vez de un evento CDC real. data-reliability-and-governance-guide → kiosko.dim_product sin ninguna validación de negocio publicada sobre unit_cost o category. aws-core-services-guide → kiosko_catalog.db, un único archivo SQLite local, sin control de concurrencia entre escritores distribuidos. airflow-and-declarative-orchestration-guide → cada script de este módulo, disparado a mano desde la terminal, sin reintentos ni sensores. dbt-analytics-engineering-guide → la lógica de V1→V2 escrita como Python imperativo, sin un modelo dbt declarativo sobre dbt-iceberg. advanced-sql-querying-guide → ningún EXPLAIN sobre el JOIN en memoria de la lección 4. cost-optimization-caching-guide → los snapshots redundantes del módulo 7, medidos en cantidad, nunca en dólares.

Ejercicio 2 — Elige, para tu propio contexto, cuál de las siete fronteras resolverías primero. Sin ninguna respuesta correcta única, elige una de las siete guías hermanas y escribe, en 2-3 frases, por qué sería la más urgente para un proyecto real que tú conozcas o imagines.

Ver solución

No hay una respuesta única — la respuesta correcta depende del problema real. Un ejemplo razonable: si el lakehouse imaginado ya corre en un bucket S3 compartido por varios equipos, sin ningún catálogo gestionado que coordine el acceso, aws-core-services-guide sería la prioridad más clara — el mismo problema exacto que el módulo 7 de esta guía ya nombró, sin implementar, con evidencia del catálogo local kiosko. Otro ejemplo igual de válido: si el negocio necesitara reaccionar a cambios de catálogo de producto en minutos, no en el momento en que alguien corre un script, streaming-with-kafka-and-flink-guide se volvería urgente antes que cualquier otra frontera.

Ejercicio 3 — Explica por qué data-modeling-for-analytics-guide no aparece en el mapa de esta lección, a pesar de ser la guía más citada en todo este módulo. En 2-3 frases, explica la diferencia entre una guía que es fuente (data-modeling-for-analytics-guide) y una guía que es siguiente paso (las siete de esta lección).

Ver solución

data-modeling-for-analytics-guide no aparece en el mapa de "qué le sigue faltando a Kiosko" porque no es una frontera hacia adelante — es la fuente ya consumida de todo el problema que esta guía resolvió: el dim_product historizado a mano, con valid_from/valid_to/is_current, y el cambio canónico de P002 (10.8/9.36), ambos ya reproducidos y verificados en las lecciones 3 y 4 de este módulo. Las siete guías de esta lección, en cambio, resuelven problemas que este lakehouse todavía no tiene resueltos —CDC, contratos, catálogos gestionados, orquestación, dbt sobre Iceberg, SQL de rendimiento, FinOps—, cada una con su propia evidencia concreta de por qué hace falta, no un problema que ya se terminó de resolver con el formato de tabla.

Resumen y siguiente paso

Esta lección cerró el mapa completo del ecosistema data-engineering-ecosystem desde la perspectiva de este lakehouse: siete fronteras nombradas con precisión —CDC real, contratos y linaje, catálogos gestionados, orquestación programada, dbt sobre Iceberg, SQL de rendimiento, FinOps de datos—, cada una con la guía hermana exacta que la resuelve y la evidencia concreta de este mismo capstone que motiva por qué hace falta. Ninguna de las siete invalida lo que construiste en los ocho módulos de esta guía — cada patrón que aprendiste es el mismo que un lakehouse de producción usa a cualquier escala.

Antes de avanzar deberías poder: nombrar las siete guías hermanas de memoria, junto con el problema específico que cada una resuelve; y explicar por qué data-modeling-for-analytics-guide no es parte de este mapa, a pesar de ser la fuente de todo el problema que este módulo resolvió.

La lección 8 —el proyecto final de toda la guía— reúne los ocho módulos completos en un solo script, de principio a fin, con la verificación final de que el revenue total (106.15) y el margen correcto de P002 (10.8, vía time travel) coinciden exactamente con data-modeling-for-analytics-guide M8 y dbt-analytics-engineering-guide M8.

Recursos

• streaming-with-kafka-and-flink-guide — CDC como fuente real de un cambio de dimensión, en vez de un valor fijo declarado en Python. Guía hermana de este ecosistema.
• data-reliability-and-governance-guide — contratos de datos publicados y linaje formal, más allá de la historia auditable que un catálogo Iceberg ya ofrece por sí solo. Guía hermana de este ecosistema.
• aws-core-services-guide — catálogos gestionados en la nube (AWS Glue Data Catalog, S3 Tables), con credenciales y control de concurrencia real, más allá del catálogo local kiosko/SQLite. Guía hermana de este ecosistema.
• airflow-and-declarative-orchestration-guide — orquesta cada script de este lakehouse como una tarea de un DAG, con reintentos y sensores. Guía hermana de este ecosistema.
• dbt-analytics-engineering-guide — el adaptador dbt-iceberg, para versionar esta misma transformación como un modelo dbt declarativo sobre tablas Iceberg. Guía hermana de este ecosistema.
• advanced-sql-querying-guide — planes de ejecución (EXPLAIN) a fondo, tuning de índices, más allá de la poda de archivos por partición que este lakehouse ya midió. Guía hermana de este ecosistema.
• cost-optimization-caching-guide — FinOps de datos: el costo real en dólares de mantener snapshots, más allá del conteo de archivos que el módulo 7 de esta guía ya midió. Guía hermana de este ecosistema.
• src/paths/data-engineering-ecosystem/VALIDACION.md — la auditoría de mercado que confirma el veredicto de esta guía y el mandato de cubrir catálogos y compactación, base del módulo 7 y de esta lección de cierre. Documento interno del repo. En español.