我的資料工程轉捩點，與數據中台

2018 年，阿里巴巴對社會輸出「數據中台」這個價值體系，聲稱這樣的技術架構可以解決業務與開發效率的不對稱性、落實「數據為本」、極大化企業資料價值。

到了 2020，流行的可能是「拆中台」，將數據中台切割成一堆不同的中台：數據中台、業務中台、技術中台、AI 中台、搜尋中台、知識中台，藉以滿足各種不同組織當中的應用情境，彷彿任何東西都可以是中台、任何問題都可以被中台解決。

上篇我會先回顧自己的經驗，到了下篇《從五個切入點看數據中台的必要性》再來拆解技術中台是什麼、它要解決什麼問題，以及它的侷限性。

從資料科學到資料工程的轉捩點

很多人以為我是資料科學專業，因為我寫的文章跟資料科學比較相關，而我的確也是跟機器學習本科相關的研究領域出身；但其實我做資料工程的時間，甚至比資料科學還久。之所以資料科學的文章寫比較多，純粹是因為科普比較容易寫到，而我也沒有很愛寫技術細節。

在約莫十年前，AI 還沒成為現今人人琅琅上口主流的技術時，我的研究就已經在這個領域，而第一份工作也剛好能用上專業。那為什麼從科學走到工程，或許就是很多人會想知道的問題，畢竟資料科學在很多人眼中是如此地性感又有趣。

建立資料服務團隊

我們很早就有團隊去負責基礎資料平台，也就是 Data Lake 的擴展性與可靠性，但對於機器學習應用，中間需要的業務儲存、API 提供、資料整理等等大量「接水管」的工作，一直都是個大缺口。

當時的情況是我身為資料科學團隊的一員，發現所有人都花了太多時間在資料處理與軟體開發，導致效率低落。換句話說，我們有資料大平台（後台）、也有資料科學家針對各種應用場景去建模、做實驗，唯獨缺了中間的角色。

有句話說得很好，大意是「誰被這件事情搞得最痛苦，誰就會有動力把它做好」。在有人專職做這些事情之前，都是我們自己在做，而我並不排斥自己做，也認為朝這個方向去努力是有價值的，於是就在團隊內提案，逐漸取得資源、做出一點成績，最後很幸運地成立一個獨立的小團隊來做這些「中間」的事情。

在那之前，我們的機器學習工程師必須一個人從管理機器、資料流、資料倉儲一直到模型；後來在一兩年內，很快地成長到約十人規模的團隊（以當時的公司規模來說，這算是相對大的工程團隊），來分擔這些比較偏向工程上的問題。

而由於這個團隊的特殊性（跟應用極為緊密、也同時能從工程角度處理問題），一直都處理了很多的核心業務，能取得這樣的成果，是一開始所沒有想到的。

在大數據平台與應用中間的角色

數據中台的概念，其實跟我的職涯有很高的相關性，但我做的也不完全是中台，而是作為應用與大數據平台中間的團隊，提供各種資料服務。

大概在 2017 - 2018 的時候，我當時任職的公司就已經有了類似的組織架構，因為我們的確有這樣的需求，要解決類似的問題。

有趣的是，我認為這樣的團隊也應該存在於不少組織當中，只是「中台」的概念太抽象而遙不可及，所以或許大家沒意識到這是同一件事情。

說穿了，這個團隊無非是在公司組織的資料平台（底層）與資料科學（應用）中間，再創一個團隊，既能從工程角度處理資料，也能從應用角度去服務資料科學家與市場客戶。

並非「我們要數據中台，所以有了數據中台」，而是我們有這樣的需求，所以成立一個團隊開發各種資料服務，差別是我們沒有把它命名為「數據中台」。

然而，這個差別並非只是名字上有意義，也反映出我（們）的目的性不夠有野心，我離開的時候還沒成為一個真正的「平台團隊」：比較多的時候我們做的是滿足單次功能的需求，離打造出一個真正的平台還有些距離；相反地，阿里的名詞太有野心、太業務銷售導向，以至於多數人都不知道他們高大上的名詞後面到底實際上是玩什麼技術把戲，因為重點不是技術。

中間平台的泛用性不夠、組織規模小，無法達到規模效益

究其原因，我認為一部分是因為業務需求本質上要的數據性質差異太大，很難有一個中台滿足所有需求；再加上工程人力的限制，在還大量技術債的同時，我們即使努力做好了一個平台，也趕不上新的應用場景。

畢竟阿里巴巴當時應該有上萬名員工，光是喊一個中台可能就投入了上百人、牽扯到上千人的組織改動，而當時我們整間公司也不過一兩百人而已。

不可諱言我的能力有限，無法再取得更多資源、把這個團隊的使命做得更好，這也是當時的一個小遺憾；但公司從三十人成長到三百人的路上，以及後來成為資料服務團隊草創的成員，我可能是整間公司當中，對於資料服務的需求演進體會最深的人之一。

從我的經驗你也可以發現，像這樣業務場景變化很快的新創，規模也不夠大，要導入中台概念是很困難的，因為業務邏輯都還沒有定下來，就算花了重本做了中台，很可能又要打掉重練；而同時間把人力成本拿去開發業務邏輯，即使會增加一大堆技術債，卻有可能創造更多營收，替公司續命、取得下一波募資。

即使是現在回頭看當時的狀況，不做數據中台，不管在商業上還是技術上，都是很合理的選擇，做了之後浪費的可能性非常大，這也是為什麼阿里喊了那麼多年，實際上真正用他們的中台解決方案，並且成功解決組織問題的企業可能也寥寥無幾的原因。

中台無所不在，但可能沒那麼高大上

說穿了，中台的工作，你我每天日常都在做，差異是中台做到把各種應用場景都考慮進去、將重複的部份歸納成一套可以快速隨著應用更改的平台。

我們常將資料工程比喻成水管工，如何將水管工的工作，轉變成一個水管平台、甚至建立一個大水管基地，連結各個水管平台，快速達成業務目標，都是我們不斷在追求與掙扎的現實。

這需要長久的經驗累積，以及不斷的組織調整，最重要的，還要高層的買單。比如阿里提出來的中台，就是一個如此龐大的組織集多年經驗大成之後，進化成最適合他們的終極型態。

我喜歡《不做中台當然會死》這篇文章當中的一句話：

小組的格局，可以讓科室受益，科室的格局，可以讓部門受益，部門的格局，可以讓公司受益，公司的格局，可以讓社會受益，阿里只是想玩把大的而已。

如果我們把類似的商業需求化繁為簡，整理成一個能夠有彈性重用的 API 或是資料庫，那不也是一個「微中台」嗎？雖然這樣的「微」中台在規模與架構上，很難說跟阿里提出的「大」中台比擬，但若從本質上去看，要解決的業務需求卻是同樣的。繞了一圈發現回歸到了本質，我喜歡這樣的思考過程。

下一篇《從五個切入點看數據中台的必要性》我會輔以自己的經驗，從不同角度切入是否真的需要數據中台。

原文連結東京疊塔