Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 05 · Lección

Particiones y paralelismo

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 3 de 5

Particiones y paralelismo

Broadcast evita mover el lado grande cuando el otro cabe con seguridad en ejecutores.

Duración
17 min aprox.
Objetivo
Broadcast evita mover el lado grande cuando el otro cabe con seguridad en ejecutores.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Catalyst, particiones, joins y shuffles

Razona sobre el plan lógico y físico antes de ajustar configuraciones o añadir cómputo.

Al terminar podrás
  • Leer explain formatted
  • Detectar Exchange, skew y spill
  • Elegir broadcast, repartition o coalesce con evidencia
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate + Professional
Ruta relacionada
core
Dominios blueprint
Troubleshooting and Optimization · Spark execution
Estado
Revisión editorial interna
Fuentes principales
Optimización en Databricks · Debugging con Spark UI
Reportar un error
03
Operación

Particiones y paralelismo

Broadcast evita mover el lado grande cuando el otro cabe con seguridad en ejecutores.

Mostrar prerrequisitos
Dificultad
Associate + Professional
Prerrequisitos
m04
Reportar un error en esta lección

BroadcastHashJoin distribuye una relación pequeña a cada executor y elimina el shuffle de la grande. El umbral automático o broadcast hint influyen en Catalyst.

Una estimación obsoleta puede emitir un broadcast demasiado grande y causar presión de memoria. SortMergeJoin es razonable para dos lados grandes.

Modelo mental

Un broadcast join cambia quién se mueve. En un shuffle join ambos lados se redistribuyen por clave; en BroadcastHashJoin el lado pequeño se recopila y distribuye a los executors para construir una tabla hash local, de modo que las particiones del lado grande pueden leerse donde están. La ventaja depende del tamaño serializado real y de la memoria disponible en cada executor, no de que el dataset se llame dimensión. Catalyst puede elegir broadcast con estadísticas y umbral, y un hint puede influir, pero forzar una relación creciente puede causar OOM. Cuando ambos lados son grandes, sort-merge suele ser una estrategia razonable aunque implique shuffle.

BroadcastHashJoin

Join que replica una relación pequeña y construye una tabla hash local en cada executor.

Evita redistribuir el lado grande cuando la memoria soporta la réplica.
Estadística de tamaño

Estimación del volumen de una relación usada por el optimizador para comparar estrategias.

Una estimación obsoleta puede conducir a un plan físico inadecuado.
Hint

Indicación declarativa que influye en la estrategia seleccionada por Catalyst.

Debe usarse con evidencia porque puede imponerse sobre una decisión adaptativa más segura.
PySparkBroadcast explícito
from pyspark.sql.functions import broadcast
enriched = facts.join(broadcast(dim.select("id", "segment")), "id")

Confirma el tamaño real de dim y el operador del plan.

Puntos clave

  • Broadcast mueve el lado pequeño
  • Las estadísticas importan
  • Dos lados grandes suelen requerir shuffle

Evita

  • Broadcast de una dimensión no acotada
  • Forzar hint sin revisar memoria

Recuerdo activo

¿Qué dataset se replica en BroadcastHashJoin?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Learn Databricks

Learn Databricks · commit 08c378c

README.md