文章目錄
- 01 資料中台起源
- 02 資料中台的定義
-
- 2.1 資料中台建設目标
- 2.2 如何實作建設目标
- 2.3 資料中台定義與特點
- 03 大資料平台與資料中台
-
- 3.1 為什麼要建設資料中台
- 3.2 資料中台與傳統的大資料平台的差別
- 3.3 資料中台的評判标準
- 04 資料中台建設總綱
-
- 4.1 業務驅動，快速落地
- 4.2 頂層架構設計及資料規範
- 4.3 平台管理，由工具來指導資料能力的抽象和共享
- 4.4 明确的責權利制定，并由工具來配合責權利的管理
- 4.5 必須是一個安全、高效、穩定、可擴充的系統
- 05 文末
01 資料中台起源
盡管大資料産生于矽谷，資料中台與大資料關系密切，但矽谷卻沒有資料中台這個名詞，“資料中台”的概念是在其倡議者阿裡巴巴内部産生的。
2015 年年中，馬雲帶領阿裡巴巴集團高管拜訪了一家芬蘭的小型遊戲公司Supercell。讓馬雲及其高管團隊感到驚訝的是，這家僅有不到 200 名員工的小型遊戲公司竟創造了高達 15 億美元的年稅前利潤！Supercell 之是以能夠支援多個團隊快速、靈活地推出高品質的遊戲作品，其強大的中台能力功不可沒。是以，在拜訪 SupercellE 的旅程結束之後，馬雲決定對阿裡巴巴的組織和系統架構進行整體調整，建立阿裡産品技術和資料能力的強大中台，建構“大中台，小前台”的組織和業務體制。
實際上，雖然矽谷并沒有“資料中台”這一叫法，但矽谷的公司早已自然形成了中台的意識。從早期的中間件（
Middleware
）、面向服務的架構（
SOA
）到後來的
IaaS/PaaS/DaaS
平台、微服務(
Microservice
),都有中台思想的影子，都來源于避免重複造輪子、快速疊代、資料驅動、業務驅動這些矽谷工程師文化的核心理念。
02 資料中台的定義
在定義資料中台前，必須了解資料中台建設的目标。
2.1 資料中台建設目标
根據資料中台要解決的問題，我們可以确定資料中台建設的終極目标。資料中台首先是一種
IT
系統，而
IT
系統建設的最終目标是服務企業，是以資料中台的建設遵循我們常說的以業務為導向的路徑。
例如：阿裡巴巴的目标是“讓天下沒有難做的生意”，騰訊的目标是“以技術豐富網際網路使用者的生活”，但是這些大目标都有一個共同的子目标，即最高效地實作資源的合理配置和利用，創造最大的企業利潤，簡單來講就是精細化營運，開源節流。從最早的會計系統，到計算機普及時代的資訊化建設，到現在的大資料、數字化轉型、智能化，都是服務于這個目标的。
是以，建設資料中台的最終目标是通過提供工具、流程和方法論，實作資料能力的全局抽象、共享和複用，賦能業務部門，提高實作資料價值的效率。
2.2 如何實作建設目标
第一，實作這些目标必須有相應的資料能力，也就是從資料中産生價值的能力。
例如，在 EA，各個遊戲工作室都會用統一的大資料平台來完成使用者行為分析、反欺詐、動态定價等一系列關鍵的資料驅動的功能。這些功能無法用預先設計好的算法或程式來完成，必須根據實際資料采取相應行動才能實作。這些都是資料能力的典型代表。
第二，要實作這些目标，必須完成全局的資料彙聚和治理
例如，EA 大資料團隊花了一年時間整理出像字典一樣厚的資料規範，形成連接配接生産資料的遊戲工作室與消費業務資料的分析部門的橋梁。有了這種統一而詳細的資料規範标準，各業務分析部門就可以輕松整合所有的遊戲資料，形成公司層面的資料資産，然後對其進行挖掘和分析，得到各自需要的有價值資料。
第三，企業必須高效完成從彙總好的資料到價值的轉換，需要進行資料能力的抽象，然後實作能力的共享和複用。
過程有兩種實作方式。
一種是由大資料部門做頂層設計來實作。舉例來講，EA 大資料團隊設計了一個反向索引的分析系統，各遊戲工作室從黑市上買了遊戲币以後，隻要把這些遊戲币的 ID
輸入系統裡，就可以通過反向索引查到并清除掉收集這些遊戲币的僵屍賬号。這個資料能力是各個工作室都需要的，雖然它們的需求會有細微差異，但是大資料平台将其中的共同點提取出來，形成一個通用工具，各個工作室可以配合自己的特定參數來使用。
- 另一種方式是一個業務部門開發供自己使用的服務，但發現其他業務部門也需要，于是就對這種服務進行抽象，以供全公司複用。舉例來講，
遊戲推廣團隊有一個需求是，每天通過電子郵件向特定使用者群體推送打折券。以往，需要進行很複雜的查詢才能得到目标使用者的FIFA
ID
，要從幾百萬個使用者中篩選出幾百個，而且一天可能隻能做一次。FIFA
遊戲推廣團隊與大資料團隊合作開發了一套标簽系統，利用它可以快速定位這幾百個使用者。比如這個群體是美國加州的使用者，年齡在
，年收入為35~45 歲
美元，過去 7 天平均玩遊戲的時間超過 1 小時，遊戲内消費金額為5 萬~8 萬
美元。确定這些标簽後，幾秒就可以完成層層過濾，鎖定目标使用者群體，然後可以很簡單地通過模闆将打折券推送給他們。2000~3000
第四，在實作資料能力的共享和複用的過程中，需要協調複用和效率的沖突。
如果一個業務部門為了滿足其他部門複用某個服務的需求而做了大量工作，結果影響到自己的工作效率，這就得不償失了。這裡首先需要有一套平衡的工具和機制，其次是要有能夠精确衡量資料能力的ROI，讓業務部門有動力共享它們的資料能力。
2.3 資料中台定義與特點
綜上所述，我們認為資料中台可以如下定義：
資料中台是企業數字化營運的統一資料能力平台，能夠按照規範彙聚和治理全局資料，為各個業務部門提供标準的資料能力和資料工具，同時在公司層面管理資料能力的抽象、共享和複用。
資料中台需要具備以下特點:
- 能夠借助彙聚全局的資料為使用者賦能;
- 實作資料能力的抽象；
- 可以通過工具體系讓企業各部門友善地共享抽象出的資料能力。
03 大資料平台與資料中台
阿裡巴巴提出資料中台的概念，隻是為了強調與現有的很多大資料平台在實作方式上的差別，強調解決資料孤島/重複開發的問題，強調資料共享和複用。
3.1 為什麼要建設資料中台
資料中台的出現，與傳統大資料平台項目的一些實踐和弊端有關：
- 為了趕風口，為了大資料而大資料，安裝一個
Hadoop
- 企業内各個部門重複建設大資料平台，或者在同一個大資料平台上重複建設類似的資料應用，最後造成資料孤島和應用孤島；
- 由于架構選擇問題，大資料平台缺乏靈活性和可擴充性，新的大資料應用和人工智能應用很難無縫擴充到現有平台上，每次新增功能都要經過冗長的流程甚至隻能另起爐竈；
- 大資料平台的開發和營運花費巨大，大家都覺得必須建設，但是并不清楚建設後到底能産生多少效益。
資料中台與傳統大資料平台、資料倉庫的關系圖：
3.2 資料中台與傳統的大資料平台的差別
傳統的大資料平台架構圖如下：
可以看到大資料平台的架構由以下核心功能組成：
- 大資料基礎能力層：
Hadoop
Spark
Hive
HBase
Flume
Sqoop
Kafka
Elasticsearch
- 在大資料元件上搭建的
ETL
- 資料治理系統。
- 資料倉庫系統。
- 資料可視化系統。
在很多大資料項目裡，隻要把這些系統搭起來，每天可以生成業務報表（包括實時大屏），就算大資料平台搭建成功了。
但資料中台應該是大資料平台的一個超集，在大資料平台的基礎之上，資料中台還應該提供下面的系統功能：
- 全局的資料應用資産管理
- 全局的資料治理機制
- 自助的、多租戶的資料應用開發及釋出
- 資料應用運維
- 資料應用內建
- 資料即服務，模型即服務
- 資料能力共享管理
- 完善的營運名額
資料中台的五大要求（OneID、OneModel、OneService、TotalPlatform TotalInsight）：
3.3 資料中台的評判标準
如何評判一個公司的大資料平台能否承擔資料中台的任務？我們認為有以下幾個比較明顯的标準：
- 資料/資料應用标準的覆寫率和複用率：必須實作資料和資料應用标準的全覆寫和高複用率。
- 資料應用建設方式及周期：必須快速落地、快速疊代。
- 新的業務場景解決方案的疊代管理方式：新的業務場景必須能夠快速複用現有資料能力，快速得到資料回報。
- 對于資料/人員業務演進的适應能力：在資料/人員業務發生變化時有可靠的管理方式。
- 不同角色使用資料中台的方式：業務部門可以自助使用資料能力并友善共享。
- ROI的精确度：能精确量化資料在系統中的使用情況。
- 業務部門/IT部門/資料平台部門的責權利劃分：各個部門的責權利清晰。
04 資料中台建設總綱
4.1 業務驅動，快速落地
所謂業務驅動，就是在建設資料中台的時候，一定要從企業的業務痛點、開發新業務的需要或者管理的需要出發，一步一步來，而不能期望一蹴而就。這是因為，資料中台的建設應該是先從 0 到 o.1, 要很快見效，不斷疊代，分階段地逐漸展現出資料中台的價值。如果能夠快速解決各部門的業務痛點和需求，各個部門才會積極響應資料中台的建設。而且從工程師的角度來看，這樣開發的服務不僅部門内部可以使用，公司其他部門也能用到。在能力得到大家認可後，其他部門的工程師還會幫助調試這個項目，一舉兩得。當其他部門的工程師也開始這樣釋出服務時，就形成了良性循環。貫徹數字化營運的理念，能夠不斷從資料中提取新的價值，這樣才能充分調動各個部門使用資料中台的積極性。
4.2 頂層架構設計及資料規範
在确定有業務痛點，需要相應的資料能力來解決問題的時候，首先必須梳理頂層的組織架構和業務架構，并确定全局的資料架構和資料規範。值得注意的是，這裡并不需要進行全局的業務梳理、資料梳理，因為我們在确定頂層架構和資料規範之後，可以根據具體的業務需求來梳理專門的業務流程和相關資料。隻要有合适的頂層架構和資料規範并貫徹執行，系統中就不會出現資料孤島。
4.3 平台管理，由工具來指導資料能力的抽象和共享
如果實作資料能力的抽象和共享需要建立大量規則，需要複雜的教育訓練，還要小心使用，那麼這個資料中台注定是很難長期演進的。資料中台的建設應該以提供一系列友善好用的工具和流程為目的，讓工具引導人來完成工作，而不是靠人手動操作。例如，添加一個新的資料源，對現有資料源進行修改的時候，相應的工具應該能自動完成這個資料源相關的管理工作（中繼資料采集、監控、通知）而不是讓使用人員手動添加很多相關的配置。
4.4 明确的責權利制定，并由工具來配合責權利的管理
4.5 必須是一個安全、高效、穩定、可擴充的系統
05 文末