資料分析與 Looker

什麼是 Google Cloud 資料分析管線？

從原始資料到商業決策

現代企業以前所未有的速度產生資料——每一次網站點擊、每一筆 IoT 感測器讀數、每一次信用卡刷卡，都是潛在的洞察來源。然而，堆在資料庫裡的原始數據毫無價值。要將資料轉化為決策，你需要一條完整的資料分析管線（analytics pipeline），將資料從源頭傳送到主管螢幕上的儀表板。

Google Cloud 的五大整合階段

Google Cloud 提供了一套完整且高度整合的服務，清楚地對應到五個階段：擷取 → 儲存 → 處理 → 分析 → 視覺化。對於 Cloud Digital Leader（CDL）考試，你不需要知道如何為這些服務撰寫程式。你需要認識每個工具的名稱、理解它服務於管線的哪個階段，並為特定商業情境選出正確的工具。

為何 Looker 家族值得深入探討

視覺化層——資料最終與人眼接觸的地方——由兩款 Google 產品主導：Looker（企業級商業智慧平台）以及 Looker Studio（免費自助式儀表板工具，前身為 Data Studio）。混淆這兩者是 CDL 考生最常見的錯誤之一，而理解受治理的企業商業智慧與即興報表之間的差異，也是分析章節中考試頻率最高的概念之一。本學習筆記從頭到尾走完整條管線，並在 Looker 家族上做最深入的解析。

資料分析管線的五個階段

不論再複雜，Google Cloud 上的每一個資料分析工作負載都可以分解成相同的五個階段。請牢記這些——它們出現在數十道 CDL 情境題中：

1. 擷取（Ingest） — 將資料帶入雲端（串流通常透過 Pub/Sub，批次則使用 Storage Transfer Service）。
2. 儲存（Store） — 存放於耐久且可查詢的位置（BigQuery 用於結構化資料倉儲，Cloud Storage 用於原始資料湖泊）。
3. 處理（Process） — 清理、轉換與豐富資料（Dataflow、Dataproc、Cloud Composer）。
4. 分析（Analyze） — 執行查詢以回答商業問題（BigQuery SQL、BigQuery ML）。
5. 視覺化（Visualize） — 將結果呈現給人類（Looker、Looker Studio、Connected Sheets）。

舉例來說，一家零售公司可能透過 Pub/Sub 擷取銷售點交易資料，儲存至 BigQuery，用 Dataflow 處理以清除空值並換算幣別，再用 BigQuery SQL 分析季度銷售，最後在 Looker 儀表板上為財務長視覺化結果。每個階段都由 Google 代管——客戶專注於商業問題，而非底層管線配置。

白話文解釋

資料分析可能感覺很抽象，但你曾看過的每一個儀表板，在現實世界中都有對應的例子。以下用三種不同的方式，說明 Looker、Looker Studio、BigQuery 和 Dataflow 在幕後實際做了什麼。

類比一 — 高鐵控制中心儀表（即時營運儀表板）

想像你是台灣高鐵的行控員，面前是一整面控制中心監視牆，密密麻麻的指示燈與數字顯示著每列車的位置、速度、月台佔用狀況與系統警示。這些數字都來自沿線各站與列車上的感測器，透過核心電腦系統轉換成乾淨的格式，出現在你面前的螢幕上。

對應到 Google Cloud：感測器就像 Pub/Sub，持續發出事件串流（每秒一筆、每秒千筆，有時達百萬筆）；將訊號清理並轉換的核心電腦就是 Dataflow，它即時處理串流，過濾異常讀數，計算衍生指標；控制中心的監視牆本身就是 Looker——一個受治理、精心整理的儀表板，無論誰坐在行控席，呈現的都是同一份可信數字。就像高鐵不會讓某個班次顯示的速度單位是公里而另一班是英哩，企業也不能讓某位副總看到「營收 = 新台幣 1.2 億」、另一位卻看到「新台幣 1.15 億」，因為兩人取用了不同的來源。Looker 透過 LookML 強制執行唯一可信來源，就像高鐵工程規範強制統一每個控制台的顯示標準。

類比二 — 醫院急診監視螢幕（串流分析）

走進急診室，你會看到病患身上接著監視器，顯示心率、血壓、血氧和呼吸頻率。這些是串流儀表板——每秒更新一次，值班醫師看到異常可在數秒內做出反應，而不是數小時後。

對應到 Google Cloud，病患就是事件來源（你網站上的點擊、應用程式的付款、伺服器的錯誤日誌）。Pub/Sub 是連接病患與監視器的導線；Dataflow 是監視器的訊號處理器，它平滑雜訊、計算滾動平均值、標記異常；BigQuery 是病患的病歷——每一筆讀數都歸檔供日後分析；Looker Studio 是醫師帶回家的當日摘要報告——快速、免費的自助式報表；Looker 則是院長用來跨科室監控醫療品質的全院治理儀表板，使用所有病房一致的關鍵績效指標（KPI）定義。臨時性的即興報表來自 Looker Studio，企業級受治理的指標來自 Looker。

類比三 — 證券交易所行情牆（嵌入式分析）

想像台灣證券交易所大廳那面行情牆——巨大的電子看板即時顯示數千檔股票的報價與漲跌幅。現在想像每一款券商 App 都在自己的介面裡，為使用者呈現一份個人化的行情切片，無縫嵌入在券商自己的品牌外觀中。這個嵌入式體驗就是 **Looker 嵌入式分析（embedded analytics）**所提供的。

BigQuery 存放交易歷史；Dataflow 處理來自交易所的報價資料串流；Looker 在上層建立 LookML 語意模型，定義「成交價」「成交量」「日漲跌幅」的精確含義——再透過 API 和 iframe 將這些受治理的指標暴露出去，讓券商嵌入自家產品。客戶看到的是「XX 證券洞察」這個品牌，完全不知道 Looker 在幕後運作。但底層使用的是同一套受治理的商業智慧平台，與公司內部分析師共用相同的指標定義。這就是金融科技公司、SaaS 廠商和電商平台選擇 Looker 作為面向客戶分析標準的原因：一個模型、一套數字、無限個呈現介面。Looker Studio 無法在這個規模上做到——它是供內部團隊使用的免費儀表板工具，而非面向付費客戶的嵌入式分析平台。

Looker：企業商業智慧平台

Looker 是什麼以及 Google 為何收購它

Looker 是 Google Cloud 旗艦級的企業商業智慧（BI）平台。2020 年被 Google 收購後，現在是任何需要受治理指標、唯一可信來源以及在面向客戶產品中提供嵌入式分析的組織首選。

LookML — 一次定義指標，到處重用

Looker 的核心功能是 LookML，一種類 YAML 的建模語言，讓資料工程師只需在程式碼中定義一次業務邏輯——「營收的定義是什麼？」「如何計算活躍使用者？」——之後每個儀表板、每份報表、每次 API 呼叫都使用相同的定義。這消除了試算表式報表的混亂，避免各部門各自發明同一個關鍵績效指標的不同版本。

資料庫連線能力與定價模式

Looker 可連接超過 50 種資料庫，包括 BigQuery、Snowflake、Redshift、MySQL 和 PostgreSQL。它是**資料庫無關（database-agnostic）**的，但得益於 BI Engine 加速，與 BigQuery 搭配時效果尤佳。Looker 以付費訂閱制銷售，採用每用戶或容量計費——沒有免費方案。

Looker Studio：自助式儀表板

從 Data Studio 到 Looker Studio

Looker Studio（前身為 Google Data Studio，2022 年更名）是一款免費的自助式儀表板與報表工具。如果說 Looker 是企業商業智慧的高鐵控制中心，Looker Studio 就是讓單一分析師、小型團隊或行銷主管能用拖放方式快速建立儀表板的個人工作台。

連接器與零安裝分享

Looker Studio 可連接 BigQuery、Google Sheets、Google Analytics、Google Ads、YouTube Analytics，以及數十種第三方來源（透過社群連接器）。它完全在瀏覽器中運作，無需安裝任何軟體，儀表板可像 Google 文件一樣用連結分享。

理想使用情境

Looker Studio 適合以下情境：

• 行銷分析師快速製作活動成效報表。
• 小型企業以 Google Sheets 追蹤每週銷售。
• 在決定是否投資完整 Looker 部署前，先製作探索性儀表板。
• 可公開分享的報表（例如政府開放資料儀表板）。

在一致性至關重要的關鍵任務、全企業報表場景中，Looker 才是正確的工具。追求敏捷性、實驗性與「夠用就好」的零成本報表，Looker Studio 勝出。

Looker Studio Pro：中間地帶

在免費的 Looker Studio 與完整企業版 Looker 之間，Google 提供了 Looker Studio Pro。它在免費版的基礎上增加企業功能：團隊工作區、Cloud 客戶支援以及 Dataplex 資料治理整合。它不包含 LookML——那仍然是 Looker 的專屬功能。Pro 版採用按專案計費，對於已超出免費版 Looker Studio 需求、但尚不需要完整 Looker 部署的中型團隊來說，是合理的選擇。

何時選擇 Looker vs Looker Studio

這個決策在 CDL 考試中反覆出現。以下是速查表：

處理層：Dataflow

Apache Beam 底層原理

Dataflow 是 Google Cloud 完全代管的 Apache Beam 管線執行服務。其最重要的特性是 Dataflow 使用相同的管線程式碼，同時處理**批次（batch）處理（對固定大小的資料集執行一次）與串流（streaming）**處理（對無界的事件串流持續處理）。

Dataflow 常見工作負載

Dataflow 的實際應用情境包括：

• 在將 Pub/Sub 串流資料載入 BigQuery 前，先進行清理與轉換。
• 將資料從業務資料庫移入資料倉儲的 ETL（擷取-轉換-載入）作業。
• 對支付串流進行即時詐騙偵測。
• 對點擊流資料進行 session 化，用於產品分析。

無伺服器自動擴展

Dataflow 是無伺服器的——Google 管理所有自動擴展、工作節點池和資料洗牌。客戶只需提交管線，Dataflow 自行決定需要多少工作節點、何時擴展、何時縮減。

處理層：Dataproc

代管 Hadoop 與 Spark

Dataproc 是 Google Cloud 用於執行 Apache Hadoop 與 Apache Spark 叢集的代管服務。雖然 Dataflow 是全新專案的首選，但 Dataproc 主要是為了支援現有地端 Hadoop 與 Spark 工作負載的**搬遷上雲（lift-and-shift）**而存在。

搬遷上雲無需重寫程式碼

如果一家公司花了多年在 Cloudera 或 Hortonworks 叢集上用 Scala 或 PySpark 撰寫 Spark 作業，他們不願意全部改寫為 Apache Beam。Dataproc 讓他們無需修改程式碼，直接搬移這些作業在 Google Cloud 上執行，同時享有雲端優勢：叢集可在 90 秒內建立完成、彈性擴展，並在閒置時關閉以節省費用。

需要 Hadoop 生態系統時

當工作負載需要 Hadoop 生態系統中特定工具——Hive、Pig、Presto、HBase、Zeppelin——而 Dataflow 沒有直接對等功能時，Dataproc 也是正確答案。

處理層：Cloud Composer

代管 Apache Airflow

Cloud Composer 是 Google Cloud 的代管 Apache Airflow 服務。Dataflow 負責處理資料本身，而 Composer 協調（orchestrate） 管線——決定每個步驟何時執行、相依關係為何，以及某步驟失敗時如何處理。

典型的協調 DAG

一個典型的 Composer 工作流程可能是：

1. 等待新檔案在凌晨 3 點落入 Cloud Storage。
2. 觸發 Dataflow 作業進行清理。
3. 等待 Dataflow 作業完成。
4. 執行 BigQuery SQL 轉換。
5. 通知 Looker 重新整理每日儀表板。
6. 若任何步驟失敗，傳送 Slack 通知。

Composer 是 Dataflow 的補充而非替代

當 CDL 題目描述「協調（orchestration）」、「排程（scheduling）」、「工作流程管理」、「DAG（有向無環圖）」或「Airflow」時，Cloud Composer 就是答案。它不是 Dataflow 的替代品——而是與 Dataflow 協同運作，協調多步驟作業。

擷取層：Pub/Sub

主題、訂閱與解耦

Pub/Sub（發布/訂閱）是 Google Cloud 的全球分散式訊息服務，也是串流資料的標準入口。發布者（資料生產者）將訊息發送至主題（topics）；訂閱者（消費者）從**訂閱（subscriptions）**拉取或接收訊息。Pub/Sub 將生產者與消費者解耦，使兩者可獨立擴展。

標準 PDB-L 參考管線

Pub/Sub 是 Google Cloud 上幾乎每個串流分析架構的前門。標準參考管線如下：

Pub/Sub → Dataflow → BigQuery → Looker

裝置或網路應用程式將事件發布至 Pub/Sub；Dataflow 消費這些事件，清理並豐富後串流寫入 BigQuery；Looker 查詢 BigQuery 以驅動即時儀表板。這個四服務管線在 CDL 考試中極為常見，值得自創記憶口訣——記住這條鏈路 PDB-L（Pub/Sub、Dataflow、BigQuery、Looker）。

規模、耐久性與擷取模式

Pub/Sub 每秒支援數百萬則訊息、保證至少一次傳遞（at-least-once delivery），並跨多個 Google Cloud 區域複製訊息以確保耐久性。它是 IoT 遙測、應用程式事件日誌、資料庫變更資料擷取（CDC）以及 Webhook 扇出的首選擷取服務。詳見 Pub/Sub overview。

儲存層：BigQuery 與 Cloud Storage

資料倉儲 vs 資料湖泊 — 兩種不同角色

分析管線中的儲存分為兩種角色：

• BigQuery 是資料倉儲——結構化、可用 SQL 查詢，針對數兆行資料的快速分析查詢最佳化。清理過的模型化資料存放於此，供 Looker 與 Looker Studio 視覺化使用。關於倉儲層的深入解析，請參閱使用 BigQuery 進行資料倉儲。
• Cloud Storage 是資料湖泊——原始的、非結構化或半結構化的檔案（CSV、JSON、Parquet、圖片、影片），以極低的成本儲存於任意規模。資料最初落地的地方，以及為合規而保留的歸檔副本。

BigLake — 橋接資料倉儲與資料湖泊

現代資料架構常使用 BigLake，讓 BigQuery 能直接查詢 Cloud Storage 中的資料而無需複製——結合物件儲存的低成本與資料倉儲的 SQL 能力。若要將 BigQuery 與平台上的其他資料庫進行比較，請參閱 Google Cloud Databases。

即時分析 vs 批次分析

CDL 考試中一個關鍵的決策點，是工作負載需要即時（串流）還是批次分析。

何時必須使用串流

**即時（串流）**適用於延遲需以秒計算的情境：

• 信用卡交易的詐騙偵測。
• 使用者瀏覽時的個人化推薦。
• 全天候服務台的營運儀表板。
• 工業設備的 IoT 警示。

何時批次已足夠

批次適用於以小時或天為單位的延遲可接受的情境：

• 每月財務結算。
• 每日早上 8 點發送的銷售報告電子郵件。
• 季度主管審查。
• 歷史資料的歸檔分析。

串流與批次的成本取捨

成本差異不容忽視。批次作業執行一次後關閉；串流作業全天候運行，持續累計費用。只有在商業價值足以支撐常態運行處理時，才使用串流。關於雲端的更廣泛商業案例，請參閱雲端價值主張。

嵌入式分析：Looker 的獨特優勢

iframe 嵌入與 Powered by Looker

區分 Looker 與 Looker Studio 的一項功能是嵌入式分析。透過 Looker 的 iframe 嵌入與 Powered by Looker 計畫，Looker 儀表板與視覺化圖表可以直接嵌入第三方 SaaS 產品中。該 SaaS 的客戶將分析功能視為產品的原生功能，完全不知道背後是 Looker 在驅動。

白標 B2B SaaS 分析

這正成為 B2B SaaS 廠商的業界標準——他們希望為自己的客戶提供「白標分析」，而無需從零打造商業智慧工具。HubSpot、Lyft 和 Spotify 等公司都在 Looker 上建立了面向客戶的分析功能。Looker Studio 不支援這種企業級嵌入情境。

對應管線的商業故事

將考試情境比對至技術棧

CDL 考題幾乎都以商業故事的形式呈現。以下是四種最常見的情境及其對應的分析技術棧：

• 「我們的主管希望有一個即時關鍵績效指標儀表板，各地區使用一致的定義」 → Pub/Sub + Dataflow + BigQuery + Looker（治理與 LookML）。
• 「我們的行銷分析師希望在週五前把 Google Ads、Google Analytics 和一份試算表整合成一個視圖」 → Looker Studio（免費、自助式、快速）。
• 「我們是 SaaS 公司，希望在應用程式內向付費客戶展示使用量圖表」 → Looker 嵌入式分析。
• 「我們有十年的 Hive 作業在地端運行，需要快速上雲而不重寫程式碼」 → Dataproc（搬遷上雲），輸出至 BigQuery，以 Looker 製作儀表板。

成本與定價比較

Looker Studio 與 BigQuery 的免費方案合計，讓小型企業可以零成本永久運行真實的分析工作。一旦治理、嵌入式分析或嚴格的關鍵績效指標一致性成為需求，升級至 Looker 的路徑就隨之開啟。

常見問題

Looker 與 Looker Studio 有什麼差別？

Looker 是企業級付費商業智慧平台，具備 LookML 語意建模、受治理指標與嵌入式分析功能。Looker Studio 是免費的自助式儀表板工具，用於即興報表。相同品牌、不同產品、不同使用情境。

何時應選擇 Dataflow 而非 Dataproc？

新建的雲端原生管線（尤其是串流管線）選 Dataflow，因為它透過 Apache Beam 提供批次加串流的統一模型。從地端遷移現有 Hadoop 或 Spark 工作負載、且希望最小化程式碼異動時，選 Dataproc。

LookML 是什麼？

LookML 是 Looker 的建模語言。資料工程師用 LookML 一次性定義維度、量值與業務邏輯，之後每個儀表板、報表和 API 呼叫都使用這些共用定義——在整個組織內形成唯一可信來源。

Looker Studio 可以連接 BigQuery 嗎？

可以。Looker Studio 有原生 BigQuery 連接器，是免費視覺化 BigQuery 資料最常用的工具之一。若需要受治理的企業級報表，首選 Looker；若只需要快速或即興圖表，Looker Studio 已綽綽有餘。

Google Cloud 上的標準串流分析管線是什麼？

Pub/Sub → Dataflow → BigQuery → Looker（記憶口訣：PDB-L）。事件透過 Pub/Sub 進入，由 Dataflow 處理，儲存至 BigQuery，再透過 Looker（或免費 / 即興情境使用 Looker Studio）視覺化。

Cloud Composer 是 Dataflow 的替代品嗎？

不是。Cloud Composer（代管 Apache Airflow）負責協調工作流程——排程並協調多步驟管線。Dataflow 負責執行每個步驟內的資料處理。兩者互補而非競爭。

總結：從管線到決策

對於 Google Cloud Digital Leader 考試，資料分析層的重點在於認識五個階段（擷取 → 儲存 → 處理 → 分析 → 視覺化），並將正確的 Google 服務對應到每個階段。視覺化階段有兩個產品需要特別留意：Looker 用於具備 LookML 與嵌入式分析的受治理企業商業智慧，Looker Studio 用於免費的自助式儀表板。在幕後，Pub/Sub 擷取串流，Dataflow 與 Dataproc 處理資料，Cloud Composer 協調工作流程，BigQuery 儲存一切並備妥供 SQL 查詢。掌握這張服務地圖以及各服務適用的商業情境，你就掌握了 CDL 考試大約五分之一的內容。