6 technical skills every data engineer should have

原始來源與檔名：2026-08-07T094415+0800-6 technical skills every data engineer should have.md

SOURCE | 資訊源評估

• 準確性: 高 - 作者基於實戰經驗整理資料工程師必備的六大核心技能，內容涵蓋底層原理與架構抉擇，具備高度的實用性與權威性。
• 易理解性: 高 - 透過大量圖解、對比（如 Kimball vs. Inmon, Task-based vs. Asset-based）與漸進式的學習路徑，讓複雜的架構概念變得容易消化。
• 閱讀策略建議: 建議針對自己較不熟悉的領域（如 OLAP 儲存原理或資料塑模），搭配實際工具操作驗證文中提到的概念。

NAPKIN | 餐巾紙

餐巾紙公式

優秀的資料工程師 = Data Modeling * (SQL + Python + Git) * (OLAP + Orchestration)

掌握語言與工具只是基礎，核心在於資料塑模的藍圖以及透過排程與 OLAP 架構實現大規模資料處理的能力。

一句話

面對日新月異的資料技術，資料工程師應專注於投資不會隨時間淘汰的核心基本功：資料塑模、版本控制、SQL、Python、OLAP 系統與工作流排程。

餐巾紙草圖

┌───────────────────────────────
│ 1. Data Modeling (Blueprint)
│ 2. Git (Version Control)
│ 3. SQL (Transformation)
│ 4. Python (Automation/Orchestration)
│ 5. OLAP (Storage & Compute)
│ 6. Orchestration (DAGs/Dependencies)
└───────────────────────────────

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

• 核心問題: 在充滿各種新工具與 AI 技術的時代，資料工程師應該優先學習哪些「不會輕易過時」的核心技術？
• 核心答案: 每個資料工程師都必須掌握六大技術技能：資料塑模、Git、SQL、Python、OLAP 系統與工作流排程。
• 論證結構: 歸納型與案例型結合。針對每一項技能，作者均從「Why（為什麼重要）」與「How to learn it（如何學習）」兩個維度展開論述。

章節骨架

1. Data Modeling: 建立架構藍圖
2. Git: 實現版本控制與協作
3. SQL: 處理資料轉換
4. Python: 自動化與複雜邏輯
5. OLAP: 儲存與運算核心
6. Orchestration: 管理相依性與排程

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

技術日新月異 --> 聚焦不變的核心基礎 --> 提出六大必備技能 --> 分別論述其在資料管線中的不可替代性 --> 透過掌握基礎提升整體工程品質

關鍵證據

1. 資料塑模決定成敗：沒有藍圖的資料倉儲將導致高維護成本與資料一致性問題，Kimball 與 Inmon 的方法論至今仍是業界標準。
2. OLAP 架構的演進：從傳統關聯式資料庫到具備運算與儲存分離（Share-nothing）、列式儲存（Columnar）的現代 OLAP 系統，這是支撐大數據分析的基石。
3. 排程系統的必要性：當工作流變複雜時，必須依賴 Airflow 或 Dagster 來解決相依性（Dependency）、冪等性（Idempotency）與回填（Backfilling）的問題。

隱形假設與邊界

• 隱形假設:
  • 讀者具備基本的資料處理概念，但可能在面對眾多工具時感到迷惘。
  • 企業的資料架構已經達到需要使用資料倉儲與排程工具的規模。
• 邊界條件:
  • 對於極小型的專案，或許不需要完整的資料塑模與複雜的 Orchestration 工具。
  • 未來若 AI 能夠完全自動生成與維護管線，部分手動 Coding 技能的需求可能會降低（但底層邏輯依然適用）。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲點: 文章主要集中在技術面，對於「資料治理（Data Governance）」與「資料品質監控（Data Observability）」著墨較少，而這些也是現代 Data Engineer 不可或缺的能力。
• 知識連接: 與軟體工程領域的 SOLID 原則、Clean Code，以及 DevOps 的 CI/CD 流程有著深度的交叉，資料工程本質上就是在做「資料領域的軟體工程」。
• 行動觸發: 檢視自己目前的技能樹，找出最弱的一環（例如 OLAP 系統底層運作原理或資料塑模），並規劃專案實作來補強。

留白提問 (Guided Reflection)

• 在你的日常工作中，最常遇到因為缺乏「資料塑模」而導致的痛點是什麼？
• 如果只能選擇 Airflow (Task-based) 或 Dagster (Asset-based) 其中之一來構建你的下一代資料平台，你會根據什麼標準來選擇？

跨域映射

• 在 軟體工程，這叫 架構設計與設計模式
• 在 資料工程，這叫 資料塑模與資料管線設計

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. OLAP system - Storage: 深入解釋了列式儲存、Metadata 最佳化、不可變性（Immutable）以及物件儲存的特性，這是理解現代資料倉儲效能的關鍵。
2. Orchestration - Idempotency and Backfilling: 詳細解釋了冪等性與資料回填的概念，這是設計出可靠、可重試（Retryable）資料管線的必備觀念。

6 technical skills every data engineer should have (Architectural Deep Dive)

前言/背景

在充斥著各種新穎資料工具與 AI 技術的時代，資料工程師很容易感到迷惘。這篇文章探討了六項「不會隨時間改變」的核心基礎技術，幫助工程師在瞬息萬變的技術洪流中建立堅實的基礎。

章節詳細總結

Data Modeling (資料塑模)

資料塑模是整個資料架構的藍圖。缺乏藍圖的資料倉儲會導致高昂的維護成本、低效的查詢效能與資料一致性問題。

• 塑模三層次：
  • Conceptual Data Model (概念模型)：專注於業務需求，識別核心實體（如客戶、訂單）與其關聯，不涉及底層技術。
  • Logical Data Model (邏輯模型)：定義實體的屬性、主鍵與資料型別，是業務概念與實體建置的橋樑。
  • Physical Data Model (實體模型)：針對特定的資料庫系統（如 BigQuery、Snowflake）進行實作，包含資料表、索引、分區 (Partitioning) 等最佳化配置。
• 兩大流派：
  • Kimball 方法 (Dimensional Modeling)：採用由下而上 (Bottom-up) 的策略，以星狀綱要 (Star Schema) 為核心，包含儲存量化指標的事實表 (Fact tables)與提供描述性脈絡的維度表 (Dimension tables)，優化分析查詢效能。
  • Inmon 方法：採用由上而下 (Top-down) 的策略，強調建立高度正規化 (通常為 3NF) 的企業資料倉儲 (EDW) 作為單一事實來源 (Single Source of Truth)，再從中建立資料超市 (Data Marts)。

Git

版本控制是團隊協作的基石，能避免生產環境的意外、追蹤 Bug 來源以及建立 CI/CD 管線。 Git 的核心在於它將資料儲存為「快照 (Snapshots)」，並透過指標 (Pointers) 來建立強大的分支功能。一個 Commit 就是專案在特定時間點的完整快照，而 Branch 僅是指向某個 Commit 的可移動指標。

SQL

SQL 是資料領域的通用語言，隨著現代資料倉儲與轉換工具 (如 dbt、SQLMesh) 的興起，其重要性不減反增。

• Window Function 與 GROUP BY 的差異：
  • GROUP BY 會將多筆資料折疊 (Collapse) 成一筆聚合後的摘要列。
  • Window Function 會在定義的「視窗」內運作，但保留原始資料列。例如：SELECT country, SUM(sales) OVER (PARTITION BY country) AS category_total_sales FROM products 會在每一列附加上該類別的總銷售額。
• SQL 執行順序 (Execution Order)：理解執行順序是撰寫最佳化查詢的關鍵：
  1. FROM / JOIN：確認資料表並執行關聯。
  2. WHERE：過濾資料集。
  3. GROUP BY：分組以準備聚合。
  4. HAVING：過濾聚合後的結果。
  5. SELECT：處理要輸出的欄位與 Window functions。
  6. DISTINCT：移除重複列。
  7. ORDER BY：排序結果。
  8. LIMIT / OFFSET：限制輸出筆數。 (BigQuery 等系統還支援 QUALIFY 語句，用於過濾 Window function 的結果。)

Python

Python 用於處理 SQL 難以表達的複雜轉換、API 串接、自動化任務以及排程管理 (Airflow/Dagster)。 學習 Python 不僅是學習語法，更重要的是撰寫高可讀性、可維護與可擴展的程式碼。工程師應該盡早熟悉設計模式 (Design Patterns)、SOLID 原則與 Clean Code 的概念，確保團隊協作的順暢。

OLAP system (線上分析處理系統)

OLAP 系統是現代資料基礎設施的核心，專為處理 TB/PB 級的分析查詢而生。

• 架構特性：
  • Share-nothing Architecture：運算 (Compute) 與儲存 (Storage) 分離，以實現高擴展性。
  • Processing (處理)：採用分散式運算，並利用向量化執行 (Vectorized execution) 或程式碼生成 (Code generation) 提升效能。
  • Storage (儲存)：
    • 資料採用列式 (Columnar) 或混合格式儲存，有利於聚合分析。
    • 具備豐富的 Metadata，協助查詢引擎在掃描時盡可能跳過不必要的資料區塊。
    • 資料不可變 (Immutable)，變更會寫入新檔案，藉此實現版本控制與工作負載隔離。
    • 為了成本效益，大多底層採用物件儲存 (Object Storage)。

Orchestration (排程與自動化)

當生產環境的任務與相依性變得複雜時，Apache Airflow 或 Dagster 等排程工具便不可或缺。它們透過有向無環圖 (DAG) 來管理工作流。

• Task-Based vs. Asset-Based：Airflow 偏向「執行這項任務後再執行另一項」(Task-based)；而 Dagster 則著眼於「如何保持這些資料資產的最新狀態」(Asset-based)。
• Idempotency (冪等性)：指相同的輸入重複執行多次，結果始終相同。具備冪等性的管線在失敗重試時，不會產生重複資料或副作用（常見作法是設計成覆寫特定日期的分區，而非不斷 append）。
• Backfilling (回填)：針對歷史區間重新執行管線以修正 Bug 或補齊晚到的資料。冪等性設計是安全執行回填的前提。

總結與結論

• 架構決策應優先於工具選擇：不論使用 BigQuery 或 Snowflake，底層的 Kimball 維度塑模與 OLAP 儲存原理（運算儲存分離、列式儲存）才是影響效能與維護成本的根本原因。
• 資料工程本質即是軟體工程：導入 Git 版控、撰寫 Clean Code 以及遵循 SOLID 原則，是確保資料管線具備可維護性與可擴展性的必經之路。
• 設計冪等的資料管線：在設計 Orchestration 流程時，應強烈要求所有的 Task 都具備冪等性 (Idempotency)，以確保在面對失敗重試與歷史資料回填 (Backfilling) 時，不會破壞資料的一致性。