ETL

前言：手動維護 53 種食物的極限 我正在開發一款健康追蹤 App，核心功能之一是飲食記錄。一開始，食物資料庫是手動維護的 JSON — 53 種台灣常見小吃，從滷肉飯到珍珠奶茶。 53 種夠用嗎？使用者搜尋「鮭魚」找不到、搜尋「優格」找不到、搜尋「oatmeal」更不用說。手動新增不可能跟上需求，我需要一條自動化管線，把全世界的食物營養資料拉進來。 這就是 ETL 管線登場的時機。 什麼是 ETL？用食物資料庫解釋 ETL 是 Extract（擷取）、Transform（轉換）、Load（載入） 的縮寫，是資料工程最基礎的設計模式。與其抽象解釋，直接用這個專案的食物資料庫來看： flowchart LR subgraph Extract A1[🇹🇼 台灣食藥署 API] A2[🇯🇵 日本 GitHub] A3[🇨🇳 中國 GitHub] A4[🇺🇸 USDA API] end subgraph Transform B[統一格式化<br/>營養素映射<br/>分類標準化<br/>名稱清理] end subgraph Load C[合併去重<br/>驗證完整性] D[(foods_database.json<br/>13,152 種食物)] end A1 --> B A2 --> B A3 --> B A4 --> B B --> C --> D 四個來源的原始資料格式完全不同 — 台灣用中文欄位名（粗蛋白）、日本用 FAO 代碼（prot）、USDA 用數字編號（203）。Transform 階段把它們統一成 App 需要的 {id, name, emoji, category, nutrition} 結構。 ...