Metodología de éxito de implementación de Synapse: evaluación del diseño del grupo de SQL sin servidor

Nota

Este artículo forma parte de la serie de artículos Éxito en la implementación de Azure Synapse por diseño. Para obtener información general sobre la serie, vea Éxito en la implementación de Azure Synapse por diseño.

Debe evaluar el diseño del your grupo de SQL sin servidor para identificar problemas y validar que cumple las instrucciones y los requisitos. Al evaluar el diseño antes de que comience el desarrollo de la solución, puede evitar obstáculos y cambios de diseño inesperados. De este modo, protegerá la escala de tiempo y el presupuesto del proyecto.

La separación arquitectónica del almacenamiento y el proceso para los datos modernos, las plataformas analíticas y los servicios ha sido una tendencia y un patrón de uso frecuente. Proporciona ahorros de costos y más flexibilidad, lo que permite el escalado a petición independiente del almacenamiento y el proceso. Synapse SQL sin servidor amplía este patrón mediante la adición de funcionalidad para consultar los datos del lago de datos directamente. No es necesario preocuparse por la administración de procesos al usar tipos de cargas de trabajo de autoservicio.

Ajuste del análisis de brechas

Al planificar la implementación de grupos de SQL sin servidor en Azure Synapse, primero debe asegurarse de que sean los adecuados para las cargas de trabajo. Debe tener en cuenta aspectos como la excelencia operativa, la eficiencia del rendimiento, la confiabilidad y la seguridad.

Excelencia operativa

Para la excelencia operativa, evalúe los puntos siguientes.

• Entorno de desarrollo de soluciones: dentro de esta metodología hay una evaluación del entorno de desarrollo de soluciones. Identifique cómo se diseñan los entornos (desarrollo, prueba y producción) para admitir el desarrollo de soluciones. Normalmente, encontrará entornos de producción y que no son de producción (para desarrollo y pruebas). Debería encontrar áreas de trabajo de Synapse en todos los entornos. En la mayoría de los casos, tendrá la obligación de separar los usuarios y las cargas de trabajo de producción y desarrollo y pruebas.
• Diseño del área de trabajo de Synapse: dentro de esta metodología, hay una evaluación del diseño del área de trabajo de Synapse. Identifique cómo se han diseñado las áreas de trabajo para la solución. Familiarícese con el diseño y sepa si la solución usará una sola área de trabajo o si varias áreas de trabajo forman parte de la solución. Sepa por qué se ha elegido un diseño de una o varias áreas de trabajo. A menudo, se elige un diseño de varias áreas de trabajo para aplicar límites de seguridad estrictos.
• Implementación: SQL sin servidor está disponible a petición con cada área de trabajo de Synapse, por lo que no necesita ninguna acción de implementación especial. Compruebe la proximidad regional del servicio y la de la cuenta de Azure Data Lake Storage Gen2 (ADLS Gen2) a la que está conectada.
• Supervisión: compruebe si la supervisión integrada es suficiente y si se deben instalar servicios externos para almacenar los datos de registro históricos. Los datos de registro permiten analizar los cambios en el rendimiento y definir acciones desencadenadas o de alerta para circunstancias específicas.

Eficiencia del rendimiento

A diferencia de los motores de base de datos tradicionales, SQL sin servidor no depende de su propia capa de almacenamiento optimizada. Por ese motivo, su rendimiento depende en gran medida de cómo se organizan los datos en ADLS Gen2. Para la eficiencia del rendimiento, evalúe los puntos siguientes.

• Ingesta de datos: revise cómo se almacenan los datos en el lago de datos. Los tamaños de archivo, el número de archivos y la estructura de carpetas tienen un impacto en el rendimiento. Tenga en cuenta que, aunque algunos tamaños de archivo pueden funcionar para SQL sin servidor, pueden imponer problemas para un procesamiento o consumo eficientes por parte de otros motores o aplicaciones. Tendrá que evaluar el diseño del almacenamiento de datos y validarlo con todos los consumidores de los datos, incluidos SQL sin servidor y cualquier otra herramienta de datos que forme parte de la solución.
• Selección de ubicación de los datos: evalúe si el diseño tiene patrones comunes unificados y definidos para la selección de ubicación de los datos. Asegúrese de que la creación de ramas de directorios puede admitir los requisitos de seguridad. Hay algunos patrones comunes que pueden ayudarle a mantener organizados los datos de series temporales. Con independencia de la elección, asegúrese de que también funciona con otros motores y cargas de trabajo. Además, valide si puede ayudar a crear particiones de detección automática para aplicaciones de Spark y tablas externas.
• Formatos de datos: en la mayoría de los casos, SQL sin servidor ofrecerá el mejor rendimiento y una mejor compatibilidad con características mediante un formato Parquet. Compruebe los requisitos de rendimiento y compatibilidad, ya que aunque Parquet mejora el rendimiento, gracias a una mejor compresión y reducción de E/S (solo se leen las columnas necesarias para el análisis), necesita más recursos de proceso. Además, como algunos sistemas de origen no admiten Parquet de forma nativa como formato de exportación, podría provocar más pasos de transformación en las canalizaciones o dependencias en la arquitectura general.
• Exploración: cada sector es diferente. Pero en muchos casos hay patrones de acceso a datos comunes que se encuentran en las consultas de ejecución más frecuentes. Normalmente, los patrones implican filtrado y agregaciones por fechas, categorías o regiones geográficas. Identificar los criterios de filtrado más comunes y relaciónelos con la cantidad de datos leídos o descartados por las consultas de ejecución más frecuentes. Valide si la información del lago de datos está organizada para favorecer los requisitos y las expectativas de exploración. Para las consultas identificadas en el diseño y en la evaluación, compruebe si puede eliminar particiones innecesarias en el parámetro de ruta OPENROWSET o, si hay tablas externas, si puede crear más índices.

Confiabilidad

Para la confiabilidad, evalúe los puntos siguientes.

• Disponibilidad: valide los requisitos de disponibilidad identificados durante la fase de evaluación. Aunque no hay ningún Acuerdo de Nivel de Servicio específico para SQL sin servidor, hay un tiempo de espera de 30 minutos para la ejecución de consultas. Identifique las consultas de ejecución más largas en la evaluación y valídelas con respecto al diseño de SQL sin servidor. Un tiempo de espera de 30 minutos podría interrumpir las expectativas de la carga de trabajo y aparecer como un problema de servicio.
• Consistencia: SQL sin servidor está diseñado principalmente para cargas de trabajo de lectura. Por tanto, valide si todas las comprobaciones de coherencia se han realizado durante el proceso de formación y aprovisionamiento de datos del lago de datos. Mantenga al día de las nuevas funcionalidades, como la capa de almacenamiento de código abierto Delta Lake, que proporciona compatibilidad con las garantías ACID (atomicidad, coherencia, aislamiento y durabilidad) para las transacciones. Esta funcionalidad permite implementar arquitecturas lambda o kappa eficaces para admitir casos de uso de streaming y por lotes. Asegúrese de evaluar el diseño de las oportunidades para aplicar nuevas funcionalidades, pero no a costa de la escala de tiempo o el costo del proyecto.
• Copia de seguridad: revise los requisitos de recuperación ante desastres identificados durante la evaluación. Valídelos con el diseño sin servidor de SQL para la recuperación. SQL sin servidor no tiene una capa de almacenamiento propia y, por eso, será necesario controlar las instantáneas y copias de seguridad de los datos. El almacén de datos al que accede SQL sin servidor es externo (ADLS Gen2). Revise el diseño de recuperación en el proyecto para estos conjuntos de datos.

Seguridad

La organización de los datos es importante para crear bases de seguridad flexibles. En la mayoría de los casos, los distintos procesos y usuarios necesitarán distintos permisos y acceso a subáreas específicos del lago de datos o del almacenamiento de datos lógico.

Para la seguridad, evalúe los puntos siguientes.

• Almacenamiento de datos: con la información recopilada durante la fase de evaluación, identifique si las áreas típicas de lago de datos Sin procesar, Fase y Mantenidos se deben colocar en la misma cuenta de almacenamiento en lugar de hacerlo en cuentas de almacenamiento independientes. Esto último podría dar lugar a una mayor flexibilidad en términos de roles y permisos. También puede agregar más operaciones de entrada y salida por segundo (IOPS) que podrían ser necesarias si la arquitectura debe admitir cargas de trabajo de lectura y escritura intensivas y simultáneas (como escenarios de IoT o en tiempo real). Valide si necesita ampliar la separación mediante la conservación de las áreas de datos maestras y de espacio aislado en cuentas de almacenamiento independientes. La mayoría de los usuarios no necesitarán actualizar ni eliminar datos, por lo que no necesitan permisos de escritura en el lago de datos, excepto para las áreas privadas y de espacio aislado.
• En la información de evaluación, identifique si los requisitos dependen de características de seguridad como Always Encrypted, Enmascaramiento dinámico de datos o Seguridad de nivel de fila. Valide la disponibilidad de estas características en escenarios específicos, como cuando se usan con la función OPENROWSET. Anticipe posibles soluciones alternativas que pueden ser necesarias.
• De la información de evaluación, identifique cuáles serían los mejores métodos de autenticación. Considere las entidades de servicio de Microsoft Entra, la firma de acceso compartido (SAS) y cuándo y cómo se puede usar e integrar la autenticación transferida en la herramienta de exploración que prefiera el cliente. Evalúe el diseño y valide que el mejor método de autenticación forma parte del diseño.

Otras consideraciones

Revise el diseño y compruebe si ha implementado procedimientos recomendados y recomendaciones. Preste especial atención a la optimización de filtros y la intercalación para asegurarse de que la delegación de predicados funciona correctamente.

Pasos siguientes

En el siguiente artículo de la serie de Diseño de éxito de Azure Synapse, aprenderá a evaluar el diseño del grupo de Spark para identificar problemas y validar que cumple las instrucciones y los requisitos.