説明

グラフィカル ユーザー インターフェイス、テキスト、アプリケーションの説明が自動生成される

ボックス 1: MAX
クエリの最初のステップでは、10 分間のウィンドウ内の最大タイム スタンプ、つまり、そのウィンドウの最後のイベントのタイム スタンプを検索します。2 番目のステップでは、最初のクエリの結果を元のストリームと結合して、各ウィンドウの最後のタイムスタンプに一致するイベントを見つけます。
クエリ:
LastInWindow AS を使用
(
選択する
MAX(時間) AS LastEventTime
から
TIMESTAMP BY 時刻を入力
グループ化
タンブリングウィンドウ(分、10)
)
選択する
入力.ナンバープレート、
入力.作成、
入力時間
から
TIMESTAMP BY 時刻を入力
内部結合 LastInWindow
ON DATEDIFF(分、入力、LastInWindow) BETWEEN 0 AND 10
AND 入力.時間 = LastInWindow.LastEventTime
ボックス 2: タンブリングウィンドウ
タンブリング ウィンドウは、一連の固定サイズの重複しない連続した時間間隔です。
ボックス 3: 日付の差分
DATEDIFF は、2 つの DateTime フィールド間の時間差を比較して返します。詳細については、日付関数を参照してください。
参照：
https://docs.microsoft.com/en-us/stream-analytics-query/tumble-window-azure-stream-analytics

シナリオ: 2 年以上前の Twitter フィード データ レコードを消去します。
データセットには固有のライフサイクルがあります。ライフサイクルの初期段階では、人々は一部のデータに頻繁にアクセスします。しかし、データが古くなると、アクセスの必要性が大幅に低下することがよくあります。一部のデータはクラウド内でアイドル状態のままであり、一度保存されるとアクセスされることはほとんどありません。一部のデータ セットは作成後数日または数か月で期限切れになりますが、他のデータ セットは存続期間中アクティブに読み取られ、変更されます。Azure Storage ライフサイクル管理では、BLOB データを適切なアクセス層に移行したり、データ ライフサイクルの終了時にデータを期限切れにしたりするために使用できるルールベースのポリシーが提供されます。
参照：
https://docs.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
概要
Litware, Inc. は、全米で 300 のコンビニエンス ストアを所有および運営しています。同社は、さまざまな包装食品や飲料のほか、サンドイッチやピザなどのさまざまな調理済み食品を販売しています。
Litware にはロイヤルティ クラブがあり、会員はチェックアウト時に会員番号を入力することで、特定の商品の毎日の割引を受けることができます。
Litware では、Microsoft Power BI を使用したデータ分析を好むビジネス アナリストと、Azure Databricks ノートブックでのデータ分析を好むデータ サイエンティストを雇用しています。
トピック 2、Litware, Inc.
要件
ビジネス目標
Litware は、次の要件を満たすために、Azure に新しい分析環境を作成したいと考えています。
店舗全体の在庫レベルを確認します。データはできる限りリアルタイムに近い状態で更新する必要があります。
履歴データに対してアドホック分析クエリを実行して、ロイヤルティ クラブの割引が割引製品の売上を増加させるかどうかを特定します。
販売データの過去の需要に基づいて、製造する調理済み食品の数を 4 時間ごとに店舗従業員に通知します。
技術的要件
Litware では、次の技術要件を特定しています。
ビジネス目標を達成するために必要なさまざまな Azure サービスの数を最小限に抑えます。
可能な限りサービスとしてのプラットフォーム (PaaS) サービスを使用し、Litware で管理する必要がある仮想マシンをプロビジョニングする必要を回避します。
分析データ ストアには、企業のオンプレミス ネットワークと Azure サービスのみがアクセスできるようにしてください。
可能な限り Azure Active Directory (Azure AD) 認証を使用してください。
セキュリティを設計するときは、最小特権の原則を使用します。
データを分析データ ストアに読み込む前に、Azure Data Lake Storage Gen2 でインベントリ データをステージングします。Litware は、一時データが使用されなくなったら Data Lake Storage から削除したいと考えています。変更日が 14 日より古いファイルは削除する必要があります。
この種のデータは分析に関連しないため、ビジネス アナリストによる電話番号などの顧客連絡先情報へのアクセスを制限します。
破損または誤って削除された場合に、分析データ ストアのコピーを 1 時間以内に迅速に復元できることを確認します。
計画された環境
Litware は次の環境を実装する予定です。
アプリケーション開発チームは、店舗番号、日付、時刻、製品 ID、顧客ロイヤルティ番号、価格、割引額などのリアルタイム販売データを販売時点管理 (POS) システムと出力から受信するための Azure イベント ハブを作成します。データを Azure のデータ ストレージに保存します。
名前、連絡先情報、ロイヤルティ番号などの顧客データは、SaaS アプリケーションである Salesforce から取得され、8 時間ごとに Azure にインポートできます。行の変更日はソーステーブルでは信頼されません。
製品 ID、名前、カテゴリなどの製品データは Salesforce から取得され、8 時間ごとに Azure にインポートできます。行の変更日はソーステーブルでは信頼されません。
毎日のインベントリ データは、プライベート ネットワーク上にある Microsoft SQL サーバーから取得されます。
Litware には現在、5 TB の過去の販売データと 100 GB の顧客データがあります。同社は、今後 1 年間に毎月約 100 GB の新しいデータが発生すると予想しています。
Litware は、FoodPrep という名前のカスタム アプリケーションを構築し、店舗従業員に 4 時間ごとに調理済み食品の数を生産する計算結果を提供します。
Litware は、オンプレミス ネットワークと Azure の間に Azure ExpressRoute または VPN を実装する予定はありません。