我們是怎麼從一個 Shell Script，搞到整個 GCP 大架構的？
今天要來聊聊一個蠻有趣的話題，就是一個資料工程專案是怎麼「長大」的。這不是那種教科書上畫好的完美路線圖，更像是一部…嗯，一部充滿意外跟掙扎的演化史。一切的開頭，真的就只是一個超級簡單的需求：把一些伺服器上的資料搬來搬去，好做成報表。
我自己是覺得，很多人在看技術演進的時候，都只看到「哇，新工具好酷！」，但很少人去聊那個「為什麼非得換不可」的痛苦。老實說，每一次架構的大改版，都不是因為我們想玩新玩具，而是舊的方法已經痛到不行了，真的。這整個故事，大概就是一部血淚斑斑的…痛點驅動創新史吧。
重點一句話
專案的演進從來就不是一條直線，它是一連串為了解決當下最痛的問題（從手動傳檔、處理不完的資料、到系統互相干擾），而被迫做出的選擇，最後才慢慢長成今天這個複雜但又強大的樣子。
石器時代：SCP 與 Crontab 的美好時光
一開始，真的超單純。需求就是要從 A 伺服器把資料搬到 B 伺服器。那…用什麼？想都不用想，就是 `scp` 啊。這就像遠古人類發現了石頭可以當工具一樣直覺。
但你總不能每次都手動下指令吧？很煩。所以我們就寫了一個小小的 shell script，把 `scp` 包起來。為了不用每次都打密碼，就設定了 SSH key，讓它自動登入。搞定。
最後一步，用 `crontab` 設定好排程，每小時自動跑一次。完美。簡單、有效，而且幾乎不用錢。在那個時候，這就是最棒的解決方案了。有時候，最基本的工具真的就夠用了，根本不需要什麼花俏又昂貴的方案。
…好景不常。需求開始爆炸性成長。一下要傳這個、一下要處理那個，ETL 的請求越來越多、越來越複雜。原本那個小小的 script 根本管不住了，系統維護變成一場災難。這時候我們才意識到，不行，得重新思考整個架構了。一個新的時代要開始了。
青銅器時代：走入 Hadoop 與 Pig 的結構化…陣痛
當需求演變得越來越複雜，我們就不能再用石斧了，得進入「青銅器時代」。這時候，我們引進了更強壯、更「專業」的工具：Hadoop。還有一個很酷的東西叫 Apache Pig。
Hadoop 就像一個超大的倉庫（HDFS），可以把所有亂七八糟的原始資料都先丟進去。然後，Apache Pig 用一種叫做 Pig Latin 的語言，把這些資料做處理，像是過濾啊、加總啊這些。這背後其實就是跑 MapReduce，在當時聽起來就很厲害。
所以整個流程變成這樣：
- Shell script 繼續負責把資料從外面搬進 Hadoop 的 HDFS。
- Apache Pig 去讀 HDFS 裡的資料，用 MapReduce 處理完。
- 處理好的結果，再寫回 HDFS。
- 最後…沒錯，又是 Shell script，把處理好的資料從 HDFS 搬出去給其他團隊用。
你看，雖然開始有結構了，但整個流程還是很「手工」。很多地方都還是靠 script 串起來。而且說真的，用過 Apache Pig 的人可能都知道…寫那個腳本，特別是又要自己寫 Java 的 UDF (使用者自訂函數) 來處理複雜邏輯的時候，維護起來真的是一場惡夢。
更重要的是，它解決了資料「處理」的規模問題，但「傳輸」跟「整合」的痛點還在。那些 Shell script 非常不可靠，很容易出錯，而且出了錯你很難追查。再加上，大家開始想要「即時」看到資料，這對 Pig 或 Shell script 這種批次處理的模式來說，根本是不可能的任務。
就在這個時候，一個改變遊戲規則的工具出現了：Apache NiFi。
鐵器時代：圍繞 Apache NiFi 打造的資料中樞
我們那時候真的超興奮，決定要來一次大遷徙，把那些手工的 Shell script 全部換成 Apache NiFi。NiFi 最吸引人的地方就是它那個圖形化介面，用拉的、用點的，看起來好像很簡單，就能設計出一個資料流。
一開始用起來真的很美好，覺得自己找到了神器。但…就像鐵器雖然強大，但也更難駕馭。我們很快就發現，NiFi 看似簡單的背後，水超深。你需要對它的運作原理、效能調校、資源管理有很深的理解。
第一個踩到的大坑就是「資料流隔離」。我們把好幾個 dataflow 都放在同一個 NiFi 叢集上跑，結果一個流量大的 flow 一塞車，整個叢集上的其他 flow 全都跟著變慢甚至停擺。哇，這下代誌大條了。另外，雖然是 Low-code，但你在介面上一個小小的設定錯誤，可能會對業務資料造成毀滅性的影響。還有，要怎麼做自動化部署跟版本控制，也比想像中複雜很多。
這段期間，為了滿足一些即時運算的需求，我們還加上了 Apache Spark。雖然 Spark 嚴格來說是微批次（micro-batching）而不是真的 real-time，但它的延遲已經低到我們可以接受了，處理串流資料很給力。
不過呢，導入 NiFi 也意外地幫我們打開了通往「雲端運算」的大門。它那種模組化、分散式的設計，讓我們後來要把資料流整合到雲端環境時，變得順利很多。
古典時代：邁向雲端與 Kubernetes 的現代架構
這大概是整個演化史上最大的一步：全面遷移到 GCP (Google Cloud Platform)。這就像古代航海家要出航尋找新大陸一樣，每一步都得小心翼翼。
上雲不是把機器搬過去而已，而是整個思維都要改變。我們要重新設計架構、定義資源怎麼命名、標籤怎麼貼、權限怎麼管…這些事情聽起來很無聊，但沒做好的話，後面就是無盡的混亂跟驚人的帳單。
在雲上，我們把 NiFi 的用法又提升到一個新層次。我們用了一個叫 NiFiKop 的開源工具，把它跑在 Google Kubernetes Engine (GKE) 上。這讓我們能做到以前在自己機房裡夢寐以求的事：為每一個重要的資料流，都建立一個「專屬」的 NiFi 叢集。
這就是真正的「隔離」。A 專案的資料流再怎麼爆量，也絕對不會影響到 B 專案。這給了我們前所未有的穩定性和擴展性。
這個架構也讓我們可以很輕鬆地去實驗一些新東西，像是 dbt (Data Build Tool)。我們把它部署在 GKE 上，用 Airflow 來調度，再把結果存在 BigQuery。整個流程變得非常現代化。
我們建立的架構對照表
講了這麼多，我把它整理成一個表，這樣看就比較清楚每個時代到底在幹嘛，還有我們付出了什麼代價。
| 時代 | 核心工具 | 優點 (當時啦) | 痛點 (然後就...) | 團隊技能要求 |
|---|---|---|---|---|
| 石器時代 (史前) |
Shell Script, SCP, Cron | 超簡單、零成本、馬上就能用。 | 需求一多就炸了，無法管理、沒有監控、容易出錯。 | 懂 Linux 基本指令就好。 |
| 青銅器時代 | Hadoop (HDFS), Apache Pig | 可以處理 TB 等級的巨量資料，感覺很專業。 | 寫 Pig 和 Java UDF 超痛苦，維護地獄。資料傳輸還是靠 script，不可靠。 | 要懂 Java、Hadoop 生態系，開始變難了。 |
| 鐵器時代 | Apache NiFi, Apache Spark | 圖形化介面！資料流變可視化，也開始能做串流處理。 | 看似簡單但水很深，容易互相干擾，部署和維運比想像中複雜。 | 要精通 NiFi/Spark，還要懂資源調校，門檻更高。 |
| 古典時代 (雲端) |
GCP, GKE, NiFiKop, Terraform | 真正實現了隔離！彈性擴展、高可用性，想開新服務超快。 | 太複雜了！而且雲端費用如果沒管好，會變成錢坑。 | Java, GCP, Docker, K8s, Hadoop, Spark, CI/CD, Terraform... 這是要找神吧？ |
啊…我們好像把系統搞得太複雜了
是的，你沒看錯。走到這一步，我們回頭一看，才驚覺…我們打造出一個超級強大的平台，但它太複雜了！
這就帶來一個全新的，也是最致命的問題：找不到人。
你要找一個工程師，他要精通 Java，又要懂 GCP 雲端服務，還要會寫 Docker 跟 Kubernetes，同時不能忘記 Hadoop 跟 Spark，對了，最好還要會用 Terraform 做 IaC (基礎設施即程式碼)，然後 Gitlab CI/CD 也要熟…。
說真的，這種人根本是神獸級的，超級稀有而且超級貴。這在台灣的徵才市場尤其明顯，很多時候技能樹點到這麼滿的人，早就被大公司或外商搶走了。相較之下，像是美國那邊，人才庫雖然大，但這種複合型人才的薪資也是水漲船高。這讓我們意識到，技術最強的架構，不等於對公司最好的架構。我們必須再次進化。
工業時代：邁向「資料工程即服務 (Data Engineering as a Service)」
這就是我們現在正在努力的方向。目標是把我們前面辛辛苦苦建立起來的這套強大能力，打包成一個「服務」或「產品」。
簡單講，就是讓一個懂資料、但不一定是頂尖後端或 DevOps 工程師的人——比如說，資料分析師或懂 SQL 的 PM——也能透過簡單的介面，自己去建立、管理資料流，而不需要後面跟著一整票貴得要死的工程師團隊。
這不只能解決人才問題，也能大幅降低建立新資料專案的成本。當創建一個 data flow 的成本，從幾個人月的工作，變成幾天的設定時，整個公司能做的事情就完全不一樣了。這才是真正的規模化。
好啦，這趟旅程大概就是這樣，還在繼續往前走。不知道你的團隊現在是卡在哪一個階段？是還在跟 Shell Script 奮鬥，還是已經開始被雲端帳單追著跑了？可以在下面留言分享一下你的故事！
