本文是 AC 助教 Shu-Ting 記錄自己踏入資料領域工作多年，對於資料工程與資料分析師實務工作的觀點及經驗分享，AC 獲得授權刊登，原文來自 Shu-Ting 助教的個人部落格「Shu-Ting | 資料科學漂流者」。
「資料分析和資料工程，有什麼不一樣？」
這個大哉問成為每個知道我過去三份工作職稱變化（Data Analyst → Data Scientist → Data Engineer）的人們必定會問的問題。這次，就用我個人的職涯經驗來回答這個問題吧！
閱讀本文的幾個小小提醒。
- 內容只會提到我實際運用上的工具、技術與知識，僅止於聽過但沒實際用過的部分就不多談。
- 撰文視角以我個人經驗為主，可能和網路上搜尋到的有所差異。
- 本文沒有談論任何機器學習（Machine Learning）或 AI，因此不會提到 Machine Learning Engineer 或任何和模型、演算法有關的事。
資料分析 Data Analysis｜從洞察到決策
資料分析是一個著重資料意涵理解和提取背後蘊含訊息的過程。透過剖析資料，找尋其中的模式、趨勢和洞察（insight），回應問題進而擬定決策。總結來說，資料分析的目標是打造一個完整的資料傳達過程，從量化角度切入，驗證某些對市場的觀察與假設，解決實際商業問題。
任務執掌
以下從資料傳達過程做逐步解析。
- 資料前處理（pre-processing）：很重要的前置作業。無論是從資料倉儲 、資料湖或是不曉得打哪來的一個 .csv 檔，針對超出合理範圍的不預期值（如出生年份填了未來日期）或遺漏空值都需要有所理解與對應處理，才能確保所取用的資料有可用性。還有一個很重要但常常被忽略的步驟「確保可重現性」，從資料前處理就應該要做好！簡言之，今天取得某種樣貌的資料開始進行分析報告，在未來的某一刻，應該要能夠分毫不差的取得同樣的資料，方便回溯及盤查。
- 探索資料（exploratory）：透過統計方法來描述和解釋資料。最基礎的就是掌握資料統計分布狀況，如平均值、標準差、四分位數等等。
- 資料視覺化（visualization）：將資料結果圖像化，使意涵更容易理解並傳達給他人。常見的有觀察趨勢的折線圖、長條圖，觀察分布的圓餅圖等。
- 提取洞察（insight）：視覺化後的下一步。分析者從數字、表格搭配視覺化圖表後，從中找出模式或趨勢回應問題。
- 報告和溝通（story telling）：資料傳達的最後一步。需要把分析結果以清晰的方式報告給決策者和相關部門。
交付產物
產物可以概略分為一次性產出和定時監測的儀表板。
- 一次性（ad-hoc report）：交付產物最常見的是投影片（slides）搭配會議說明。但我偏好用 Python 寫 Jupyter Notebook 作為成果直接報告，喜歡用程式人的方式做事。報告的聽眾/使用者沒辦法自己調整關鍵參數，只能口頭詢答。分析者一但面臨調參數再報告，最初強調可重現性就顯得很重要。我們都不會希望改過一版參數之後再改回去，結果就變得不一樣了。
- 資料儀表板（dashboard）：基本的視覺化圖表可透過 Excel/Google Sheet 產出。但資料量超過一定門檻後就需要搭配相關軟體了，我自己接觸過的包含 Metabase、Looker Studio。做成儀表板的好處是，讓使用者自行決定篩選條件、分析範圍，門檻值等等，想怎麼觀察都很彈性，不需要和分析師一來一往。
工具、知識與技能
- 工具：BI 軟體（Google Sheet：容易對資料加值運用；Metabase：免費開源；Looker Studio：搭配 BigQuery 便利）
- 知識：統計學、領域知識（domain knowledge，幫助自己掌握服務產業的「行話」）
- 技能：SQL、Python/R（能方便處理 dataframe 的語言都行）
資料工程 Data Engineering｜基礎設施搭建
資料工程著重的是建立和維護資料基礎設施，將來自企業內部各處的資料進行彙整蒐集，以確保資料的可用性、可靠性和效能。資料來源包含產品（網站、APP 等）、各部門業務衍生的資料或是其他第三方 API。資料工程是前述資料分析的關鍵上游，它確保資料處於可分析及可重現狀態。
任務執掌
- 資料蒐集（collection）：從四面八方獲取資料。我接觸過的內部資料有網站、APP，第三方資料則有 ERP、CRM、事件收集追蹤器等等。
- 資料儲存（storage）：建構系統以統一存放將來自橫跨各處的資料，方便後續運用。除了足夠大規模的團隊可能需要自建儲存系統外，多半是能夠考慮使用雲端服務例如 AWS 或 GCP 來完成。
- 資料處理（transformation）：大家最耳熟能詳的 ELT，包含萃取（Extract)、載入（Load）及轉換（Transform），用以確保資料的一致性和品質。
- 資料管線（pipeline）：打造一個穩固的流程，讓資料從源頭順利傳輸到目的地。方式有定時處理的批量（batch）和即時處理（streaming）兩種。採用手法會根據後續應用的場景需求而定。
- 提升品質與效能（quality & effectiveness）：在資料流量達到一定程度時，為了避免下游分析應用或產品應用端取用延滯（latency）過高，在儲存系統上就需要設計適當的索引（index）和分區表（partition tables）以應對效能需求。品質部分，則是在資料管線上設計監控機制，當資料量或資料內容偏離常態過多時加以示警，讓工程師能夠盡快維修。
交付產物
綜觀任務職掌，應該可以推斷出資料工程著重於建構高品質高效能的「資料處理流程/系統」，任何軟體工程師在乎的價值，包含程式碼品質、伺服器穩定、查詢效能、低延滯，資料工程師也都同等在乎。但有趣的是，資料工程師交付的不是軟體本身，而是可用的資料。因此我把資料倉儲及資料湖定位於「交付產物」。
- 資料倉儲（data warehouse）：用結構化（structured data）的方式儲存，查詢上自然就使用 SQL 即可，但也因此需要在寫入前就定義好資料表結構（schema），設計上較嚴謹但擴展性較資料湖差。
- 資料湖（data lake）： 資料以各種可能的形式寫入，包含結構化、半結構化和非結構化資料，使用彈性高，讀取時再作轉換即可。擴展性好，適合處理巨量資料。
實務上兩者可以並存，先以接近原始狀態（raw data）的模式送入資料湖，而後送入資料倉儲做結構轉換，以利後續分析及產品應用。混合模式兼容了取用彈性及設計嚴謹帶來的資料品質。
工具、知識與技能
- 工具：Airflow（排程自動化）、Kafka（串流資料處理）、Docker/Kubernetes（容器化技術）
- 知識：瞭解關聯式資料庫與非關聯式資料庫的特性差異，包含索引與分區表的建置，提升讀寫效能
- 技能：利用 SQL/Mongo 指令對資料源讀取，透過 Python 開發資料管線
分析工程 Analytics Engineering｜專為分析而生的工程需求
從資料分析與資料工程的描述可以看出，雖然同為資料科學工作流程的一環，但兩者關注點似乎差異頗大：分析端重視洞察與傳達，工程端則在乎流程、系統的穩定性。在兩者之間，有沒有灰色地帶的存在？
有的，就是分析工程（Analytics Engineering）。在組織較大，分工較明確的團隊中，偏重資料分析的職務對於資料管線、資料倉儲建構的環節或許較少涉獵；偏重資料工程的職務則較著力於流程的早期階段。但在光譜的中間地帶，有一群人致力於資料搬遷與轉換的環節，也就是資料處理 ELT 流程的 LT，是為了讓分析變得更順利。
他們穿梭在業務單位和資料分析師之間，既要充分瞭解商業面的訊息，又要掌握基本的工程運用知識，讓資料模型（models），也就是資料倉儲內的資料表建構地更加合用。Data Engineer vs Analytics Engineer: How to choose the career that’s right for you 這篇文章對於分析工程師和資料工程師的差異提出一些見解，也歡迎讀者參考。
在台灣的資料工作中，似乎還沒有看到太多 Analytics Engineer 的職務名稱出現，普遍還是以 Data Analyst / Data Scientist /Data Engineer 的頭銜來定義任務。不過，我認為任務性質類似 Analytics Engineering，或真正在從事這樣的職務的人，遠比掛上這個職務名稱的人多。
「職稱不重要，稱職才重要。」
當公司還在業務的初期發展階段，資料量還沒有龐大到需要糾結效能疑慮時，若能具備分析工程師的思維與職能，就足以讓分析的層次從單純的執行查詢提升到設計出具備商業見解的資料模型。而在我現今的職務範疇中，也負責開發及維護一個資料分析產品。當資料分析功能要產品化（data as a product）時，最前期的階段就是要提升資料模型的合用性與可維護性，讓產品以一定的可維護性交付到為數眾多的用戶手裡，這也正是分析工程關注的環節。
職涯小回顧｜我所在的位置
上述段落是以個人觀點整理出我對資料分析到資料工程這條光譜上的各個區段的認定。在我四年多的工作經驗中，因為服務單位的需求，接觸到的職能其實較接近分析工程。
在這樣的位置上，對企業各部門的理解面向會比較廣一些，涵蓋了業務端到工程端的領域。這個特點讓我能夠在不同層面上進行協調，並俯瞰整個業務運作。然而也因為這樣的特性，相較於商業思維更深厚，能夠提出有價值策略的商業分析師，或是工程底蘊較深厚的軟體工程師而言，鑽研的深度則較不足。回顧至此，感謝職涯旅途上協助過我的夥伴，從合作中讓我看到許多拆解問題的思維。同時，幾年的實務經驗讓我掌握了許多實用的技術與工具，也看見自己在解決問題的途中緩緩地成長與進步。
隨著職務角色的定位變化及業務需求，近期接觸到處理 streaming pipeline 的 Kafka，我在批量/即時資料流的差異間看見對於資料應用思路的差異，也意味著我正一步步地朝著光譜的工程端前進。除了奠基於熟悉的工具運用外，也期望自己要努力提升理論基礎，面對更加複雜和挑戰性的工程任務有穩定的表現。
參考資料
- IT 鐵人賽｜當代資料工程與資料分析系列
- Data Engineer vs Analytics Engineer: How to choose the career that’s right for you
