Migración métodos paraMigración de grupos de SQL dedicados de Azure Synapse Analytics a Fabric Data Warehouse

Esto se aplica a:✅ Warehouse en Microsoft Fabric

En este artículo se detallan los métodos de migración del almacenamiento de datos en grupos de SQL dedicados de Azure Synapse Analytics a Microsoft Fabric Warehouse.

En esta tabla se resume la información del esquema de datos (DDL), el código de base de datos (DML) y los métodos de migración de datos. Más adelante en este artículo, vinculado en la columna Opción, ampliaremos cada escenario.

Elección de la carga de trabajo para la migración inicial

Al decidir por dónde comenzar el proyecto de migración desde el grupo de SQL dedicado de Synapse hacia Fabric Warehouse, elija una área de cargas de trabajo donde pueda:

• Demostrar la viabilidad de la migración a Fabric Warehouse entregando rápidamente los beneficios del nuevo entorno. Comience por algo pequeño y sencillo, prepárese para varias migraciones pequeñas.
• Permitir que el personal técnico interno tenga tiempo para obtener experiencia relevante con los procesos y herramientas que usan al migrar a otras áreas.
• Crear una plantilla para realizar migraciones adicionales específicas del entorno de Synapse de origen, así como las herramientas y los procesos implementados para ayudar.

El volumen de datos migrados en una migración inicial debe ser suficientemente grande como para demostrar las capacidades y beneficios del entorno de Fabric Warehouse, pero no demasiado grande para demostrar rápidamente el valor. Un tamaño en el rango de 1 a 10 terabytes es lo habitual.

Migración con Fabric Data Factory

En esta sección, se describen las opciones que usan Data Factory para el rol de código bajo o sin código que está familiarizado con Azure Data Factory y la canalización de Synapse. Esta opción de interfaz de usuario de arrastrar y colocar proporciona un paso sencillo para convertir el DDL y migrar los datos.

Fabric Data Factory puede realizar las siguientes tareas:

• Convertir el esquema (DDL) en sintaxis de Fabric Warehouse.
• Crear el esquema (DDL) en Fabric Warehouse.
• Migrar los datos a Fabric Warehouse.

Opción 1. Migración de esquemas y datos: asistente para copia y actividad de copia ForEach

Este método usa el Asistente para copia de Data Factory para conectarse al grupo de SQL dedicado de origen, convertir la sintaxis DDL del grupo de SQL dedicado en Fabric y copiar datos en Fabric Warehouse. Puede seleccionar una o varias tablas de destino (para el conjunto de datos TPC-DS hay 22 tablas). Genera ForEach para recorrer en bucle la lista de tablas seleccionadas en la interfaz de usuario y generar 22 subprocesos de actividad de copia en paralelo.

• Se han generado y ejecutado 22 Consultas SELECT (una para cada tabla seleccionada) en el grupo de SQL dedicado.
• Asegúrese de que tiene la clase de recursos y DWU adecuada para permitir que se ejecuten las consultas generadas. Para este caso, necesita un mínimo de DWU1000 con staticrc10 para permitir que un máximo de 32 consultas controle 22 consultas enviadas.
• La copia directa de datos de Data Factory desde el grupo de SQL dedicado a Fabric Warehouse requiere almacenamiento provisional. El proceso de ingesta consta de dos fases.
  • La primera fase consiste en extraer los datos del grupo de SQL dedicado en ADLS y se conoce como almacenamiento provisional.
  • La segunda fase consiste en ingerir los datos de ensayo en Fabric Warehouse. La mayor parte del tiempo de ingesta de datos se encuentra en la fase de almacenamiento provisional. En resumen, el almacenamiento provisional tiene un gran impacto en el rendimiento de la ingesta.

Uso recomendado

Usando el Asistente para Copia para generar un ForEach se proporciona una interfaz de usuario sencilla para convertir el DDL e ingerir las tablas seleccionadas del grupo de SQL dedicado en Fabric Warehouse en un solo paso.

Sin embargo, no es óptimo en cuanto al rendimiento general. El requisito de usar el almacenamiento provisional, la necesidad de paralelizar la lectura y escritura del paso "Origen a fase" son los principales factores para la latencia de rendimiento. Se recomienda usar esta opción solo para tablas de dimensiones.

Opción 2. Migración de DDL/Data: canalización mediante la opción de partición

Para abordar la mejora del rendimiento para cargar tablas de hechos más grandes mediante la canalización de Fabric, se recomienda usar la Actividad de Copia para cada tabla de hechos con la opción de particionamiento. Esto proporciona el mejor rendimiento con la actividad de copia.

Tiene la opción de utilizar la partición física de la tabla de origen, si está disponible. Si la tabla no tiene particiones físicas, debe especificar la columna de partición y proporcionar valores min/max para usar la creación de particiones dinámicas. En la captura de pantalla siguiente, las opciones de la canalización Source especifican un intervalo dinámico de particiones basado en la ws_sold_date_sk columna.

Aunque el uso de una partición puede aumentar el rendimiento durante la fase de preparación, hay consideraciones para hacer los ajustes adecuados.

• En función del intervalo de particiones, podría usar todos los slots de concurrencia, ya que esto podría generar más de 128 consultas en el pool de SQL dedicado.
• Es necesario escalar a un mínimo de DWU6000 para permitir que se ejecuten todas las consultas.
• Por ejemplo, para la tabla TPC-DS web_sales, se enviaron 163 consultas al grupo de SQL dedicado. En DWU6000, se ejecutaron 128 consultas mientras se ponen en cola 35 consultas.
• La partición dinámica selecciona automáticamente la partición de intervalo. En este caso, un intervalo de 11 días para cada consulta SELECT enviada al grupo de SQL dedicado. Por ejemplo:

  WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
  ...
  WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
  

Uso recomendado

Para las tablas de hechos, se recomienda usar Data Factory con la opción de creación de particiones para aumentar el rendimiento.

Sin embargo, el aumento de las lecturas en paralelo requiere un grupo de SQL dedicado para escalar a una DWU superior para permitir que se ejecuten las consultas de extracción. Aprovechando la creación de particiones, la velocidad mejora diez veces en comparación con la opción sin partición. Puede aumentar la DWU para obtener un rendimiento adicional a través de recursos de proceso, pero el grupo de SQL dedicado tiene un máximo de 128 consultas activas permitidas.

Para obtener más información sobre el mapeo de DWU de Synapse a Fabric, consulte Blog: Mapeo de grupos de SQL dedicados de Azure Synapse al cómputo de almacén de datos de Fabric.

Opción 3. Migración de DDL: actividad de copia del Asistente para copia de ForEach

Las dos opciones anteriores son excelentes opciones de migración de datos para bases de datos más pequeñas. Pero si necesita un mayor rendimiento, se recomienda una opción alternativa:

1. Extraiga los datos del grupo de SQL dedicado a ADLS, lo que mitiga la sobrecarga de rendimiento de la fase.
2. Usa Data Factory o el comando COPY para importar los datos en Fabric Warehouse.

Uso recomendado

Puede seguir usando Data Factory para convertir el esquema (DDL). Con el Asistente para copia, puede seleccionar la tabla específica o Todas las tablas. Por diseño, esto migra el esquema y los datos en un solo paso, extrayendo el esquema sin ninguna fila, utilizando la condición false, TOP 0 en la instrucción de consulta.

En el siguiente ejemplo de código se trata la migración del esquema (DDL) con Data Factory.

Ejemplo de código: migración de esquema (DDL) con Data Factory

Puede usar Pipelines de Fabric para migrar fácilmente sus DDL (esquemas) para objetos de tabla desde cualquier instancia de origen de Azure SQL Database o SQL pool dedicado. Esta tubería migra el esquema (DDL) de las tablas de pool dedicadas de SQL del origen a Fabric Warehouse.

Diseño de canalización: parámetros

Esta canalización acepta un parámetro SchemaName, que permite especificar qué esquemas se van a migrar. El esquema dbo es el valor predeterminado.

En el campo Valor predeterminado, escriba una lista delimitada por comas del esquema de tabla que indica qué esquemas se van a migrar: 'dbo','tpch' para proporcionar dos esquemas: dbo y tpch.

Diseño de canalización: actividad de búsqueda

Cree una actividad de búsqueda y establezca la conexión para que apunte a la base de datos de origen.

En la pestaña Configuración:

• Establezca Tipo de almacén de datos en Externo.

• Conexión es el grupo de SQL dedicado de Azure Synapse. Tipo de conexión: seleccione Azure Synapse Analytics.

• Usar consulta está establecido en Consulta.

• El campo Consulta debe crearse mediante una expresión dinámica, lo que permite usar el parámetro SchemaName en una consulta que devuelve una lista de tablas de origen de destino. Seleccione Consulta y, a continuación, seleccione Agregar contenido dinámico.

  Esta expresión dentro de la actividad de búsqueda genera una instrucción SQL para consultar las vistas del sistema para recuperar una lista de esquemas y tablas. Hace referencia al parámetro SchemaName para permitir el filtrado en esquemas SQL. El resultado es una matriz de esquemas SQL y tablas que se usarán como entrada en la actividad ForEach.

  Usa el siguiente código para devolver una lista de todas las tablas de usuario con su nombre de esquema.

  @concat('
  SELECT s.name AS SchemaName,
  t.name  AS TableName
  FROM sys.tables AS t
  INNER JOIN sys.schemas AS s
  ON t.type = ''U''
  AND s.schema_id = t.schema_id
  AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
  ')
  

Diseño de canalización: bucle ForEach

Para el bucle ForEach, configure las siguientes opciones en la pestaña Configuración:

• Deshabilite Secuencial para permitir que varias iteraciones se ejecuten simultáneamente.
• Establezca Recuento de lotes en 50, limitando el número máximo de iteraciones simultáneas.
• El campo Elementos debe usar contenido dinámico para hacer referencia a la salida de la actividad de búsqueda. Use el siguiente fragmento de código: @activity('Get List of Source Objects').output.value

Diseño de canalización: actividad de copia dentro del bucle ForEach

Dentro de la actividad ForEach, agregue una actividad de copia. Este método usa el Dynamic Expression Language dentro de las canalizaciones para construir un para migrar solo el esquema sin datos a Fabric Warehouse.

En la pestaña Origen:

• Establezca Tipo de almacén de datos en Externo.
• Conexión es el grupo de SQL dedicado de Azure Synapse. Tipo de conexión: seleccione Azure Synapse Analytics.
• Establezca Usar consulta en Consulta.
• En el campo Consulta, pegue la consulta de contenido dinámico y use esta expresión que devolverá cero filas, solo el esquema de la tabla: @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

En la pestaña Destino:

• Establezca Tipo de almacén de datos en Área de trabajo.
• El tipo de almacén de datos del área de trabajo es Data Warehouse y Data Warehouse se establece en Fabric Warehouse.
• El esquema y el nombre de la tabla de destino se definen mediante contenido dinámico.
  • El esquema hace referencia al campo de la iteración actual, SchemaName con el fragmento de código: @item().SchemaName
  • La tabla hace referencia a TableName con el fragmento de código: @item().TableName

Diseño de canalización: Sumidero

En Receptor, apunte al almacén y haga referencia al nombre de esquema y tabla de origen.

Una vez que ejecutes esta canalización, verás que el almacén de datos se rellena con cada tabla del origen, con el esquema adecuado.

Migración mediante procedimientos almacenados en el grupo de SQL dedicado de Synapse

Esta opción usa procedimientos almacenados para realizar la migración de Fabric.

Puede obtener los ejemplos de código en microsoft/fabric-migration en GitHub.com. Este código se comparte como código abierto, así que no dude en colaborar y ayudar a la comunidad.

Qué pueden hacer los procedimientos almacenados de migración:

• Convertir el esquema (DDL) en sintaxis de Fabric Warehouse.
• Crear el esquema (DDL) en Fabric Warehouse.
• Extraer datos del grupo de SQL dedicado de Synapse a ADLS.
• Marcar la sintaxis de Fabric no admitida para códigos T-SQL (procedimientos almacenados, funciones, vistas).

Uso recomendado

Esta es una excelente opción para aquellos que:

• Están familiarizados con T-SQL.
• Quieren usar un entorno de desarrollo integrado como SQL Server Management Studio (SSMS).
• Desean un control más pormenorizado sobre las tareas en las que quieren trabajar.

Puede ejecutar el procedimiento almacenado específico para la conversión del esquema (DDL), la extracción de datos o la evaluación de código de T-SQL.

Para la migración de datos, debe usar COPY INTO o Data Factory para ingerir los datos en Fabric Warehouse.

Migrar mediante los proyectos de base de datos de SQL

Microsoft Fabric Data Warehouse se admite en la extensión Proyectos de SQL Database disponibles dentro de Visual Studio Code.

Esta extensión está disponible en Visual Studio Code. Esta característica permite funcionalidades para el control de código fuente, las pruebas de base de datos y la validación de esquemas.

Para obtener más información sobre el control de código fuente para almacenes en Microsoft Fabric, incluidas las canalizaciones de integración e implementación de Git, consulte Control de código fuente con almacenamiento.

Uso recomendado

Esta es una excelente opción para aquellos que prefieren usar el proyecto de SQL Database para su implementación. Esta opción integra básicamente los procedimientos almacenados de migración de Fabric en el proyecto de SQL Database para proporcionar una experiencia de migración sin problemas.

Un proyecto de SQL Database puede:

• Convertir el esquema (DDL) en sintaxis de Fabric Warehouse.
• Crear el esquema (DDL) en Fabric Warehouse.
• Extraer datos del grupo de SQL dedicado de Synapse a ADLS.
• Marcar la sintaxis no admitida para códigos T-SQL (procedimientos almacenados, funciones, vistas).

Para la migración de datos, usarás COPY INTO o Data Factory para importar los datos en Fabric Warehouse.

El equipo cat de Microsoft Fabric ha proporcionado un conjunto de scripts de PowerShell para controlar la extracción, la creación y la implementación del esquema (DDL) y el código de base de datos (DML) a través de un proyecto de SQL Database. Para ver un tutorial sobre el uso del proyecto de SQL Database con nuestros scripts útiles de PowerShell, consulte microsoft/fabric-migration en GitHub.com.

Para obtener más información sobre proyectos de SQL Database, consulte Introducción a la extensión Proyectos de SQL Database y Compilación y publicación de un proyecto.

Migración de datos con CETAS

El comando T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) proporciona el método más rentable y óptimo para extraer datos de grupos de SQL dedicados de Synapse a Azure Data Lake Storage (ADLS) Gen2.

Qué puede hacer CETAS:

• Extraer datos en ADLS.
  • Esta opción requiere que los usuarios creen el esquema (DDL) en Fabric Warehouse antes de ingerir los datos. Tenga en cuenta las opciones de este artículo para migrar el esquema (DDL).

Las ventajas de esta opción son:

• Solo se envía una sola consulta por tabla en el grupo de SQL dedicado de Synapse de origen. No usará todas las ranuras de simultaneidad, por lo que no bloqueará las consultas ETL/ETL de producción simultáneas del cliente.
• El escalado a DWU6000 no es necesario, ya que se utiliza una única ranura de simultaneidad para cada tabla, por lo que los clientes pueden utilizar DWUs más bajos.
• La extracción se ejecuta en paralelo en todos los nodos de proceso y esta es la clave para mejorar el rendimiento.

Uso recomendado

Use CETAS para extraer los datos en ADLS como archivos Parquet. Los archivos Parquet proporcionan la ventaja de un almacenamiento de datos eficiente con compresión columnar que requiere menos ancho de banda para transferirse a través de la red. Además, dado que Fabric almacenó los datos como formato Delta Parquet, la ingesta de datos será 2,5 veces más rápida en comparación con el formato de archivo de texto, ya que no hay ninguna conversión a la sobrecarga de formato Delta durante la ingesta.

Para aumentar el rendimiento de CETAS:

• Agregue operaciones CETAS paralelas, lo que aumenta el uso de slots de concurrencia y permite un mayor rendimiento.
• Escale la DWU en el grupo de SQL dedicado de Synapse.

Migración a través de dbt

En esta sección, se describe la opción dbt para aquellos clientes que ya usan dbt en su entorno actual del grupo de SQL dedicado de Synapse.

Qué puede hacer dbt:

• Convertir el esquema (DDL) en sintaxis de Fabric Warehouse.
• Crear el esquema (DDL) en Fabric Warehouse.
• Convertir el código de base de datos (DML) en sintaxis de Fabric.

El marco dbt genera DDL y DML (scripts SQL) sobre la marcha con cada ejecución. Con los archivos de modelo expresados en instrucciones SELECT, DDL/DML se puede traducir al instante a cualquier plataforma de destino cambiando el perfil (cadena de conexión) y el tipo de adaptador.

Uso recomendado

El marco dbt es un enfoque orientado al código. Los datos deben migrarse mediante opciones enumeradas en este documento, como CETAS o COPY/Data Factory.

El adaptador de dbt para Microsoft Fabric Data Warehouse permite migrar los proyectos de dbt existentes destinados a distintas plataformas, como grupos de SQL dedicados de Synapse, Snowflake, Databricks, Google Big Query o Amazon Redshift, con un simple cambio de configuración.

Para empezar a trabajar con un proyecto de dbt destinado a Fabric Warehouse, consulte Tutorial: Configuración de dbt para Fabric Data Warehouse. En este documento también se muestra una opción para moverse entre diferentes almacenes o plataformas.

Ingesta de datos en Fabric Warehouse

Para la ingesta en Fabric Warehouse, use COPY INTO o Fabric Data Factory, según sus preferencias. Ambos métodos son las opciones recomendadas y de mejor rendimiento, ya que tienen un rendimiento equivalente, dado que los archivos ya se extraen en Azure Data Lake Storage (ADLS) Gen2.

Varios factores que se deben tener en cuenta para que pueda diseñar el proceso para obtener el máximo rendimiento:

• Con Fabric, no hay ninguna contención de recursos al cargar varias tablas de ADLS a Fabric Warehouse simultáneamente. Como resultado, no hay ninguna degradación del rendimiento al cargar subprocesos paralelos. El rendimiento máximo de ingesta solo estará limitado por la potencia de proceso de la capacidad de Fabric.
• La gestión de cargas de trabajo en Fabric proporciona una separación de los recursos asignados para la carga de datos y la consulta. No hay contención de recursos mientras las consultas y la carga de datos se ejecutan al mismo tiempo.

Contenido relacionado

• Fabric Migration Assistant para Data Warehouse
• Creación de un almacén en Microsoft Fabric
• Directrices de rendimiento de Fabric Data Warehouse
• Seguridad para el almacenamiento de datos en Microsoft Fabric
• Blog: AsignaciónAsignación de grupos de SQL dedicados de Azure Synapse al proceso de almacenamiento de datos de Fabric
• Introducción a la migración de Microsoft Fabric