4.3　數據能力中臺化階段

此時，企業已經進入了數據管理的高級階段，需要全局的數據治理、數據能力的復用和共享以及云原生架構的支撐。在這個階段需要解決的一個重要問題是如何避免數據孤島和應用孤島。

應用場景：為什么會出現數據孤島和應用孤島

部門A為了解決一些大數據問題，采購了廠商X的大數據解決方案，安裝了一個大數據平臺，導入自己的數據并開發了一些大數據應用，運行得挺不錯。這個時候，部門B也需要解決一些大數據問題，于是試圖采購廠商Y提供的大數據解決方案，但Y的大數據平臺和X的有一些版本、組件上的差異，所以需要對X的大數據平臺進行改造。問題是，這個任務由誰來完成，由誰負責改造后的大數據平臺的運維？有可能廠商Y的大數據應用也需要做些改造，這可行嗎？部門A的應用已經運行得很好了，部門B的應用會不會對部門A的應用造成影響（包括性能和數據安全的影響）？如果影響了，誰來負責？比較簡單且快速見效的方法是直接安裝廠商Y提供的端到端的解決方案。照此下去，每個解決方案都會安裝一個新的大數據系統。還有一個問題是，廠商X和廠商Y底層的數據結構可能不是對外公開的，因而它們各自解決自己的問題，雖然開始互不干擾，但是后來就造成了數據孤島和煙囪。這個時候，由于各個子系統的數據標準不一、數據格式不同，各部門之間數據無法互聯互通，很難根據數據做出全局決策。

解決上面的問題，正是數據中臺方法論和架構的任務。TotalPlatform保證所有數據應用的統一管理，OneID、OneModel確保各子系統中數據的互聯互通，OneService負責數據能力的共享，TotalInsight確保全局數據運營的高效和價值量化。

4.3.1　全局的數據治理

必須有全局的數據治理系統來管理所有子系統的數據，確保它們能互聯互通。例如，OneID要求所有關于用戶的數據都必須使用同一個ID，OneModel要求所有數據倉庫的模型都必須符合同樣的標準。

但是這里要指出，解決數據孤島和應用孤島的問題，除了技術方案以外，明確責權利也很重要。出現孤島的原因之一就是各部門的責權利不明晰。如何在使用數據中臺解決孤島問題的同時保證責權利的明晰，是一個非常重要的問題，我們將在第6章中詳細描述。

4.3.2　數據能力的復用和共享

在進行全局的數據治理的同時，治理的結果必須能為公司創造價值。這個時候就類似于OneService的功能，既要求能進行全局的數據能力的復用和共享，也需要類似TotalInsight的功能，管理全局的數據資產，量化數據能力的投入產出。主要的工作如下：

·建立數據能力共享的責權利機制；

·提供全局的數據能力目錄和訪問機制；

·提供數據能力共享的工具、機制和流程；

·對共享的數據能力的管控和審計；

·確保共享的數據能力的高效運行。

4.3.3　云原生架構的支撐

在這個階段隨著業務的不斷增長，越來越多的應用程序被添加到大數據系統中。先有Spark、Kafka，后有Flink、TensorFlow，現在又有各種新的大數據和人工智能組件。

這些就是在云基礎架構上運行大數據系統的根本原因。而云平臺為分析工作負載和一般工作負載提供了極大支持，并提供了云計算技術的所有好處：易于配置和部署、彈性擴展、資源隔離、高資源利用率、高彈性、自動恢復。

在云計算環境中運行大數據系統的另一個原因是大數據工具的發展。傳統的分布式系統（如MySQL集群、Hadoop和MongoDB集群）傾向于處理自己的資源管理和分布式協調，但是現在由于Kubernetes、Mesos、YARN等分布式資源管理器和調度程序的出現，越來越多的分布式系統（如Spark）將依賴底層分布式框架來提供這些資源分配和程序協調調度的分布式操作原語。在這樣的統一框架（見圖4-5）中運行它們將大大降低復雜性并提高運行效率。

圖4-5　云原生架構

第8章將詳細介紹云原生架構如何幫助我們簡化數據中臺的運營與管理以及真正實現TotalPlatform。