En primer lugar, el tipo de consulta que realiza es extremadamente ineficiente. Por ahora (Spark 1.5.0*) para realizar una unión como esta, ambas tablas deben barajarse/particionarse mediante hash cada vez que se ejecuta la consulta. No debería ser un problema en el caso de users tabla donde user_id = 123 lo más probable es que el predicado se reduzca, pero aún requiere una reproducción aleatoria completa en user_address .
Además, si las tablas solo se registran y no se almacenan en caché, cada ejecución de esta consulta obtendrá una user_address completa. tabla de MySQL a Spark.
No está exactamente claro por qué desea usar Spark para la aplicación, pero la configuración de una sola máquina, los datos pequeños y el tipo de consultas sugieren que Spark no es una buena opción aquí.
En términos generales, si la lógica de la aplicación requiere un único acceso a un registro, Spark SQL no funcionará bien. Está diseñado para consultas analíticas, no como un reemplazo de la base de datos OLTP.
Si una sola tabla/marco de datos es mucho más pequeño, puede intentar transmitir.
import org.apache.spark.sql.DataFrame
import org.apache.spark.sql.functions.broadcast
val user: DataFrame = ???
val user_address: DataFrame = ???
val userFiltered = user.where(???)
user_addresses.join(
broadcast(userFiltered), $"address_id" === $"user_address_id")
* Esto debería cambiar en Spark 1.6.0 con SPARK-11410 que debería habilitar la partición persistente de tablas.
