私たちは、テレメトリデータと大きくて広いフラットファイルを持っています。彼らは毎日到着します。スタースキーマ、サロゲートキー
私はスター・スキーマをADLA DBに作成し、これらのワイド・ビッグ・ファイルからデータを取り込みます。
我々のいずれかを使用することができます代理キーを生成するには：（インデックス、statisctics、圧縮、流通管理が... ADLA DB）は反対の生ADLSに（機能の多くを与えるようになります）：
ハッシュについてはどうですか？どのような機能を実装するために使用できますか？
を（私はC＃のことを考えている）まず、私はあなたが代理キーを使用したい理由を理解したいと思います。
現在のU-SQLテーブルはあなたが事前に予想されるクエリのほとんどを知っているバッチクエリをサポートするために設計されています。したがって、最も高価なジョブを最適化するために、配布キーとスキーム（ハッシュ、ダイレクトハッシュ、範囲）とクラスタードインデックスを設計します。あなたは、たとえば、データ・スキューを管理するために、直接ハッシュを使用する必要がある場合は代理キーを持つ
は理にかなっているが、それ以外の場合は、パーティション/配布消去を利用するために複雑さを追加することができます。独自のハッシュ関数を実装するよう
、C＃が、いくつかの組み込みのハッシュ関数を持っているか、あなた自身を書くことができます。例えば、C＃Object.GetHashCodeメソッド。
テレメトリのタイムラインデータがCSVに保存されています。これらのCSVは幅広いです（多くの列）。彼らは大きくなると予想されますが、（ADLAエンジンが期待しているように）1~4Gbの範囲内のすべてのサイズを制御できます。パーティション、ディストリビューション、互換性のある結合/集約、統計などの機能を使用するために、これらのデータをADLA DBに段階的にロードしたいと考えています。これらのデータは非常に冗長で幅広です（多くの列）。すべての主要な問合せの互換性によって、ジョイン/グループを達成するためにフラットなワイド・テーブル用に単一のディストリビューション・スキーマを作成することは不可能です。フラット構造をスタースキーマに分解したい。 – churupaha
この場合、いくつかのDimテーブルを共有するいくつかのFact-Tableがあります。これらのファクトテーブルは、ソースフラットテーブルほど広いものではなく、あらゆる具体的なケースで適切なディストリビューションスキーマを選択できるようになります。また、データセットのサイズを小さくする必要があります。また、これらのファクトテーブルは、大きな文字列ではなく整数からほぼすべてが構成されます（フラットスキーマの場合と同様）。それは集約の利益をもたらすはずです（または、少なくともAzure DWHについては真実でした）。スタースキーマを実装するには、DimTablesのサロゲートキーを生成する方法が必要です。私はrow_numberや何らかのハッシングを使用することができます。 – churupaha
ソースデータとのコンパイルで値の分布を破ってはいけません。私たちは、ソース平らなテーブルに値「Biiiiig文字列1」の列を持っている場合は、「Biiiiigは1文字列」、「Biiiiig文字列は1」、「Biiiiig列2」、「Biiiiigは、文字列3」、彼らは代理整数に置き換えられますので1、1、1、2、3 – churupaha
これはあなたの質問に対する回答ではありません。しかし、ADLテーブルからUSQLで現在UPDATEまたはDELETEできないという事実に対処する必要があると示唆していることを言及する価値はあると考えました。おそらく、再実行可能性を求めて、より多くのパーティションを見る必要があります。 –
はい、わかりました。私は、FactXXXテーブルのDateによるパーティショニングを使用します。 – churupaha