Limitaciones de las bases de datos duplicadas de Microsoft Fabric desde Snowflake

Las limitaciones actuales de las bases de datos reflejadas de Microsoft Fabric desde Snowflake se muestran en esta página. Esta página está sujeta a cambios.

Limitaciones de conexión y autenticación

  • En la tabla siguiente se enumeran los métodos de autenticación compatibles con la duplicación en Snowflake:
Método de autenticación Compatible Notas
Nombre de usuario y contraseña Autenticación nativa de Snowflake
Microsoft Entra ID (SSO) Inicio de sesión único a través de Entra ID
Autenticación del par de claves Par de claves RSA para escenarios de cuentas de servicio
Identidad del área de trabajo No Actualmente no es compatible con Snowflake
  • La identidad del área de trabajo actualmente no es compatible con la duplicación de Snowflake. Está disponible para determinados orígenes, como SharePoint.

  • La conectividad de Private Link entre un espacio de trabajo de Fabric y Snowflake aún no está disponible. Use una puerta de enlace de datos de red virtual o una puerta de enlace de datos local para la conectividad privada mientras tanto.

  • Debe agregar destinatarios de uso compartido al área de trabajo. Para compartir un conjunto de datos o informe, agregue primero access al área de trabajo con un rol de administrador, miembro, lector o colaborador.

  • Distinción entre mayúsculas y minúsculas: todos los identificadores de Snowflake, incluidos el nombre del almacén, el nombre de la base de datos, el nombre del esquema, los nombres de las tablas y los nombres de las vistas, distinguen entre mayúsculas y minúsculas al configurar conexiones de replicación y al usar la API REST de replicación. El uso de mayúsculas y minúsculas que escriba en Fabric debe coincidir exactamente con lo que está configurado en Snowflake. Las diferencias entre mayúsculas y minúsculas pueden provocar fallos de conexión o hacer que las tablas no aparezcan para la replicación, a menudo sin ningún mensaje de error claro. Por ejemplo, si el almacén de Snowflake se denomina ANALYTICS_WH, debe escribir ANALYTICS_WH en la conexión de Fabric, no analytics_wh.

Tipos de objeto admitidos

  • En la tabla siguiente se enumeran los tipos de objeto Snowflake que se admiten para la creación de reflejo:
Tipo de objeto Compatible Notas
Tablas administradas Totalmente compatible con la replicación
Tablas de Iceberg Requiere una conexión al almacenamiento subyacente de la tabla Iceberg. Solo las tablas Iceberg accesibles mediante la misma conexión de almacenamiento pueden reflejarse juntas.
Views Compatible con sincronizaciones cada 12 horas
Vistas materializadas Compatible con sincronizaciones cada 12 horas
Tablas externas No No soportado
Tablas transitorias No No soportado
Tablas temporales No No soportado
Tablas dinámicas No No soportado

Limitaciones de la replicación y de los datos

  • Si no hay actualizaciones en una tabla de origen, el motor de replicación comienza a reducir su actividad a intervalos de tiempo cada vez mayores, hasta una hora, para esa tabla. Lo mismo puede ocurrir si se produce un error transitorio, lo que impide la actualización de datos. El motor del replicador reanudará automáticamente el sondeo normal después de detectar los datos actualizados.
  • La jerarquía de esquemas de origen se replica en la base de datos reflejada. En el caso de las bases de datos reflejadas creadas antes de habilitar esta característica, el esquema de origen se aplana y el nombre del esquema se codifica en el nombre de la tabla. Si desea reorganizar tablas con esquemas, vuelva a crear la base de datos reflejada. Obtenga más información en Replicación de la jerarquía de esquemas de origen.
  • La creación de reflejo admite la replicación de columnas que contienen espacios o caracteres especiales en nombres (como ,;{}()\n\t=). Para las tablas en replicación antes de habilitar esta característica, debe actualizar la configuración de la base de datos reflejada o reiniciar la base de datos reflejada para incluir esas columnas. Obtenga más información en Compatibilidad con la asignación de columnas delta.
  • El número máximo de tablas que se pueden reflejar en Fabric es de 1000 tablas. Las tablas por encima del límite de 1000 actualmente no se pueden replicar.
    • Si selecciona Reflejar todos los datos al configurar el reflejo, las tablas que se van a duplicar se determinarán tomando las primeras 1,000 tablas cuando todas las tablas se ordenen alfabéticamente según el nombre del esquema y el nombre de la tabla. El conjunto restante de tablas en la parte inferior de la lista alfabética no se reflejará.
    • Si anula la selección de Reflejo de todos los datos y selecciona tablas individuales, no podrá seleccionar más de 1000 tablas.
  • Columnas calculadas y tablas calculadas: las bases de datos reflejadas son de solo lectura. No se pueden crear columnas calculadas ni tablas calculadas directamente en una base de datos reflejada. Para añadir columnas calculadas, cree un Lakehouse y use accesos directos para hacer referencia a los datos replicados; a continuación, cree sus columnas calculadas en el Lakehouse mediante cuadernos o SQL.

Limitaciones de rendimiento

  • Si va a modificar la mayor parte de los datos de una tabla grande, es más eficiente detener y reiniciar Mirroring. La inserción o actualización de miles de millones de registros puede tardar mucho tiempo.
  • Algunos cambios de esquema no se reflejan inmediatamente. Algunos cambios de esquema necesitan un cambio de datos (insertar, actualizar o eliminar) antes de que los cambios de esquema se repliquen en Fabric.
  • Consideraciones entre regiones: si la instancia de Snowflake y la capacidad de Fabric están en regiones en la nube diferentes, es posible que experimente mayores cargos de latencia de replicación y salida de datos. Para obtener un rendimiento óptimo y evitar los costos de salida entre regiones, implemente la capacidad de Fabric en la misma región de nube que la instancia de Snowflake. Si la implementación entre regiones es inevitable, tenga en cuenta las tarifas de salida adicionales de Snowflake o Azure. Consulte la documentación de salida de Snowflake para obtener más información.
  • Al reflejar datos de Snowflake en el OneLake de un cliente, el proceso normalmente almacena temporalmente los datos mediante una URL insertada en línea para mejorar el rendimiento. Si el parámetro de nivel de cuenta de Snowflake PREVENT_UNLOAD_TO_INLINE_URL se establece en true, se aplica el siguiente comportamiento:
Método de conectividad Efecto cuando PREVENT_UNLOAD_TO_INLINE_URL = true
Directo (punto de conexión público) La creación de reflejos recurre a la lectura directa desde Snowflake. Esta alternativa provoca tiempos de replicación más lentos y un mayor riesgo de que se agote el tiempo de espera de la conexión, especialmente con grandes conjuntos de datos.
puerta de enlace de datos de Virtual Network (VNet) La duplicación está completamente bloqueada. Los escenarios de puerta de enlace de VNet no pueden usar la lectura directa y requieren la ruta de almacenamiento provisional de la URL insertada.
Puerta de enlace de datos local (OPDG) La creación de reflejo está completamente bloqueada. Los escenarios de OPDG no pueden usar la lectura directa y requieren la ruta de almacenamiento provisional de URL insertada.

Solución prevista: la compatibilidad de integración con el almacenamiento está en desarrollo y proporcionará una ruta alternativa de almacenamiento provisional que funciona cuando PREVENT_UNLOAD_TO_INLINE_URL está establecido en true. Esta solución elimina los bloqueos en los escenarios con VNet y OPDG. Compruebe esta página para obtener actualizaciones sobre la disponibilidad.

  • Comportamiento de la reinicialización: Una reinicialización es una recarga completa de los datos de toda una tabla. A diferencia de la sincronización incremental (que solo procesa las filas modificadas), una resincronización completa vuelve a leer y reescribe todos los datos de la tabla. Las reinicializaciones pueden suponer un coste significativo de cómputo en Snowflake, especialmente para tablas grandes.
    • Qué desencadena una reinicialización:
Trigger Descripción
Cambios de DDL Cualquier cambio de DDL que modifique la marca temporal de DDL de una tabla desencadena una reinicialización. Este desencadenador incluye instrucciones ALTER TABLE que agregan, quitan o cambian el nombre de columnas, cambian tipos de datos o modifican propiedades de tabla.
Herramientas de modificación de esquemas (por ejemplo, DBT) Si una herramienta como DBT modifica las definiciones de las tablas de forma periódica (por ejemplo, mediante `dbt run`, que elimina y vuelve a crear tablas), cada modificación desencadena una reinicialización. Ejecutar estas herramientas con frecuencia (por ejemplo, cada pocos minutos) puede provocar bucles continuos de resiembra.
Detener y reiniciar la duplicación Cada vez que se detiene y reinicia la replicación, se vuelve a recuperar toda la tabla desde cero.
Pausa de capacidad ampliada Si una capacidad de Fabric se pausa durante un período prolongado, la réplica podría reiniciarse desde el principio al reanudarse. Consulte Cambios en la capacidad de Fabric.
  • Prácticas recomendadas para evitar regeneraciones de semillas innecesarias:
    • Programe los cambios de esquema fuera de los periodos de replicación activa. Si utiliza DBT u otras herramientas de administración de esquemas, programe su ejecución durante las ventanas de mantenimiento o pause la replicación antes de realizar cambios en el esquema.
    • Evite modificaciones frecuentes de DDL. Consolide los cambios de esquema en menos lotes más grandes en lugar de realizar cambios incrementales a lo largo del día.
    • Controle los reseeds inesperados. En la página Estado de duplicación, esté atento a las tablas que muestren repetidamente un comportamiento de copia inicial. Si una tabla grande se reinicializa cada pocos minutos, compruebe si hay cambios de DDL en origen.
    • Tenga en cuenta el impacto en el costo. Una actualización de una tabla de 226 millones de filas (~26,5 GB) tarda un tiempo de proceso significativo. Multiplique este costo por la frecuencia de los cambios de esquema para calcular el impacto en el costo.

Limitaciones de seguridad

  • Fabric no replica las directivas de Snowflake Row-Level Security (RLS) y Column-Level Security (CLS). Debe volver a configurar manualmente directivas de seguridad equivalentes en Fabric.
  • Los destinatarios para compartir deben agregarse al área de trabajo. Para compartir un conjunto de datos o informe, agregue primero access al área de trabajo con un rol de administrador, miembro, lector o colaborador.

Consideraciones sobre costos y facturación

Para minimizar los costes de cómputo de Snowflake derivados de la replicación, tenga en cuenta las siguientes prácticas recomendadas:

  • Reutilización de un almacén existente. En lugar de crear un almacenamiento dedicado para la creación de reflejo, configure la creación de reflejo para usar el mismo almacenamiento que las aplicaciones ya usan para actualizar las tablas de origen. Este enfoque evita ciclos innecesarios de reactivación y suspensión automática del almacenamiento. Cuando la aplicación actualiza una tabla, el replicador de creación de reflejo recoge los cambios casi inmediatamente mientras el almacenamiento sigue activo, lo que elimina la necesidad de reactivar un almacén independiente. Algunas organizaciones pueden preferir un almacenamiento dedicado para el aislamiento presupuestario. Esta opción es un equilibrio entre el ahorro de costos y la granularidad del presupuesto.
  • Replica solo las tablas que necesites. Reflejar una base de datos completa puede provocar un consumo inesperadamente alto de Snowflake y picos de capacidad en Fabric. Para empezar, seleccione solo las tablas necesarias para los escenarios de análisis. Puede agregar tablas más adelante según sea necesario.
  • Supervise las reinicializaciones inesperadas. Un reseado (recarga completa de datos) procesa toda la tabla y incurre en un costo de proceso proporcional al tamaño de la tabla. Los cambios de esquema, incluidos los desencadenados por herramientas como DBT, pueden provocar reinicializaciones continuas. Consulte la página Estado de la duplicación para identificar tablas que muestren un comportamiento repetido de copia inicial y revise la sección Reinicialización para ver los factores desencadenantes y la orientación para la solución de problemas.
  • Tenga en cuenta que la duplicación se realiza de forma continua. La replicación reflejada no admite actualmente programación ni ventanas de replicación. El replicador consulta continuamente si hay cambios, lo que genera un consumo continuo de cómputo de Snowflake. Planee los presupuestos de Snowflake en consecuencia.

Regiones soportadas

El reflejo de bases de datos y el reflejo abierto están disponibles en todas las regiones de Microsoft Fabric. Para obtener más información, consulte Disponibilidad de la región de Fabric.