👂🏼 💒 🍁 パフォーマンスApache Parquet 🤘🏾 🚆 🖖🏿

良いテストの悪い例。

最近、喫煙室では、Apache Hadoopのさまざまなストレージ形式（CSV、JSON、Apache Avro、Apache Parquetなど）のパフォーマンスを比較する議論が頻繁に行われています。ほとんどの参加者はすぐにテキスト形式を明白な部外者として却下し、AvroとParquetの間のコンテストの主な陰謀を残しました。

一般的な意見は、データセット全体を操作するときに1つの形式が「より良い」ように見え、2番目の「より良い」が列のサブセットのクエリを処理するという未確認の噂でした。

他の自尊心のあるエンジニアと同様に、本格的なパフォーマンステストを実施して、どちらが正しいかを最終的に確認することをお勧めします。比較の結果は切り捨てられています。

アパッチ寄木細工のロゴ

翻訳者注：

当初、この記事は、 Apache Sparkを使用してApache AvroとApache Parquetを比較した経験に関するCloudera Engineering BlogのDon Drakeのテキスト（ @dondrake ）の無料翻訳として構想されました。しかし、翻訳プロセス中に詳細を調べて、テストで多くの論争点を見つけました。記事にサブタイトルを追加しました。テキストには、不正確さを示す悪意のあるコメントが含まれています。

テストデータセット

テストに実際のデータと実際のクエリを使用するのが正しいと思いました。この場合、実稼働環境でのパフォーマンスはテスト環境と同様に動作することが期待できます。つまり、テストでは、サロゲートデータの行をカウントすることはできません。

テストのための「実際のデータ」と「実際のクエリ」の選択は、非常に物議をかもしているようです。誰もが異なる実際のデータと要求を持っています。この問題を解決するために、 TPCベンチマークなどの典型的なストレージパフォーマンステストが合成されます。

私が最近作業したデータセットを調べたところ、テストに最適な2つのデータが見つかりました。 1つ目は「ナロー」と呼び、3列のみで構成され、8230万行が含まれています。CSVでは3.9 GBを占めます。

以下に示すように、これにより750〜1000 MBのシリアル化されたデータが生成され、50人のワーカーで処理されます。各ワーカーは15〜20 MBのデータを取得します。ほとんどの場合、ワーカーの初期化はデータの読み取りと処理よりも時間がかかります。

2つ目は、「ワイド」と呼びます。103列と6億9,400万行で構成され、サイズが194 GBのCSVファイルになります。このアプローチにより、大小のファイルでどの形式がより適切に機能するかを評価できると思います。

「ワイド」データセットは30倍だけでなく、8倍も長くなっています。元のサイズの49倍。データセットを「小」および「大」と呼ぶ方がより正確です。

さらに、サイズ比から判断すると、データセットではさまざまなタイプの列が表されているようです。この作業では、データ型の違いは通常無視されます。一方、これはストレージ形式の重要な側面です。

試験方法

テストの主力として、Apache Spark 1.6を選択しました。 SparkはそのままParquetをサポートし、AvroおよびCSVのサポートは個別に接続されます。すべての操作は、100台以上のマシンのCDH 5.5.xクラスターで実行されました。

さまざまな種類の処理（読み込み、単純なクエリ、重要なクエリ、データセット全体の処理、および使用されているディスク容量）のフォーマットのパフォーマンスを測定することに興味がありました。

両方のデータセットに対して同じ構成でspark-shell

を介してテストを実行しました（違いはエグゼキューターの数のみでした）。シェルモード:paste

は、インタープリターを混乱させる可能性のある複数行のコマンドを心配することなく、ScalaコードをREPLに直接コピーできるようにして、命を救いました。

 #!/bin/bash -x # Drake export HADOOP_CONF_DIR=/etc/hive/conf export SPARK_HOME=/home/drake/coolstuff/spark/spark-1.6.0-bin-hadoop2.6 export PATH=$SPARK_HOME/bin:$PATH # use Java8 export JAVA_HOME=/usr/java/latest export PATH=$JAVA_HOME/bin:$PATH # NARROW NUM_EXECUTORS=50 # WIDE NUM_EXECUTORS=500 spark-shell —master yarn-client \ —conf spark.eventLog.enabled=true \ —conf spark.eventLog.dir=hdfs://nameservice1/user/spark/applicationHistory \ —conf spark.yarn.historyServer.address=http://yarnhistserver.allstate.com:18088 \ —packages com.databricks:spark-csv_2.10:1.3.0,com.databricks:spark-avro_2.10:2.0.1 \ —driver-memory 4G \ —executor-memory 2G \ —num-executors $NUM_EXECUTORS \ ...

Spark Web UIの[ジョブ]タブからクエリの実行時間を取得しました。各テストを3回繰り返し、平均時間を計算しました。狭いデータセットへの要求は比較的負荷の高いクラスターで実行され、広いデータセットへの要求は完全なアイドルクラスターの時点で実行されました。それは意図的に起こったのではなく、偶然です。

テスト間で異なる環境（異なる数のワーカーと異なるクラスター負荷を含む）を使用すると、絶対値を比較することができなくなります。

ロードされたクラスター自体の使用は、再起動時の測定結果の再現性に悪影響を及ぼします-簡単なことではありません。

実験の3回の繰り返しは統計的に軽微に見えます-評価の信頼区間は非常に大きくなります。ただし、著者は信頼区間についても言及していません。

データの前処理

CSVから狭いデータセットを読み取るときに、回路を出力しませんでしたが、 String

型のString

をTimestamp

に変換する必要がありました。結果にこの変換の時間を含めませんでした。なぜなら、ストレージ形式には適用されません。広いデータセットを使用する場合、回路の出力を使用しましたが、この時間も考慮しませんでした。

スキーマの出力（元の- 推論スキーマ ） DataFrame

、Reflectionを使用したRDD

からDataFrame

への暗黙的な変換を意味します。

テストプロセス中に、Timestampタイプの列を持つAvroファイルを保存することが不可能であることを知って驚いた。実際、Avroバージョン1.7.xは基本的にDate

またはTimestamp

サポートしていません。

Avro 1.8 は、論理型Date

、 Timestamp

およびそれらの派生型をサポートしています。実際、これらはint

またはlong

単なるラッパーです。

狭いデータセットのテスト

最初に、AvroまたはParquet形式で狭いデータセットをディスクに書き込むことができる時間を見積もりました。データをデータフレームに読み込んだ後、記録に有効な時間のみを考慮しました。統計誤差の範囲内で差が得られました。したがって、狭いデータセットの書き込みパフォーマンスは、両方の形式でほぼ同じです。

ネットワークのオーバーヘッドなどを考慮しても、シリアル化の時間は非常に長くなりました。結局のところ、1人のワーカーの出力は20 MB未満です。

作成者が読み取りと処理の時間と書き込みの時間を誤って分離したように見えます。この場合、この時間のほとんどが4ギガバイトのCSVファイルを読み込んでいる可能性があり、おそらく1つのストリームでさえです。そして、他のすべては5-10秒かかります。

狭いデータセットをディスクに書き込む時間（秒単位）（少ないほど良い）：

狭い名前で保存

その後、狭いデータセットの行数を単純にカウントするのにかかる時間を調べました。 AvroとParquetの実行速度は等しく[^ fast-row-count]です。比較のため、また読者を脅すために、非圧縮CSVのカウント時間も計算しました。

寄木細工のファイルには、メタデータにブロック内のオブジェクトの数が含まれています。ワーカーごとのデータ量のこの比率では、それぞれが1つのParquetブロックのみを取得します。したがって、カウントするには、すべての人が1つの数値を読み取ってから、一般的な縮小を行って合計を取得するだけで十分です。

Avroの場合、タスクははるかに複雑です-Avroブロックにはブロック内のオブジェクトの数も含まれますが、ブロック自体ははるかに小さく（デフォルトでは64 KB ）、ファイルには多くのブロックが含まれます。理論的には、avroファイル内のすべてのオブジェクトのカウント時間は長くする必要があります。実際には、このような小さなファイルの場合、違いに気付かない場合があります。

CSVファイルの行数をカウントするには、Avroの場合と同様に、このファイルを完全に読み取る必要があります。 4 GBファイルを正しく分割すると、各ワーカーは80 MBのデータを持ち、数秒で読み取ることができます。ただし、作成者の読み取りプロセスには45秒かかります。これは、ファイルが十分に並列化されていないことを示します。

狭いデータセットの行数を秒単位で数える（少ない方が良い）：

狭い行数

GROUP BY

グルーピングを使用したより複雑なクエリを試した後。このデータセットの列の1つはタイムスタンプであり、毎日別の列の量を計算しました。なぜなら AvroはDate

とTimestamp

サポートしていません。同様の結果を得るためにクエリを微調整する必要がありました。

寄木細工のお問い合わせ：

 val sums = sqlContext.sql("""select to_date(precise_ts) as day, sum(replacement_cost) from narrow_parq group by to_date(precise_ts) """)

Avroクエリのクエリ：

 val a_sums = sqlContext.sql("""select to_date(from_unixtime(precise_ts/1000)) as day, sum(replacement_cost) from narrow_avro group by to_date(from_unixtime(precise_ts/1000)) """)

グループ化されたクエリの場合、ParquetはAvroより2.6倍高速でした。

狭いグループ

次に、 DataFrame

eで.map()

DataFrame

を実行して、データセット全体の処理をシミュレートすることにしました。行の列数をカウントし、すべての一意の値を収集する変換を選択しました。

 def numCols(x: Row): Int = { x.length } val numColumns = narrow_parq.rdd.map(numCols).distinct.collect

.distinct()

操作はタスクを非常に複雑にします。簡単にするために、プロセスにリデュースフェーズを追加すると想定できます。これは、データセット全体の.map()

が測定されるだけでなく、ワーカー間のデータ交換のオーバーヘッドも測定されることを意味します。

これは実際のデータ処理中に実行されるタスクそのものではありませんが、それでもデータセット全体の処理を強制します。また、ParquetはAvroのほぼ2倍高速です。

狭い地図

最後に行う必要があるのは、ディスク上のデータセットのサイズを比較することです。グラフはサイズをバイト単位で示します。 AvroはSnappy圧縮コーデックを使用するように構成され、Parquetにはデフォルト設定が使用されました。

ParquetのデータセットはAvroよりも25％少ないことが判明しました。

狭いディスク使用量

デフォルトの圧縮設定を使用し、それらを調べないことは非常に悪い習慣です。

ただし、Parquet はデフォルトでgzipを使用します。 Gzipは、Snappyよりも著しく強力に圧縮されます。突然、サイズの違いは単にコーデックの違いによるものですか？正しい比較のために、同じ圧縮を使用する場合、またはまったく使用しない場合のデータセットのサイズを計算する必要があります。

また、正直なところ、通常はテキストファイルを時々圧縮できることに注意してください。積極的にgzipベースのソースCSVファイルが1.5 GBを超えないことを認めます。したがって、バイナリ形式の利点はそれほど劇的ではありません。

ワイドデータセットテスト

大規模な「ワイド」データセットに対して同様の操作を実行しました。このデータセットには103列と6億9,400万行が含まれており、194 GBの非圧縮CSVファイルに変換されることに注意してください。

そして、今後、5 GBのParquetと17 GBのAvroが得られることをお知らせします。 500人の従業員がいると、Parquetの場合は100 MB、Avroの場合は340 MBの負荷がかかります。もちろん、寄木細工はコンパクトな収納で勝ちました。しかし、Avroファイルはより多くのブロックを持つことが判明しました。つまり、ワーカーの数を増やすことで処理速度を上げることができます。そのため、クラスターを天井からロードし、ワーカーの数を動的に計算すると、これらのテストよりも優れたAvroパフォーマンスを実現できます。

最初に、両方の形式で幅広いデータセットを保存する時間を測定しました。パーケットは毎回Avroよりも高速でした。

ワイドセーブとして

行数の計算で、ParquetはAvroを完全に破壊し、3秒よりも速く結果を出しました。

広い行数

Parquetはデフォルトで、 128 MBのブロックサイズを使用します。これは、ワーカーごとの平均データ量よりも大きくなります。したがって、Parquetを使用する場合、「狭い」データセットからのトリックは引き続き機能します。データセット内の行数を計算するには、メタデータから1つの数値を読み取るだけで十分です。

Avroファイルの場合は、データセットを完全に読み取り、各ブロックのメタデータのみを解釈し、データ自体を（デシリアライズせずに）スキップする必要があります。これは、ディスクの「実際の」作業に変換されます。 CSVの場合、状況はさらに悪化します。そこでは、すべてのバイトを解析する必要があります。

より複雑なGROUP BY

クエリの場合、Parquetが再びリードします。

広いグループ

ここでは、Avroで3.4倍のワーカーを起動できることを思い出してください。寄木細工はその後リーダーシップを維持しますか

そして、データセット全体の.map()

変換の場合でも、パーケットは説得力のあるマージンで再び勝利します。

広い地図

また、ここでは、Avroで3.4倍以上のワーカーを起動できることも覚えておく必要があります。そして、操作時間のどの割合が.distinct()

を必要とし、どの部分が実際にディスクから読み取られますか？

最新のテストであるディスク使用効率のテストでは、両方の参加者に印象的な結果が示されました。 Parquetは元の194 GBを4.7 GBに圧縮することができ、97％を超える大きな圧縮を実現しました。また、Avroは、データを16.9 GBに圧縮する（91％の圧縮）という印象的な結果を示しました。両方の参加者に称賛：

広いディスク使用量

おわりに

その結果、Parquetは各テストで少なくとも最悪のパフォーマンスを示しませんでした。データ量が増加するにつれて、その利点が明らかになりました。 AvroはParquetの3.5倍の読み取りを行う必要があったため、Parquetの良い結果は圧縮効率の向上に一部起因しています。また、Avroは、彼に起因すると噂されているデータセット全体を読み取ったときに、その高いパフォーマンスを示しませんでした。

Hadoopでストレージ形式を選択する必要がある場合、サードパーティアプリケーションとの統合、スキームの進化、特定のデータタイプのサポートなど、多くの要因を考慮する必要があります...しかし、パフォーマンスを最前線に置いた場合、上記のテストはParquetが最良の選択であることを確信的に示します。

そして、自分から追加します。これは、フォーマットのパフォーマンスの完全に適切な測定です。これは、私たちのチームの業界経験からの多数の散見的な観察によって確認されています。それでも、テスト方法論は、外部アクション（CSV、 GROUP BY', '.distinct()

などGROUP BY', '.distinct()

測定をゆがめることがあり、重要な問題（圧縮、データ形式など）を完全に無視することがあります。「蒸留」メトリックを使用して標準テストを実行するのは簡単ではないことを理解しています。しかし、Clouderaのブログからは、まさにそれを期待していました。

パフォーマンスApache Parquet