Runtimes de Apache Spark en Fabric
Microsoft Fabric Runtime es una plataforma integrada en Azure basada en Apache Spark que permite la ejecución y administración de experiencias de ingeniería de datos y ciencia de datos. Combina componentes clave de orígenes internos y de código abierto, lo que proporciona a los clientes una solución completa. Para simplificar, nos referiremos a Microsoft Fabric Runtime con tecnología de Apache Spark como Fabric Runtime.
Principales componentes de Fabric Runtime:
Apache Spark: una potente biblioteca informática distribuida de código abierto que permite realizar tareas de análisis y procesamiento de datos a gran escala. Apache Spark proporciona una plataforma versátil y de alto rendimiento para experiencias de ingeniería de datos y ciencia de datos.
Delta Lake : una capa de almacenamiento de código abierto que aporta transacciones ACID y otras características de confiabilidad de datos a Apache Spark. Integrado en Fabric Runtime, Delta Lake mejora las capacidades de procesamiento de datos y garantiza la coherencia de los datos en múltiples operaciones simultáneas.
Paquetes por defecto para Java/Scala, Python y R: paquetes compatibles con diversos lenguajes y entornos de programación. Estos paquetes se instalan y configuran automáticamente, lo que permite a los desarrolladores aplicar sus lenguajes de programación preferidos para las tareas de procesamiento de datos.
Microsoft Fabric Runtime se basa en un sólido sistema operativo de código abierto, lo que garantiza la compatibilidad con diversas configuraciones de hardware y requisitos del sistema.
A continuación, encontrará una comparación completa de los componentes clave, incluidas las versiones de Apache Spark, los sistemas operativos compatibles, Java, Scala, Python, Delta Lake y R, para entornos de ejecución basados en Apache Spark dentro de la plataforma Microsoft Fabric.
Sugerencia
Use siempre la versión más reciente del entorno de ejecución de disponibilidad general para la carga de trabajo de producción, que actualmente es Runtime 1.3.
| Runtime 1.1 | Runtime 1.2 | Runtime 1.3 | |
|---|---|---|---|
| Spark de Apache | 3.3.1 | 3.4.1 | 3.5.0 |
| Sistema operativo | Ubuntu 18.04 | Mariner 2.0 | Mariner 2.0 |
| Java | 8 | 11 | 11 |
| Scala | 2.12.15 | 2.12.17 | 2.12.17 |
| Python | 3.10 | 3.10 | 3,11 |
| Delta Lake | 2.2.0 | 2.4.0 | 3.2 |
| R | 4.2.2 | 4.2.2 | 4.4.1 |
Visite Runtime 1.1, Runtime 1.2 o Runtime 1.3 para explorar detalles, nuevas características, mejoras y escenarios de migración para la versión específica del runtime.
Optimizaciones de Fabric
En Microsoft Fabric, tanto el motor de Spark como las implementaciones de Delta Lake incorporan características y optimizaciones específicas de la plataforma. Estas características están diseñadas para usar integraciones nativas dentro de la plataforma. Es importante tener en cuenta que todas estas características se pueden deshabilitar para lograr la funcionalidad de Spark estándar y Delta Lake. Los runtimes de Fabric para Apache Spark abarcan:
- La versión completa de código abierto de Apache Spark.
- Una colección de casi 100 mejoras integradas y distintas de rendimiento de las consultas. Estas mejoras incluyen características como el almacenamiento en caché de particiones (habilitando la caché de partición FileSystem para reducir las llamadas de metastore) y la combinación cruzada a la proyección de la subconsulta escalar.
- Caché inteligente integrada.
Dentro de Fabric Runtime para Apache Spark y Delta Lake, hay funcionalidades nativas de escritura que sirven para dos propósitos clave:
- Ofrecen un rendimiento diferenciado para escribir cargas de trabajo, optimizando el proceso de escritura.
- De forma predeterminada, se ajustan a la optimización V-Order de archivos Delta Parquet. La optimización V-Order de Delta Lake es fundamental para ofrecer un rendimiento de lectura superior en todos los motores de Fabric. Para comprender mejor el funcionamiento y la administración, consulte el artículo dedicado sobre Optimización de la tabla Delta Lake y V-Order.
Compatibilidad con varios runtimes
Fabric admite varios runtimes, lo que ofrece a los usuarios la flexibilidad de cambiar sin problemas entre ellos, minimizando el riesgo de incompatibilidades o interrupciones.
De forma predeterminada, todas las áreas de trabajo nuevas usan la versión más reciente del entorno de ejecución, que actualmente es Runtime 1.3.
Para cambiar la versión de runtime en el nivel de área de trabajo, vaya a Configuración del área de trabajo > Ingeniería de datos/Ciencia de datos > Proceso de Spark > Valor predeterminado del nivel de área de trabajo, y seleccione el runtime deseado en las opciones disponibles.
Una vez realizado este cambio, todos los elementos creados por el sistema en el área de trabajo, incluidos Lakehouses, SJD y Notebooks, funcionarán con la nueva versión seleccionada de runtime de nivel de área de trabajo a partir de la siguiente sesión Spark. Si actualmente usa un cuaderno con una sesión existente para un trabajo o cualquier actividad relacionada con un lakehouse, esa sesión Spark continúa tal como está. Sin embargo, a partir de la siguiente sesión o trabajo, se aplicará la versión de runtime seleccionada.
Consecuencias de los cambios de runtime en la configuración de Spark
En general, pretendemos migrar toda la configuración de Spark. Sin embargo, si identificamos que la configuración de Spark no es compatible con Runtime B, emitimos un mensaje de advertencia y nos abstenemos de implementar la configuración.
Consecuencias de los cambios de runtime en la administración de la biblioteca
En general, nuestro enfoque consiste en migrar todas las bibliotecas de Runtime A a Runtime B, incluidos los runtimes públicos y personalizados. Si las versiones de Python y R permanecen sin cambios, las bibliotecas deben funcionar correctamente. Sin embargo, para Jars, hay una probabilidad significativa de que no funcionen debido a alteraciones en las dependencias y otros factores, como los cambios en Scala, Java, Spark y el sistema operativo.
El usuario es responsable de actualizar o reemplazar las bibliotecas que no funcionan por Runtime B. Si hay algún conflicto (es decir, si Runtime B incluye una biblioteca definida originalmente en Runtime A), nuestro sistema de administración de bibliotecas intentará crear la dependencia necesaria para Runtime B de acuerdo con la configuración del usuario. Sin embargo, se producirá un error en el proceso de compilación si se genera un conflicto. En el registro de errores, los usuarios pueden ver qué bibliotecas están causando conflictos y hacer ajustes en sus versiones o especificaciones.
Actualizar el protocolo Delta Lake
Las características de Delta Lake siempre son compatibles con versiones anteriores, lo que garantiza que las tablas creadas en una versión inferior de Delta Lake puedan interactuar sin problemas con versiones superiores. Sin embargo, cuando determinadas características están habilitadas (por ejemplo, mediante el método delta.upgradeTableProtocol(minReaderVersion, minWriterVersion), la compatibilidad ascendente con versiones inferiores de Delta Lake puede verse comprometida. En tales casos, es esencial modificar las cargas de trabajo que hacen referencia a las tablas actualizadas para alinearse con una versión de Delta Lake que mantenga la compatibilidad.
Cada tabla Delta está asociada a una especificación de protocolo, definiendo las características que admite. Las aplicaciones que interactúan con la tabla, ya sea para la lectura o escritura, dependen de esta especificación de protocolo para determinar si son compatibles con el conjunto de características de la tabla. Si una aplicación no tiene la capacidad de controlar una característica que aparece como compatible con el protocolo de la tabla, no puede leer ni escribir en esa tabla.
La especificación del protocolo se divide en dos componentes distintos: el protocolo de lectura y el protocolo de escritura. Visite la página "¿Cómo administra Delta Lake la compatibilidad de características?" para obtener más detalles al respecto.
Los usuarios pueden ejecutar el comando delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) en el entorno de PySpark y en Spark SQL y Scala. Este comando les permite iniciar una actualización en la tabla Delta.
Es importante tener en cuenta que al realizar esta actualización, los usuarios reciben una advertencia que indica que la actualización de la versión del protocolo Delta es un proceso no reversible. Esto significa que una vez ejecutada la actualización, no se puede deshacer.
Las actualizaciones de la versión de protocolo pueden afectar potencialmente a la compatibilidad de los escritores, lectores de tabla o ambos existentes de Delta Lake. Por lo tanto, es aconsejable continuar con precaución y actualizar la versión del protocolo solo cuando sea necesario, como al adoptar nuevas características en Delta Lake.
Además, los usuarios deben comprobar que todas las cargas de trabajo y procesos de producción actuales y futuros son compatibles con las tablas Delta Lake mediante la nueva versión del protocolo para garantizar una transición sin problemas y evitar posibles interrupciones.
Cambios de Delta 2.2 frente a Delta 2.4
En Fabric Runtime, versión 1.3 más reciente y Fabric Runtime, versión 1.2, el formato de tabla predeterminado (spark.sql.sources.default) ahora es delta. En versiones anteriores de Fabric Runtime, versión 1.1 y en todo el Synapse Runtime para Apache Spark que contiene Spark 3.3 o anteriores, el formato de tabla predeterminado se definió como parquet. Compruebe la tabla con los detalles de configuración de Apache Spark para ver las diferencias entre Azure Synapse Analytics y Microsoft Fabric.
Todas las tablas creadas con Spark SQL, PySpark, Scala Spark y Spark R, siempre que se omita el tipo de tabla, crearán la tabla como delta de forma predeterminada. Si los scripts establecen explícitamente el formato de tabla, se respetará. El comando USING DELTA de los comandos de creación de tabla de Spark se vuelve redundante.
Se deben revisar los scripts que esperan o presuponen el formato de tabla parquet. Los comandos siguientes no se admiten en tablas Delta:
ANALYZE TABLE $partitionedTableName PARTITION (p1) COMPUTE STATISTICSALTER TABLE $partitionedTableName ADD PARTITION (p1=3)ALTER TABLE DROP PARTITIONALTER TABLE RECOVER PARTITIONSALTER TABLE SET SERDEPROPERTIESLOAD DATAINSERT OVERWRITE DIRECTORYSHOW CREATE TABLECREATE TABLE LIKE