系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
今日任務：區分線上交易（OLTP）與巨量分析（OLAP），並以資料倉儲、資料湖、SQL 與 Apache Spark 的責任邊界，判斷 Azure Synapse Analytics 與 Azure Databricks 的適用情境。
Day 19 的 Cosmos DB 解決了 Titan 科技「玩家此刻要快速讀寫資料」的問題；但遊戲營運團隊今天問的是另一題：如何把數十 TB 的事件日誌、交易紀錄與行銷資料安全地彙整，讓分析師用 SQL 做報表、資料工程師批次轉換資料、資料科學家以 Spark 訓練模型？把這些跨月掃描與聚合查詢直接丟回線上交易資料庫，會與玩家即時請求競爭資源，成本、延遲與事故爆炸半徑都會一起升高。
今天的判斷鏈是 資料落地位置 → 工作負載型態 → 查詢／轉換引擎 → 身分與網路邊界。看到企業資料倉儲與整合式分析工作區，要想到 Synapse；看到團隊以 Apache Spark、Notebook 與協作式資料工程／機器學習為主，要想到 Databricks。兩者都能在資料湖上工作，並不是互斥的同義詞。
┌──────────────────────────────────────────────────┐
│ 業務系統：交易、遊戲事件、CRM、裝置遙測資料 │
└─────────────────────────┬────────────────────────┘
▼
┌──────────────────────────────────────────────────┐
│ Azure Data Lake Storage Gen2：原始與整理後資料 │
└───────────────┬──────────────────┬───────────────┘
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Synapse SQL │ │ Databricks │
│ 倉儲／查詢 │ │ Spark／Notebook│
└────────┬───────┘ └────────┬───────┘
└──────────┬─────────┘
▼
┌────────────────────┐
│ Power BI 與營運決策 │
└────────────────────┘
💡 架構師重點筆記：資料湖不是免責的「大硬碟」。若原始、清理與可供報表使用的資料混在同一路徑，或讓每個人用過度授權帳號任意掃描，錯誤資料與資料外洩都會擴大。先分層、定義資料擁有者與存取權，再選擇 SQL 或 Spark 引擎。
把 Titan 的資料平台想成港口：ADLS Gen2 是堆放原料貨櫃的港區，能以低成本保存原始資料；Synapse 像港口的報關、倉儲與查詢中心，讓分析師以 SQL 有秩序地盤點貨物、產出報表；Databricks 則像大型加工廠，讓工程團隊用 Spark 把混雜的原料切分、清洗、加工成可交付的產品。三者可以共同服務同一批資料，但「把貨堆進港口」不等於「已完成報關」，也不等於「已加工完成」。
這個比喻可避免三個常見誤會：資料湖不是資料倉儲；Notebook 不是祕密管理工具；Spark 叢集也不是讓所有使用者都直接碰原始個資的理由。資料平台的難題不是只有能不能跑，而是誰能讀、讀哪一層、成本由誰負責、以及失敗後能否重跑。
OLTP 與 OLAP 的衝突源自存取型態。交易系統偏好小筆、可預期、低延遲的讀寫；分析系統則會掃描很長時間範圍、跨資料來源做 join、group by 與聚合。若讓 Power BI、資料科學實驗與玩家交易共用同一份線上資料庫，月結查詢可能搶走 CPU／IO，甚至把熱門交易逾時誤判成應用程式故障。
更合理的抽象是運算與儲存分離：將原始資料匯入資料湖，使用可重跑的管線建立已驗證、可分析的資料集合，再分別讓 SQL 與 Spark 工作負載讀取。這並不代表資料複製可以無限制增加；每個副本都要有資料擁有者、保留期限、敏感度分類與刪除流程。否則「為了分析複製一份」很快就演變成不可追蹤的個資散落。
Titan 可將 ADLS Gen2 中的資料分為三層：
這不是 Azure 強制的產品功能，而是資料工程常用的治理模式。它的價值在於縮小錯誤爆炸半徑：若某次清理程式邏輯錯誤，只需重建受影響的 Silver／Gold，而非覆寫唯一的原始事實來源。AWS 的 S3 資料湖也能採同樣概念；雲端服務名稱不同，資料血緣與可重跑性原則相同。
Synapse 是整合式分析工作區，不是一個只有單一引擎的「大資料庫」。從 AZ-900 的選型角度，最容易混淆的是三個詞：
⚠️ 名稱陷阱：Azure SQL Data Warehouse 是舊名稱，現行名稱為 Azure Synapse Analytics。碰到 2020 題庫時，先做名稱轉換，再判斷題目是否仍符合現行服務邊界；不能把舊名當成另一個產品，也不能用過時名稱掩蓋新的功能差異。
Synapse pipelines 與 Azure Data Factory 的資料整合能力，可用於排程、複製與轉換資料。但管線本身只是一條受控的資料流，不會自動替 Titan 解決來源 schema 演變、重複事件、晚到資料或錯誤重跑。每條管線都應記錄輸入版本、輸出位置、失敗通知與重跑策略；連線到來源系統時，應使用受控身分或 Key Vault，而不是把資料庫密碼塞在活動設定裡。
對 AWS 背景讀者而言，這個抽象近似 Glue 的 crawler／job 與 workflow：它們幫忙編排與轉換，卻不會自動保證資料品質。資料品質規則、目錄、權限與監控仍是架構設計的一部分。
Azure Databricks 的核心是受控 Apache Spark 與協作工作區。它適合 Titan 的資料工程師把多來源事件資料以 Python、SQL、Scala 或 R 轉換，讓資料科學家在同一類協作介面中探索資料與準備特徵。Notebook 能保留分析脈絡，但Notebook 不等於正式部署流程：可重複的生產作業仍要有版本控制、參數化、測試、排程、失敗重試與權限審查。
Spark 的分散式特性也不是免費的擴展按鈕。若將大量小檔案、資料偏斜（data skew）或不必要的全表 shuffle 交給叢集，工作可能變慢、成本升高，甚至只有少數 executor 被熱分割拖住。資料工程團隊應觀察工作負載、設定資料分割與檔案格式，並以工作集群與預算告警限制實驗性工作對正式分析平台的衝擊。
這不是二選一考題時才需要的觀念。Titan 可以讓 Databricks 負責 Spark 清理與特徵工程，把已驗證的資料寫入資料湖的消費層；接著讓 Synapse SQL 與 Power BI 面向分析師提供一致的查詢／報表體驗。共同資料湖不代表互相繞過權限：資料湖、工作區與 BI 都要維持一致的資料分類與最小權限。
反過來，如果團隊沒有 Spark 資料工程需求，只需以 SQL 查詢資料湖與建置企業報表，就不必為了「看起來比較強」而增加 Databricks。服務越多，權限、網路端點、成本標籤與事故排查面就越大。先以存取模式與團隊能力選工具，才是降低爆炸半徑的作法。
把資料湖當成公開共享磁碟：所有人都能讀取 Bronze 層，等於把原始個資與交易資料擴散到不需要的人。修正方式是分層授權、建立資料目錄與只提供 Gold 資料集給一般報表角色。
把 serverless 當成無成本：serverless SQL 省掉預先配置，不代表掃描資料免費。未分割的原始檔、重複掃描與沒有查詢治理的儀表板，都可能讓小型試驗變成持續成本。修正方式是量測掃描量、整理資料格式、設定預算與把高頻穩定負載重新評估為適當的容量模型。
把 Notebook 當成祕密保管庫與正式發布管道：硬編碼金鑰一旦被複製、匯出或寫進執行記錄，就失去輪替與稽核能力。修正方式是以 Microsoft Entra ID 受控身分、最小 RBAC 與 Key Vault 管理祕密，並讓程式碼經版本控制與審查後再排程執行。
分析平台的爆炸半徑至少有三層。資料層：錯誤 ETL 不應覆寫 Bronze 原始資料；以不可變原始層、版本化輸出與品質檢查來縮小範圍。運算層：實驗 Notebook 不應耗盡正式報表的資源；以工作負載隔離、容量限制、標籤與監控分開處理。身分層：一個廣泛的儲存體金鑰不應讓所有工作負載讀寫整座資料湖；以受控身分、範圍化角色與資料夾／資料集邊界授權。
復原也應演練：管線失敗後能否從原始資料重跑？Gold 指標若算錯，能否定位是哪一個版本、哪些報表受影響？區域或工作區不可用時，哪些報表可以延遲，哪些決策流程必須切換？這些問題把「能查詢」提升成可營運的資料產品。
生產資料湖與分析工作區應評估 Private Endpoint、受控虛擬網路及私人 DNS，避免資料平面端點被無限制暴露在公網。網路隔離不能取代身分驗證；即使流量留在私網，也仍要以 Microsoft Entra ID、RBAC 與資料層授權限制誰能讀寫。
祕密則應放入 Key Vault 或以受控身分避免長期祕密。最後，為資料管線建立日誌、失敗告警、掃描量／叢集使用量監控、成本標籤與預算，才能在錯誤擴散前看見它。安全、可靠性與成本不是資料工程完成後才補的三份文件，而是每次讀寫路徑的一部分。
Azure Synapse Analytics
Azure Databricks
Data lake（資料湖）
OLAP（線上分析處理）
Titan 的遊戲營運團隊每天收集數十億筆事件資料，資料工程師要以 Python／Spark 清洗多來源資料並建立特徵資料集；分析師則要用 SQL 產生長期營運與營收報表。CTO 要求原始資料留在 ADLS Gen2、不要讓報表查詢直接壓到線上交易庫，且所有服務帳號都必須避免使用硬編碼祕密。
哪個方案最符合需求？
✅ 正解：B。 題目同時包含資料湖、Spark 資料工程、企業 SQL 分析、交易與分析隔離，以及避免祕密硬編碼。Databricks 對應 Spark／Notebook 協作；Synapse 對應資料倉儲與分析 SQL；ADLS Gen2 是兩者可共用的資料湖底座。受控身分與最小權限將資料存取權限限制在必要範圍。
❌ A 的陷阱：Cosmos DB 適合線上操作型請求；把長期大範圍分析直接壓在交易資料庫，會讓報表與玩家請求互相爭用資源，也擴大資料讀取與成本風險。
❌ C 的陷阱：自架 VM 把修補、叢集擴縮、高可用、祕密保管與網路防護全交回 Titan，且所有風險集中在單一故障點，不符合受控分析平台與防禦性設計需求。
❌ D 的陷阱：Queue Storage 解決的是非同步訊息傳遞，不是可儲存與查詢巨量分析資料、執行 Spark 轉換或建置資料倉儲的服務。
活動首日，Titan 發現 Gold 層的「付費玩家數」比財務系統多 18%。CTO 要求立刻處理，但不能讓工程師直接刪除原始日誌。最安全的 Runbook 是：先暫停下游報表刷新並標示資料新鮮度；保留 Bronze 原始資料；找出造成重複計數的 Silver／Gold 轉換版本；在隔離環境修正、以可追溯的輸入重新計算，最後再發布新的 Gold 版本。這個順序避免把可稽核的原始事實與錯誤的衍生結果一起刪掉。
| 錯誤決策 | 為何危險 | 防禦性替代方案 |
|---|---|---|
| 直接覆寫原始資料 | 失去重跑、稽核與比對依據 | 保留 Bronze，重建衍生層 |
| 讓每位分析師修正式 Notebook | 權限與結果不可控 | 以版本控制、審查與排程作業發布 |
| 關閉所有資料湖存取 | 使必要營運也中斷 | 暫停受影響 Gold 資料集，保留最小必要路徑 |
| 忽略已發出的報表 | 錯誤決策持續擴散 | 標記受影響儀表板、通知資料擁有者並重算 |
驗證狀態：真題 1 與真題 3 已經 Microsoft Learn 官方文件逐選項交叉驗證確認，但 ExamTopics 討論頁無法定位到與 Synapse / serverless SQL 完全對應的 AZ-900 專屬題號（列表頁已無法存取），因此未附社群 tally。真題 2 已同時完成 ExamTopics 社群驗證（Q212，Playwright 讀取）與 Microsoft Learn 交叉驗證。
舊系統文件要求 Titan 將「Azure SQL Data Warehouse」遷移到現行 Azure 分析服務。這個舊名稱現在對應哪個服務？
A. Azure Synapse Analytics
以下敘述是否正確？「Azure Databricks 是以 Apache Spark 為基礎的分析服務。」
A. 不需修改
read_discussion.py 讀取討論頁確認）；並經 Microsoft Learn：Azure Databricks 是什麼？ 與 Azure Databricks 產品頁 交叉驗證確認。Titan 已把歷史事件資料存放在 ADLS Gen2。分析師想依需要用 SQL 查詢資料湖，並避免預先維護持續運行的專用資料倉儲資源。Synapse 中最貼近的能力是？
A. serverless SQL pool
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q26，屬歷史題庫層，已與 Microsoft Learn 交叉驗證；舊題所稱 SQL Data Warehouse 已按現行名稱 Azure Synapse Analytics 修正，不將舊稱當作現行服務。
Titan 要保留 20 TB 的歷史遊戲日誌，平時少量存取、每月由 Power BI 與分析團隊做大範圍彙總。哪個架構方向最合理？
答案：B。 巨量、低頻存取、彙總與 BI 是分析型訊號；資料湖加上 Synapse 比把分析壓在 OLTP NoSQL 資料庫更合適。C 與 D 分別是名稱解析與訊息傳遞服務，沒有分析查詢能力。
⚠️ 來源說明：本題依 2020 年 gratisexam AZ-900 題庫 Q56 的「服務邊界與最小權限」題型改寫，屬歷史題庫層；本題採用現行 Microsoft Entra ID、受控身分與 Key Vault 的防禦性設計，不使用已過期名稱。
Titan 的 Databricks Notebook 必須存取資料湖與第三方資料來源。哪項做法最符合防禦性設計？
答案：B。 最小權限、受控身分與集中祕密管理能縮小外洩與誤操作的爆炸半徑。A 容易讓祕密流入程式碼與記錄；C 過度授權；D 擴大網路曝露面。
Titan 的分析師只需要用 SQL 定期查詢 ADLS Gen2 中已整理的 Parquet 資料；資料工程團隊沒有 Spark Notebook 或機器學習的需求。哪個判斷最精確？
答案：A。 題幹的主要工作是資料湖 SQL 分析，沒有出現 Spark、Notebook 或資料工程協作需求。Synapse SQL 是直接的候選；Databricks 不是錯誤服務，但不應在需求不足時增加一個工作區、權限與成本面。
Titan 建立 serverless SQL 查詢原始資料湖。某份儀表板每五分鐘掃描全部未分割的歷史檔案。哪項改善最符合成本與效能治理？
答案：B。 serverless 指的是不預先管理專用運算資源，不是資料掃描與查詢沒有成本。整理資料與治理查詢可降低不必要掃描；C、D 則擴大權限與祕密外洩風險。
Titan 的轉換工作只需要將 Silver 資料寫入指定路徑，不需要讀取所有 HR 原始檔。哪種設計最符合最小權限？
答案：B。 受控身分配合範圍化的角色授權能限制憑證與存取範圍。A 是過度授權；C 讓祕密散落；D 完全破壞資料平面邊界。
先問「資料要被誰、以什麼方式消費」：交易服務需要低延遲單筆操作，不要被 OLAP 掃描拖慢；分析師需要 SQL 與受治理的資料集，優先看 Synapse；資料工程師需要分散式 Spark 與 Notebook 協作，評估 Databricks。接著才問運算要常駐還是按查詢、資料是否已整理、以及權限是否能限制到資料集與工作負載。
┌────────────────────────────────────────────────────┐
│ 先判斷資料消費模式 │
├───────────────┬────────────────┬───────────────────┤
│ 即時交易 │ SQL／BI 分析 │ Spark 資料工程 │
│ SQL／Cosmos DB│ Synapse │ Azure Databricks │
├───────────────┴────────────────┴───────────────────┤
│ 共同底座：ADLS Gen2、Entra ID、最小權限、監控 │
└────────────────────────────────────────────────────┘
Titan 已在 ADLS Gen2 保存原始事件資料。資料工程師需要以 Spark 做去重與 sessionization，分析師需要每天早上用 SQL 檢視已核准的營運指標。Azure 可讓 Databricks 產出已清理的資料層，再由 Synapse SQL／Power BI 消費；AWS 方向上可由 EMR／Glue 做 Spark 轉換，再由 Athena 或 Redshift Spectrum 讀取 S3 資料。這是架構觀點的對照，不是可互換設定：每一邊都必須各自設計資料目錄、IAM／Entra 權限、網路端點與成本監控。
雙雲考場口訣：
資料湖是底座，不是報表引擎SQL 倉儲／資料湖分析：Synapse ↔ Redshift／AthenaSpark／Notebook 資料工程：Databricks ↔ EMR（方向性對照）先分資料層，再分權限；先量測掃描，再談 serverless
| 項目 | 內容 |
|---|---|
| 對應課程章節 | 本主題課程未收錄 |
| 官方考綱領域 | Describe Azure Architecture & Services（占比 35–40%） |
| 課程涵蓋範圍 | 本主題課程未收錄。 |
| 本文補充範圍 | 以 Microsoft Learn 補齊 Synapse 的資料倉儲／SQL 分析定位、Databricks 的 Apache Spark 資料工程定位、ADLS Gen2 資料湖分層，以及資料分析的最小權限與網路邊界；RPG 素材僅用於 Titan 情境與 AWS 對照。 |
⚠️ 考綱變更：2020 題庫的 Azure SQL Data Warehouse 已更名為 Azure Synapse Analytics；本文一律採用現行名稱。
明天 Titan 科技將進入資料金庫的階段驗收：Blob、檔案與磁碟、資料遷移、關聯式資料庫、Cosmos DB 與大數據分析服務會放進同一張選型地圖，透過 15 題情境題檢驗你是否能在壓力下選出正確服務。
iThome鐵人賽
看影片追技術