Cuaderno de estrategias de POC de Synapse: almacenamiento de datos con grupos de SQL dedicados en Azure Synapse Analytics

En este artículo se presenta una metodología de alto nivel para preparar y ejecutar un proyecto eficaz de prueba de concepto (POC) de Azure Synapse Analytics para un grupo de SQL dedicado.

Nota

Este artículo forma parte de la serie de artículos Cuaderno de estrategias de prueba de concepto de Azure Synapse. Para información general sobre la serie, consulte Cuaderno de estrategias de prueba de concepto de Azure Synapse.

Sugerencia

Si no está familiarizado con los grupos de SQL dedicados, se recomienda que siga la ruta de aprendizaje Trabajar con almacenamientos de datos mediante Azure Synapse Analytics.

Preparación para la prueba de concepto

Antes de decidir los objetivos de la prueba de concepto de Azure Synapse, se recomienda leer primero el artículo Arquitectura de Azure Synapse SQL para familiarizarse con cómo un grupo de SQL dedicado separa el proceso y el almacenamiento para proporcionar un rendimiento líder del sector.

Identificación de patrocinadores y posibles impedimentos

Una vez que esté familiarizado con Azure Synapse, es el momento de asegurarse de que su POC tiene el respaldo necesario y no se tropieza con ningún impedimento. Debería hacer lo siguiente:

  • Identificar las restricciones o directivas que tiene su organización respecto al traslado de datos y el almacenamiento de datos en la nube.
  • Identificar el patrocinio ejecutivo y empresarial de un proyecto de almacenamiento de datos basado en la nube.
  • Comprobar que la carga de trabajo es adecuada para Azure Synapse. Para más información, consulte Arquitectura de grupos de SQL dedicados en Azure Synapse Analytics.

Establecimiento de la escala de tiempo

Una prueba de concepto es un ejercicio con un ámbito definido y limitado en el tiempo con objetivos y métricas específicos y medibles que definen el éxito. Lo ideal es que tenga alguna base en la realidad empresarial para que los resultados sean significativos.

Las pruebas de concepto tienen el mejor resultado cuando tienen un tiempo asignado. Tiempo asignado significa que se asigna una unidad de tiempo fija y máxima a una actividad. En nuestra experiencia, dos semanas es tiempo suficiente para completar el trabajo sin la carga de demasiados casos de uso o matrices de pruebas complejas. En este período de tiempo fijo, se recomienda seguir esta escala de tiempo:

  1. Carga de datos: tres días o menos.
  2. Consulta: cinco días o menos.
  3. Pruebas de valor añadido: dos días o menos.

A continuación se incluyen algunas sugerencias:

  • Realice estimaciones realistas del tiempo que necesitará para completar las tareas del plan.
  • Reconozca que el tiempo de finalización de la prueba de concepto estará relacionado con el tamaño del conjunto de datos, el número de objetos de base de datos (tablas, vistas y procedimientos almacenados), la complejidad de los objetos de base de datos y el número de interfaces que probará.
  • Si calcula que su prueba de concepto se ejecutará durante más de cuatro semanas, considere la posibilidad de reducir el ámbito para centrarse solo en los objetivos más importantes.
  • Obtenga el apoyo de todos los recursos principales y patrocinadores mientras dura el proyecto antes de comenzar la prueba de concepto.

Cuando haya determinado que no hay ningún obstáculo inmediato y haya establecido la escala de tiempo, puede definir el ámbito de una arquitectura de alto nivel.

Creación de una arquitectura con ámbito de alto nivel

Una arquitectura futura de alto nivel probablemente contiene muchos orígenes de datos y consumidores de datos, componentes de macrodatos y, posiblemente, consumidores de datos de inteligencia artificial y aprendizaje automático. Para mantener la viabilidad de los objetivos de la prueba de concepto (y dentro de los límites de la escala de tiempo establecida), decida cuál de estos componentes formará parte de la prueba de concepto y cuál se excluirá.

Además, si ya usa Azure, identifique lo siguiente:

  • Los recursos de Azure existentes que pueda usar durante la prueba de concepto. Por ejemplo, los recursos pueden incluir Microsoft Entra ID o Azure ExpressRoute.
  • Qué regiones de Azure prefiere su organización.
  • Una suscripción que pueda usar para el trabajo de la prueba de concepto que no sea de producción.
  • El rendimiento de la conexión de red a Azure.

    Importante

    Asegúrese de comprobar que la prueba de concepto puede consumir parte de ese rendimiento sin tener un efecto adverso sobre las soluciones de producción.

Aplicación de opciones de migración

Si va a migrar desde un sistema de almacenamiento de datos heredado a Azure Synapse, estas son algunas preguntas que debe tener en cuenta:

  • ¿Va a migrar y quiere hacer el menor número posible de cambios en los procesos existentes de extracción, transformación y carga (ETL) y en el consumo del almacén de datos?
  • ¿Va a migrar pero quiere realizar algunas mejoras exhaustivas durante el proceso?
  • ¿Va a crear un entorno de análisis de datos completamente nuevo (a veces denominado proyecto Greenfield)?

A continuación, debe tener en cuenta sus puntos débiles.

Identificación de los puntos débiles actuales

Su prueba de concepto debe contener casos de uso para demostrar posibles soluciones para abordar los puntos débiles actuales. Estas son algunas preguntas que debe tener en cuenta:

  • ¿Qué lagunas en la implementación actual espera que cubra Azure Synapse?
  • ¿Qué nuevas necesidades empresariales debe respaldar?
  • ¿Qué Acuerdos de Nivel de Servicio (SLA) deben cumplir?
  • ¿Cuáles serán las cargas de trabajo (por ejemplo, ETL, consultas por lotes, análisis, consultas de informes o consultas interactivas)?

A continuación, debe establecer los criterios de éxito de su prueba de concepto.

Establecimiento de criterios de éxito de la prueba de concepto

Identifique por qué hace una prueba de concepto y asegúrese de definir objetivos claros. También es importante saber qué resultados desea de la prueba de concepto y lo que planea hacer con ellos.

Tenga en cuenta que una prueba de concepto debe ser un trabajo corto y bien enfocado para demostrar o probar rápidamente un conjunto limitado de conceptos. Si tiene una larga lista de elementos que quiere probar, lo más conveniente será profundizar en varias pruebas de concepto. Las pruebas de concepto pueden tener vías de paso entre ellas para que se pueda determinar si se debe continuar con la siguiente prueba de concepto.

Estos son algunos objetivos de ejemplo de una prueba de concepto:

  • Es necesario saber que el rendimiento de las consultas de nuestras consultas de informes grandes y complejas satisfará los nuevos Acuerdos de Nivel de Servicio.
  • Es necesario conocer el rendimiento de las consultas para nuestros usuarios interactivos.
  • Necesitamos saber si nuestros procesos ETL existentes son una buena opción y dónde deben realizarse mejoras.
  • Necesitamos saber si podemos acortar los tiempos de ejecución de ETL y cuánto.
  • Necesitamos saber que Synapse Analytics tiene suficientes funcionalidades de seguridad para proteger adecuadamente nuestros datos.

A continuación, debe crear un plan de prueba.

Creación de un plan de pruebas

Usando sus objetivos, identifique pruebas específicas que se ejecutarán con el fin de respaldar esos objetivos y proporcionar los resultados identificados. Es importante asegurarse de que tiene al menos una prueba para cada objetivo y el resultado esperado. Identifique consultas, informes, ETL y otros procesos específicos que ejecutará para proporcionar resultados cuantificables.

Para refinar las pruebas, agregue varios escenarios de prueba con el fin de aclarar las preguntas de estructura de tabla que surjan.

Normalmente, un buen planeamiento define una ejecución eficaz de una prueba de concepto. Asegúrese de que todas las partes interesadas acuerden un plan de pruebas escrito que vincule cada objetivo de la prueba de concepto a un conjunto de casos de prueba y medidas de éxito claramente indicados.

La mayoría de los planes de prueba giran en torno al rendimiento y a la experiencia de usuario esperada. A continuación se muestra un ejemplo de un plan de pruebas. Es importante personalizar el plan de pruebas para satisfacer sus requisitos empresariales. Definir claramente lo que se está probando dará sus frutos más adelante en este proceso.

Objetivo Prueba Resultados esperados
Es necesario saber que el rendimiento de nuestras consultas de informes grandes y complejas satisfará los nuevos Acuerdos de Nivel de Servicio. - Prueba secuencial de consultas complejas.
- Prueba de simultaneidad de consultas complejas con respecto a los Acuerdos de Nivel de Servicio indicados.
- Consultas A, B y C completadas en 10, 13 y 21 segundos, respectivamente.
- Con 10 usuarios simultáneos, consultas A, B y C completadas en 11, 15 y 23 segundos, por término medio.
Es necesario conocer el rendimiento de las consultas de nuestros usuarios interactivos. - Prueba de simultaneidad de las consultas seleccionadas en un nivel de simultaneidad esperada de 50 usuarios.
- Ejecución de la consulta anterior con almacenamiento en caché del conjunto de resultados.
- En 50 usuarios simultáneos, se espera que el tiempo de ejecución promedio sea inferior a 10 segundos y sin almacenamiento en caché del conjunto de resultados.
- En 50 usuarios simultáneos, se espera que el tiempo de ejecución promedio sea inferior a cinco segundos con almacenamiento en caché del conjunto de resultados.
Es necesario saber si nuestros procesos ETL existentes se pueden ejecutar dentro del Acuerdo de Nivel de Servicio. - Ejecución de uno o dos procesos ETL para imitar las cargas de producción. - La carga incremental en una tabla de hechos principal debe completarse en menos de 20 minutos (incluido el almacenamiento provisional y la limpieza de datos).
- El procesamiento de dimensiones debe tardar menos de cinco minutos.
Es necesario saber que el almacenamiento de datos tiene suficientes funcionalidades de seguridad para proteger nuestros datos. - Revisión y habilitación de la seguridad de red (VNet y puntos de conexión privados), el control de acceso (seguridad de nivel de fila, enmascaramiento dinámico de datos). - Probar que los datos nunca abandonan nuestro inquilino.
- Asegurarse de que el contenido del cliente está protegido fácilmente.

A continuación, debe identificar y validar el conjunto de datos de la prueba de concepto.

Identificación y validación del conjunto de datos de prueba de concepto

Con las pruebas con ámbito, ahora puede identificar el conjunto de datos necesario para ejecutar esas pruebas en Azure Synapse. Revise el conjunto de datos teniendo en cuenta lo siguiente:

  • Compruebe que el conjunto de datos representa adecuadamente el conjunto de datos de producción en términos de contenido, complejidad y escala.
  • No use un conjunto de datos demasiado pequeño (menos de 1 TB), ya que podría no lograr un rendimiento representativo.
  • No use un conjunto de datos demasiado grande, ya que la prueba de concepto no está pensada para completar una migración completa de los datos.
  • Identifique el patrón de distribución, la opción de indexación y la creación de particiones para cada tabla. Si hay alguna pregunta relacionada con la distribución, la indexación o la creación de particiones, agregue pruebas a su prueba de concepto para responderlas. Tenga en cuenta que es posible que quiera probar más de una opción de distribución o de indexación en algunas tablas.
  • Consulte con los propietarios de la empresa si existe algún impedimento para mover el conjunto de datos de prueba de concepto a la nube.
  • Identifique los problemas de seguridad o privacidad.

Importante

Asegúrese de comprobar con los propietarios empresariales que no existan impedimentos para mover los datos a la nube. Identifique cualquier problema de seguridad o privacidad o cualquier necesidad de ofuscación de datos que se deba resolver antes de mover los datos a la nube.

A continuación, debe reunir al equipo de expertos.

Reunión del equipo

Identifique los miembros del equipo y su compromiso de apoyar la prueba de concepto. Los miembros del equipo deben incluir los siguientes:

  • Jefe de proyecto para ejecutar el proyecto de prueba de concepto.
  • Representante empresarial para supervisar los requisitos y los resultados.
  • Experto en datos de aplicación para obtener los datos del conjunto de datos de prueba de concepto.
  • Especialista en Azure Synapse.
  • Asesor experto para optimizar las pruebas de concepto.
  • Cualquier persona que sea necesaria para algunas tareas concretas del proyecto de prueba de concepto, pero no todo el tiempo. Estos recursos auxiliares podrían incluir administradores de red, administradores de Azure o administradores de Microsoft Entra.

Sugerencia

Se recomienda acudir a un asesor experto para que le ayude con la prueba de concepto. La comunidad de partners de Microsoft tiene disponibilidad mundial de consultores expertos que pueden ayudarle a valorar, evaluar, evaluar o implementar Azure Synapse.

Ahora que está totalmente preparado, es el momento de poner en práctica su prueba de concepto.

Puesta en práctica de la prueba de concepto

Es importante tener en cuenta los siguientes aspectos:

  • Implemente el proyecto de prueba de concepto con la disciplina y el rigor de cualquier proyecto de producción.
  • Ejecute la prueba de concepto según el plan.
  • Tenga implementado un proceso de solicitud de cambios para evitar que el ámbito de la prueba de concepto crezca o cambie.

Antes de que se puedan iniciar las pruebas, debe configurar el entorno de prueba. Este proceso conlleva cuatro fases:

  1. Configurar
  2. Carga de datos
  3. Consultas
  4. Pruebas de valor agregado

Image shows the four test environment stages: Setup, Data loading, Querying, and Value added tests.

Instalación

Puede configurar una prueba de concepto en Azure Synapse siguiendo estos pasos:

  1. Use este inicio rápido para aprovisionar un área de trabajo de Synapse y configurar el almacenamiento y los permisos según el plan de pruebas de la prueba de concepto.
  2. Use este inicio rápido para agregar un grupo de SQL dedicado al área de trabajo de Synapse.
  3. Configure las redes y la seguridad según sus requisitos.
  4. Conceda el acceso adecuado a los miembros del equipo de la prueba de concepto. Consulte este artículo sobre la autenticación y la autorización para acceder a grupos de SQL dedicados.

Sugerencia

Se recomienda desarrollar código y pruebas unitarias mediante el nivel de servicio DW500c (o inferior). Se recomienda ejecutar pruebas de carga y rendimiento mediante el nivel de servicio DW1000c (o superior). Puede pausar el proceso del grupo de SQL dedicado en cualquier momento para detener la facturación del proceso y así ahorrar costos.

Carga de datos

Una vez configurado el grupo de SQL dedicado, puede seguir estos pasos para cargar datos:

  1. Cargue los datos en Azure Blob Storage. En una prueba de concepto, se recomienda usar una cuenta de almacenamiento de uso general V2 con almacenamiento con redundancia local (LRS). Aunque hay varias herramientas para migrar datos a Azure Blob Storage, la manera más fácil es usar el Explorador de Azure Storage, que permite copiar archivos en un contenedor de almacenamiento.
  2. Cargue los datos en el grupo de SQL dedicado. Azure Synapse admite dos métodos de carga de T-SQL: PolyBase y la instrucción COPY. Puede usar SSMS para conectarse al grupo de SQL dedicado para usar cualquiera de los métodos.

Al cargar datos en el grupo de SQL dedicado por primera vez, debe tener en cuenta qué patrón de distribución y opción de índice usar. Aunque un grupo de SQL dedicado admite una variedad de ambos, se recomienda confiar en la configuración predeterminada. La configuración predeterminada usa la distribución round robin y un índice de almacén de columnas agrupado. Si es necesario, puede ajustar esta configuración posteriormente (más adelante en este artículo se describe cómo hacerlo).

En el ejemplo siguiente se muestra el método de carga COPY:

--Note when specifying the column list, input field numbers start from 1
COPY INTO
    test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
    'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
    FILE_TYPE = 'CSV',
    CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
    FIELDQUOTE = '"',
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '0x0A',
    ENCODING = 'UTF8',
    FIRSTROW = 2
);

Consultas

La finalidad principal de un almacenamiento de datos es realizar análisis, lo que requiere consultar el almacenamiento de datos. La mayoría de las pruebas de concepto comienzan ejecutando un pequeño número de consultas representativas en el almacenamiento de datos, al principio secuencialmente y después simultáneamente. Debe definir ambos enfoques en el plan de pruebas.

Pruebas de consulta secuencial

Es fácil ejecutar pruebas de consulta secuencial en SSMS. Es importante ejecutar estas pruebas con un usuario que tenga una clase de recursos suficientemente grande. Las clases de recursos son límites de recursos predeterminados en el grupo de SQL dedicado que rigen los recursos de proceso y la simultaneidad de la ejecución de las consultas. En el caso de consultas sencillas, se recomienda usar la clase de recursos staticrc20 predefinida. Para consultas más complejas, se recomienda usar la clase de recursos staticrc40 predefinida.

Observe que la primera consulta siguiente usa una etiqueta de consulta para proporcionar un mecanismo de seguimiento de la consulta. La segunda consulta usa la vista de administración dinámica sys.dm_pdw_exec_requests para buscar por la etiqueta.

/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
    *
FROM
    [dbo].[Date]
OPTION (LABEL = 'Test1');

/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
    Total_elapsed_time AS [Elapsed_Time_ms],
    [label]
FROM
    sys.dm_pdw_exec_requests
WHERE
    [label] = 'Test1';

Pruebas de consultas simultáneas

Después de registrar el rendimiento de las consultas secuenciales, puede ejecutar varias consultas simultáneas. De este modo, puede simular una carga de trabajo de inteligencia empresarial que se ejecuta en el grupo de SQL dedicado. La manera más fácil de ejecutar esta prueba es descargar una herramienta de prueba de esfuerzo. La herramienta más conocida es Apache JMeter, que es una herramienta de código abierto de terceros.

La herramienta informa sobre duraciones de consulta mínima, máxima y media para un nivel de simultaneidad determinado. Por ejemplo, supongamos que quiere simular una carga de trabajo de inteligencia empresarial que genera 100 consultas simultáneas. Puede configurar JMeter para ejecutar esas 100 consultas simultáneas en un bucle y, luego, revisar la ejecución del estado estable. Se puede hacer con el almacenamiento en caché del conjunto de resultados activado o desactivado para evaluar la idoneidad de esa característica.

Asegúrese de documentar los resultados. Este es un ejemplo de algunos resultados:

Simultaneidad N.º de ejecuciones de consultas DWU Duraciones mínimas Duraciones máximas Duraciones medias
100 1,000 5\.000 3 10 5
50 5\.000 5\.000 3 6 4

Pruebas de carga de trabajo mixtas

Las pruebas de cargas de trabajo mixtas son una extensión de las pruebas de consultas simultáneas. Al agregar un proceso de carga de datos a la combinación de cargas de trabajo, la carga de trabajo simulará mejor una carga de trabajo de producción real.

Optimización de los datos

Según la carga de trabajo de consulta que se ejecuta en Azure Synapse, es posible que tenga que optimizar las distribuciones y los índices del almacenamiento de datos y volver a ejecutar las pruebas. Para más información, consulte Procedimientos recomendados para grupos de SQL dedicados en Azure Synapse Analytics.

Los errores más comunes detectados durante la instalación son:

  • Las consultas grandes se ejecutan con una clase de recursos demasiado baja.
  • Las DWU de nivel de servicio del grupo de SQL dedicado son demasiado bajas para la carga de trabajo.
  • Las tablas grandes requieren la distribución de valores hash.

Para mejorar el rendimiento de las consultas, puede hacer lo siguiente:

Pruebas de valor agregado

Una vez completadas las pruebas de rendimiento de las consultas, es un buen momento para probar características específicas a fin de comprobar que satisfacen los casos de uso previstos. Estas características son:

Por último, debe interpretar los resultados de la prueba de concepto.

Interpretación de los resultados de la prueba de concepto

Cuando haya probado los resultados de la prueba del almacenamiento de datos, es importante interpretar esos datos. Un enfoque común que puede adoptar es comparar las ejecuciones en términos de precio/rendimiento. En pocas palabras, el precio/rendimiento elimina las diferencias de precio por hardware de servicio o DWU y proporciona un número único comparable para cada prueba de rendimiento.

Este es un ejemplo:

Prueba Duración de la prueba DWU USD/h de DWU Costo de la prueba
Prueba 1 10 min 1000 12 USD/h 2 $
Prueba 2 30 min 500 6 USD/h $3

Este ejemplo permite ver fácilmente que la prueba 1 con DWU1000 es más rentable a 2 USD por ejecución de pruebas en comparación con 3 USD por ejecución de pruebas.

Nota

También puede usar esta metodología para comparar los resultados entre los proveedores en una prueba de concepto.

En resumen, una vez completadas todas las pruebas de la prueba de concepto, estará listo para evaluar los resultados. Empiece por evaluar si se han cumplido los objetivos de la prueba de concepto y los resultados deseados recopilados. Anote los casos en los que se justifica la realización de pruebas adicionales y otras cuestiones que se plantearon.

Pasos siguientes