資料工程師面試問題

框架: 搭配確定性排序的視窗函數

我會用視窗函數，在每個 event_id 分區內為資料列編上列號，並依照最可靠的新鮮度欄位遞減排序，例如 ingestion_timestamp 或 updated_at。如果可能出現同值的情況，再加上一個具確定性的決勝欄位，像是 source_sequence_number 或 raw_file_name。 查詢的寫法是：選取所有資料列，計算 row_number() over(partition by event_id order by ingestion_timestamp desc, source_sequence_number desc)，再篩選出 row_number = 1 的資料列。 面試時最關鍵的細節是確定性。如果兩筆紀錄的時間戳記相同、又沒有決勝欄位，每次執行的結果可能都不一樣。另外也要先釐清「最新的事件」指的是最晚擷取的時間、最晚的事件發生時間，還是來源端最後更新的時間。 在正式環境中，我會監控重複率、延遲抵達的事件、event_id 為 null 的筆數，以及去重複是否讓下游指標出現意料之外的變化。

框架: 篩選活躍事件 → 統一日期 → 依日期與使用者分組

首先要定義什麼是活躍使用者。通常不是每一種事件都該算數，頁面瀏覽、機器人事件、背景重新整理和內部使用者可能都需要排除。我會依產品性質挑選有意義的事件，例如 session_start、purchase、message_sent 或 feature_used。 接著建立一個轉換：篩選出符合條件的事件，把事件時間戳記轉換成業務時區，依 activity_date 和 user_id 分組，輸出每位活躍使用者每天一列的資料。如果最終資料表是彙總表，就依日期計算不重複的使用者數；如果是供下游使用的服務層模型，就儲存 date、user_id、platform、country 和 first_active_timestamp。 正式環境要注意的細節包括時區、延遲抵達的事件、機器人與測試資料過濾、已刪除的使用者、重複事件，以及依 activity_date 分區。做增量建置時，要重新處理最近幾個分區來接住延遲事件，而不是只處理當天。 好的回答還會包含驗證：將 DAU 與來源事件數比對、監控每天的變化，並檢查各分群層級的數字是否一致。

框架: 影響範圍 → 查詢計畫 → 資料成長 → join → 分區 → 近期變更

我會先確認問題是出在這個查詢本身、整個資料倉儲，還是基礎架構。如果很多查詢都變慢，可能是叢集容量不足、資料倉儲負載過高或服務效能下降；如果只有這個查詢變慢，就深入檢查查詢本身和資料。 接著看近期有什麼變化：資料表變大、schema 變更、新增的 join、篩選條件改變、分區修剪失效、統計資訊過時、資料傾斜、join 後資料列暴增，或是多了 distinct / order by 操作。如果拿得到查詢計畫，也會一併檢視。 常見原因包括在錯誤的粒度上 join、缺少日期篩選、多對多 join、掃描所有分區、沒效率的視窗函數、大量 shuffle，或是在分區欄位上套用函數，導致無法修剪分區。 修正方式可能包括提早篩選、預先彙總、加上分區篩選條件、叢集化/排序、將中間模型實體化、更新統計資訊、減少選取的欄位，或修正 join 邏輯。我也會針對執行時間、掃描的位元組數、資料列數和成本加上監控。

框架: 業務流程 → 事實表 → 維度表 → 粒度 → 指標

我會從核心業務流程開始：瀏覽、購物車、訂單、付款、出貨、退貨、退款、庫存與行銷歸因。視使用方式而定，每個流程都可能成為一張事實表或一個事件模型。 重要的事實表包括：一筆訂單一列的 fact_orders、每筆訂單中每項商品一列的 fact_order_items、fact_payments、fact_refunds、fact_shipments，以及 fact_inventory_snapshot。維度表則包括 dim_customer、dim_product、dim_date、dim_store（或倉庫維度）、dim_channel 與 dim_campaign。 粒度一定要明確宣告。依商品類別計算營收，通常應該來自訂單商品粒度，而不是訂單粒度；顧客生命週期指標可能用顧客或訂閱粒度；庫存分析則可能需要每日快照粒度。 建模時要考量的地方有：顧客或商品屬性的緩慢變化、退款與取消、訂單層級與商品層級的折扣、幣別、稅金、運費、訪客結帳，以及延遲抵達的資料。我會定義作為單一事實來源的指標，並為財務、行銷、產品與營運建立語意模型或 data mart。 驗證方面，我會把營收與財務對帳、訂單數與交易系統對帳、退款總額與付款系統對帳，以及庫存與倉儲系統對帳。

框架: 依是否需要保留歷史，選擇 Type 1 或 Type 2

適合的做法取決於歷史資料的正確性重不重要。Type 1 會直接覆寫舊值，做法簡單，適合只在乎最新值的情況。Type 2 則會在每次屬性變動時新增一列維度資料來保留歷史，通常會搭配 effective_start_date、effective_end_date、current_flag 和代理鍵。 舉例來說，如果某位顧客的區域從 West 改成 East，Type 1 會把這位顧客的資料列直接更新成 East，結果歷史營收報表會把過去的營收也算在 East 底下，這可能是錯的。Type 2 會保留原本 West 那一列，再新增一列 East，讓事實表能 join 到事件發生當下的正確版本。 Type 2 會增加複雜度：代理鍵、日期區間 join、延遲抵達的事實資料、目前報表與歷史報表的區分，以及更大的維度表。當報表必須反映事件發生當時的屬性時，就適合用 Type 2。 好的回答會先說明業務需求，再決定要用哪一種 SCD 類型。

框架: 治理與彈性，對比查詢簡潔度與效能

Star schema 會把事實表和維度表分開。當你需要可重複使用的維度、一致的指標、治理、明確的粒度和彈性分析時，它就很有用。它能減少資料重複，維度的變更也比較好管理。 反正規化的寬表則適合特定的高使用量分析、機器學習特徵，或重視查詢簡潔度與效能的儀表板。它能為使用者減少 join 的複雜度，但可能造成資料重複；如果許多寬表各自用不同方式定義指標，也會產生治理風險。 實務上，我通常會維護一套乾淨、標準的事實表和維度表，再針對特定使用情境發布整理好的 data mart 或寬表。資料倉儲的基礎層要維持可信，下游模型再針對使用者需求做最佳化。 最後的決定取決於資料規模、使用者是誰、BI 工具的運作方式、成本、延遲，以及業務定義多常變動。

框架: 擷取 → 原始資料落地 → 轉換 → 驗證 → 發布 → 監控

我會先釐清需求：資料新鮮度、訂單量、可接受的延遲、來源資料庫的負載限制、下游使用者，以及是否會有歷史資料修正。 一個簡單的設計是：用 updated_at 或 CDC 增量擷取訂單，把原始資料落地到物件儲存或資料倉儲的原始資料表，轉換成暫存表，再發布 fact_orders 和 fact_order_items 這類模型化的事實表。排程編排可以用 Airflow、Dagster、dbt Cloud 或代管的工作流程工具。 這條管線必須具備冪等性。如果針對某個日期或批次重新執行，應該以確定性的方式取代或合併資料，而不是重複附加。watermark 要謹慎使用，並重新處理一段回溯區間，以接住延遲的更新。 驗證檢查包括：資料列數、主鍵為 null、重複的訂單 ID、營收總額、狀態分布、新鮮度，以及與來源端對帳。監控應在失敗、資料量異常變化、重複率偏高或資料延遲時發出警示。同時也要記錄負責人與下游相依關係。

框架: 相同輸入重新執行，產生相同輸出

冪等的管線可以用相同的輸入執行很多次，每次都產生同樣正確的輸出，不會出現重複資料或意外的副作用。這很重要，因為管線會失敗、會被重試，也需要回補。 舉例來說，一條不冪等的管線每次執行都會把昨天的訂單附加進去。如果失敗後重試，營收就會變成兩倍。冪等的版本則會刪除並取代目標分區、依主鍵合併，或先寫入暫存表，再以原子性的方式切換。 要做到冪等，需要明確的鍵、分區策略、確定性的轉換，以及謹慎處理副作用。這是正式環境資料工程最重要的概念之一，因為能不能復原就取決於它。

框架: 偵測 → 分類 → 防護 → 溝通 → 遷移

我會先透過 schema registry、中繼資料檢查、合約測試或擷取時的驗證，自動偵測 schema 變更。接著把變更分類：新增欄位、移除欄位、欄位改名、型別變更、可否為 null 的變更，或語意變更。 新增可為 null 的欄位通常是安全的。移除欄位、欄位改名和型別變更則可能讓下游的轉換和儀表板壞掉。語意變更尤其危險，因為 schema 看起來仍然有效，實際意義卻已經改變。 要保護管線，可以保留原始資料、做相容性檢查、設定警示，並為關鍵來源建立合約。遇到破壞性變更時，要與來源負責人協調、更新轉換邏輯、視需要回補資料，並向下游說明影響範圍。 成熟的回答會提到資料合約、版本控管、資料血緣、測試與明確的負責歸屬，確保 schema 變更不會在無人察覺下破壞分析結果。

框架: 決策時效與複雜度的取捨

當低延遲能帶來實質價值時，我會選擇串流。例子包括詐欺偵測、維運警示、即時個人化、庫存更新、即時實驗指標，以及需要最新事件、直接面對使用者的產品功能。 對於每日報表、歷史分析、財務對帳，以及延遲幾個小時也能接受的轉換，批次通常是更好的選擇。批次的維運比較簡單、比較容易重播，成本也往往比較低。 做決定時應考量新鮮度需求、事件量、順序要求、有狀態處理、容錯能力、團隊的專業能力、成本與下游使用者。串流不會自動比較好，它會在重複資料、延遲事件、檢查點、schema 演進與監控方面增加複雜度。 好的回答會這樣說：採用能滿足業務需求的最簡單架構。如果業務只需要每日指標，就不要為了面子去打造串流系統。

框架: 事件 → 串流 → 資料補充 → 規則/模型 → 處置 → 儲存 → 監控

我會先從需求開始：事件量、延遲目標、詐欺決策的類型、對誤判的容忍度，以及決策是要直接阻擋交易，還是觸發審查。 一種可行的設計是：付款事件發布到 Kafka 或 Kinesis。串流處理器消費這些事件、驗證 schema、依 event_id 去重複，補上使用者、裝置、商家與歷史頻率（velocity）特徵，再套用規則或模型。高風險事件會觸發決策服務、進入人工審查佇列，或要求加強驗證。原始事件與決策結果會寫入持久性儲存，供稽核與模型訓練使用。 關鍵的工程考量包括：重複事件、事件亂序、特徵新鮮度、狀態儲存的大小、exactly-once 或 effectively-once 處理、背壓、死信佇列、重播、延遲監控，以及模型與規則的版本控管。 因為詐欺決策會影響顧客，資料品質與治理也很重要。要記錄原因代碼、監控誤判率，並在規則或模型表現異常時支援回滾。

框架: 在分區之間重新分配資料

當 Spark 需要在分區之間重新分配資料時，就會發生 shuffle，通常出現在 groupBy、join、distinct、orderBy 和 repartition 這類操作。它之所以昂貴，是因為資料必須透過網路搬移、經過序列化與反序列化、寫入磁碟，還要在各個 executor 之間協調。 Shuffle 常常占掉作業大部分的執行時間；當資料傾斜或中間資料過大時，還可能導致失敗。單一熱門鍵就可能把過多資料送到同一個分區，造成落後任務（straggler）或記憶體不足錯誤。 降低 shuffle 成本的方法包括：提早篩選、只選取需要的欄位、預先彙總、對小表使用 broadcast join、依 join 鍵分區、對傾斜的鍵加鹽（salting）、避免不必要的 distinct/orderBy，以及調整分區數量。 好的回答會把概念連結到實際的 debug：檢查 Spark UI、各個 stage、shuffle 讀寫量、資料傾斜、溢寫（spill）、task 執行時間與 executor 記憶體。

框架: 找出 stage → 減少資料量 → 修正傾斜 → 調整分區 → 避免不良操作

我會先透過 Spark UI 或日誌找出失敗發生在哪裡：哪個 stage、哪個操作、哪個分區、哪個 executor。OOM 可能來自資料傾斜、大型 join、collect 操作、過大的分區、沒效率的 UDF，或快取了太多資料。 接著及早減少資料量：篩選資料列、只選取必要欄位、下推述詞，並避免讀取不需要的分區。再檢查 join：如果其中一張表很小，就用 broadcast join；如果某個鍵有傾斜，就用加鹽或把熱門鍵拆開處理；如果分區太大，就增加分區數量；如果有太多很小的分區，就適度用 coalesce 合併。 避免對大量資料使用 collect()；原生函數能做到的就不要用 Python UDF；只有在資料會重複使用、而且記憶體足夠時才快取。輸出檔案時，避免產生太多小檔案，並選擇 Parquet 這類欄式格式搭配壓縮。 如果需要調整資源，可以調整 executor 記憶體、核心數、shuffle 分區數與記憶體額外開銷（memory overhead），但不要只靠加大叢集。修正資料的分布形態與查詢計畫，通常才是更長久的解法。

框架: 欄式儲存、schema、壓縮、述詞下推

Parquet 是欄式檔案格式，而查詢通常只會讀取部分欄位，所以很適合用來做分析。它支援壓縮、會對資料型別編碼、會儲存 schema，在許多引擎中也能做到述詞下推和欄位修剪。 CSV 是以列為主的純文字格式，人可以直接閱讀、可攜性也高，但缺乏嚴謹的型別，檔案可能更大、掃描更慢，在分隔符號和跳脫字元上更容易出錯，也沒辦法有效率地跳過不相關的欄位。 對資料湖和資料倉儲來說，Parquet 通常能降低儲存成本並提升查詢效能。CSV 仍適合簡單的匯出、小檔案或跨系統交換資料，但不適合當作主要的分析儲存格式。

框架: 新鮮度 → 完整性 → 唯一性 → 有效性 → 對帳

針對營收管線，我會加入這些檢查：新鮮度、資料列數、主鍵為 null、重複的交易 ID、狀態值是否有效、幣別是否有效、適用情況下金額不得為負、日期是否落在可接受範圍內，以及訂單、付款、退款與顧客之間的參照完整性。 我也會加入對帳檢查：將營收總額與來源付款系統、財務報表或上一版管線的結果比對。用門檻值監控與前一天、前一週相比的變化，但要把季節性和已知事件考慮進去。 業務規則也很重要：已取消的訂單不應計入營收、退款應從淨營收中扣除、測試交易應排除，而幣別換算要使用正確的匯率。 警示必須能讓人採取行動、送到負責人手上，並附上背景資訊：哪項檢查失敗、受影響的資料表、嚴重程度、下游相依關係，以及建議參考的 runbook。太多雜訊警示最後只會被忽略。

框架: 評估影響 → 比較版本 → 檢查資料血緣 → 緩解 → 找出根本原因

我會先評估影響：哪個儀表板、哪個指標、哪些使用者、哪段日期範圍，以及哪些決策受到影響。再判斷這個數字是錯的，還是這次部署其實修正了先前的問題。 接著把新輸出和前一版比較，依資料表、分區、資料列數、不重複計數、指標總額與關鍵分群逐一對照。用資料血緣找出上游的變更，並檢查程式碼變更、schema 變更、篩選條件、join、去重複與日期邏輯。 如果指標確實有錯，而且已經影響到業務使用者，就要快速緩解：回滾轉換邏輯、還原前一版資料表、停用儀表板，或加上警告提示。之後再做根本原因分析，必要時回補修正後的資料。 溝通很重要。我會通知利害關係人哪些地方改變了、影響範圍、目前的把握程度、預計修復時間，以及過去的決策是否需要重新檢視。

框架: 埋點 → 擷取 → 儲存 → 處理 → 建模 → 資料服務 → 治理

我會先從需求開始：事件量、延遲、使用者、保留期限、schema 演進、隱私與可靠性。產品分析事件可能會用在儀表板、實驗、個人化與機器學習特徵。 用戶端透過 SDK 送出事件，內容包含 event_name、user_id、session_id、timestamp、properties、App 版本、平台與匿名 ID。事件先送到擷取 API 或事件收集器，再進入 Kafka/Kinesis/Pub/Sub 這類持久性串流。原始事件會寫入物件儲存以便重播，同時寫入資料倉儲或 lakehouse 供分析使用。 處理流程包括 schema 驗證、去重複、過濾機器人與內部流量、session 切分、身分整合，並轉換成 fact_events、fact_sessions、dim_users 與各產品專屬 data mart 等模型化資料表。依新鮮度需求，批次與串流兩條路徑可能並存。 品質與治理方面：事件合約、schema registry、PII 處理、使用者同意的落實、資料血緣、負責歸屬、新鮮度檢查、資料量異常警示，以及文件。資料服務層包括 BI 儀表板、實驗分析、reverse ETL 與 feature store。 需要取捨的地方包括：即時與批次的成本、嚴格與彈性的 schema、原始事件的保留時間、身分整合的複雜度，以及多少邏輯該放在擷取階段、多少該放在轉換階段。

框架: 離線/線上一致性 → 特徵定義 → 新鮮度 → 資料服務 → 監控

Feature store 應該為模型訓練與線上服務提供可重複使用、可靠的特徵。需求包括特徵定義、時間點正確性、離線訓練資料、線上低延遲服務、新鮮度、存取控制與監控。 離線特徵可以存放在資料倉儲或 lakehouse，依日期與實體分區；線上特徵可以由低延遲的鍵值儲存提供。特徵註冊表會儲存中繼資料：特徵名稱、負責人、實體鍵、轉換邏輯、新鮮度 SLA、來源資料表與說明。 時間點正確性非常關鍵。訓練資料必須使用預測當下就已經存在的特徵值，而不能用到未來的值。為了確保線上與離線一致，應盡可能重複使用同一套轉換邏輯；如果兩邊是分開的管線，就要做充分的測試。 監控應涵蓋特徵新鮮度、null 比例、分布漂移、線上服務延遲、training-serving skew，以及對下游模型的影響。治理則包括 PII 控管、資料血緣、淘汰機制與負責歸屬。

框架: 影響 → 研判 → 緩解 → 根本原因 → 預防

挑一個真正造成影響的事故：資料缺漏、指標錯誤、管線延遲、重複紀錄、儀表板壞掉、模型特徵出問題，或是影響到下游產品。開頭先講清楚誰受到影響、為什麼這件事重要。 接著說明你的研判過程：日誌、排程編排狀態、來源資料新鮮度、近期部署、schema 變更、資料列數、分區、資料血緣與下游相依關係。再描述你如何緩解問題：重新執行、回滾、修補、回補資料，或先向利害關係人發出提醒。 最有力的回答會包含預防措施。你是否加入了資料品質檢查、警示、重試、schema 合約、冪等寫入、runbook、資料血緣，或更好的部署管控？不要把責任推給上游團隊，要展現你對系統與溝通的當責。 最後談談你從中學到哪些關於可靠性的經驗，以及之後你的做法有什麼改變。

框架: 釐清 → 重現 → 追蹤資料血緣 → 解決 → 記錄

我會先釐清到底哪裡看起來不對：哪個指標、哪張資料表、哪段日期範圍、哪個儀表板、用了什麼篩選條件、預期的數值是多少，以及背後的業務理由。「資料有錯」必須先變成一個可以重現的問題。 接著把分析師的查詢或儀表板，和來源資料表及模型定義做比較，檢查粒度、篩選條件、join、時區、新鮮度、指標定義和近期變更，並用資料血緣追蹤上游相依關係。 如果資料真的有錯，我會修正並說明影響範圍；如果資料正確，只是定義和對方預期不同，就要對齊指標定義並補上文件；如果還有不確定的地方，我會說明目前已知的部分、正在檢查的項目，以及什麼時候會回覆進度。 關係很重要。分析師是資料平台的客戶，信任要靠快速、清楚、以證據為本的回應來建立。

框架: 影響 → 可靠性 → 急迫性 → 相依關係 → 槓桿效益

我會依業務影響、可靠性風險、急迫性、下游相依關係和槓桿效益來排序。壞掉的營收管線或法遵問題，通常優先於可有可無的儀表板模型；如果某項平台改善能讓很多團隊不再卡關，它也可能優先於一次性的需求。 我也會區分緊急事故、策略性的平台工作、利害關係人需求、技術債，以及重複性的維運雜務。如果團隊只顧著處理工單，可靠性和平台品質就會逐漸變差；如果團隊只顧著打造平台抽象層，業務團隊可能就會被卡住。 好的優先順序流程包括明確的負責歸屬、SLA、嚴重程度分級、與 roadmap 對齊，以及透明的取捨。我會說明正在做什麼、延後了什麼、原因是什麼，以及這樣會帶來哪些風險。