1.4　數據中臺建設方法論總綱

如前所述，數據中臺強調的是數據倉庫和大數據平臺的建設方式。實際上，不能簡單地將數據中臺當成一個技術問題。建設數據中臺必須要有技術和方法論。就像云計算一樣，虛擬化是云計算的核心技術，但是如果要將公司上云、IT系統云原生化，還需要一整套以技術為基礎的方法論來引導。舉例來說，如何理解云原生中的重要概念“微服務”？傳統的軟件開發是把所有功能放到一個大型軟件中，而微服務的概念是解耦，即把相對集中的功能作為一個微服務來開發。微服務的好處是可以單獨測試和部署，微服務間通過API進行通信。微服務最好的載體是容器，容器是一項輕量級的虛擬化技術，不僅產生和消亡的代價很低，而且具有提供資源隔離等便于發布和管理的特性。微服務+容器加速了軟件的開發、測試、生產和發布流程。但僅有這兩項技術還不夠，還要有DevOps來實現自動發布和穩定高效的系統運維，以輕松部署微服務和容器應用。同時，需要一個CI/CD架構來持續集成和持續發布，把代碼提交到代碼倉庫后，自動觸發微服務構建、容器構建及打包過程，然后發布到半生產系統進行集成測試，最后進入生產系統進行部署。這就是一整套的技術和方法論。

同理，打造數據中臺也必須有一整套的技術和方法論的指導。我們先在這里簡單介紹一下，第6章會更加詳細地闡述。

（1）業務驅動，快速落地

所謂業務驅動，就是在建設數據中臺的時候，一定要從企業的業務痛點、開發新業務的需要或者管理的需要出發，一步一步來，而不能期望一蹴而就。這是因為，數據中臺的建設應該是先從0到0.1，要很快見效，不斷迭代，分階段地逐漸體現出數據中臺的價值。如果能夠快速解決各部門的業務痛點和需求，各個部門才會積極響應數據中臺的建設。而且從工程師的角度來看，這樣開發的服務不僅部門內部可以使用，公司其他部門也能用到。在能力得到大家認可后，其他部門的工程師還會幫助調試這個項目，一舉兩得。當其他部門的工程師也開始這樣發布服務時，就形成了良性循環。貫徹數字化運營的理念，能夠不斷從數據中提取新的價值，這樣才能充分調動各個部門使用數據中臺的積極性。

（2）頂層架構設計及數據規范

在確定有業務痛點，需要相應的數據能力來解決問題的時候，首先必須梳理頂層的組織架構和業務架構，并確定全局的數據架構和數據規范。值得注意的是，這里并不需要進行全局的業務梳理、數據梳理，因為我們在確定頂層架構和數據規范之后，可以根據具體的業務需求來梳理專門的業務流程和相關數據。只要有合適的頂層架構和數據規范并貫徹執行，系統中就不會出現數據孤島。

（3）平臺管理，由工具來指導數據能力的抽象和共享

如果實現數據能力的抽象和共享需要建立大量規則，需要復雜的培訓，還要小心使用，那么這個數據中臺注定是很難長期演進的。數據中臺的建設應該以提供一系列方便好用的工具和流程為目的，讓工具引導人來完成工作，而不是靠人手動操作。例如，添加一個新的數據源，對現有數據源進行修改的時候，相應的工具應該能自動完成這個數據源相關的管理工作（元數據采集、監控、通知），而不是讓使用人員手動添加很多相關的配置。

（4）明確的責權利制定，并由工具來配合責權利的管理

任何一個系統的有效執行都需要參與人員的高效管理，高效的管理需要明確的責權利定義。特別是數據中臺這種幾乎涉及公司所有部門的體系，參與各方的責權利必須明確。一個常見的問題是，數據中臺和大數據平臺團隊的價值無法明確體現，卻要承擔整個系統的高效、穩定、正確運行，而這個系統很多時候要運行來自業務部門的應用和服務。如果不將各個部門的責權利定義清楚，最后就會陷入相互推諉的境地。這是一個管理問題，但是也需要相應工具的支撐。

（5）必須是一個安全、高效、穩定、可擴展的系統

實際上，中臺并不是一個新概念，只不過以前受制于IT技術，企業無法建立安全、高效、穩定、可擴展的平臺。如今，借助云原生、容器等技術，構建這樣的系統已經變得非常可行。有了這些技術，再加上快速穩定的DevOps和CI/CD流程，整個應用開發和部署變得更快捷，從開發到上線的流程變得更加流暢，因此數據中臺建設最好的開發基礎就是云原生架構。而且，容器天然具有資源和數據的隔離性，可以很好地保證系統的安全性。

在云原生架構下做數據服務有天生的好處，就是以微服務和容器化的方式發布數據服務，能夠實現非常快速的部署和迭代。另外，數據中臺能夠實現數據服務的彈性擴展。在容器編排如Kubernetes等架構下，一個操作就可以把一個數據服務容器實例變成多個實例，從而充分滿足系統的可擴展性。因此，數據中臺的建設一定要基于云原生和容器。