Busca en todas las páginas de la documentación
Las nuevas herramientas de Python (orquestadores, bases de datos vectoriales, frameworks) requieren puntas y pruebas de concepto disciplinadas antes de su adopción a nivel de flota. Los límites de tiempo, los criterios escritos y los resultados de las ADR evitan el desarrollo impulsado por el currículum y las sorpresas en producción.
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
# Carta de Puntas
**Pregunta:** ¿Puede Polars reducir el tiempo de ETL en un 50% en el mart de pedidos?
**Límite de tiempo:** 3 días (finaliza el viernes al final del día)
**Propietario:** @data-eng
**Éxito:** tiempo de ejecución del trabajo de staging < 12 min (línea base 25 min)
**No objetivos:** cambio a producción, refactorización completa
**Salida:** README en `spikes/2026-07-polars/` + borrador de ADR de recomendaciónCuándo usar esto:
# spikes/2026-07-polars/README.md
## Resultado: Adoptar para nuevos marts; no reescribir el legado todavía
| Criterio | ¿Cumplido? |
| Mejora del 50% en el tiempo de ejecución | sí (22→10 min) |
| El equipo puede mantener | sí (2 ingenieros capacitados) |
| Costo operativo aceptable | sí (mismo tamaño de trabajo K8s) |
| Modos de fallo entendidos | parcial - documentar pico de memoria en uniones amplias |
## Próximos pasos
- ADR-021 adoptar Polars para nuevas canalizaciones
- Ticket: añadir Polars a la cookiecutter de la plataforma de datos
- Pruebas de concepto de endurecimiento NO realizadas - la producción necesita ticket de observabilidad# spikes/2026-07-polars/benchmark.py - script de evidencia mínimo
import time
import polars as pl
start = time.perf_counter()
df = pl.scan_parquet("sample.parquet").group_by("tenant_id").len().collect()
print(f"rows={df.height} elapsed={time.perf_counter() - start:.2f}s")Lo que esto demuestra:
spikes/.| Dimensión | Pregunta |
|---|---|
| Operabilidad | ¿Guardia a las 3am? |
| Seguridad | Historial de CVE, cadena de suministro |
| Contratación | ¿Podemos reclutar la habilidad? |
| Costo de salida | Severidad del bloqueo |
| Ajuste | Compatibilidad con Python 3.14 |
La carpeta spikes/ está ignorada por git para datos grandes; solo confirma README + scripts| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Comprar SaaS | Capacidad de producto básico | Diferenciador principal |
| No hacer nada ADR | La punta muestra una ganancia insuficiente | Reemplazo de emergencia de CVE |
| Soporte de PoC del proveedor | Gran acuerdo | Pequeño experimento |
| Herramienta interna siempre en punta | Nunca - decidir adoptar/rechazar |
La punta responde a una pregunta técnica; la prueba de concepto demuestra el valor del producto, puede ser más larga pero aún así con límite de tiempo.
Líder técnico + plataforma + seguridad para herramientas de infraestructura; EM para impacto en el cronograma.
Incluir conjunto de evaluación, modelo de costos y residencia de datos antes del piloto.
Alto - documentar por qué no; ahorra tiempo futuro.
Limitar el trabajo en curso por escuadrón; las puntas cuentan para la planificación de capacidad.
Verificar el factor autobús, la cadencia de lanzamiento, la respuesta a CVE en la tabla de evaluación.
Requeriría evidencia extraordinaria; la punta compara el tiempo de CI y la compatibilidad de bloqueo.
Solo piloto con indicador, monitorización de SLO y reversión - no sombra silenciosa para siempre.
Solo se fusionan patrones/pruebas; los scripts desechables permanecen en spikes/ o se eliminan.
Estimación y Riesgo utiliza los resultados de las puntas.
Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.
Revisado por Chris St. John·Última actualización: 16 jul 2026