En esta página, se explica el ajuste de rendimiento para operaciones de JOIN en Cloud Data Fusion.
Las operaciones de JOIN pueden ser la parte más costosa de una canalización. Como todo
más de una canalización, las operaciones se ejecutan en paralelo. El primer paso de una JOIN es redistribuir los datos para que cada registro con la misma clave de JOIN se envíe al 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 paralelo en operaciones JOIN
Por ejemplo, supongamos que realizas una operación JOIN en conjuntos de datos llamados 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, estos se mezclan en el clúster, de manera que
registros con el mismo ID terminan 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.
Divide automáticamente las particiones sesgadas
Con la ejecución de consultas adaptables, los sesgos muy pesados se controlarán automáticamente.
En cuanto un JOIN produce algunas particiones mucho más grandes que otras, se
dividir 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 elementos se carga primero en la memoria del Controlador de Spark. Luego, se transmite a cada ejecutor. Los ejecutores ahora pueden unirse al sin mezclar los conjuntos de datos de compras.
Este enfoque requiere que otorgues suficiente memoria al controlador de Spark y
ejecutores para permitirles 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 el ejecutor y la memoria del controlador. Por ejemplo, si el conjunto de datos de artículos fuera de 1 GB, tendríamos que establecer la memoria del ejecutor y del controlador en al menos 4 GB. Los conjuntos de datos de más de 8 GB no se pueden cargar 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 operaciones FULL OUTER JOIN.
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 nueva columna en el lado expandido, propagado
con cada número del 1 al N. Luego, se realiza un JOIN normal, excepto que la columna 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 divididas del 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 tiene el costo de dividir un lado del JOIN, lo que genera más datos en el clúster. Debido a esto, el beneficio disminuye a medida que la distribución
aumenta. 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.