Métodos · Tema T6

Cómo se debe estructurar el ciclo de vida de un proyecto de datos a escala

Revisado el 18 de octubre de 2026

Se imprime completa desde el navegador, en A4 o en carta.

Bloque 1

El problema

Diseñar una plataforma de datos y el ciclo de vida de lo que corre en ella para que crezca por integraciones sin multiplicar copias, sin mezclar clientes y sin llevar a producción cambios que nadie probó.

Síntesis en tres líneas

Se empieza por el recorrido del dato y sus consumidores, no por los componentes: de dónde llega, qué transformación le falta para ser confiable y quién lo consume, con qué motor —personas, aplicaciones o agentes—. Así se diseñó desde cero la plataforma de datos de Vesting en Microsoft Fabric.
Lo común se separa de lo configurable: un contrato de eventos y una normalización temprana para que todo hable el mismo idioma, capas que avanzan de la recepción al consumo, una sola copia del dato en formato abierto y el aislamiento como propiedad de la arquitectura —un workspace por cliente—, no como un filtro.
El ciclo de vida no termina al publicar: desarrollo, prueba y producción separados, cambios versionados y promovidos entre ambientes, una conciliación que detiene la publicación si una cifra no cuadra y el retiro de lo que dejó de responder a una necesidad.

Bloque 2

El mapa

De la fuente a quien decide, y del cambio a producción

Desliza para ver el mapa completo.

Leyenda de formas y colores

Actor — quien hace el trabajo
Dato — lo que se guarda y se lee
Control — una regla que se comprueba
Persona — una persona decide
Externo — lo que viene de afuera

Lectura del mapa, nodo por nodo

Las integraciones entregan eventos que deben cumplir un contrato: campos obligatorios, identificadores de contexto y estados comunes. La recepción conserva el evento crudo, la preparación lo valida y lo normaliza, y las tablas de consumo lo sirven en una sola copia, en formato abierto. El modelo semántico gobernado es la definición que leen quienes deciden y también las aplicaciones y los agentes, que consultan la medida en vez de reinterpretar la tabla cruda. Cada cliente tiene su propio workspace sobre las mismas estructuras. Lo que no cuadra al usar el dato llega a la observación y al linaje, que piden un cambio: el cambio nace en desarrollo, pasa una prueba de conciliación y un pipeline de despliegue lo promueve a producción.

Nodo 1 Fuentes e integraciones (Externo) — Lo que produce los eventos: en Vesting, las integraciones de los agentes y los flujos que los orquestaban.
Nodo 2 Contrato de eventos (Control) — Campos obligatorios, identificadores de contexto y estados comunes; lo que no cumple se ve en el ingreso.
Nodo 3 Recepción: el evento crudo (Dato) — El lakehouse conserva el detalle de cada sesión para reconstruir lo que pasó.
Nodo 4 Preparación y calidad (Control) — Validaciones dentro del pipeline: faltantes, tipos inesperados, duplicados y relaciones que no cierran.
Nodo 5 Tablas para el consumo (Dato) — Estructuras relacionales y agregados para preguntas predecibles, en una sola copia y en formato abierto.
Nodo 6 Semántica gobernada (Dato) — Relaciones, medidas y seguridad por fila: la definición que todos consumen.
Nodo 7 Quien decide (Persona) — Producto, operaciones y líderes de proceso: leen tableros sobre el mismo significado.
Nodo 8 Aplicaciones y agentes (Actor) — Consumidores nuevos: leen la medida gobernada en vez de reinterpretar la tabla cruda.
Nodo 9 Un workspace por cliente (Control) — El límite de acceso coincide con el límite del cliente, sobre las mismas estructuras comunes.
Nodo 10 Cambio en desarrollo (Dato) — Toda modificación nace en su ambiente de desarrollo, versionada.
Nodo 11 Prueba y conciliación (Control) — La cifra clave del modelo nuevo debe coincidir con la del vigente y con la fuente.
Nodo 12 Pipeline de despliegue (Control) — Promueve el cambio de un ambiente al siguiente, con una forma de volver a la versión anterior.
Nodo 13 Observación y linaje (Control) — Del tablero al modelo, a la tabla y al pipeline: quién responde por cada activo, qué depende de él y qué ya no responde a una necesidad y se retira.

Conexiones

de Fuentes e integraciones a Contrato de eventos (entrega)
de Contrato de eventos a Recepción: el evento crudo (cumple)
de Recepción: el evento crudo a Preparación y calidad
de Preparación y calidad a Tablas para el consumo (normaliza)
de Tablas para el consumo a Semántica gobernada
de Semántica gobernada a Quien decide (decide)
de Semántica gobernada a Aplicaciones y agentes (consulta)
de Un workspace por cliente a Recepción: el evento crudo (aísla)
de Quien decide a Observación y linaje (lo que no cuadra)
de Observación y linaje a Cambio en desarrollo (pide un cambio)
de Cambio en desarrollo a Prueba y conciliación
de Prueba y conciliación a Pipeline de despliegue (cuadra)
de Pipeline de despliegue a Preparación y calidad (promueve)

Bloque 3

Las fases

1
Fase 1
Mapear el recorrido del dato y sus consumidores
Entradas
- El proceso, las preguntas y las decisiones que el dato debe sostener.
- Las fuentes y sus integraciones.
Actividades
- Identificar quién consume cada dato y con qué motor: SQL, Spark, el modelo semántico o un agente.
- Decidir qué nivel de detalle se conserva y con qué frecuencia se necesita.
- Nombrar, para cada dato, la copia que será la referencia.
Artefactos
- El mapa del recorrido, de la fuente a cada consumidor.
Quién decide
Quien responde por la plataforma de datos.
Control que cierra la fase
Si la respuesta a «cuál copia es la referencia» es «varias», la arquitectura todavía no está terminada.
Evidencia
Antes de crear un artefacto en Fabric, la práctica del autor es responder tres preguntas: quién va a consumir este dato y con qué motor, qué transformación le falta para ser confiable y cuál de las copias posibles será la referencia.
2
Fase 2
Fijar el contrato de eventos y normalizar en el ingreso
Entradas
- Los eventos que trae cada integración.
- Las entidades comunes: sesión, solicitud, respuesta, estado.
Actividades
- Definir campos obligatorios e identificadores de contexto que viajan desde el primer evento.
- Validar la estructura en el ingreso y hacer visibles las excepciones.
- Separar lo común, que permite comparar, de lo configurable, que permite no frenar.
Artefactos
- El contrato de eventos.
- Una representación común de los eventos.
Quién decide
Quien diseña la plataforma, con producto.
Control que cierra la fase
Un cambio en la estructura de eventos se valida en la recepción antes de tocar un modelo semántico.
Evidencia
En Vesting, un agente o un cliente nuevo no podía requerir una tabla nueva para lo que ya tenía nombre en la plataforma; con 27 agentes y 12 clientes, la normalización temprana fue la decisión clave de la arquitectura.
3
Fase 3
Diseñar las capas y servir una sola copia
Entradas
- Los eventos normalizados.
- Las cargas de trabajo: Spark, SQL y el modelo semántico.
Actividades
- Conservar el detalle en la recepción y avanzar por capas cada vez más confiables, con reglas de calidad.
- Asignar cada carga al motor adecuado: el lakehouse para ingeniería y Spark, el warehouse para lo relacional y T-SQL.
- Aislar por cliente con workspaces separados sobre las mismas estructuras.
Artefactos
- El lakehouse con el detalle y las tablas de consumo.
- Un workspace por cliente.
Quién decide
Quien diseña la plataforma.
Control que cierra la fase
Cada transformación tiene un lugar y una referencia: ni el dato ni la lógica se duplican sin razón.
Evidencia
En Vesting, separar recepción, preparación y consumo permitía que una integración nueva entrara sin tocar las anteriores: la recepción absorbía la variación de cada agente y, desde la preparación, todo hablaba el mismo idioma.
4
Fase 4
Modelar el significado para personas, aplicaciones y agentes
Entradas
- Las tablas de consumo.
- Las definiciones acordadas con el negocio.
Actividades
- Construir el esquema en estrella, las medidas y la seguridad por fila, probada suplantando roles antes de publicar.
- Elegir el modo de almacenamiento por la frescura, el volumen y el costo que pide cada uso.
- Decidir qué lee un agente: la medida gobernada o la tabla, con su interpretación escrita.
Artefactos
- El modelo semántico gobernado.
Quién decide
El negocio acuerda la definición; la plataforma la convierte en regla.
Control que cierra la fase
Una medida crítica no se recalcula libremente: quien la consume la lee del modelo.
Evidencia
Cuando dos personas llegan con cifras distintas para el mismo indicador, el problema se resuelve en la semántica y en la definición acordada, no en la visualización; en Banco Pichincha un indicador con dos definiciones era un problema de gobierno antes que de DAX.
5
Fase 5
El ciclo de vida en Microsoft Fabric: desarrollo, prueba y producción separados
Entradas
- El cambio que se quiere publicar.
- El activo vigente y quién depende de él.
Actividades
- Versionar el modelo semántico como proyecto, en un repositorio Git.
- Promover el cambio entre workspaces separados por ambiente con pipelines de despliegue.
- Conciliar la cifra clave: el modelo nuevo, el vigente y la fuente tienen que coincidir.
- Conocer qué personas, procesos o productos dependen del activo antes de cambiarlo.
Artefactos
- El cambio versionado y su razón.
- La conciliación registrada.
Quién decide
Quien responde por el activo.
Control que cierra la fase
Una diferencia que no se explica detiene la publicación.
Estado del campo
Microsoft arma el CI/CD de Fabric con la integración con Git y con pipelines de despliegue entre etapas de desarrollo, prueba y producción; como cada uno liga un workspace a un ambiente, aconseja un workspace por ambiente.^[6]^[7]
6
Fase 6
Observar, optimizar y retirar
Entradas
- El uso real y la capacidad consumida.
- Los activos publicados y su linaje.
Actividades
- Recorrer el linaje del tablero al modelo, a la tabla y al pipeline que la cargó.
- Intervenir primero en la capa donde nace el desperdicio, no en la última.
- Retirar lo que dejó de responder a una necesidad, avisando a sus consumidores.
Artefactos
- El linaje y la decisión de retiro.
Quién decide
Quien responde por la plataforma.
Control que cierra la fase
Ningún activo queda vigente en apariencia: o tiene consumidores y responsable, o se retira.
Estado del campo
Fabric reparte el consumo de cada operación en el tiempo —las interactivas en un mínimo de cinco minutos, las de fondo en 24 horas— y, si la capacidad se sobrecarga, primero retrasa 20 segundos las operaciones interactivas nuevas y después las rechaza.^[9]

Bloque 4

Las decisiones de diseño

Lo común y lo configurable en la plataforma de datos de Vesting
Cuándo sí
Común: los eventos fundamentales, los identificadores, los estados y las métricas, con definiciones compartidas que permiten comparar.
Cuándo no
Configurable: los atributos propios de cada cliente o agente, dentro de una estructura que ya sabe recibirlos y sin rediseñar la plataforma.
Por qué
Evidencia
La plataforma de datos de Vesting se diseñó con el nivel mínimo de estandarización que conservara la agilidad de la startup sin renunciar a la trazabilidad ni a la calidad.
Criterio
Lo común es la condición de comparar; lo configurable, la condición de no frenar.
Capas progresivas o un solo paso
Cuándo sí
Capas, cuando hay varias fuentes, reglas de calidad que aplicar y consumidores distintos que deben leer lo mismo.
Cuándo no
Un paso directo, cuando la fuente ya llega limpia, la consume una sola pregunta y otra capa solo agregaría copias y latencia.
Por qué
Estado del campo
La documentación de Azure Databricks presenta la arquitectura medallion —bronce, plata y oro— como una práctica recomendada, pero no como un requisito; Microsoft la llama el enfoque de diseño recomendado para Fabric.^[4]^[3]
Criterio
Las capas no son un dogma: cada una tiene que agregar valor sin perder trazabilidad, y la que no agrega nada sobra.
Lakehouse, warehouse o los dos
Cuándo sí
Los dos, cuando hay una razón funcional: el lakehouse para conservar y transformar eventos con mucho detalle; el warehouse para relaciones, métricas y consultas predecibles.
Cuándo no
Los dos por si acaso, sin una regla sobre dónde ocurre cada transformación ni cuál copia es la referencia.
Por qué
Evidencia
En Vesting el lakehouse conservaba los eventos de los agentes —sesión, solicitud, respuesta, tiempo, estado, costo— y el warehouse organizaba lo que pedían los tableros de producto y operaciones.
Estado del campo
En OneLake los motores de Fabric —T-SQL, Spark, Analysis Services— guardan las tablas en Delta Parquet, de modo que el mismo dato se lee con otro motor sin copiarlo.^[1]
Aislar por cliente: un workspace propio o un filtro en el modelo
Cuándo sí
Un workspace por cliente, cuando el límite de acceso debe coincidir con el límite del cliente y un cambio en uno no puede tocar a otro.
Cuándo no
Solo un filtro de seguridad por fila, cuando todos los datos tienen un mismo dueño y un filtro mal escrito es un riesgo aceptable.
Por qué
Evidencia
En Vesting el aislamiento entre los 12 clientes se resolvió con workspaces separados sobre las estructuras de eventos comunes: el límite no dependía de un filtro bien escrito.
Evidencia
La seguridad por fila seguía en el modelo, definida como filtros DAX sobre las dimensiones y probada suplantando roles antes de publicar.
Copiar el dato o leerlo donde está
Cuándo sí
Leerlo donde está, con un atajo o un espejado, cuando la fuente ya está en un formato abierto o en otro workspace y la frescura importa.
Cuándo no
Copiarlo, cuando la fuente necesita una disposición optimizada para consultas o no cumple lo que se le pide sin copia.
Por qué
Estado del campo
Microsoft recomienda los atajos para incluir un dato sin copiarlo y propone espejar una fuente una sola vez para que los demás workspaces la consuman con atajos, sin crear otra copia.^[2]
Criterio
Cada copia necesita una razón escrita: la copia sin razón es la que mañana dice otra cifra.
Direct Lake, importación o DirectQuery
Cuándo sí
Direct Lake para lo que debe verse al momento sobre tablas Delta; importación para el histórico agregado; DirectQuery para el detalle que no cabe en memoria y se consulta poco.
Cuándo no
Un solo modo para todo el modelo, cuando hay preguntas de distinta frescura, volumen y costo.
Por qué
Evidencia
En Vesting un mismo modelo combinaba los tres modos: Direct Lake para el monitoreo operativo, importación para el histórico y DirectQuery para bajar a los eventos de una sesión.
Estado del campo
Microsoft separa Direct Lake sobre OneLake, que no recurre a DirectQuery y es la opción recomendada para modelos nuevos, de Direct Lake sobre el punto de conexión SQL, que sí puede caer en DirectQuery y volverse más lento.^[8]

Bloque 5

Lo innovador en 2026

Estado del campo
Una sola copia en OneLake, en Delta o en Iceberg
Qué cambia frente a la práctica común
OneLake virtualiza los metadatos entre formatos abiertos: una tabla Iceberg se lee como Delta en Fabric y una Delta se lee con lectores Iceberg, sin conversión manual; cuando una conversión falla o descarta una columna, lo deja en un registro.^[1]^[13]
Evidencia
En Vesting las tablas vivían en Delta sobre OneLake y el modelo las leía desde ahí; Apache Iceberg salió de la lista de herramientas del autor por no haberse usado.
Estado del campo
Atajos y espejado: leer el dato donde está
Qué cambia frente a la práctica común
Los atajos hacen que datos de otro workspace, de otra nube o de otro lago aparezcan en OneLake sin copiarlos; el espejado replica una base operativa como tablas Delta o sincroniza solo un catálogo externo, y Microsoft propone espejar una vez y consumir en todas partes.^[1]^[2]
Criterio
Antes de copiar, conviene preguntar si un atajo basta: menos copias son menos cifras que pueden contradecirse.
Estado del campo
Capas declarativas con vistas materializadas del lakehouse
Qué cambia frente a la práctica común
Las vistas materializadas del lakehouse, definidas en Spark SQL o —en versión preliminar y solo con actualización completa— en PySpark, expresan como declaraciones las transformaciones de bronce a plata y a oro: Fabric sigue sus dependencias, las refresca en orden y aplica reglas de calidad en cada etapa; Microsoft advierte que no sirven para lógica que no es SQL ni para flujos que piden actualizaciones de menos de un segundo.^[5]
Evidencia
Las reglas de calidad viven dentro de los pipelines: faltantes, tipos inesperados, duplicados y relaciones que no cierran se ven antes de llegar al modelo.
Estado del campo
CI/CD de Fabric: Git, pipelines de despliegue y variables por etapa
Qué cambia frente a la práctica común
El CI/CD de Fabric junta la integración con Git, los pipelines de despliegue entre desarrollo, prueba y producción, una biblioteca de variables con valores por etapa y un plan de despliegue que fija el orden en que se despliegan los elementos.^[6]
Evidencia
El modelo semántico se versiona como proyecto —con Tabular Editor o en formato PBIP, en un repositorio Git— para comparar un cambio y volver a la versión anterior sin reconstruir nada a mano.
Estado del campo
El agente de datos de Fabric sobre el modelo gobernado
Qué cambia frente a la práctica común
Un agente de datos de Fabric responde en lenguaje natural sobre lakehouses, warehouses, modelos semánticos y bases KQL: genera solo consultas de lectura, con las credenciales y los permisos de quien pregunta, y sus respuestas se limitan a 25 filas y 25 columnas.^[10]
Evidencia
Un agente que lee una medida gobernada hereda su definición; uno que lee una tabla cruda hereda la obligación de interpretarla, y esa obligación tiene que estar escrita en alguna parte.
Estado del campo
Fabric y Databricks: un puente entre catálogos
Qué cambia frente a la práctica común
Muchas organizaciones registran sus datos en Unity Catalog, dentro de Azure Databricks; Fabric puede espejar ese catálogo sin mover ni replicar los datos —solo copia la estructura y los lee por atajos—, de modo que lee las mismas tablas sin copiarlas, con cambios que pueden tardar de segundos a minutos en verse.^[11]
Evidencia
En el perfil del autor, Databricks y Snowflake figuran como prototipo; Microsoft Fabric es la plataforma usada de extremo a extremo, en Vesting.
Estado del campo
El DP-600 que se evalúa a partir del 19 de octubre de 2026
Qué cambia frente a la práctica común
La guía del DP-600 pide configurar el control de versiones de un workspace, crear pipelines de despliegue, analizar el impacto sobre lo que depende de un lakehouse o de un modelo y elegir entre Direct Lake sobre OneLake y sobre el punto de conexión SQL.^[12]
Evidencia
El DP-600 se obtuvo en diciembre de 2024, dentro del rol del autor en Vesting, mientras se construía la plataforma que el temario describe.

Bloque 6

Modos de falla y cómo anticiparlos

Qué se rompe
Cada integración trae su propia tabla
Cómo se ve venir
Un cliente o un agente nuevo obliga a reescribir pipelines y métricas que ya existían.
Control que la atrapa
Contrato de eventos y normalización temprana: lo que ya tiene nombre no se vuelve a modelar.
Qué se rompe
Dos cifras para el mismo indicador
Cómo se ve venir
Dos personas llegan a la reunión con resultados distintos para la misma métrica.
Control que la atrapa
Una definición acordada con su responsable, convertida en medida del modelo gobernado.
Qué se rompe
Una copia sin dueño se vuelve la verdad de alguien
Cómo se ve venir
Varias copias del mismo dato y nadie sabe cuál es la referencia.
Control que la atrapa
Una referencia por dato, una razón escrita para cada copia y atajos antes que copias.
Qué se rompe
Un cliente ve datos de otro
Cómo se ve venir
Un filtro mal escrito o un modelo compartido entre audiencias que no deberían cruzarse.
Control que la atrapa
Un workspace por cliente y seguridad por fila probada suplantando roles antes de publicar.
Qué se rompe
Un cambio publicado mueve una cifra en silencio
Cómo se ve venir
Un despliegue que termina bien y aun así produce otro total.
Control que la atrapa
Conciliación de la cifra clave contra el modelo vigente y la fuente; una diferencia sin explicación detiene la publicación.
Qué se rompe
La capacidad se agota y el tablero se vuelve lento
Cómo se ve venir
Operaciones interactivas retrasadas o rechazadas; consumo que sube sin que suban los usuarios.
Control que la atrapa
Intervenir en la capa donde nace el desperdicio antes de comprar más capacidad, y vigilar la capacidad compartida.
Qué se rompe
Un agente reinterpreta una tabla cruda
Cómo se ve venir
Respuestas con cifras que no coinciden con las medidas oficiales.
Control que la atrapa
El agente consulta la medida gobernada; la tabla cruda, solo con su interpretación escrita.
Qué se rompe
Un activo retirado sigue en uso
Cómo se ve venir
Reportes y modelos que nadie mantiene pero alguien sigue abriendo.
Control que la atrapa
Linaje para conocer a sus consumidores, aviso del cambio y retiro explícito.

Bloque 7

Métricas y controles

Qué se mide
Eventos que cumplen el contrato al ingresar
Umbral
Todos; el que no cumple se ve como excepción y no avanza en silencio.
Quién aprueba el paso a producción
Quien diseña la plataforma.
Qué se mide
Cifras clave conciliadas antes de publicar
Umbral
Modelo nuevo, modelo vigente y fuente coinciden; una diferencia sin explicación detiene la publicación.
Quién aprueba el paso a producción
Quien responde por el activo.
Qué se mide
Medidas críticas con una definición y un responsable
Umbral
Todas las que usan más de un reporte o un agente.
Quién aprueba el paso a producción
El responsable del negocio.
Qué se mide
Copias del mismo dato
Umbral
Una referencia por dato; cada copia adicional con su razón escrita.
Quién aprueba el paso a producción
Quien diseña la plataforma.
Qué se mide
Activos con consumidores y responsable conocidos
Umbral
Ninguno vigente sin dueño ni consumidores.
Quién aprueba el paso a producción
Quien responde por la plataforma.
Qué se mide
Uso de la capacidad compartida
Umbral
Por debajo del límite en promedio, con margen antes de que empiece la limitación.
Quién aprueba el paso a producción
Quien paga y administra la capacidad.
Qué se mide
Acceso entre clientes
Umbral
Ninguno: cada cliente en su workspace y la seguridad por fila probada antes de publicar.
Quién aprueba el paso a producción
Quien responde por los datos.

Los umbrales son ejemplos del método, no cifras de un proyecto concreto.

Bloque 8

Evidencia en proyectos

EvidenciaNivel: Uso real
Vesting: cómo se diseñó su plataforma de datos
Entre agosto de 2023 y enero de 2025 se diseñó e implementó en Vesting la plataforma de datos de una startup de agentes: 12 clientes integrados, 27 agentes en el inventario, 1.000 eventos por día, 120 tablas y 20 GB al cierre, con monitoreo en tiempo real de hasta 23 agentes a la vez.
Ver dónde
EvidenciaNivel: Uso real
La normalización temprana como decisión de arquitectura
Una representación común de los eventos desde el ingreso permitió métricas comparables entre los 27 agentes: el lakehouse conservaba el evento crudo y las capas siguientes lo convertían en sesión, solicitud, respuesta, agente y cliente.
EvidenciaNivel: Uso real
Lakehouse y warehouse sobre OneLake, con modos combinados
El lakehouse conservaba los eventos y permitía transformarlos con Spark, el warehouse servía en T-SQL lo que pedían los tableros, y los modelos combinaban Direct Lake, importación y DirectQuery según la frescura, el volumen y el costo.
EvidenciaNivel: Uso real
Gobierno desde el diseño: un workspace por cliente y seguridad por fila
Cada cliente con su workspace, sus permisos y sus modelos sobre las estructuras de eventos comunes; la seguridad por fila definida con filtros DAX y probada suplantando roles antes de publicar.
EvidenciaNivel: Uso real
Conciliar y versionar los modelos semánticos
En los modelos de Power BI del autor, el total de una medida clave en el modelo nuevo debe coincidir con el del vigente y con la fuente —tres cifras, una sola verdad—, y el modelo se versiona como proyecto en Git para volver atrás sin reconstruir nada.
EvidenciaNivel: Uso real
Separar desarrollo y producción en la Fundación CTIC
En la Fundación CTIC, con más de 25 productos analíticos en uso, separar los estados de una solución es lo que permite corregir un modelo sin que unos 75 usuarios vean una cifra a medias.
EvidenciaNivel: Uso real
Banco Pichincha: preparar con pasos separados
En 2023, reorganizar los procesos ETL con pasos separados de conexión, preparación y construcción de las tablas del modelo redujo un 35 % los tiempos de análisis.

Bloque 9

Límites y alcance

Evidencia
Eventhouse y KQL los conoce el autor a nivel de consulta, como SQL —el DP-600 exige trabajar con SQL, KQL y DAX—, no por un proyecto.
Evidencia
En el perfil del autor, Databricks y Snowflake figuran como prototipo; Airflow y PySpark, en estudio; el 27 de septiembre de 2026 dbt y Apache Iceberg salieron de su lista de herramientas por no haberse usado.
Evidencia
Esta publicación no describe experiencia con AWS ni con Redshift: la plataforma de datos de extremo a extremo de la evidencia es Microsoft Fabric, en Vesting.
Evidencia
La pieza pública de Fabric con datos abiertos de Colombia sigue en exploración: no se presenta como construida.
Criterio
Lo que conviene hacer distinto hoy: empezar los modelos nuevos con Direct Lake sobre OneLake y dejar DirectQuery solo para el detalle que no cabe en memoria.
Criterio
Entre Fabric y Databricks no conviene elegir por el motor sino por dónde vive ya el gobierno de la organización y quién lo opera; con el catálogo espejado, la pregunta deja de ser una u otra.

Bloque 10

Fuentes y fecha de revisión

Revisado el 18 de octubre de 2026

[1]
What is OneLake?
Microsoft Learn · 9 de marzo de 2026
https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview
[2]
Unify data with OneLake shortcuts and mirroring
Microsoft Learn · 15 de julio de 2026
https://learn.microsoft.com/en-us/fabric/onelake/unify-data
[3]
Understand medallion architecture for Fabric with OneLake
Microsoft Learn · 12 de febrero de 2026
https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture
[4]
What is the medallion lakehouse architecture? (Azure Databricks)
Microsoft Learn · 11 de septiembre de 2026
https://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion
[5]
What are materialized lake views in Microsoft Fabric?
Microsoft Learn · 30 de septiembre de 2026
https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/overview-materialized-lake-view
[6]
What is CI/CD in Microsoft Fabric?
Microsoft Learn · 23 de agosto de 2026
https://learn.microsoft.com/en-us/fabric/cicd/cicd-overview
[7]
CI/CD for pipelines in Data Factory in Microsoft Fabric
Microsoft Learn · 10 de junio de 2025
https://learn.microsoft.com/en-us/fabric/data-factory/cicd-pipelines
[8]
How Direct Lake works
Microsoft Learn · 22 de septiembre de 2025
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-how-it-works
[9]
Understand the Fabric capacity throttling policy
Microsoft Learn · 14 de agosto de 2026
https://learn.microsoft.com/en-us/fabric/enterprise/throttling
[10]
Fabric data agent concepts
Microsoft Learn · 11 de mayo de 2026
https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent
[11]
Mirroring Azure Databricks Unity Catalog
Microsoft Learn · 24 de octubre de 2025
https://learn.microsoft.com/en-us/fabric/mirroring/azure-databricks
[12]
Study guide for Exam DP-600: Implementing Analytics Solutions Using Microsoft Fabric
Microsoft Learn · 16 de agosto de 2026
https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/dp-600
[13]
Use Iceberg tables with OneLake
Microsoft Learn · 30 de julio de 2026
https://learn.microsoft.com/en-us/fabric/onelake/onelake-iceberg-tables

Síntesis en tres líneas

De la fuente a quien decide, y del cambio a producción

Leyenda de formas y colores

Lectura del mapa, nodo por nodo

Conexiones

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Lo común y lo configurable en la plataforma de datos de Vesting

Por qué

Capas progresivas o un solo paso

Por qué

Lakehouse, warehouse o los dos

Por qué

Aislar por cliente: un workspace propio o un filtro en el modelo

Por qué

Copiar el dato o leerlo donde está

Por qué

Direct Lake, importación o DirectQuery

Por qué

Una sola copia en OneLake, en Delta o en Iceberg

Atajos y espejado: leer el dato donde está

Capas declarativas con vistas materializadas del lakehouse

CI/CD de Fabric: Git, pipelines de despliegue y variables por etapa

El agente de datos de Fabric sobre el modelo gobernado

Fabric y Databricks: un puente entre catálogos

El DP-600 que se evalúa a partir del 19 de octubre de 2026

Vesting: cómo se diseñó su plataforma de datos

La normalización temprana como decisión de arquitectura

Lakehouse y warehouse sobre OneLake, con modos combinados

Gobierno desde el diseño: un workspace por cliente y seguridad por fila

Conciliar y versionar los modelos semánticos

Separar desarrollo y producción en la Fundación CTIC

Banco Pichincha: preparar con pasos separados