ADLテーブルからの読み出し時のデータ抽出の最適化

Question

ラウンドロビン方式でデータをADLテーブルに挿入しています。別のジョブでは、テーブルから3つの異なるパーティションのデータを抽出し、パーティションの不均一な頂点数を観察しました。たとえば、1つのパーティションでは264 GBのデータ用に56の頂点を作成し、別のパーティションでは209 GBのデータ用に2つの頂点を作成します。いくつかの頂点を持つパーティションでは、完了までに膨大な時間がかかりました。添付の画像では、なぜSV5とSV3の頂点が2つしかないのか分かりません。これを最適化し、これらのパーティションの頂点の数を増やす方法はありますか？ここで

は、テーブルのためのスクリプトです：

CREATE TABLE IF NOT EXISTS dbo.<tablename> 
(
abc string, 
def string, 
<Other columns> 
xyz int, 
INDEX clx_abc_def CLUSTERED(abc, def ASC) 
) 
PARTITIONED BY (xyz) 
DISTRIBUTED BY ROUND ROBIN; 

アップデート：ここで

は、データを挿入するためのスクリプトです：私は複数をやっている

INSERT INTO dbo.<tablename> 
    (
    abc, 
    def, 
    <Other columns> 
    xyz 
    ) 
    ON INTEGRITY VIOLATION IGNORE 
SELECT * 
FROM @logs; 

（最大3）パーティションに挿入します。しかし、別の仕事では、データを選択したり、処理をしたり、パーティションを切り捨ててパーティションにデータを戻したりしています。ラウンドロビンのデフォルト配布方式がSV5とSV3の2つのディストリビューションしか作成していないのはなぜですか？私は、この量のデータに対してより多くのディストリビューションを用意したいと考えています。

Answer 1

パーティション内にパーティションとディストリビューションの両方を使用しています。

パーティションにすべてのデータを一度に挿入しますか、またはパーティションごとに複数のINSERTステートメントがありますか？

各ステートメントは、パーティションに新しいファイルを追加し、それが独自の頂点で処理されることに注意してください。

また、ROUND ROBINディストリビューションは、各パーティションファイルに個別に適用されます。

したがって、多くの配布グループが抽出される可能性があります。

シナリオの解釈が正しい場合は、ALTER TABLE REBUILDを使用してパーティションを圧縮してください。

Answer 2

SV1が読んでいるデータを挿入するスクリプトのように、別の方法で挿入すると、時にはそのように見えることがありますが、U-SQLには非常に悪い影響が出ます。ラウンドロビンを使用するが、ディストリビューションを指定しない場合、U-SQLはコンパイル時の推定データサイズに基づいてU-SQLを選択します。これはHASHとDIRECT HASHでも同様です。このための最も堅固な緩和策は、あなたが望む分布が得られるかどうかを知るたびに、INTO節の分布数を指定することです。それはあなたがスイートスポットにあなたを保つように50から200のいずれかのように見えます。