Em primeiro lugar, o tipo de consulta que você executa é extremamente ineficiente. Por enquanto (Spark 1.5.0*) para realizar a junção assim, ambas as tabelas devem ser embaralhadas / particionadas por hash cada vez que a consulta é executada. Não deve ser um problema no caso de
users tabela onde user_id = 123 o predicado provavelmente está pressionado, mas ainda requer embaralhamento completo em user_address . Além disso, se as tabelas forem apenas registradas e não armazenadas em cache, cada execução dessa consulta buscará um
user_address inteiro tabela do MySQL para o Spark. Não está exatamente claro por que você deseja usar o Spark para aplicativos, mas a configuração de uma única máquina, pequenos dados e tipos de consultas sugerem que o Spark não é uma boa opção aqui.
De um modo geral, se a lógica do aplicativo exigir um acesso de registro único, o Spark SQL não terá um bom desempenho. Ele é projetado para consultas analíticas e não como uma substituição de banco de dados OLTP.
Se uma única tabela / quadro de dados for muito menor, você pode tentar 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")
* Isso deve mudar no Spark 1.6.0 com SPARK-11410 que deve habilitar o particionamento de tabela persistente.
