0
管理されたテーブルの400Mのレコードに対して独自のクエリを実行しています。 しかし、開発中は、すべてのレコードに対して常に実行したくないので、where節をポップアップし、データの小さなサブセクションで実行し、約2分（@ AU）で完了します。私のデータ湖のtsvに結果を書き出します。 それに満足です。USQLのネストされたクエリのパフォーマンス
ただし、これを2番目のクエリとそれ以降の処理のソースとして使用したいと考えています。 元のUSQL（where節を除いたもの）でビューを作成します。 はその後、新しいスクリプトをテストするために：
'Select * from MyView WHERE <my original test filter>'.
を今私は、元の生のクエリと同じ時期で実行することを期待していました。しかし、代わりに私は4分、計画を通してわずか10％になってキャンセルしました - 何かが正しくありません。
元のスクリプトは、2つの「抽象コンバイン」パーティションで起動します。両方とも、hundered MBのカップルを読んでいます。保存したビューで私の選択は100GBを超えています！ したがって、この段階ではwhere句は考慮されていません。
これは明らかに、DLAが背後でどのように動作するかについて私がまだ理解していないことを示しています。
誰かが（a）何が起こっているのか、（b）私が必要とする行動を得るための道を理解するのを助けてくれるでしょうか？
現在、テーブルに1番目の結果を格納し、それに対して2番目のクエリを呼び出すためのストアドプロシージャを使用していますが、従来のSQL Serverと比較して過剰です。
すべてのポインタ&ヒントありがとう！ 多くのおかげで
オリジナルベースクエリ：
CREATE VIEW IF NOT EXISTS Play.[M3_CycleStartPoints]
AS
//@BASE =
SELECT ROW_NUMBER() OVER (PARTITION BY A.[CTNNumber] ORDER BY A.[SeqNo]) AS [CTNCycleNo], A.[CTNNumber], A.[SeqNo], A.[BizstepDescription], A.[ContainerStatus], A.[FillStatus]
FROM
[Play].[RawData] AS A
LEFT OUTER JOIN
(
SELECT [CTNNumber],[SeqNo]+1 AS [SeqNo],[FillStatus],[ContainerStatus],[BizstepDescription]
FROM [Play].[RawData]
WHERE [FillStatus] == "EMPTY" AND [AssetUsage] == "CYLINDER"
) AS B
ON A.[CTNNumber] == B.[CTNNumber] AND A.[SeqNo] == B.[SeqNo]
WHERE (
(A.[FillStatus] == "FULL" AND
A.[AssetUsage] == "CYLINDER" AND
B.[CTNNumber] == A.[CTNNumber]
) OR (
A.[SeqNo] == 1
)
);
//AND A.[CTNNumber] == "BE52XH7";
//Only used to test when running script as stand-alone & output to tsv
2番目のクエリ
SELECT *
FROM [Play].[M3_CycleStartPoints]
WHERE [CTNNumber] == "BE52XH7";
ローカルエミュレータがインストールされていると仮定して、Visual Studioのローカル環境を使用することをお勧めします。テストするために縮小されたデータセットをホストし、ドロップダウンを使用して実際のAzure Data Lake Analyticsアカウントにアクセスしてください。私はこれを常に使用し、シームレスなスイッチを愛しています。 – wBob