專案協作第 2 週 ｜ 02 通用資料管線藍圖

獲得一個通用的 Data Engineer Pipeline 架構：所有 DE 專案都長同一個樣子，只是每個 stage 用不同工具

---

一句話總結

所有資料管線都是 6 個階段：Source → Ingest → Storage → Process → Serve → Observe。

我們的 8 種情境也好，業界等級的系統也好，骨架完全一樣。差別只在每階段的選型。

---

從 ETL/ELT 講起：DE 工作的核心動作

在拆解六階段之前，先讓你認識業界最常掛在嘴邊的兩個縮寫：ETL 與 ELT。

資料工程師（DE）的工作核心 = 蓋一條「從原始資料到可用洞察的輸送帶」，行話叫 Pipeline。最常見的 3 個動作合稱 ETL：

步驟	中文	在做什麼
📥 E — Extract	取資料	從來源把資料抓回來：API、爬蟲、CSV、資料庫
🛠️ T — Transform	變乾淨 / 變有用	清洗、補缺值、合併、計算指標、轉成可分析格式
📤 L — Load	送到該去的地方	寫進資料庫、產出儀表板、推播警示、寄出週報

ETL vs ELT — 差異就在順序，而這個順序是為了解決儲存和運算

ETL（傳統）  E → T → L    先在中間轉換好再進倉儲
                          適合嚴格 schema、傳統資料倉儲、批次處理

ELT（雲端主流） E → L → T    先全部入倉儲，再用資料倉儲的設備或機器的運算力來做資料處理
                            (BigQuery / Snowflake / Databricks) 

💡 為什麼延伸出 ELT？因為雲端倉儲算力越來越強，成本也逐漸降低，「先進再轉」變得划算 —— 原始資料保留、轉換邏輯可隨時重跑（你之前算錯了？重跑就好）

範例： 🍱 餐飲連鎖店 POS Pipeline

業務需求：店長想每天知道「哪些菜熱賣？什麼時候要補貨？哪間店做得最好？」 → DE 要設計一條每天自動跑的 pipeline。

flowchart LR
    A["🍱 POS 系統<br/>+ 各分店訂單"] --> B["② Extract<br/>Python 抓 API/CSV"]
    B --> C["③ Storage<br/>MySQL 入庫"]
    C --> D["④ Transform<br/>pandas + SQL 算指標"]
    D --> E["⑤ Load<br/>Streamlit 儀表板"]

對照架構視角：② Extract = 架構的 Ingest｜③ Storage = 架構的 Storage｜④ Transform = 架構的 Process｜⑤ Load 視情境落在 Serve 或 Storage

這條 pipeline 把「業務問題（為什麼）」連到「工具選型（用什麼）」連到「執行流程（怎麼跑）」。 DE 的價值所在：寫程式之外，也要把業務需求變成可運作的資料流(總結：程式碼正確正確且有高品質的資料或數據能持續進來)

📚 接下來的「六階段藍圖」其實是把 ETL 拆得更細、補上前後端（資料來源、儲存、服務、監控），讓整條 pipeline 完整可運作。

---

兩種視角：架構視角 vs 行為視角

DE 在講 pipeline 時，常常把兩件事混在一起講，先把它們分開：

視角	看什麼	用什麼詞彙	回答什麼問題
🏛 架構視角	整條 pipeline 由哪些階段組成（靜態結構）	六階段：Source → Ingest → Storage → Process → Serve → Observe	「pipeline 長什麼樣？」
⚙️ 行為視角	資料怎麼流動（動態執行）	ETL（E → T → L）／ ELT（E → L → T）	「資料怎麼動？什麼時候做轉換？」

💡 同一條 pipeline可以用兩種視角描述。架構是骨架，行為是它的執行順序。 接下來先講架構，行為的部分回頭看上面「從 ETL 講起」那段。

---

6 階段藍圖（架構視角）

flowchart LR
    S["📁 Source<br/>資料源"] --> I["📥 Ingest<br/>進料"]
    I --> ST["💾 Storage<br/>儲存"]
    ST <-.順序可換.-> P["⚙️ Process<br/>處理"]
    P --> SE["🖥 Serve<br/>服務"]
    SE --> O["📡 Observe<br/>監控"]
    O -.feedback loop.-> S

    style ST fill:#FEF3C7,stroke:#D97706
    style P fill:#FEF3C7,stroke:#D97706

💎 資料層（Storage ⇄ Process）順序可換：

• ETL（傳統）：Process → Storage（先轉再進倉）
• ELT（雲端主流）：Storage → Process（先進倉再用倉儲算力轉）

💡 為什麼 Storage 和 Process 順序可以換？

• ETL 傳統作法：資料先 Process（清洗、轉換）→ 再 Storage（存進倉儲）→ 嚴格 schema、批次處理
• ELT 雲端主流：資料先 Storage（全部入倉）→ 再 Process（用倉儲算力轉換）→ 原始資料保留、轉換邏輯可隨時重跑
• 兩種架構視角下的階段一樣，只是「執行順序」不同 — 這正是行為視角的工作

1️⃣ Source — 資料從哪來

形式	範例	學期會碰到
API（被動拉）	OpenAI / Spotify / 政府開放資料	✅
爬蟲（主動抓）	momo / 104	✅
檔案下載	Kaggle CSV / 壓縮檔 zip	✅
資料庫匯出	企業 ERP MySQL dump / python pandas read_sql()	✅
Streaming	Kafka topic / Pub/Sub	進階

選型原則：用 API 就別用爬蟲，用爬蟲了話也不能寫死(hard code，也就是要用function或把參數拉出來使用)。

2️⃣ Ingest — 怎麼把資料拉進來

模式	工具	何時用
一次性手動	Python + requests	POC 階段
排程批次	Airflow / cron / GitHub Actions	多數情境
即時串流	Kafka / Pub/Sub	高頻 + 低延遲
事件觸發	Webhook + Cloud Function	整合第三方

一個小提醒：很多人交作業時就停在「手動跑一次」—— 但 pipeline 的價值在「自動」。沒上排程的話，面試官比較難從你的 demo 感受到工程價值，可以排程的就盡量排起來。

3️⃣ Storage — 資料放在哪

原始層（Raw / Bronze）        → MongoDB / GCS / S3 / 本地 parquet
   ↓
清洗層（Cleaned / Silver）    → MySQL / PostgreSQL
   ↓
分析層（Curated / Gold）      → BigQuery / dbt model

一個小提醒：剛開始很容易只開一張 MySQL table，原始資料每次直接覆蓋掉 —— 結果分析跑錯時，連回去重算的機會都沒有。

建議習慣：Raw 永遠保留，只在 Silver / Gold 層做清洗。多一份備份，安心很多。

4️⃣ Process — 處理成可用資訊

行為視角下，這就是 ETL/ELT 的 T（Transform）動作；架構視角我們稱這一段為 Process。

工具	適用
pandas	中小資料（<10 GB）、單機
SQL (BigQuery / Postgres)	大資料分析
dbt	維度建模、版本控制的 SQL
Spark	超大資料、分散式
LLM API	文字理解 / 分類 / 摘要

一個值得早點養成的習慣：與其塞一支 1000 行的 notebook，不如拆成 staging → intermediate → mart 三層。 每層職責清楚的好處：除錯時不用整支重看、組員 review 時抓得到重點。

5️⃣ Serve — 怎麼讓人用到

形式	工具	何時用
Dashboard	Streamlit / Tableau / Looker	內部視覺化
API	FastAPI / Flask	給其他系統呼叫
Chat Bot	LINE Bot / Discord Bot	一般用戶
報告	Notebook + PDF export	一次性分析
Notification	Email / Slack / LINE 推播	警示型

選型原則：跟著「使用者怎麼用」走，不是跟著「我會什麼」走。

6️⃣ Observe — 出問題你知道嗎？

監控項目	工具
Pipeline 跑沒跑	Airflow UI / Sentry
資料品質	dbt tests / Great Expectations
API 健康	Uptime Robot / Cloudflare
Cost	GCP Billing / AWS Cost Explorer
Alert	Email / Slack / Discord webhook

很容易被忽略的一步 —— 但這一步往往就是讓作品從「能跑」變成「能讓人放心交給你」的關鍵。

---

怎麼套用到 8 情境

以下作爲參考，基本上團隊專題還是建議用到課程所學的工具，或這些工具的進階等)

#	情境	Source	Storage	Process	Serve
1	餐飲 POS	Kaggle / API	MySQL	pandas	Streamlit
2	電商比價	爬蟲 (momo/PChome)	MySQL	Airflow + SQL	FastAPI
3	數位金融	CFPB API	MongoDB	LLM 分類	Streamlit
4	音樂串流	Spotify API	MongoDB	SQL + pandas	Streamlit
5	叫車交通	NYC TLC	BigQuery	Airflow 15 min	FastAPI
6	求職媒合	104 爬蟲	MongoDB	pandas	Streamlit
7	新聞輿情	RSS / NewsAPI	MongoDB	LLM	Streamlit + LINE
8	房地產	data.gov.tw	MySQL	pandas	Streamlit 地圖

每個情境的細節展開請見 scenarios/*.md。

---

工具選型

此章節參考和理解即可，基本上專題都要用上課所學或相對應工具較佳，包含Python、Pandas、DB(SQL、NoSQL)、Airflow、Docker等

思考點 1：資料規模

你的資料每天進多少？
├ <1 GB        → MySQL / MongoDB 就夠
├ 1-100 GB     → BigQuery / PostgreSQL
└ >100 GB      → BigQuery / Snowflake / Spark

思考點 2：更新頻率

資料多久要新一次？
├ 每天 / 每週   → cron job （排程設定）
├ 每小時 / 15min→ Airflow
└ 即時          → Kafka / Pub/Sub

思考點 3：使用者

誰在用你的結果？
├ 工程師 / 自己   → 寫 python 腳本 或 SQL 就好
├ 非技術同事     → Streamlit / Tableau
├ 一般用戶       → LINE Bot / 網頁
└ 其他系統       → FastAPI

---

---

下一步：04 8 情境痛點 × 業界對應地圖 →