3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@fpt_quyetnn(Quyet Nguyen)inＦＰＴジャパンホールディングス株式会社

Azureで統合データプラットフォームを設計する：Databricks + ADF + Synapse + Delta UniForm + Unity Catalog

3
Last updated at Posted at 2026-03-25

Azure統合データプラットフォーム設計：Databricks + ADF + Synapse + Delta UniForm + Unity Catalog

投稿日：2026年03月25日

はじめに

Azure上でエンタープライズ向けのデータ基盤を設計する場合、単一のサービスだけですべての要件を満たすのは現実的ではありません。データ取り込み、変換、分析、ガバナンスをそれぞれ適切なサービスに分担させ、そのうえで全体として一貫したプラットフォームとして成立させることが重要です。

本記事は、Azure上でLakehouse / 分析基盤を設計・実装するData Engineer / Data Architect / Analytics Platform Engineer を主な対象読者としています。特に、Databricksを中核に据えながら、ADFによるオーケストレーション、SynapseによるSQL提供、Unity Catalogによる統合ガバナンスをどう組み合わせるべきかを整理したい方を想定しています。

ここで紹介する構成は、単なるBI基盤にとどまりません。将来的なAI/ML活用も見据え、Databricks上のMLflow、Vector Search、Azure OpenAIとの連携まで視野に入れた、AI-Readyなデータプラットフォームとして設計しています。

本記事では、以下の構成要素を組み合わせた統合アーキテクチャを、実践的なコードとあわせて解説します。

  • Azure Data Factory (ADF) — オーケストレーションとデータ取り込み
  • Azure Databricks — Sparkベースの変換処理基盤
  • Azure Synapse Analytics — SQLアナリティクスとサービングレイヤー
  • Delta UniForm (Iceberg互換) — Deltaを基盤にしながらIcebergクライアント互換を提供するオープンテーブル戦略
  • Unity Catalog — ガバナンス、リネージ、アクセス制御、およびIceberg REST Catalog API

Tech Stack:

  • Python 3.11+ / PySpark
  • Azure Databricks Runtime 14.3 LTS+
  • Azure Data Factory
  • Azure Synapse Analytics (Serverless + Dedicated Pool)
  • Delta Lake / Apache Iceberg ecosystem
  • ADLS Gen2
  • Unity Catalog

アーキテクチャ全体像

┌─────────────────────────────────────────────────────────────────┐
│                    Azure Data Platform                          │
│                                                                 │
│  ┌──────────────┐    ┌─────────────────────────────────────┐   │
│  │     ADF      │    │        ADLS Gen2 Storage            │   │
│  │              │    │  ┌──────────┬──────────┬─────────┐  │   │
│  │  - Copy      │───▶│  │  Bronze  │  Silver  │  Gold   │  │   │
│  │  - Trigger   │    │  │ (Raw)    │(Cleansed)│(Serving)│  │   │
│  │  - Monitor   │    │  └──────────┴──────────┴─────────┘  │   │
│  └──────────────┘    │    Delta Format (UniForm Iceberg)   │   │
│         │            └─────────────────────────────────────┘   │
│         ▼                         │                             │
│  ┌──────────────────┐             │                             │
│  │ Azure Databricks │◀────────────┘                            │
│  │                  │                                           │
│  │ - Auto Loader    │    ┌───────────────────────────────┐      │
│  │ - Spark ETL      │    │        Unity Catalog          │      │
│  │ - UniForm Write  │───▶│ - Governance & Lineage        │      │
│  │ - DLT Pipelines  │    │ - Iceberg REST Endpoint       │      │
│  └──────────────────┘    └──────────────┬────────────────┘      │
│                                         │ REST API Connection   │
│                                         ▼                       │
│                    ┌─────────────────────────────┐              │
│                    │   Azure Synapse Analytics   │              │
│                    │ - Serverless SQL (Delta)    │              │
│                    │ - Spark Pool (Iceberg)      │              │
│                    └─────────────────────────────┘              │
└─────────────────────────────────────────────────────────────────┘

この構成の基本方針は明確です。データの主処理はDatabricks、ワークフロー制御はADF、SQL公開はSynapse、統制はUnity Catalog に寄せます。役割を分けることで、機能追加や運用変更が入っても構成が崩れにくくなります。

Part 1: ADF — データ取り込みオーケストレーション

1.1 ADFパイプライン設計

ADFの役割は、変換処理を自ら実行することではなく、データパイプライン全体をオーケストレーションすることにあります。どのソースを、どの順番で、どのタイミングで取り込み、どのジョブへ引き渡すかを管理するのがADFの責務です。

エンタープライズ環境では、ソースシステムごとに実行ウィンドウ、依存関係、リトライ条件、通知要件が異なります。ADFを使うことで、こうした運用上の制御をGUIベースで可視化しながら管理でき、Databricks側には変換ロジックそのものを集中させることができます。

1.2 Auto Loader — ストリーミング取り込み

DatabricksのAuto Loaderは、ADLS Gen2上の新着ファイルを自動検知し、増分で取り込むための仕組みです。チェックポイントによってExactly-Once処理を担保でき、スキーマ進化にも追従しやすいため、Bronze層の取り込み基盤として非常に相性が良いです。

Bronze層では、まず「欠損なく安全に取り込む」ことが最優先です。業務ルールを含む厳密な整形や品質担保はSilver層以降に寄せることで、再処理や監査のしやすい構成になります。

# Databricks Notebook: bronze_auto_loader.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import current_timestamp, input_file_name

spark = SparkSession.builder.appName("BronzeAutoLoader").getOrCreate()

BRONZE_PATH = "abfss://datalake@<storage_account>.dfs.core.windows.net/bronze/sales"
CHECKPOINT_PATH = "abfss://datalake@<storage_account>.dfs.core.windows.net/_checkpoints/bronze/sales"

def ingest_to_bronze(source_path: str, target_table: str):
    df = (
        spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "parquet")
        .option("cloudFiles.schemaLocation", f"{CHECKPOINT_PATH}/schema")
        .option("cloudFiles.inferColumnTypes", "true")
        .option("cloudFiles.schemaEvolutionMode", "addNewColumns")
        .load(source_path)
        .withColumn("_ingested_at", current_timestamp())
        .withColumn("_source_file", input_file_name())
    )

    query = (
        df.writeStream
        .format("delta")
        .outputMode("append")
        .option("checkpointLocation", CHECKPOINT_PATH)
        .option("mergeSchema", "true")
        .trigger(availableNow=True)
        .table(target_table)
    )
    query.awaitTermination()

ingest_to_bronze(BRONZE_PATH, "enterprise_catalog.bronze.sales_raw")

Part 2: Delta UniForm (Iceberg互換) によるオープンテーブル戦略

2.1 なぜUniFormなのか？

Databricksを中心に据えるのであれば、書き込み性能、MERGEの成熟度、運用容易性、Unity Catalogとの親和性を考えて、基本フォーマットはDeltaに寄せるのが自然です。一方で、将来的な外部エンジン連携やベンダー依存の低減を考えると、Icebergエコシステムとの接続性も確保しておきたい場面があります。

そのバランスを取るのがDelta UniFormです。UniFormを有効化したテーブルでは、Databricks側はDeltaとして運用しつつ、外部のIceberg対応クライアントに対してIceberg互換のメタデータを提供できます。つまり、Databricksの強みを活かしながら、将来の選択肢を狭めにくい設計が可能になります。

2.2 UniForm対応テーブルの作成

UniForm対応テーブルは、USING DELTAで作成したうえで、Iceberg compatibility関連の設定をTBLPROPERTIESで付与します。運用の中核はあくまでDeltaですが、公開インターフェースとしてIceberg互換を持たせることで、マルチエンジン利用に備えられます。

# Delta UniForm（Iceberg互換）テーブルの作成
spark.sql("""
    CREATE TABLE IF NOT EXISTS enterprise_catalog.silver.sales_transactions (
        transaction_id  STRING,
        customer_id     STRING,
        product_code    STRING,
        amount          DOUBLE,
        currency        STRING,
        transaction_at  TIMESTAMP,
        region          STRING,
        _processed_at   TIMESTAMP
    )
    USING DELTA
    PARTITIONED BY (region)
    TBLPROPERTIES (
        'delta.enableIcebergCompatV2' = 'true',
        'delta.universalFormat.enabledFormats' = 'iceberg',
        'delta.columnMapping.mode' = 'name'
    )
""")

# MERGE INTOによるACIDアップサート
def upsert_to_silver(source_df, target_table: str):
    source_df.createOrReplaceTempView("source_data")
    spark.sql(f"""
        MERGE INTO {target_table} AS target
        USING source_data AS source
        ON target.transaction_id = source.transaction_id
        WHEN MATCHED AND source._processed_at > target._processed_at THEN UPDATE SET *
        WHEN NOT MATCHED THEN INSERT *
    """)

ここで重要なのは、「完全にベンダー非依存になる」と言い切ることではなく、実運用をDatabricks中心に置きながら、外部公開や将来拡張において選択肢を残すことです。その意味で、UniFormは現実的な落としどころと言えます。

Part 3: Unity Catalog — ガバナンス統合

Unity Catalogは、単なるメタストアではありません。アクセス制御、データリネージ、タグ付け、監査といった、エンタープライズ運用に必要な統制機能を一箇所に集約するための制御面の中心です。

現場で問題になりやすいのは、「誰がどのデータを見られるか」だけではなく、「どのジョブがこのテーブルを生成したのか」「PIIを含む列がどこに流れているのか」を追跡できるかどうかです。Unity Catalogを中心に据えることで、個別の仕組みを継ぎ足すのではなく、ガバナンスをアーキテクチャの前提条件として組み込めます。

# Unity Catalogによる細粒度アクセス制御
spark.sql("GRANT SELECT ON TABLE enterprise_catalog.silver.sales_transactions TO `data-analysts@company.com`")
spark.sql("GRANT MODIFY ON TABLE enterprise_catalog.silver.sales_transactions TO `data-engineers@company.com`")

# 機密カラムへのPIIタグ付け
spark.sql("""
    ALTER TABLE enterprise_catalog.silver.sales_transactions
    ALTER COLUMN customer_id SET TAGS ('pii' = 'true', 'sensitivity' = 'high')
""")

さらに、Unity CatalogはIceberg REST Catalog APIを提供できるため、外部エンジンとの接続においても、ストレージへの直接フルアクセスを前提としない統制しやすい設計を実現できます。

Part 4: Azure Synapse — サービングレイヤー

DatabricksとSynapseを組み合わせる場合、両者を競合させるのではなく、責務を分けて共存させることが重要です。本構成では、Databricksを変換・品質管理・主要なデータ処理の実行基盤とし、SynapseはSQL公開や参照系ユースケースを担うサービングレイヤーとして位置付けます。

4.1 Synapse Serverless SQLからの読み込み (Delta)

Synapse Serverless SQL Poolは、ADLS上のDelta形式データを直接クエリできます。UniFormテーブルの物理実体はDeltaであるため、Serverless SQLからの参照と相性が良く、BIやアドホックSQL用途に適しています。

-- Synapse Serverless SQL：ADLS Gen2上のDeltaフォーマットを直接クエリ
CREATE EXTERNAL TABLE dbo.sales_silver
WITH (
    LOCATION = 'silver/sales_transactions/',
    DATA_SOURCE = ds_adls_datalake,
    FILE_FORMAT = DeltaLakeFormat
)
AS
SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'https://<storage_account>.dfs.core.windows.net/datalake/silver/sales_transactions/',
    FORMAT = 'DELTA'
) AS [sales_data]
WHERE region = 'APAC' AND transaction_at >= '2026-01-01';

4.2 Synapse Spark Poolからの読み込み (Iceberg REST API)

Synapse Spark PoolのようにIcebergを扱えるエンジンからは、Unity CatalogのIceberg REST Endpoint経由でテーブルへアクセスできます。これにより、外部エンジンでも標準的なIcebergインターフェースで接続しつつ、統制面はUnity Catalogに集約できます。

# Synapse Spark Pool — Unity Catalog (Iceberg REST Catalog) への接続設定
%%configure -f
{
    "conf": {
        "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
        "spark.sql.catalog.uc_iceberg": "org.apache.iceberg.spark.SparkCatalog",
        "spark.sql.catalog.uc_iceberg.type": "rest",
        "spark.sql.catalog.uc_iceberg.uri": "https://<databricks-workspace-url>/api/2.1/unity-catalog/iceberg-rest",
        "spark.sql.catalog.uc_iceberg.token": "<databricks-pat-or-oauth>",
        "spark.sql.catalog.uc_iceberg.warehouse": "enterprise_catalog"
    }
}

df = spark.read.table("uc_iceberg.silver.sales_transactions")
df.createOrReplaceTempView("sales")

result = spark.sql("""
    SELECT region, SUM(amount) AS total_amount
    FROM sales
    WHERE transaction_at >= '2026-01-01'
    GROUP BY region
""")
result.show()

ここでのポイントは、Synapseを“もうひとつのETL基盤”として肥大化させないことです。変換ロジックの中核をDatabricksに寄せ、Synapseは読むための面として整理した方が、全体の責務がぶれにくくなります。

Part 5: Trade-offs / Limitations

この構成は柔軟ですが、すべてのケースに対して最適解というわけではありません。設計時には、どのエンジンが主導権を持つのか、誰が運用するのか、将来どこまでプラットフォームを広げるのかを明確にしておく必要があります。

5.1 いつDelta UniFormを選ぶべきか

次のような条件では、Delta UniFormが特に有効です。

  • Databricksが主要なデータ処理基盤である
  • Deltaの書き込み性能やMERGE運用を活かしたい
  • Unity Catalog中心のガバナンスを維持したい
  • 外部エンジンにはIceberg互換で公開できれば十分である

5.2 いつネイティブIcebergを検討すべきか

一方で、次のようなケースではネイティブIcebergを直接採用する余地があります。

  • Databricks以外の複数エンジンが対等に書き込みを行う
  • 完全なオープン実装を最優先したい
  • 中長期的にDatabricks非依存の運用へ寄せる可能性が高い

5.3 いつSynapseをServing Layerに限定すべきか

SynapseはSQL公開や外部参照には適していますが、複雑なデータ変換、継続的な品質担保、CDC込みの大規模ETLまで担わせると、パイプラインの責務が分散しやすくなります。そのため、変換はDatabricks、公開はSynapseという役割分担の方が、長期運用では整理しやすい構成になることが多いです。

Part 6: Production Considerations

PoCでは動いていても、本番運用では別の論点が出てきます。重要なのは、機能そのものよりも、継続運用に耐えられるかどうかです。

6.1 Cost / FinOps

  • 重いETLや大規模集計はDatabricksに寄せる
  • SQL参照やアドホック分析はSynapse Serverlessで吸収する
  • Bronze / Silver / Goldごとに保持期間を見直し、不要な長期保存を避ける
  • ジョブ頻度やクラスターサイズは業務SLAに合わせて調整する

6.2 Monitoring / Observability

  • ADFの実行履歴、Databricksジョブ、品質チェック結果を統合的に監視する
  • Bronze件数、Silver変換成功率、Gold更新時刻などを運用KPIとして定義する
  • 監査ログや品質結果はDeltaテーブルに蓄積し、後から分析可能にする

6.3 Security Boundary

  • ストレージへの広い直接アクセスは避け、可能な限りUnity Catalog経由で統制する
  • PIIや機微データにはタグ付けと列レベル制御を適用する
  • 認証は可能であればManaged IdentityやOAuth中心で構成する
  • 開発者、分析者、運用者の権限境界を明確に分ける

6.4 CI/CD

  • Notebookだけで運用せず、ジョブ定義、SQL、IaCをGitで管理する
  • dev / stg / prodでCatalog、Storage path、Secret、接続先を分離する
  • コード変更とデータ定義変更を一緒にレビューできる状態を作る

6.5 Environment Separation

  • 開発環境では試行速度、本番環境では監査性と変更統制を優先する
  • 本番データを無制限に開発環境へ複製しない
  • 環境ごとにCatalog名、Service Principal、External Locationを分離する

Part 7: AIへの拡張 — AI-Readyなデータ基盤

このアーキテクチャの価値は、BIだけで終わらない点にあります。Gold層まで整備されたデータは、そのままAI/MLワークロードへ接続しやすく、後続の活用フェーズへ自然に展開できます。

たとえば、Unity Catalogのタグ情報を利用すれば、PIIを含むデータをAI学習やRAG用途から除外しやすくなります。また、Goldテーブルや派生テーブルをVector Searchや検索基盤の入力として利用することで、AI活用においても既存のガバナンスを崩さずに済みます。

重要なのは、AI向けデータだけを別管理にしないことです。既存のデータ基盤と同じ統制面の上でAIワークロードを展開できる設計にしておくことで、将来の運用負荷を大きく減らせます。

重要なポイント

  1. Delta UniFormは現実的なマルチエンジン戦略である
    DatabricksではDeltaとして最適化しつつ、外部にはIceberg互換で公開できるため、実運用と拡張性の両立がしやすくなります。

  2. ベンダーロックインを抑えた設計ができる
    実行基盤はDatabricks中心でも、公開インターフェースをIceberg互換で持つことで、将来の選択肢を残しやすくなります。

  3. Unity Catalogを中心に据えることで統制しやすくなる
    ガバナンス、アクセス制御、リネージ、外部共有を個別実装せずに一元管理できます。

  4. SynapseはServing Layerとして使うと整理しやすい
    SQL公開や参照系ユースケースに集中させることで、Databricksとの責務分離が明確になります。

  5. Production readinessを先に考えるべきである
    コスト、監視、CI/CD、セキュリティ境界、環境分離まで含めて設計しないと、PoC止まりになりやすいです。

  6. AI拡張を前提にしたLakehouse設計が有効である
    BI向けに整備したデータを、そのままAI/MLワークロードへ接続できる構成は、将来の拡張性が高いです。

まとめ

本記事で紹介した構成は、Databricksを変換の中核、ADFを制御、Synapseを公開面、Unity Catalogを統制面として整理することで、役割の明確なAzureデータプラットフォームを実現するアプローチです。

特に、Delta UniFormを採用することで、Databricks中心の運用効率を維持しながら、Iceberg互換を通じて外部エンジン連携や将来拡張の余地を持たせることができます。加えて、AI活用や本番運用までを最初から見据えておくことで、PoCに閉じず、継続利用できる実践的な基盤へつなげやすくなります。

参考リンク

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?