Nuevas funciones de Spark3.0

Documento reimpreso: después de
casi dos años, finalmente se lanza la versión oficial de Apache Spark 3.0.0

Poda de partición dinámica (Poda de partición dinámica)

El llamado corte de partición dinámico se basa en la información inferida en tiempo de ejecución (tiempo de ejecución) para un posterior corte de partición. Por ejemplo, tenemos la siguiente consulta:

SELECT * FROM dim_iteblog 
JOIN fact_iteblog 
ON (dim_iteblog.partcol = fact_iteblog.partcol) 
WHERE dim_iteblog.othercol > 10

Suponiendo que dim_iteblog.othercol> 10 de la tabla dim_iteblog filtra menos datos, pero debido a que la versión anterior de Spark no puede calcular dinámicamente el costo, puede hacer que la tabla fact_iteblog escanee una gran cantidad de datos no válidos. Con la reducción dinámica de particiones, los datos inútiles de la tabla fact_iteblog se pueden filtrar en tiempo de ejecución. Después de esta optimización, los datos para el análisis de consultas se reducen en gran medida y el rendimiento se mejora 33 veces.

Configuración relacionada:

Para habilitar la poda dinámica de particiones, debe establecer el parámetro spark.sql.optimizer.dynamicPartitionPruning.enabled en verdadero (predeterminado), otros parámetros relacionados:

• spark.sql.optimizer.dynamicPartitionPruning.useStats ： verdadero （默认） ， Cuando es verdadero, se usarán estadísticas de conteo distintas para calcular el tamaño de los datos de la tabla particionada después de la poda dinámica de la partición, con el fin de evaluar si vale la pena agregar una subconsulta adicional como filtro de poda si la reutilización al voleo no es aplicable.
• spark.sql.optimizer.dynamicPartitionPruning.fallbackFilterRatio ： 0.5 ， Cuando las estadísticas no están disponibles o configuradas para no ser utilizadas, esta configuración se usará como la relación de filtro de respaldo para calcular el tamaño de datos de la tabla particionada después de la poda dinámica de particiones, en orden para evaluar si vale la pena agregar una subconsulta adicional como filtro de poda si la reutilización de difusión no es aplicable.
• spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcast ： 默认 为 true ， Cuando es true, la poda dinámica de particiones buscará reutilizar los resultados de difusión de una operación de unión de hash de difusión.

Para obtener más información, consulte:
https://www.iteblog.com/archives/8589.html
https://www.iteblog.com/archives/8590.html

Ejecución de consultas adaptables (ejecución de consultas adaptables)

La ejecución de consultas adaptables (también conocida como Optimización adaptativa de consultas o Optimización adaptativa) es la optimización de los planes de ejecución de consultas, lo que permite que Spark Planner ejecute planes de ejecución opcionales en tiempo de ejecución. Estos planes se optimizarán en función de las estadísticas de tiempo de ejecución.
Ya en 2015, la comunidad Spark propuso la idea básica de ejecución adaptativa. En Spark's DAGScheduler, se agregó una interfaz para enviar una única etapa de mapa y se intentó ajustar el número de particiones de reproducción aleatoria en tiempo de ejecución. Sin embargo, la implementación actual tiene ciertas limitaciones. En algunos escenarios se introducirán más barajas, es decir, más etapas, y no se puede manejar la situación de tres tablas uniéndose en una misma etapa; y la actual Es difícil para el marco implementar de manera flexible otras funciones en la ejecución adaptativa, como cambiar el plan de ejecución o manejar uniones inclinadas en tiempo de ejecución.

El marco AQE actualmente proporciona tres funciones:

• Fusionar dinámicamente particiones aleatoriamente;
• Ajustar dinámicamente la estrategia de unión;
• Optimización dinámica de combinaciones sesgadas (combinaciones sesgadas).

Basado en el punto de referencia TPC-DS de 1TB sin estadísticas, Spark 3.0 puede aumentar la velocidad de q77 en 8 veces, la velocidad de q5 en 2 veces y la velocidad de otras 26 consultas en más de 1,1 veces. AQE se puede habilitar estableciendo la configuración de SQL spark.sql.adaptive = true, el valor predeterminado de este parámetro es falso.

Programación consciente del acelerador

Hoy en día, big data y aprendizaje automático se han combinado en gran medida. En el aprendizaje automático, debido a que el tiempo de iteración del cálculo puede ser muy largo, los desarrolladores generalmente optan por usar GPU, FPGA o TPU para acelerar el cálculo. En la versión Apache Hadoop 3.1, ha comenzado el soporte nativo para GPU y FPGA. Como motor informático de uso general, Spark ciertamente no se queda atrás. Los ingenieros de Databricks, NVIDIA, Google y Alibaba están agregando soporte nativo de programación de GPU a Apache Spark. Esta solución llena el vacío en la programación de tareas de Spark de recursos de GPU de forma orgánica. Integra el procesamiento de big data y aplicaciones de inteligencia artificial, y expande los escenarios de aplicación de Spark en aprendizaje profundo, procesamiento de señales y varias aplicaciones de big data.

Actualmente, los administradores de recursos YARN y Kubernetes compatibles con Apache Spark ya admiten GPU. Para que Spark también sea compatible con GPU, se deben realizar dos cambios importantes a nivel técnico:

A nivel de administrador de clúster, los administradores de clúster deben actualizarse para admitir GPU. Y proporcione a los usuarios API relacionadas, de modo que los usuarios puedan controlar el uso y la asignación de recursos de la GPU.
Dentro de Spark, se deben realizar modificaciones en el nivel del programador para que el programador pueda identificar la demanda de GPU en la solicitud de tarea del usuario y luego completar la asignación de acuerdo con el suministro de GPU en el ejecutor.
Debido a que es una característica relativamente grande que Apache Spark admite GPU, el proyecto se divide en varias etapas. En la versión Apache Spark 3.0, admitirá el soporte de GPU en administradores de recursos independientes, YARN y Kubernetes, y básicamente no tendrá ningún impacto en las operaciones normales existentes. La compatibilidad con TPU, la compatibilidad con GPU en Mesos Explorer y la compatibilidad con GPU en la plataforma Windows no serán el objetivo de esta versión. Además, la programación detallada dentro de una tarjeta GPU no será compatible con esta versión; la versión Apache Spark 3.0 tratará una tarjeta GPU y su memoria como una unidad inseparable.

Apache Spark DataSource V2

La API de fuente de datos define cómo leer y escribir interfaces API relacionadas desde el sistema de almacenamiento, como InputFormat / OutputFormat de Hadoop, Serde de Hive, etc. Estas API son muy adecuadas para que los usuarios utilicen la programación RDD en Spark. Aunque programar con estas API puede resolver nuestros problemas, el costo para los usuarios sigue siendo bastante alto y Spark no puede optimizarlos. Para solucionar estos problemas, la versión Spark 1.3 comenzó a introducir Data Source API V1, a través de esta API podemos leer fácilmente datos de varias fuentes, y Spark utiliza algunos motores de optimización de componentes SQL para optimizar la lectura de fuentes de datos. Como recorte de columnas, filtrado de empuje hacia abajo, etc.

Data Source API V1 abstrae una serie de interfaces para nosotros, y la mayoría de los escenarios se pueden realizar mediante el uso de estas interfaces. Sin embargo, a medida que aumentaba el número de usuarios, surgieron gradualmente algunos problemas:

• Parte de la interfaz depende de SQLContext y DataFrame
• La capacidad de expansión es limitada, es difícil presionar a otros operadores
• Falta de soporte para lecturas de almacenamiento en columnas
• Falta de particionamiento y clasificación de información
• La operación de escritura no admite transacciones
• No admite procesamiento de transmisión

Para resolver algunos problemas de Data Source V1, a partir de la versión Apache Spark 2.3.0, la comunidad introdujo Data Source API V2. Además de conservar las funciones originales, también resolvió algunos de los problemas de Data Source API V1, como ya no Al depender de la API de nivel superior, se mejora la capacidad de expansión.

Para obtener más información, consulte:
https://www.iteblog.com/archives/2578.html
https://www.iteblog.com/archives/2579.html

API y funciones enriquecidas

• Pandas mejorados UDF

• Un conjunto completo de sugerencias de combinación
  Aunque la comunidad continúa mejorando la inteligencia del compilador, no puede garantizar que el compilador siempre pueda tomar la mejor decisión para cada situación. La elección del algoritmo de combinación se basa en estadísticas y heurísticas. Cuando el compilador no puede hacer la mejor elección, los usuarios aún pueden usar sugerencias de combinación para influir en el optimizador para elegir un plan mejor. Apache Spark 3.0 amplía las sugerencias de combinación existentes al agregar nuevas sugerencias: SHUFFLE_MERGE, SHUFFLE_HASH y SHUFFLE_REPLICATE_NL

• Nuevas funciones integradas
  Scala API agrega 32 nuevas funciones integradas y funciones de orden superior. Entre estas funciones integradas, se ha agregado un conjunto de funciones integradas específicas para MAP [transform_key, transform_value, map_entries, map_filter, map_zip_with] para simplificar el procesamiento de tipos de datos MAP.

Función de monitoreo mejorada

• Rediseño de la interfaz de usuario de transmisión estructurada La transmisión
  estructurada se introdujo originalmente en Spark 2.0. Spark 3.0 rediseñó la interfaz de usuario para monitorear estos trabajos de transmisión
  
• Comando EXPLAIN mejorado Los
  planes de lectura son muy importantes para comprender y ajustar las consultas. La solución existente parece muy confusa, la representación de cadena de cada operador puede ser muy amplia e incluso puede estar truncada. La versión Spark 3.0 usa un nuevo modo de formato (FORMATTED) para mejorarlo y también proporciona la función de volcar el plan en un archivo.
• Indicadores observables
  El monitoreo continuo de los cambios en la calidad de los datos es una característica muy necesaria para administrar las canalizaciones de datos. Spark versión 3.0 introdujo esta capacidad para aplicaciones de procesamiento por lotes y de flujo. Los indicadores observables se denominan como cualquier función agregada (marco de datos) que se puede definir en la consulta. Una vez que la ejecución del marco de datos alcanza un punto de finalización (por ejemplo, se completa una consulta por lotes), se emite un evento con nombre que contiene un indicador de los datos procesados ​​desde el último punto de finalización.

Mejor compatibilidad ANSI SQL

PostgreSQL es una de las bases de datos de código abierto más avanzadas. Admite la mayoría de las características principales de SQL: 2011. Entre las 179 funciones que cumplen plenamente los requisitos de SQL: 2011, PostgreSQL cumple al menos 160. La comunidad Spark actualmente tiene un NÚMERO ESPECIAL SPARK-27764 para resolver las diferencias entre Spark SQL y PostgreSQL, incluidos suplementos de características funcionales, modificaciones de errores, etc. El complemento de funciones incluye algunas funciones que admiten ANSI SQL, que distinguen las palabras clave reservadas de SQL y las funciones integradas. Este ISSUE corresponde a 231 sub-ISSUEs. Si se resuelve esta parte del ISSUE, la diferencia entre Spark SQL y PostgreSQL o ANSI SQL: 2011 es aún menor.

otro

• SparkR lectura y escritura vectorizada
• Kafka Streaming includeHeaders admite la configuración de información de algunos encabezados en el mensaje
• Spark en K8S: el soporte de Spark para Kubernetes comenzó desde la versión 2.3, Spark 2.4 se mejoró y Spark 3.0 agregará soporte para Kerberos y asignación dinámica de recursos.
• Servicio Shuffle remoto: el Shuffle actual tiene muchos problemas, como poca flexibilidad, tiene un gran impacto en NodeManager y no es adecuado para el entorno de la nube. Para resolver los problemas anteriores, se introducirá el servicio de reproducción aleatoria remota; consulte SPARK-25299 para obtener más detalles
• Compatibilidad con JDK 11: consulte SPARK-24417. La razón para elegir JDK 11 directamente es porque JDK 8 está a punto de alcanzar el fin de vida útil (EOL), y JDK9 y JDK10 ya están en EOL, por lo que la comunidad omite JDK9 y JDK10 y admite directamente JDK11. Sin embargo, la versión preliminar de Spark 3.0 todavía usa JDK 1.8 de forma predeterminada;
• Elimine el soporte para Scala 2.11, soporte Scala 2.12 de forma predeterminada, consulte SPARK-26132 para obtener más detalles
• Compatibilidad con Hadoop 3.2, consulte SPARK-23534 para obtener más detalles. Hadoop 3.0 se ha lanzado durante 2 años (Apache Hadoop 3.0.0-beta1 se lanzó oficialmente y la próxima versión (GA) se puede usar en línea), por lo que es natural admitir Hadoop 3.0. Sin embargo, la versión preliminar de Spark 3.0 todavía usa Hadoop 2.7.4 de forma predeterminada.
• Eliminar la compatibilidad con Python 2.x: ya en junio de 2019, hubo una discusión relacionada en la comunidad sobre la eliminación de la compatibilidad con Python 2 en Spark 3.0. Actualmente, Spark 3.0.0 es compatible con Python 3.x de forma predeterminada. Consulte SPARK-27884.
• Spark Graph es compatible con Cypher: Cypher es un lenguaje de consulta de gráficos popular, y ahora podemos usar Cypher directamente en Spark 3.0.
• Los registros de eventos de Spark son compatibles con Roll; consulte "Spark 3.0 finalmente admite la actualización de registros de eventos"