Cuaderno de estrategias de la POC de Synapse: exploración del lago de datos con un grupo de SQL sin servidor de 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 el grupo de SQL sin servidor.

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.

Preparación para la POC

Un proyecto de POC puede ayudarle a tomar una decisión empresarial bien fundada sobre la implementación de un entorno de macrodatos y un análisis avanzado en una plataforma basada en la nube que aprovecha el grupo de SQL sin servidor de Azure Synapse. Si necesita explorar los datos del lago de datos, informarse sobre este u optimizar la canalización de transformación de datos existente, puede beneficiarse del uso del grupo de SQL sin servidor. Es apropiado para los escenarios siguientes:

  • Detección y exploración básicos: analice rápidamente datos almacenados de diversos formatos (Parquet, CSV y JSON) en el lago de datos, para que pueda planear cómo extraer información de estos.
  • Almacenamiento de datos lógico: proporcione una abstracción relacional sobre datos sin procesar o dispares sin reubicarlos ni transformarlos, para obtener una vista siempre actualizada de estos.
  • Transformación de datos: ejecute consultas de lago de datos sencillas, escalables y de alto rendimiento mediante T-SQL. Puede enviar los resultados de las consultas a las herramientas de inteligencia empresarial (BI) o cargarlos en una base de datos relacional. Los sistemas de destino pueden incluir grupos de SQL de Azure Synapse dedicados o de Azure SQL Database.

Diferentes puestos 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 el grupo de SQL sin servidor y simplificar las canalizaciones de transformación de datos.
  • Los científicos de datos pueden razonar rápidamente sobre el contenido y la estructura de los datos almacenados en el lago de datos mediante la función T-SQL OPENROWSET y su inferencia automática de esquema.
  • Los analistas de datos pueden escribir consultas de T-SQL en sus herramientas de consulta preferidas, que pueden conectarse al grupo de SQL sin servidor. Pueden explorar datos en tablas externas de Spark que hayan creado científicos o ingenieros de datos.
  • Los profesionales de BI pueden crear rápidamente informes de Power BI que se conectan a tablas del lago de datos o Spark.

Un proyecto de POC del grupo de SQL sin servidor identificará los objetivos clave y los controladores empresariales que el grupo de SQL sin servidor está diseñado para admitir. También probará las características clave y recopilará métricas para admitir las decisiones de implementación. Una POC no está diseñada para implementarse en un entorno de producción. En su lugar, es un proyecto a corto plazo que se centra en preguntas clave y su resultado se puede descartar.

Antes de empezar a planear el proyecto de POC del grupo de SQL sin servidor:

  • Identifique las restricciones o directrices de su organización sobre cómo mover datos a la nube.
  • Identifique a los patrocinadores ejecutivos o empresariales para un proyecto de plataforma de análisis avanzado y macrodatos. Proteja su compatibilidad con la migración a la nube.
  • Identifique la disponibilidad de expertos técnicos y usuarios empresariales para que le ayuden durante la ejecución de la POC.

Antes de empezar a preparar el proyecto de POC, se recomienda leer primero la documentación del grupo de SQL sin servidor.

Sugerencia

Si no está familiarizado con los grupos de SQL sin servidor, se recomienda trabajar a través de las soluciones de análisis de datos de compilación mediante la ruta de aprendizaje de grupos de SQL sin servidor de Azure Synapse.

Establecer los objetivos

Un proyecto de POC correcto requiere planificación. Para comenzar, tiene que saber por qué está haciendo una POC y así poder reconocer completamente las motivaciones reales. Las motivaciones pueden incluir modernización, ahorro de costos, mejora del rendimiento o experiencia integrada. Asegúrese de documentar unos objetivos claros para la POC y los criterios que definirán su éxito. Pregúntese lo siguiente:

  • ¿Qué resultados quiere obtener de la POC?
  • ¿Qué hará con esos resultados?
  • ¿Quién usará los resultados?
  • ¿Qué definirá a una POC correcta?

Tenga en cuenta que una POC debe consistir en un esfuerzo corto y centrado para demostrar rápidamente un conjunto limitado de conceptos y funcionalidades. Estos conceptos y funcionalidades deben ser representativos de la carga de trabajo general. Si tiene una larga lista de elementos para demostrarlo, es posible que quiera planear más de una POC. En ese caso, defina los límites de las POC para determinar si necesita continuar con la siguiente. Dados los distintos roles profesionales que pueden usar un grupo de SQL sin servidor (y los diferentes escenarios que admite el grupo de SQL sin servidor), puede optar por ejecutar varias POC. Por ejemplo, una POC puede centrarse en los requisitos para el rol científico de datos, como la detección y exploración de datos en distintos formatos. Otra puede centrarse en los requisitos para el rol de ingeniería de datos, como la transformación de datos y la creación de un almacenamiento de datos lógico.

A medida que establezca los objetivos de la POC, hágase las siguientes preguntas para que pueda darles forma:

  • ¿Va a migrar desde una plataforma de análisis avanzado y macrodatos existente (local o en la nube)?
  • ¿Va a migrar, pero quiere realizar los pocos cambios posibles en la ingesta y el procesamiento de datos existentes?
  • ¿Va a migrar, pero quiere realizar algunas mejoras exhaustivas por el camino?
  • ¿Está creando una plataforma de análisis avanzado y macrodatos completamente nueva (proyecto greenfield)?
  • ¿Cuáles son sus puntos débiles actuales? Por ejemplo, escalabilidad, rendimiento o flexibilidad.
  • ¿Qué nuevos requisitos empresariales necesita admitir?
  • ¿Cuáles son los Acuerdos de Nivel de Servicio que debe cumplir?
  • ¿Cuáles serán las cargas de trabajo? Por ejemplo, la exploración de datos sobre diferentes formatos, exploración básica, un almacenamiento de datos lógico, preparación o transformación de datos, análisis interactivo de T-SQL, consulta de T-SQL de tablas de Spark o de informes sobre el lago de datos.
  • ¿Cuáles son las aptitudes de los usuarios que serán los propietarios del proyecto (debe implementarse la POC)?

Estos son algunos ejemplos de la configuración del objetivo de la POC:

  • ¿Por qué estamos haciendo una POC?
    • Es necesario saber si podemos explorar todos los formatos de archivo sin procesar que almacenamos mediante el grupo de SQL sin servidor.
    • Es necesario saber si nuestros ingenieros de datos pueden evaluar rápidamente nuevas fuentes de distribución de datos.
    • Es necesario saber si el rendimiento de las consultas del lago de datos mediante el grupo de SQL sin servidor cumplirá nuestros requisitos de exploración de datos.
    • Es necesario saber si el grupo de SQL sin servidor es una buena opción para algunas de nuestras visualizaciones y requisitos de informes.
    • Es necesario saber si el grupo de SQL sin servidor es una buena opción para algunos de nuestros requisitos de ingesta y procesamiento de datos.
    • Es necesario saber si nuestro traslado a Azure Synapse entrará dentro de nuestro presupuesto.
  • Al concluir esta POC:
    • Tendremos los datos para identificar las transformaciones de datos adecuadas para el grupo de SQL sin servidor.
    • Tendremos los datos para identificar cuándo se puede usar mejor el grupo de SQL sin servidor durante la visualización de datos.
    • Tendremos los datos para saber la facilidad con la que nuestros ingenieros de datos y científicos de datos pueden adoptar la nueva plataforma.
    • Hemos obtenido información para estimar mejor el esfuerzo necesario para completar el proyecto de implementación o migración.
    • Tendremos una lista de elementos que pueden necesitar más pruebas.
    • Nuestra POC será correcta si tenemos los datos necesarios y hemos completado las pruebas identificadas para determinar cómo el grupo de SQL sin servidor admitirá nuestros macrodatos basados en la nube y la plataforma de análisis avanzado.
    • Hemos determinado si podemos pasar a la siguiente fase o si se necesitan más pruebas de la POC para acabar de tomar una decisión.
    • Podremos tomar una decisión empresarial sólida compatible con puntos de datos específicos.

Planeamiento del proyecto

Use sus objetivos para identificar pruebas específicas y proporcionar las salidas que identificó. Es importante asegurarse de que tiene al menos una prueba para admitir cada objetivo y el resultado esperado. Además, puede identificar las tareas específicas de exploración y análisis de datos, las transformaciones específicas y el procesamiento existente específico que quiera probar. Identifique un conjunto de datos y un código base específicos que puede usar.

Este es un ejemplo del nivel de especificicación necesario en la planificación:

  • Objetivo: es necesario saber si los ingenieros de datos pueden lograr el procesamiento equivalente al proceso ETL existente denominado "Validación diaria de archivos sin formato por lotes" en el Acuerdo de Nivel de Servicio requerido.
  • Resultado: tendremos los datos para determinar si podemos usar consultas de T-SQL para ejecutar el proceso ETL "Validación diaria de archivos sin formato por lotes" en el Acuerdo de Nivel de Servicio necesario.
  • Prueba: las consultas de validación A, B y C se identifican mediante la ingeniería de datos y representan las necesidades generales de procesamiento de datos. Compare el rendimiento de estas consultas con el punto de referencia obtenido del sistema existente.

Evaluación del conjunto de datos de la POC

Con las pruebas específicas que identificó, seleccione un conjunto de datos para admitir las pruebas. Dedique un tiempo a revisar este conjunto de datos. Debe comprobar que el conjunto de datos representará de forma adecuada el futuro procesamiento en términos de contenido, complejidad y escala. No use un conjunto de datos demasiado pequeño porque no ofrecerá un rendimiento representativo. Por el contrario, no use un conjunto de datos demasiado grande porque la POC no debe convertirse en una migración de datos completa. Asegúrese de obtener los puntos de referencias adecuados de los sistemas existentes para poder usarlos en las comparaciones de rendimiento.

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 realizar antes de mover los datos a la nube.

Creación de arquitectura de alto nivel

En función de la arquitectura de alto nivel de la arquitectura de estado futuro propuesta, identifique los componentes que formarán parte de la POC. Es probable que la arquitectura de alto nivel de estado futuro contenga muchos orígenes de datos, numerosos consumidores de datos, componentes de macrodatos y posiblemente consumidores de datos de aprendizaje automático e inteligencia artificial (IA). La arquitectura de la POC debe identificar específicamente los componentes que formarán parte de ella. Lo importante es que debe identificar los componentes que no formen parte de las pruebas de la POC.

Si ya usa Azure, identifique los recursos que ya tiene implementados (Microsoft Entra ID, ExpressRoute, etc.) que puede usar durante la prueba de concepto. Identifique también las regiones de Azure que usa su organización. Ahora es un buen momento para identificar el rendimiento de la conexión de ExpressRoute y comprobar con otros usuarios empresariales que su POC puede consumir parte de ese rendimiento sin afectar negativamente a los sistemas de producción.

Identificación de recursos de la POC

Identifique específicamente los recursos técnicos y los compromisos de tiempo necesarios para respaldar la POC. Su POC necesitará:

  • Un representante empresarial para supervisar los requisitos y los resultados.
  • Un experto en datos de aplicaciones, para obtener los datos de la POC y proporcionar conocimiento de los procesos y la lógica existentes.
  • Un experto en grupos de SQL sin servidor.
  • Un asesor experto para optimizar las pruebas de las POC.
  • Recursos que serán necesarios para componentes específicos del proyecto de POC, pero no necesariamente necesarios para la duración de la POC. Estos recursos pueden incluir administradores de red, administradores de Azure, administradores de Active Directory, administradores de Azure Portal y otros.
  • Asegúrese de que se aprovisionan todos los recursos de servicios de Azure necesarios y se concede el nivel de acceso necesario, como el acceso a las cuentas de almacenamiento.
  • Asegúrese de tener una cuenta que tenga permisos de acceso a datos necesarios para recuperar datos de todos los orígenes de datos en el ámbito de la POC.

Sugerencia

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

Establecimiento de la escala de tiempo

Revise los detalles de planificación de la POC y las necesidades empresariales para identificar un período de tiempo para su POC. Realice estimaciones realistas del tiempo necesario para completar los objetivos de la POC. El tiempo para completar la POC se verá afectado por el tamaño del conjunto de datos de la POC, el número y la complejidad de las pruebas y el número de interfaces que se van a probar. Si calcula que la POC tardará en ejecutarse más de cuatro semanas, considere la posibilidad de reducir el ámbito de esta para centrarse en los objetivos de prioridad más alta. Asegúrese de obtener la aprobación y el compromiso de todos los recursos y patrocinadores principales antes de continuar.

Puesta en práctica de la prueba de concepto

Se recomienda ejecutar el proyecto de la POC con la disciplina y el rigor de cualquier proyecto de producción. Ejecute el proyecto según el plan y administre un proceso de solicitud de cambio para evitar el crecimiento sin control del ámbito de la POC.

Estos son algunos ejemplos de tareas de alto nivel:

  1. Cree un área de trabajo de Synapse, cuentas de almacenamiento y los recursos de Azure identificados en el plan de la POC.
  2. Configure las redes y la seguridad según sus requisitos.
  3. Conceda un acceso adecuado a los miembros del equipo de la POC. Consulte este artículo sobre los permisos para acceder a archivos directamente desde Azure Storage.
  4. Cargue el conjunto de datos de la POC.
  5. Implemente y configure las pruebas o migre el código existente a vistas y scripts del grupo de SQL sin servidor.
  6. Ejecute las pruebas:
    • Muchas pruebas se pueden ejecutar en paralelo.
    • Registre los resultados en un formato consumible y fácil de entender.
  7. Supervise la solución de problemas y el rendimiento.
  8. Evalúe los resultados y presente las conclusiones.
  9. Trabaje con las partes técnicas interesadas y la empresa para planear la siguiente fase del proyecto. La siguiente fase podría ser una POC de seguimiento o una implementación de producción.

Interprete los resultados de la POC

Cuando complete todas las pruebas de la POC, evalúe los resultados. Para empezar, evalúe si se cumplieron los objetivos de la POC y se recopilaron los resultados que buscaba. Determine si es necesario realizar más pruebas o si hay alguna pregunta que se debe abordar.

Pasos siguientes