Supongamos que tiene una situación en la que un conjunto de datos es muy pequeño y otro bastante grande, y desea realizar la operación de unión entre estos dos. En ese caso, deberíamos ir por la unión de transmisión para que el pequeño conjunto de datos pueda caber en su variable de transmisión. La sintaxis para usar la variable broadcast es df1.unirse(broadcast (df2)). Aquí tenemos un segundo marco de datos que es muy pequeño y mantenemos este marco de datos como una variable de transmisión.
Código:
val broadcastVar = sc.difusión (Array(1, 2, 3))
broadcastVar.valor
res0: Array = Array(1, 2, 3)
val accum = sc.Acumulador largo («Mi acumulador»)
sc.paralelizar(Matriz(1, 2, 3, 4)).foreach (x => accum.añadir (x))
accum.value
res2: Long = 10
Cache y Persist
- Spark proporciona sus propios mecanismos de almacenamiento en caché, como persist() y cache().
- cache() y persist () almacenarán el conjunto de datos en memoria.
- Cuando tiene un conjunto de datos pequeño que necesita ser utilizado varias veces en su programa, almacenamos en caché ese conjunto de datos.
- Cache () – Siempre en memoria
- Persist () – Memoria y discos
Spark proporciona su propio mecanismo de almacenamiento en caché, como Persist y Caching. Los mecanismos Persist y Cache almacenarán el conjunto de datos en la memoria siempre que sea necesario, cuando tenga un pequeño conjunto de datos y ese conjunto de datos se use varias veces en su programa. Si aplicamos RDD.Cache() siempre almacenará los datos en memoria, y si aplicamos RDD.Persist() entonces una parte de los datos se puede almacenar en la memoria, otra parte se puede almacenar en el disco.
5. Operación ByKey
- Los shuffles son operaciones pesadas que consumen mucha memoria.
- Mientras codifica en Spark, el usuario siempre debe tratar de evitar la operación aleatoria.
- El barajado alto puede dar lugar a un error de memoria externa; Para evitar tal error, el usuario puede aumentar el nivel de paralelismo.
- Use reduceByKey en lugar de groupByKey.
- Particione los datos correctamente.
Como sabemos durante nuestra transformación de Spark, tenemos muchas operaciones ByKey. Las operaciones de ByKey generan mucha mezcla. Baraja son pesados operación, debido a que consumen una gran cantidad de memoria. Al codificar en Spark, un usuario siempre debe tratar de evitar cualquier operación de mezcla porque la operación de mezcla degradará el rendimiento. Si hay un alto barajamiento, el usuario puede sacar el error de la memoria. En este caso, para evitar ese error, un usuario debe aumentar el nivel de paralelismo. En lugar de groupBy, un usuario debe ir por la reduceByKey porque groupByKey crea una gran cantidad de barajado que dificulta el rendimiento, mientras que reduceByKey no baraja tanto los datos. Por lo tanto, reduceByKey es más rápido en comparación con groupByKey. Siempre que se use cualquier operación ByKey, el usuario debe particionar los datos correctamente.
6. Selección de formato de archivo
- Spark admite muchos formatos, como CSV, JSON, XML, PARQUET, ORC, AVRO, etc.
- Los trabajos de Spark se pueden optimizar eligiendo el archivo de parquet con compresión rápida que proporciona un alto rendimiento y el mejor análisis.
- El archivo de parquet es nativo de Spark, que lleva los metadatos junto con su pie de página.
Spark viene con muchos formatos de archivo como CSV, JSON, XML, PARQUET, ORC, AVRO y más. Un trabajo de Spark se puede optimizar eligiendo el archivo de parquet con compresión rápida. El archivo de parquet es nativo de Spark, que lleva los metadatos junto con su pie de página, como sabemos, el archivo de parquet es nativo de spark, que está en el formato binario y, junto con los datos, también lleva el pie de página, también lleva los metadatos y su pie de página, por lo que cada vez que cree un archivo de parquet, verá .archivo de metadatos en el mismo directorio junto con el archivo de datos.
Código:
val peopleDF = spark.Leer.json («examples / src/main/resources / people.json»)
personasf.escribir.parquet («personas.parquet»)
val parquetFileDF = spark . Leer.parquet («personas.parquet»)
val usersDF = spark.Leer.formato («avro»).load («examples / src/main/resources / users.avro»)
usersDF.seleccione («nombre», «color favorito»).escribir.formato («avro»).guardar(«namesAndFavColors.avro»)
Ajuste de recolección de basura
- La recolección de basura de JVM puede ser un problema cuando tiene una gran colección de objetos sin usar.
- El primer paso en el ajuste de GC es recopilar estadísticas eligiendo-detallado al enviar trabajos de spark.
- En una situación ideal, tratamos de mantener los gastos generales de GC < el 10% de la memoria del montón.
Como sabemos, debajo de nuestro trabajo de Spark se está ejecutando en la plataforma JVM, por lo que la recolección de basura de JVM puede ser problemática cuando tiene una gran colección de objetos sin usar, por lo que el primer paso para ajustar la recolección de basura es recopilar estadísticas eligiendo la opción en su envío detallado de Spark. En general, en una situación ideal, deberíamos mantener nuestra memoria de recolección de basura por debajo del 10% de la memoria del montón.
8. Nivel de paralelismo
- El paralelismo juega un papel muy importante al ajustar los trabajos de spark.
- Cada tarea de partición ~ requiere un único núcleo para su procesamiento.
- Hay dos formas de mantener el paralelismo:
- Repartición: Da igual número de particiones con un alto barajamiento
- Coalescencia: Generalmente reduce el número de particiones con menos barajamiento.
En cualquier entorno distribuido, el paralelismo juega un papel muy importante al ajustar su trabajo de Spark. Cada vez que se envía un trabajo de Spark, crea el escritorio que contendrá etapas, y las tareas dependen de la partición, por lo que cada partición o tarea requiere un solo núcleo del sistema para su procesamiento. Hay dos maneras de mantener el paralelismo: Repartición y Fusión. Cada vez que aplicas el método de repartición, te da el mismo número de particiones, pero se barajará mucho, por lo que no es recomendable ir a la repartición cuando quieras azotar todos los datos. Coalesce generalmente reducirá el número de particiones y creará menos barajado de datos.
Estos factores para la optimización de chispas, si se utilizan correctamente, pueden –
