Compartir vía

Cuaderno de estrategias de POC de Synapse: Análisis de macrodatos con grupos de Apache Spark en Azure Synapse Analytics

  • Artículo

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 grupos de Apache Spark.

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 prueba de concepto

Un proyecto POC puede ayudarle a tomar una decisión empresarial informada sobre la implementación de un entorno de macrodatos y análisis avanzado en una plataforma basada en la nube que aprovecha el grupo de Apache Spark en Azure Synapse.

Un proyecto POC identificará los objetivos clave y los factores empresariales que debe respaldar la plataforma de análisis avanzado y macrodatos basada en la nube. Probará las métricas clave y demostrará los comportamientos principales que son fundamentales para el éxito de la ingeniería de datos, la creación de modelos de aprendizaje automático y los requisitos de entrenamiento. 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 POC de Spark, haga lo siguiente:

  • 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 ayudarle durante la ejecución de la POC.

Antes de empezar a preparar el proyecto POC, se recomienda leer primero la documentación de Apache Spark.

Sugerencia

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

A estas alturas debería haber determinado que no hay bloqueos inmediatos y entonces puede empezar a preparar su POC. Si no está familiarizado con los grupos de Apache Spark en Azure Synapse Analytics, puede consultar esta documentación donde puede obtener información general sobre la arquitectura de Spark y aprender cómo funciona en Azure Synapse.

Desarrolle una comprensión de estos conceptos clave:

  • Apache Spark y su arquitectura distribuida.
  • Conceptos de Spark, como conjuntos de datos distribuidos resistentes (RDD) y particiones (en memoria y físicas).
  • Área de trabajo de Azure Synapse, los distintos motores de proceso, canalizaciones y supervisión.
  • Separación del proceso y el almacenamiento en el grupo de Spark.
  • Autenticación y autorización en Azure Synapse.
  • Conectores nativos que se integran con el grupo de SQL dedicado de Azure Synapse, Azure Cosmos DB y otros.

Azure Synapse desacopla los recursos de proceso del almacenamiento para que pueda administrar mejor las necesidades de procesamiento de datos y controlar los costos. La arquitectura sin servidor del grupo de Spark le permite aumentar y reducir su clúster de Spark, independientemente de su almacenamiento. Puede pausar (o configurar la pausa automática) un clúster de Spark por completo. De este modo, solo se paga por el proceso cuando está en uso. Cuando no está en uso, solo se paga por el almacenamiento. Puede escalar verticalmente el clúster de Spark si tiene que procesar grandes volúmenes de datos o en el caso de cargas grandes y, luego, reducirlo verticalmente durante las horas de procesamiento menos intensas (o apagarlo completamente). Puede escalar y pausar eficazmente un clúster para reducir los costos. Las pruebas POC de Spark deben incluir la ingesta y el procesamiento de datos a diferentes escalas (pequeña, mediana y grande) para comparar el precio y el rendimiento. Para más información, consulte Escalado automático de grupos de Apache Spark de Azure Synapse Analytics.

Es importante comprender la diferencia entre los distintos conjuntos de API de Spark para que pueda decidir el que mejor funciona en su caso. Puede elegir el que proporciona un mejor rendimiento o facilidad de uso, y aprovechar los conjuntos de aptitudes existentes de su equipo. Para más información, consulte Historia de tres API de Apache Spark: RDD, DataFrames y Datasets.

La creación de particiones de datos y archivos funciona de forma ligeramente diferente en Spark. Comprender las diferencias le ayudará a optimizar el rendimiento. Para más información, consulte la documentación de Apache Spark: Detección de particiones y Opciones de configuración de particiones.

Establecimiento de 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 las vías de paso entre las POC para determinar si debe continuar con la siguiente. Dados los distintos roles profesionales que pueden usar grupos y cuadernos de Spark en Azure Synapse, puede optar por ejecutar varias POC. Por ejemplo, una POC podría centrarse en los requisitos del rol de ingeniería de datos, como la ingesta y el procesamiento. Otra POC podría centrarse en el desarrollo de modelos de aprendizaje automático (ML).

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

  • ¿Va a migrar desde una plataforma de análisis avanzado y macrodatos existente (local o en la nube)?
  • ¿Va a migrar y quiere hacer el menor número posible de cambios en la ingesta y el procesamiento de datos existentes? Por ejemplo, una migración de Spark a Spark o una migración de Hadoop o Hive a Spark.
  • ¿Va a migrar pero quiere realizar bastantes mejoras durante el proceso? Por ejemplo, volver a escribir trabajos de MapReduce como trabajos de Spark o convertir el código heredado basado en RDD en código basado en tramas de datos o conjuntos de datos.
  • ¿Va a crear 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, ¿ETL, procesamiento por lotes, procesamiento de secuencias, entrenamiento de modelos de aprendizaje automático, análisis, consultas de informes o consultas interactivas?
  • ¿Cuáles son las aptitudes de los usuarios que serán propietarios del proyecto (en caso de que se implemente la POC)? Por ejemplo, aptitudes de PySpark frente a Scala, experiencia de cuadernos frente a IDE.

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

  • ¿Por qué estamos haciendo una POC?
    • Es necesario saber que el rendimiento de la ingesta y el procesamiento de datos de nuestra carga de trabajo de macrodatos cumplirá los nuevos Acuerdos de Nivel de Servicio.
    • Es necesario saber si el procesamiento de secuencias casi en tiempo real es posible y cuánto rendimiento puede admitir. (¿Respaldará nuestros requisitos empresariales?)
    • Es necesario saber si nuestros procesos de ingesta y transformación de datos existentes son una buena opción y dónde deben realizarse mejoras.
    • Es necesario saber si podemos acortar los tiempos de ejecución de integración de datos y cuánto.
    • Es necesario saber si nuestros científicos de datos pueden crear y entrenar modelos de aprendizaje automático y aprovechar las bibliotecas de inteligencia artificial y aprendizaje automático según sea necesario en un grupo de Spark.
    • ¿El traslado a Synapse Analytics basado en la nube cumplirá nuestros objetivos de costo?
  • Al concluir esta POC:
    • Tendremos los datos para determinar si se pueden cumplir los requisitos de rendimiento del procesamiento de datos para el streaming por lotes y en tiempo real.
    • Habremos probado la ingesta y el procesamiento de todos nuestros diferentes tipos de datos (estructurados, semiestructurados) que admiten nuestros casos de uso.
    • Habremos probado parte del procesamiento de datos complejo existente y podremos identificar el trabajo que deberá hacerse para migrar nuestra cartera de integración de datos al nuevo entorno.
    • Habremos probado la ingesta y el procesamiento de datos y tendremos los puntos de datos para calcular el trabajo necesario para la migración inicial y la carga de datos históricos, y para migrar nuestra ingesta de datos (Azure Data Factory [ADF], Distcp, Databox u otros).
    • Habremos probado la ingesta y el procesamiento de datos y podremos determinar si se pueden cumplir nuestros requisitos de procesamiento ETL/ELT.
    • Habremos obtenido información para calcular mejor el trabajo necesario para completar el proyecto de implementación.
    • Habremos probado las opciones de escalado y escala y tendremos los puntos de datos para configurar mejor nuestra plataforma de cara a una mejor configuración del rendimiento de los precios.
    • Tendremos una lista de elementos que pueden necesitar más pruebas.

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 respaldar cada objetivo y resultado esperado. Además, identifique la ingesta de datos específica, el procesamiento de secuencias o por lotes, y todos los demás procesos que se ejecutarán para poder identificar un conjunto de datos y un código base muy específicos. Este conjunto de datos y código base específicos definirán el ámbito de la POC.

Este es un ejemplo del nivel de especificidad necesario en el planeamiento:

  • Objetivo A: es necesario saber si nuestro requisito de ingesta de datos y procesamiento de datos por lotes se puede cumplir en nuestro Acuerdo de Nivel de Servicio definido.
  • Resultado A: tendremos los datos para determinar si la ingesta y el procesamiento de datos por lotes pueden satisfacer el requisito de procesamiento de datos y el Acuerdo de Nivel de Servicio.
    • Prueba A1: las consultas de procesamiento A, B y C se identifican como buenas pruebas de rendimiento, ya que normalmente las ejecuta el equipo de ingeniería de datos. Además, representan las necesidades generales de procesamiento de datos.
    • Prueba A2: las consultas de procesamiento X, Y y Z se identifican como buenas pruebas de rendimiento, ya que contienen requisitos de procesamiento de secuencias casi en tiempo real. Además, representan las necesidades generales de procesamiento de secuencias basado en eventos.
    • Prueba A3: compare el rendimiento de estas consultas a una escala diferente del clúster de Spark (número y tamaño variables de los nodos de trabajo, como pequeño, mediano y grande; número y tamaño de los ejecutores) con la prueba comparativa obtenida del sistema existente. Tenga en cuenta la ley de los rendimientos decrecientes; agregar más recursos (ya sea mediante el escalado vertical u horizontal) puede ayudar a lograr el paralelismo; pero para ello, hay un cierto límite que es específico de cada escenario. Descubra la configuración óptima de cada caso de uso identificado en las pruebas.
  • Objetivo B: es necesario saber si nuestros científicos de datos pueden crear y entrenar modelos de aprendizaje automático en esta plataforma.
  • Resultado B: habremos probado algunos de nuestros modelos de aprendizaje automático mediante su entrenamiento con los datos de un grupo de Spark o de un grupo de SQL y el uso de diferentes bibliotecas de aprendizaje automático. Estas pruebas le ayudarán a determinar qué modelos de aprendizaje automático se pueden migrar al nuevo entorno.
    • Prueba B1: se probarán modelos de aprendizaje automático específicos.
    • Prueba B2: pruebe las bibliotecas de aprendizaje automático base que se incluyen con Spark (Spark MLLib) junto con una biblioteca adicional que se puede instalar en Spark (como scikit-learn) para cumplir los requisitos.
  • Objetivo C: habremos probado la ingesta de datos y tendremos los puntos de datos para:
    • Calcular el trabajo de la migración inicial de datos históricos al lago de datos o al grupo de Spark.
    • Planee un enfoque para migrar datos históricos.
  • Resultado C: habremos probado y determinado la tasa de ingesta de datos factible en nuestro entorno y podemos determinar si nuestra tasa de ingesta de datos es suficiente para migrar los datos históricos durante el período de tiempo disponible.
  • Objetivo D: habremos probado la tasa de ingesta de datos de la carga incremental de datos y tendrá los puntos de datos para calcular la ventana de tiempo de ingesta y de procesamiento de datos para el lago de datos o el grupo de SQL dedicado.
  • Resultado D: habremos probado la tasa de ingesta de datos y podremos determinar si los requisitos de ingesta y procesamiento de datos se pueden satisfacer con el enfoque identificado.
    • Prueba D1: pruebe la ingesta y el procesamiento de datos de actualizaciones diarias.
    • Prueba D2: pruebe la carga de datos procesada en la tabla del grupo de SQL dedicado desde el grupo de Spark. Para más información, consulte Conector del grupo de SQL dedicado de Azure Synapse para Apache Spark.
    • Prueba D3: ejecute el proceso de carga de actualizaciones diarias simultáneamente mientras ejecuta consultas de usuario final.

Asegúrese de refinar las pruebas agregando varios escenarios de prueba. Azure Synapse facilita la prueba a diferentes escalas (número y tamaño variables de los nodos de trabajo, como pequeño, mediano y grande) para comparar el rendimiento y el comportamiento.

Estos son algunos escenarios de prueba:

  • Prueba del grupo de Spark A: ejecutaremos el procesamiento de datos en varios tipos de nodos (pequeños, medianos y grandes), así como en diferentes números de nodos de trabajo.
  • Prueba del grupo de Spark B: cargaremos o recuperaremos los datos procesados del grupo de Spark en el grupo de SQL dedicado mediante el conector.
  • Prueba del grupo de Spark C: cargaremos o recuperaremos los datos procesados del grupo de Spark en Azure Cosmos DB mediante Azure Synapse Link.

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 (menos de 1 TB) porque no ofrecerá un rendimiento representativo. Y al 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.

Para más información, consulte Arquitecturas de macrodatos.

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 Apache Spark y Spark.
  • Un asesor experto para optimizar las pruebas de la 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, grupos de Spark y grupos de SQL dedicados, cuentas de almacenamiento y todos los recursos de Azure identificados en el plan de POC.

  2. Cargue el conjunto de datos de POC:

  3. Migre el código existente al grupo de Spark:

    • Si va a migrar desde Spark, es probable que el trabajo de migración sea sencillo, ya que el grupo de Spark aprovecha la distribución de Spark de código abierto. Sin embargo, si usa características específicas del proveedor aparte de las características principales de Spark, deberá asignar correctamente estas características a las características del grupo de Spark.
    • Si va a migrar desde un sistema que no es de Spark, el trabajo de migración variará en función de la complejidad implicada.

  4. Ejecute las pruebas:

    • Muchas pruebas se pueden ejecutar en paralelo en varios clústeres de grupos de Spark.
    • Registre los resultados en un formato consumible y fácil de entender.

  5. Supervise la solución de problemas y el rendimiento. Para más información, consulte:

  6. Supervise la asimetría de datos, la asimetría de tiempo y el porcentaje de uso del ejecutor abriendo la pestaña Diagnóstico del servidor de historial de Spark.

    Imagen que muestra la pestaña de Diagnóstico del servidor de historial de Spark.

Interpretación de los resultados de la prueba de concepto

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

Exploración de lagos de datos con grupos de SQL dedicados en Azure Synapse Analytics

Exploración de lagos de datos con grupos de SQL sin servidor en Azure Synapse Analytics

Preguntas frecuentes sobre Azure Synapse Analytics