✅ 1. SOP BDS – Data Intake & Profiling (texto listo para Word)

Propietario: Oficina de Entrega BDS Aplicación: Todos los proyectos CRISP-DM

⁠

I. Objetivo

Estandarizar la recepción, validación, perfilamiento y diagnóstico de calidad de datos provenientes de clientes, sin importar el formato (Excel, CSV, TXT, JSON, JSONL, Parquet, Feather o ZIP), garantizando:

Velocidad en el entendimiento inicial.

Eliminación de retrabajos y ciclos de corrección.

Trazabilidad y reproducibilidad de análisis.

Alineación con prácticas de fábrica analítica en BDS.

⁠

II. Alcance

Este procedimiento se utiliza desde la entrega del primer archivo hasta su validación formal para continuar a la fase de Data Understanding de CRISP-DM.

Cubre:

Intake de datos en múltiples formatos.

Validación estructural y semántica.

Perfilamiento automático.

Generación de reportes HTML y hallazgos.

Comunicación con cliente.

⁠

III. Roles involucrados

Data Intake Owner (DIO): ejecuta pipeline, documenta hallazgos.

Data Engineer: confirma integridad, schemas y normalización.

Data Scientist: revisa descripciones y riesgos para modelado.

Project Manager: comunica hallazgos al cliente (<2 horas).

Cliente: corrige archivos y valida el data contract.

⁠

IV. Proceso estándar

1. Handshake previo

Definir tipos de archivo permitidos: .xlsx, .xls, .csv, .tsv, .txt, .json, .jsonl, .parquet, .feather, .zip.

Solicitar delimitador estándar para archivos planos o indicación explícita si no es estándar.

Acordar codificación esperada: UTF-8, Latin-1, CP1252 (crítico para bancos).

Compartir ejemplo mínimo (200 filas) por cada formato.

Documentar schema esperado, incluso si el archivo no tiene encabezado.

Definir naming convention homogénea sin importar el formato.

Alinear diccionario de datos y revalidar llaves, granularidad y lógica de negocio.

⁠

2. Recepción del archivo (detector de formato automático)

El pipeline debe:

Detectar tipo de archivo.

Seleccionar el lector adecuado.

Unificar encabezados y codificación.

Perfilar y validar en menos de 1 minuto.

⁠

3. Exploración estructural para cualquier formato

¿Los encabezados y metadatos (incluyendo BOM) son detectables y están correctamente formados?

¿El delimitador y las reglas de separación (comillas, escapes) son consistentes en todas las filas?

¿Todas las filas mantienen la misma cantidad de columnas sin rupturas por saltos o comillas mal balanceadas?

¿Las estructuras jerárquicas o anidadas (JSON/JSONL) están completas y son normalizables?

¿El schema declarado o inferido (tipos, nombres, orden) coincide con lo esperado para el archivo?

¿Los formatos binarios (parquet/feather) presentan un schema íntegro, compatible y libre de columnas inesperadas?

Si el archivo es un ZIP, ¿contiene únicamente los archivos tabulares esperados y está claramente identificado el archivo principal?

⁠

4. Perfilamiento automático

Descriptivas numéricas

count

mean, std

min, 25%, 50%, 75%, max

número de ceros

% de nulos

coeficiente de variación

outliers (IQR y Z-score)

Descriptivas categóricas

Cardinalidad

Top 20 categorías y su frecuencia

Categorías con menos de 5 registros (riesgo ML)

Texto libre con distribución de longitud

Detección de valores atípicos (“NA”, “.”, “?”, “null”, “n/a”)

Validación de fechas y rangos

Rango de fechas

Huecos y saltos inesperados

Registros fuera de ventana de negocio

Estacionalidad rápida (conteo por día/semana/mes)

Detectar saltos, baja calidad y ruido

⁠

5. Reportes entregables

El sistema genera automáticamente:

Reporte HTML (reporte_bds_universal.html)

Log de problemas (quality_log.json)

Diccionario inferido (schema_detected.json)

⁠

6. Comunicación con cliente (< 2 horas)

Enviar:

Lista de errores detectados.

Recomendaciones de corrección.

Confirmación de si el archivo “pasa/no pasa” para modelado.

⁠

7. Cierre de Intake

Publicar reporte final en /data/processed/.

Notificar al equipo DS/DE que el archivo está validado.

Continuar con Data Understanding y Data Preparation.

⁠

V. Criterios de aceptación

Un archivo queda aprobado SI:

Estructura coincide con contrato.

Columnas clave están presentes.

Tipos son correctos.

No hay anomalías críticas.

Outliers y nulos están dentro de tolerancia.

Llaves primarias son únicas.

⁠

VI. Anexos

Incluye:

Tablas de problemas comunes por tipo de archivo.

Matriz de severidad (High/Medium/Low).

Instructivo del CLI.

⁠

✅ 2. Repositorio GitHub – Estructura recomendada

bds-data-intake/

│

├── README.md

├── requirements.txt

├── setup.py

│

├── bds_profile/

│ ├── __init__.py

│ ├── cli.py

│ ├── loaders.py # lectura agnóstica

│ ├── profiler.py # descriptivas + ydata profiling

│ ├── quality.py # reglas de calidad

│ ├── utils.py

│

├── data/

│ ├── raw/

│ ├── processed/

│ └── reports/

│

└── examples/

├── archivo.csv

├── archivo.xlsx

└── archivo.json

⁠

✅ 3. Script CLI profesional bds_profile

Instalación

En el repositorio:

pip install -e .

Esto crea el comando global:

bds_profile archivo.ext

⁠

Código del CLI (listo para pegar)

# cli.py

import click

from .loaders import load_file

from .profiler import generate_profile

from .quality import run_quality_checks

@click.command()

@click.argument("path")

def main(path):

click.echo(f"📁 Cargando archivo: {path}")

df = load_file(path)

click.echo(f"✔ Archivo cargado: {df.shape[0]} filas, {df.shape[1]} columnas")

issues = run_quality_checks(df)

click.echo("🔍 Problemas detectados:")

for k, v in issues.items():

click.echo(f" - {k}: {v}")

report_path = generate_profile(df, path)

click.echo(f"📊 Reporte generado en: {report_path}")

click.echo("🚀 Intake completado.")

if __name__ == "__main__":

main()

⁠

✅ 4. Metodología institucional BDS – Data Intake Framework

Principio rector

Cero retrabajos. Cero ambigüedad. Cero conjeturas. Solo datos bien entendidos permiten modelos robustos.

⁠

Pilares

Estandarizar: data contracts, naming, codificación.

Automatizar: ingestión, perfilamiento y QA estructural.

Centralizar: repositorio unificado con versionado.

Desambiguar: validación inmediata con cliente.

Trazar: logs de cambios y problemas.

Acelerar: tiempos de ciclo bajo una hora.

Industrializar: convertir scripts en activos BDS reutilizables.

⁠

Ciclo operativo tipo fábrica

Input: archivo llega → webhook → pipeline.

Procesamiento: lectura, normalización, perfilamiento.

QA: validaciones estructurales + semánticas.

Output: HTML + logs + schema inferido.

Feedback: cliente corrige en la misma ventana diaria.

Liberación: archivo aprobado para modelado.

Integración: DS/DE consumen datos en notebooks o pipeline ETL.

⁠

Métricas clave (KPIs BDS Intake)

Cycle Time Intake: < 60 minutos.

Retrabajo neto: < 5 %.

Porcentaje de archivos aceptados al primer intento: > 70 %.

Tiempo de respuesta al cliente: < 2 horas.

Errores críticos detectados automáticamente: 100 %.

Trazabilidad completa: 100 % de archivos versionados.

⁠

https://chatgpt.com/share/69330581-5674-8003-96ae-b4dd0917ad84⁠

⁠

descriptivas_de_Excel.py

8.4 kB

⁠

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.

Standard Operating Procedure (SOP) – Data Intake & Profiling