Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: ✅ Almacén en Microsoft Fabric
Este artículo describe métodos para migrar almacenamiento de datos en Azure Synapse Analytics pools SQL dedicados a Microsoft Fabric Data Warehouse.
Sugerencia
Para obtener más información sobre la estrategia y la planificación de la migración, consulte Planificación de migración: pools SQL dedicados de Azure Synapse Analytics a Fabric Data Warehouse.
Hay disponible una experiencia automatizada para la migración desde grupos de SQL dedicados de Azure Synapse Analytics mediante Asistente de migración de Fabric para Data Warehouse. El resto de este artículo contiene más pasos de migración manuales.
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.
| Número de opción | Opción | Qué hace | Aptitud/Preferencia | Escenario |
|---|---|---|---|---|
| 1 | Fábrica de Datos | Conversión de esquema (DDL) Extracción de datos Ingesta de datos |
ADF/Canalización | Se ha simplificado todo en un esquema (DDL) y la migración de datos. Se recomienda para las tablas de dimensiones. |
| 2 | Data Factory con partición | Conversión de esquema (DDL) Extracción de datos Ingesta de datos |
ADF/Canalización | Usar opciones de particionamiento para aumentar el paralelismo de lectura y escritura, lo que proporciona diez veces más rendimiento frente a la opción 1, recomendado para tablas de hechos. |
| 3 | Data Factory con código acelerado | Conversión de esquema (DDL) | ADF/Canalización | Convierta y migre primero el esquema (DDL), luego use CETAS para extraer y COPY/Data Factory para ingerir datos y maximizar así el rendimiento en la ingesta de datos. |
| 4 | Código acelerado de procedimientos almacenados | Conversión de esquema (DDL) Extracción de datos Valoración del código |
T-SQL | Usuario de SQL que usa IDE con un control más pormenorizado sobre las tareas en las que desea trabajar. Usar COPY/Data Factory para procesar datos. |
| 5 | Extensión de proyecto de SQL Database para Visual Studio Code | Conversión de esquema (DDL) Extracción de datos Valoración del código |
Proyecto de SQL | Proyecto de base de datos SQL para la implementación con la integración de la opción 4. Utilice COPY o Data Factory para ingresar datos. |
| 6 | CREATE EXTERNAL TABLE AS SELECT (CETAS) - Crear tabla externa como selección | Extracción de datos | T-SQL | Extracción de datos rentable y de alto rendimiento en Azure Data Lake Storage (ADLS) Gen2. Usar COPY/Data Factory para procesar datos. |
| 7 | Migración mediante dbt | Conversión de esquema (DDL) Conversión de código de base de datos (DML) |
dbt | Los usuarios de dbt existentes pueden usar el adaptador de dbt Fabric para convertir su DDL y DML. A continuación, debe migrar datos mediante otras opciones de esta tabla. |
Elección de la carga de trabajo para la migración inicial
Al decidir por dónde empezar con el pool SQL dedicado de Synapse para Fabric Data Warehouse proyecto de migración, elige un área de carga de trabajo donde puedas:
- Demuestra la viabilidad de migrar a Fabric Data Warehouse entregando rápidamente los beneficios del nuevo entorno. Empieza pequeño y sencillo, y prepárate para múltiples 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.
Sugerencia
Crear un inventario de objetos que deban migrarse y documente el proceso de migración de principio a fin, de modo que se pueda repetir para otros grupos o cargas de trabajo de SQL dedicados.
El volumen de datos migrados en una migración inicial debe ser lo suficientemente grande para demostrar las capacidades y beneficios del entorno Fabric Data Warehouse, pero no demasiado grande para demostrar su valor rápidamente. 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:
- Convierte el esquema (DDL) a Fabric Data Warehouse sintaxis.
- Crea el esquema (DDL) en Fabric Data Warehouse.
- Migra los datos a Fabric Data Warehouse.
Opción 1. Migración de esquemas y datos: asistente para copia y actividad de copia ForEach
Este método utiliza el asistente Data Factory Copy para conectarse al pool SQL dedicado de origen, convertir la sintaxis DDL del pool dedicado SQL a Fabric y copiar datos a Fabric Data 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
staticrc10para permitir que un máximo de 32 consultas controle 22 consultas enviadas. - Data Factory para copiar directamente los datos del pool SQL dedicado a Fabric Data Warehouse requiere staging. El proceso de ingestión 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 ingiere los datos de la preparación en Fabric Data 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
Usar el Copy Wizard para generar un ForEach proporciona una interfaz sencilla para convertir DDL e ingestionar las tablas seleccionadas del pool SQL dedicado para Fabric Data 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 lecturas paralelizadas requiere que un pool SQL dedicado escale a DWU superior para permitir la ejecución de las consultas de extracción. Aprovechando la partición, la tasa mejora diez veces respecto a una opción sin partición. Puedes aumentar la DWU para obtener un rendimiento adicional a través de recursos de cómputo, pero el pool dedicado de SQL permite un máximo de 128 consultas activas.
Para más información sobre la asignación de DWU a Fabric de Synapse, consulte Blog: Asignación de grupos de SQL dedicados de Azure Synapse al proceso de Fabric Data Warehouse.
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:
- Extraiga los datos del grupo de SQL dedicado a ADLS, lo que mitiga la sobrecarga de rendimiento de la fase.
- Utiliza Data Factory o el comando COPY para ingerir los datos en tu almacén.
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
Puedes usar Fabric Pipelines para migrar fácilmente tus DDL (esquemas) para objetos de tabla desde cualquier fuente de Azure SQL Database o pool SQL dedicado. Esta tubería migra el esquema (DDL) de las tablas de pool SQL dedicadas de origen a Fabric Data 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 de consulta debe construirse usando una expresión dinámica, permitiendo que el parámetro
SchemaNamese utilice en una consulta que devuelva una lista de tablas de origen 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
SchemaNameparámetro para permitir el filtrado en los 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 utiliza el Lenguaje de Expresiones Dinámicas dentro de las tuberías para construir un SELECT TOP 0 * FROM <TABLE> y migrar solo el esquema sin datos a un almacén.
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 almacenamiento de datos de Workspace es Data Warehouse y el Data Warehouse está configurado como el almacén.
- El esquema y el nombre de la tabla de destino se definen mediante contenido dinámico.
- Esquema se refiere al campo de la iteración actual,
SchemaNamecon el fragmento:@item().SchemaName - La tabla hace referencia a TableName con el fragmento de código:
@item().TableName
- Esquema se refiere al campo de la iteración actual,
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:
- Convierte el esquema (DDL) a Fabric Data Warehouse sintaxis.
- Crea el esquema (DDL) en Fabric Data 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, necesitas usar o COPY INTO Fabric Data Factory para ingirlos en tu almacén.
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 más información sobre control de versiones, consulte Resumen de Desarrollo y despliegue.
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:
- Convierte el esquema (DDL) a Fabric Data Warehouse sintaxis.
- Crea el esquema (DDL) en Fabric Data 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 o COPY INTO bien Data Factory para ingerir los datos en tu almacén.
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 de un proyecto de base de datos desde la línea de comandos.
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 tu almacén 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:
- Convierte el esquema (DDL) a Fabric Data Warehouse sintaxis.
- Crea el esquema (DDL) en Fabric Data 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 DBT para Microsoft Fabric Data Warehouse permite que los proyectos DBT existentes que estaban dirigidos a diferentes plataformas como pools SQL dedicados Synapse, Snowflake, Databricks, Google Big Query o Amazon Redshift se migren a un almacén con un simple cambio de configuración.
Para empezar con un proyecto de dbt que Fabric Data Warehouse dirigido, consulta el Tutorial: Configurar 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 Data Warehouse
Para la ingestión en Fabric Data Warehouse, usa COPY INTO o Fabric Data Factory, según prefieras. 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 contención de recursos al cargar varias tablas de ADLS a Fabric Data 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ón de los grupos de SQL dedicados de Azure Synapse al cálculo del Data Warehouse de Fabric
- Introducción a la migración de Microsoft Fabric