Nueva versión
Comparte tu experiencia y sugerencias sobre nuestro servicio.
SOPORTE
ÚLTIMA ACTUALIZACIÓN
En los casos en los que la solución de explotación del dato elegida (arquitectura, herramientas, fuentes, modelos analíticos o mecanismos de visualización) no haya sido acordada en el contrato, la empresa desarrolladora deberá argumentar el uso de la misma desde el punto de vista funcional, técnico, operativo y de mantenimiento, y será necesario el visto bueno de la persona responsable del proyecto por parte del Cabildo de Tenerife.
Toda solución de explotación del dato deberá diseñarse teniendo en cuenta, al menos, los siguientes principios:
- Reutilización de fuentes y componentes ya existentes, siempre que resulte viable.
- Separación entre las capas de ingesta, transformación, almacenamiento y consumo.
- Trazabilidad completa del dato desde su origen hasta su explotación final.
- Definición explícita de reglas de negocio, transformaciones y cálculos aplicados.
- Calidad del dato, mediante la aplicación de reglas de validación.
- Seguridad y control de acceso acordes con la naturaleza de la información tratada.
- Facilidad de mantenimiento, evolución y soporte de la solución implantada.
Herramientas corporativas
Con carácter general se hará uso de las siguientes herramientas, empleando las últimas versiones estables salvo que desde el Cabildo se indique otra recomendación:
- Plataforma de datos
Microsoft Fabric (con OneLake como lago de datos)
- Análisis y visualización de cuadros de mando
Microsoft Power BI
- Gobierno y catalogación
Microsoft Purview
- Conexión segura a fuentes corporativas
Data Gateway (on-premises), cuando sea necesario conectar los entornos de análisis con fuentes de datos internas del Cabildo de Tenerife
- Lenguaje de desarrollo de ETLs
Python (notebooks Spark de Fabric)
Lenguaje de desarrollo
Las ETLs deberán ser desarrolladas en Python, favoreciendo así su reutilización futura, la portabilidad del código y el aprovechamiento del ecosistema de notebooks Spark de Microsoft Fabric.
-
Se priorizará el uso de PySpark para el procesamiento distribuido sobre tablas Delta en OneLake.
-
La lógica transversal (validaciones, normalizaciones, utilidades de logging, gestión de watermarks, etc.) se centralizará en notebooks o módulos reutilizables invocables desde el resto de procesos, evitando la duplicación de código entre proyectos.
-
El código se escribirá siguiendo un estilo consistente, con funciones pequeñas, con responsabilidad única y adecuadamente documentadas.
Arquitectura de almacenamiento: medallón (Lakehouse)
El almacenamiento seguirá una arquitectura medallón sobre almacenes de lago (Lakehouse) en OneLake, organizada en tres capas de calidad creciente. Cada capa tiene una responsabilidad única y no deben producirse saltos de capa que dificulten la trazabilidad:
Nombre
Contenido