Fabric Runtime 1.2 (GA)
Microsoft Fabric Runtime es una plataforma integrada de Azure basada en Apache Spark que permite la ejecución y administración de experiencias de ingeniería de datos y ciencia de datos. En este documento se describen los componentes y versiones de Runtime 1.2.
Los componentes principales de Runtime 1.2 incluyen:
- Apache Spark 3.4.1
- Sistema operativo: Mariner 2.0
- Java: 11
- Scala: 2.12.17
- Python: 3.10
- Delta Lake: 2.4.0
- R: 4.2.2
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.
Microsoft Fabric Runtime 1.2 incluye una colección de paquetes de nivel predeterminados, incluida una instalación completa de Anaconda y bibliotecas de uso frecuente para Java/Scala, Python y R. Estas bibliotecas se incluyen automáticamente al usar cuadernos o trabajos en la plataforma Microsoft Fabric. Consulte la documentación para obtener una lista completa de bibliotecas. Microsoft Fabric implementa periódicamente actualizaciones de mantenimiento para Runtime 1.2, lo que proporciona correcciones de errores, mejoras de rendimiento y revisiones de seguridad. Mantenerse al día garantiza un rendimiento y una confiabilidad óptimos para las tareas de procesamiento de datos.
Nuevas características y mejoras de la versión 3.4.1 de Spark
Apache Spark 3.4.0 es la quinta versión de la línea 3.x. Esta versión, controlada por la comunidad de código abierto, resolvió más de 2600 vales Jira. Presenta un cliente de Python para Spark Connect, mejora el flujo estructurado con seguimiento de progreso asincrónico y procesamiento con estado de Python. Amplía la cobertura de la API Pandas con compatibilidad de entrada NumPy, simplifica la migración desde almacenamientos de datos tradicionales a través del cumplimiento ANSI y las nuevas funciones integradas. También mejora la productividad del desarrollo y la depuración con la generación de perfiles de memoria. Además, Runtime 1.2 se basa en Apache Spark 3.4.1, una versión de mantenimiento centrada en correcciones de estabilidad.
Aspectos destacados
Lea la versión completa de las notas de la versión de una versión específica de Apache Spark visitando Spark 3.4.0 y Spark 3.4.1.
Nuevas optimizaciones de consultas personalizadas
Compatibilidad con escrituras simultáneas en Spark
Encontrarse con un error 404 con el mensaje "Error en la operación: la ruta especificada no existe" es un problema común cuando se realizan inserciones de datos paralelas en la misma tabla utilizando una consulta SQL INSERT INTO. Este error puede provocar la pérdida de datos. Nuestra nueva característica, el algoritmo de confirmación de salida de archivo, resuelve este problema, lo que permite a los clientes realizar la inserción de datos en paralelo sin problemas.
Para acceder a esta característica, habilite la marca de característica spark.sql.enable.concurrentWrites
, que está habilitada de forma predeterminada a partir de Runtime 1.2 (Spark 3.4). Aunque esta característica también está disponible en otras versiones de Spark 3, no está habilitada de forma predeterminada. Esta característica no admite la ejecución en paralelo de consultas INSERT OVERWRITE en las que cada trabajo simultáneo sobrescribe datos en particiones diferentes de la misma tabla dinámicamente. Para ello, Spark ofrece una característica alternativa, que se puede activar mediante la configuración del valor spark.sql.sources.partitionOverwriteMode
en dinámico.
Lecturas inteligentes, que omiten archivos de trabajos con errores
En el sistema de confirmador de Spark actual, cuando se produce un error en una inserción en un trabajo de tabla, pero algunas tareas se realizan correctamente, los archivos que generan las tareas correctas coexisten con los archivos del trabajo con errores. Esta coexistencia puede causar confusión para los usuarios, ya que resulta difícil distinguir entre los archivos que pertenecen a trabajos correctos e incorrectos. Además, cuando un trabajo lee de una tabla mientras otro inserta datos simultáneamente en la misma tabla, el trabajo de lectura podría acceder a datos no confirmados. Si se produce un error en un trabajo de escritura, el trabajo de lectura podría procesar datos incorrectos.
La marca spark.sql.auto.cleanup.enabled
controla nuestra nueva característica, solucionando este problema. Cuando está habilitada, Spark omite automáticamente la lectura de archivos que no se han confirmado cuando realiza spark.read
o selecciona consultas de una tabla. Los archivos escritos antes de habilitar esta característica siguen leyéndose como de costumbre.
Estos son los cambios visibles:
- Todos los archivos ahora incluyen un identificador
tid-{jobID}
en sus nombres de archivo. - En lugar del marcador
_success
normalmente creado en la ubicación de salida tras la finalización correcta del trabajo, se genera un nuevo marcador_committed_{jobID}
. Este marcador asocia identificadores de trabajo correctos con nombres de archivo específicos. - Hemos introducido un nuevo comando SQL que los usuarios pueden ejecutar periódicamente para administrar el almacenamiento y limpiar archivos sin confirmar. La sintaxis de este comando es la siguiente:
- Para limpiar un directorio específico:
CLEANUP ('/path/to/dir') [RETAIN number HOURS];
- Para limpiar una tabla específica:
CLEANUP [db_name.]table_name [RETAIN number HOURS];
En esta sintaxis,path/to/dir
representa el URI de ubicación donde se requiere la limpieza ynumber
es un valor de tipo doble que representa el período de retención. El período de retención predeterminado se establece en siete días.
- Para limpiar un directorio específico:
- Hemos introducido una nueva opción de configuración denominada
spark.sql.deleteUncommittedFilesWhileListing
, que se establece enfalse
de forma predeterminada. Al habilitar esta opción, se elimina automáticamente los archivos no confirmados durante las lecturas, pero este escenario podría ralentizar las operaciones de lectura. Se recomienda ejecutar manualmente el comando de limpieza cuando el clúster está inactivo en lugar de habilitar esta marca.
Guía de migración de Runtime 1.1 a Runtime 1.2
Al migrar desde Runtime 1.1, con tecnología de Apache Spark 3.3, a Runtime 1.2, con tecnología de Apache Spark 3.4, revise la guía de migración oficial.
Nuevas características y mejoras de Delta Lake 2.4
Delta Lake es un proyecto de código abierto que permite crear una arquitectura de almacén de lago sobre lagos de datos. Delta Lake proporciona transacciones ACID y control escalable de metadatos, y unifica el procesamiento de datos de streaming y por lotes sobre los lagos de datos existentes.
En concreto, Delta Lake ofrece:
- Transacciones ACID en Spark: los niveles de aislamiento serializables garantizan que los lectores nunca vean datos incoherentes.
- Control escalable de metadatos: usa la potencia de procesamiento distribuido de Spark para manejar con facilidad todos los metadatos de tablas a escala de petabytes con miles de millones de archivos.
- Unificación de streaming y lotes: una tabla en Delta Lake es una tabla de lotes, así como un origen y un receptor de streaming. La ingesta de datos de streaming, la reposición histórica de lotes y las consultas interactivas funcionan de manera integral.
- Cumplimiento del esquema: controla automáticamente las variaciones de esquema para evitar la inserción de registros incorrectos durante la ingesta.
- Viaje en el tiempo: el control de versiones de datos permite reversiones, seguimientos de auditoría históricos completos y experimentos reproducibles de aprendizaje automático.
- Upserts y eliminaciones: admite operaciones de combinación, actualización y eliminación para habilitar casos de uso complejos como captura de datos modificados, operaciones de dimensión de variación lenta, upserts de streaming, etc.
Lea la versión completa de las notas de la versión de Delta Lake 2.4.
Paquetes de nivel predeterminados para bibliotecas de Java, Scala y Python
Para obtener una lista de todos los paquetes de nivel predeterminados para Java, Scala, Python y sus respectivas versiones, consulte las notas de la versión.