1.3　大數據平臺與數據中臺

既然大數據平臺與數據中臺的建設目的一樣，我們為什么還要區分大數據平臺（包括其中建設的數據倉庫）和數據中臺呢？實際上，硅谷的絕大部分公司有一個數據平臺（Data Platform）部門負責建設公司的大數據平臺，公司的各個部門都在這個平臺上管理和使用自己的數據，并與其他部門共享數據能力。這些團隊建設的大數據平臺絕大部分符合上面數據中臺的定義，實際已經包含了阿里巴巴所提出的數據中臺的功能。因此，在硅谷并沒有數據中臺和大數據平臺的絕對區分。阿里巴巴提出數據中臺的概念，如上所述，只是為了強調與現有的很多大數據平臺在實現方式上的區別，強調解決數據孤島/重復開發的問題，強調數據共享和復用。

1.3.1　為什么要建設數據中臺

數據中臺的出現，與傳統大數據平臺項目的一些實踐和弊端有關：

·為了趕風口，為了大數據而大數據，安裝一個Hadoop集群之后把數據都存上去，卻發現除了有限的應用之外很難挖掘數據的價值；

·企業內各個部門重復建設大數據平臺，或者在同一個大數據平臺上重復建設類似的數據應用，最后造成數據孤島和應用孤島；

·由于架構選擇問題，大數據平臺缺乏靈活性和可擴展性，新的大數據應用和人工智能應用很難無縫擴展到現有平臺上，每次新增功能都要經過冗長的流程甚至只能另起爐灶；

·大數據平臺的開發和運營花費巨大，大家都覺得必須建設，但是并不清楚建設后到底能產生多少效益。

在建設了五六年大數據平臺之后，阿里巴巴提出了“數據中臺”的概念，來強調一些能夠更好地發掘數據價值的實踐原則：

“基于阿里巴巴實戰經驗沉淀而成，致力于為企業構建既準又快的全、統、通的智能且安全的大數據體系。包含三項核心能力：OneModel，負責統一數據構建及管理；OneID，負責將核心商業要素資產化；OneService，負責向上提供統一的數據服務。根據企業不同發展時期所關注的不同業務訴求，提供‘中臺核心產品+專家咨詢服務+生態交付服務’的運作模式，為企業構建數字經濟時代的增長引擎。”

這里的OneID、OneModel和OneService是符合上面數據中臺的定義的：OneID是一種全局的數據規范，OneModel是一個數據能力抽象的成果，OneService是一種可復用的數據能力的形式。

但是，硅谷的高科技公司就不需要這些能力嗎？無論公司大小，或者從小公司發展到大公司，硅谷的高科技公司都沒有特別強調數據中臺的概念。難道它們沒有數據中臺的需求嗎？答案當然是否定的，類似于Supercell的實踐在硅谷的大數據平臺團隊里是非常常見的。實際上，為了追求更高的效率，硅谷公司在內部都有實際的績效要求，其大數據平臺建設絕大多數是需求驅動的，而且后續發展都由這個大數據平臺能產生多少價值來決定。因此，它們為了大數據而大數據的情況很少。

硅谷公司在建設大數據平臺的時候，大數據平臺的效率，包括運營效率和使用效率，都是必須考慮的關鍵問題。不管是在起初進行架構設計的時候，還是在后續迭代的時候，如何最大化投入產出比，如何讓業務部門真正發揮數據的作用，都是非常關鍵的問題。在這個過程中有很多嘗試和迭代，但是最終的結果是，絕大部分大數據平臺會自然而然地提供我們這里所說的數據中臺的能力，并將其作為公司內部的核心價值驅動引擎，而不是一個可有可無的報表生成工具。

實際上，很多已有大數據平臺的公司要建設數據中臺或者改進現有的數據平臺，一般是出于以下幾點考慮。

·從獨立的煙囪到連通的系統：從各個部門獨立建設到全局統籌、數據匯聚、協同演進的過程。

·從限定的功能到開放的數據能力平臺：不再局限于數據倉庫中預制的數據模型，提供從數據湖開始端到端的數據開發體系。

·解耦數據處理流程與數據使用過程：使前端應用能夠通過統一的數據服務、數據資產管理體系來使用數據。

·從粗放式管理到精細化運營：從粗放式安裝使用到精細化管理、量化ROI的轉化。

·從T+1到T+0：從一個簡單的數據處理和報表生成系統（一般都是定時運行，而且以日報的形式居多，因此叫作T+1），到能夠支持大量實時數據驅動的產品（T+0）。

·從成本中心變成利潤中心：從一個簡單的報表生成工具、可視化看板展示工具到業務的核心驅動力。

解決這些問題并不是獨立的任務，因為底層的很多問題是相通的：

·全局數據的打通與治理，數據標準和數據資產的管理；

·數據應用開發的管理和標準化；

·大數據平臺本身的數字化運營；

·工具的易用性、靈活性、多租戶管理及協同性；

·核心組件（Hadoop、Spark、Kafka、MPP）的性能及管理問題。

因此，我們不應拘泥于這個系統的名稱，而要了解一個公司如何最有效地發揮數據價值，真正實現高效的數字化運營，從而在市場競爭中取得先機。

圖1-1顯示了信息化系統、數據倉庫、傳統大數據平臺、數據中臺之間的關系，其中的箭頭表示數據的主要流向。我們可以這樣理解，傳統大數據平臺和數據倉庫是數據中臺的數據來源，建設數據中臺是為了更好地服務于業務部門。

圖1-1　數據中臺與傳統大數據平臺、數據倉庫的關系

1.3.2　數據中臺與傳統大數據平臺的區別

數據中臺與傳統大數據平臺到底有什么區別？為了敘述方便，我們先給出傳統大數據平臺的架構（見圖1-2）。

圖1-2　傳統大數據平臺

·大數據基礎能力層：Hadoop、Spark、Hive、HBase、Flume、Sqoop、Kafka、Elasticsearch等。

·在大數據組件上搭建的ETL流水線，包括數據分析、機器學習程序。

·數據治理系統。

·數據倉庫系統。

·數據可視化系統。

可以看到，這些是傳統大數據平臺的核心功能。在很多大數據項目里，只要把這些系統搭起來，每天可以生成業務報表（包括實時大屏），就算大數據平臺搭建成功了。

但數據中臺應該是大數據平臺的一個超集。我們認為，在大數據平臺的基礎之上，數據中臺還應該提供下面的系統功能。

（1）全局的數據應用資產管理

這里所說的數據應用資產管理包括整個生態系統中的數據和應用。傳統的數據資產管理絕大部分只包括關系型數據庫中的資產（包括Hive），而一個數據中臺應該管理所有結構化、非結構化的數據資產，以及使用這些數據資產的應用。如果傳統的數據資產管理提供的是數據目錄，那么數據中臺提供的應該是擴展的數據及應用目錄。要避免重復造輪子，首先要知道系統中有哪些輪子，因此維護一個系統中數據及數據應用的列表是很關鍵的。

（2）全局的數據治理機制

與傳統的數據治理不一樣，數據中臺必須提供針對全局的數據治理工具和機制。傳統數據倉庫中的數據建模和數據治理大多針對一個特定部門的業務，部分原因是全局數據建模和治理周期太長，由于存在部門之間的協調問題，往往難度很大。數據中臺提供的數據治理機制必須允許各個業務部門自主迭代，但前提是要有全局一致的標準。阿里提出的OneID強調全局統一的對象ID（例如用戶ID），就屬于這個機制。

（3）自助的、多租戶的數據應用開發及發布

現有的絕大部分大數據平臺要求使用者具備一定的編程能力。數據中臺強調的是為業務部門賦能，而業務人員需要有一個自助的、可適應不同水平和能力要求的開發平臺。這個開發平臺要能夠保證數據隔離和資源隔離，這樣任何一個使用系統的人都不用擔心自己會對系統造成損害。

（4）數據應用運維

用戶應該可以很方便地將自己開發的數據應用自助發布到生產系統中，而無須經過專門的數據團隊。因為我們需要共享這些應用及其產生的數據，所以需要有類似于CI/CD的專門系統來管理應用的代碼質量和進行版本控制。在數據應用運行過程中產生的數據也需要全程監控，以保證數據的完整性、正確性和實時性。

（5）數據應用集成

應該可以隨時集成新的數據應用。新的大數據應用、人工智能工具不斷涌現，我們的系統應該能夠隨時支持這些新應用。如果數據中臺不能支持這些應用，各個業務部門可能又會打造自己的小集群，造成新的數據孤島及應用孤島。

（6）數據即服務，模型即服務

數據分析的結果，不管是統計分析的結果，還是機器學習生成的模型，應該能夠很快地使用無代碼的方式發布，并供全機構使用。

（7）數據能力共享管理

大部分數據能力應當具有完善的共享管理機制、方便安全的共享機制以及靈活的反饋機制。最后決定數據如何使用的是獨立的個人，他們需要一套獲取信息的機制，因此在機構內部必須要有這樣的共享機制，才能真正讓數據用起來。

（8）完善的運營指標

數據中臺強調的是可衡量的數據價值，因此，對于數據在系統中的使用方式、被使用的頻率、最后產生的效果，必須要有一定的運營指標，才能驗證數據的價值和數據中臺項目的效率。

綜合上面的討論，除了阿里巴巴提出的OneID、OneModel、OneService之外，我們認為數據中臺還應該滿足以下兩個要求。

·TotalPlatform：所有中臺數據及相關的應用應該在統一平臺中統一管理。如果有數據存儲在中臺管理不到的地方，或者有人在中臺未知的情況下使用數據，我們就無法真正實現對數據的全局管理。這要求數據中臺能快速支持新的數據格式和數據應用，便于數據工具的共享，而無須建立一個分離的系統。

·TotalInsight：數據中臺應該能夠理解并管理系統中數據的流動，提供數據價值的定量衡量，明確各個部門的花費和產出。整個中臺的運營是有序可控的，而不是一個黑盒子，用戶可以輕松理解全局的數據資產和能力，從系統中快速實現數據變現。

如圖1-3所示，數據中臺可以說是按照一定的規范要求建設的數據能力平臺，在數據倉庫、大數據平臺、數據服務、數據應用的建設中實現了符合OneID、OneModel、OneService的數據層。這個數據層，加上在其上建立的業務能力層以及運營這個數據中臺需要的TotalPlatform、TotalInsight，形成我們看到的數據中臺。在后面的章節中，我們將會介紹如何通過合適的系統架構和方法論來實現數據中臺的五大要求：OneID、OneModel、OneService、TotalPlatform和TotalInsight。

圖1-3　數據中臺的五大要求

1.3.3　數據中臺的評判標準

如何評判一個公司的大數據平臺能否承擔數據中臺的任務？我們認為有以下幾個比較明顯的標準。

·數據/數據應用標準的覆蓋率和復用率：必須實現數據和數據應用標準的全覆蓋和高復用率。

·數據應用建設方式及周期：必須快速落地、快速迭代。

·新的業務場景解決方案的迭代管理方式：新的業務場景必須能夠快速復用現有數據能力，快速得到數據反饋。

·對于數據/人員/業務演進的適應能力：在數據/人員/業務發生變化時有可靠的管理方式。

·不同角色使用數據中臺的方式：業務部門可以自助使用數據能力并方便共享。

·ROI的精確度：能精確量化數據在系統中的使用情況。

·業務部門/IT部門/數據平臺部門的責權利劃分：各個部門的責權利清晰。

阿里巴巴提出的OneID、OneModel、OneService實際上對應了我們評判標準的一部分：能夠用統一標準覆蓋盡可能多的數據，引入新業務時可以復用現有數據能力。但是對于建設方式、使用方式、衡量方式、管理架構方式，我們認為需要更清楚的定義和方法論來指導，例如如何實現TotalPlatform和TotalInsight。因為即便目標都一樣，設計過程、建設過程以及后續的迭代和演進過程對于一個公司的核心系統來講應該更為重要。