Cloud Service
Azure Synapse Analytics
分析用データウェアハウスと Apache Spark を1つのワークスペースに統合した統合分析プラットフォーム。AWS の Redshift と EMR の組み合わせに相当する。
- 1.DWH(専用 SQL プール)と Spark、サーバーレス SQL を1つのワークスペースに統合する。
- 2.Data Lake 上のファイルを移動せずにそのまま SQL や Spark で分析できる。
- 3.AWS では Redshift と EMR、Athena を組み合わせた領域に相当する。
解決する課題
データウェアハウス(構造化データの集計・BI)とビッグデータ処理(Spark によるデータ加工・機械学習)は、従来は別々の製品・別々のチームで運用されがちでした。Synapse Analytics は、これらを単一のワークスペースに束ね、同じデータレイク上のデータに対して複数のエンジンからアクセスできるようにします。
- 大規模な集計・分析を 列指向の MPP(超並列処理)DWH で高速に実行したい
- データレイク上のファイルを 移動・取り込みせずに SQL や Spark で直接クエリしたい
- DWH 用途と Spark によるデータ加工 / 機械学習 を同じ基盤で扱いたい
- 取り込み・変換・分析・可視化までの パイプラインを1か所 で管理したい
主要概念と用語
- ワークスペース(Synapse ワークスペース): 各種分析エンジンとパイプラインを束ねる単位。Synapse Studio から統合的に操作する
- 専用 SQL プール(Dedicated SQL Pool): 旧 Azure SQL Data Warehouse 相当の MPP 型 DWH。
DWU(Data Warehouse Unit)でスケールするプロビジョンド型のエンジン - サーバーレス SQL プール(Serverless SQL Pool): 事前にプロビジョニング不要で、データレイク上のファイルにそのまま T-SQL を発行できるエンジン。処理したデータ量に応じた従量課金
- Apache Spark プール: マネージドな Spark クラスター。データ加工(ETL)や機械学習、ノートブックでの探索に使う
- DWU(Data Warehouse Unit): 専用 SQL プールの計算リソースの単位。大きくするほど並列度とスループットが上がる
- 分散(Distribution): 専用 SQL プールがテーブルをノード間に分割する方式。ハッシュ分散・ラウンドロビン・レプリケートの3種類がある
- Synapse Studio: SQL・Spark・パイプライン・監視を1つの Web UI で扱う開発環境
- Synapse Link: Cosmos DB などの運用データベースと分析を、ETL なしでほぼリアルタイムに接続する機能
仕様・制限・クォータ
- エンジンは複数あり、用途で使い分ける: 集計・BI 向けの専用 SQL プール、アドホックなファイル探索向けのサーバーレス SQL プール、加工・ML 向けの Spark プール
- 専用 SQL プールは DWU でスケールするプロビジョンド型で、一時停止 / 再開 ができる。停止中はコンピューティング課金が止まる(ストレージは別途)
- サーバーレス SQL プールはスキャンしたデータ量に対する従量課金で、常時稼働するクラスターを持たない
- 分散テーブルの設計が性能を大きく左右する。大きなファクトテーブルはハッシュ分散、小さなディメンションはレプリケートが定石
- 専用 SQL プールには 同時実行スロットや、PolyBase /
COPYによる一括読み込みなどの上限・推奨がある - データ量・規模に関わる具体的な上限値は SKU やリージョンで異なるため、最新の公式ドキュメントで確認する
内部の仕組み
専用 SQL プールは MPP(Massively Parallel Processing) アーキテクチャを採用しています。1つの制御ノードがクエリを受け取り、複数のコンピューティングノードへ分割して並列実行し、結果を集約します。テーブルのデータは 分散の方式に従ってノード間に物理的に分割され、結合や集計がノード間でどれだけデータを移動(データ移動操作)するかが性能を決めます。
- ハッシュ分散: 指定列のハッシュ値でデータを各ノードに割り当てる。結合キーや集計キーをそろえると、ノードをまたぐデータ移動を抑えられる
- ラウンドロビン分散: 偏りなく均等に配るが、結合では再分散が発生しやすい。ステージング用などに向く
- レプリケート: 全ノードに同じコピーを置く。小さなディメンションテーブルに有効
- サーバーレス SQL プールは、データレイク上の Parquet / CSV / JSON を直接読み、クラスターを常駐させずにクエリ単位でリソースを割り当てる(AWS の Athena に近い考え方)
- Spark プールは、ノートブックやジョブから起動するマネージド Spark で、加工結果を再びレイクや専用 SQL プールへ書き戻せる
これらのエンジンが 同一のデータレイク(Data Lake Storage Gen2) を共有するため、データを各エンジン用にコピーして回す必要が減るのが Synapse の核心です。
定型の集計・BI で安定した高性能が欲しいなら専用 SQL プール、レイク上のファイルを手早く調べたいならサーバーレス SQL プール、複雑な変換や機械学習なら Spark プール、と要件で選びます。1つに固定せず、適材適所で組み合わせるのが Synapse らしい設計です。
設計パターン / ベストプラクティス
- 取り込み層と分析層を分ける: 生データはレイクに置き、サーバーレス SQL や Spark で加工してから専用 SQL プールへロードする(メダリオン構成)
- 専用 SQL プールへの一括ロードは
COPY文 / PolyBase を使い、行単位のINSERTを避ける - 分散キーを結合・集計のキーにそろえることでデータ移動を最小化する
- 統計情報を最新化し、列指向(クラスター化列ストア)の利点を引き出す
- 使わない時間帯は専用 SQL プールを一時停止してコンピューティング課金を止める
- アドホックな探索は常駐コストのない サーバーレス SQL プールに寄せる
運用・監視
- Azure Monitor と Synapse Studio の監視ハブで、SQL リクエスト・Spark アプリケーション・パイプライン実行を確認する
- 専用 SQL プールでは DWU 使用率・同時実行・データ移動量を見て、ボトルネックを切り分ける
- 診断設定でログ・メトリクスを Log Analytics へ送り、長期分析やアラートに使う
- 専用 SQL プールの 一時停止 / 再開 を運用スケジュールに組み込み、無駄な稼働を避ける
- パイプライン障害はトリガー実行履歴とアクティビティ単位の出力で原因を追う
コスト
エンジンごとに課金モデルが異なる点を押さえるのがコスト最適化の出発点です。専用 SQL プールはプロビジョンド(停止可能)、サーバーレス SQL プールはスキャン量の従量、Spark プールは稼働したノード時間で考えます。
| エンジン | 課金の考え方 | 向いている用途 |
|---|---|---|
| 専用 SQL プール | DWU 単位のプロビジョンド(停止で停止) | 定型の集計・BI・大規模 DWH |
| サーバーレス SQL プール | スキャンしたデータ量の従量 | レイク上ファイルのアドホック探索 |
| Spark プール | 稼働したノード時間(自動停止可) | ETL・データ加工・機械学習 |
専用 SQL プールは使っていなくても稼働中はコンピューティング課金が続きます。検証環境や夜間は一時停止を徹底し、アドホックな探索はサーバーレス SQL プールに寄せると無駄を抑えられます。サーバーレス側もスキャン量課金のため、Parquet 化や列の絞り込みでスキャン量を減らすことが効きます。
セキュリティ
- Microsoft Entra ID 認証 + RBAC を基本とし、SQL 認証への過度な依存を避ける
- データレイクへのアクセスは マネージド ID を使い、資格情報のハードコードを避ける
- 保存データはサービス側で暗号化され、カスタマーマネージドキー(Key Vault) にも対応する
- マネージド仮想ネットワーク / プライベートエンドポイントでワークスペースの通信を閉域化できる
- 専用 SQL プールでは 列レベル / 行レベルのセキュリティや動的データマスクで、ユーザーごとに見える範囲を制御する
Well-Architected の観点
- パフォーマンス効率: 分散方式・統計情報・列ストアの設計が専用 SQL プールの性能を決める。エンジンを用途で使い分け、不要なデータ移動とスキャンを減らす
- コスト最適化: 専用 SQL プールの一時停止、サーバーレス SQL プールへのアドホック移譲、データの Parquet 化によるスキャン量削減を組み合わせる
- 取り込み・変換・配信をパイプラインで一元管理し、運用の複雑さを抑える点も含めて、性能とコストのバランスを継続的に見直す
試験で問われるポイント
- 専用 SQL プール = MPP 型の DWH(旧 SQL Data Warehouse)で、DWU でスケールし一時停止できるプロビジョンド型である点
- サーバーレス SQL プール = レイク上のファイルをそのまま T-SQL で読む、スキャン量課金のエンジンである点(AWS の Athena に近い)
- 分散方式(ハッシュ / ラウンドロビン / レプリケート) の使い分けと、ハッシュ分散がデータ移動を抑える理由
- Spark プールはデータ加工・機械学習、SQL プールは集計・BI、と役割が分かれること
- 大量ロードは
COPY/ PolyBase を使い、行単位 INSERT を避けるという定石 - 同一のデータレイクを複数エンジンで共有し、データのコピーを減らすのが統合の狙いである点
- AWS の相当領域は Redshift(DWH)+ EMR(Spark)+ Athena(サーバーレスクエリ) の組み合わせ
関連サービス・比較
Synapse は単一サービスというより、AWS では複数サービスにまたがる領域を1つのワークスペースに統合したものです。AWS の代表的な相当サービスと対応づけると理解しやすくなります。
| 観点 | Azure Synapse Analytics | AWS の相当サービス |
|---|---|---|
| MPP 型 DWH | 専用 SQL プール | Amazon Redshift |
| Spark 処理 | Apache Spark プール | Amazon EMR / Glue |
| レイク上の直接クエリ | サーバーレス SQL プール | Amazon Athena |
| 共有ストレージ | Data Lake Storage Gen2 | Amazon S3 |
| パイプライン / ETL | Synapse パイプライン | AWS Glue / Step Functions |
| 権限付与 | Entra ID + RBAC | IAM |
新規のレイクハウス志向の構築では、Microsoft は Synapse の発展形として Microsoft Fabric を案内しています。既存の Synapse 資産は引き続き有効ですが、新規採用の際は要件に応じて両者を比較検討するとよいでしょう。
ハンズオン / CLI例
# リソースグループを作成
az group create --name demo-rg --location japaneast
# Synapse が使う Data Lake Storage Gen2 用のストレージアカウントを作成
az storage account create \
--resource-group demo-rg \
--name demosynapselake0614 \
--location japaneast \
--sku Standard_LRS \
--enable-hierarchical-namespace true
# Synapse ワークスペースを作成(既定のデータレイクを紐づけ)
az synapse workspace create \
--resource-group demo-rg \
--name demo-synapse-0614 \
--storage-account demosynapselake0614 \
--file-system synapsefs \
--location japaneast \
--sql-admin-login-user sqladminuser \
--sql-admin-login-password "<強力なパスワード>"
# 専用 SQL プール(DWH)を作成(パフォーマンスレベルを指定)
az synapse sql pool create \
--resource-group demo-rg \
--workspace-name demo-synapse-0614 \
--name demoSqlPool \
--performance-level DW100c
# 不要な時間帯は専用 SQL プールを一時停止してコンピューティング課金を止める
az synapse sql pool pause \
--resource-group demo-rg \
--workspace-name demo-synapse-0614 \
--name demoSqlPool
Azure Service
Azure Synapse Analyticsを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
分析
比較で見る軸
クラウド: Azure / カテゴリ: 分析 / 難易度: intermediate
導入後に効く点
Data Lake 上のファイルを移動せずにそのまま SQL や Spark で分析できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- 分析
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- performance / cost
判断チェックリスト
- 自社の用途が「分析 / performance」に近いか確認する。
- 強みである「DWH(専用 SQL プール)と Spark、サーバーレス SQL を1つのワークスペースに統合する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。