Hao程式筆記

DE Day 45 系列總結與延伸路線 執行需求：CPU 可跑 。今天是「資料工程實戰：SQL、DuckDB 與自動化管線」系列的最後一篇。從 Day 1 的環境導覽到 Day 44 的部署展示，我們用 45 天把一條完整的資料管線從零寫到能跑、能展示、能交接。本篇不寫新技術，只整理學過的工具、指標、模型，並對延伸到 2025 年底後仍可走的學習方向。我們會把六個階段的學習重點串成一張圖、列出五個常見的延伸方向，並用 13 條自我評估清單幫你對照「學到了什麼、還缺什麼」。所有引用的工具版本都停留在 2025 年 11 月（Python 3.13、DuckDB 1.4.x、dbt-core 1.10、Streamlit 1.41 等），不引用 2026 年 1 月後才出現的新工具或新功能。 引言 回頭看 45 天前，Day 1 我們說「這系列要把讀者從『會用 pandas 讀資料』帶到『能獨立打造每天自動運行的資料管線』」。今天我們可以驗收這個承諾：Day 1-2 的環境導覽建立了工作目錄 de-journey/ 、固定了 Python 3.13 + DuckDB 1.4 + Polars 1.33 + dbt-core 1.10 的工具鏈版本；Day 3-7 的 SQL 進階把視窗函式、CTE、查詢計畫、EXPLAIN 講完；Day 8-12 把 DuckDB、Parquet、pandas、Polars 的特性與分工釐清；Day 13-19 用資料清洗、品質規則、爬蟲、開放資料串起「資料怎麼進來」這條線；Day 20-29 講水位標記、冪等、排程、Airflow 與輕量編排，把「管線怎麼跑得穩」這條線補齊；Day 30-37 進入端到端管線、Streamlit 儀表板、容器化、GitHub Actions 排程。最後 Day 38-44 是收尾八篇，把監控、合約、LLM 清洗、文件化、定義與資料模型、管線實作、評估、部署展示串成完整的專案。 本篇的內容分四段。第一段回顧六個階段的學習路徑與代表工具，並用 Day 41-44 的共用設定（ project_config.py 、 aqi_hourly.yml 、七個 dbt 模型）做具體的成果盤點。第二段整理五個延伸學習方向（Airflow 3.x 進階、dbt 進階、Great Expectation...

DE Day 44 部署與展示 執行需求：CPU 可跑 。今天是專案篇的最後一天實作。我們要把 Day 42 的 GitHub Actions 排程推上雲端、把 Day 43 的指標接到 Streamlit 儀表板、並把這套管線「開放」給所有人瀏覽。具體要做四件事：第一，把 DuckDB 檔案與指標快照變成可下載的 artifact；第二，用 Streamlit 1.41 寫一支儀表板應用（讀 project_config.INDICATORS 與 mart_daily_summary ）；第三，把儀表板部署到 Streamlit Community Cloud 或自架容器；第四，把 GitHub Actions 的 workflow 完整接上 daily_run、回歸測試、文件檢查。整個部署流程沿用 Day 41-43 的共用設定，Day 45 會用今天的成果做系列總結。 引言 資料工程的「最後一哩」是讓資料被看到、被使用。寫得再好的管線，如果沒有人查詢儀表板、沒有報告引用指標，就只是一堆跑得很快的程式碼。今天我們把專案從「能跑」推進到「能展示」，這個轉變比想像中大：它牽涉到部署、權限、檔案大小、讀延遲、UI 設計、可存取性。我們一步一步把這些都處理好。 「展示」分成兩個層次。第一層是「資料分析師介面」，給 SQL 熟練的人用，他們需要直接 query DuckDB 拿最新資料。第二層是「一般使用者介面」，給完全沒碰過 SQL 的同事或對外民眾用，他們透過 Streamlit 的儀表板看圖表、看指標。本專案的目標使用者包含兩種，所以兩種介面都要做：dbt 的 docs serve 提供第一層、Streamlit 提供第二層。 今天的設計原則是「可重現、可存取、可驗證」。可重現指任何同事都能從空白機器跑 bash scripts/bootstrap.sh 把整個環境建起來；可存取指部署後的 URL 任何人能開、不需要登入；可驗證指部署後的應用要能被自動測試確認「資料有更新、指標有計算、儀表板有渲染」。我們把這三個特性都做到。 第一段部署：把 DuckDB 變成 artifact GitHub Actions 跑完 daily_run 後， warehouse/de-journey.duckdb 與 logs/indicators/...

DE Day 43 評估與迭代 執行需求：CPU 可跑 。昨天把管線實作完，今天進入專案篇的評估階段。我們要做四件事：第一，用 dbt 內建的 tests 與 sources.yml 跑完整性、唯一性、值域、列舉四種品質檢查；第二，自訂 SQL 指標（全國日均 AQI、不良日比例、各測站排名、縣市不良率）並寫進 DuckDB；第三，建立「指標快照」機制，每天比較今天與昨天、這個月與上個月；第四，當指標異常時自動產生「假說清單」，把可能的成因列出來給值班的人判斷。整個評估流程沿用 Day 41 的 project_config.INDICATORS ，讓 Day 41-45 的指標定義只有一份。 引言 資料管線最常見的失敗不是「抓不到資料」，而是「抓到了但指標悄悄下滑」。一個 AQI 儀表板可能在某個週末突然少了 5 個測站的資料，但平均值「看起來」還在合理範圍；某個縣市的空氣品質可能連續一週惡化，但月報只看月平均沒感覺；某個模型改版可能讓資料品質變好 10%，但沒人對比歷史就不知道。這些「指標滑動」的問題，往往要等下游決策者發現才會被察覺，這時已經過了好幾週。 「評估」的目的就是把這些變化「天天可見」。它分成三個層次。第一層是「這份資料對不對」（資料品質），由 Day 38 學的合約檢查與 dbt tests 負責。第二層是「指標的當下值是多少」（指標計算），由 INDICATORS 字典裡的 SQL 負責。第三層是「指標相對於歷史是高還是低」（趨勢比較），由「指標快照」機制負責。今天把這三層全部接起來。 評估與監控不一樣。監控（Day 38）回答「資料進來時合不合法」，評估（今天）回答「資料經過轉換後的指標是否合理」。兩者結合才形成完整的「資料品質」觀點：監控抓技術錯誤（NULL、型別、重複），評估抓語意錯誤（指標突然掉 30%、某縣市連續一週沒資料）。今天我們把評估變成可重複執行、可對比歷史、可自動產生假說的系統。 第一層評估：dbt tests 與 sources.yml Day 26 已經介紹過 dbt 的四種內建測試：unique、not_null、relationships、accepted_values。我們把這些測試套到 Day 41 與 Day 42 的模型上，把資料品質的「最低底線」寫成版本化的測試程式碼。 # ...