Resumen
El episodio 15 de enCoders presenta Kedro, una librería de Python que impone una estructura estándar a los proyectos de datos para facilitar su puesta en producción. Los anfitriones recorren un tutorial: crear el proyecto, configurar el ambiente virtual, el catálogo de datos, los pipelines y nodos, los parámetros, el versionado de modelos, Kedro Viz y la documentación automática. Valoran el catálogo de datos, la carpeta de configuración, la separación de parámetros y credenciales, y la visualización del flujo. Critican que solo funcione con Python, que depure con dificultad y que las empresas lo impongan. Concluyen que Kedro conviene después del trabajo exploratorio previo, cuando ya se sabe qué funciones y transformaciones se necesitan, y que es útil conocerlo y usarlo cuando aplique. Uno de los participantes no lo recomienda como herramienta general.
Capítulos
- 00:00IntroSe presenta Kedro como librería de Python que estandariza proyectos y facilita pasar a producción. Los participantes dan opiniones: les gusta el catálogo y las buenas prácticas, pero critican que solo use Python y que una empresa grande lo imponga. Mencionan alternativas (Metaflow, Cookie Cutter, un flujo propio) y debaten el costo de mantener herramientas internas sin equipo de soporte.
- 09:59Creando un proyecto en Kedro y estructura baseSe instalan `kedro` y `kedro-viz` con pip y se crea un proyecto con `kedro new`. Se explican las carpetas: `conf` (con `base` y `local` para credenciales), `data` (raw, intermediate, primary, feature, reporting), `docs`, `logs`, `notebooks` y `src` (con pipelines, tests, requirements y setup). Se discute si `src` y `docs` son necesarias y qué es lo mínimo de una buena estructura (conf, data y código en subcarpetas).
- 23:54Ambiente virtualSe crea un ambiente virtual con `virtualenv`, se activa en ambas terminales y se instalan las dependencias con `pip install -r` desde `requirements.txt`.
- 25:24Catálogo de datosEn `conf/base/catalog` se declaran los datasets una sola vez y se referencian luego por nombre. Se critica la línea `type` porque ata el proyecto a Python, aunque se reconoce que soporta muchos formatos (CSV, Excel, Parquet) y argumentos como `load_args`. Con `kedro ipython` se accede a variables globales como `catalog`, `context` y `session`, y `catalog.list()` muestra los datasets. Se insiste en usar rutas relativas y se menciona `PartitionedDataset` para cargar muchos archivos de una carpeta.
- 32:57Pipelines, nodos y outputs "efimeros" o "permanentes"Se crea el pipeline `data_processing` con `kedro pipeline create`. Los nodos son funciones con input y output (preprocess companies y preprocess shuttles). Los outputs no declarados en el catálogo son efímeros y se descartan al terminar; si se declaran, se guardan (por ejemplo, como parquet). Se muestra `kedro run`, `--node` y `--pipeline`. Se debate si Kedro sirve al inicio de un proyecto o solo después del trabajo exploratorio.
- 01:14:08MemesSe comentan memes sobre automatizar tareas que no valía la pena automatizar y otro sobre que construir pipelines es más difícil que el ML. Hay desacuerdo sobre cuándo conviene automatizar. Hacia el final de este tramo se discute el manifiesto ágil.
- 01:14:30Kedro vizSe agrega el nodo `create_model_input_table`, que une tres tablas en una y se guarda en `primary`. Luego `kedro viz` levanta un servicio local que muestra el flujo de datasets y funciones, con metadatos como tipo y ruta de archivo, y filtros.
- 01:17:12Nuevo pipeline y sus inputsSe crea el pipeline `data_science` con funciones para dividir datos, entrenar una regresión lineal y evaluarla con R². Se explican los inputs como lista, los outputs múltiples o `None` y los parámetros en `conf/base/parameters` (`params:model_options` con test size, random state y features). Se debate si anotar tipos en las funciones; la postura es que es buena práctica aunque Python no lo exija. Hay consenso en que centralizar los parámetros evita errores.
- 01:26:40Guardando outputs de modelosEl regresor se guarda en el catálogo como pickle, versionado, dentro de la carpeta `models`. Se ejecuta solo el pipeline de ciencia de datos. Se comenta que los `print` se pierden entre los muchos mensajes y que depurar un nodo es engorroso; se sugiere un script aparte o una sección de la documentación de Kedro sobre depuración.
- 01:35:02Pipelines de pipelinesSe definen dos pipelines con la misma plantilla de tres nodos pero con distintos parámetros, usando `namespace`, y se combinan. Se menciona poder correr en paralelo con ParallelRunner, ThreadRunner o SequentialRunner (el predeterminado). No está claro cómo elegir el diccionario de parámetros desde la línea de comandos.
- 01:38:31Documentación del proyectoSe genera la documentación con Kedro en `docs` y se explica que `kedro package` permite empaquetar un pipeline para reutilizarlo. La documentación en HTML describe módulos, pipelines, parámetros y retornos, de forma automática y genérica. Hubo problemas al mostrarla en vivo.
- 01:40:54CierreConclusiones: Kedro aporta estructura y sirve para automatizar flujos recurrentes más allá de modelos, pero limita a Python y dificulta la depuración. Se recomienda usarlo cuando el trabajo previo ya está hecho y conocerlo aunque no se use siempre. Se anticipa una comparación futura con otra herramienta.