Metodología de éxito en la implementación de Synapse: evaluación del entorno

Nota

Este artículo forma parte de la serie de artículos Éxito en la implementación de Azure Synapse por diseño. Para más información general sobre la serie, consulte Implementación correcta de Azure Synapse por diseño.

El primer paso al implementar Azure Synapse Analytics es llevar a cabo una evaluación del entorno. Una valoración le proporciona la oportunidad de recopilar toda la información disponible sobre el entorno, los requisitos ambientales, los requisitos del proyecto, las restricciones, las escalas de tiempo y los puntos de dificultad existentes. Esta información formará la base de las evaluaciones posteriores y las actividades de punto de comprobación. Será de gran valor cuando llegue el momento de asegurarse y comparar con la solución del proyecto a medida que se planee, diseñe y desarrolle. Le recomendamos que dedique una gran cantidad de tiempo a recopilar toda la información y se asegure de tener las conversaciones necesarias con los grupos apropiados. Entre estos grupos se pueden incluir partes interesadas del proyecto, usuarios empresariales, diseñadores de soluciones y expertos en la materia (SME) de la solución y el entorno existentes.

La valoración se convertirá en una guía que le ayudará a evaluar el diseño de la solución y a realizar recomendaciones de tecnología informadas para implementar Azure Synapse.

Valoración de la carga de trabajo

La valoración de la carga de trabajo se preocupa por el entorno, los roles de carga de trabajo analíticos, ETL/ELT, las redes y la seguridad, el entorno de Azure y el consumo de datos.

Entorno

Para el entorno, evalúe los puntos siguientes.

• Describa la carga de trabajo analítica existente:
  • ¿Qué son las cargas de trabajo (como el almacenamiento de datos o los macrodatos)?
  • ¿Cómo ayuda esta carga de trabajo a la empresa? ¿Qué son los escenarios de casos de uso?
  • ¿Cuál es el impulsor empresarial de esta plataforma analítica y de una posible migración?
  • Recopile detalles sobre las opciones de arquitectura, diseño e implementación existentes.
  • Recopile detalles sobre todos los componentes dependientes ascendentes y descendentes y los consumidores existentes.
• ¿Va a migrar un almacenamiento de datos existente (como Microsoft SQL Server, Microsoft Analytics Platform System (APS), Netezza, Snowflake o Teradata)?
• ¿Va a migrar una plataforma de macrodatos (como Cloudera o Hortonworks)?
• Recopile los diagramas de arquitectura y flujo de datos para el entorno analítico actual.
• ¿Dónde se encuentran los orígenes de datos de las cargas de trabajo analíticas planeadas (Azure, otros proveedores de nube o locales)?
• ¿Cuál es el tamaño total de los conjuntos de datos existentes (históricos e incrementales)? ¿Cuál es la tasa actual de crecimiento del conjunto o conjuntos de datos? ¿Cuál es la tasa de crecimiento proyectada de los conjuntos de datos durante los próximos 2-5 años?
• ¿Tiene algún lago de datos existente? Recopile tantos detalles como sea posible sobre los tipos de archivo (como Parquet o CSV), los tamaños de archivo y la configuración de seguridad.
• ¿Tiene datos semiestructurados o no estructurados para procesar y analizar?
• Describa la naturaleza del procesamiento de datos (procesamiento por lotes o en tiempo real).
• ¿Necesita una exploración interactiva de datos a partir de datos relacionales, lago de datos u otros orígenes?
• ¿Necesita análisis y exploración de datos en tiempo real desde orígenes de datos operativos?
• ¿Qué son los puntos de dificultad y las limitaciones en el entorno actual?
• ¿Qué herramientas de control de código fuente y DevOps usa actualmente?
• ¿Tiene un caso de uso para crear una solución de análisis híbrida (en la nube y local), solo en la nube o en varias nubes?
• Recopile información sobre el entorno de nube existente. ¿Es un proveedor de nube única o un proveedor de varias nubes?
• Recopile planes sobre el futuro entorno en la nube. ¿Será un proveedor de nube única o un proveedor de varias nubes?
• ¿Qué son los requisitos de RPO/RTO/HA/SLA en el entorno existente?
• ¿Qué son los requisitos de RPO/RTO/HA/SLA en el entorno planeado?

Roles de carga de trabajo analíticos

Para los roles de carga de trabajo analíticos, evalúe los siguientes puntos.

• Describa los distintos roles (científico de datos, ingeniero de datos, analista de datos y otros).
• Describa el requisito de control de acceso de la plataforma analítica para estos roles.
• Identifique al propietario de la plataforma responsable de aprovisionar recursos de proceso y conceder acceso.
• Describa cómo colaboran actualmente los distintos roles de datos.
• ¿Hay varios equipos que colaboran en la misma plataforma analítica? Si es así, ¿cuáles son los requisitos de control de acceso y aislamiento para cada uno de estos equipos?
• ¿Cuáles son las herramientas de cliente que usan los usuarios finales para interactuar con la plataforma analítica?

ETL/ELT, transformación y orquestación

Para ETL/ELT, transformación y orquestación, evalúe los puntos siguientes.

• ¿Qué herramientas usa hoy para la ingesta de datos (ETL o ELT)?
• ¿Dónde existen estas herramientas en el entorno existente (local o en la nube)?
• ¿Qué son los requisitos actuales de carga y actualización de datos (en tiempo real, microlotes, por hora, diarios, semanales o mensuales)?
• Describa los requisitos de transformación de cada nivel (macrodatos, lago de datos, almacenamiento de datos).
• ¿Cuál es el enfoque de programación actual para transformar los datos (sin código, poco código, programación como SQL, Python, Scala, C# u otros)?
• ¿Cuál es el enfoque de programación planeado preferido para transformar los datos (sin código, poco código, programación como SQL, Python, Scala, C# u otros)?
• ¿Qué herramientas se usan actualmente para la orquestación de datos con el fin de automatizar el proceso controlado por datos?
• ¿Dónde se encuentran los orígenes de datos de su ETL existente (Azure, otro proveedor de nube o local)?
• ¿Qué son las herramientas de consumo de datos existentes (informes, herramientas de BI, herramientas de código abierto) que requieren la integración con la plataforma analítica?
• ¿Qué son las herramientas de consumo de datos planeadas (informes, herramientas de BI, herramientas de código abierto) que requerirán la integración con la plataforma analítica?

Redes y seguridad

Para las redes y la seguridad, evalúe los siguientes puntos.

• ¿Qué requisitos normativos tiene para los datos?
• Si los datos incluyen contenido del cliente, datos del sector de tarjetas de pago (PCI) o de la Ley de Portabilidad y Responsabilidad de Seguros de Salud de 1996 (HIPAA), ¿cuenta el grupo de seguridad con Azure certificado para estos datos? Si es así, ¿para qué servicios de Azure?
• Describa los requisitos de autenticación y autorización de usuario.
• ¿Hay problemas de seguridad que podrían limitar el acceso a los datos durante la implementación?
• ¿Hay datos de prueba disponibles para utilizarlos durante el desarrollo y las pruebas?
• Describa los requisitos de seguridad de red de la organización en el proceso analítico y el almacenamiento (red privada, red pública o restricciones de firewall).
• Describa los requisitos de seguridad de red para que las herramientas del cliente accedan al almacenamiento y al proceso analítico (red emparejada, punto de conexión privado u otros).
• Describa la configuración de red actual entre el entorno local y Azure (Azure ExpressRoute, de sitio a sitio u otros).

Use las siguientes listas de comprobación de los posibles requisitos para guiar su valoración.

• Protección de datos:
  • Cifrado de datos en tránsito
  • Cifrado en reposo (claves predeterminadas o claves administradas por el cliente)
  • Clasificación y detección de datos
• Control de acceso:
  • Seguridad de nivel de objeto
  • Seguridad de nivel de fila
  • Seguridad de nivel de columna
  • Enmascaramiento de datos dinámicos
• Autenticación:
  • Inicio de sesión de SQL
  • Microsoft Entra ID
  • Multi-Factor Authentication (MFA)
• Seguridad de redes:
  • Redes virtuales
  • Firewall
  • Azure ExpressRoute
• Protección contra amenazas:
  • Detección de amenazas
  • Auditoría
  • Evaluación de vulnerabilidades

Para más información, consulte las notas del producto sobre seguridad de Azure Synapse Analytics.

Entorno de Azure

Para el entorno de Azure, evalúe los puntos siguientes.

• ¿Actualmente usa Azure? ¿Se utiliza para cargas de trabajo de producción?
• Si usa Azure, ¿qué servicios utiliza? ¿Qué regiones usa?
• ¿Utiliza Azure ExpressRoute? ¿Cuál es su ancho de banda?
• ¿Tiene la aprobación del presupuesto para aprovisionar los servicios de Azure necesarios?
• ¿Cómo aprovisiona y administra actualmente los recursos (Azure Resource Manager (ARM) o Terraform)?
• ¿Están familiarizados los miembros clave de su equipo con Synapse Analytics? ¿Se requiere algún aprendizaje?

Consumo de datos

Para el consumo de datos, evalúe los puntos siguientes.

• Describa qué herramientas usa actualmente y cómo para realizar actividades como ingesta, exploración, preparación y visualización de datos.
• Identifique qué herramientas planea usar para realizar actividades como ingesta, exploración, preparación y visualización de datos.
• ¿Qué aplicaciones están planeadas para interactuar con la plataforma analítica (Microsoft Power BI, Microsoft Excel, Microsoft SQL Server Reporting Services, Tableau u otros)?
• Identifique todos los consumidores de datos.
• Identifique los requisitos de exportación de datos y uso compartido de datos.

Valoración de servicios de Azure Synapse

La valoración de servicios de Azure Synapse se ocupa de los servicios de Azure Synapse. Azure Synapse tiene los siguientes componentes para el proceso y el movimiento de datos:

• Synapse SQL: sistema de consultas distribuidas para Transact-SQL (T-SQL) que permite escenarios de almacenamiento y virtualización de datos. También amplía T-SQL para abordar escenarios de streaming y aprendizaje automático (ML). Synapse SQL ofrece modelos de recurso sin servidor y dedicados.
• Grupo de SQL sin servidor: es un sistema de procesamiento de datos distribuido, creado para datos a gran escala y funciones computacionales. No hay infraestructuras que haya que configurar o clústeres que mantener. Este servicio es adecuado para cargas de trabajo no planeadas o de ráfaga. Entre los escenarios recomendados se incluyen la exploración rápida de datos en archivos directamente en el lago de datos, el almacenamiento de datos lógico y la transformación de datos sin procesar.
• Grupo de SQL dedicado: representa una colección de recursos de análisis que se aprovisionan al usar Synapse SQL. El tamaño de un grupo de SQL dedicado (anteriormente SQL DW) se determina mediante las unidades de almacenamiento de datos (DWU). Este servicio es adecuado para un almacenamiento de datos con cargas de trabajo continuas predecibles y de alto rendimiento en los datos almacenados en tablas SQL. 
• Grupo de Apache Spark: se integra profundamente y sin fisuras en Apache Spark, que es el motor de macrodatos de código abierto más popular que se usa para la preparación de datos, la ingeniería de datos, ETL y ML.
• Canalización de integración de datos: Azure Synapse contiene el mismo motor de integración de datos y experiencias que Azure Data Factory (ADF). Permiten crear canalizaciones de ETL enriquecidas a escala sin salir de Azure Synapse.

Para ayudarle a determinar el mejor tipo de grupo de SQL (dedicado o sin servidor), evalúe los siguientes puntos.

• ¿Desea crear un almacenamiento de datos relacional tradicional reservando la capacidad de procesamiento de los datos almacenados en tablas SQL?
• ¿Los casos de uso exigen un rendimiento predecible?
• ¿Desea crear un almacenamiento de datos lógico a partir de un lago de datos?
• ¿Desea consultar datos directamente desde un lago de datos?
• ¿Desea explorar datos de un lago de datos?

En la tabla siguiente se comparan los dos tipos de grupos de Synapse SQL.

De comparación	Grupo de SQL dedicado	Grupo de SQL sin servidor
Propuestas de valor	Funcionalidades totalmente administradas de un almacenamiento de datos. Rendimiento predecible y de alto rendimiento para cargas de trabajo continuas. Optimizado para datos administrados (cargados).	Fácil para comenzar a trabajar con él y explorar los datos del lago de datos. Mejor costo total de propiedad (TCO) para cargas de trabajo ad hoc e intermitentes. Optimizado para consultar datos en un lago de datos.
Cargas de trabajo	Ideal para cargas de trabajo continuas. La carga aumenta el rendimiento, con mayor complejidad. La carga por unidad de almacenamiento de datos (si tiene un tamaño correcto) será rentable.	Ideal para cargas de trabajo ad hoc o intermitentes. No es necesario cargar datos, por lo que se facilita el inicio y la ejecución. La carga por uso será rentable.
Rendimiento de las consultas	Ofrece alta simultaneidad y baja latencia. Admite opciones de almacenamiento en caché enriquecidas, incluidas las vistas materializadas. Existe la posibilidad de elegir ventajas y desventajas con la administración de cargas de trabajo (WLM).	No es adecuado para las consultas de paneles. No se esperan tiempos de respuesta de milisegundos. Solo funciona con datos externos.

Valoración del grupo de SQL dedicado

Para la valoración del grupo de SQL dedicado, evalúe los siguientes puntos de plataforma.

• ¿Cuál es la plataforma de almacenamiento de datos actual (Microsoft SQL Server, Netezza, Teradata, Greenplum u otros)?
• Para una carga de trabajo de migración, determine la marca y el modelo de la aplicación para cada entorno. Incluya detalles de las CPU, las GPU y la memoria.
• Para una migración de la aplicación, ¿cuándo se compró el hardware? ¿Se ha depreciado totalmente la aplicación? Si no es así, ¿cuándo finalizará la depreciación? ¿Y cuántos gastos de capital quedan?
• ¿Hay algún diagrama de arquitectura de hardware y red?
• ¿Dónde se encuentran los orígenes de datos del almacenamiento de datos planeado (Azure, otro proveedor de nube o local)?
• ¿Qué son las plataformas de hospedaje de datos de los orígenes de datos del almacenamiento de datos (Microsoft SQL Server, Azure SQL Database, DB2, Oracle, Azure Blob Storage, AWS, Hadoop u otros)?
• ¿Hay algún almacén de datos de orígenes de datos? Si es así, ¿cuáles?
• Identifique todos los escenarios de carga de datos, ETL y ELT (ventanas por lotes, streaming, casi en tiempo real). Identifique los acuerdos de nivel de servicio (SLA) existentes para cada escenario y documente los acuerdos de nivel de servicio que se esperan en el nuevo entorno.
• ¿Cuál es el tamaño actual del almacenamiento de datos?
• ¿Qué tasa de crecimiento del conjunto de datos se destina al grupo de SQL dedicado?
• Describa los entornos que usa actualmente (desarrollo, prueba o producción).
• ¿Qué herramientas están implementadas actualmente para el movimiento de datos (ADF, Microsoft SQL Server Integration Services (SSIS), robocopy, Informatica, SFTP u otras)?
• ¿Planea cargar datos en tiempo real o casi en tiempo real?

Evalúe los siguientes puntos de base de datos.

• ¿Cuál es el número de objetos de cada almacenamiento de datos (esquemas, tablas, vistas, procedimientos almacenados, funciones)?
• ¿Es un esquema de estrella, un esquema de copo de nieve u otro diseño?
• ¿Qué son las tablas más grandes en términos de tamaño y número de registros?
• ¿Qué son las tablas más anchas en términos del número de columnas?
• ¿Ya hay un modelo de datos diseñado para su almacenamiento de datos? ¿Es un diseño de esquema de estrella, Inmon o Kimball?
• ¿Están en uso las dimensiones de variación lenta (SCD)? Si es así, ¿qué tipos?
• ¿Se implementará un nivel semántico mediante data marts relacionales o Analysis Services (tabulares o multidimensionales) u otros productos?
• ¿Qué son los requisitos de archivado de datos/HA/RPO/RTO?
• ¿Qué son los requisitos de replicación de regiones?

Evalúe las siguientes características de carga de trabajo.

• ¿Cuál es el número estimado de usuarios o trabajos simultáneos que acceden al almacenamiento de datos durante las horas punta?
• ¿Cuál es el número estimado de usuarios o trabajos simultáneos que acceden al almacenamiento de datos fuera de las horas punta?
• ¿Hay algún período de tiempo en el que no habrá usuarios o trabajos?
• ¿Qué son las expectativas de rendimiento de ejecución de consultas para las consultas interactivas?
• ¿Qué son las expectativas de rendimiento de carga de datos para cargas o actualizaciones de datos diarias, semanales o mensuales?
• ¿Qué son las expectativas de ejecución de consultas para informes y consultas analíticas?
• ¿Qué complejidad tendrán las consultas ejecutadas con mayor frecuencia?
• ¿Qué porcentaje del tamaño total del conjunto de datos es el conjunto de datos activo?
• ¿Aproximadamente qué porcentaje de carga de trabajo se prevé para carga o actualización, procesamiento por lotes o informes, consultas interactivas y procesamiento analítico?
• Identifique los datos que consumen patrones y plataformas:
  • Método y herramientas de informes actuales y planeados.
  • ¿Qué aplicación o herramientas analíticas accederán al almacenamiento de datos?
  • ¿Número de consultas simultáneas?
  • ¿Número medio de consultas activas en un momento determinado?
  • ¿Cuál es la naturaleza del acceso a datos (interactivo, ad hoc, exportación u otros)?
  • Roles de datos y descripción completa de sus requisitos de datos.
  • Número máximo de conexiones simultáneas.
• Patrón de acuerdo de nivel de servicio de rendimiento de consultas por:
  • Usuarios del panel.
  • Informes por lotes.
  • Usuarios de ML.
  • Proceso de ETL.
• ¿Qué son los requisitos de seguridad para el entorno existente y para el nuevo entorno (seguridad de nivel de fila, seguridad de nivel de columna, control de acceso, cifrado y otros)?
• ¿Tiene requisitos para integrar la puntuación de modelos de ML con T-SQL?

Valoración del grupo de SQL sin servidor

El grupo de SQL sin servidor de Synapse admite tres casos de uso principales.

• Detección y exploración básicos: analice rápidamente datos de diversos formatos (Parquet, CSV y JSON) en el lago de datos, para que pueda planear cómo extraer información detallada de estos.
• Almacenamiento de datos lógico: proporcione una abstracción relacional a partir de datos sin procesar o dispares sin tener que reubicar y transformar los datos, lo que permite una vista actual de estos.
• Transformación de datos: una forma sencilla, escalable y eficaz de transformar los datos del lago mediante T-SQL, para que estos puedan alimentar a las herramientas de inteligencia empresarial o de cualquier otro tipo, o se carguen en un almacén de datos relacional (bases de datos de Synapse SQL, Azure SQL Database u otros).

Diferentes datos profesionales se pueden beneficiar del grupo de SQL sin servidor:

• Los ingenieros de datos pueden explorar el lago de datos, transformar y preparar los datos mediante este servicio y simplificar las canalizaciones de transformación de datos.
• Los científicos de datos pueden analizar rápidamente el contenido y la estructura de los datos del lago de datos gracias a características como OPENROWSET y la inferencia de esquemas automática.
• Los analistas de datos pueden explorar los datos y tablas externas de Spark que crean los científicos o ingenieros de datos mediante las conocidas instrucciones T-SQL o sus herramientas de consulta favoritas.
• Los profesionales de inteligencia empresarial pueden crear rápidamente informes de Power BI a partir de los datos del lago de datos y las tablas de Spark.

Nota

El lenguaje T-SQL se usa tanto en el grupo de SQL dedicado como en el grupo de SQL sin servidor, pero hay algunas diferencias en el conjunto de características admitidas. Para más información sobre las características de T-SQL admitidas en Synapse SQL (dedicado y sin servidor), consulte Características de Transact-SQL compatibles en Azure Synapse SQL.

Para la valoración del grupo de SQL sin servidor, evalúe los siguientes puntos.

• ¿Tiene casos de uso para detectar y explorar datos de un lago de datos mediante consultas relacionales (T-SQL)?
• ¿Tiene casos de uso para crear un almacenamiento de datos lógico a partir de un lago de datos?
• Identifique si hay casos de uso para transformar datos en el lago de datos sin mover antes los datos del lago de datos.
• ¿Los datos ya están en Azure Data Lake Storage (ADLS) o Azure Blob Storage?
• Si los datos ya están en ADLS, ¿tiene una buena estrategia de partición en el lago de datos?
• ¿Tiene datos operativos en Azure Cosmos DB? ¿Tiene casos de uso para el análisis en tiempo real en Azure Cosmos DB sin que afecte a las transacciones?
• Identifique los tipos de archivo en el lago de datos.
• Identifique el acuerdo de nivel de servicio de rendimiento de consultas. ¿El caso de uso exige un rendimiento y un costo predecibles?
• ¿Tiene cargas de trabajo analíticas de SQL no planeadas o por ráfagas?
• Identifique los datos que consumen patrones y plataformas:
  • Método y herramientas de informes actuales y planeados.
  • ¿Qué aplicación o herramientas analíticas accederán al grupo de SQL sin servidor?
  • Número medio de consultas activas en un momento dado.
  • ¿Cuál es la naturaleza del acceso a datos (interactivo, ad hoc, exportación u otros)?
  • Roles de datos y descripción completa de sus requisitos de datos.
  • Número máximo de conexiones simultáneas.
  • ¿Complejidad de la consulta?
• ¿Qué son los requisitos de seguridad (control de acceso, cifrado y otros)?
• ¿Cuál es la funcionalidad de T-SQL necesaria (procedimientos almacenados o funciones)?
• Identifique el número de consultas que se enviarán al grupo de SQL sin servidor y el tamaño del conjunto de resultados de cada consulta.

Sugerencia

Si no está familiarizado con los grupos de SQL sin servidor, se recomienda trabajar siguiendo la ruta de aprendizaje de Creación de soluciones de análisis de datos con grupos de SQL sin servidor de Azure Synapse.

Valoración del grupo de Spark

Los grupos de Spark en Azure Synapse permiten los siguientes escenarios clave.

• Ingeniería de datos/Preparación de datos: Apache Spark incluye muchas características de lenguaje para admitir la preparación y el procesamiento de grandes volúmenes de datos. La preparación y el procesamiento pueden hacer que los datos sean más valiosos y permitir que otros servicios de Azure Synapse los consuman. Es posible gracias a varios lenguajes (C#, Scala, PySpark, Spark SQL) y mediante las bibliotecas suministradas para el procesamiento y la conectividad.
• Machine Learning: Apache Spark incluye MLlib, una biblioteca de ML basada en Spark que puede usar desde un grupo de Spark. Los grupos de Spark también incluyen Anaconda, que es una distribución de Python que consta de varios paquetes para la ciencia de datos, incluido ML. Además, Apache Spark en Synapse proporciona bibliotecas preinstaladas para Microsoft Machine Learning, que es una plataforma de ML RESTful, elástico y con tolerancia a errores. Cuando se combinan con la compatibilidad integrada con cuadernos, dispone de un entorno enriquecido para crear aplicaciones de ML.

Nota

Para más información, consulte Apache Spark en Azure Synapse Analytics.

Asimismo, Azure Synapse es compatible con Delta Lake de Linux Foundation. Delta Lake es una capa de almacenamiento de código abierto que ofrece transacciones ACID (atomicidad, coherencia, aislamiento y durabilidad) para cargas de trabajo de macrodatos de Apache Spark. Para más información, consulte ¿Qué es Delta Lake?

Para la valoración del grupo de Spark, evalúe los puntos siguientes.

• Identifique las cargas de trabajo que requieren ingeniería de datos o preparación de datos.
• Defina claramente los tipos de transformaciones.
• Identifique si tiene datos no estructurados que se van a procesar.
• Al migrar desde una carga de trabajo de Spark o Hadoop existente:
  • ¿Cuál es la plataforma de macrodatos existente (Cloudera, Hortonworks, servicios en la nube u otros)?
  • Si se trata de una migración desde el entorno local, ¿se ha depreciado el hardware o han expirado las licencias? Si no es así, ¿cuándo se producirá la depreciación o la expiración?
  • ¿Cuál es el tipo de clúster existente?
  • ¿Qué son las bibliotecas necesarias y las versiones de Spark?
  • ¿Es una migración de Hadoop a Spark?
  • ¿Qué son los lenguajes de programación actuales o preferidos?
  • ¿Cuál es el tipo de carga de trabajo (macrodatos, ML u otros)?
  • ¿Qué son las herramientas de cliente y las plataformas de informes existentes y planeadas?
  • ¿Qué son los nuevos requisitos de seguridad?
  • ¿Existen puntos de dificultad y limitaciones actuales?
• ¿Tiene previsto usar o está utilizando actualmente Delta Lake?
• ¿Cómo administra los paquetes hoy?
• Identifique los tipos de clúster de proceso necesarios.
• Identifique si se requiere la personalización del clúster.

Sugerencia

Si no está familiarizado con los grupos de Spark, se recomienda trabajar siguiendo la ruta de aprendizaje de Realización de tareas de ingeniería de datos con grupos de Apache Spark en Azure Synapse.

Pasos siguientes

En el siguiente artículo de la serie Éxito de Azure Synapse por diseño, aprenda a evaluar el diseño del área de trabajo de Synapse y a asegurarse de que cumple las directrices y los requisitos.