ハイブ テーブルのストレージ形式として Parquet を使用することにし、実際にクラスターに実装する前に、いくつかのテストを実行することにしました。驚いたことに、Parquet はプレーン テキスト ファイルよりも高速であるという一般的な概念とは対照的に、私のテストでは低速でした。
MapRでHive-0.13を使用していることに注意してください
----------------------------------------------------------
| | Table A | Table B | Table C | |
----------------------------------------------------------
| Format | Text | Parquet | Parquet | |
| Size[Gb] | 2.5 | 1.9 | 1.9 | |
| Comrepssion | N/A | N/A | Snappy | |
| CPU [sec] | 123.33 | 204.92 | N/A | Operation1 |
| Time [sec] | 59.057 | 50.33 | N/A | Operation1 |
| CPU [sec] | 51.18 | 117.08 | N/A | Operation2 |
| Time [sec] | 25.296 | 27.448 | N/A | Operation2 |
| CPU [sec] | 57.55 | 113.97 | N/A | Operation3 |
| Time [sec] | 20.254 | 27.678 | N/A | Operation3 |
| CPU [sec] | 57.55 | 113.97 | N/A | Operation4 |
| Time [sec] | 20.254 | 27.678 | N/A | Operation4 |
| CPU [sec] | 127.85 | 255.2 | N/A | Operation5 |
| Time [sec] | 29.68 | 41.025 | N/A | Operation5 |
- Operation1: 行カウント操作
- 操作 2: 単一行の選択
- 操作 3: Where 句を使用した複数行の選択 [1000 行をフェッチ]
- 操作 4: 複数行の選択 [4 列のみ] Where 句を使用 [1000 行を取得]
- 操作5: 集計操作 [特定の列で sum 関数を使用]
両方のテーブルに適用したほぼすべての操作で、行カウント操作を除いて、クエリの実行にかかる時間の点で Parquet が遅れていることがわかります。
また、テーブル C を使用して前述の操作を実行しましたが、結果は TextFile 形式とほぼ同様の行にあり、2 つのうちでより鮮明でした。
誰かが私が間違っていることを教えてもらえますか?
ありがとう！
編集
ストレージ形式のリストに ORC を追加し、テストを再度実行しました。詳細に従います。
行カウント操作
テキスト形式累積 CPU - 123.33 秒
Parquet 形式の累積 CPU - 204.92 秒
ORC フォーマット累積 CPU - 119.99 秒
ORC with SNAPPY 累積 CPU - 107.05 秒
列演算の合計
テキスト形式累積 CPU - 127.85 秒
Parquet フォーマット累積 CPU - 255.2 秒
ORC フォーマット累積 CPU - 120.48 秒
ORC with SNAPPY 累積 CPU - 98.27 秒
列操作の平均
テキスト形式累積 CPU - 128.79 秒
Parquet 形式の累積 CPU - 211.73 秒
ORC フォーマット累積 CPU - 165.5 秒
ORC with SNAPPY 累積 CPU - 135.45 秒
where句を使用して特定の範囲から4列を選択する
テキスト形式累積 CPU - 72.48 秒
Parquet 形式の累積 CPU - 136.4 秒
ORC フォーマット累積 CPU - 96.63 秒
ORC with SNAPPY 累積 CPU - 82.05 秒
それは ORC が Parquet よりも速いということですか? または、クエリの応答時間と圧縮率を改善するためにできることはありますか?
ありがとう！