知道要轉型，要建設數據中台，卻不知咋做，咋辦？ 現在有很多講“如何建設數據中台”文章，觀點各不相同： - 數據中台是數據建設方法論，按照數據中台設計方法和規範實施就可建成數據中台 - 數據中台背後是數據部門組織架構變更，把原先分散的組織架構形成一個統一中台部門，就建成數據中台 - 一些大數據公司說， ...
知道要轉型，要建設數據中台，卻不知咋做，咋辦？
現在有很多講“如何建設數據中台”文章，觀點各不相同：
- 數據中台是數據建設方法論，按照數據中台設計方法和規範實施就可建成數據中台
- 數據中台背後是數據部門組織架構變更，把原先分散的組織架構形成一個統一中台部門，就建成數據中台
- 一些大數據公司說，他們可賣支撐數據中台建設的產品技術
蓋房前，先得設計圖紙，知道如何蓋這房？然後還要有好用工具（如水泥攪拌機、鋼筋切割機）幫你蓋好這房。蓋房子離不開一個靠譜施工隊伍，這裡面涉及很多角色（泥瓦工、木工、水電工等等），人須高效協作，才能蓋出好房。
如把建數據中台比作蓋房：
- 設計圖紙就是數據中台建設方法論
- 工具是數據中台的支撐技術
- 施工隊伍就是數據中台的組織架構
本文以全局視角從巨集觀瞭解如何建設企業級數據中台。
1 數據中台建設方法論
2016年阿裡提出數據中台建設核心方法論：OneData、OneService。很多公司都進行實踐，但你很難找定義去描述這些方法論。
1.1 OneData
所有數據只加工一次。
電商業務建設數據中台前，每個部門內部都有一些小數倉完成本部門數據分析需求。
有天，供應鏈團隊接到一個數據需求，即計算“商品庫存”指標，供應鏈的運營需根據每個商品的庫存制訂商品採購計劃，部門的數據開發從業務系統同步數據，進行數據清洗、聚合、深度加工，最終，產出這個指標花1周時間。
恰逢大促，市場部門也需根據每個商品的庫存，制訂商品促銷計劃。該數據開發接到緊急需求（與供應鏈團隊類似）從需求開發到上線，花費1周。同部門運營抱怨說，為啥數據需求開發這麼慢，根本無法滿足大促高頻市場運營決策。對公司而言，等1周意味巨大損失，該促銷商品沒有促銷，不該促銷的卻低價賣了。
如你是公司老闆， 肯定問，既然供應鏈團隊已計算出來商品庫存數據，為什麼市場部門不直接用，還要從頭再計算一遍？這看似傻行為，卻處處出現在日常數據建設。
數據中台就是要在整個電商業務形成一個公共數據層，消滅這些跨部門小數倉，實現數據復用，所以強調數據只加工一次，不會因為不同的應用場景，不同的部門數據重覆加工。
如何才能實現數據只加工一次？
如你構建了數據中台，但存在幾萬張表，又有幾十個數據開發維護這些表，如何確保這些表管理效率？ 建議你選擇劃
主題域
可將這幾萬張表划到不同主題域，如電商業務中，商品、交易、流量、用戶、售後、配送、供應鏈都可作為主題域。好的主題域劃分，相對穩定，儘可能覆蓋絕大多數表。
還要對錶的
命名規範化統一
表的名稱中最好能夠攜帶表的主題域、業務過程、分層及分區信息。如倉儲域的一張入庫明細表的規則命名：
接著，構建全局的指標字典，確保所有表中相同指標的口徑須一致（06文）。
為實現模型的復用，數據中台適合分層設計，常見分層：ODS 原始數據層，DWD 明細數據層，DWS 輕度彙總數據層，ADS/DM 應用數據層/數據集市層。
最後，數據中台的數據須儘可能覆蓋所有業務過程，數據中台每層的數據要儘可能完善，讓數據使用者儘可能使用彙總後的數據。
OneData 體系的目標是構建統一的數據規範標準，讓數據成為一種資產，而非成本。資產和成本差別在於：
- 資產可沉澱，可被覆用
- 成本是消耗性質、臨時、無法被覆用
1.2 OneService
數據即服務，強調數據中臺中的數據應通過API介面被訪問。
為何數據要通過API被訪問，而不通過API介面，直接提供數據表給用戶？
如你是數據應用開發，當你要開發一個數據產品，先要把數據導到不同查詢引擎：
- 數據量小的，MySQL
- 大的，可能HBase
- 多維分析的，可能Greenplum
- 實時性要求高的，要用Redis
總的來說，不同的查詢引擎，應用開發需要定製不同的訪問介面。
如你是數據開發：
- 當某任務無法按時產出，發生異常時，想瞭解這個表可能影響下游哪些應用或報表，但卻發現單純依賴表與表的血緣無法觸及應用，根本無法知道最後這些表被哪些應用訪問
- 當你想下線一張表，因不知道誰訪問這張表，無法實施，最終造成“上線易，下線難”
而API介面：
- 對應用開發屏蔽了底層數據存儲，使用統一標準的API介面查詢數據，提高數據接入速度
- 對數據開發，提高數據應用的管理效率，建立表到應用的鏈路關係
2 如何實現數據服務化
2.1 屏蔽異構數據源
數據服務要能支撐類型豐富的查詢引擎，滿足不同場景下數據的查詢需求，常見如MySQL、HBase、Greenplum、Redis、ES等。
2.2 數據網關
要實現包括許可權、監控、流控、日誌在內的一系列管控能力，哪個應用的哪個頁面訪問了哪個模型，要做到實時跟蹤，如有一些模型長時間沒被訪問，應下線。使用數據的每個應用都應通過accesskey、secretkey實現身份認證和介面許可權管理。
訪問日誌可方便在訪問出現問題時，加快排查速度。
2.3 邏輯模型
從用戶視角出發，屏蔽底層的模型設計的實現，面向用戶提供邏輯模型。什麼是邏輯模型呢？熟悉資料庫的同學應該知道，資料庫中有一個視圖的概念，視圖本身並沒有真實的數據，一個視圖可以關聯一張或者多張表，每次在查詢的時候，動態地將不同表的查詢結果聚合成視圖的查詢結果。邏輯模型可以類比視圖，它可以幫助應用開發者屏蔽底層的數據物理實現，實現相同粒度的數據構造一個邏輯模型，簡化了數據接入的複雜度。
性能和穩定性：由於數據服務侵入到用戶的訪問鏈路，所以對服務的可用性和性能都有很高的要求，數據服務必須是無狀態的，可以做到橫向擴展。
OneService 體系目標是提高數據共用能力，讓數據被用得好、爽。
3 數據中台支撐技術
這個圖完整地描述了數據中台支撐技術體系，底層以Hadoop為代表的大數據計算、存儲基礎設施，提供大數據運行所須的計算、存儲資源。都屬基礎設施範疇：
- HDFS為代表的分散式文件系統
- Yarn/Kubernates為代表的資源調度系統
- Hive、Spark、Fink為代表的分散式計算引擎
若把數據中台比作數據工廠，它們就是工廠的水、電。
在Hadoop之上：
- 淺綠色，原有大數據平臺範疇內的工具產品，覆蓋從數據集成、數據開發、數據測試到任務運維的整套工具鏈產品。同時包括基礎的監控運維繫統、許可權訪問控制系統和項目用戶的管理系統。由於多人協作，所以還有流程協作與通知中心
- 灰色，數據中台核心組成：數據治理模塊。它對應的方法論就是OneData 體系。以元數據中心為基礎，在統一了企業所有數據源的元數據基礎上，提供了包括數據地圖、數倉設計、數據質量、成本優化以及指標管理在內的5個產品，分別對應的就是數據發現、模型、質量、成本和指標的治理
- 深綠色，數據服務，它是數據中台的門戶，對外提供了統一的數據服務，對應的方法論就是OneService。數據服務向下提供了應用和表的訪問關係，使數據血緣可以延申到數據應用，向上支撐了各種數據應用和服務，所有的系統通過統一的API介面獲取數據。
在數據服務之上，是面向不同場景的數據產品和應用，包括面向非技術人員的自助取數系統；面向數據開發、分析師的自助分析系統；面向敏捷數據分析場景的BI產品；活動直播場景下的大屏系統；以及用戶畫像相關的標簽工廠。
這套產品技術支撐體系，覆蓋了數據中台建設的整個過程，配合規範化實施，你就可以搭建出一個數據中台，關於具體的細節我會在實現篇中逐一分析講解，這裡你只需要知道這個框架就可以了。
4 組織架構
在網易電商數據中台建設之前，各個部門都會存在一些小的數倉，那麼你有沒有想過，為什麼會存在這些分散的小數倉？ 歸根結底是因為建設這些數倉的人分散在各個業務部門。所以，如果你要建設數據中台，單純有方法論和支撐技術還不夠，還必須要有一個獨立於業務部門的中台團隊。
數據中台提供的是一個跨業務部門共用的公共數據能力，所以，承擔數據中台建設職責的部門一定是一個獨立於業務線的部門。這個部門的負責人應該直接向公司的CTO彙報工作，當然這個也要取決於數據中台建設的層次，例如在網易內，有雲音樂、嚴選等多個產品線，數據中台的建設層次是在產品級別的，也就是說，雲音樂有一個數據中台，嚴選有一個數據中台，所以嚴選的數據中台應該向嚴選的CTO彙報。
而獨立部門的最大風險是與業務脫節，所以我們對數據中台的組織定位是：懂業務，能夠深入業務，扎根業務。數據中台要管理所有的指標，而每個業務線之間的指標既有差異，也有交叉，要理解指標的口徑定義，就必須要瞭解業務的過程。同時，當我們要制定一些新的指標時，必須要瞭解各個業務線新的業務目標，指標的本質還是為業務目標服務的。
啥樣的組織架構適合數據中台建設？
- 數據產品部門：負責數據中台、數據產品的體系規劃、產品設計、規範制定、應用效果跟進，指標口徑的定義和維護（有的部門是由分析師管理）。
- 數據平臺部門：負責研發支撐數據中台構建的產品，例如指標系統、元數據中心、數據地圖等。
- 數據開發團隊：負責維護數據中台的公共數據層，滿足數據產品制定的數據需求。
- 應用開發團隊：負責開發數據應用產品，比如報表系統、電商中的供應鏈系統、高層看板、經營分析。
而且，中台組織的績效目標一定是要與業務落地價值綁定的，比如在電商中，我們提供了供應鏈決策系統，有智能補貨的功能，會根據商品的庫存，各個地區的歷史銷售情況，生產加工周期，自動生成補貨決策，由人工審核以後，直接推送給採購系統。那我們評估價值時，我們會拿由系統自動生成的採購計劃占整體採購計劃的比例來衡量數據的應用價值。
最後，數據中台的組織架構改革涉及原有各部門利益，所以這個是數據中台構建最難又不得不做的地方，必須要取得高層領導的支持和重視。
5 總結
數據中台建設的三板斧：方法論、支撐技術和組織架構。
- 適合數據中台的組織架構是建設數據中台的第一步，數據中台組織一定是獨立的部門，同時要避免與業務脫節，深入業務，要與業務目標綁定。
- 數據中台支撐技術大規模落地，需要有成熟的系統工具作為支撐，同時要註意這些系統工具之間的聯動和打通。
- 數據中台的方法論可以借鑒，但是不能完全照搬，每個公司的數據應用水平和當前遇到的問題都不相同，可以針對這些問題，分階段制定數據中台的建設計劃，選擇性的應用一些技術，例如當前最主要的問題是數據質量問題，那就應該優先落地數據質量中心，提升質量。
6 如何建設數據中台？
數據中台的建設絕對不是為了建中台而建中台，數據中台的建設一定要結合落地場景，可以先從從一些小的場景開始，但是規劃一定是要有頂層設計。
FAQ
哪些數據中台建設的方法論和支撐技術是適合你當前的公司的，如果你們要做數據中台，你所在的組織架構要做哪些變動。
本文由博客一文多發平臺 OpenWrite 發佈！
