Qué le falta todavía a Kiosko

Descripción

El warehouse de Kiosko funciona, de punta a punta, y lo probaste con evidencia: bronze y silver reconstruidos, un star con historia real, dos patrones de hecho que ningún modelo transaccional puede resolver, y una OBT publicada con el join correcto ya adentro. Sería un error, sin embargo, cerrar esta guía pensando que ese warehouse está "terminado" en el sentido en que un equipo de datos real lo terminaría. No lo está — y esta lección existe para ser honesta sobre exactamente qué le falta, sin vaguedad, nombrando cada hueco con precisión y la guía específica del ecosistema de Data Engineering de NIEVA que lo resuelve.

Conexión con el módulo. Esta lección no agrega ni una línea de código nuevo al warehouse de Kiosko — es, deliberadamente, un mapa. Cada fila de la tabla que sigue nombra una limitación real y verificable de lo que construiste en los ocho módulos de esta guía, y la guía hermana exacta que la resuelve. No es una lista de "cosas interesantes que podrías aprender después" — es la frontera explícita que esta guía trazó desde su propio diseño, módulo por módulo, y que ahora, con el warehouse completo delante, por fin tiene sentido ver junta.

Una analogía: quien ya sabe diseñar una casa, no todavía dirigir la constructora

Alguien que termina un curso completo de arquitectura residencial y diseña, con criterio real, los planos de una casa —cimientos, distribución, plomería, electricidad— ya sabe diseñar una casa. Pero esa misma persona no puede, todavía, dirigir una constructora que levanta cien casas al año: no sabe coordinar veinte cuadrillas trabajando en paralelo, no sabe qué hacer cuando el proveedor de cemento se atrasa a mitad de una obra, no sabe versionar los planos cuando tres arquitectos distintos los modifican la misma semana. Ninguna de esas carencias invalida lo que aprendió — la casa que sabe diseñar es real, y el criterio que dominó (grano, forma, historia, distribución de responsabilidades) es exactamente el mismo que necesitaría alguien dirigiendo cien obras a la vez, a mayor escala.

Terminaste esta guía sabiendo diseñar un warehouse dimensional completo: el de Kiosko, con grano declarado, historia preservada, joins correctos en el tiempo, y contratos de esquema verificados. Lo que sigue —dirigir la construcción completa de un warehouse de producción, con volumen real, con un equipo, con orquestación y con gobierno— es exactamente lo que las guías hermanas de este ecosistema enseñan, cada una profundizando un hilo específico que aquí, a propósito, se dejó superficial.

El mapa: las guías hermanas, y qué resuelve cada una

# ecosystem_map.py
GAPS = [
    ("dbt-analytics-engineering-guide",
     "El SQL de este warehouse vive en scripts de Python ejecutados directo "
     "(con.execute(...)) -- nadie mas en el equipo puede versionarlo, testearlo "
     "declarativamente ni rastrear su lineage sin leer el codigo Python entero."),
    ("airflow-and-declarative-orchestration-guide",
     "bronze -> silver -> gold se corre a mano, en un solo script, en el orden "
     "que TU escribiste -- nada lo programa para correr solo cada noche, ni "
     "reintenta un paso que falla si el MERGE de dim_product_scd se corta a la mitad."),
    ("spark-and-distributed-processing-guide",
     "Las 40 ordenes y 32 eventos de Kiosko caben en memoria a proposito -- un "
     "retailer real, con millones de ordenes y miles de productos cambiando de "
     "categoria cada trimestre, necesitaria saber cuando SI hace falta un cluster."),
    ("lakehouse-and-iceberg-guide",
     "dim_product_scd historiza a mano, con columnas valid_from/valid_to y un "
     "MERGE INTO escrito por ti -- sin time travel nativo, sin transacciones ACID "
     "entre varios escritores, sin catalogo formal."),
    ("streaming-with-kafka-and-flink-guide",
     "El cambio de P002 llego como un snapshot fijo (products_v2), cargado a mano "
     "-- en produccion real, ese cambio llegaria por CDC desde el sistema "
     "transaccional del catalogo, no como un archivo Python declarado a proposito."),
    ("data-reliability-and-governance-guide",
     "validate_gold_schema() es una funcion local que tu mismo corres -- no hay "
     "linaje formal, ni contratos de datos publicados como artefacto, ni control "
     "de acceso a nivel de columna (quien puede ver unit_cost, quien solo revenue)."),
    ("python-for-data-engineering-guide",
     "Todo el codigo de este warehouse es Python plano, sin tests, sin logging "
     "estructurado, sin empaquetado -- el glue code minimo para disparar SQL, "
     "no la API completa de DuckDB/Polars como motor de trabajo diario."),
    ("advanced-sql-querying-guide",
     "EXPLAIN se uso una sola vez (modulo 3) para COMPARAR star vs snowflake -- "
     "nunca para afinar un plan de ejecucion lento, ni para escribir una CTE "
     "recursiva sobre un warehouse de produccion real."),
]

print("=== Kiosko: lo que este warehouse NO resuelve, y quien si ===\n")
for guide, gap in GAPS:
    print(f"{guide}")
    print(f"  -> {gap}\n")

Qué esperar. Al correr python3 ecosystem_map.py, la salida es exactamente esta:

=== Kiosko: lo que este warehouse NO resuelve, y quien si ===

dbt-analytics-engineering-guide
  -> El SQL de este warehouse vive en scripts de Python ejecutados directo (con.execute(...)) -- nadie mas en el equipo puede versionarlo, testearlo declarativamente ni rastrear su lineage sin leer el codigo Python entero.

airflow-and-declarative-orchestration-guide
  -> bronze -> silver -> gold se corre a mano, en un solo script, en el orden que TU escribiste -- nada lo programa para correr solo cada noche, ni reintenta un paso que falla si el MERGE de dim_product_scd se corta a la mitad.

spark-and-distributed-processing-guide
  -> Las 40 ordenes y 32 eventos de Kiosko caben en memoria a proposito -- un retailer real, con millones de ordenes y miles de productos cambiando de categoria cada trimestre, necesitaria saber cuando SI hace falta un cluster.

lakehouse-and-iceberg-guide
  -> dim_product_scd historiza a mano, con columnas valid_from/valid_to y un MERGE INTO escrito por ti -- sin time travel nativo, sin transacciones ACID entre varios escritores, sin catalogo formal.

streaming-with-kafka-and-flink-guide
  -> El cambio de P002 llego como un snapshot fijo (products_v2), cargado a mano -- en produccion real, ese cambio llegaria por CDC desde el sistema transaccional del catalogo, no como un archivo Python declarado a proposito.

data-reliability-and-governance-guide
  -> validate_gold_schema() es una funcion local que tu mismo corres -- no hay linaje formal, ni contratos de datos publicados como artefacto, ni control de acceso a nivel de columna (quien puede ver unit_cost, quien solo revenue).

python-for-data-engineering-guide
  -> Todo el codigo de este warehouse es Python plano, sin tests, sin logging estructurado, sin empaquetado -- el glue code minimo para disparar SQL, no la API completa de DuckDB/Polars como motor de trabajo diario.

advanced-sql-querying-guide
  -> EXPLAIN se uso una sola vez (modulo 3) para COMPARAR star vs snowflake -- nunca para afinar un plan de ejecucion lento, ni para escribir una CTE recursiva sobre un warehouse de produccion real.

Ocho líneas, ocho huecos reales, ocho guías. Ninguna de estas limitaciones es un error del warehouse que construiste — son, exactamente, la frontera que esta guía trazó desde el módulo 1: "aquí se llega hasta el modelo dimensional correcto, ejecutado de verdad; la infraestructura de producción que lo rodea vive en la guía hermana correspondiente".

Profundización: una por una, las guías hermanas

dbt-analytics-engineering-guide. El SQL de este warehouse —MERGE INTO dim_product_scd, el JOIN punto-en-el-tiempo, la agregación de mart_daily_sales_obt— vive dentro de scripts de Python, ejecutado con con.execute(open("archivo.sql").read()) o directamente como texto inline. Nadie más en un equipo real puede versionar esas reglas de negocio en Git de forma declarativa, escribir un test que confirme "category nunca debe ser nula en dim_product_scd" sin escribirlo a mano como un assert, ni responder "¿de qué tabla fuente sale exactamente la columna margin de la OBT?" sin leer el código Python línea por línea. Esta guía hermana toma el mismo modelo dimensional que construiste aquí y lo convierte en un proyecto dbt real: modelos SQL versionados, tests declarativos (not_null, unique, relationships), y un grafo de lineage automático.

airflow-and-declarative-orchestration-guide. El warehouse completo de este módulo se corre con un solo comando, python3 kiosko_analytics_warehouse.py, de principio a fin, en el orden exacto que tú escribiste en el script. Ningún sistema lo programa para correr solo cada madrugada, ningún sistema reintenta automáticamente el segundo MERGE INTO si falla por un problema transitorio de memoria, y ningún sistema detecta que bronze llegó incompleto antes de que silver intente procesarlo. Esta guía hermana toma exactamente esta secuencia bronze→silver→gold y la convierte en un DAG real: sensores, reintentos gestionados por el orquestador, y observabilidad de cada corrida.

spark-and-distributed-processing-guide. El dataset completo de Kiosko —cuarenta órdenes, treinta y dos eventos— cabe cómodamente en la memoria de cualquier laptop, y esta guía lo declaró así, a propósito, desde el módulo 1: la pregunta "¿esto necesita un clúster?" se responde con un NO justificado, no con una intuición. Pero un retailer real, con millones de órdenes diarias y un catálogo de miles de productos que cambian de categoría constantemente, sí cruza el umbral donde MERGE INTO sobre una sola conexión de DuckDB deja de alcanzar. Esta guía hermana enseña cuándo SÍ distribuir el cómputo entre varias máquinas, y cómo razonar sobre un plan de ejecución distribuido para un MERGE de SCD a escala.

lakehouse-and-iceberg-guide. dim_product_scd, tal como la construiste en la lección 4 de este módulo, historiza a mano: tú decidiste las columnas valid_from/valid_to/is_current, tú escribiste el MERGE INTO con su lógica de detección de cambios, y esa tabla vive como un archivo Parquet o una tabla DuckDB simple, sin ningún catálogo formal que rastree sus versiones. Esta guía hermana construye la capa que reemplaza ese trabajo manual con time travel nativo del motor: Apache Iceberg o Delta Lake pueden responder "¿cómo se veía esta tabla el 14 de agosto?" con una simple consulta de versión, sin que nadie tenga que mantener columnas valid_from/valid_to a mano — el mismo problema que resolviste en el módulo 4, resuelto de otra forma, a nivel del formato de tabla.

streaming-with-kafka-and-flink-guide. El cambio de P002 —de snacks/0.60 a health-snacks/0.68— llegó a este warehouse como PRODUCTS_V2, un snapshot fijo declarado directamente en Python, cargado en un momento que tú decidiste. En producción real, ese cambio llegaría como un evento de un sistema transaccional de catálogo —alguien, en algún ERP, actualiza el registro de P002—, propagado por Change Data Capture (CDC) hacia el warehouse, sin que nadie tenga que preparar manualmente un segundo snapshot. Esta guía hermana enseña Kafka como sistema de mensajería, Flink para procesamiento continuo, y CDC como la fuente de producción típica de cualquier SCD — el módulo 4 de esta guía ya nombró esto explícitamente al construir dim_product_scd, sin implementarlo.

data-reliability-and-governance-guide. validate_gold_schema(), construida en el módulo 7 y corrida de nuevo en este capstone, es un contrato local: vive dentro del propio script del warehouse, la corres tú mismo, y no sabe nada de lo que pasa fuera de este pipeline específico. No hay linaje formal que rastree automáticamente de dónde viene cada columna a través de un ecosistema completo de pipelines, no hay contratos de datos como artefacto versionado que un equipo consumidor pueda validar antes de usar tus datos, y no hay control de acceso granular —¿quién puede ver unit_cost, el costo real de cada producto, y quién solo el revenue agregado que ya viste en la OBT?—. Esta guía hermana construye exactamente esas capacidades, a la escala de una organización completa.

python-for-data-engineering-guide. Todo el código de este warehouse —kiosko.py, los scripts de cada lección— es deliberadamente plano: archivos .py que corres con python3 archivo.py, sin estructura de paquete, sin pytest, sin logging más allá de un print(). Esta guía, la número dos del ecosistema, ya existía antes que esta —esta guía se apoyó en ella solo como referencia de estilo, sin asumirla como prerequisito—, y profundiza exactamente lo que aquí quedó como glue code mínimo: empaquetado real, pruebas automatizadas, logging estructurado, y la API completa de DuckDB y Polars como motores de trabajo diario, no como la herramienta que solo dispara un SELECT cada vez.

advanced-sql-querying-guide (vinculada, de otro ecosistema). EXPLAIN, en esta guía, se usó una sola vez —en el módulo 3, para comparar el costo de un JOIN de un salto (star) contra uno de dos saltos (snowflake)—, nunca para diagnosticar y afinar una consulta lenta en un warehouse de producción real. Window functions más allá de ROW_NUMBER(), CTEs recursivas, y la lectura profesional de un plan de ejecución para optimizar (no solo comparar) viven en esta guía vinculada, del ecosistema de SQL, no del de Data Engineering.

Errores comunes

Sentir que el warehouse de Kiosko "no sirve" porque le faltan estas ocho cosas. Qué pasa: alguien termina esta lección con la sensación de que todo lo construido en los ocho módulos era, en el fondo, un ejercicio de juguete incompleto. Por qué pasa: ver una lista de ocho carencias, todas juntas, se siente abrumador — parece que "falta casi todo". Cómo detectarlo: si tu conclusión es "entonces no aprendí modelado dimensional real", relee la analogía de esta lección — la casa que aprendiste a diseñar es genuina, aunque todavía no sepas dirigir la constructora completa. Cómo corregirlo: cada patrón que construiste —grano, star, SCD, join punto-en-el-tiempo, accumulating snapshot, cumulative design, dimensión junk, contrato de esquema— es el mismo patrón exacto que usa un warehouse de producción a cualquier escala, tal como advirtió el diseño de esta guía desde el módulo 1. Lo que falta no es "el modelo correcto" — es la infraestructura de producción alrededor de ese modelo, y eso es, precisamente, lo que enseña cada guía hermana.

Intentar aprender las ocho guías hermanas todas a la vez. Qué pasa: alguien, motivado por el mapa completo de esta lección, intenta abrir las ocho guías en paralelo, sin terminar ninguna a fondo. Por qué pasa: ver ocho huecos nombrados explícitamente genera la urgencia de "resolverlos todos ya". Cómo detectarlo: si tienes ocho pestañas del navegador abiertas con guías distintas y no completaste ni el primer módulo de ninguna, es una señal de dispersión, no de progreso. Cómo corregirlo: elige una guía, la que resuelve el hueco que más te importa para tu situación concreta —¿necesitas versionar tu modelo como código para tu trabajo actual? empieza por dbt; ¿te interesa el time travel nativo? empieza por Iceberg—, y termínala antes de abrir la siguiente. El mapa de esta lección es para orientarte, no para consumirse de una sola sentada.

Asumir que el orden de la tabla de esta lección es el orden en que hay que aprenderlas. Qué pasa: alguien interpreta que, como dbt-analytics-engineering-guide aparece primera en la lista, es la que "hay que" estudiar primero, sin importar su situación. Por qué pasa: una lista numerada o en orden sugiere, implícitamente, una secuencia obligatoria. Cómo detectarlo: si elegiste una guía hermana solo porque "era la primera de la lista", no porque resuelve un hueco que te importa a ti específicamente, revisa tu razón. Cómo corregirlo: el orden de esta lección sigue, simplemente, el orden en que cada tema apareció mencionado a lo largo de los ocho módulos de esta guía —no implica prioridad ni secuencia obligatoria—. Elige según tu propio contexto: alguien que ya trabaja con Kafka en su empleo actual probablemente saque más valor de dbt-analytics-engineering-guide que de repetir CDC desde cero.

Ejercicios

Ejercicio 1 — Mapea tu propio hueco. Piensa en una limitación del warehouse de Kiosko que tú mismo notaste durante los ocho módulos de esta guía, y que no esté nombrada explícitamente en la tabla de esta lección (puede ser algo pequeño). Identifica a cuál de las guías hermanas correspondería, y justifica tu elección en 2-3 frases.

Ver solución

No hay una única respuesta correcta —el ejercicio pide reflexión personal—, pero un ejemplo razonable: "el warehouse de Kiosko nunca validó que valid_from fuera siempre anterior a valid_to en dim_product_scd, ni que dos versiones del mismo producto nunca se solaparan en el tiempo". Esa limitación específica podría verse como una extensión de validate_gold_schema() (que solo valida esquema, no reglas de negocio sobre los datos) o, pensada como una regla que debería aplicarse de forma consistente a cualquier dimensión historizada de cualquier pipeline de la organización, caería dentro de data-reliability-and-governance-guide.

Ejercicio 2 — Distingue guía hermana de guía vinculada. Sin mirar las secciones anteriores, clasifica cada una de estas cuatro guías como hermana (parte del ecosistema de Data Engineering) o vinculada (de otro ecosistema, referenciada porque este warehouse la necesita indirectamente):

• (a) lakehouse-and-iceberg-guide
• (b) advanced-sql-querying-guide
• (c) streaming-with-kafka-and-flink-guide
• (d) python-for-data-engineering-guide

Ver solución

• (a) Hermana. Profundiza el formato de tabla del lakehouse con time travel nativo, un hilo abierto explícitamente en los módulos 4 y 5 de esta guía.
• (b) Vinculada. Pertenece al ecosistema de SQL, referenciada porque EXPLAIN en esta guía fue deliberadamente introductorio.
• (c) Hermana. Continúa el hilo de CDC que el módulo 4 nombró al historizar dim_product_scd con un snapshot fijo en vez de un evento real.
• (d) Hermana. Es la guía número dos del ecosistema de Data Engineering —anterior a esta—, que profundiza el Python de producción que aquí quedó como glue code mínimo.

Ejercicio 3 — Argumenta por qué esta guía no intentó enseñar las ocho cosas a la vez. Usando el criterio de frontera que esta guía declaró desde su propio diseño (módulo 1), explica en 2-3 frases por qué habría sido un error pedagógico que esta guía intentara cubrir, aunque fuera superficialmente, los ocho temas de las guías hermanas dentro de sus propios ocho módulos.

Ver solución

Si esta guía hubiera intentado tocar dbt, Airflow, Spark, Iceberg, Kafka, gobierno de datos y Python de producción dentro de sus propios ocho módulos, cada tema habría recibido, como mucho, una mención superficial, sin el código real y verificado que sí tuvo cada concepto que sí cubrió a fondo —grano, star, SCD, join punto-en-el-tiempo, accumulating snapshot, cumulative design—. Separar cada tema en su propia guía hermana, completa y terminal en sí misma, es lo que permite que cada una reciba el mismo tratamiento ejecutable que recibió el modelado dimensional aquí, en vez de una demostración de dos minutos sin ningún assert detrás.

Resumen y siguiente paso

En esta lección diste un paso atrás del código y trazaste el mapa completo de ecosistema: siete guías hermanas —dbt, Airflow, Spark, Iceberg, Kafka/Flink, gobierno de datos, Python de producción— más una guía vinculada de otro ecosistema —SQL avanzado—, cada una resolviendo un hueco específico y nombrado del warehouse de Kiosko. Ninguna limitación nombrada aquí invalida lo que construiste — es, exactamente, la frontera que esta guía trazó desde su propio diseño, ahora vista completa con el warehouse terminado delante.

Antes de cerrar la guía deberías poder: nombrar, de memoria, al menos cuatro de las ocho guías nombradas en esta lección y qué resuelve cada una; explicar la diferencia entre una guía hermana y una guía vinculada; y elegir, con criterio propio —no por orden de lista—, cuál guía seguirías primero según tu propia situación.

La lección 8, el mini-proyecto final que cierra toda la guía, junta el warehouse completo una última vez —bronze, silver, star historizado, funnel, actividad, OBT— en un solo flujo verificado de punta a punta: la entrega definitiva de data-modeling-for-analytics-guide.

Recursos

• dbt Labs — "What is dbt?" — introducción oficial al proyecto que profundiza dbt-analytics-engineering-guide. docs.getdbt.com/docs/introduction. En inglés.
• Apache Airflow — documentación oficial, el punto de partida de airflow-and-declarative-orchestration-guide. airflow.apache.org/docs. En inglés.
• Apache Iceberg — documentación oficial, el punto de partida de lakehouse-and-iceberg-guide, y la referencia del time travel nativo que reemplaza el SCD-2 a mano de esta guía. iceberg.apache.org/docs/latest. En inglés.
• Databricks — "What is the medallion lakehouse architecture?" — el marco que organizó el warehouse completo de esta guía, y el punto de partida natural hacia lakehouse-and-iceberg-guide y data-reliability-and-governance-guide. docs.databricks.com/aws/en/lakehouse/medallion. En inglés.