中臺建設之路-中臺建設怎麼作？建設中臺須要具有什麼？

開宗明義：要建設中臺，須要考慮組織、支撐技術、方法論這三個方面，每每還須要諮詢服務。
中臺做爲一種有業務屬性的共性能力，首先就須要一個懂業務、承擔業務職責的專職的組織機構來負責。要不要建中臺，首先要看領導有沒有魄力去整合創建一箇中臺組織。由於原來的平臺部一般不懂業務，懂業務的人各自分散在前臺業務部門，因此創建中臺組織每每涉及人員、組織架構和部門職責的調整。正由於如此，中臺的建設每每須要做爲一把手工程才能成功。
中臺組織關鍵要懂業務和承擔業務職責。舉個例子，一個大數據平臺的建設運維團隊不是一箇中臺組織。一個團隊若是作了很是完善的中臺產品（如開發了數據中臺所須要的指標管理系統、數據倉庫開發系統、數據質量管理系統等等），但只是把產品提供給業務方使用，這個團隊仍然不能說是中臺組織。只有當這個團隊承擔起指標體系的建設和管理、數據倉庫的設計和實施、數據質量的保障等工做時，才能夠說是中臺組織。而要作到這一點，這個組織確定是比較瞭解業務的，它的目標和考覈也必定與業務有相關性（確定不僅是平臺穩定性這樣的非業務指標）。
中臺組織的層次與中臺的層次最好是對應的，BU級的中臺組織最好直接向BU老大或分管的CXO彙報，企業的中臺組織最好直接向CEO或分管的CXO彙報。
這裏特別說明一點的是若是不建設在線業務中臺，而只是採用微服務、雲原生等技術的話，能夠不涉及組織方面的大規模變更，就在原來的研發部實現轉型。一般來講也能夠實現必定的系統可用率、彈性和研發效率方面的提高。
中臺建設的支撐技術
建設中臺通常須要一套支撐技術。
1、在線業務中臺支撐技術
建設在線業務中臺通常須要雲原生、DevOps、微服務技術體系的支撐，這是由於：
微服務技術：中臺是一個獨立的組織負責併爲多個前臺業務服務，所以須要一個標準的服務接口、成熟的服務治理能力和高效的敏捷研發技術。在當前的技術環境下，採用地球人都熟悉的REST風格的同步API、消息隊列異步通訊做爲標準的服務接口技術，採用服務框架（如Spring Cloud等）、API網關、APM等做爲標準的服務治理和敏捷研發技術是最合適的選擇。再也不建議採用傳統的基於ESB的服務化（SOA）技術，由於ESB產品過多的介入到業務邏輯中，致使前臺業務的變動每每須要中臺團隊的配合才能完成，這樣就失去了建設好中臺，支撐前臺高效創新的意義。此外，中心化的ESB軟件和複雜的基於XML的WS-xxx等協議也影響到系統的可用性和性能。能夠參見Martin Fowler在P of EAA中的評價，Web Services是應用集成而非應用開發的技術。
DevOps技術：若是不經過DevOps使得各微服務都能自助式的部署更新，則微服務帶來的敏捷性就無從發揮，反而由於服務數量的增長致使研發效率的降低，所以持續集成、持續發佈等DevOps技術通常是實現微服務的必備。
雲原生技術：微服務和DevOps要求底層的基礎設施是靈活可編程的，不然根據Amdahl定律，只要有一個必須的環節是低效的，總體的效能也提不上去。
須要強調的是中臺要敏捷，這一方面是由於中臺具有業務屬性，且支撐了很是豐富的前臺業務，前臺業務的敏捷性要求有一部分就會傳導的中臺層；另外一方面是中臺的重要性使得其須要持續不斷的優化，即使對外提供的服務不變，內部實現也會常常變。
分佈式事務技術：實施微服務拆分後，複雜的業務流程再也不能經過數據庫的事務機制來實現ACID特性，爲此還須要服務層面的分佈式事務處理技術。典型的分佈式事務處理模型包括TCC、Saga、FMT等。其中TCC和Saga須要各服務實現定製化回滾邏輯，侵入性比較嚴重，用起來門檻比較高。FMT模式對於Java能夠作到加一行註解（如@GlobalTransaction）便可實現分佈式事務，剩下的由框架自動處理，用起來方便的多。Saga模式是Princeton的兩位研究者在1987年提出的，靈活性和併發度最好，但須要經過語義鎖等精細的設計才能發揮出來。
因而可知，在線業務中臺的技術支撐體系是至關複雜的，所幸的是Netflix、Google等世界領先的互聯網企業因爲自身業務須要打造了不少實用的技術模塊，開源社區也貢獻了很多力量，CNCF組織又作了很好的聚集和標準化。經過將相關技術加以整合，已經有了不錯的產品可用，如網易輕舟微服務就是一套產品化設計良好、功能豐富的在線業務中臺支撐技術產品。
通常而言，前臺也會和在線業務中臺同樣採用雲原生等一樣的技術體系，這是由於前臺更須要敏捷性。在完善的中臺支撐之下，前臺會比較輕，還能夠考慮採用FaaS Serverless技術，不過目前這方面的實踐還很少（特別在中國），相關的支撐技術也不是很成熟。
2、數據中臺支撐技術
建設數據中臺通常須要一整套以下典型的支撐技術：
指標管理系統：指標是中臺與前臺之間最關鍵的接口，也是建設數據中臺的牛鼻子，由於它是最核心的業務語言，且指標不一致、數據常出錯是建設數據中臺最多見的出發點。若是指標體系沒有統一的方法論，進行統一建設，那麼就很難說是數據中臺。指標管理系統通常要實現一套一致的方法論（如原子 / 派生 / 複合指標、維度、修飾詞等），作好指標的業務和技術口徑管理，還須要支持指標的審批管理。數據中臺的指標沒法交給各前臺業務自助式的建設。
數據服務系統：相似於在線業務中臺須要經過API網關提供標準化的服務，數據中臺也須要一個標準化的服務方式，一般稱爲數據服務系統，也能夠說是數據網關或數據門戶。相似於別的網關類產品，數據服務系統須要提供鑑權、日誌審計、流控、協議轉換（如SQL Dialect之間的轉換）等功能，也應該發展多引擎融合查詢、邏輯模型等擴展功能以提升服務接口的穩定性和實現的靈活性。
元數據管理系統：元數據管理是整個數據中臺的基礎和中心，全部的其餘系統都依賴元數據管理。元數據管理首先要作好的固然是數據模式或目錄（catalog）的管理，至少要知道中臺裏都有什麼數據。對複雜的數據中臺來講，數據血緣也很重要。沒有血緣信息，不知道數據間的依賴關係，數據質量確定管很差，由於不知道一個數據的質量問題怎麼來，又進而會影響什麼。一樣的若是沒有血緣，數據資產也確定管很差，由於不知道什麼數據有價值什麼沒價值，這就像若是你不知道一個函數被誰調用，你就不知道它是否是死代碼同樣。元數據管理系統每每也須要提供一個基礎的訪問界面，一般稱之爲數據地圖。
數據倉庫開發與管理系統：除了指標管理，數據倉庫的開發是將一大堆初始數據建設梳理成一個漂亮的數據中臺的核心過程。通常來說數據中臺更適合用Kimball的維度建模方法而非數據倉庫之父Bill Inmon所提倡的方法，這是由於Inmon強調頂層設計，而Kimball強調至下而上。若是要建設數據中臺，確定是由於前臺業務複雜多變，這時強調頂層設計會致使中臺建設緩慢、僵化。由於中臺雖然應該是由組織高層決策，但目的倒是爲了支持前臺業務，而不是爲了控制。支持而不是控制，這一點毫不能本末倒置。
數據質量管理系統：全部複雜的系統都須要專業的質量管理，在線業務系統有一系列的彈力設計和APM等監控運維工具，數據中臺也須要專業的質量管理。數據質量管理系統一般設計爲支持豐富的稽覈 / 校驗 / 比對規則，監控數據是否準確、實時、一致，還要作到及時的報警，分析影響面，提供快速修復的手段等。但這些手段只能發現和補救問題，不能預防問題，要預防問題，還要經過測試工具減小代碼bug、經過資源彈性應對性能波動、經過優先級調度優先知足重要業務需求等。相對來講，當前數據中臺領域的質量管理沒有在線業務領域的成熟，如在線業務領域的測試手段遠比數據領域的精細，在線業務領域很常見的熔斷、限流、服務降級等模式在數據領域都沒有成熟的實踐方法（優先級調度能夠說是實現了部分的服務降級功能），隨着數據中臺愈來愈普遍和重要，這些技術應該也須要持續發展，但技術上的挑戰不小。
數據安全管理系統：數據中臺由於聚集了組織全部有價值的數據資產，所以良好的安全管理是必須的。細粒度的權限和審計是基礎，通常的還須要隱私 / 敏感數據的脫敏處理、數據加密（特別是將數據託管在第三方平臺之上時）、數據泄漏防禦（比方說一種常見的方法是限制將數據下載到本地的數據量）等技術。發展到高級階段甚至可能還須要聯邦學習、數據沙盒等技術。
數據資產管理系統：在數據質量和安全單列的狀況下，數據資產管理主要負責的是數據的生命週期管理、成本的統計分析與優化等工做。
同時，數據中臺還須要強大的大數據計算引擎、數據集成 / 同步 / 交換引擎，還每每須要一套敏捷BI系統：
大數據計算引擎：數據中臺要管理的數據規模和複雜度每每都很高（不然搞中臺屬於爲賦新詞強說愁），因此傳統的數據庫和數據倉庫基本上支撐不了。當前的技術環境下，基於Hadoop MapReduce或Spark幾乎是惟二的選擇，固然這也包括了這二者之上的Hive和Spark SQL。能用SQL就用SQL，易於維護，也易於數據血緣的收集。除此以外，流處理可能還須要Flink，交互式查詢可能要引入Impala或GreenPlum。
數據集成 / 同步 / 交換引擎：一方面數據中臺須要強大的數據集成和同步能力才能吸納各方數據。集成和同步的概念相近，同步更強調實時性。另外一方面，數據中臺每每由多種數據計算引擎構成，就須要同步或交換引擎實現不一樣引擎見的數據交換。
敏捷BI系統：建設數據中臺一般最重要的目的是爲了支持業務運營和決策，爲此須要基於數據中臺進一步開發數據產品。敏捷BI系統是開發數據產品快速、輕型的手段，可以儘快儘早的發揮數據中臺的價值。
此外，對於互聯網業務，統一的埋點引擎每每也是數據中臺所須要的。若是埋點的邏輯都不統一的話，建數據中臺的時候會發現數據的源頭就是亂的，後續也都無法作。其餘行業業務，數據採集也屬於基礎工做，也是要先作好的。
因而可知，建設數據中臺須要的技術支撐體系也是至關的龐大，複雜。所幸的是這十年來Google等領先的企業、Hadoop / Spark等開源社區以及大量的廠商大體聯合探索出了一條可行的路徑，方法論和技術路線都比較統一了。以此爲基礎，就能夠提供較成熟的數據中臺技術支撐產品，如網易杭研研發的「網易猛獁V6.0 + 網易有數」就是一套較完整的數據中臺產品。