Elige OneLake Shortcut cuando el dato puede quedarse donde vive y Fabric solo necesita referenciarlo sin duplicar. Elige Mirroring cuando una base operacional compatible debe replicarse a OneLake con baja latencia y sin diseñar un ETL propio. Elige Copy Job cuando solo hace falta mover datos por copia completa, incremental o CDC sin coordinar un flujo complejo. Se selecciona siempre el mecanismo más simple que cumple latencia, seguridad, trazabilidad y operación.
Primero se decide qué le pasa al dato, después la herramienta
Data Factory dentro de Microsoft Fabric no es una única herramienta, y ese es el primer malentendido que cuesta caro. Antes de tocar nada conviene responder una pregunta de arquitectura: ¿el dato se referencia, se replica, se copia o se transforma? La respuesta define el mecanismo, no al revés.
La elección depende de cuatro variables concretas:
- Dónde vive el dato hoy y si puede quedarse ahí.
- Cuánta latencia admite el negocio entre el origen y OneLake.
- Si el dato necesita transformación antes de servir.
- Cuántos pasos debe coordinar el flujo para completarse.
Cuando estas cuatro variables están claras, la decisión casi se toma sola. Cuando no lo están, el equipo termina usando Data Pipeline por costumbre o Mirroring por novedad, y paga el sobrecosto en operación y gobierno. La regla práctica es criterio antes que herramienta, la misma lógica de cómo elegir la herramienta correcta para traer los datos: primero se fijan las decisiones del negocio y el modelo de datos que las sostiene, y recién después se elige la tubería.
OneLake Shortcut: referenciar sin duplicar
Un OneLake Shortcut sirve cuando el dato puede permanecer en su ubicación original y Fabric solo necesita apuntar a él, sin crear otra copia. Es la opción más liviana porque no mueve bytes: elimina duplicación, reduce costo de almacenamiento y evita procesos de sincronización.
Esa misma virtud es su riesgo. Como el dato vive fuera, dependes de una fuente externa que puede cambiar credenciales, permisos o disponibilidad. Antes de crear un shortcut debe quedar definido:
- El origen exacto y la credencial que lo autentica.
- La dependencia externa y quién la controla.
- El modelo de seguridad y quién puede leer a través del shortcut.
- El comportamiento del sistema si la fuente deja de estar disponible.
Si no puedes responder ese último punto, todavía no estás listo para usar un shortcut en producción.
Mirroring: replicar una base operacional con baja latencia
Mirroring es la respuesta cuando una base operacional compatible debe estar disponible en OneLake con baja latencia y no quieres diseñar ni mantener un proceso ETL propio. Fabric se encarga de la replicación continua; tú defines el alcance y los controles.
Es la herramienta correcta cuando el objetivo es tener una copia analítica fresca de un sistema transaccional soportado, sin escribir lógica de movimiento. Lo que debe quedar definido:
- La fuente soportada (no toda base es candidata a mirroring).
- El alcance de tablas que se replican.
- La latencia que el negocio acepta de verdad.
- La seguridad y los controles de replicación.
La trampa habitual es elegir mirroring porque es lo más nuevo, cuando en realidad una copia por lotes cada noche cumpliría igual. Baja latencia que nadie usa es costo sin retorno.
Copy Job: mover datos por copia, sin orquestar
Copy Job encaja cuando solo hace falta mover datos mediante copia completa, incremental o CDC, y no hay un flujo complejo que coordinar. Es transporte puro: del punto A al punto B, con una regla clara de qué filas mover en cada corrida.
Define antes de operarlo:
- El modo de copia: completa, incremental o CDC.
- La marca de control o el mecanismo de CDC que decide qué es nuevo.
- El destino y la frecuencia de ejecución.
- La reanudación ante fallo y las columnas de auditoría para trazar cada carga.
Si el proceso empieza a necesitar condiciones, notebooks, alertas o pasos entre sistemas, ya dejaste el territorio de Copy Job.
Cuándo escalar a Data Pipeline o Dataflow Gen2
Los dos mecanismos restantes resuelven necesidades distintas al simple movimiento.
Data Pipeline es el orquestador. Se usa cuando el proceso necesita dependencias, condiciones, varias actividades, notebooks, funciones, alertas o pasos entre sistemas. Aquí importan el orden, los parámetros, la identidad de ejecución, los reintentos, las notificaciones, el SLA y el responsable de cada fallo. Cuando un flujo combina varias herramientas, Pipeline actúa como director y cada actividad conserva un propósito claro.
Dataflow Gen2 es para preparar y transformar datos tabulares con Power Query en una experiencia de bajo código. Se elige cuando el equipo necesita limpiar y modelar sin escribir código, dejando definidas las consultas reutilizables, el destino, el esquema de salida, el historial de actualizaciones y las reglas de calidad.
Tabla de decisión rápida
| Mecanismo | Cuándo usarlo | Qué debe quedar definido |
|---|---|---|
| OneLake Shortcut | El dato puede quedarse en su ubicación y Fabric solo lo referencia sin copiar | Origen, credencial, dependencia externa, seguridad y qué pasa si la fuente cae |
| Mirroring | Una base operacional compatible se replica a OneLake con baja latencia, sin ETL propio | Fuente soportada, alcance de tablas, latencia aceptada, seguridad y controles |
| Copy Job | Solo mover datos por copia completa, incremental o CDC, sin flujo complejo | Modo de copia, marca de control o CDC, destino, frecuencia, reanudación y auditoría |
| Data Pipeline | El proceso necesita dependencias, condiciones, varias actividades o pasos entre sistemas | Orden, parámetros, identidad, reintentos, notificaciones, SLA y responsable de fallos |
| Dataflow Gen2 | Preparar y transformar datos tabulares con Power Query en bajo código | Consultas reutilizables, destino, esquema de salida, historial y reglas de calidad |
El criterio que evita el sobrediseño
La regla de implementación es una sola: se selecciona el mecanismo más simple que cumple latencia, seguridad, trazabilidad y operación. No se elige Pipeline por costumbre ni Mirroring por novedad. Cada capa que agregas es una capa que alguien mantiene, monitorea y explica cuando falla.
Esto conecta con la arquitectura medallion (Bronze, Silver, Gold): la entrada de datos alimenta la capa Bronze, y elegir bien ahí evita arrastrar complejidad hacia arriba. Esa capa Bronze es también donde empieza el trabajo de unificar los datos de ventas, finanzas y operaciones en un modelo común. Un shortcut mal justificado o un pipeline innecesario contaminan todo lo que viene después. Estos flujos requieren revisión y mantenimiento continuo, no son configuraciones que se dejan y se olvidan.
Si tu equipo aún no distingue con claridad cuándo referenciar, replicar o copiar, ese criterio se construye con práctica y acompañamiento, sea por la vía de la formación o de la consultoría. El mejor primer paso es ver cómo se aplica este enfoque sobre casos reales de Fabric: mira la demo gratuita y evalúa con datos concretos qué camino le conviene a tu empresa.
Preguntas relacionadas
¿Cuál es la diferencia entre un OneLake Shortcut y Mirroring en Fabric?
Un OneLake Shortcut referencia el dato en su ubicación original sin crear una copia, así que dependes de la fuente externa. Mirroring sí replica una base operacional compatible hacia OneLake con baja latencia, sin que diseñes un proceso ETL propio.
¿Cuándo conviene usar Copy Job en lugar de Data Pipeline?
Usa Copy Job cuando solo necesitas mover datos por copia completa, incremental o CDC sin coordinar condiciones ni varias actividades. Escala a Data Pipeline cuando el proceso requiere dependencias, notebooks, alertas o pasos entre sistemas.
¿Mirroring siempre es mejor por tener baja latencia?
No. La baja latencia solo aporta valor si el negocio la usa. Si una copia por lotes cada noche cumple el requisito, elegir Mirroring por novedad agrega costo y controles de replicación sin retorno real.
¿Qué riesgo tiene apoyarse en un Shortcut para datos de producción?
Como el dato vive fuera de Fabric, dependes de una fuente externa que puede cambiar credenciales, permisos o disponibilidad. Antes de usarlo debe quedar definido el comportamiento del sistema si esa fuente deja de estar disponible.
¿Cómo se decide el mecanismo de entrada de datos correcto?
Se responde primero si el dato se referencia, replica, copia o transforma, evaluando latencia, transformación y cantidad de pasos. Luego se elige el mecanismo más simple que cumpla latencia, seguridad, trazabilidad y operación.