Skip to content

MS_AzureStreamAnalytics

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azure Stream Analytics

概要

  • デバイスやセンサーなどからのストリーミングデータを分析するサービス

  • Spark Structured Streaming（DNET_SparkStructuredStreaming.md）も
    少しづつ解ってきているケド、解らない事と言うか、
    ハマり所が多いので、Stream Analytics でイイかな？などと思い始めたりした。

  • ただし、独自のクエリ言語を覚えるのが、なんと言うか、チョット、アレ。

補足（この評価は妥当）: 「Spark はハマり所が多いので Stream Analytics で
イイかな」という判断は、多くの現場で追認される。

Stream Analytics Spark Structured Streaming
記述 SQL ライク（数行で書ける） Python / Scala のコード
運用 完全マネージド（クラスタ管理なし） クラスタのサイズ・チューニングが要る
状態管理 サービスが面倒を見る チェックポイント設計が必要
表現力 定型的な集計・フィルタ・結合 任意の処理（ML 連携など）
課金 SU（ストリーミング ユニット）単位 クラスタ稼働時間

「定型的なストリーム処理なら Stream Analytics、
複雑な変換や機械学習を伴うなら Spark」という切り分けになる。

なお「独自のクエリ言語」は T-SQL のサブセット ＋ 時間窓の拡張であり、
SQL を知っていれば習得コストは高くない（後述のウィンドウ関数が要点）。

詳細

BLOB や Azure Event Hubs、Azure IoT Hub からデータを入力し、

クエリ言語

  • SQL ライクな Stream Analytics の独自のクエリ言語でデータ処理
  • 入出力に関して、プログラムを一切書かなくてもイケる。

データ出力

処理データを再度、BLOB や Event Hubs、SQL Database に出力（保存）可能。

関数

以下の関数が使用できる。

ユーザー定義関数

JavaScript や C# で記述する。

ウィンドウ関数

Group By で使用する。

  • TumblingWindow
    指定時間間隔毎（例えば 10 秒間隔毎）にデータをまとめる。

  • HoppingWindow

    • 指定時間間隔＆指定インターバル毎（例えば 5 秒毎 10 秒間隔）にデータをまとめる。
    • インターバルによって、ウィンドウを重ねたり、間を空けることができる。

  • SlidingWindow

    • 指定時間間隔毎（例えば 10 秒間隔毎）にデータをまとめる。
    • インターバルではなく、データの到着毎に記録される。

  • SessionWindow

    • 類似した時刻に到着するイベントをグループ化する
    • Session の最大継続時間とタイムアウト時間を設定する。

  • SnapshotWindow

    • 同じタイムスタンプのデータをまとめる。
    • System.Timestamp() を GROUP BY 句に追加する

移行メモ（表記）: 原文の「TumbingWindow」は
TumblingWindow（"l" が入る）の誤記と判断し修正した。

補足（ウィンドウ関数がストリーム処理の核）: 「いつからいつまでを
1 まとまりとして集計するか」を決めるのがウィンドウである。
図にすると違いが分かりやすい。

時間 ──────────────────────────────▶

Tumbling  [====][====][====][====]      重ならず、隙間なし

Hopping   [========]                    重なる（または隙間が空く）
              [========]
                  [========]

Sliding        イベント到着ごとに、直前 N 秒を評価

Session   [==イベント群==]  ..空白..  [==イベント群==]
          （途切れたら区切る）

実務上の注意:

  • Tumbling が最も理解しやすく、レポート用途の既定の選択。
  • Hopping / Sliding は同じイベントが複数のウィンドウに属するため、
    出力件数が増える（課金・下流の負荷に影響）。
  • 遅れて到着するイベント（late arrival）と
    順序が乱れたイベント（out of order）の扱いを
    ジョブの設定で決める必要がある。既定のまま本番に出さないこと。

地理空間関数

地図を使用したエンリッチメント

Azure Machine Learning

AI の推論を使用したエンリッチメント

その他

  • 集計関数
  • 数学関数
  • 文字列関数

Edge での実行

補足: Azure Stream Analytics on IoT Edge として、
同じクエリを IoT Edge デバイス上で実行できる。
クラウドに送る前に現場で間引き・集計することで、
通信量とクラウド側の処理量を減らせる。
IoT で「全データを送ると回線も課金も持たない」という
典型的な問題への対処になる。

チュートリアル

契約

Azure の契約

Stream Analytics の契約

  • sku はストリーミング ユニット (SU) の capacity で決まる。
  • クラスタは専用クラスタで、36SU 毎の増分で購入できる。

ジョブの作成

インスタンス的なものは作成不要で、いきなりジョブ的なものを作成できる。

ポータル

  • Stream Analytics ジョブに移動して作成から以下を入力

    • ジョブ名を入力
    • サブスクリプションを選択
    • リソース・グループを選択
    • リージョンを選択
    • ホスティング環境を選択（[クラウド] or Edge）
    • ストリーミング ユニット (1 から 396)
    • このジョブに必要なすべての
      プライベート・データ資産を自分のストレージ・アカウントに保管して
      セキュリティで保護する ✔ → ストレージ・アカウントを指定

  • パラメタを設定したら [作成] ボタンを押下。

  • デプロイが完了したら [リソースに移動] ボタンを押下。

  • ジョブの入力、出力、クエリを設定する。

    • 入力は [Add input] を押下して設定
    • 出力は [Add output] を押下して設定
    • クエリは [Write query] を押下して設定

IaC

コチラ

補足（SU の考え方）: SU はメモリと CPU をまとめた単位で、
SU 使用率（メモリ使用率）が 80% を超えると危険水域とされる。
超えるとイベントの処理が遅延し、最終的にジョブが停止する。
Azure Monitor で
SU % Utilization と Watermark Delay を監視し、
Azure Alerts を設定しておくこと。

なお、現在の SU は V2 SU（1 V2 SU ≒ 従来の 6 SU）に
体系が変わっており、原文の「1 から 396」は旧体系の数値である。

クラスタの作成

複雑で要求の厳しいユース ケースでシングル テナント デプロイも可能。

ポータル

IaC

補足: 専用クラスタ（Stream Analytics クラスター）は
VNET 内のリソースに
Private Link 経由で接続できる点が最大の利点。
閉域構成が要件になる場合、通常のジョブでは対応できないため
クラスタが必要になる。ただし 36 SU からの購入となり高額。

参考

ナレコム Azure レシピ

について

触ってみた

microsoft.com

Microsoft Azure

Microsoft Learn

クイック スタート

チュートリアル

Tags: 移行, インフラストラクチャ, クラウド, ビッグデータ, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally