Una vez que tienes claro qué es un almacenamiento de datos y para qué lo quieres, llega la parte que de verdad pone a prueba la solución: cargar datos de forma fiable, mantenible y con sentido.
Porque una cosa es tener un warehouse. Y otra muy distinta es alimentarlo bien.
Aquí es donde muchas arquitecturas empiezan a mostrar su verdadera complejidad. No tanto por almacenar, sino por decidir cómo entran los datos, cuándo se transforman, dónde se preparan y qué estrategia tiene más sentido en cada caso.
Y en Microsoft Fabric, esta parte cobra todavía más interés porque no hablamos solo de SQL tradicional, sino de un entorno donde conviven canalizaciones, flujos de datos, T-SQL y OneLake dentro del mismo ecosistema.
El contexto: un almacenamiento moderno dentro de Fabric
El almacenamiento de datos de Microsoft Fabric se apoya en una base moderna, muy conectada con el resto de la plataforma. Aunque mantiene una experiencia relacional y capacidades completas de T-SQL, no vive aislado. Se integra con OneLake y almacena sus datos en formato Parquet.
Esto tiene una implicación importante: el warehouse no es una isla. Es una pieza más dentro de una arquitectura donde la ingesta, la transformación, el Lakehouse, Power BI y las demás cargas de trabajo conviven de forma natural.
Por eso, cuando hablamos de carga de datos en Fabric, no estamos hablando solo de “meter datos en tablas”. Estamos hablando de cómo encaja esa carga dentro de una solución de análisis más amplia.
ETL sigue importando
Aunque cambien las herramientas, el fondo sigue siendo el mismo: extraer, transformar y cargar.
El proceso ETL sigue siendo la base sobre la que se construyen muchos flujos de trabajo analíticos. La diferencia es que ahora las etapas no siempre son rígidas ni secuenciales. En algunos escenarios pueden ejecutarse en paralelo, y en otros la frontera entre transformación y carga se vuelve más flexible.
Pero la lógica sigue ahí:
- traer datos desde origen
- prepararlos
- y llevarlos al destino final listo para análisis
Entender esto sigue siendo clave, porque la herramienta puede cambiar, pero los principios no.
Ingesta no es lo mismo que carga
Aquí conviene hacer una distinción importante que muchas veces se pasa por alto.
La ingesta consiste en mover datos desde los sistemas origen hacia un repositorio central. Es, por así decirlo, el aterrizaje inicial del dato.
La carga, en cambio, implica llevar ya los datos transformados o preparados a las tablas finales del almacenamiento de datos, donde van a ser consumidos para análisis y reporting.
Parece una diferencia pequeña, pero no lo es. Porque te obliga a pensar bien dónde acaba cada fase y qué responsabilidad tiene cada capa dentro de la arquitectura.
El papel del almacenamiento provisional
Cuando trabajas con procesos de carga serios, aparece una pieza clásica que sigue teniendo muchísimo sentido: el staging o almacenamiento provisional.
El staging actúa como zona intermedia. Un lugar donde puedes dejar datos temporalmente, limpiarlos, validarlos, transformarlos o consolidarlos antes de llevarlos a las tablas finales del warehouse.
Y esto tiene varias ventajas. Por un lado, simplifica la lógica de carga. Por otro, reduce el impacto sobre las tablas finales y ayuda a controlar mejor errores, transformaciones y validaciones.
En definitiva, evita que el warehouse final se convierta en el lugar donde se resuelve todo a la vez.
Carga completa o carga incremental
Otra decisión fundamental es el tipo de carga.
Hay escenarios donde tiene sentido hacer una carga completa, es decir, reemplazar todo el contenido con una nueva versión. Y otros donde lo razonable es hacer una carga incremental, trayendo solo lo nuevo o lo cambiado.
No hay una respuesta única. Depende del volumen, de la frecuencia, de la naturaleza del dato y de lo que necesite el negocio.
Muchas veces, de hecho, lo más sensato es combinar ambos enfoques. Carga completa en unas tablas, incremental en otras. Todo depende del contexto.
Y aquí es donde se nota si el diseño del proceso está bien pensado o no.
Claves de negocio y claves suplentes
Cuando la carga entra ya en terreno de modelado dimensional, aparece una cuestión muy importante: cómo relacionas el dato de origen con el dato del warehouse.
La clave de negocio viene del sistema origen y tiene significado funcional: un código de producto, un identificador de cliente, un número de empleado.
La clave suplente, en cambio, es la clave interna del warehouse. No tiene significado de negocio, pero sí una función esencial: mantener consistencia y control dentro del modelo.
Y esto es especialmente importante cuando integras datos de varios orígenes, cuando hay cambios en los sistemas fuente o cuando necesitas mantener histórico con precisión.
Carga de dimensiones
En la práctica, cargar una dimensión no es solo insertar filas en una tabla descriptiva. Es construir contexto para los hechos.
Las dimensiones son las que explican el quién, el qué, el dónde, el cuándo o el porqué de los números. Y por eso su carga requiere bastante cuidado, sobre todo cuando los atributos cambian con el tiempo.
Aquí es donde entran las dimensiones de variación lenta o SCD. Especialmente el tipo 1 y el tipo 2, que son los más habituales.
El tipo 1 sobrescribe el valor anterior y no conserva histórico. El tipo 2, en cambio, crea una nueva versión del registro y permite mantener la historia completa de esa entidad a lo largo del tiempo.
Y esto no es un detalle menor. En muchos modelos, la diferencia entre un análisis correcto y uno engañoso está precisamente en cómo has tratado estos cambios.
Carga de hechos
Normalmente, las tablas de hechos se cargan después de las dimensiones. Y la razón es bastante lógica: los hechos necesitan referenciar a las dimensiones correctas.
Los datos de hechos suelen llegar con claves de negocio, así que durante la carga hay que buscar las claves suplentes correspondientes en las dimensiones. Si además estás trabajando con dimensiones de cambio lento, no basta con encontrar “el cliente” o “el producto”, sino la versión correcta de ese cliente o producto en el momento en que ocurrió el hecho.
Y aquí ya entramos en una carga mucho más analítica que operativa. No se trata solo de insertar registros. Se trata de insertar registros correctamente contextualizados.
Carga mediante canalizaciones de datos
Dentro de Fabric, una de las formas más naturales de cargar un warehouse es mediante canalizaciones de datos.
Las canalizaciones permiten construir flujos de trabajo de movimiento e integración de datos con una interfaz visual y bastante amigable. Esto las hace especialmente interesantes para escenarios low-code o para equipos que quieren automatizar procesos sin depender siempre de desarrollo puramente SQL.
Puedes usarlas para copiar datos desde orígenes diversos, programar ejecuciones, encadenar tareas y combinar procesos ETL o ELT dentro de un mismo flujo.
Y como heredan bastante de Azure Data Factory, el enfoque resulta familiar para quienes ya han trabajado con ese tipo de soluciones.
El asistente de copia
Dentro de las canalizaciones, una pieza especialmente útil es el asistente de copia.
Te guía paso a paso para:
- elegir el origen
- conectarte a los datos
- seleccionar tablas o consultas
- elegir el destino
- mapear columnas
- y configurar opciones adicionales
Es una forma bastante directa de poner en marcha una carga sin tener que construir todo manualmente desde cero.
Después, si lo necesitas, puedes añadir más pasos para seguir transformando, validando o integrando esos datos dentro del proceso.
Programación y automatización
Una vez creada la canalización, puedes programarla.
Y esto es importante porque una carga de warehouse rara vez tiene sentido si depende de ejecución manual continua. Lo normal es que exista una frecuencia definida: diaria, horaria, semanal… lo que toque según el caso.
La automatización aquí no es un lujo. Es parte del diseño.
Porque si el warehouse es una base para análisis, tiene que mantenerse alimentado de forma predecible y controlada.
Carga mediante T-SQL
Para perfiles más orientados a SQL, Fabric también permite trabajar directamente con T-SQL para cargar datos.
Esto resulta especialmente cómodo para quien ya está acostumbrado a trabajar con el motor SQL y quiere mantener ese enfoque dentro del warehouse. No hablamos solo de consultar, sino de realizar operaciones de carga, transformación y combinación directamente desde base de datos.
Y aquí la instrucción COPY tiene un papel protagonista.
La instrucción COPY
COPY es el método principal para importar datos al warehouse desde almacenamiento externo.
Permite cargar datos desde archivos, definir formato, controlar encabezados, gestionar errores e incluso trabajar con varios archivos a la vez.
Esto da bastante flexibilidad a la hora de diseñar cargas, especialmente cuando los datos están repartidos en ficheros o llegan desde cuentas de almacenamiento externas.
Además, la posibilidad de separar filas rechazadas o errores ayuda mucho en la depuración y en el control de calidad del proceso.
Carga desde otros warehouse y Lakehouse
Otra capacidad muy interesante en Fabric es la posibilidad de cargar datos desde otros almacenes o Lakehouse dentro de la misma área de trabajo.
Esto permite combinar información distribuida entre distintos activos sin necesidad de sacarla fuera del entorno. Puedes usar nomenclatura de tres partes, hacer consultas entre bases de datos y apoyarte en patrones como CREATE TABLE AS SELECT o INSERT...SELECT para mover y consolidar datos.
Esto encaja muy bien cuando el dato está repartido entre varios recursos y necesitas construir una capa unificada de análisis dentro del warehouse.
Dataflow Gen2 como opción de carga y transformación
La otra gran vía dentro de Fabric es Dataflow Gen2.
Aquí el enfoque cambia: en lugar de apoyarte en SQL o en una canalización centrada en copia, entras en una experiencia muy ligada a Power Query, más visual y más cercana a perfiles analíticos o de negocio técnico.
Dataflow Gen2 permite importar, limpiar, transformar y cargar datos en un flujo bastante natural. Si vienes de Power BI o Excel, esta experiencia resulta especialmente familiar.
Y eso le da mucho valor en escenarios donde la transformación previa a la carga tiene bastante peso.
Transformación de datos con Dataflow
Una vez que los datos entran en un flujo de datos, puedes aplicar limpieza, reestructuración, eliminación de columnas, creación de nuevas columnas y muchos otros pasos.
Todos esos pasos quedan registrados, lo que ayuda bastante en mantenimiento y trazabilidad.
Y además, aquí entra una pieza interesante dentro del ecosistema actual: Copilot.
Copilot puede ayudarte a generar transformaciones dentro del flujo de datos a partir de instrucciones en lenguaje natural. No sustituye el criterio, claro, pero puede acelerar bastante ciertas tareas repetitivas o mecánicas.
Destinos y métodos de actualización
Cuando terminas de transformar, puedes elegir el destino. Y entre esos destinos está, por supuesto, el warehouse.
Una vez seleccionado, puedes decidir cómo actualizar la tabla:
- añadir filas nuevas
- o reemplazar el contenido existente
Y aquí volvemos otra vez a la lógica de carga: no es una decisión técnica aislada, sino parte del diseño general del proceso.
Publicación del flujo
En Dataflow Gen2, nada de lo que haces entra en funcionamiento realmente hasta que publicas.
La publicación convierte ese diseño en un flujo activo, listo para ejecutarse manualmente o por programación.
Y esto, aunque parezca una obviedad, es importante porque convierte una serie de pasos sueltos en una unidad reutilizable y mantenible dentro del proceso de carga.
Conclusión
Cargar datos en un almacenamiento de datos de Microsoft Fabric no consiste simplemente en llevar información de un punto A a un punto B.
Consiste en decidir:
- cómo entra el dato
- dónde se prepara
- qué estrategia de carga tiene sentido
- cómo se relaciona con dimensiones y hechos
- y qué herramienta encaja mejor en cada parte del proceso
Fabric ofrece varias formas de hacerlo: canalizaciones, T-SQL, COPY, consultas entre activos, Dataflow Gen2… y esa variedad no es un problema, es una ventaja, siempre que sepas qué papel debe jugar cada una.
