2015-09-15 11 views
5

Non sono stato in grado di trovare molte informazioni su questo argomento, ma diciamo che usiamo un dataframe per leggere in un file parquet che è 10 Blocks spark creerà naturalmente 10 partizioni. Ma quando il dataframe legge nel file per elaborarlo, non elaborerà un rapporto di dati di grandi dimensioni perché se elaborasse il file non compresso, la dimensione del blocco sarebbe stata molto più ampia, il che significa che anche le partizioni sarebbero più grandi.Spark DataFrames with Parquet and Partitioning

Quindi mi permetta di chiarire, parquet compresso (questi numeri non sono completamente accurati). 1GB Par = 5 Blocks = 5 Partizioni che potrebbero essere decompressi a 5 GB rendendole 25 blocchi/25 partizioni. Ma a meno che non si partiziona il file par da 1 GB, si resteranno bloccati con solo 5 partizioni quando in modo ottimale sarebbero 25 partizioni? O è la mia logica sbagliata.

Avrebbe senso ripartire per aumentare la velocità? O sto pensando a questo torto. Qualcuno può far luce su questo?

Ipotesi:

  • 1 blocco = 1 Partizione scintilla
  • 1 core operati 1 Partizione
+0

"elaborare molte più informazioni" rispetto a cosa? –

+1

Quello che voglio dire è che leggiamo un file parquet con diciamo 10 blocchi, ma quando non è compresso si usano ancora 10 partizioni in Spark. Dovresti ripartizionare perché il file non compresso è naturalmente più grande? – theMadKing

+0

aggiunto ulteriori chiarimenti – theMadKing

risposta

4

Spark dataframe non caricare file in parquet nella memoria. Usa l'API Hadoop/HDFS per leggerlo durante ogni operazione. Quindi il numero ottimale di partizioni dipende dalla dimensione del blocco HDFS (diversa dalla dimensione del blocco Parquet!).

Spark 1.5 dataframe file di partizioni parquet come segue:

  • 1 partizione per blocco HDFS
  • Se dimensione del blocco HDFS è inferiore configurato in termini di dimensioni Spark blocco parquet una partizione verrà creata per più blocchi HDFS tali come dimensione totale della partizione non è inferiore alla dimensione del blocco di parquet
0

Ho visto l'altra risposta ma ho pensato che posso chiarire di più su questo. Se stai leggendo Parquet dal file system posix, puoi aumentare il numero di letture del partizionamento semplicemente avendo più lavoratori in Spark.

Ma per controllare l'equilibrio dei dati che arrivano nei lavoratori si può usare la struttura gerarchica dei dati dei file Parquet, e più avanti negli operai è possibile indicare diverse partizioni o parti del file Parquet. Ciò ti consentirà di controllare la quantità di dati che devono essere inviati a ciascun lavoratore in base al dominio del set di dati (se il bilanciamento dei dati nei lavoratori indica che la parità di dati per lavoratore non è efficiente).