資料工程

資料工程師轉職專題:細節盤點

作為第一個經過完整開發流程的專案,我已經撰寫兩篇文章說明專案的特點與開發遇到的困難與挑戰。最後我想更細節的分享這個專案的各個環節,我們所做的決定和一些細節。我想這篇文章會更偏向「紀錄」,所以並未有太多的技術價值,但若你正好有需要可以作為參考。

目錄


相關連結

概述

本專案(相關閱讀:《六都寵物資源分析開發實錄》困難與挑戰)旨在透過蒐集六都寵物店家資訊,分析資源分布與商業潛力,並以視覺化儀表板呈現。

作為一個 End-to-End 的資料工程專案,我們建立了一套自動化的 Data Pipeline,涵蓋爬蟲、ETL、資料倉儲、分析到視覺化。

技術棧

領域 工具/技術 用途
資料獲取 Python Script, Google Maps API 網站爬蟲與 API 串接
ETL/ELT Python (Pandas) 資料清洗、轉換與格式化
資料庫 MySQL (GCP Cloud SQL/VM) 關聯式資料庫儲存
自動化排程 Apache Airflow 工作流調度與監控
雲端 & DevOps GCP (Compute Engine), Docker 雲端基礎設施與容器化部署
CI/CD GitHub Actions 自動化部署
BI 視覺化 Tableau 互動式儀表板製作

技術架構圖

大數據架構下的資料庫設計與工程

在學習資料工程的過程中,雖然沒有特別區分,但從講師的敘述和某些技術中,隱隱可以察覺「大數據」和一般的資料工程是有區隔的,不單單只是「資料變多」而已。所以雖然不在課程內,但我另外又搜尋了一些與大數據有關的資料,包括大數據下的資料庫設計、大數據下的資料工程等。除了分享也作為筆記,讓自己可以重複複習關於大數據的相關知識。

目錄


簡介

在軟體工程的世界裡,資料庫往往是系統的瓶頸所在。當資料規模從 GB 成長至 TB 甚至 PB 等級,我們面臨的不僅是儲存空間的挑戰,更是計算能力的典範轉移 (Paradigm Shift)。

1. 大數據的特殊性 (Volume, Velocity, Variety)

傳統單機資料庫(RDBMS)依賴 Vertical Scaling (Scale-up),透過升級 CPU 和記憶體來提升效能。然而,硬體升級有其物理極限。大數據架構的核心在於 Horizontal Scaling (Scale-out),利用數百甚至數千台商用伺服器組成叢集,共同處理龐大的資料集。

2. 分散式架構的本質

在大數據領域(如 Hadoop 生態系、Spark、Cloud Data Warehouses),我們遵循 「分而治之 (Divide and Conquer)」 的哲學:

  • 儲存與計算分離 (Storage-Compute Separation):現代架構傾向將資料存在物件儲存(如 S3, GCS, HDFS),計算資源(如 Spark Executors)則是動態調配的。
  • 移動計算而非移動數據:由於網路 I/O 是最大的效能瓶頸,我們盡可能將程式碼派發到存放資料的節點上執行,而非將資料拉回中心節點處理。

資料庫設計模型

理解資料模型的適用場景,是架構師進行技術選型(Tech Stack Selection)的第一步。

1. 一般資料庫模型 (General Purpose / OLTP)

這些模型通常應用於應用程式後端,強調交易的即時性與一致性。

  • Relational Model (RDBMS)
    • 代表:MySQL, PostgreSQL, Oracle。
    • 特性:嚴格 Schema、ACID 交易保證、使用 SQL。
    • 適用:核心業務系統(Core Banking, ERP),資料一致性要求極高的場景。
  • Document Model
    • 代表:MongoDB。
    • 特性:Schema-less (BSON/JSON)、支援巢狀結構、開發迭代快。
    • 適用:內容管理系統 (CMS)、產品目錄 (Catalog)、屬性高度動態的資料。
  • Key-Value Model
    • 代表:Redis, DynamoDB。
    • 特性:Hash Table 結構、O(1) 讀寫延遲。
    • 適用:快取 (Cache)、Session Store、高併發計數器。
  • Graph Model
    • 代表:Neo4j。
    • 特性:以節點 (Node) 與邊 (Edge) 儲存關係,解決遞迴查詢效能問題。
    • 適用:社交網絡分析、推薦引擎、路徑演算法。

2. 大數據與資料倉儲模型 (Analytical / OLAP)

當場景轉向數據分析時,寫入效能不再是首要考量,查詢吞吐量 (Throughput)歷史資料整合 才是重點。

資料工程師轉職專題:挑戰與難點

有時候發現錯誤比做對更重要,因為對的時候不會知道自己是怎麼對的,但錯的時候一定會找出錯誤的原因。開發經驗的寶貴不只是學習新技術或工具,更重要的是不斷嘗試錯誤的經驗。本文會分享自己在開發轉職專題時遇到的困難與挑戰。(建議搭配建議搭配轉職專題介紹一同閱讀)

目錄


相關連結

Airflow 挑戰(一):迴圈流程

這個問題發生在要將爬蟲程式轉換成Airflow的dag程式時遇到的。由於專題的資料涉及許多「縣市」、「行政區」、「店家類別」、「寵物類別」、「日期」等參數的變化,所以在起初撰寫爬蟲時,我使用了多個迴圈來處理這些參數,可以快速的掃過所有排列組合。例如:

# 以日期作為啟動條件,接著搜尋所有城市與寵物類別的排列組合

while start < today:
    for city in city_list:
        for animal in animal_list:
            ## 爬蟲程式邏輯.
            ## 爬蟲程式邏輯..
            ## 爬蟲程式邏輯...
            ## 且變數可以多次使用,例如存檔檔名
            file_name = f"{start}_{city}_pet.csv"

這樣的寫法方便又快速,但是在編寫dag程式時卻行不通。原因如下:

  • 在dag中是以函式作為pipeline的節點,如果要為完整流程設立節點,就必須將程式拆成多個函式。
  • 但是迴圈本身是一個不可拆分的流程,一旦執行就是完整的一圈,無法把單次迴圈再切成上半和下半,也沒辦法切成前10圈和後10圈。
  • 所以如果要在dag中使用迴圈,那整個迴圈就只會有一個節點。這樣的問題是:如果中途出錯了就必須從第一圈重跑,這就失去了Airflow錯誤重試的特點。

解決方法

我的解法意外的單純:放棄迴圈,改為各自獨立的流程。Airflow是支援平行處理的,所以可以將原本的每一圈都獨立成單獨的流程,當所有流程都完成,再將資料合併成一個檔案或DataFrame做後續處理。有兩種寫法可以達到相同的效果:

寫法一:土法煉鋼

data_NTP_dog = S_create_post_data(dict_name=data_dict_NTP, ani="0")
data_NTP_cat = S_create_post_data(dict_name=data_dict_NTP, ani="1")
data_TPE_dog = S_create_post_data(dict_name=data_dict_TPE, ani="0")
data_TPE_cat = S_create_post_data(dict_name=data_dict_TPE, ani="1")
data_TYN_dog = S_create_post_data(dict_name=data_dict_TYN, ani="0")
data_TYN_cat = S_create_post_data(dict_name=data_dict_TYN, ani="1")
data_TCH_dog = S_create_post_data(dict_name=data_dict_TCH, ani="0")
data_TCH_cat = S_create_post_data(dict_name=data_dict_TCH, ani="1")
data_TNA_dog = S_create_post_data(dict_name=data_dict_TNA, ani="0")
data_TNA_cat = S_create_post_data(dict_name=data_dict_TNA, ani="1")
data_KSH_dog = S_create_post_data(dict_name=data_dict_KSH, ani="0")
data_KSH_cat = S_create_post_data(dict_name=data_dict_KSH, ani="1")

上述的寫法簡單粗暴,就是將程式碼重複編寫,只是帶入不同參數,好處是不會有什麼問題,只是寫好後最好再次檢查,如果用複製貼上容易有漏換的參數。另一個缺點是看起來冗長,視覺化流程圖也會看起來很龐大複雜

資料工程師轉職專題《六都寵物資源分析》開發實錄

這是我在參加資料工程師轉職培訓班時開發的專題作品,我的小組一共有五人,剛好大致可分為「資料工程組」、「資料分析組」兩部分,而我是專注在資料工程方面的開發。經過三個月的學習與開發,這個專題已經趨於完成,所以撰寫此文記錄開發的過程,並分享一些心得給或許也計劃要轉職的夥伴。

目錄

  1. 相關連結(Link)
  2. 專題簡介 (Project Overview)
  3. 技術選型 (Technical Stack)
  4. 技術架構 (Architecture Diagram)
  5. 爬蟲 & ETL:資料獲取與挑戰
  6. Airflow 自動化
  7. 雲端部署:VM、Docker 與 CI/CD
  8. 結語

專題概覽與技術選型

1. 專題簡介 (Project Overview)

本專題的最終目的是「分析六都寵物資源的分布情形」,而作為資料工程師的任務就是找到資料滿足這項需求,並且要能夠自動化運行

2. 技術選型 (Technical Stack)

以下是我們選擇的工具和技術。

類別 工具/技術
程式語言 Python
資料庫 MySQL
雲服務 GCP
自動化 Airflow
CI/CD GitHub Action
部署 Docker

資料管線架構與實作

3. 技術架構 (Architecture Diagram)

以下是本專題的技術架構圖,這是一個典型資料管線

技術架構圖

  1. 資料擷取 (Extraction): 透過 Python 程式爬取資料,存入 Data Lake (GCS 及 VM 硬碟)。
  2. 資料轉換 (Transform): 使用 Python 的 Pandas 進行資料清洗與格式統一。
  3. 資料儲存 (Loading): 將清洗後的資料存入 Data Warehouse (MySQL)。
  4. 分析與呈現: 後續分析皆來自 MySQL,最終使用 Tableau 進行視覺化呈現。

4. 爬蟲 & ETL:資料獲取與挑戰

我們資料爬取方式主要有兩種: