mixとmaxを使ってデータを分割する理由は何ですか？

Question

私はそれが基本的にこのロジックを使用して、Sqoopはマッパーの間で作業を分割する方法を知っている：（= 1（1）mytableはSELECT * FROM）T1から

MIN（ID）を選択し、MAX（ID）

ここで、idは--split byで定義された値です。私は--boundary-queryを使って別のロジックを使ってこのロジックを変更できることも知っています。

たとえば、キー列の値が均一に分散されていない場合、たとえばレコードが10個あり、これを5つのマッパーで実行するとしたらどうなるでしょうか（OK、これは一例です）：

id_column: 1,200,201,202,203,204,205,206,207, 208, 209, 210, 211 
splits: (211 - 1)/5 = 42 

mapper1 = from 1 to 42 ==> 1 record processed 
mapper2 = from 42 to 84 ==> 0 records processed 
mapper3 = from 84 to 126 ==> 0 records processed 
mapper4 = from 126 to 168 ==> 0 records processed 
mapper5 = from 168 to 211 ==> 12 records processed 

は、たぶん私は一例でミスを犯したが、私が言及したいのは、我々はなりませんレコードの数と、マッパーの間でアンバランスの仕事を持っているということです大したことではありませんが、何百万ものレコードについて話しているときは、パフォーマンスに大きな影響を与えます。言われていること

、私は二つのことを知りたい：

1. 言及したロジックの背後にある考え方は何ですか？ （おそらく、私が見ていないものがあるかもしれません）

2. 例のように一様に分布していないidsカラムを持っている場合、私は回避策をどのように構築できますか？

Answer 1

ロジックの背後にあるアイデアは何ですか？

考えられるのは、主キーを列ごとに分割して使用することです（がある場合は）。一般に、主キーは一様にに配信されます。一般的な方法で問題を解決するために、データを均等に分割することも考えられます。また、ほとんどすべてのRDBMSでmin()とmax()関数を使用できます。

私は2つのマッパーであなたの問題を解決する新しいプロパティを思いついています。

--mapper-range m1=1-10,m2=200-220 

mapper1 = 1〜10 ==> 1つのレコードが処理

mapper2 = 200 220 ==> 12枚のレコードからそれがsqoopためのはるかに困難ではないだろう

を処理開発者は私の新しい魔法のプロパティを使用して、マッパーの範囲クエリを無効にします。

---

ここでは大きなデータについて言及していますが、10億のレコードがあるとします。このためにデータ全体を処理する必要があるため、列ごとの値のパターンを見つけるのは非常にコストがかかります。私は誰もこのコストで私の魔法の財産を買うことに興味がないと思う。

あなたは何かを念頭に置いて考えてください。