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.
Tip
Microsoft Fabric Data Warehouse es un almacenamiento relacional de escala empresarial en una base de lago de datos, con una arquitectura lista para el futuro, inteligencia artificial integrada y nuevas características. Si no está familiarizado con el almacenamiento de datos, comience con Fabric Data Warehouse. Las cargas de trabajo del grupo de SQL dedicadas pueden actualizarse a Fabric para acceder a nuevas funcionalidades en ciencia de datos, análisis en tiempo real e informes.
Esta hoja de referencia rápida proporciona sugerencias útiles y procedimientos recomendados para crear soluciones de grupo de SQL dedicado (anteriormente SQL DW).
En el gráfico siguiente se muestra el proceso de diseño de un almacenamiento de datos con un grupo de SQL dedicado (anteriormente SQL DW):
Consultas y operaciones entre tablas
Cuando sepa con antelación las operaciones principales y las consultas que se van a ejecutar en el almacenamiento de datos, puede priorizar la arquitectura del almacenamiento de datos para esas operaciones. Estas consultas y operaciones pueden incluir:
- Combinar una o dos tablas de hechos con tablas de dimensiones, filtrar la tabla combinada y, a continuación, anexar los resultados a un data mart.
- Realizar actualizaciones grandes o pequeñas en sus datos de ventas.
- Anexar solo datos a las tablas.
Conocer los tipos de operaciones de antemano le ayuda a optimizar el diseño de las tablas.
Migración de datos
En primer lugar, cargue los datos en Azure Data Lake Storage o Azure Blob Storage. A continuación, use la instrucción COPY para cargar los datos en tablas de almacenamiento provisional. Use la configuración siguiente:
| Diseño | Recomendación |
|---|---|
| Distribución | Round Robin |
| Indexación | Heap |
| Partición | Ninguno |
| Clase de recurso | largerc o xlargerc |
Obtenga más información sobre la migración de datos, la carga de datos y el proceso De extracción, carga y transformación (ELT).
Tablas distribuidas o replicadas
Use las estrategias siguientes, en función de las propiedades de la tabla:
| Tipo | Ideal para... | Ten cuidado si... |
|---|---|---|
| Replicado | * Tablas de dimensiones pequeñas en un modelo estrella con menos de 2 GB de almacenamiento tras una compresión de aproximadamente 5x. | * Muchas transacciones de escritura están en la tabla (como la inserción, el upsert, la eliminación, la actualización) * Cambia el aprovisionamiento de unidades de Data Warehouse (DWU) con frecuencia. * Solo se usan 2-3 columnas, pero la tabla tiene muchas columnas. * Indexa una tabla replicada |
| Round Robin (valor predeterminado) | * Tabla temporal/de ensayo * No hay una clave de combinación obvia o una columna candidata adecuada |
* El rendimiento es lento debido al movimiento de datos |
| Hash | * Tablas de hechos * Tablas de dimensiones grandes |
* No se puede actualizar la clave de distribución. |
Sugerencias:
- Comience con "Round Robin", pero aspire a utilizar una estrategia de distribución en hash para aprovechar una arquitectura masivamente paralela.
- Asegúrese de que las claves hash comunes tienen el mismo formato de datos.
- No distribuya en formato varchar.
- Las tablas de dimensiones que tienen una clave hash común y que están vinculadas a una tabla de hechos con operaciones de combinación frecuentes se pueden distribuir mediante hash.
- Use sys.dm_pdw_nodes_db_partition_stats para analizar cualquier asimetría en los datos.
- Utilizar sys.dm_pdw_request_steps para analizar los movimientos de datos detrás de las consultas, supervisar el tiempo de difusión y las operaciones de intercambio. Esto resulta útil para revisar la estrategia de distribución.
Obtenga más información sobre las tablas replicadas y las tablas distribuidas.
Indiza tu tabla
La indexación es útil para leer tablas rápidamente. Hay un conjunto único de tecnologías que puede usar en función de sus necesidades:
| Tipo | Excelente compatibilidad para... | Ten cuidado si... |
|---|---|---|
| Heap | **
* Tabla de preparación/tabla temporal * Tablas pequeñas con búsquedas pequeñas |
* Cualquier búsqueda examina la tabla completa. |
| Índice agrupado | * Tablas con hasta 100 millones de filas * Tablas grandes (más de 100 millones de filas) con solo 1 a 2 columnas muy usadas |
* Se usa en una tabla replicada * Tiene consultas complejas que implican varias operaciones de combinación y agrupación por * Realizas actualizaciones en las columnas indexadas: esto toma memoria. |
| Índice de almacén de columnas agrupado (CCI) (valor predeterminado) | * Tablas grandes (más de 100 millones de filas) | * Se usa en una tabla replicada * Usted realiza operaciones de actualización masivas en su tabla. * Se sobreparticiona la tabla: los grupos de filas no abarcan diferentes nodos de distribución y particiones. |
Sugerencias:
- En la parte superior de un índice agrupado, es posible que desee agregar un índice no clúster a una columna que se usa en gran medida para el filtrado.
- Tenga cuidado de cómo administrar la memoria en una tabla con CCI. Al cargar datos, quiere que el usuario (o la consulta) se beneficie de una clase de recursos grande. Asegúrese de evitar recortar y crear pequeños grupos de filas comprimidas.
- En Gen2, las tablas CCI se almacenan en caché localmente en los nodos de proceso para maximizar el rendimiento.
- En el caso de CCI, el rendimiento lento puede producirse debido a una compresión deficiente de los grupos de filas. Si esto ocurre, reconstruya o reorganice su CCI. Desea al menos 100 000 filas por grupos de filas comprimidos. Lo ideal es 1 millón de filas en un grupo de filas.
- En función de la frecuencia y el tamaño de la carga incremental, quiere automatizar cuándo reorganizar o recompilar sus índices. La limpieza de primavera siempre es útil.
- Sea estratégico cuando quiera recortar un grupo de filas. ¿Cuán grandes son los grupos de filas abiertos? ¿Cuántos datos espera cargar en los próximos días?
Más información sobre los índices.
Partición
Puede particionar su tabla cuando tenga una tabla de hechos grande (más de mil millones de filas). En el 99 % de los casos, la clave de partición debe basarse en la fecha.
Con las tablas de almacenamiento provisional que requieren ELT, puede beneficiarse de la creación de particiones. Facilita la administración del ciclo de vida de los datos. Tenga cuidado de no sobrepartir la tabla de hechos o la tabla de staging, especialmente en un índice de almacén de columnas agrupado.
Más información sobre las particiones.
Carga incremental
Si va a cargar los datos de forma incremental, primero asegúrese de asignar clases de recursos más grandes para cargar los datos. Esto es especialmente importante al cargar en tablas con índices de columnas almacenadas agrupadas. Consulte clases de recursos para obtener más información.
Recomendamos usar PolyBase y ADF V2 para automatizar las canalizaciones de ELT en su almacén de datos.
Para un gran lote de actualizaciones en los datos históricos, considere la posibilidad de usar un CTAS para escribir los datos que desea mantener en una tabla en lugar de usar INSERT, UPDATE y DELETE.
Mantenimiento de estadísticas
Es importante actualizar las estadísticas a medida que se producen cambios significativos en los datos. Consulte las estadísticas de actualización para determinar si se han producido cambios significativos . Las estadísticas actualizadas optimizan los planes de consulta. Si observa que tarda demasiado tiempo en mantener todas las estadísticas, sea más selectivo sobre qué columnas tienen estadísticas.
También puede definir la frecuencia de las actualizaciones. Por ejemplo, es posible que desee actualizar columnas de fecha, donde se pueden agregar nuevos valores a diario. Obtiene la mayor ventaja al tener estadísticas sobre las columnas implicadas en combinaciones, columnas usadas en la cláusula WHERE y columnas que se encuentran en GROUP BY.
Obtenga más información sobre las estadísticas.
Clase de recurso
Los grupos de recursos se usan como una manera de asignar memoria a las consultas. Si necesita más memoria para mejorar la velocidad de carga o consulta, debe asignar clases de recursos más altas. Al contrario, el uso de clases de recursos más grandes afecta a la simultaneidad. Debería tenerlo en cuenta antes de mover a todos sus usuarios a una gran clase de recursos.
Si observa que las consultas tardan demasiado tiempo, compruebe que los usuarios no ejecuten consultas en clases de recursos extensas. Las clases de recursos grandes consumen muchos espacios de concurrencia. Pueden hacer que otras consultas se pongan en cola.
Por último, mediante gen2 del grupo de SQL dedicado (anteriormente SQL DW), cada clase de recurso obtiene 2,5 veces más memoria que Gen1.
Obtenga más información sobre cómo trabajar con clases de recursos y simultaneidad.
Reducir el costo
Una característica clave de Azure Synapse es la capacidad de administrar recursos de proceso. Puede desactivar el grupo de SQL dedicado (anteriormente SQL DW) cuando no lo use, lo que detiene la facturación de los recursos de computación. Puede escalar los recursos para satisfacer las demandas de rendimiento. Para pausar, use el portal Azure o PowerShell. Para escalar, use el portal Azure, PowerShell, T-SQL o una API REST.
Escalado automático ahora en el momento que quiera con Azure Functions:
Optimización de la arquitectura para el rendimiento
Recomendamos considerar SQL Database y Azure Analysis Services en una arquitectura hub-and-spoke. Esta solución puede proporcionar aislamiento de carga de trabajo entre distintos grupos de usuarios, al tiempo que también usa características de seguridad avanzadas de SQL Database y Azure Analysis Services. También es una manera de proporcionar simultaneidad ilimitada a los usuarios.
Obtenga más información sobre las arquitecturas típicas que aprovechan el pool SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics.
Implemente los nodos en bases de datos SQL desde un pool SQL dedicado (anteriormente SQL DW).