資料工程師面試問題——30多個問題及專家回答

資料工程職位自2020年以來成長超過60%，使其成為科技領域成長最快的專業方向之一 [1]。然而，平均每個空缺職位有118名申請者，面試到錄用率僅為27% [2]，面試競爭依然十分激烈。現代資料工程師面試不僅考查SQL能力——還測試你設計可擴展管線、為分析建模資料、管理資料品質以及使用Spark、Kafka、dbt和Airflow等工具在生產環境中運維的能力 [3]。以下問題反映了從構建首個資料棧的新創企業到管理PB級資料倉儲的大型企業的招聘團隊所使用的模式。

關鍵要點

• 資料工程師面試涵蓋SQL、Python、資料建模、ETL/ELT管線設計和系統架構 [1]。
• 預期會有SQL和Python程式設計挑戰以及白板管線設計環節。
• 行為面試問題考察你如何處理資料品質事件、利害關係人溝通和跨團隊協作。
• 對現代資料棧工具（dbt、Airflow、Spark、Kafka、Snowflake、Databricks）的了解日益成為要求。
• 展示對資料治理、資料血緣和可觀測性的理解能區分高階候選人。

行為面試問題

資料工程師位於工程和分析的交會處，與資料科學家、分析師和產品團隊協作。行為面試問題評估你在現實約束條件下如何駕馭這些關係 [4]。

1. 描述一次你構建的資料管線在生產中故障的經歷。你如何診斷和修復了問題？

使用STAR：情境（日常ETL作業在凌晨3點失敗，延遲了早間分析儀表板），任務（在工作時間之前恢復資料新鮮度），行動（檢查Airflow日誌，發現來源API的結構描述變更破壞了擷取步驟，實施了結構描述演化處理並添加了告警），結果（90分鐘內恢復管線，添加了自動偵測結構描述變更的整合測試）。

2. 講述一次你與資料科學家或分析師在資料建模方式上存在分歧的經歷。你如何解決的？

描述權衡——也許分析師想要寬的非正規化表以提高查詢效能，而你主張正規化的維度模型以便於維護。解釋你如何使用代表性查詢測試了兩種方法，並找到了滿足雙方需求的折衷方案（物化檢視或預聚合表）。

3. 請介紹一次你繼承了遺留資料管線並必須決定是重構還是重建的經歷。

評估決策標準：文件品質、測試覆蓋率、業務關鍵性以及遷移期間停機的成本。有力的回答展示系統性評估，而非預設選擇「全部重寫」或「維持原狀」。

4. 描述一次你實施了資料品質監控並在問題到達下游消費者之前捕獲了問題的經歷。

討論具體的資料品質檢查：空值率監控、新鮮度SLA、列數異常偵測和結構描述驗證。提及Great Expectations、dbt測試或Monte Carlo等工具。量化影響——「偵測到由來源系統變更導致的列數40%下降，避免了產生不正確的營收報告」。

5. 講述一次你必須向非技術利害關係人解釋資料工程概念的經歷。

用業務語言表述ETL流程、資料延遲和管線依賴關係是至關重要的。描述使用類比、儀表板或資料新鮮度指標來使管線健康狀況可見且易於理解。

6. 你如何處理來源系統資料不可靠或不一致的情況？

討論在擷取層實施驗證、建立來源與目標之間的對帳檢查、在資料目錄中記錄資料品質問題，以及將已知限制傳達給下游使用者而非默默傳播錯誤資料。

技術問題

技術問題測試你在SQL、分散式系統、資料建模和管線架構方面的深度 [5]。

1. 解釋ETL和ELT之間的區別。什麼時候選擇哪種方法？

ETL（Extract, Transform, Load）在載入資料倉儲之前轉換資料——適用於倉儲計算能力有限或轉換需要複雜業務邏輯的情況。ELT（Extract, Load, Transform）先載入原始資料然後在倉儲中轉換——現代欄位式倉儲（Snowflake、BigQuery、Redshift）具有彈性計算能力進行轉換時首選 [3]。討論dbt如何成為ELT中「T」的標準工具。

2. 編寫一個SQL查詢，找出每個部門中第二高的薪資。

使用窗口函式：SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2。討論DENSE_RANK為何能正確處理並列，以及RANK或ROW_NUMBER可能產生不同結果的原因。

3. 你將如何設計一個增量資料管線，僅處理來源系統中變更的記錄？

討論變更資料擷取（CDC）策略：基於時間戳的增量載入（使用updated_at欄位）、基於日誌的CDC（Debezium讀取資料庫預寫日誌）和基於雜湊的比較。解決相關挑戰：延遲到達的資料、基於時間戳方法無法偵測的刪除操作，以及精確一次處理保證 [1]。

4. 解釋星型結構描述和雪花結構描述的區別。什麼時候使用哪種？

星型結構描述有一個中心事實表連接到非正規化的維度表——查詢更簡單、讀取更快、適合BI工具。雪花結構描述將維度表正規化為子維度——減少儲存冗餘但增加查詢複雜度。星型結構描述適合查詢效能很重要的分析工作負載；雪花結構描述適合儲存效率和資料完整性為優先的環境。

5. Apache Kafka與RabbitMQ等傳統訊息佇列有什麼不同？什麼時候為資料管線選擇Kafka？

Kafka是一個具有持久、有序、可重放日誌的分散式事件串流平台。RabbitMQ是一個針對點對點傳遞並具有確認語義最佳化的訊息代理。高吞吐量事件串流、日誌聚合以及多個消費者需要獨立讀取相同資料（扇出）的場景選擇Kafka。複雜路由和精確一次傳遞要求的任務佇列選擇RabbitMQ [5]。

6. 什麼是資料分割？它如何改善資料倉儲中的查詢效能？

分割基於鍵（日期、地區、客戶ID）將大表分割成區段。按分割鍵過濾的查詢只掃描相關區段，降低I/O和計算成本。討論分割策略：時間序列資料的範圍分割、均勻分布的雜湊分割，以及選擇與常見查詢模式一致的分割鍵的重要性。

7. 當上游來源更改資料格式時，你如何在資料管線中處理結構描述演化？

實施結構描述登錄（Kafka的Confluent Schema Registry或Avro/Parquet結構描述演化）。定義前向和後向相容性規則。使用不強制結構描述的著陸區接受原始資料，然後在暫存層進行驗證和轉換。對結構描述變更發出告警，並實施熔斷器在傳播損壞資料之前停止處理 [3]。

情境問題

情境問題提出現實的管線挑戰，以評估你的問題解決方法 [4]。

1. 你的日常管線需要6小時完成，但業務需要每2小時更新資料。你如何處理？

分析時間花在哪裡——擷取、轉換還是載入？實施增量處理替代全表重載。平行化獨立的轉換。考慮將繁重的轉換移至倉儲（ELT）以利用其彈性計算能力。如果SLA要求近即時，評估最關鍵表的串流處理替代方案。

2. 一位資料科學家報告機器學習模型的準確率突然下降。他們懷疑是資料品質問題。你如何調查？

檢查管線中繼資料：最近一次執行是否成功完成？將列數、空值率和值分布與歷史基準進行比較。檢查來源系統變更（結構描述修改、業務規則更新）。使用資料血緣工具追蹤模型的輸入特徵到其來源表，識別分布偏移發生的位置。

3. 你正在為一家目前擁有10 GB資料但預計18個月內達到10 TB的新創企業設計資料平台。如何在不過度工程化的情況下為成長構建架構？

從彈性擴展的託管雲端倉儲（Snowflake、BigQuery）開始。使用隨倉儲計算能力擴展的dbt進行轉換。從一開始就實施Airflow或Dagster的編排——以後添加更困難。設計支援未來擴展的維度模型。避免像Spark叢集這樣的過早最佳化，直到資料量確實需要。

4. 兩個不同的團隊需要相同的來源資料但轉換和新鮮度要求不同。如何避免重複管線？

實施共享的銅/銀/金層次架構。將原始資料一次擷取到銅層，在銀層應用通用清洗，讓每個團隊構建自己的金層轉換。使用資料目錄記錄可用資料集並防止團隊構建冗餘的擷取管線。

5. 你的管線使用一個每分鐘100次請求限制的API，但你需要每天擷取100萬筆記錄。如何設計擷取？

在擷取程式碼中實施帶指數退避的速率限制。使用基於游標偏移的分頁進行增量拉取。在非尖峰時段安排擷取以在速率限制內最大化吞吐量。快取API回應以避免重新取得未變更的資料。如果API支援批次匯出端點，使用它們而非逐筆記錄取得。

向面試官提出的問題

資料工程師應評估資料平台的成熟度和團隊的工程文化 [1]。

1. 「你們目前的資料棧是什麼樣的——倉儲、編排、轉換和可觀測性工具？」 ——揭示技術環境和現代化狀態。
2. 「你們今天如何處理資料品質，是否有現有的資料品質監控框架？」 ——表明資料治理成熟度。
3. 「團隊中資料工程師與資料科學家和分析師的比例是多少？」 ——顯示資料工程師是嵌入消費者還是孤立的。
4. 「團隊如何處理資料管線故障的值班？」 ——評估運維負擔和工作生活平衡期望。
5. 「是否有資料目錄或資料血緣工具？」 ——揭示可發現性和文件化實務。
6. 「團隊目前面臨的最大資料工程挑戰是什麼？」 ——提供該角色是否符合你的技能和興趣的洞察。

面試形式及預期

資料工程師面試通常包括四到五輪，評估程式設計能力和系統設計思維 [3]。

招聘人員篩選（30分鐘）： 討論經驗、薪資期望和整體技術背景。

SQL程式設計輪（60分鐘）： 在共享環境中編寫SQL查詢——窗口函式、CTE、聚合和聯結。預期會有關於查詢執行計畫的最佳化討論。

Python/程式設計輪（60分鐘）： 實作資料處理邏輯——解析檔案、轉換資料結構或構建簡單的管線元件。重點是清晰、可測試的程式碼。

系統設計輪（60-90分鐘）： 端到端設計資料管線或資料平台。常見題目：設計即時分析系統、為多產品公司構建資料湖或架構事件驅動資料平台。

行為面試輪（45-60分鐘）： 關於協作、事件回應和與非技術利害關係人溝通的問題。

如何準備

資料工程師面試準備應結合SQL練習、管線設計學習和工具特定知識 [5]。

精通SQL： 練習窗口函式、CTE、自我聯結和查詢最佳化。使用LeetCode資料庫題、HackerRank SQL或Stratascratch等平台。能夠在沒有IDE的情況下編寫複雜查詢。

學習資料建模： 理解星型結構描述、雪花結構描述、緩慢變化維度（類型1、2、3）和層次架構（銅/銀/金）。準備好在白板上設計維度模型。

了解你的工具： 準備好討論職位描述中列出的工具。對於Spark，理解RDD與DataFrame、分割和shuffle操作。對於Airflow，理解DAG、運算子、感測器和XCom。對於dbt，理解模型、測試、巨集和增量物化。

練習管線設計： 走完五個端到端管線設計：批次ETL、即時串流處理、基於CDC的複製、基於API的擷取和資料倉儲遷移。對於每一個，識別工具、故障模式和監控策略。

準備資料品質故事： 擁有你發現、調查和解決的資料品質問題的具體案例。量化捕獲（或遺漏）這些問題的業務影響。

複習分散式系統概念： 理解分割、複製、一致性模型和CAP定理在資料系統中的應用。Martin Kleppmann的Designing Data-Intensive Applications等書籍是非常有價值的準備材料。

常見面試錯誤

避免這些經常導致資料工程候選人被淘汰的陷阱 [4]。

1. 編寫正確但未最佳化的SQL。 產生正確結果但不必要地掃描整個表的查詢表明缺乏生產意識。始終討論索引、分割和執行計畫。

2. 在管線設計中忽視資料品質。 沒有驗證、監控和告警的管線是不完整的。在系統設計回答中始終包含資料品質檢查。

3. 為不存在的規模過度工程化。 為10 GB日負載提議Kafka和Spark與為10 TB日負載使用簡單指令碼同樣是錯誤。將架構與實際資料量和成長軌跡匹配。

4. 不理解業務背景。 資料管線服務於業務決策。設計技術上可靠但與業務無關的解決方案的候選人偏離了重點。詢問關於誰消費資料以及它驅動什麼決策的澄清問題。

5. 將批次處理和串流處理視為可互換。 兩者在複雜性、成本和延遲方面有不同的權衡。明確什麼時候每種方法是合適的，以及選擇其中一種的運維影響。

6. 忽視運維關注點。 管線監控、告警、重試邏輯、死信佇列和回填程序不是可選的——它們是使管線做好生產準備的要素 [3]。

關鍵要點

資料工程師面試評估你設計、構建和運維資料系統的能力，這些系統向需要的人提供可靠、及時的資料。透過精通SQL、理解現代資料棧工具和練習端到端管線設計來準備。脫穎而出的候選人是那些思考資料品質、運維韌性和業務影響的人——而不僅僅是理想路徑。

想確保你的履歷突出正確的資料工程技能嗎？試試ResumeGeni的免費ATS評分檢查工具，在申請前最佳化你的資料工程師履歷。

常見問題

資料工程師面試應該掌握哪些程式語言？ SQL是必不可少的。大多數職位需要Python。Scala在Spark密集型環境中很有價值。Java在一些企業環境中使用 [5]。

雲端經驗對資料工程面試有多重要？ 非常重要。大多數現代資料工程職位要求至少一個雲端平台（AWS、GCP或Azure）和雲端原生資料服務（Redshift、BigQuery、Snowflake、Databricks）的經驗 [1]。

資料工程師面試包括現場程式設計嗎？ 是的。預期至少一輪現場SQL程式設計，通常還有一輪專注於資料轉換邏輯的Python程式設計 [3]。

資料工程師最常見的系統設計問題是什麼？ 設計帶增量處理的批次資料管線，或設計即時事件串流系統，是兩個最常見的題目。

如果只有在現有管線上工作的經驗，如何準備系統設計輪？ 研究開源架構，閱讀Netflix、Uber和Airbnb等公司的工程部落格文章，練習大聲解釋設計決策。關鍵技能是闡述權衡，而非背誦架構。

資料工程面試應該學習dbt嗎？ 是的——dbt已成為現代資料棧的標準工具。理解模型、測試和增量物化是大多數分析工程和資料工程職位的預期要求 [5]。

哪些認證對資料工程面試有幫助？ 雲端認證（AWS Data Analytics Specialty、GCP Professional Data Engineer、Azure Data Engineer Associate）展示了平台特定的知識，受到許多雇主的重視。