+ Alluxioは10個のヒントをチューニングスパーク

（例えばS3など）シーンユニファイドストレージアクセスオブジェクトとHDFSデータの出現と普及ので、Apacheのスパーク組み合わせAlluxioビッグデータは、ますます人気スタック。加えて、ますます人気のコンピューティングとストレージインフラストラクチャは、エンドクエリレイテンシ増加を計算するの分離をもたらします。したがって、Alluxio算出近位端は、多くの場合、パフォーマンスを向上させるために熱ストアデータとして使用されます。最高のパフォーマンスを得るために、我々は、実務経験の最適な組み合わせをたどるようスタックのような他の技術を使用する必要があります。この記事では、Sparkは、Alluxio上で実行されている実際のワークロードのパフォーマンスチューニングのための10個のヒントについて説明しています。

データの局所性について

計算されたノードのローカルデータがネットワークを介してデータの送信を回避するために、データが配置されて移動することが可能となります。並列分散データ環境では、ローカルデータは非常に重要です。大幅スパークジョブのパフォーマンスを向上させることができ、データの局所性を向上させます。計算に必要なデータがローカルノードに格納されている場合、タスクは、ネットワークを介してデータを送信することなく、ローカルにデータAlluxio Alluxioワーカーから（RAMディスクを構成するとき）を直接メモリ読み出し速度スパークであってもよいです。まず、データの局所的な側面についてであるいくつかのチューニングのヒントをご紹介したいと思います。

読み出し動作点検スパークAlluxio中にデータの局所性

同じノード上のホームの展開（共同見つけ）時間とすると、ワーカースパークAlluxioワーカー、Alluxioサポートは、スパークのタスクを計算する（リンク1を参照）短絡リーダーによることができる最高のパフォーマンスを提供します。I / O要求は、次のように実際に短絡Alluxioが提供するデータ・アクセス・サービスは、読み取り/書き込みであるユーザーをチェックする方法はいくつかあります。

方法1：あなたは（リンク2参照）を監視ページAlluxioメトリックUIページを観察するためにスパークミッションを実行すると、2つのインジケータ短絡の上とRemoteInstanceから読み込みます。また、値も観察することができ、cluster.BytesReadLocalThroughput cluster.BytesReadAlluxioThroughput 2つの指標が決定されます。ローカルデータが読み出され、ゼロ又は全体的なスループットよりもはるかに低いのスループットを記述する場合、それはジョブスパークAlluxio作業者がローカルデータ交換ではないかもしれないことを示しています。

方法2：私たちは、短絡が発生したかどうかを確認し、実際のネットワークスループットを読むことができるように使用DSTATは、ネットワークトラフィックなどの検出ツール（リンク3を参照します）。YARNのユーザーもの/ var / / Hadoopの糸/ userlogsは、以下の情報をログログで見ることができます：INFO ShuffleBlockFetcherIterator：開始0リモートは0msとして取り出し、遠隔読み取りを観察し発生した、または読み取るために短絡されます。ジョブを実行しているスパーク、ユーザは、糸関連するパラメータ（例えば-master糸NUM-エグゼキュータ4 4 --executor-コア）を開くためにログが収集さを設定することができます。

ユーザが読み取りまたは上記プロセスによって書き込ま短絡のほんの一部を提供するAlluxioスパークジョブが検出された場合、データの局所性を向上させるために、以下のいくつかの技術を読み取ります。

2必ずスパークエグゼキュータの局所性を確認します

エグゼキュータ（エグゼキュータ局所性）の局所レベル、タスク（タスク局所性）の局所レベル：スパークの地域データは、2つのカテゴリに分けられます。ローカルレベルのスパークジョブの実行者は、（例えばMesos糸のような）他のリソース管理フレームワークによって展開されるとき、スパークエグゼキュータが均一で実行され、Alluxioワーカーノードのために、同時にノードAlluxioワーカー上で実行するように割り当てられることを意味します。地域のエグゼキュータが届かない場合は、Alluxioは、Sparkジョブのローカル・データ・サービスを提供することができません。私たちはしばしば、スパークによってMesosモードの糸または他のリソース管理フレームワーク上のスパークスパークに配備スパークスタンドアロンモードの展開、と比較して、エグゼキュータの局所性がしばしば困難を保証するために、ことがわかりました。

フレームワークにおけるスパークの新しいバージョンはMesos糸及びスケジューリングデータ配信エグゼキュータは、所望のノードで開始エグゼキュータを強制する方法に加えて、ローカルの要因を考慮することができます。したがって、単純な戦略は、executorが各ノードに必要な少なくとも一つのエグゼキュータが実行されていることを確認できた各ノード上にある開始することです。

次に、実際の状況に制約を資源に起因する、Alluxioworker通常の生産環境を実行している各ノード上に展開されてまだ比較的困難です。展開同じAlluxioworkerの計算ノードを（共ロケート）を設定することができるように、ユーザは、（リンクテキスト4の端部を参照）、リソース管理フレームワークの関数を同様の糸ノードのラベルを使用することができます。具体的には、まず、Alluxioworkerを含むラベルは、ノード標識NodeManagersは、（特定のタグ名は重要ではない）alluxio。そして、ユーザはalluxioスパークラベル指定されたノードにジョブを送信します。最後に、システムはAlluxioの労働者で、これらのマシンのノードとの仕事上の執行スパークジョブを開始します。

3スパークタスクの局所性を確認してください

タスクレベルのローカルデータは、Spark自体によって決定され、次のレベルに属する地域です。一旦到達タスクエグゼキュータは、ローカル表示を開始、スパークタスク（ローカルAlluxioエグゼキュータによって提供されるタスク・スケジューリング・データを実行するために、シーンAlluxioと一緒にすなわち）にデータ局所エグゼキュータ満たす上で実行されるようにスケジュールすることができます。この目標を達成するために、スパークタスクスケジューラはAlluxioからのすべてのデータの位置情報を収集する必要があります。ホスト名のリストへの位置情報はAlluxioワーカー表現しました。次に、ホスト名スパークエグゼキュータのスケジュールに合わせてみてください。ユーザーは名前AlluxioワーカーをホストするAlluxioマスターのWeb UIから見ることができ、あなたはまた、スパークドライバのWeb UIでホスト名スパークexecutorを見つけることができます。

しかし、時には、ネットワーク環境または別の構成に応じて、同じマシンAlluxioワーカーとスパークキュータ上で動作しているホスト名が提供一致しない場合があります。この場合、スパークタスクスケジューラは、データの局所性を確保することができないのホスト名と一致して混乱させます。そのため、同じ「ホスト名の名前空間」のホスト名スパークエグゼキュータとホスト名Alluxioワーカーは非常に重要です。一つの問題は、ユーザーが頻繁に遭遇することです：AlluxioワーカーとスパークキュータIPアドレスは、ラベルを使用して、および他の示されたホスト名を使用して。この問題が発生した場合、ユーザーはまだAlluxioクライアントプロパティalluxio.user.hostnameを設定することができます（リンク5参照）を解決するために、同じ値のalluxio.worker.hostnameプロパティを手動でスパークし、労働者Alluxio問題。さらに、ユーザーはまた、JIRASPARK-10149（リンク6を参照）、オープンソースコミュニティのSparkソリューションを確認することができます。

4スパーク優先因子ローカルスケジューラ

地域について、スパーククライアントは、チューニングのために利用可能ないくつかの設定パラメータがあります。具体的には、spark.locality.wait：タイムアウトがローカルタスクの次の優先レベルを開始した場合、デフォルトの即ち、データ待ち時間局所分解は、3000ミリ秒です。異なる優先順位の地域にも同様に適用可能で、この設定パラメータ（PROCESS_LOCAL、NODE_LOCAL、RACK_LOCAL、ANY）。また、待ち時間の地方の慣習の各ノードを有効にする、地域の特定のパラメータspark.locality.wait.nodeレベルに設定することができます。

ロードバランシング

ロードバランシングは、利用可能なスパークジョブの実装は一様に異なるノードに配布することができることを確認することが可能であり、また非常に重要です。ここでは不均一な荷重やタスク・スケジューリングにAlluxio入力データスキュー結果を回避する方法いくつかのヒントです。

UFSからDeterministicHashPolicy Alluxio冷読み出しデータを用いて5

ジョブに複数のタスクをスパークは、多くの場合、同じ入力ファイルを読み込みます。ファイルがAlluxioにロードされていない場合は、デフォルトでは、UFSは異なるローカルタスクAlluxioワーカーは、同じファイルを読み込みます。これは、次のような結果になることがあります。

複数Alluxio労働者が同時に同じデータ接続Alluxio-UFSを競います。AlluxioからUFSへの接続速度が遅い場合は、これらの不必要な競争が遅いデータ読み出し速度に起因しているため、各ワーカーになります。

同じデータがキャッシュ領域にAlluxio複数のコピーを保存され、多くのスペースを無駄にし、間接的にAlluxioキャッシュ空間から解放される他の有用なデータクエリのものを。

この問題を解決する1つの方法は、不必要な競争を避けるために、UFSからプロセスAlluxioワーカー読み取りデータを調整するためにDeterministicHashPolicyのalluxio.user.ufs.block.read.location.policyを設定することです。例えば、編集スパーク/ confには、4つのランダムAlluxioワーカーの最大値は、データの所与のブロックを読み取るようにすることを確実にするために/spark-defaults.conf。（数alluxio.user.ufs.block.read.location.policy.deterministic.hash.shards特定のパラメータによって決定されます）

spark.driver.extraJavaOptions = -Dalluxio.user.ufs.block.read.location.policy = alluxio.client.block.policy.DeterministicHashPolicy

spark.executor.extraJavaOptions = -Dalluxio.user.ufs.block.read.location.policy.deterministic.hash.shards = 4

上記構成によれば、ランダムに4つの対応ワーカーの異なるセットを選択する異なるデータ・ブロックのためのシステムことに留意されたいです。

図6は、より高い並列Alluxio小さいブロックを使用します

データブロック（ブロック）が最小Alluxioシステム記憶部です。Alluxioデータブロックサイズ（デフォルトは512MBです）ロットに比べてファイル自体た場合、そのファイルはわずか数ブロックが含まれていることを意味します。そのため、ファイルを読み込むパラレルためのサービスを提供するために、わずか数Alluxio労働者でした。具体的には、NODE_LOCAL地域のデータを得るために、相の「スキャンファイル」スパークでは、タスクは唯一のサーバプロセスの一握りに割り当ててもよいです。これは、サーバーのほとんどは、クラスタの負荷の不均衡、貧しい取り扱い同時実行で、その結果、アイドル状態の原因となります。この場合には、より小さなブロックAlluxio組織格納ファイル（128メガバイト以下に例えば、alluxio.user.block.size.bytes.default）の使用は、そのようなそのファイル、ファイルのデータブロックの数を増やすことができます並列ファイルの度合いを高めるために、分散複数のマシンに格納されたデータは、データを読み取ります。。データ・ブロック・サイズAlluxioは、HDFSのブロックサイズに強制されますので、UFSは、HDFSのとき、付勢Alluxioブロックサイズが接近することは適用されないことに注意してください。

数7および各エグゼキュータのタスクエグゼキュータの数を調整し、最適化します

タスク実行中に実行さのあまり、同時にと競合するネットワーク接続、ネットワーク帯域幅および他のリソースを引き起こす可能性がありAlluxioからデータを読み取ります。ノードの数に基づいてAlluxio作業者は、ユーザが適切に番号及び（火花に備えていてもよい）、各エグゼキュータのタスクエグゼキュータの数を調整することができる良好にタスクに割り当てられた複数のノード（Alluxioより高い帯域幅を得ます）そして、リソースの競合のコストを削減します。

Alluxioに8つのプリロード・データ

Alluxioは、透明性と非同期のキャッシュメカニズムを提供していますが（リンク7を参照）が、ユーザーの最初のコールド・リーディングは、まだパフォーマンスのオーバーヘッドが存在します。この問題を回避するために、ユーザーは、次のコマンドを使用してメモリ空間にプリロードデータをAlluxioしようとしています。

bashの

$ビン/ alluxio FS負荷/パス/に/ロード

-Dalluxio.user.ufs.block.read.location.policy = alluxio.client.file.policy.MostAvailableFirstPolicy

注：loadコマンドは、単にターゲットAlluxioに基本的なファイルに保存され、このノードからロードされ、そのAlluxioへのデータの書き込み速度は、多くの場合、単一のサーバノードに制限しました。Alluxio 2.0において、我々は、スループットを向上させるために分散負荷データロード機能を実装する予定。

容量管理

Alluxioは、ユーザ入力データバッファホットスポットサービスの高いレベルを提供します。実際には、キャッシュ割当量の正確かつ合理的な配分と管理能力が良好なパフォーマンスを得るためにも非常に重要です。

9拡張HDDまたはSSDシステムの記憶容量を使用してAlluxio

Alluxio労働者とローカルストレージリソース相補SSD（ソリッドステートドライブ）を使用してRAM（メモリ）、またはHDD（ハードディスク）であってもよいです。データを減少させるためにAlluxioのストレージスペースを除外した、我々はAlluxio蓄積層だけではなく、単一のストレージ層にマルチレベルの格納ディレクトリを設定することはお勧めし、詳細が8の最後にあるリンクを参照してください。AWS EC2注にAlluxio労働者を実行しているユーザー：ローカルディスクのデータとしてマウントEBSストレージはデータアクセスが遅くなることが発生する可能性がありますネットワーク上で送信されます。

10は、キャッシュスラッシングを防ぐために、受動的なキャッシュ機能を閉じます

追加データがキャッシュされたかどうかを制御できalluxio.user.file.passive.cache.enabled Alluxioクライアントの設定パラメータは、中Alluxioをコピーします。このプロパティは、デフォルト（つまり、真= alluxio.user.file.passive.cache.enabled）で有効になっています。そのため、クライアントがデータを要求した場合、データキャッシュAlluxio労働者はすでに、他の労働者に存在してもよいです。このプロパティがfalseの場合、Alluxioの収納スペースには、データは、任意の余分なコピーを持っていません。

属性がオンになっている場合、特に、同じデータブロックが作業者の複数にアクセスすることができ、そのようなマルチコピー・ストレージは、全体的な記憶容量Alluxioスペースを減少させます。ストレージ容量とAlluxioのデータセットのサイズ、受動的なキャッシュデータの局所性に近いがAlluxioワークロードが有益であるより大きなストレージ容量を必要としません。将来、Alluxio 2.0は、最小の柔軟な構成とコピーAlluxio指定されたファイルの最大数として、データセットのより詳細なコピーをサポートします。

付録のリンク：

リンク1：

https://www.alluxio.org/docs/1.8/en/Architecture-DataFlow.html#local-cache-hit

リンク2：

http://www.alluxio.org/docs/1.8/en/operation/Metrics-System.html

リンク3：

https://linux.die.net/man/1/dstat

リンク4：

https://hadoop.apache.org/docs/r2.9.1/hadoop-yarn/hadoop-yarn-site/ノードラベル。HTML

リンク5：

http://www.alluxio.org/docs/1.8/en/compute/Spark.html#advanced -setup

リンク6：