摘要
還記得第一次被資料量嚇到的瞬間嗎？這篇文章想聊聊我們怎麼從用木頭蓋資料倉庫，慢慢學會打鋼筋的過程——有些教訓現在看根本是血淚史。 歸納要點:
- 從土炮架構到銅器時代：那些年我們用shell script硬幹HDFS的日子，現在回頭看才發現——原來鋼筋比木頭耐用的道理，在資料工程也通用
- 當ETL需求暴增時，與其死守便宜老工具，不如學我們團隊偷偷試過的招：用Pig Latin把批量處理變成像在拼樂高，雖然手動但至少能喘口氣
- 技術債這東西啊...就像廚房油垢，平時覺得擦擦就好。等火燒屁股才懂，當年該把Hadoop那些『鋼筋』早點打進去的
如果要說數據傳輸的那些早期階段，可能得追溯到剛開始有人問起怎麼把瀏覽紀錄之類的資料移來移去，好像也沒多複雜。當時大概只有一兩台伺服器，有點像某些人形容的「原始社會」——工具其實不多，SCP這東西被拿來用也很自然。有人提過就直接在終端下指令，檔案就能從這邊飄到那頭。
但說真的，一直手動操作還是挺麻煩，偶爾還會忘了哪次漏傳。後來有誰寫了個腳本，不記得是不是某次晚上討論完、隔天就出現了。反正就是自動跑，每次都讓SCP自己把檔案搬到對面那台機器上。密碼問題嘛……最初幾回還真的是得一遍遍打，可過了沒多久，就有人建議換SSH金鑰登入，也省掉不少麻煩事，安全性聽說也比之前高一些。
想讓它變得更無縫，大致上就是設個排程吧。crontab應該用了好一陣子，每隔將近一小時自動執行。有時候腳本失敗，也不是每次都會發現——這種狀況大約只在偶爾才遇到。不過那時候其實沒人太在意細節，只要資料能順利傳出去，大家就覺得差不多夠用了。
但說真的，一直手動操作還是挺麻煩，偶爾還會忘了哪次漏傳。後來有誰寫了個腳本，不記得是不是某次晚上討論完、隔天就出現了。反正就是自動跑，每次都讓SCP自己把檔案搬到對面那台機器上。密碼問題嘛……最初幾回還真的是得一遍遍打，可過了沒多久，就有人建議換SSH金鑰登入，也省掉不少麻煩事，安全性聽說也比之前高一些。
想讓它變得更無縫，大致上就是設個排程吧。crontab應該用了好一陣子，每隔將近一小時自動執行。有時候腳本失敗，也不是每次都會發現——這種狀況大約只在偶爾才遇到。不過那時候其實沒人太在意細節，只要資料能順利傳出去，大家就覺得差不多夠用了。
有時候，簡單就是種方式。當初那套架構，其實沒啥複雜的花樣，就是樸素地把該有的工具拼起來——不貴、也不難懂。對於不少情境來說，好像這種粗淺組合反倒夠用了，也就沒人特別想去追求什麼昂貴又花俏的新玩意兒。不過，時間一久，資料轉移跟處理的需求陸續變多，一開始還只是小規模的搬移和基本ETL，後來突然變得頻繁起來。管理那些計畫的時候，會發現事情逐漸變得不好掌控。維護系統也慢慢地顯得吃力，大概就在那段期間，有些人開始思考是不是該重新檢視整體架構，要不要換個更能應付未來狀況的方法。
進入下一階段後，好像很多團隊都默默地離開了那種「土炮」時代。這也許可以叫做某種銅器年代？有人開始接觸到比以前堅固、耐用一些的技術，例如Hadoop就被不少單位採用過。有點類似於蓋房子多了幾根鋼筋，不再全靠木頭撐著。有趣的是，那陣子Pig和Pig Latin語言也逐步出現了，所以大批量數據處理好像一下子容易不少——雖然流程還是帶點手工味道。例如，用shell script把原始檔案丟上HDFS，這件事在當時算常見操作。總之，那階段並不是什麼徹底自動化，但大家也沒太多選擇，只能邊做邊摸索吧。
進入下一階段後，好像很多團隊都默默地離開了那種「土炮」時代。這也許可以叫做某種銅器年代？有人開始接觸到比以前堅固、耐用一些的技術，例如Hadoop就被不少單位採用過。有點類似於蓋房子多了幾根鋼筋，不再全靠木頭撐著。有趣的是，那陣子Pig和Pig Latin語言也逐步出現了，所以大批量數據處理好像一下子容易不少——雖然流程還是帶點手工味道。例如，用shell script把原始檔案丟上HDFS，這件事在當時算常見操作。總之，那階段並不是什麼徹底自動化，但大家也沒太多選擇，只能邊做邊摸索吧。
觀點延伸比較:
| 結論 | 說明 |
|---|---|
| 低程式碼工具的利與弊 | 簡化設計流程但需警惕小錯誤導致資料問題。 |
| 雲端架構下的數據流量隔離 | 未處理時會影響不同流程負載，增加複雜度。 |
| Apache Spark在即時處理中的角色 | 適合分散運算的大型串流資料，降低延遲。 |
| NiFi和NiFiKop的優勢 | 模組化、彈性部署並可獨立運行數據流，提高穩定性。 |
| 資料工程的工業化趨勢 | 減少對高技術人才依賴，使非專業人士能管理資料流。 |
)
當時 Apache Pig 負責讀取資料，然後就交給 MapReduce 做運算，像是篩選、加總這類的處理都有。有些人還記得，那時候結果通常會再丟回 HDFS ，接下來大概就是用 Shell script 來搬資料，有點像是把東西推給其他小組。雖然這一切勉強算是能跑得動，但很多流程其實還要靠人工寫腳本去維持。看起來那個階段才剛剛開始有點系統化，但手動部分還是佔了不少，感覺每次需求變多的時候都快撐不住。不過話說回來，好像正因為那些基礎打下來，後面才逐漸往所謂的工業標準靠近。
有印象的人應該記得那陣子 Hadoop 用在分散式儲存和 MapReduce 計算上，也讓大家處理資料轉換總算比較沒那麼吃力，只是 Apache Pig 有些地方真的不太容易上手——尤其當腳本越寫越長，再加上一堆 UDF（就是自己寫的函式）時，更複雜的轉換常常需要用 Java 來補足，但反而使維護變難了。有種情況一直困擾著，就是每次要搬移或整合資料時，不知道是不是設計本身就比較麻煩，問題好像也沒少過。
所以說，在這樣的架構底下，資料轉換雖然解決了一部分，可每當提到檔案傳輸和整合流程，也許還是會卡住；細節方面偶爾有人會討論，有的地方可能不是特別明確，到現在也未必全都搞清楚。
有印象的人應該記得那陣子 Hadoop 用在分散式儲存和 MapReduce 計算上，也讓大家處理資料轉換總算比較沒那麼吃力，只是 Apache Pig 有些地方真的不太容易上手——尤其當腳本越寫越長，再加上一堆 UDF（就是自己寫的函式）時，更複雜的轉換常常需要用 Java 來補足，但反而使維護變難了。有種情況一直困擾著，就是每次要搬移或整合資料時，不知道是不是設計本身就比較麻煩，問題好像也沒少過。
所以說，在這樣的架構底下，資料轉換雖然解決了一部分，可每當提到檔案傳輸和整合流程，也許還是會卡住；細節方面偶爾有人會討論，有的地方可能不是特別明確，到現在也未必全都搞清楚。
其實早些年，有人還用著那些老派的 Shell 腳本搬移資料，雖說勉強堪用，但一出事，要不是搞不清楚哪裡出錯，就是查半天也沒個頭緒。有時候，一些監控手段看起來蠻吃力，偶爾甚至得一行行手動追。更別說什麼即時處理，這方面光靠 Shell 或是 Apache Pig，好像本來就不太現實。
某個時間點，團隊開始討論是不是得換點新玩意兒。那陣子聽說有 Apache NiFi 這套工具，好像不少圈內人都在聊。它主打的是圖形化操作和自動化流程，看起來可以減省很多手工活，而且介面也挺直觀。有同事記得剛導入那會兒，氛圍有點像在嘗鮮，也或許帶了幾分好奇。
大致上，我們算是逐步從原本那些自己拼湊的腳本慢慢轉到 NiFi。一開始大家都抱著試試看的心態去摸索，有時候還會懷疑是不是真的比較穩。不過，不少人後來發現，用 NiFi 處理資料流確實方便了不少，特別是在調整流程、追蹤錯誤這些地方。雖然中間難免遇到一些小問題，但至少比原先那種土法煉鋼方式，多了一層保障。如果要說效果多明顯，好像也看場合——有人覺得很適合，也有人還是懷念以前簡單直接的做法。
至於規模啊、效能啊，那大概比舊方法提升了好幾成，可到底差多少，其實沒人仔細算過。回頭想想，每次重大改動總會有點未知數，只能邊做邊調整，沒有誰能保證哪個方案一定最好。
某個時間點，團隊開始討論是不是得換點新玩意兒。那陣子聽說有 Apache NiFi 這套工具，好像不少圈內人都在聊。它主打的是圖形化操作和自動化流程，看起來可以減省很多手工活，而且介面也挺直觀。有同事記得剛導入那會兒，氛圍有點像在嘗鮮，也或許帶了幾分好奇。
大致上，我們算是逐步從原本那些自己拼湊的腳本慢慢轉到 NiFi。一開始大家都抱著試試看的心態去摸索，有時候還會懷疑是不是真的比較穩。不過，不少人後來發現，用 NiFi 處理資料流確實方便了不少，特別是在調整流程、追蹤錯誤這些地方。雖然中間難免遇到一些小問題，但至少比原先那種土法煉鋼方式，多了一層保障。如果要說效果多明顯，好像也看場合——有人覺得很適合，也有人還是懷念以前簡單直接的做法。
至於規模啊、效能啊，那大概比舊方法提升了好幾成，可到底差多少，其實沒人仔細算過。回頭想想，每次重大改動總會有點未知數，只能邊做邊調整，沒有誰能保證哪個方案一定最好。
)
那個介面，剛開始看起來真的很直覺，拖一拖拉一拉就能搞定資料流，好像不用花太多腦筋。不過後來慢慢發現，其實背後還是藏了不少眉角。操作是方便沒錯，可要怎麼用才算妥當、效能會不會爆掉、機器資源分配到底要怎麼抓——這些都不是隨便摸一摸就通的。說到這裡，有人提過好像鍛造鐵器的時候也差不多，一開始只是覺得金屬很硬，但工匠們要花上將近幾十年的功夫才能玩得轉。NiFi其實有點類似，要真的運用順手，經驗和技巧少不了。
有段時間大家一直卡在怎麼把不同資料流隔開。有時候某條流程突然負載變重，整個叢集裡其他流程也會被牽連，資源調度變得更棘手——這問題不像表面那樣單純。至於最佳做法到底長什麼樣？目前大概只能說經驗累積到一定程度才比較有感覺吧。有些細節現在回想起來其實還不是很確定，也許哪天又得重新調整思路。
有段時間大家一直卡在怎麼把不同資料流隔開。有時候某條流程突然負載變重，整個叢集裡其他流程也會被牽連，資源調度變得更棘手——這問題不像表面那樣單純。至於最佳做法到底長什麼樣？目前大概只能說經驗累積到一定程度才比較有感覺吧。有些細節現在回想起來其實還不是很確定，也許哪天又得重新調整思路。
有時候，低程式碼工具在設計流程時確實讓操作變得比較直觀，可說是簡化了不少步驟。不過稍有閃失，例如一個小地方沒注意到，資料就可能出現讓人頭痛的問題。某些部署自動化還真的比預想中複雜，像是版本切換、回溯那類流程，後來也只好邊做邊修正，好讓整體效率不要掉太多。
至於數據流量隔離這件事，在雲端架構下，有觀察到如果沒有特別處理，不同流程的負載會互相干擾。本來以為搬進雲端後會輕鬆一點，但其實本地運算環境還是卡在即時反應上，所以只能再想一些辦法。
後來才覺得單靠原本的工具好像不太夠用，就決定加進Apache Spark。它其實不是那種真正意義上的即時流處理，比較偏向分批次（有人說微批次），但對於需要分散運算的大型串流資料，也許能達到接近可接受的延遲範圍。這樣一來，本地端那些大量即時數據的需求才比較不會卡住。
另外，NiFi帶來的新可能性也被討論不少。有些人提到它模組化又可以分散執行，資料流程搬去雲端似乎容易許多。擴充、串接系統什麼的，看起來比以前方便很多。但說到底，每個方案都只是暫時解決部分問題而已。
至於數據流量隔離這件事，在雲端架構下，有觀察到如果沒有特別處理，不同流程的負載會互相干擾。本來以為搬進雲端後會輕鬆一點，但其實本地運算環境還是卡在即時反應上，所以只能再想一些辦法。
後來才覺得單靠原本的工具好像不太夠用，就決定加進Apache Spark。它其實不是那種真正意義上的即時流處理，比較偏向分批次（有人說微批次），但對於需要分散運算的大型串流資料，也許能達到接近可接受的延遲範圍。這樣一來，本地端那些大量即時數據的需求才比較不會卡住。
另外，NiFi帶來的新可能性也被討論不少。有些人提到它模組化又可以分散執行，資料流程搬去雲端似乎容易許多。擴充、串接系統什麼的，看起來比以前方便很多。但說到底，每個方案都只是暫時解決部分問題而已。
)
資料工程這件事，早期跟現在的樣貌其實差滿多的。有一陣子大家都在往雲端搬，像是當時選了 GCP，那感覺有點像歷史課本裡頭那些航海家，一路摸索也不知道下個港口在哪。每到一個步驟，比如說怎麼規劃架構、定義資源名稱、標籤怎麼用，都得設一些規則，其實好像也沒誰能說哪種一定最好，主要是那會兒就是邊做邊修。
管理權限跟專案建立的規範，大概分了好幾階段才逐漸成形。記得自動化部署這塊，有人提議試試 Terraform，後來就慢慢變成主流選擇。等到搞定這些流程之後，監控花費的儀表板也出現了，不過功能是不是完全齊全，好像還有人有不同看法。
資料流那塊，當時 Apache NiFi 算是被推上了一個新高度，也不是說別無選擇，只是剛好碰上需求增加吧。有些團隊想要把 NiFi 的部署弄得更彈性，就嘗試用 NiFiKop 這套由 Orange 開發、開源的 Kubernetes 操作員。印象中，他們說這樣可以針對不同資料流量或比較重要的應用，各自開獨立叢集，用來隔離彼此。不過要說效果如何，有些案例似乎很不錯，也有地方還在摸索最佳做法。
整體來講，那陣子從討論架構開始，到各種命名和存取設定，再到自動化和成本追蹤，很多細節其實都不是一次就拍板定案，中間反覆調整也是常有的事。或許跟大航海時代一樣吧，每多走一步，就多學一些新東西。
管理權限跟專案建立的規範，大概分了好幾階段才逐漸成形。記得自動化部署這塊，有人提議試試 Terraform，後來就慢慢變成主流選擇。等到搞定這些流程之後，監控花費的儀表板也出現了，不過功能是不是完全齊全，好像還有人有不同看法。
資料流那塊，當時 Apache NiFi 算是被推上了一個新高度，也不是說別無選擇，只是剛好碰上需求增加吧。有些團隊想要把 NiFi 的部署弄得更彈性，就嘗試用 NiFiKop 這套由 Orange 開發、開源的 Kubernetes 操作員。印象中，他們說這樣可以針對不同資料流量或比較重要的應用，各自開獨立叢集，用來隔離彼此。不過要說效果如何，有些案例似乎很不錯，也有地方還在摸索最佳做法。
整體來講，那陣子從討論架構開始，到各種命名和存取設定，再到自動化和成本追蹤，很多細節其實都不是一次就拍板定案，中間反覆調整也是常有的事。或許跟大航海時代一樣吧，每多走一步，就多學一些新東西。
NiFiKop這個工具，說起來，最近在我們的數據流管理上算是帶來一些變化。它會自動部署流程，不管是在本地的那些舊有叢集，還是丟到Google Cloud Platform裡頭的GKE，好像都行得通。這種彈性讓擴展或調度變得容易不少吧，也有人覺得穩定性也高了一些。不過講白了，其實最大好處，大概就是日常維運沒那麼麻煩。
有趣的是，他們搞出一種隔離機制──每個比較要緊的數據流好像都能分開跑，各自獨立。萬一哪條線卡住或表現不佳，也不至於拖累其他關鍵任務。這招下去，有人說架構就顯得靈活又厚實，反正現在大數據時代嘛，難題層出不窮，總得想辦法應對。
後來平台重組之後，要加新東西什麼的倒是方便多了。有點像拼積木一樣，新元件隨時插進去也不太費事。比如DBT（那個用來做數據轉換跟追蹤流程的小工具），他們直接丟到GCP上的Kubernetes環境跑，又搭配Airflow排程、BigQuery存轉換紀錄之類的，都串接上去了。
話雖如此，一切也沒真的十全十美。走著走著才發現，有點像早期阿拉伯天文學家摸索星辰一樣，解決完眼前問題，又冒出新的疑惑。整體運作起來，是滿足需求啦，但仔細想想結構似乎變複雜了不少。有些地方甚至會讓人搞混，到底是不是非得這麼繁瑣，其實大家心裡可能都還在斟酌……
有趣的是，他們搞出一種隔離機制──每個比較要緊的數據流好像都能分開跑，各自獨立。萬一哪條線卡住或表現不佳，也不至於拖累其他關鍵任務。這招下去，有人說架構就顯得靈活又厚實，反正現在大數據時代嘛，難題層出不窮，總得想辦法應對。
後來平台重組之後，要加新東西什麼的倒是方便多了。有點像拼積木一樣，新元件隨時插進去也不太費事。比如DBT（那個用來做數據轉換跟追蹤流程的小工具），他們直接丟到GCP上的Kubernetes環境跑，又搭配Airflow排程、BigQuery存轉換紀錄之類的，都串接上去了。
話雖如此，一切也沒真的十全十美。走著走著才發現，有點像早期阿拉伯天文學家摸索星辰一樣，解決完眼前問題，又冒出新的疑惑。整體運作起來，是滿足需求啦，但仔細想想結構似乎變複雜了不少。有些地方甚至會讓人搞混，到底是不是非得這麼繁瑣，其實大家心裡可能都還在斟酌……
)
找到合適的人才這件事，似乎變得愈來愈不容易。像Java、GCP、Docker還有Kubernetes，這些技能很常見嗎？其實好像也不是，尤其當還要會Hadoop、Spark，再加上一些GitLab CI或者Terraform之類的工具，要全部都精通的人數量大概只有少數幾成，而且薪資通常也不低。有時候公司面試一輪又一輪，結果常常卡住；招聘難題讓很多團隊開始琢磨是不是該換種做法。
說到現在的資料工程，好像正慢慢變成另外一回事。有人講這叫做「工業化」時代，就是讓資料相關的需求者，不一定要靠著一大群專業工程師，就能自己動手搞定資料流。以前維護和運作成本拉高，有團隊估過，如果每個流程都自己寫，每年要管控的資料流加起來可能有將近上百條，光花在維運上的開銷就不少。有了這種新型態的平台或服務後，建置和管理流程彷彿變得沒那麼困難，也不用特地找那些技術門檻很高的人才。以往大家都是手動堆出一堆腳本，如今則好像更傾向於追求類似SaaS服務的簡便操作。
有些人說，新時代下建構資料處理流程已經比早期Shell script年代進步太多，但具體怎麼演變，有些細節大家記憶可能也沒完全一致。不過看趨勢，好像是漸漸從複雜走向親民，只是速度快慢、效果怎樣，各家觀察略有不同吧。
說到現在的資料工程，好像正慢慢變成另外一回事。有人講這叫做「工業化」時代，就是讓資料相關的需求者，不一定要靠著一大群專業工程師，就能自己動手搞定資料流。以前維護和運作成本拉高，有團隊估過，如果每個流程都自己寫，每年要管控的資料流加起來可能有將近上百條，光花在維運上的開銷就不少。有了這種新型態的平台或服務後，建置和管理流程彷彿變得沒那麼困難，也不用特地找那些技術門檻很高的人才。以往大家都是手動堆出一堆腳本，如今則好像更傾向於追求類似SaaS服務的簡便操作。
有些人說，新時代下建構資料處理流程已經比早期Shell script年代進步太多，但具體怎麼演變，有些細節大家記憶可能也沒完全一致。不過看趨勢，好像是漸漸從複雜走向親民，只是速度快慢、效果怎樣，各家觀察略有不同吧。
有時候，一家公司在面對資料增長的時候，會發現自己得慢慢去摸索怎麼把這些資訊用起來。其實現在資料工程這領域，說起來變化還挺多的——也許有人覺得每隔幾年就會冒出一兩樣新東西吧。有的人注意到像Apache Iceberg、Trino或是Apache Ozone這類工具，好像在圈內有被談論過，不過功能到底差在哪裡，有時也不是那麼容易分清楚。當然，也有人開始接觸Dataiku、Rakuten那種平台，說是支援分析處理，比傳統做法多了點彈性，但效果怎樣，好像也要看實際應用。
其實如果往近幾年看，資料虛擬化還有什麼多雲策略這些詞語，有點像最近才開始流行起來的。據說企業想藉著這樣的方式，多開幾條路線，不至於綁死在某一種系統上。不過是不是每個公司都能馬上吃透這套玩法，也沒什麼定論，只能說有部分業界人士觀察到一些新機會。
整體來講，資料工程好像一直都沒有停下腳步，但是不是所有人都感受到同樣的刺激與期待，就難講了。倘若哪家公司比較快去適應那些剛冒出來的新科技或新的思路——可能未來更容易利用數據達成自己的目標吧。但話又說回來，不少經驗似乎顯示，每條路徑都有它的不確定，所以真要談成果如何，也只能先看看情況再說。
其實如果往近幾年看，資料虛擬化還有什麼多雲策略這些詞語，有點像最近才開始流行起來的。據說企業想藉著這樣的方式，多開幾條路線，不至於綁死在某一種系統上。不過是不是每個公司都能馬上吃透這套玩法，也沒什麼定論，只能說有部分業界人士觀察到一些新機會。
整體來講，資料工程好像一直都沒有停下腳步，但是不是所有人都感受到同樣的刺激與期待，就難講了。倘若哪家公司比較快去適應那些剛冒出來的新科技或新的思路——可能未來更容易利用數據達成自己的目標吧。但話又說回來，不少經驗似乎顯示，每條路徑都有它的不確定，所以真要談成果如何，也只能先看看情況再說。
參考來源
《天生不愛動》讀後心得：人類懶惰是本性，我們為何要運動？
人類真正的問題出在我們具有舊石器時代的情緒、中古時代的習俗，以及上帝般 ... 殺出一條血路的人，他們不走尋常路，只專注在自我實現上，黑馬告訴我們，成功不只 ...
來源： Vocus【討論】奇幻戰鎚各種族首領與人物介紹( 新增斯納格拉．毒涎)
經過漫長的戰爭後勞恩最終被納垢領主" 水蛭" 菲斯圖斯( Festus the Leechlord ) 刺成重傷，後者隨後被趕來的弗拉德馮卡斯坦( Vlad von Carstein ) 所殺， ...
來源： 巴哈姆特
全部
資訊科技
相關討論