Google 數位人才探索計畫

Google Cloud 學程總整課程

Denny Huang

2026/06/25

Denny Huang

https://denny.one/20260625-digital-education-google-cloud/

今天要完成的學習旅程

理解雲端責任與架構
        ↓
以程式碼建立基礎設施
        ↓
驗證服務是否真的可用
        ↓
利用觀測資料理解系統
        ↓
將資料轉化成可回答的問題
        ↓
使用 Data Canvas 設計查詢與視覺化
        ↓
驗證答案並管理風險

這堂課的三個目標

建立

把雲端架構從抽象概念，轉成可重複建立的環境。

理解

從 Metrics、Logs、Traces 與分析資料看懂系統發生什麼事。

判斷

在架構、資料、AI、安全、成本與責任之間做出合理取捨。

課程地圖

階段 我們要回答的問題
Cloud Foundations 雲端如何分配控制權與責任？
Infrastructure as Code 如何可靠地建立與重建環境？
Operations & Observability 建立成功後，如何知道服務真的正常？
Data & BigQuery 資料如何從原始紀錄變成可信任的分析？
Data Canvas 如何用視覺化流程設計查詢、圖表與協作？
Responsible AI 如何控制權限、成本、品質與風險？

暖身：你會怎麼判斷？

請先快速回答：

  1. IaaS、PaaS、SaaS 的差異主要是什麼？
  2. BigQuery 適合拿來做什麼類型的工作？
  3. 好的 Prompt 通常需要包含哪些資訊？
  4. Budget Alert 達到門檻時，是否會預設自動停止所有支出？

先保留你的答案，課程後面會逐步回到這些問題。

Part 1｜Cloud Foundations

先建立一套可貫穿整堂課的雲端心智模型

雲端改變的，不只是伺服器位置

傳統環境常見流程：

預估需求 → 採購硬體 → 安裝與設定 → 部署

雲端環境則可以：

宣告需求 → 呼叫 API → 建立資源 → 量測 → 調整 → 清理

真正的轉變包括：

  • 資源可以被程式化
  • 建立速度加快
  • 規模可以動態調整
  • 成本從一次採購變成持續治理
  • 營運責任必須被持續管理

雲端提供能力，不保證結果

常見誤解

  • 上雲一定比較便宜
  • 雲端一定比較安全
  • 受管服務不需要營運
  • 流量增加時系統會自然變快

真正需要的條件

  • 正確的架構
  • 合理的權限與設定
  • 可觀測性與事件處理
  • 成本與容量治理
  • 定期驗證備援與復原
  • 團隊流程與責任分工

IaaS、PaaS、SaaS：控制權與責任的光譜

模型 你取得什麼 你主要管理什麼 例子
IaaS 運算、網路、儲存 OS、Runtime、應用、資料 Compute Engine
PaaS 受管執行環境 應用、設定、資料 App Engine、Cloud Run
SaaS 完整可使用的應用 帳號、內容、使用政策 Google Workspace

越接近 IaaS，控制越多；越接近 SaaS，底層營運工作越少。

沒有永遠最好的服務模型

選擇時要問：

  • 是否需要完整 OS 控制？
  • 是否依賴特殊 Runtime 或系統套件？
  • 團隊有多少維運能力？
  • 上線速度有多重要？
  • 是否需要高度可攜性？
  • 是否能接受平台限制？
  • 安全與法遵需要控制到哪一層？

合適的服務模型，是在控制、速度、成本與責任之間取得平衡。

Shared Responsibility：責任不是消失，而是重新分配

雲端供應商通常負責

  • 實體資料中心
  • 基礎硬體
  • 底層網路與平台
  • 服務本身的安全與可用性

使用者通常仍負責

  • 身分與帳號
  • IAM 與設定
  • 應用程式
  • 資料與機密資訊
  • 使用目的與合規
  • 監控與事件回應

Security of the cloud / in the cloud

Security of the cloud

雲端供應商如何保護：

  • 資料中心
  • 硬體
  • 基礎網路
  • 平台服務

Security in the cloud

我們如何保護：

  • 帳號與身分
  • 權限設定
  • 應用與資料
  • 日誌與事件

使用雲端不代表把風險全部交出去。

Google Cloud 的資源層級

Organization
└── Folder
    └── Project
        └── Resource
  • Organization：整個組織的管理根
  • Folder：依部門、產品、環境或政策分群
  • Project：API、帳務、配額與 IAM 的重要邊界
  • Resource：VM、Bucket、Dataset、Service 等實體資源

資源層級的真正價值

它影響：

  • 政策能否一致套用
  • 權限能否由上往下管理
  • 開發、測試、正式環境如何隔離
  • 成本如何分攤
  • 事件發生時如何確認影響範圍
  • 誰能建立、修改與刪除資源

資源層級是治理模型，不只是畫面上的資料夾。

IAM 回答三個問題

Who can do what on which resource?

  • Who：使用者、群組、Service Account、工作負載身分
  • What：Role 內的一組 Permission
  • Which resource：Organization、Folder、Project 或個別資源
Principal + Role + Resource
         = IAM Policy Binding

最小權限不是「什麼都不給」

最小權限（Least Privilege）代表：

  • 只給完成工作所需的權限
  • 只給需要的資源範圍
  • 只在需要的時間有效
  • 定期回收不再需要的權限

常見危險做法：

  • 為了方便，把所有人設為 Owner
  • 把長期金鑰寫進程式碼
  • 多個系統共用同一個 Service Account
  • 人員離開後未撤銷權限

Service Account 代表工作負載身分

Application
   ↓ uses
Service Account
   ↓ has
Required Roles
   ↓ accesses
Google Cloud Resources

好的設計：

  • 每個工作負載使用合適身分
  • 避免長期靜態金鑰
  • 權限可追蹤、可撤銷、可稽核
  • 人類身分與程式身分分開管理

VPC：雲端網路的邏輯邊界

VPC 用來定義：

  • 私有 IP 位址空間
  • 子網路（Subnet）
  • 路由（Route）
  • 防火牆規則（Firewall rule）
  • 與其他網路的連線方式

Google Cloud 中：

  • VPC Network 是全域資源
  • Subnet 屬於特定 Region
  • 是否能互通，取決於路由、防火牆、服務設定與身分

網路可達，不代表應用可用

排查連線問題時，可以依序問：

  1. DNS 是否解析到正確位置？
  2. 是否有可用路由？
  3. 防火牆是否允許？
  4. 服務是否正在監聽？
  5. 應用是否要求驗證？
  6. 身分是否有權使用服務？
  7. TLS 與憑證是否有效？

網路、應用與身分是不同層次的控制。

Compute、Storage 與 Database：依工作負載選擇

需求 可優先評估
完整 OS 控制 Compute Engine
容器編排與複雜平台 Google Kubernetes Engine
無狀態 Web/API，減少維運 Cloud Run
檔案、媒體、備份 Cloud Storage
關聯式交易 Cloud SQL
大規模分析 BigQuery

產品名稱只是結果；需求、存取模式與責任才是選擇依據。

Part 1 重點

  • IaaS、PaaS、SaaS 代表不同的控制程度與責任邊界。
  • 雲端供應商與使用者依服務模型分擔責任。
  • Organization、Folder、Project、Resource 形成治理層級。
  • VPC 管理網路；IAM 管理身分與權限。
  • 權限應遵循最小權限原則。
  • 上雲不會自動解決成本、安全與可靠性問題。

Part 2｜Infrastructure as Code

用 Terraform 把雲端架構變成可重複、可審查的程式碼

Lab GSP089：我們要建立什麼？

Internet
   ↓ HTTP :80
Firewall Rule
   ↓
Compute Engine VM
   ├─ Debian
   ├─ Apache
   └─ Google Cloud Ops Agent
              ↓
       Monitoring / Logging

同時建立：

  • Uptime Check
  • Alert Policy
  • Monitoring Dashboard
  • CPU Load 與 Received Packets 圖表

為什麼不全部用 Console 手動建立？

若 50 個人都要建立相同環境，容易出現：

  • 步驟遺漏
  • 設定不一致
  • 難以審查
  • 難以重建
  • 不知道誰修改了什麼
  • 資源忘記清理
  • 錯誤只能靠人工比對

Infrastructure as Code 讓環境變成：

可版本控制、可比較、可重複、可自動化的描述。

Terraform 的核心概念

概念 作用
Provider 告訴 Terraform 要操作哪個平台
Resource 建立或管理的雲端物件
Data Source 讀取已存在的資源或資訊
Variable 將環境輸入與程式碼分離
Output 將建立後的結果輸出
State 記錄 Terraform 管理哪些資源

Terraform 採用宣告式思維：描述希望環境最後長什麼樣子。

專案檔案地圖

versions.tf
  工具版本、Google Provider、Project / Region / Zone

variables.tf
  project_id、region、zone、vm_name、machine_type

main.tf
  Network、Firewall、VM、Startup Script、Ops Agent

monitoring.tf
  Uptime Check、Alert Policy、Dashboard

outputs.tf
  VM IP、Apache URL、Monitoring 資源名稱

先讀 versions.tf

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

觀察：

  • Terraform 與 Provider 都有版本
  • 環境資訊來自 Variable
  • 程式碼與每次 Lab 的 Project ID 分離

再讀 variables.tf

變數解決的問題：

  • 每次 Lab 的 Project ID 不同
  • Region 與 Zone 可以調整
  • VM 名稱與規格集中管理
  • 設定不必散落在所有檔案中
variable "machine_type" {
  type    = string
  default = "e2-medium"
}

不要把環境差異直接寫死在每個 Resource 中。

main.tf：把架構轉成資源

data "google_compute_network" "default" {
  name = "default"
}

Data Source：

  • 不建立新的 VPC
  • 讀取已存在的 Default Network
  • 讓後續 Resource 引用它

main.tf：防火牆規則

resource "google_compute_firewall" "allow_http" {
  direction = "INGRESS"

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["http-server"]
}

觀察：

  • 允許外部 HTTP 流量
  • 只套用到具有 http-server Tag 的 VM
  • Lab 為了方便測試而開放所有來源

main.tf：Compute Engine VM

resource "google_compute_instance" "lamp" {
  name         = var.vm_name
  machine_type = var.machine_type
  zone         = var.zone

  tags = ["http-server"]

  network_interface {
    network = data.google_compute_network.default.self_link
    access_config {}
  }
}

這段將 Project、Zone、Compute、VPC、External IP 與 Network Tag 串在一起。

Startup Script：資源建立後自動設定

VM 啟動時會自動：

  • 更新套件清單
  • 安裝 Apache 與 PHP
  • 啟用 Apache
  • 安裝 Google Cloud Ops Agent
  • 將執行紀錄寫入 Log
VM exists ≠ Application is ready

建立 VM 與成功啟動應用，是兩個不同階段。

monitoring.tf：系統上線後仍需回答問題

Terraform 會建立：

  • Uptime Check：服務從外部是否可達
  • Notification Channel：告警送到哪裡
  • Alert Policy：什麼狀況需要介入
  • Dashboard：系統狀態如何隨時間變化

Infrastructure as Code 不只建立主機，也可以建立營運能力。

Terraform 的執行生命週期

terraform init
      ↓
terraform plan
      ↓
terraform apply
      ↓
terraform output
      ↓
terraform destroy

每一步都回答不同問題。

terraform init

用途：

  • 初始化目前工作目錄
  • 下載需要的 Provider
  • 準備 Terraform 後續執行環境

它不會：

  • 建立 VM
  • 修改防火牆
  • 部署應用

terraform plan

Terraform 會比較：

Configuration
+ Variables
+ State
+ Real Infrastructure
        ↓
Change Plan

Plan 可能包含：

  • + 新增
  • ~ 修改
  • - 刪除
  • -/+ 重新建立

Plan 的價值是先看懂 Terraform 準備做什麼。

terraform apply

Apply 會：

  • 顯示即將套用的變更
  • 經確認後呼叫 Google Cloud API
  • 建立或更新資源
  • 更新 Terraform State

執行前應確認：

  • Project 是否正確
  • Region／Zone 是否正確
  • 預計建立與刪除的資源是否合理

terraform output

Output 將建立結果交給人員或後續流程：

terraform output apache_url

例如：

  • Project ID
  • VM 名稱
  • External IP
  • Apache URL
  • Uptime Check 名稱
  • Dashboard 名稱

terraform destroy

Destroy 會依據 State：

  • 找出這份設定管理的資源
  • 顯示刪除計畫
  • 經確認後進行清理
  • 更新 State

清理也是系統生命週期的一部分，不是 Lab 結束後才想到的雜務。

Lab 操作：準備環境

gcloud auth list
gcloud config list project
terraform version

確認：

  • 使用的是 Lab 提供的帳號
  • 目前 Project 正確
  • Terraform 已安裝

接著：

git clone https://github.com/denny0223/GSP089-Terraform.git
cd GSP089-Terraform

Lab 操作：設定環境變數

REGION="請改成本次 lab 指定的 region，例如 us-central1"
ZONE="請改成本次 lab 指定的 zone，例如 us-central1-b"

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

PROJECT_ID="$(gcloud config get-value project)"

cat > terraform.tfvars <<EOF
project_id   = "${PROJECT_ID}"
region       = "${REGION}"
zone         = "${ZONE}"
vm_name      = "lamp-1-vm"
machine_type = "e2-medium"
alert_email  = ""
EOF

Terraform 會從 terraform.tfvars 讀取本次 Lab 的環境值。

Lab 操作：執行 Terraform

terraform init
terraform plan
terraform apply

在輸入 yes 前，先觀察：

  • 預計建立多少 Resource
  • 是否有任何刪除
  • VM、Firewall、Monitoring Resource 是否都在 Plan 中
  • Project、Region、Zone 是否正確

Lab 操作：驗證結果

依序檢查：

  1. Terraform 是否成功
  2. VM 是否存在
  3. Apache 是否啟動
  4. 網站是否可連線
  5. Ops Agent 是否運作
  6. Uptime Check 是否建立
  7. Alert Policy 是否建立
  8. Dashboard 是否建立
  9. Lab Progress Check 是否通過

Apply 成功，但網站打不開？

依序檢查：

  • External IP 是否存在
  • Firewall 是否允許 TCP 80
  • VM 是否有 http-server Tag
  • Startup Script 是否完成
  • Apache 是否啟動
  • 是否正在使用正確 Project 與 Zone

Apply 成功代表資源建立流程完成，不代表使用者已能正常使用服務。

Terraform Lab：帶走的觀念

  • 雲端資源可以被程式碼描述。
  • 宣告式設定描述 Desired State。
  • Plan 用來預覽差異；Apply 才真正修改環境。
  • State 讓 Terraform 知道自己管理哪些資源。
  • 自動化能複製正確設定，也能快速複製錯誤設定。
  • 資源建立成功後，仍需要驗證與觀測。

Part 3｜Operations & Observability

系統上線後，真正的營運責任才開始

三種不同的「成功」

Resource Created
        ↓
Application Running
        ↓
User Can Use the Service
  • VM 存在，不代表 Apache 已啟動
  • Apache 已啟動，不代表網路可達
  • 網路可達，不代表服務品質符合期待

每一層都需要不同的驗證方法。

Uptime Check、Dashboard、Alert 各自回答什麼？

元件 問題
Uptime Check 從外部看，服務是否可用？
Metric 數值與趨勢如何變化？
Dashboard 如何快速觀察一組重要訊號？
Alert Policy 哪個狀態需要人員介入？
Incident 哪次告警事件正在發生或曾經發生？

Metrics、Logs、Traces

Metrics

  • 數值
  • 趨勢
  • 聚合
  • 告警

回答：多少？多快？多久？

Logs

  • 事件
  • 錯誤
  • 文字上下文
  • 稽核紀錄

回答：發生了什麼？

Traces

  • 單次請求路徑
  • 父子 Span
  • 各步驟耗時

回答：這一次為什麼慢？

OpenTelemetry 示範情境

Route Status 預期觀察
/ 200 快速且正常
/api/status 200 有後端檢查，延遲中等
/checkout 200 Inventory／Payment 步驟較慢
/checkout 500 模擬 Inventory Timeout

觀察：

  • Request Counter
  • Error Counter
  • Latency Histogram
  • Parent／Child Spans

從 Metrics 到 Trace

Metrics
發現 /checkout 延遲上升
        ↓
Logs
找到錯誤與事件上下文
        ↓
Trace
發現時間花在 query_inventory

不同訊號不是競爭關係，而是互相補充。

SRE：以工程方法管理可靠性

Site Reliability Engineering 強調：

  • 定義使用者真正關心的可靠性
  • 透過自動化降低重複工作
  • 讓系統狀態可以被觀測
  • 在變更速度與穩定性之間取得平衡
  • 從事故中持續改善

可靠性是一項產品能力，不是「永遠不能出錯」的口號。

SLI、SLO、SLA

名稱 意義 例子
SLI 實際量測的服務指標 成功請求比例、延遲
SLO 團隊設定的可靠性目標 30 天內 99.9% 成功
SLA 對外承諾與可能的補償 未達標準時的商業條款

先定義使用者期待，再決定要量測什麼。

成本治理是持續循環

看見成本
   ↓
分配責任
   ↓
設定預算與警示
   ↓
找出異常與閒置
   ↓
調整規格與架構
   ↓
驗證效果

成本最佳化不是月底看一次帳單，也不是一律選最便宜的產品。

Budget Alert 不等於硬性支出上限

Cloud Billing Budget 可以：

  • 設定預算金額
  • 追蹤實際與預估支出
  • 在達到門檻時通知
  • 搭配自動化流程

但在預設設定下：

Budget Alert 會通知，不會自動停止所有資源與支出。

合理的成本最佳化

應同時考量

  • 工作負載規模與 Right-sizing
  • 自動擴縮與閒置資源
  • 儲存分層與執行時間
  • 可靠性與可觀測性
  • 工程與維運成本

危險做法

  • 關閉所有 Logs 只為省錢
  • 把容量壓到沒有任何緩衝
  • 只看單價，不看整體營運成本

Part 3 重點

  • 資源存在、應用運作與使用者可用，是不同層次。
  • Uptime Check、Dashboard 與 Alert 解決不同問題。
  • Metrics、Logs、Traces 提供互補的觀測訊號。
  • SRE 以工程與自動化提升可靠性與營運效率。
  • Budget Alert 用來追蹤與通知，不是硬性支出上限。
  • 成本最佳化必須平衡可靠性、品質與營運需求。

中場休息

回來後：從系統資料走向分析、視覺化與生成式 AI

Part 4｜Data & BigQuery

資料不是被儲存就會自動產生價值

從資料到決策

事件與業務活動
      ↓
資料蒐集
      ↓
清理、整合、轉換
      ↓
分析與建模
      ↓
洞察
      ↓
決策與行動
      ↓
產生新的事件與資料

若資料品質、定義或治理有問題，這個迴路會把錯誤放大。

數位轉型不是把舊系統搬上雲端

只做搬遷：

  • 基礎設施位置改變
  • 流程與決策方式可能完全不變

真正的轉型：

  • 縮短從想法到驗證的時間
  • 建立資料驅動的回饋迴路
  • 改變跨部門合作方式
  • 提升使用者體驗
  • 讓系統可以持續演進
  • 同時治理安全、可靠性與成本

資料型態會影響技術選擇

類型 例子 常見特性
結構化 訂單表、會員表 Schema 明確，適合 SQL
半結構化 JSON、事件紀錄 有結構但可能變動
非結構化 圖片、音訊、PDF 無固定表格結構

選擇時還要問：

  • 如何讀寫？
  • 是否需要交易一致性？
  • 延遲與規模要求？
  • 保留多久？
  • 誰能存取？
  • 如何分析？

儲存服務不能只看「資料很大」

需求 可優先評估
檔案、圖片、備份、物件資料 Cloud Storage
關聯式交易與應用查詢 Cloud SQL
文件型應用資料 Firestore
大規模低延遲寬欄資料 Bigtable
大規模 SQL 分析與資料倉儲 BigQuery

資料量只是其中一個條件；存取模式與工作負載更重要。

Data Transformation：讓資料變得可用

資料轉換可能包含：

  • 格式標準化
  • 欄位清理與型別轉換
  • 去除重複與錯誤
  • 合併不同來源
  • 建立業務定義
  • 建立衍生指標
  • 匿名化或遮罩敏感資訊
  • 為分析與模型建立特徵

原始資料是系統留下的觀測，不一定等於可直接使用的真相。

ETL 與 ELT

ETL

Extract → Transform → Load

先轉換，再載入目標系統。

ELT

Extract → Load → Transform

先載入分析平台，再利用平台能力轉換。

選擇依據：

  • 資料量
  • 延遲
  • 治理要求
  • 轉換能力
  • 平台成本
  • 團隊流程

BigQuery 的角色

BigQuery 適合：

  • 大規模 SQL 分析
  • 資料倉儲
  • 儀表板與報表
  • 跨來源資料整合
  • 分群、聚合與趨勢分析
  • BigQuery ML 與 AI 分析能力

BigQuery 不是：

  • 所有應用的主要交易資料庫
  • 所有檔案的通用儲存空間
  • 不需要成本與權限治理的無限查詢工具

Schema、Metadata、Business Semantics

Schema
score 是 INTEGER
        ↓
Metadata
score 代表某搜尋詞的相對熱度
        ↓
Business Semantics
score 只能比較同一個 term 在不同時間的變化，
不能直接比較不同 term 的大小

欄位型別正確，不代表分析方式一定正確。

認識 BigQuery Data Canvas

BigQuery Data Canvas 是 BigQuery 中的視覺化分析介面，適合：

  • 用自然語言搜尋資料表
  • 在畫布上串接資料來源
  • 透過 Prompt 產生與調整 SQL
  • 建立圖表與產生摘要
  • 儲存、分享分析流程
  • 將分析流程匯出為 Notebook

它的價值不是取代資料分析能力，而是降低探索、視覺化與協作的門檻。

Data Canvas 與傳統 SQL 的關係

傳統 SQL

  • 清楚、可版本化
  • 適合正式查詢
  • 需要撰寫能力
  • 可精確控制邏輯

Data Canvas

  • 視覺化工作流
  • 可用自然語言輔助
  • 適合探索與協作
  • 仍應檢查產生的 SQL

Data Canvas 讓探索更容易，但不代表可以跳過驗證。

使用生成式 AI 產生 SQL 時

應持續檢查：

  • 是否查詢正確資料表
  • Join 條件是否合理
  • 是否不必要地使用 SELECT *
  • Filter 是否符合問題
  • Grouping 與排序是否正確
  • 是否限制了不該限制的筆數
  • 查詢成本是否可接受
  • 回答是否真的由查詢結果支持

Part 4 重點

  • 資料型態會影響儲存、處理與分析方式。
  • Data Transformation 能改善資料品質、可用性與分析價值。
  • BigQuery 是大規模 SQL 分析與資料倉儲服務。
  • Schema 不等於 Metadata；Metadata 也不等於 Business Semantics。
  • Data Canvas 可以協助視覺化查詢設計、圖表建立與團隊協作。
  • 自然語言分析仍需驗證、權限與成本治理。

Part 5｜BigQuery Data Canvas Lab

用視覺化流程設計查詢、圖表與協作

Lab GSP1259 情境：Data Beans 與 Coffee on Wheels

你是 Data Beans 的資料分析師，正在帶領新進分析師熟悉資料。

團隊已經會使用 Gemini 協助產生 SQL 與洞察，但現在需要更好的協作工具：

  • 可以視覺化資料探索流程
  • 可以設計更複雜的查詢
  • 可以 Join 多張表
  • 可以建立圖表
  • 可以分享分析流程給其他人

這就是 Data Canvas 要解決的問題。

Lab 目標

在本 Lab 中，我們會使用 Data Canvas：

  1. Join menu、orders、order_items 三張表
  2. 計算 2024 年所有菜單品項的總營收
  3. 建立營收前 10 名品項的長條圖
  4. 找出兩個產生相同營收的菜單品項
  5. 儲存、分享 Data Canvas，並匯出為 Notebook

Data Canvas 的工作方式

Find data
   ↓
Join tables
   ↓
Query these results
   ↓
Visualize
   ↓
Generate insights
   ↓
Save / Share / Export

每個節點代表一段可檢查、可延伸、可分享的分析流程。

Task 1：找到資料表

在 BigQuery Data Canvas 中：

  1. 建立新的 Data Canvas
  2. 選擇 Region
  3. 使用搜尋框輸入：
coffee on wheels

預期看到四張表：

  • location
  • menu
  • orders
  • order_items

本 Lab 主要使用 menu、orders、order_items。

Task 1：Join 三張表

選取：

  • menu
  • orders
  • order_items

點選 Join 後，Data Canvas 會建立視覺化 Join 節點，並自動產生初步 SQL。

初步查詢可能只是把表格放在一起，或使用 SELECT *。

這時要先觀察：

  • Join 是否真的完成？
  • Join key 是否合理？
  • 查詢是否只回傳少量樣本？
  • 欄位是否過多、難以閱讀？

改善 Join Prompt

初步查詢常見問題：

  • 使用 SELECT *
  • Alias 不清楚
  • 欄位過多
  • 可讀性不足

可以要求：

Join these data sources without using * and use descriptive table aliases

目標是產生更可讀、可驗證、適合後續分析的 SQL。

Task 1：觀察結果

執行 Join 後，確認結果包含後續分析需要的欄位：

  • item_name
  • item_price
  • item_size
  • order_datetime
  • item_total
  • quantity
  • menu_id
  • order_id

Join 的重點不是「有結果」，而是確認資料是否真的可支援下一個問題。

Task 2：計算 2024 年總營收

在 Join 結果下方選擇 Query these results。

Prompt 範例：

From the joined table, only consider orders from 2024.
Calculate the total revenue for each menu item.
Display menu_id, item_name, item_size, and total_revenue.
Round total_revenue to two decimal places.
Order results by total_revenue descending.

Task 2：檢查產生的 SQL

應觀察查詢是否包含：

  • 使用 order_datetime 篩選 2024 年
  • 依 menu_id、item_name、item_size 分組
  • 使用 SUM(item_total) 計算營收
  • 使用 ROUND(..., 2) 保留兩位小數
  • 依 total_revenue 由高到低排序

生成式 AI 幫忙產生 SQL，但資料分析師仍需判斷邏輯是否正確。

Task 2：反思

請觀察結果並回答：

  • 營收最高的商品是哪一項？
  • 排名第二的商品是什麼？
  • 是否有 item_size？
  • 如果兩個商品名稱相同但尺寸不同，應該合併還是拆開？

這些問題會影響後續圖表與解讀。

Task 3：找出前 10 名

在總營收結果下方選擇 Query these results。

Prompt 範例：

Identify the top 10 items by total revenue.
Include menu_id, item_name, item_size, and total_revenue.

觀察：

  • 是否使用 ORDER BY total_revenue DESC
  • 是否使用 LIMIT 10
  • 是否保留圖表需要的欄位

Task 3：建立長條圖

選擇 Visualize → Bar。

初始圖表可能不完全符合需求，接著用 Prompt 調整：

Create a vertical bar chart displaying total revenue.
Include item name on the x-axis and total revenue on the y-axis.
Start with the highest revenue.
Stack the results by item size.

觀察：

  • 是否依總營收排序
  • 是否以 item_size 區分顏色
  • 圖表是否容易被非技術角色理解

Task 3：Generate Insights

Data Canvas 可以對圖表產生摘要。

使用時請檢查：

  • 摘要是否和圖表一致
  • 排名是否和查詢結果一致
  • 是否把尺寸或品項解讀錯誤
  • 是否將視覺化的聚合結果誤解為原始資料

圖表摘要能加快理解，但最終仍需要人工驗證。

Task 4：找出相同營收的品項

回到總營收結果節點，選擇 Query these results。

Prompt 範例：

Find two items with the same total revenue.
Display item names, item size, and total revenue.
Limit your response to only two items.

觀察：

  • 是否用子查詢找出重複的 total_revenue
  • 是否只回傳兩筆
  • 兩筆營收是否真的相同
  • 是否需要進一步解釋為什麼相同

Task 4：這題在練什麼？

這不是只為了找出兩筆資料。

它在練習：

  • 用自然語言描述條件
  • 讓 AI 產生較複雜的 SQL
  • 檢查子查詢邏輯
  • 驗證結果是否真的符合條件
  • 思考資料規則是否需要補充說明

AI 產生查詢後，驗證仍是分析流程的一部分。

Task 5：儲存 Data Canvas

完成分析後，將 Data Canvas 儲存為：

Two items with same total revenue

觀察：

  • Data Canvas 是否出現在 Shared data canvases
  • 名稱是否清楚表達分析目的
  • 後續是否能讓其他人理解流程

好的分析成果不只是一張圖，而是一條可被追蹤的分析路徑。

Task 5：匯出為 Notebook

Data Canvas 可將查詢匯出為 Notebook。

用途：

  • 保留分析流程
  • 讓資料分析師進一步修改
  • 與更進階的資料處理流程整合
  • 方便重現查詢步驟
  • 作為團隊交接文件

視覺化探索與可重現分析可以互相補充。

Task 5：分享與權限

Lab 會使用兩個不同使用者檢查 Data Canvas 分享。

你會觀察：

  • Owner 擁有哪些角色
  • 另一位使用者擁有哪些角色
  • 誰能開啟 Data Canvas
  • 誰能匯出 Notebook
  • 權限不足時會有哪些限制

分享分析成果時，IAM 仍然是資料安全的基礎。

Data Canvas Lab：帶走的觀念

  • Data Canvas 讓資料探索變成視覺化流程。
  • 自然語言可以協助搜尋資料、產生 SQL、建立圖表。
  • 產生的 SQL 與摘要仍需要人工檢查。
  • 圖表能幫助溝通，但必須理解底層聚合邏輯。
  • 儲存、分享與匯出讓分析流程可以協作。
  • IAM 決定誰能檢視、修改與延伸分析成果。

Part 6｜AI, Generative AI & Responsible AI

模型只是完整應用系統中的一部分

AI、ML、Foundation Model 與 Generative AI

Artificial Intelligence
└── Machine Learning
    └── Deep Learning
        └── Foundation Models
            └── Generative AI Applications
  • AI：讓機器完成需要智慧判斷的任務
  • ML：從資料中學習模式
  • Deep Learning：利用多層神經網路學習表示
  • Generative AI：依據學到的模式產生新內容

生成式 AI 在本課程中的位置

本課程中，生成式 AI 出現在幾個層次：

  • 協助撰寫與改善 SQL
  • 根據圖表產生摘要
  • 協助探索資料與解釋結果
  • 支援更大的 AI / ML 與 Agent 應用場景

它可以提升效率，但不能取代：

  • 資料定義
  • 權限治理
  • 結果驗證
  • 成本管理
  • 責任歸屬

基礎模型的能力與限制

能力：

  • 可處理多種任務
  • 可透過 Prompt 快速適應
  • 可搭配外部資料與工具
  • 可處理多模態內容

限制：

  • 幻覺與錯誤自信
  • 知識時效與邊界
  • 資料偏差
  • Prompt Injection
  • 不穩定與難以重現
  • 成本與延遲

從 Vertex AI 到 Agent Platform

你在自學課程或舊文件中可能看過 Vertex AI。

Google Cloud 現在以 Gemini Enterprise Agent Platform
承接這個平台脈絡：

  • Vertex AI 是許多 AI / ML 能力的舊有入口與常見稱呼
  • Agent Platform 把模型、資料、工具、權限與治理放在同一個生命週期
  • 學習時要能把舊稱對應到目前的平台定位

不需要死背產品名稱，理解完整 AI 應用需要哪些控制。

Agent Platform：從模型到 Agent

Gemini Enterprise Agent Platform 可支援：

  • Model Garden
  • Gemini、第三方模型與 open models
  • 模型訓練與調整
  • 部署與 Prediction
  • 評估、實驗與品質控管
  • MLOps、監控與治理
  • Agent 開發與工具串接

平台提供模型，更可以管理模型、資料、工具、權限、評估與監控。

Prompt 的基本結構

一個可維護的 Prompt，通常包含：

  1. 角色或任務
  2. 明確目標
  3. 必要背景
  4. 限制條件
  5. 輸出格式
  6. 範例
  7. 無法完成時的行為

Prompt 範例：資料分析

根據目前查詢結果建立一張垂直長條圖。

需求：
- x 軸使用 item_name
- y 軸使用 total_revenue
- 依 total_revenue 由高到低排序
- 使用 item_size 區分顏色
- 不要改變資料篩選條件

這個 Prompt 提供任務、欄位、排序、視覺化方式與限制。

Prompt Engineering 不是咒語

Prompt 可以：

  • 降低任務歧義
  • 提供必要脈絡
  • 約束輸出格式
  • 定義拒答與例外行為
  • 讓結果更容易評估

Prompt 無法單獨解決：

  • 資料權限
  • 模型能力限制
  • 系統可靠性
  • 惡意工具呼叫
  • 監控與事件回應
  • 組織治理

從模型到 Agent

Agent = Model + Instructions + Context + Data + Tools + Permissions + Workflow + Evaluation

Agent 能：

  • 查詢資料
  • 呼叫 API
  • 執行工作流程
  • 保留狀態
  • 依結果選擇下一步

因此風險不只是回答錯，也可能是做錯事。

工具呼叫是一種權限操作

若 Agent 可以

  • 寄送 Email
  • 修改訂單
  • 查詢客戶資料
  • 建立雲端資源
  • 執行程式碼

系統必須提供

  • 最小權限與允許清單
  • 參數驗證
  • 動作範圍限制
  • 高風險操作人工確認
  • 速率與金額限制
  • 完整稽核日誌
  • 失敗與復原流程

Responsible AI 貫穿完整生命週期

問題定義
  ↓
資料取得
  ↓
模型與系統設計
  ↓
評估
  ↓
部署
  ↓
監控與回饋
  ↓
更新或退場

每個階段都可能引入不同風險。

Responsible AI 的核心面向

Fairness

  • 不同族群表現是否不均？
  • 資料是否具代表性？
  • 是否加深既有不平等？

Safety & Privacy

  • 是否洩漏敏感資料？
  • 是否可能被濫用？
  • 是否能抵抗攻擊？

Transparency & Accountability

  • 使用者是否知道限制？
  • 誰對結果負責？
  • 是否能追蹤與申訴？

偏見不能只看整體準確率

假設整體準確率為 95%，仍可能：

  • A 群體：99%
  • B 群體：70%
  • 特定錯誤造成更嚴重影響
  • 上線後資料分布改變

因此需要檢查：

  • 不同族群
  • 不同情境
  • 不同錯誤類型
  • 錯誤嚴重程度
  • 資料與標註來源
  • 部署後漂移

Prompt、IAM、Evaluation 是不同控制

Instructions
告訴模型應該怎麼做

IAM
限制系統實際能存取什麼

Evaluation
確認系統實際做得如何

Monitoring
確認上線後是否持續符合期待

任何一個都不能取代另外三個。

內部資料型 AI 的主要風險

  • 未授權使用者取得資料
  • 模型輸出敏感資訊
  • 檢索未沿用原始 ACL
  • 文件或資料中包含惡意 Prompt
  • 回答沒有來源，難以驗證
  • 過期內容仍被使用
  • 對話與查詢紀錄被不當保留

讓模型看見資料前，先確認它是否應該看見。

Part 6 重點

  • Generative AI 能降低操作門檻，但不會自動保證正確性。
  • Gemini Enterprise Agent Platform（formerly Vertex AI）協助管理 AI / ML 與 Agent 應用生命週期。
  • Prompt 應明確描述任務、限制與輸出格式。
  • Agent 應用必須同時考慮工具、資料、權限與評估。
  • Responsible AI 需要落實到權限、評估、監控與問責。
  • Prompt 不能取代 IAM；免責聲明不能取代驗證。

Part 7｜Integrated Case Study

把雲端、資料、AI、營運與治理組成完整系統

情境：Coffee on Wheels 資料平台

一家行動咖啡品牌希望掌握菜單銷售表現，支援營運與產品決策。

需求：

  • 建立可觀測的雲端服務
  • 追蹤服務是否穩定
  • 分析菜單與訂單資料
  • 視覺化營收趨勢
  • 分享分析流程給團隊
  • 透過生成式 AI 加快探索
  • 控制權限、成本與資料風險

從建置到分析

Provision
建立雲端資源與監控
        ↓
Verify
確認網站與服務可用
        ↓
Observe
透過 Metrics、Logs、Traces 理解狀態
        ↓
Analyze
用 BigQuery 分析訂單與菜單資料
        ↓
Visualize
用 Data Canvas 建立圖表與摘要
        ↓
Share
儲存、分享並匯出分析流程
        ↓
Govern
管理 IAM、成本、品質與風險

端到端架構思維

Cloud

  • Project
  • VPC
  • Firewall
  • Compute Engine
  • Monitoring
  • Billing

Data

  • Dataset
  • Tables
  • Join
  • SQL
  • Chart
  • Notebook

AI

  • Prompt
  • SQL generation
  • Chart insights
  • Validation
  • Responsible AI

Governance

  • IAM
  • Cost
  • Audit
  • Collaboration
  • Review

課程回顧：

  1. 雲端是可程式化的能力，不是自動成功的保證。
  2. 資料品質與業務語意，決定分析與 AI 的上限。
  3. Data Canvas 降低探索門檻，但結果仍需要驗證。
  4. 成本、可靠性與安全必須一起設計。
  5. Responsible AI 必須落實到權限、評估、監控與問責。

Q&A

Thanks for listening

本投影片採用
創用 CC「姓名標示-相同方式分享 4.0 國際」授權條款 釋出
Marp 製作

Google tag (gtag.js)