Elige el mecanismo más simple que cumpla la latencia, la seguridad y la trazabilidad que el flujo necesita: referencia el dato con un Shortcut cuando puede quedarse donde vive, replícalo con Mirroring cuando una base operacional debe llegar a OneLake con baja latencia y sin ETL propio, y cópialo con Copy Job cuando solo hace falta mover datos por completo, incremental o CDC.
Antes de tocar una herramienta conviene responder una pregunta anterior: ¿este dato debe referenciarse, replicarse, copiarse o transformarse? Esa decisión ordena el resto. Data Factory dentro de Microsoft Fabric no es una única herramienta, y la elección depende de dónde vive el dato, cuánta latencia admite, si necesita transformación y cuántos pasos debe coordinar el flujo. La guía de opciones de ingesta de Fabric compara tiempo real, lotes, mirroring y shortcuts para que la elección sea explícita y no por costumbre.
La primera pregunta no es qué herramienta, es qué le pasa al dato
Hay cuatro verbos que definen la entrada y el movimiento: referenciar, replicar, copiar y transformar. Referenciar deja el dato en su origen y solo lo hace visible dentro de Fabric. Replicar trae una base operacional a OneLake con baja latencia y sin que tú diseñes el proceso. Copiar mueve los datos con un mecanismo directo, completo o incremental. Transformar prepara y modela con Power Query o notebooks.
Cada verbo tiene su patrón preferido. Confundirlos es la causa más común de arquitecturas que hacen copias que nadie pidió, con latencia peor y sin dueño claro. La decisión de implementación es sencilla de enunciar y difícil de sostener: no se elige Pipeline por costumbre ni Mirroring por novedad, se selecciona el mecanismo más simple que cumple latencia, seguridad, trazabilidad y operación.
OneLake Shortcut: cuando el dato puede quedarse donde vive
Un Shortcut sirve cuando el dato puede permanecer en su ubicación y Fabric solo necesita referenciarlo, sin crear otra copia. Es la opción más liviana porque no mueve nada: apunta a datos internos o externos y los hace visibles dentro de OneLake, incluyendo de dónde proviene cada activo.
Antes de crear un Shortcut deben quedar definidos el origen, la credencial, la dependencia externa, la seguridad y, sobre todo, el comportamiento si la fuente deja de estar disponible. Ese último punto es el límite real: al no haber copia, la disponibilidad del dato depende de un sistema que no controlas dentro de Fabric. Si el origen cae, la referencia cae con él. El Shortcut brilla cuando esa dependencia es aceptable y evitar la duplicación importa más que el aislamiento.
Mirroring: replicación de baja latencia sin diseñar tu ETL
Mirroring encaja cuando una base operacional compatible debe replicarse hacia OneLake con baja latencia y sin que tu equipo diseñe un proceso ETL propio. Es replicación gestionada: tú defines el alcance y Fabric mantiene la copia cerca del origen. La documentación de Mirroring describe cómo cubre esa réplica de baja latencia para las fuentes soportadas.
Los elementos que deben quedar definidos son la fuente soportada, el alcance de tablas, la latencia aceptada, la seguridad y los controles de replicación. El límite aquí es doble: la fuente tiene que estar entre las soportadas, y estás asumiendo una réplica continua, no una foto puntual. Si la base operacional no es compatible, o si en realidad solo necesitas datos por lotes cada cierto tiempo, Mirroring es más maquinaria de la que el problema pide.
Copy Job: mover datos sin orquestar un flujo complejo
Copy Job es la respuesta cuando solo hace falta mover datos mediante copia completa, incremental o CDC, sin coordinar un flujo con muchas dependencias. Es el patrón de copia directa. La referencia de Copy Job documenta la copia incremental por lotes, que es su terreno natural frente a la réplica continua de Mirroring.
Para un Copy Job conviene fijar el modo de copia, la marca de control o CDC, el destino, la frecuencia, la reanudación y las columnas de auditoría. El límite es de propósito: Copy Job copia bien, pero no orquesta. En el momento en que aparecen condiciones, notebooks, alertas o pasos encadenados entre sistemas, el problema dejó de ser copiar y pasó a ser coordinar, y ahí entra otra herramienta.
Cuándo el flujo deja de ser un patrón y necesita orquestación
Data Pipeline no compite con los tres anteriores, los coordina. Se usa cuando el proceso necesita dependencias, condiciones, varias actividades, notebooks, funciones, alertas o pasos entre sistemas. Si el flujo combina varias herramientas, Pipeline actúa como orquestador y cada actividad conserva un propósito claro: puede haber un Copy Job dentro de un Pipeline, disparado tras una condición y seguido de una notificación.
Dataflow Gen2 es un caso aparte, no de movimiento sino de preparación: aplica cuando el equipo necesita transformar datos tabulares con Power Query en una experiencia de bajo código. Si tu pregunta era transformar, ninguno de los tres patrones de movimiento es la respuesta. Vale la pena distinguirlo porque muchas discusiones de Shortcut contra Mirroring en realidad escondían una necesidad de transformación, que pertenece a otra capa, la misma que ordena la arquitectura medallion en Fabric.
Un árbol de decisión que se sostiene en producción
Una forma de recorrer la decisión, en orden:
- ¿El dato puede quedarse en su origen y solo necesitas verlo en Fabric? Shortcut, aceptando la dependencia externa.
- ¿Es una base operacional compatible que debe llegar a OneLake con baja latencia y continua? Mirroring, definiendo alcance de tablas y latencia.
- ¿Solo necesitas mover datos por lotes, completo, incremental o CDC, sin coordinar? Copy Job, fijando marca de control y columnas de auditoría.
- ¿Hay dependencias, condiciones o varias actividades? Pipeline como orquestador de los anteriores.
- ¿La necesidad real era preparar y transformar? Dataflow Gen2.
Este árbol se apoya en una decisión previa de gobierno: si el proyecto es pequeño, se simplifica; si va a escalar, se define la separación por entorno, capa o dominio y se registran propietarios, descripciones, sensibilidad y señales de confianza desde el inicio. OneLake Catalog reúne descubrimiento, linaje y gobierno para que cada activo tenga contexto y dueño, y el modelo de control de acceso explica cómo se combinan los roles con la seguridad del motor. Elegir el patrón de movimiento sin decidir quién es el propietario del activo resultante deja deuda que aparece cuando el sistema crece. Esa misma frontera entre motor de consulta y almacenamiento es la que separa un lakehouse de un warehouse en Fabric.
El criterio antes que la herramienta es lo que evita copias innecesarias y latencias mal elegidas. Cuando la decisión de entrada y movimiento se toma para una empresa entera, con fuentes reales, responsables y límites concretos, conviene mapearla como parte de un diagnóstico ordenado. Si quieres ver cómo se aborda ese inventario de fuentes, propiedad y preparación en la práctica, mira la demo gratuita.
Antes de crear el primer Shortcut o Mirror
Toma tus tres o cuatro fuentes más críticas y clasifícalas con el árbol anterior en una tabla de cuatro columnas: origen, verbo (referenciar, replicar, copiar), latencia aceptada y propietario del activo resultante. Si una fila no puede nombrar a su propietario, resuélvelo antes de configurar el mecanismo, no después. Esa tabla, y no la herramienta, es la decisión de arquitectura.
Preguntas relacionadas
¿Un OneLake Shortcut crea una copia del dato en Fabric?
No. El Shortcut referencia el dato en su ubicación original sin copiarlo, por lo que la disponibilidad depende de que la fuente siga en línea. Por eso conviene definir de antemano el comportamiento esperado si el origen deja de estar disponible.
¿Cuál es la diferencia práctica entre Mirroring y Copy Job?
Mirroring mantiene una réplica continua de baja latencia de una base operacional soportada, sin que diseñes un ETL. Copy Job mueve datos por lotes mediante copia completa, incremental o CDC. Uno mantiene una copia viva; el otro ejecuta una transferencia definida.
¿Puedo combinar Copy Job dentro de un Data Pipeline?
Sí. Cuando el flujo necesita dependencias, condiciones, alertas o pasos entre sistemas, el Pipeline actúa como orquestador y cada actividad, incluido un Copy Job, conserva un propósito claro dentro del orden general.
¿Qué debo definir antes de elegir el patrón de movimiento?
El propietario del activo resultante, además de origen, latencia aceptada, seguridad y trazabilidad. Elegir el mecanismo sin decidir quién es responsable del dato deja deuda de gobierno que aparece cuando el sistema escala.
¿Dataflow Gen2 sirve para mover datos entre sistemas?
No es su propósito. Dataflow Gen2 prepara y transforma datos tabulares con Power Query en bajo código. Si la necesidad real era transformar y no mover, ninguno de los patrones de movimiento (Shortcut, Mirroring, Copy Job) es la respuesta correcta.