スパーク最適化の概要（） - データスキュー

1.はじめに

アプリケーション開発プロセスにおけるスパークは、通常、パフォーマンスの問題のほとんどは、傾きデータポイントです。データスキューの問題については、我々は次のように応じて状態の実行を分離することができます：
- チルトデータソース
- ストレージは、結果を歪め
- チルトランタイム（問題の大部分）

2.データソースの傾き

説明
- スパークを使用してデータを読み出す際に、我々のデータソースは、通常、それぞれの個々のノードのデータ・ソースからデータを読み取るためにスパークを必要とストレージを、分散されます。何らかの理由で、偏在クラスタの各ノードに格納されたデータのいくつかの部分で、その結果、その後の時間は、データを読み取るために必要な最も遅いノードに等しい場合
- 例えば、データ配信ノード10は、データ量が他のノードの5倍であり、ノードで
例：データはハイブ浴槽傾いリードポイント
- 浴槽は、テーブルの設定、データが均等にクラスタに分散させることができるように選択された行の良好な分布がある場合にハイブ設計テーブルを分割することができます。
- あなたは、列の間違ったディストリビューションを選択した場合、それはおそらく、他のノードと少数ながら、いくつかの非常にマルチノード・データにつながることがあります。スパークでハイブテーブルを読み込むときに、あなたはデータノードが終了するまで待機する必要があります。
たとえば、次のデータは、傾斜隔壁カフカから生じます
- トピックにカフカの生産データ、パーティションを指定することができ、キーまたはデフォルト値は、パーティションのトピックに送信されたデータを決定するために使用。
- その結果、パーティション、キーがない場合は、データのトピック一定量を分割するためにつながるはるかに他のパーティションを超えています。データSparkStream（又はStructuredStream）トピックアセスを使用ときに、データは、過度のスパーク単一のアクセスノードを導くことができます。

3.データストレージに傾斜

説明
- スパークは、一般的に処理されたデータ、データクラスタを格納するための必要性を利用しています。一般的には、HDFS、HIVEおよび他のクラスタストレージのパフォーマンスの問題は存在しません。デザイン、原因のデータはほとんどどのノード（またはノードへのアクセス）を堆積させる必要性を保存するためにいくつかの理由のために、クラスタに保存されている場合は、スパークは明らかに最後に、ストレージノードの完了を待つ必要があります。
たとえば：ハイブはバレル、カフカのパーティションを指します
- 同様に、データソースと傾斜
例：分散MPPアーキテクチャデータベース
- 一般に、マスターの複数の分散データベースアクセスにJDBC / ODBC接続ノードが存在することになります。あなたが唯一のマスターノードのIPを設定するスパークストレージを使用する場合、それはストレージ効率が得られ、分散データベースアクセスノードサージにつながる可能性があります。
- ソリューション：
  - スパークは、ランダムにノードを選択し（各指定された）データベースのマスターノードたIP
  - 自身のデータベースのデータのインポートツール（典型的には一括インポート）
- 、データベースを分散していない場合はさらに、データベースが一つのノードのみが利用可能であるならば、それはまた、この問題が発生します
たとえば、次のHBaseの者のrowKeyの設計ミス
- HBaseのデータは、ノードデータの同様のソートが記憶されている、自然のrowKeyでソートされます。データを同時にHBaseのテーブルに似た自然な順序でロードされている場合は、ホットスポット領域を引き起こす可能性があります。
- 例えば、リアルタイムのデータ収集SparkStreamのHBaseの使用は、テーブルは、時間ののrowKey先頭に設計されている場合、それは常にホットな問題、最終的にストレージのパフォーマンスにつながる、近いデータストレージの自然な順序になり、テーブルをロードしました。
- ソリューション：
  - 時間の初めにデザインのrowKeyありません
  - 各クエリは、特別のrowKey知ることができる取得であれば、あなたは、時間の値を前に移動し、いくつかの後になるようにランダムにデータストレージことができ
  - データは、一般的にHIVEバックアップに必要とされている間、リアルタイムのストレージを必要としない、あなたはそれがデータをスクランブルしますrepartiton、スパークバルクデータを読み、[ストレージのHBaseに置くことができます

4.データ傾斜ランニング

データのフィルタリングに起因4.1凹凸

開発する場合、事前ろ過でよくデータを処理する前に、それは良い習慣です。しかし、フィルタ基準は、（例えばここで、フィルタ）パーティション（パーティションより少ないデータがフィルタ基準を満たすため）、および他の多くの地域のデータの少ないデータ部分をもたらし得る、この時間は、ステージほとんどの実装に依存するであろう遅いノード（データまで）。
たとえば、次のデータが均等千万パーティション各ノードについて、パーティション10に分配されます。あなたは、特定の条件に応じてデータをフィルタリングして、処理動作を実行する必要があります。3つのパーティションとすることができる、フィルタリングデータは900万人程度資格がある場合は、他の7つのパーティションには、2万人の資格に関するものです。その後のロジックに進み、終了するステージ3パーティションデータの終了まで待機するには、この見かけ上の必要性が（論理フィルタリング処理を実行するために多くの時間がかかる必要である場合、例えば、さらにデータの各10秒、その後の効果が特に顕著です）。
ソリューション：
- 再び使用repartion分布データ。あなたのデータは、傾斜の度合いが行うことができないではない場合repartionがシャッフル操作であることに注意してください、ネットワーク伝送は、時間のかかるが必要です。あなたはコストと時間repartionデータが発生するスキュー比較する必要があり、時間手段を過ごした後、決定を下します。
- 合体について、このほとんど効果が合体ローカル・ノードがマージ彼らのパーティションであるため、データスキューの問題を解決しません

異常データにより引き起こさ4.2デフォルト値の変化、

データは、開発、優先度の調査で遭遇スキュー。通常処理のフィールドにデフォルト値を与える可能性がある原因上流解決の問題があるか（たとえば、@＃¥％など）異常な値（たとえば、0、NULL、空白文字、など）。
パーティションキーをシャッフル列として使用される場合、例えば、100,000,000データテーブルの合計は、前記文字列「01234」の80％のデフォルト値、データは傾きが発生します。
データ行の値を、その後、事前に除外されていない場合、デフォルトまたは統計外れ値の良い割合にオススメ。あなたがする必要がある場合は、パーティション・キーシャッフルなどの別の列を選択するための方法を考える必要があります。

4.3は、凹凸結果のデータを結合します

必要なカラムを選択するときに操作が斜めに傾斜する列の値を結合する場合、加入。
例えば：都市フィールドを含む百万約10オーダ情報のバッチ、ここで、A、Bよりため市内次数（各300万人程度）、より少ない他の都市次数（双方未満5000万以上）。選択した都市フィールドが参加した場合、我々は、データに関連付けられている市関連のデータを持っている必要があります。この時点で、都市の注文情報は、各パーティションのノードに配布されるようになります。明らかに、データA、B市発注の量より大きなパーティションの各ノード、処理されたパーティションを待つ必要、ステージは終了とみなします。
ソリューション：
- マップ側に使用する放送が参加します
- 例：
  - スパークコードの読みやすさとパフォーマンスの最適化 - の典型的な5（ハッシュ結合）