データスキューとは
ハイブを使用してデータをフェッチする場合、単純な結合ステートメントを実行するだけで、長時間実行されることがあります。クラスターリソースの不足が原因であると考えることもありますが、ほとんどの場合、 「データスキュー」の状況。
一般的に、データスキューには2つのケースがあります。
変数値はほとんどありません。単一の変数値は、性別、教育、年齢などの一般的なフィールドの大部分を占めます。
多くの変数値があります。単一の変数値の割合は非常に小さく、収益や注文額などの一般的なフィールドは似ています。
MapReduceプログラミングモデルで非常に一般的なデータスキューは、多数の同一のキーがパーティションによってパーティションに割り当てられるため、並列計算の本来の意図に反する「1つが使い果たされ、他のものがアイドル状態」になるという状況です。効率は非常に低いです。
データスキューの理由
99％（または100％）で長時間維持するタスクの進行状況を見ると、タスク監視ページを見ると、少数（1つまたはいくつか）のreduceサブタスクしか完了していないことがわかります。処理するデータの量が他の削減とあまりにも異なるため、これはデータスキューの直接の現れです。
この理由は、次の点に大別できます。
1）不均一なキー配布
2）ビジネスデータ自体の特徴
3）時計を組み立てる際の不十分な考慮事項
4）一部のSQLステートメントには、本質的にデータスキューがあります
次の一般的な操作で具体化できます。
Hadoopコンピューティングフレームワークの機能
データスキューを回避する方法を理解する前に、Hadoopフレームワークの機能を見てみましょう。
大容量のデータは大きな問題ではありません。データの傾きは大きな問題です。
多数のジョブがあるジョブの効率は比較的低く、たとえば、数百万のテーブルがある場合でも、複数の関連付けが複数回実行されると、ダースのジョブが生成され、時間がかかります。その理由は、マップによりジョブの初期化時間が短縮されるためです。
sum、count、max、minなどのUDAF（ユーザー定義集計関数）は、データの偏りを恐れていません。Hadoopは、データの偏りが問題にならないように、マップ側で集計および最適化します。
カウント（個別）、データ量が多い場合は効率が低下します。カウント（個別）が多い場合は効率が低下します。これは、カウント（個別）がフィールドごとにグループ化され、個別のフィールドでソートされているためです。男性uv、女性uv、淘宝網1日30億pvなど、性別でグループ化すると、2つの削減が割り当てられ、それぞれの削減で15億のデータが処理されます。
最適化の一般的な手段
まず、データの分布を理解する必要がありますが、データの傾きの問題を自分で解決することをお勧めします。
jvm（Java仮想マシン：Java仮想マシン）メモリを増やします。これは、変数の値が非常に小さい場合に適しています。この場合、多くの場合、ハードウェアによってのみ調整できます。jvmメモリを増やすと、操作効率が大幅に向上します。
多くの変数値がある場合に該当する、reduceの数を増やします。この場合、最も可能性の高い結果は、同じキーが多数パーティションに分割され、reduceが多くの作業を実行することです。
キーを再設計するには、マップ段階で乱数をキーに追加する解決策があります。乱数を持つキーは、同じノードに大きな数で割り当てられることはなく（確率が低い）、乱数は削減後に削除されますただ
結合するにはコンバイナを使用します。Combinnerはマップステージにあり、削減の前の中間ステージです。このステージでは、大量の同じキーデータを最初に選択的にマージできます。これはローカル削減と見なすことができ、次にマップサイドを削減するために削減に渡されます。リデュースエンドに送信されるデータの量（ネットワーク帯域幅の削減）、およびマップエンドとリデュースエンドの間のシャッフルフェーズでのデータプルの数の削減（ローカライズされたディスクIOレート）;（hive.map.aggr = true）
適切な数のmap reduceタスクを設定すると、パフォーマンスを効果的に改善できます。（たとえば、160wの削減を使用した10w +レベルの計算は非常に無駄が多く、1つで十分です）;
データの量が多い場合は、count（明確）を慎重に使用し、count（明確）は傾斜の問題を起こしやすい傾向があります。
hive.groupby.skewindata = true;
データの偏りがある場合にロードバランシングが実行されます。このオプションがtrueに設定されている場合、生成されたクエリプランには2つのMRジョブがあります。最初のMRジョブでは、Mapの出力結果セットが無作為にReduceに分散されます。Reduceはそれぞれ、部分的な集計操作を実行して結果を出力します。このように、処理された結果は同じGroup By Keyであり、別のReduceに分散できます。 、ロードバランシングの目的を達成するために、2番目のMRジョブは、Group By Keyに従って前処理されたデータの結果に応じてReduceに分散され（このプロセスにより、同じGroup By Keyが同じReduceに確実に分散される）、最後に最後のジョブが完了する集計操作。