El pipeline comienza desde el JSON dataset_hospital 2 AWS.json. Se propone el siguiente modelo por capas para asegurar limpieza, validación y entrega de tablas limpias.
Perfilado inicial con tipos estrictos y reportes tempranos.
Transformaciones guiadas por reglas documentadas.
Métricas y pruebas para gobernar cada entrega.
pd.read_json() apuntando a cada tabla y establecer tipos básicos (int, datetime, category) para reducir sorpresas.nombre, ciudad y especialidad.fecha_nacimiento; si la fecha falta, dejar edad como NaN y documentar la restricción.id_paciente y consolidar los registros con preferencia por los valores no nulos recientes.pandas.merge() para validar que cada id_paciente de citas exista en pacientes; los huérfanos se exportan a un CSV de discrepancias.estado_cita con un Enum (p.ej., {Completada, Cancelada, Reprogramada}).reports/metrics.json..csv o .parquet en carpetas con timestamp (por ejemplo: outputs/pacientes/).pytest y Great Expectations para cubrir: tipos contrato, integridad referencial, no null en campos críticos.id_paciente es clave primaria y no se debe duplicar a menos que se consoliden datos.rules.yaml para mantener trazabilidad.Archivo JSON (descargado manual o desde S3). Un script Python programado (cron o Airflow) lee el fichero, lo valida y escribe tablas intermedias.
Pandas + Great Expectations + funciones propias (p.ej., validate_citas()). Se registra cada transformación y se generan reportes HTML/JSON.
Versionamiento en carpetas organizadas por fecha en el repositorio (outputs/{tabla}/{timestamp}/) o en un bucket de datos si se escala.
Métricas de calidad almacenadas en reports/metrics.json y dashboards con Power BI o herramientas open source usando csv/parquet generados.
Airflow o Prefect para encadenar pasos: ingestión → limpieza → validaciones → exportación → pruebas automáticas.
Exportar datasets limpios, reportes y pruebas en un ZIP, junto al informe PDF para cumplir con requisitos de la prueba técnica.
Comandos clave para refrescar métricas, artefactos y reportes HTML tras cada carga.
Esta propuesta se puede implementar como script monolítico o a través de notebooks modulares, siempre dejando artefactos (logs, métricas) que respalden las decisiones.