En esta página, se explica el ajuste de rendimiento para operaciones de JOIN en Cloud Data Fusion.
Las operaciones JOIN pueden ser la parte más costosa de una canalización. Al igual que todo lo demás en una canalización, las operaciones se ejecutan en paralelo. El primer paso de un
JOIN es redistribuir los datos para que se envíen todos los registros con la misma clave JOIN.
en el mismo ejecutor. Después de que todos los datos se mezclan, se unen, y
de salida continúa a través de la canalización.
Ejemplo de procesamiento en paralelo en operaciones JOIN
Por ejemplo, supongamos que realizas una operación JOIN en conjuntos de datos llamada
Purchases y Items. Cada registro de compra contiene un nombre y un número de artículo.
comprados. Cada registro de artículo contiene el nombre y el precio del artículo. Se realiza una JOIN en el nombre del artículo para calcular el precio total de cada compra. Cuando se unen los datos, se redistribuyen en el clúster de modo que los registros con el mismo ID terminen en el mismo ejecutor.
Cuando las claves JOIN se distribuyen de manera bastante uniforme, las operaciones JOIN funcionan
porque se pueden ejecutar en paralelo.
Al igual que cualquier redistribución, el sesgo de datos afecta negativamente el rendimiento. En el proceso anterior
Por ejemplo, los huevos se compran
con mucha más frecuencia que el pollo o la leche,
significa que el ejecutor que se une a las compras de huevos hace más trabajo que el otro
ejecutores. Si notas que un JOIN está sesgado, hay dos formas de mejorar
rendimiento.
Cómo dividir automáticamente particiones sesgadas
Con la ejecución de consultas adaptable, se controlarán automáticamente los sesgos muy grandes.
En cuanto un JOIN produce algunas particiones mucho más grandes que otras, se dividen en otras más pequeñas. Para confirmar que tienes habilitada la ejecución de consultas adaptables,
consulta Ajuste automático.
Usa un JOIN en la memoria
Se puede realizar una JOIN en la memoria si un lado de JOIN es lo suficientemente pequeño
para que quepa en la memoria. En esta situación, el conjunto de datos pequeño se carga en la memoria y, luego, se transmite a cada ejecutor. Un conjunto de datos grande no se mezcla en
y quita todas las particiones desigual que se generan cuando se aplica la redistribución
Tecla JOIN.
En el ejemplo anterior, el conjunto de datos de artículos se carga primero en la memoria del controlador de Spark. Luego, se transmite a cada ejecutor. Los ejecutores ahora pueden unir los datos sin mezclar ninguno de los conjuntos de datos de compras.
Este enfoque requiere que le proporciones suficiente memoria al controlador de Spark y a los ejecutores para que puedan almacenar el conjunto de datos de transmisión en la memoria. De forma predeterminada,
Spark reserva un poco menos del 30% de su memoria para almacenar este tipo de
datos. Cuando uses JOIN en la memoria, multiplica el tamaño del conjunto de datos por cuatro y configúralo como la memoria del ejecutor y del controlador. Por ejemplo, si el conjunto de datos de elementos
si tuviera un tamaño de 1 GB, tendríamos que establecer la memoria del ejecutor y del controlador en
4 GB como mínimo. No se pueden cargar conjuntos de datos de más de 8 GB en la memoria.
Distribución de claves
Cuando ambos lados de JOIN son demasiado grandes para caber en la memoria, se muestra una
se puede usar para dividir cada clave JOIN en varias claves a fin de aumentar
el nivel de paralelismo. Esta técnica se puede aplicar a INNER JOIN y
LEFT OUTER JOIN. No se puede usar para FULL OUTER JOIN
las operaciones.
En este enfoque, el lado sesgado se sala con una nueva columna de número entero con un
un número aleatorio de 1 a N. El lado no sesgado se expande, y cada fila existente
generando N filas nuevas. Se agrega una columna nueva al lado expandido, propagada con cada número del 1 al N. Luego, se realiza una JOIN normal, excepto la nueva.
se agrega como parte de la clave JOIN. De esta manera, todos los datos que usaron
para ir a una sola partición ahora se distribuye en hasta N particiones diferentes.
En el ejemplo anterior, el factor de distribución N se establece en 3. El
conjuntos de datos originales se muestran a la izquierda. Las versiones con sal y desglosadas de la
conjunto de datos se muestran en el medio. A la derecha, se muestran los datos aleatorios
tres ejecutores diferentes que unen compras de huevos, en lugar de uno.
Se logra un mayor paralelismo aumentando las distribuciones. Sin embargo, esto viene
a costa de expandir un lado de JOIN, lo que genera más datos redistribuidos
en todo el clúster. Por este motivo, el beneficio disminuye a medida que aumenta la distribución. En la mayoría de los casos, configúralo en 20 o menos.
¿Qué sigue?
- Obtén más información sobre el procesamiento paralelo en Cloud Data Fusion.