スパークSQLのための5つの理由寄木を選択
次の詳細は、寄木SparkSQLなどの理由は、デフォルトの入力および出力データ・ソースを使用します。
どのように強力な寄木はいを理解するために、我々は、TPC-DSを完了するために24を選択した（99件の問い合わせの合計を比較するクエリから派生し、1TBのスケーリングにおける一部のクエリは、火花PERF-SQLで平面から使用することはできませんCSVデータファイル。より下記参照）。レポート、アドホックレポート、およびデータマイニングの反復：これらのクエリはTPC-DSのすべてのカテゴリを表します。私たちは、短いクエリ（クエリ12及び91）と長時間実行クエリ（クエリ24a及び25）、及び用途のよく知られたクエリ（クエリ97）の100％のCPUを含めることを確認する必要があります。
私たちは、各Ciscoはデザインが同様の構成を有する検証前提のCisco UCSクラスタノード6を、使用していました。あなたはすべてのテストでネットワークやディスクIOのボトルネックが発生した場合、我々はチューン基礎となるハードウェア、。この記事では理解スパークに焦点を当て1.5.1スパーク1.6.0リリースされたばかりとだけこれらのクエリのテキストや寄せ木ストレージフォーマットを実行し、どのようにパフォーマンスの違いがします。スパーク総労働ストレージは500ギガバイトです。1TBの規模をTPCは-DS。
寄木細工を使用高速化1.スパークSQL！
下のグラフは、すべてのスパーク1.5.1クエリ実行時に実行さ24の合計を比較します。平面CVSファイルを使用する場合は、クエリが完了するまでに約12時間を要し、かつ使用寄木張りで、時間の1時間未満での問合せは11倍の性能向上を完了させます。
良好寄せ木より大規模に使用する場合2.スパークSQL性能（すなわち使用は、寄木細工多くの問題の発生を低減することができます）
多くの場合、診断が困難と修復が困難につながる選択肢の不適切な保存形式。スケーリングの1TBを使用するときには、フラットCSVファイルを使用した場合、すべてのクエリは、クエリの少なくとも三分の一、実行することができます完了したが、寄木細工を使用した場合、これらの問い合わせが完了することができません。
非常に神秘的ないくつかのエラーと例外。3例があります。
頻繁に発生する問題のいくつか：
例1エラー：
このエラーは、ときに例外マップした後、シャッフルは、データを取得することができないと言うことですつまり、非常に一般的です。
| 1 2 3 4 |
|
例2エラー：
このエラーは、非常に一般的であり、シャッフルのために、データが失われたと言われています。
| 1 2 3 4 5 6 7 |
|
例3エラー：
このエラーは、非常に一般的であり、実行者データの損失を終了します。
| 1 |
|
再キューイングされたタスクフォーススパーク（あるいはいくつかの段階に再起動）によって、ほとんどのクエリの失敗はやり直してください。その後、物事が悪くなるので、最終的には、アプリケーションは決して完全なように、失敗します。
寄木張りに切り替えることにより、他のコンフィギュレーションスパークを変更せずに、これらの問題が解決されました。圧縮は、列フォーマットのみ入力データを削減するために、選択したレコードを読み込むことができます直接（詳細は下記参照）スパークDAG実行スケジューラに関する意思決定に影響を与える、ファイルサイズが小さくなります。すべてのこれらの利点は、迅速寄木クエリに重要です。
3.少ないディスクIO
寄木張りがあり、75％、平均でデータストレージを許す圧縮機能を使用して、ディスク上のデータファイルの1TBの圧縮率は、ディスク容量の250ギガバイト程度占有します。これは、大幅に必要な入力データスパークSQLアプリケーションを低減します。スパーク1.6.0で、寄せ木リーダはさらに、ディスクIOを減らすためにプッシュダウンフィルタ（述語プッシュダウン）を使用します。データはスパークに読み込まれる前に、プッシュダウンフィルタは、データの開発に選択決定を可能にします。例えば、節97の間の処理クエリは次のように
| 1 2 3 4 |
|
スパークSQLステートメントは、クエリのための物理的な計画のスキャンを示しています。
| 1 |
|
ここで、PushedFiltersは1200年から1211年d_mont_seq列の範囲内で返されたレコード、または少数のレコードが返されます。フラット・ファイルを使用するときに物理プログラムに示すように、フラットファイルと比較し、それは、テーブル全体（各列及び各行）を読み出します。
| 1 |
|
4. Spark 1.6.0 提供了更高的扫描吞吐量
Databricks 的 Spark 1.6.0 发布博客中曾经提到过显著的平面扫描吞吐量，因为该博客使用到了 “更优化的代码路径” 一词。为了在现实世界中说明这一点，我们在 Spark 1.5.1 和 1.6.0 中运行了查询 97，并捕获了 nmon 数据。改进非常明显。
首先，查询响应时间减少了一半：查询 97 在 Spark 1.5.1 中用了 138 秒时间，而在 Spark 1.6.0 中只用了 60 秒。
图 2. 使用 Parquet 时查询 97 所用的时间（以秒为单位）
其次，在 Spark 1.6.0 中，工作节点上的 CPU 使用率更低一些，这主要归功于 SPARK-11787：
图 3. Spark 1.6.0 中的查询 97 的 CPU 使用率，最高时为 70%
图 4. Spark 1.5.1 中的查询 97 的 CPU 使用率，最高时为 100%
与上述数据相关，在 Spark 1.6.0 中，磁盘读取吞吐量要高出 50%：
图 5. Spark 1.5.1 和 1.6.0 中的磁盘读取吞吐量
5. 高效的 Spark 执行图
除了更智能的读取器（比如 Parquet）之外，数据格式也会直接影响 Spark 执行图，因为调度程序的一个主要输入是 RDD 计数。在我们的示例中，我们使用文本和 Parquet 在 Spark 1.5.1 上运行了相同的查询 97，我们获得了各个阶段的以下执行模式。
使用文本 – 有许多长时间运行的阶段（请注意，y 轴上使用的单位是毫秒）
图 6. 使用文本的执行阶段
在使用 Parquet 时，虽然有更多的阶段，但工作的执行速度很快，而且只创建了两个长时间运行的阶段就接近了工作尾声。这表明 “父-子” 阶段的边界变得更明确，因此需要保存到磁盘和/或通过网络节点的中间数据变得更少，这加快了端到端执行的速度。
图 7. 使用 Parquet 的执行阶段
结束语
Parquet 用于 Spark SQL 时表现非常出色。它不仅提供了更高的压缩率，还允许通过已选定的列和低级别的读取器过滤器来只读取感兴趣的记录。因此，如果需要多次传递数据，那么花费一些时间编码现有的平面文件可能是值得的。