2016-02-03 14 views
7

Ho provato a confrontare le prestazioni di Spark SQL versione 1.6 e versione 1.5. In un caso semplice, Spark 1.6 è molto più veloce di Spark 1.5. Tuttavia, in una query più complessa, nel mio caso una query di aggregazione con insiemi di raggruppamenti, Spark SQL versione 1.6 è molto più lenta di Spark SQL versione 1.5. Qualcuno ha notato lo stesso problema? e ancora meglio avere una soluzione per questo tipo di query?Prestazioni di Spark SQL: versione 1.6 vs versione 1.5

Ecco il mio codice

case class Toto(
       a: String = f"${(math.random*1e6).toLong}%06.0f", 
       b: String = f"${(math.random*1e6).toLong}%06.0f", 
       c: String = f"${(math.random*1e6).toLong}%06.0f", 
       n: Int = (math.random*1e3).toInt, 
       m: Double = (math.random*1e3)) 

val data = sc.parallelize(1 to 1e6.toInt).map(i => Toto()) 
val df: org.apache.spark.sql.DataFrame = sqlContext.createDataFrame(data) 

df.registerTempTable("toto") 
val sqlSelect = "SELECT a, b, COUNT(1) AS k1, COUNT(DISTINCT n) AS k2, SUM(m) AS k3" 
val sqlGroupBy = "FROM toto GROUP BY a, b GROUPING SETS ((a,b),(a),(b))" 
val sqlText = s"$sqlSelect $sqlGroupBy" 

val rs1 = sqlContext.sql(sqlText) 
rs1.saveAsParquetFile("rs1") 

Qui ci sono 2 screenshots Spark 1.5.2 e Spark 1.6.0 con --driver-memory = 1G. Il DAG su Spark 1.6.0 può essere visualizzato allo DAG.

+1

Sembra che sia più mischiato in 1.6, puoi pubblicare i due DAG? –

+0

Grazie a @SebastianPiu. Puoi vedere i 2 screenshot con DAG vuoti a [spark 1.5.2] (http://i.stack.imgur.com/dLXiK.png) e [spark 1.6.0] (http: //i.stack.imgur .com/4oomU.png). In altri casi, Spark visualizza ancora i DAG correttamente. –

+0

sì, purtroppo questo è un bug causato quando Chrome è stato aggiornato così impossibile da risolvere i DAG :( –

risposta

1

Grazie Herman van Hövell per la sua risposta alla community di spark dev. Per condividere con altri membri, condivido la sua risposta qui.

1.6 piani singoli aggregati distinti come più distinti aggregati; ciò causa intrinsecamente un sovraccarico ma è più stabile in caso di alte cardinalità. È possibile ripristinare il vecchio comportamento impostando l'opzione spark.sql.specializeSingleDistinctAggPlanning su false. Vedi anche: https://github.com/apache/spark/blob/branch-1.6/sql/core/src/main/scala/org/apache/spark/sql/SQLConf.scala#L452-L462

In realtà per ripristinare il valore di impostazione dovrebbe essere "true".

Problemi correlati