寄木細工と分割によるスパークデータフレーム

Question

私はこのトピックに関する多くの情報を見つけることができませんでしたが、データフレームを使用して寄木張りファイルを読み込み、10ブロックスパークは自然に10パーティションを作成します。しかし、データフレームがファイルを読み込んで処理するときには、大きなデータ対パーティション比を処理しません。なぜなら、ファイルを圧縮解除して処理すると、ブロックサイズが大きくなり、パーティションも大きくなるからです。

私は、パーケット圧縮（これらの数値は完全に正確ではありません）を明確にします。 1GB Par = 5 Blocks = 5 5GBに圧縮解除され、25ブロック/ 25パーティションになるパーティション。しかし、1GBのparファイルを再パーティション化しない限り、最適に25個のパーティションがある場合は、わずか5個のパーティションしか使えません。または私の論理が間違っている。

速度を上げるためにパーティションを再分割することは理にかなっていますか？あるいは、私はこの間違いを考えています。誰かがこれについていくつかの光を当てることができますか？

仮定：

• 1ブロックDATAFRAMEがメモリに寄木細工のファイルをロードしない1パーティション

Answer 1

スパーク上で動作スパーク

1コア用= 1つのパーティション。各操作中にHadoop/HDFS APIを使用して読み取ります。そのため、最適なパーティション数はHDFSブロックサイズに依存します（Parquetブロックサイズとは異なります）。

スパーク1.5データフレームのパーティションの寄木細工のファイルは次のようにHDFSブロック毎

• 1パーティション
• HDFSブロックサイズは、パーティションが複数のHDFSブロックのように作成されますスパーク寄​​木細工のブロックサイズで構成未満である場合パーティションの合計サイズは、寄木ブロックサイズよりも小さいので、

Answer 2

私はもう一つの答えを見ましたが、私はこれについてもっと明確にすることができると考えました。 posixファイルシステムからParquetを読んでいる場合は、Sparkでより多くの作業者を持つだけで、パーティションの読み取り数を増やすことができます。

しかし、労働者に提供されるデータのバランスを制御するために、寄木細工のファイルの階層的なデータ構造を使用することができます。後で作業者は、さまざまなパーティションまたは寄木細工のファイルの部分を指すことがあります。これにより、データセットのドメインに従って各ワーカーにどのくらいのデータを渡すかを制御できます（従業員のデータのバランスをとることで、従業員一人あたりのデータバッチが効率的でない場合）。