為什麼我們需要 Cloud Pub/Sub？

在現代的分散式系統中，不同的服務組件往往會面臨以下挑戰：

後端處理速度跟不上

當前端產生資料的速度遠大於後端處理的速度時，系統就會出現瓶頸。例如，電商網站在促銷活動期間，訂單產生的速度可能遠超過庫存系統的處理能力。

又或是遊戲架構，通常會有高低峰期，像白天線上可能只有 100 多人，但是晚上可能高達 10,000 人在玩遊戲，可是你後端只有一台機器，會來不及處理持續不斷送進來的資料，影響到使用者體驗。

流量衝擊與系統穩定性

資料處理來不及是一回事，請求突然暴增，直接衝擊到後端系統，很容易造成服務過載甚至當機，最好要有一個緩衝機制，先讓資料在某個地方「排隊」，不要直接「打進」後端，確保系統穩定。

系統耦合度過高

當系統元件之間過度依賴時，任何一點故障都可能影響整個系統的運作。Pub/Sub 扮演了一個「智慧排隊系統」的角色，讓訊息能夠讓各個服務單獨處理，不會因為某個服務壞掉，大家都不能再處理訊息。

MQTT 協定的演進與 Pub/Sub 的關係

在了 Pub/Sub 之前，早期有個協定叫做 MQTT（Message Queuing Telemetry Transport）。MQTT 最初由 IBM 在 1999 年開發，目的是為了在衛星網路中傳輸石油管線的感測器資料。目前也廣泛應用在物聯網的應用，例如收集各種感測器回傳的資料，或是從工產的生產線收集設備或產品資料，確保生產線沒有異常。

MQTT 採用發布-訂閱模式，在架構中，有三個核心角色：

發布者（Publisher）：負責發送訊息到特定主題

訂閱者（Subscriber）：或叫客戶端 (Client) 訂閱感興趣的主題並接收訊息

訊息代理（Message Broker）：居中協調，負責接收、儲存和轉發訊息

這種模式的優點是發布者和訂閱者之間完全解耦，彼此不需要知道對方的存在，也不需要同時在線上。這種設計理念深深影響了後來許多訊息系統的架構，當然也包括 Pub/Sub。

Cloud Pub/Sub 的核心概念

Google Cloud Pub/Sub 沿用了 MQTT 的發布-訂閱概念，但針對雲端環境進行了大幅優化：

主題（Topic）：

就像是一個訊息的分類標籤，發布者將訊息發送到特定主題中。例如，電商網站可能會有「user-clicks」、「purchase-events」等不同主題。

訂閱（Subscription）：

代表對某個主題的訂閱關係。一個主題可以有多個訂閱，每個訂閱都會收到該主題的所有訊息副本，這讓同一份資料可以被多個不同的服務同時處理。

訊息（Message）：

實際傳遞的資料內容，可以是 JSON、二進位資料或任何格式，每個訊息都有唯一的 ID 和時間戳記。

如下架構圖，Pub/Sub 的訊息傳送還可以分成 Pull 和 Push 兩種，Pull 是 Subscriber (或叫 Consumer) 主動去 Subscription 拉取訊息，如果要確保 Subscriber 能夠確實處理到每一筆訊息，適合使用 Pull 方式。如果希望訊息即時傳送出去，則建議使用 Push 方式。

Cloud Pub/Sub 的技術優勢

相較於傳統的訊息佇列系統，Pub/Sub 提供了幾個重要特性：

擴展性高

能夠處理每秒數百萬筆訊息，並且自動根據負載進行擴充，這種分散式的處理架構，遠遠超過傳統只能用一台機器處理的能力。

至少一次傳遞保證 (Exactly-Once Delivery)

確保每個訊息至少會被傳送一次，避免資料遺失。同時提供訊息確認機制，只有當訂閱者確認處理完成後，訊息才會從佇列中移除。

順序保證

透過訊息排序功能，可以確保相關訊息按照正確順序處理，這對金融交易相關應用特別重要。

無效信件處理 (死信佇列 Dead Letter Queue)

發送失敗的訊息暫存區 (Subscription)，訊息在此不會再持續發送，由後端主動來收訊息 (Pull 模式)。

Pub/Sub 基本操作示範

建立 Pub/Sub Topic

接下來我們可以快速體驗一下 Pub/Sub 如何運作，我們先建立一個主題為叫 my-topic。

順便勾選「新增預設訂閱項目」：

從 Cloud Shell 發送串流訊息

然後打開 Cloud Shell，執行以下指令碼，它會每 10 秒鐘發出一個 Hello 訊息，加上發出訊息當下的時間：

while true; do   gcloud pubsub topics publish my-topic --message="Hello! 時間：$(date '+%Y年%m月%d日 %H時%M分%S秒')";   sleep 10; done

接收 Pub/Sub 訊息

我們去訂閱項目 my-topic-sub 的「訊息」，按下「提取」：

接下來等幾秒鐘，就會馬上看到收到的訊息，非常快。

確認 Pub/Sub 訊息

而這些訊息是還沒有被確認的狀態，而且在「確認」欄位顯示為「已超過確認期限」，因為預設的確認截止時間是 10 秒 (可以延長)，我的手速太慢，擷圖的時候已經超過時間了。

那我們就勾選「啟用確認訊息」，再按一次「提取」，它就會把最舊的兩筆訊息顯示一個「確認」按鈕，因為 Pub/Sub 重新傳送未確認的訊息，所以確認截止時間會重新計算，現在又可以按「確認」了。

這就是所謂的「At-least-once delivery」：確保訊息至少被傳遞一次。而且會持續重試，直到被確認為止，不然就是到了 7 天之後，訊息過期。

我們再按下「確認」的話，訊息才會被刪除，它們就不會再出現在訂閱項目中了。

你會發現這些訊息一直改變它的狀態，本來可以按確認的訊息，又會一個一個到期，你就直接再「提取」，它們又會不斷出確認按鈕，有點像在打遊戲的感覺！

停止發送訊息

最後記得在 Cloud Shell 那邊，按下 ctrl + C 喔，不然訊息會一直累積下去，你就確認不完喔！

前面提到的 Pub/Sub，只是讓傳過來的資料先暫時排隊起來，我們再用後端服務來消化資料。

但是如果資料多到「怎麼樣都處理不完」的話，就不得不介紹 Cloud Dataflow 這個服務，有需要可以參考《Dataflow 是什麼？跟 Apache Beam 有什麼關係？》這篇文章喔！

The post Cloud Pub/Sub 教學：比 RabbitMQ 好用，無限擴充的訊息佇列服務 first appeared on 東東 GCP 教學 - GCP 實戰講師.

-- 計算每日銷售額的7天移動平均
SELECT 
  date,
  daily_sales,
  AVG(daily_sales) OVER (
    ORDER BY date 
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  ) as moving_avg_7days,
  -- 計算與前一天的銷售增長率
  LAG(daily_sales) OVER (ORDER BY date) as prev_day_sales,
  (daily_sales - LAG(daily_sales) OVER (ORDER BY date)) 
    / LAG(daily_sales) OVER (ORDER BY date) * 100 as growth_rate
FROM daily_sales_summary
ORDER BY date;

-- 分析用戶購物車中的商品組合
SELECT 
  user_id,
  ARRAY_LENGTH(cart_items) as item_count,
  -- 提取所有商品類別
  ARRAY_AGG(DISTINCT category) as categories,
  -- 找出最貴的商品
  ARRAY_AGG(product_name ORDER BY price DESC LIMIT 1)[OFFSET(0)] as most_expensive_item
FROM users_carts
CROSS JOIN UNNEST(cart_items) as item
GROUP BY user_id, cart_items;

-- 分析門店覆蓋範圍和競爭分析
SELECT 
  store_id,
  store_name,
  -- 計算門店間距離
  ST_DISTANCE(
    ST_GEOGPOINT(store_lng, store_lat),
    ST_GEOGPOINT(-73.935242, 40.730610)  -- 紐約時代廣場
  ) / 1000 as distance_to_times_square_km,
  -- 創建門店3公里服務範圍
  ST_BUFFER(ST_GEOGPOINT(store_lng, store_lat), 3000) as service_area,
  -- 統計服務範圍內的競爭對手數量
  (SELECT COUNT(*) 
   FROM competitor_stores c
   WHERE ST_DWITHIN(
     ST_GEOGPOINT(store_lng, store_lat),
     ST_GEOGPOINT(c.lng, c.lat),
     3000
   )) as competitors_nearby
FROM our_stores;

-- 建立客戶流失預測模型
CREATE OR REPLACE MODEL `project.dataset.churn_model`
OPTIONS(
  model_type='logistic_reg',
  input_label_cols=['churned']
) AS
SELECT
  -- 特徵工程
  DATE_DIFF(CURRENT_DATE(), last_purchase_date, DAY) as days_since_purchase,
  total_purchases,
  avg_order_value,
  customer_lifetime_value,
  support_tickets_count,
  -- 標籤
  churned
FROM customer_features
WHERE partition_date > DATE_SUB(CURRENT_DATE(), INTERVAL 365 DAY);

-- 使用模型進行預測
SELECT
  customer_id,
  ML.PREDICT(MODEL `project.dataset.churn_model`, 
    (SELECT * FROM current_customers WHERE customer_id = c.customer_id)
  ).predicted_churned as churn_probability
FROM current_customers c;

-- 使用時間序列分解來檢測異常
SELECT
  date,
  actual_value,
  -- 季節性分析
  AVG(actual_value) OVER (
    PARTITION BY EXTRACT(DAYOFWEEK FROM date)
    ORDER BY date
    ROWS BETWEEN 4 PRECEDING AND 4 FOLLOWING
  ) as seasonal_avg,
  -- 趨勢分析
  AVG(actual_value) OVER (
    ORDER BY date
    ROWS BETWEEN 30 PRECEDING AND 30 FOLLOWING
  ) as trend,
  -- 異常檢測：偏離季節性平均超過2個標準差
  ABS(actual_value - AVG(actual_value) OVER (
    PARTITION BY EXTRACT(DAYOFWEEK FROM date)
    ORDER BY date
    ROWS BETWEEN 4 PRECEDING AND 4 FOLLOWING
  )) > 2 * STDDEV(actual_value) OVER (
    PARTITION BY EXTRACT(DAYOFWEEK FROM date)
    ORDER BY date
    ROWS BETWEEN 4 PRECEDING AND 4 FOLLOWING
  ) as is_anomaly
FROM time_series_data
ORDER BY date;

-- 客戶價值分析
SELECT
  customer_segment,
  COUNT(*) as customer_count,
  -- 描述性統計
  AVG(annual_revenue) as avg_revenue,
  STDDEV(annual_revenue) as revenue_stddev,
  MIN(annual_revenue) as min_revenue,
  MAX(annual_revenue) as max_revenue,
  -- 分位數分析
  PERCENTILE_CONT(annual_revenue, 0.25) OVER() as q1_revenue,
  PERCENTILE_CONT(annual_revenue, 0.5) OVER() as median_revenue,
  PERCENTILE_CONT(annual_revenue, 0.75) OVER() as q3_revenue,
  -- 相關性分析
  CORR(annual_revenue, satisfaction_score) OVER() as revenue_satisfaction_corr
FROM customer_analysis
GROUP BY customer_segment;

-- 文本分析和數據清理
SELECT
  -- 正規表達式提取
  REGEXP_EXTRACT(email, r'@(.+)') as domain,
  -- 數據指紋（用於去重）
  FARM_FINGERPRINT(CONCAT(name, email, phone)) as record_fingerprint,
  -- 生成唯一識別碼
  GENERATE_UUID() as record_id,
  -- 文本相似度（用於數據匹配）
  EDIT_DISTANCE(name1, name2) as name_similarity,
  -- JSON 數據解析
  JSON_EXTRACT_SCALAR(user_profile, '$.preferences.language') as preferred_language
FROM user_data;

The post BigQuery 不就是查詢嗎？跟資料庫差在哪裡？能做什麼分析？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

Dataproc 是什麼？

Dataproc 是 GCP 的一個全代管的大數據處理服務，它支援開源的大數據生態系統工具，如 Apache Spark、Hadoop、Hive 等。

簡單說，Dataproc 幫你把資料處理這件事，變得又快又簡單，就像把一座沉重的工廠裝進自動販賣機，按一下就能開工。

為什麼選擇 Dataproc？四大優勢

1. 快速啟動與彈性擴展：只需幾分鐘就能啟動叢集，根據工作負載自動擴縮。

2. 與 GCP 生態系整合：無縫串接 BigQuery、Cloud Storage、Vertex AI 等工具。

3. 精準付費、節省成本：按秒計費、支援自動關閉機制，有效降低閒置成本。

4. 使用你本來就會的技能： Dataproc 包含 Hadoop、Spark、Hive、Pig 等 Open Source 的工具，不用重新學習。

Dataproc 的應用場景

大數據處理

無論是 ETL（Extract, Transform, Load）處理，還是資料清洗、彙整，都可以用 Dataproc。

結合 Spark 進行機器學習訓練

Dataproc 支援 Spark MLlib，你可以直接在叢集上進行分散式訓練，大幅提升訓練速度與模型精度。

搭配 Jupyter Notebook 做互動分析

開發者可透過 Jypyter Notebook 與叢集互動，實現即時查詢與分析，彷彿在大型資料倉庫裡漫步，探索資料的可能性。

Dataproc 的架構設計概念

叢集（Cluster）與節點角色說明

Dataproc 叢集主要包含兩種節點角色：Master 與 Worker。就像一個工廠，Master 是主管，Worker 是執行員工。

而節點其實就是 Compute Engine 的虛擬機器，因為我們是對整個 Cluster 操作，不針對某一台 VM，所以我們才稱它們叫 Node。

Master 節點與 Worker 節點的差異

• Master：負責指派任務、監控進度、管理資源。

• Worker：實際執行 Spark Job 與 Hadoop Task。

如何選擇正確的 VM 類型？

n2-standard 適合大多數應用。

e2-medium 適合成本敏感的小型專案。

可依工作負載選擇是否搭配 GPU 或高記憶體，但如果是初學者，建議不要開太大的機器喔！

Spark、Hadoop、Hive 在架構中的定位

• Spark：主力計算框架，支援即時與批次任務。

• Hadoop HDFS：用於資料儲存與分散處理。

• Hive：提供 SQL 介面查詢 HDFS 中的資料。

實際操作：如何建立一個 Dataproc Cluster (叢集)

在 GCP Console 上建立步驟

進入 Dataproc => Cluster。

選擇 Compute Engine。

給 Cluster 命名，選擇 Region 和 Zone，我是照 《Dataproc: Qwik Start – Console》 這個 Lab 做的，所以就跟它一模一樣，你也可以選擇台灣 asia-east1 喔！

先設定 Manager Node，我還是習慣叫 Master Node。

這裡要注意，剛開始你可能會找不到 N1、N2 或 E2 的主機，你要先把 Disk 改成 Standard 的，這幾個型號就會出現了。

一樣的做法再設定 Worker Node。

在 IP 的部分，原本 「Internal IP only」是有勾選的，要把它取消喔，

如果只有內部 IP，是不容易從部外連進去的，

它會先勾選，我想是為了安全性的問題，怕任何人都可以連到 Dataproc，

但我們是初學者，玩一下就會馬上把它刪掉(記得喔)，所以沒關係！

接下來等大概五分鐘左右，它就準備好了。

同時你也可以在 Compute Engine 頁面上看到真的有機器開出來，一台 Master Node，兩台 Worker Node。

接下來有兩種操作場景。

第一種是直接連到 Dataproc Master Node 的 Command Line

(本部份取自網路上的 YouTube 影片：GCP Dataproc Cluster creation | HDFS and Hive)

先 SSH 連到 Master Node，然後上傳一個要分析的檔案。

進入 Hive 建立資料庫名叫 “vehicle”。

建立表格 “vehicle_sold”，並查詢表格結構。

接下來使用語法來查詢資料，看到能正常顯示剛上傳的資料。

你會在上半部看到效能數據，如果資料量很大，可以查看是否需要調整主機規格來優化效能。

其中 Map 1 是什麼意思？

“1” 是第一階段，Map 是映射任務，資料被分割成多個小塊，每個小塊由一個 Map 任務處理。

把資料轉成 key-value 格式，例如 (Venue, 302), (Ertiga, 123)。

最後來下一個加總語法，查詢各類汽車銷售數量。

“Reducer2” 是第二階段 – 歸納任務，Reducer 接收 Map 任務輸出的 key-value，然後將相同 key 的 value 合併。

例如相同 Creta 的 336 和 265 加總起來為 601。

以上是第一種使用場景，就是讓你可以用下指令的方式，跟 Dataproc 互動操作。

第二種場景是提交你寫好的 Job 程式碼給 Dataproc 自動執行

(本部分是我操作 Skillboost Lab：Dataproc: Qwik Start – Console 的截圖)

接下來去 Jobs，我們要準備提交一個 Job。

在這個 Lab 我們要用一支程式去計算圓周率，所以要引入一個 org.apache.spark.examples.SparkPi 這個 Class，

然後再給它執行 Job 細節的程式碼檔案：file:///usr/lib/spark/examples/jars/spark-examples.jar

這個程式使用蒙地卡羅方法（Monte Carlo Method）來估算圓周率（Pi）的值，

參數 1000 代表程式將生成的 x,y 座標點對的數量，生成的點對越多，估算的圓周率值就越精確。

所以，當你在 Arguments 欄位中輸入 1000 時，您實際上是在告訴 SparkPi 程式生成 1000 個隨機點來估算 Pi 值。

如果您輸入更大的數字（例如 10000 或 100000），估算會更精確，但計算時間也會更長。

最後我們會在 Job Details 看到它算出來的圓周率，你會看到它有點不準。

我們記得 Pi 是 3.1415926……，但它算出來竟然是 3.14193…….

因為它只算 1000 個點，所以沒那麼準，如果算更多個點，一定比我們記憶的還準。

Dataproc 和 Dataflow 很像？到底有何差異？

當你在 Dataproc 上執行 Spark Job 時，確實會有一些操作方式上的相似點：

• 兩者都能執行預先編譯好的程式（JAR 檔案、Python 腳本等）
• 兩者都能處理批次和串流資料
• 兩者都能自動分散工作負載到多個節點

但根本差異仍然存在。

Dataproc 執行 Spark 程式時：

• 你要先建立和維護 Dataproc Cluster
• 使用 gcloud dataproc jobs submit spark 或通過 Web UI 提交 JAR 檔
• Spark 程式會在你開好的 Cluster 上執行
• 叢集資源是固定的（除非手動調整）
• 叢集在任務完成後繼續存在（除非配置為自動刪除）

Dataflow 執行 Apache Beam 程式時：

• 不用預先建立 Cluster
• 提交程式後，Dataflow 會自動建立和管理執行環境
• 資源會根據工作負載 Autoscale
• 任務完成後，所有資源會自動釋放 (刪除 Cluster)

簡言之，Dataproc 執行 Spark 程式時，你仍需管理基礎架構 (Cluster)，而 Dataflow 則完全幫你管理這一層面。

這就是為什麼在某些使用案例中，兩者看起來很相似，

都是提交預先寫好的程式來處理資料，但底層的資源管理和架構哲學是不同的。

Dataproc 和 Dataflow 比較表

工作流程範本 Dataproc Workflow Template

自動化任務排程的關鍵利器

Workflow Templates 用來設定和管理一系列相依的 Dataproc 作業 (Job)，

例如 A Job 必須完成之後，再開始 B Job。

就像食譜，你只需設定好步驟與材料，系統會自動幫你依序完成資料處理任務。

注意建立範本後，Dataproc 不會建立 Cluster 或開始運作。只有在建立機器後才會開始工作。

工作流程範本的種類

代管叢集 Managed Cluster

當你手上沒有運作中的 Cluster，工作流程會建立一個「臨時」Cluster 來運行作業，完成時刪除該 Cluster。

叢集選擇器 Cluster Selector

當你手上有幾個運作中的 Cluster，你可以下標籤來指定做事的 Cluster，有點像 Kubernetes 那種管理方法。

每個 Cluster 都可以設標籤，是 key-value 的結構，例如你有 3 個 Cluster：

cluster-1 的標籤  analytics=ig

cluster-2 的標籤  analytics=fb

cluster-3 的標籤  web=click

你指定 analytics=fb，cluster-2 就會開始做事。

它會選具有完全相同標籤的 cluster 來工作，而且會找具有最多 YARN 可用記憶體的叢集來運行所有工作流程作業。

但工作完，Cluster 會持續存在，不會把你的 Cluster 刪掉。

Dataproc 與其他 GCP 工具整合

結合 BigQuery 快速查詢分析結果

Dataproc 可以使用 BigQuery 連接器在 Spark 或 Hadoop 作業中直接讀寫 BigQuery 資料。

處理完的結果可直接匯入 BigQuery，進行後續報表分析與視覺化。

如果經常使用 Dataproc、Cloud Storage 和 BigQuery，建議使用 Avro 格式的資料，因為完全相容。

與 Cloud Storage 無縫資料串接

傳統上 Hadoop 用 HDFS 在資料的永久儲存，確保資料在系統關閉或重啟後仍然存在。

在 Dataproc 上使用 Cloud Storage 連接器時，可以讓 Dataproc 直接讀寫儲存在 Cloud Storage 上的資料，

無需使用 HDFS。(因為 Dataproc 通常用完就會刪掉環境，上面的 Disk 跟著刪除)

而且 GCS 還比 Disk 便宜。

你可以再搭配 GCS 的物件生命週期管理 Object Lifecycle，有效控管儲存成本。

成本管理與效能最佳化技巧

如何利用預留節點與自動關機功能省錢

使用 Preemptible VM（可搶占節點）節省 80% 成本，但這種主機可能隨時被終止。

建議你用在容錯性高的批次處理工作（可以隨時停下來、即使失敗也可以重試、有備份機制），

也就是「不緊急不重要的工作」。

建議搭配重試機制和優雅停用 (Graceful Decommissioning) 設定，確保正在進行的工作在節點移除前完成。

使用 Cloud Logging 監控資源與效能

透過指標追蹤 CPU、Memory 使用率，找出瓶頸，優化叢集配置。

Dataproc 常見錯誤與排除方式

排查任務失敗的三個關鍵檢查點

• 驗證 Cluster 資源是否足夠，像記憶體是不是快爆了。
• 檢查程式碼是否有錯誤。
• 檢查輸入資料路徑是否正確。

如何讀懂 Job Logs 與錯誤訊息

進入 Job Logs，根據錯誤訊息回推失敗原因，例如記憶體不足、格式錯誤、路徑遺失等。

你也可以直接錯誤的 Log 拿去問 ChatGPT。

適合導入 Dataproc 的企業情境

金融業：批次風險模型計算

金融機構常需夜間批次執行大量風控模型，Dataproc 正好適合這種短時高負載任務。

零售業：銷售資料彙總與推薦引擎訓練

從 POS 資料中彙總趨勢、訓練推薦模型，Dataproc 可有效協助行銷與庫存預測。

當然，可以做批次處理的工具都可以，像上面提到的 Dataflow，取決於你對哪個比較熟悉。

結語：Dataproc 是否適合你的團隊？

如果你的團隊正在處理大量資料，需要彈性資源、自動化流程，

或正從傳統平台轉型到雲端，那麼 Dataproc 將會是你強而有力的幫手。

它不只是工具，更是未來資料基礎建設的基石。

常見問答（FAQ）

Q1：Dataproc 可以不寫程式嗎？
A：可以透過 Workflow Template 搭配 SQL、Hive 指令，降低程式依賴。（所以還是要拿下指令）

真的要不寫程式，可以考慮用 Dataprep，它是互動式並且視覺化的操作界面，可以設定資料處理規則讓它自動執行。

Q2：Dataproc 和 BigQuery 哪個適合分析？
A：BigQuery 適合即時分析，Dataproc 則擅長處理大量轉換、清洗、模型訓練等流程，Dataproc 的分析，主要是拿來探索用的，就是讓你大概看一下資料長怎樣，不方便做大規模而且複雜的分析。

Q3：有支援 GPU 計算嗎？
A：有，可以在 Worker 節點指定使用 GPU 運算資源。

Q4：Dataproc 支援 Python 嗎？
A：完全支援，Spark 任務可用 PySpark 寫成，也可整合 Notebook 開發環境。

Q5：部署後多久能用？
A：幾分鐘內即可建立好叢集，立即上線處理任務。

The post Dataproc 是什麼？四大優勢與使用方法介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.