Contents
Azure Synapse Analytics の全体アーキテクチャと Lake データベース概念
Azure Synapse はデータウェアハウス、ビッグデータ処理、リアルタイム分析を単一プラットフォームで提供します。本節では主要コンポーネントの概要と、ストレージ上の Parquet などを直接参照できる Lake データベース がどのようにデータレイクハウスとして機能するかを解説します。
コンポーネント概要
Synapse の主要サービスは以下の通りです。
| コンポーネント | 主な役割 | 代表的な利用シーン |
|---|---|---|
| SQL pool (Serverless / Dedicated) | T‑SQL によるクエリ実行 | ad‑hoc 分析、ETL 不要の高速レポート |
| Spark pool | 分散処理基盤（Scala / PySpark） | 機械学習パイプライン、バッチ変換 |
| Data Explorer | 時系列データ検索エンジン | ログ・IoT データのリアルタイム分析 |
Lake データベースの役割
Lake データベースは Azure Data Lake Storage (ADLS) 上に保存されたファイルを「仮想テーブル」として扱い、SQL と Spark の両方から同一スキーマで参照できます。Microsoft Learn では「エンティティ・属性・リレーションシップ」をモデル化できるデザイナーが提供されていると説明されています（公式ドキュメント）。これにより、従来はスキーマレスだったレイクでもリレーショナルな分析が可能になります。
環境構築：前提条件・ロール・リソース作成手順
本節では Lake データベースを利用するための権限設定と、Azure Portal もしくは ARM テンプレートでのリソース作成フローを具体的に示します。
必要な Azure ロールと権限設定
Lake データベースの作成・管理には Synapse 管理者 または Synapse 共同作成者 のロールが必要です。以下にロール付与手順と推奨シナリオを示します。
|
1 2 3 4 5 6 |
# Azure CLI による Synapse 共同作成者ロールの付与例 az role assignment create \ --assignee <userPrincipalName> \ --role "Synapse Collaborative Contributor" \ --scope /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.Synapse/workspaces/<workspaceName> |
- Synapse 管理者：全機能へのフルアクセス。大規模導入時の初期設定に適しています。
- Synapse 共同作成者：データベース・パイプラインの作成・編集が可能で、運用担当者向けの最小権限です。
ポイント：ロール付与は Azure AD のグループ単位で行うと、メンバー追加時に自動的に権限が継承され管理コストを削減できます。
リソースグループ・ストレージアカウント・Synapse ワークスペースの作成
リソースは「リソースグループ → ストレージアカウント → Synapse ワークスペース」の順に構築します。以下は ARM テンプレートと Portal 手順です。
ARM テンプレート例（抜粋）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "workspaceName": { "type": "string" }, "storageAccountName": { "type": "string" } }, "resources": [ { "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2022-09-01", "name": "[parameters('storageAccountName')]", "location": "[resourceGroup().location]", "sku": { "name": "Standard_LRS" }, "kind": "StorageV2" }, { "type": "Microsoft.Synapse/workspaces", "apiVersion": "2021-06-01", "name": "[parameters('workspaceName')]", "location": "[resourceGroup().location]", "properties": { "defaultDataLakeStorage": { "accountUrl": "[concat('https://', parameters('storageAccountName'), '.dfs.core.windows.net/')]", "filesystem": "synapse" } }, "dependsOn": [ "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]" ] } ] } |
Portal 手順（概要）
- リソースの作成 → データ + AI → Synapse Analytics を選択。
- ワークスペース名・リージョンを入力し、既存または新規のストレージアカウントを紐付ける。
- 必要に応じて Azure AD のロール割当やネットワーク設定を行い、作成完了。
ポイント：リソースグループ単位でタグ付与（例：
Env=Dev）しておくと、コスト分析やポリシー適用が容易になります。
Lake データベース設計とテンプレート適用
この章では Synapse Studio の Database Designer を利用したスキーマ作成手順と、公式提供のテンプレートをインポートしてすぐに活用できる流れを示します。
Database Designer でのデータベース作成
Designer は GUI だけでエンティティ・属性・リレーションシップを定義できます。以下は基本的な操作フローです。
- Synapse Studio にサインインし左メニューの 「データ」→「Database Designer」 を選択。
- 「新しい Lake データベース」をクリックし、名前と ADLS のファイルシステムパスを入力して作成。
- エンティティ追加：
+ エンティティ→ 名前・主キー属性（例:SalesOrderId） を設定。 - 属性定義：列名・データ型（String, Int64, DateTime 等）を追加。
- リレーションシップ：外部キーをドラッグしてエンティティ間の関係を作成。
作成したモデルは自動的に Parquet ファイルと紐付くため、保存後すぐに SQL on‑demand でクエリが実行可能です。
公式テンプレートのインポート方法
Microsoft が提供する Lake データベース テンプレート（例：Sales Sample）を利用すると、代表的なテーブル構造とサンプルデータが即座に手元に届きます。
- Designer の画面左上の 「テンプレートギャラリー」 を開く。
- 「Lake データベース テンプレート」一覧から 「Sales (sample)」 を選択し 「インポート」 ボタンをクリック。
- インポート完了後、エンティティ・属性を自社要件に合わせてカスタマイズ（列の追加・削除）すれば準備完了です。
※テンプレート利用には Synapse ユーザー ロール が必要です（詳細は quick‑start を参照）。
スキーマモデリングのベストプラクティス
実務で安定運用できるスキーマは 命名規則・正規化とデノーマライズのバランス が鍵です。以下に推奨項目をまとめました。
| 項目 | 推奨内容 |
|---|---|
| エンティティ名 | PascalCase（例：SalesOrder） |
| 属性名 | camelCase、単位はサフィックスで表す（例：orderDateUtc） |
| 主キー | <EntityName>Id または単純に Id （例：salesOrderId） |
| 外部キー | <ReferenceEntity>NameId（例：customerId） |
| 正規化レベル | 第 3 正規形まで実装し、分析頻度が高いディメンションはデノーマライズ |
| パーティショニング | 日付系属性で 年/月 フォルダー構造を推奨（例：/sales/2025/03/） |
ポイント：一貫した命名と適切なパーティション設計は、クエリプランの最適化やメンテナンス効率に直結します。
データインジェストとガバナンス設定
本節では Azure Data Factory / Synapse Pipelines によるデータ取り込み手順と、アクセス制御・監査を組み合わせたガバナンス実装方法を解説します。Qiita 記事は参考情報として掲載していますが、公式ドキュメントで最新のベストプラクティスをご確認ください。
Data Factory / Synapse Pipelines による取り込みフロー
Pipeline と Data Flow を組み合わせれば、CSV や Parquet など多様なフォーマットを 自動スキーマ検出＋変換しながら Lake データベースへロードできます。主なステップは次の通りです。
- Linked Service：Blob/ADLS と Synapse ワークスペースを接続。
- Copy Activity：
source: blob/*.csv→sink: lakeDatabase.SalesOrder（Parquet に変換）。 - Data Flow：日付文字列を
DateTime型へ変換し、欠損値はデフォルトで埋める。 - パラメータ化：実行時にフォルダー名（年月）を渡すだけで自動的に該当パーティションへロード。
|
1 2 3 4 5 6 7 |
{ "name": "CopyCsvToLake", "type": "Copy", "inputs": [{ "referenceName": "BlobCsv", "type": "DatasetReference" }], "outputs": [{ "referenceName": "LakeSalesOrder", "type": "DatasetReference" }] } |
ポイント：テンプレート化したパイプラインは、スケジュールやトリガー変更だけで新規データソースに対応できます。
アクセス制御と行レベルセキュリティ（RLS）
Lake データベースでも Azure RBAC と Row‑Level Security を併用し、部門ごとの閲覧権限を細かく管理します。以下は正確な構文例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
-- 1. 部門情報テーブル（スキーマ dbo に配置） CREATE TABLE dbo.UserDepartment ( UserPrincipalName NVARCHAR(128) NOT NULL, Department NVARCHAR(64) NOT NULL, PRIMARY KEY (UserPrincipalName) ); GO -- 2. RLS 用フィルタ関数（SCHEMABINDING 必須） CREATE FUNCTION dbo.fn_SalesRls(@Dept NVARCHAR(64)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS fn_result WHERE @Dept = (SELECT Department FROM dbo.UserDepartment WHERE UserPrincipalName = USER_NAME()); GO -- 3. セキュリティポリシーの作成（対象テーブルは SalesOrder） CREATE SECURITY POLICY dbo.SalesRlsPolicy ADD FILTER PREDICATE dbo.fn_SalesRls(Department) ON dbo.SalesOrder WITH (STATE = ON); GO |
- ポイント
USER_NAME()は現在クエリ実行ユーザーの Azure AD UPN を取得します。- フィルタ関数は
SCHEMABINDINGが必須で、テーブル構造が変わると再作成が必要です。
監査ログと Azure Policy によるガバナンス自動化
監査とポリシーの組み合わせでコンプライアンス要件を継続的に満たす仕組みを構築します。
| ポリシー名 | 定義内容 | 推奨状態 |
|---|---|---|
synapse-workspace-diagnostic-enabled |
Synapse ワークスペースで診断設定が必須 | 適用済み |
storage-encryption-at-rest |
ストレージは SSE が有効か確認 | 適用済み |
lake-database-encrypted |
Lake データベースの保存先ストレージが暗号化されていることを保証 | 未適用（手動設定要） |
- 診断設定：Synapse ワークスペース → 「診断設定」から
SQLSecurityAuditEventsやSparkLogsを Log Analytics に送信。 - アラート例：ポリシー違反が検出されたら Azure Monitor のメール通知をトリガーし、必要に応じて自動修復スクリプト（Azure Automation Runbook）を実行。
ポイント：ポリシーは「評価頻度」をデイリーかウィークリーに設定すると、コスト増加なく継続的な監視が可能です。
パフォーマンス最適化・検証・運用、PoC コスト感覚と本番移行の留意点
この章ではクエリ高速化手法、デバッグ方法、運用モニタリング、そして PoC 段階での費用感覚と本番環境へのスケール戦略をまとめます。
パーティショニング・キャッシュ・マテリアライズドビュー
Lake データベースでは パーティションプルーニング と 結果キャッシュ、さらに Materialized View が有効です。代表的な構文例は以下の通りです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
-- 1. パーティショニング（年・月で分割） CREATE TABLE dbo.SalesPartitioned WITH ( LOCATION = 'abfss://synapse@mydatalake.dfs.core.windows.net/sales/', PARTITION (Year int, Month int) ) AS SELECT * FROM dbo.RawSales; GO -- 2. キャッシュヒント使用例（同一クエリの再実行を高速化） SELECT /*+ CACHE */ Year, SUM(Amount) AS Total FROM dbo.SalesPartitioned WHERE Year = 2025 AND Month BETWEEN 1 AND 3 GROUP BY Year; GO -- 3. マテリアライズドビューで集計結果を事前算出 CREATE MATERIALIZED VIEW dbo.MonthlySalesSummary WITH (CLUSTERED COLUMNSTORE INDEX) AS SELECT Year, Month, SUM(Amount) AS MonthlyTotal FROM dbo.SalesPartitioned GROUP BY Year, Month; GO |
ポイント：パーティションキーはクエリで頻繁にフィルタリングされる列（例：
Year/Month）を選ぶと、スキャン量が数十％削減できます。
デバッグと実行計画の確認方法
開発フェーズでは Synapse Studio のデバッグモード と SET SHOWPLAN_ALL ON を併用し、ボトルネックを可視化します。
- Database Designer 上でクエリを右クリック → 「デバッグ」。
- パラメータ（例：日付範囲）を設定して実行。
- 出力タブの Execution details に表示される Data Skew, Estimated Rows, I/O Cost を確認し、不要なスキャンや非効率的なジョイン順序があればパーティションやビューで調整。
ポイント：デバッグは 小規模サンプルデータ でも実行できるため、本番環境に影響を与えることなく最適化が可能です。
Azure Monitor と Log Analytics による運用監視
本番では Azure Monitor のメトリクスと Log Analytics ワークスペースに集約したログで総合的な可視化を行います。
|
1 2 3 4 5 6 7 8 |
// 例：Synapse Pipelines の失敗回数を日別に集計 AzureDiagnostics | where ResourceProvider == "MICROSOFT.SYNAPSE" and Category == "PipelineRun" and Status_s == "Failed" | summarize FailCount = count() by bin(TimeGenerated, 1d), PipelineName_s | order by TimeGenerated desc |
- アラート：
FailCount > 5（過去 24 時間）でメール通知。 - ダッシュボード：CPU、DTU、スキャン量、パイプライン成功率を表示する Workbooks を作成し、ステークホルダー向けに共有。
ポイント：Log Analytics のクエリは保存して再利用できるため、定期的なレポート作成が自動化できます。
PoC のコスト概算と本番スケール戦略（最新料金リンク付き）
PoC では主に Serverless SQL、Spark pool、ストレージ、Data Factory が課金対象です。以下は 2026 年 7 月時点の参考価格（USD 表示、為替レート 1 USD = 150 JPY 前提）です。実際の請求額は使用量とリージョンにより変動しますので、必ず公式料金ページをご確認ください。
| 項目 | 単価（2026/7 時点）※ | 想定利用量 (PoC) | 月間概算費用 |
|---|---|---|---|
| Serverless SQL (クエリ実行) | $5 / 1,000 クエリ（1 TB スキャン） | 2,000 クエリ、10 TB スキャン | 約 $100 （≈15,000 JPY） |
| Spark pool (Small) | $0.90 / vCore‑hour | 50 vCore‑hour | 約 $45 （≈6,800 JPY） |
| Storage (Hot) | $0.0184 / GB‑month | 5 TB | 約 $92 （≈13,800 JPY） |
| Data Factory アクティビティ実行 | $1 / 1,000 実行 | 10,000 実行 | 約 $10 （≈1,500 JPY） |
※価格は公式ページ（Azure Synapse の料金）を参照し、2026 年 7 月時点の情報です。実際のプロジェクトでは 予約インスタンス や 長期プラン を活用すると最大 55% の割引が得られます。
本番移行時のスケール戦略
| 項目 | 推奨アクション |
|---|---|
| SQL 実行基盤 | ピーク時は Dedicated SQL pool (DWU) に切り替え、並列度を上げる。 |
| ストレージ層 | アクセス頻度が低いテーブルは Cool/Archive 層へ移行し、スキャン単価を削減。 |
| 予約インスタンス | 1 年または 3 年の予約で vCore‑hour 単価を最大 55% 割引。 |
| 自動スケーリング | Spark pool のオートスケール設定で、負荷に応じたリソース調整を実現。 |
ポイント：PoC 段階で取得した使用パターン（CPU・メモリ・I/O）を基に、予算シミュレーションと予約購入のタイミングを計画すると、本番運用時のコストサプライズを防げます。
次のアクション：無料 Azure アカウントで PoC 環境を作成
この最終セクションでは、Azure の無料アカウント（$200 クレジット）でも本ガイドの全手順が実行可能な流れをご紹介します。
- Azure ポータルにサインアップし、無料クレジットを取得。
- 「環境構築」セクションの手順で リソースグループ → ストレージアカウント → Synapse ワークスペース を作成。
- Synapse Studio の Database Designer から公式 Lake データベース テンプレート（Sales Sample）をインポートし、必要なエンティティを自社要件に合わせて調整。
- Qiita 記事で紹介された ADF / Synapse Pipelines のサンプルをコピーし、テストデータの取り込みと RLS + 監査ログ を有効化。
これらの作業が完了すれば、自社環境で Azure Synapse の Lake データベース設計・構築・運用 が体験でき、実務プロジェクトへの適用準備が整います。ぜひ無料クレジットを活用して、データレイクハウスの第一歩を踏み出してください。
本稿は執筆時点で確認された情報に基づき作成しています。サービス仕様や料金は変更される可能性がありますので、導入前には必ず最新の公式ドキュメントをご参照ください。