建設數據中臺無疑是一個長期的戰略性工作，其建設內容包含了基礎設施、技術平臺、業務模型、團隊建設、管理協作等多種維度上的工作，對於任何一家企業來說都是不小的挑戰。本文我們將基於過去的實踐經驗給出一個實施策略，這個策略是基於大多數企業的數據生態現狀給出的，具有很高的借鑑價值。同時，在技術實施層面上，我們會做一個整體性的介紹。本文核心觀點援引自作者所著的《大數據平臺架構與原型實現：數據中臺建設實戰》一書，全書對數據中臺的理念、架構和具體實現做了詳細論述。
1 數據中臺的建設策略
數據中臺是企業的一個戰略性的基礎設施，建設週期長，牽涉範圍廣，從過去的實踐中我們總結了一些寶貴的經驗，作爲中颱的建設策略分享給讀者。數據中臺的建設可以分爲三個階段，如圖1 所示。
- 起步階段：搭建基礎設施；
- 積累階段：彙集數據，確立數據中臺的核心地位；
- 發力階段：基於豐富的數據集和完善的分析模型，產出大量有價值的分析結果，推動業務增長。
下面來分別看一下每個階段要做的事情和注意事項。
起步階段
起步階段的首要工作是進行基礎設施建設，包括服務器的採購、安裝和配置，網絡規劃，集羣搭建，各類工具的安裝和調試，資源和權限配置等。自建的IT 團隊通常會自行完成這些工作，使用供應商模式的甲方公司可以通過一個大數據項目完成初始的基礎設施建設工作。當然，也有的企業會選擇使用雲上的大數據PaaS 服務，直接跳過基礎設施的建設和維護工作。
在有了大數據集羣之後，需要通過一個到幾個項目來驗證平臺的各項組件和服務是否能滿足業務需求，對於在平臺上工作的團隊和個人來說也是一個熟悉和磨合的過程。初始階段應該使用迭代思想，不斷地調整平臺的技術堆棧、管理模式，爲平臺以後的發展壯大積累經驗。
積累階段
積累階段是一個相對艱苦而漫長的過程，數據中臺的團隊要在這個階段不斷地將企業的各個數據源接入進來，逐漸完善數據中臺上的數據版圖。中臺接入的數據越多、越全，就越能發揮出威力，最終的理想狀態是企業的全部數據都聚集在中臺上，前臺的任何數據需求都可以直接或稍做處理即可滿足。具體來說，這一階段需要完成如下工作：
- 廣泛對接企業的各個數據源；
- 不斷完善數據倉庫體系，對企業數據規範管理；
- 不斷完善數據服務體系，豐富數據供給的協議和形式；
- 搭建實時處理基礎設施，提供部分實時處理服務；
- 搭建人工智能及機器學習基礎設施，提供高級數據分析服務；
- 開始實現部分業務需求，產出業務價值。
發力階段
當數據中臺的數據版圖足夠完善時，就會自然地進入發力階段，這也是數據中臺的收穫期，在這一階段，數據中臺的優勢會體現得淋漓盡致，基於全面和完善的數據體系和強大靈活的數據分析能力，前臺和各業務中心對各種數據的需求都可以通過數據中臺滿足。前臺可以集中精力關注業務層面，快速敏捷地實現新業務功能。在發力階段，團隊需要着重開展如下工作：
-
與業務部門和業務中臺緊密合作，深入挖掘業務需求，利用豐富全面的企業數據開展多維度的洞察與分析，對業務決策提供強力支持；
-
深度介入業務的在線處理，通過數據中臺的實時處理能力解決應用系統很難實現的業務需求（如用戶積分的實時計算）；
-
將數據平臺上某些成熟的功能產品化，推廣到更多部門和業務場景中。
在發力階段，中臺團隊也將被錘鍊得更加專業和成熟，對於所管轄的數據會更加了解，對對接的業務更加熟悉，這也是中臺架構培育出的另一項重要資產：專業的人員和團隊。
以上三個階段是較大時間尺度上的切分，但並不意味着只有前一個階段徹底完成之後纔可以啓動後一個階段的工作，企業可以通過項目的方式驅動數據中臺建設，在項目實施過程中可以完成數據採集、處理、存儲、分析等一系列工作。每一個階段又可能會涉及一些基礎設施的建設，只要合理地安排好項目計劃，有規劃、有組織地推進項目開發與平臺建設之間的工作，就可以實現長期的戰略發展和短期業務需求之間的平衡。另外，數據中臺是對既有系統的改造，在建設過程中會面臨新業務需求由誰來實現及新老系統將如何更迭的問題，對此我們建議的做法是：
讓數據中臺優先承接新業務，逐步替換老系統。
意思是說，當有新的業務需求時，如果與原有系統的關聯不是很大，應該優先安排在數據中臺上實現，因爲這可以讓數據中臺儘快地產生業務價值，幫助企業建立對數據中臺的信心，如果只是一味地遷移遺留系統的功能，作爲一個持續的投入過程，在業務端很難看到ROI，這對於企業決策者和數據中臺團隊來說壓力是很大的，也是不明智的。
2 數據中臺的整體架構與建設內容
完備的數據中臺需要涵蓋：基礎設施建設、平臺架構設計、數據採集、主數據管理、實時計算、批處理與數據倉庫、數據存儲和作業調度等若干重要環節。作爲本系列的最後一篇文章，我們將給出一個數據中臺的架構參考，這是一種以Lambda架構爲藍本的通用型架構，這個架構曾經歷經多個項目驗證，穩定、可靠並具有廣泛的適用性。
首先，外部數據需要被數據採集組件採集到大數據平臺，然後針對實時處理和批處理分別寫入消息隊列和分佈式文件系統兩類不同的存儲介質上，因此從一開始，原始數據就冗餘了兩份，然後在實時處理和批處理兩條通道上同時對數據進行一系列的驗證、清洗、轉換和計算。實時處理的計算結果通常會寫入一個NoSQL 數據庫，以便後續實時查詢，批處理的計算結果往往寫回分佈式文件系統。實時處理和批處理在計算過程中都會用到主數據，批處理可以將主數據系統視爲一個數據源，將全部主數據導入大數據平臺上使用，這樣處理主數據就與處理普通數據無異，架構上無須做改動。但是對於流處理而言，在處理原始數據時需要實時獲取主數據，必須要有增強的主數據系統爲其提供服務。數據經過處理之後，就需要爲外部提供服務了。通俗地說，數據服務就是將處理後的數據提供給請求方，不同的數據供給方式將服務於不同的數據應用。常規的數據服務有：
- 將體量較小的結果集同步到傳統關係型數據庫，供報表工具或各種應用系統隨時查詢；
- 通過構建前端API 向前端應用直接提供數據查詢服務；
- 通過OLAP 引擎構建Cube，支持實時的、多維度的即時查詢。
最後，在數據服務的支撐下，會有一系列的數據可視化工具將數據展示給終端用戶。數據可視化工具一般分爲兩大類：一類是傳統的報表工具，另一類是基於Web 的頁面或移動端App。前者定製靈活，開發效率高，但是實時性較差，後者需要針對性地開發，定製性較差，成本較高，但是實時性好。
3 數據中臺的具體實現
目前，介紹中臺和數據中臺方法論的圖書和文章比較多，但是介紹如何具體實現的資源卻很少。一方面，數據中臺的架構體系龐大，技術堆棧非常深，另一方面，在很多細分領域（例如實時計算、作業調度）也沒有像樣的工程模板，這導致很多團隊在啓動數據中臺建設時往往感到無所侍從，也使得希望深入學習大數據技術的開發者由於缺少工程級的示例參考而感到迷茫。
如果在數據中臺領域有基於最佳實踐提煉出來的工程原型，幫助團隊快速啓動開發，上手就寫業務代碼的話，相信會對從事企業數據平臺建設的讀者來說有很大的幫助，而《大數據平臺架構與原型實現：數據中臺建設實戰》就是以此爲目標創作的。實際上，本系列前面文章的一系列觀點和建議也均來自於該書。實現數據中臺是一個宏大而複雜的話題，我們無法在這個系列文章中詳細展開了。如果大家認可本系列文章的觀點和見解，可以去京東或噹噹購買本書，學習如何去打造一個真正的數據中臺。
本系列結語
在本系列的七篇文章中，我們首先帶領讀者對企業的數據生態進行了一次“摸底”，告訴大家如何度量企業當前的數據能力，然後，我們轉入對中臺介紹的前期準備，先是以案例形式解釋了煙囪式架構產生的背景和現實原因，然後回顧了SOA爲什麼沒有能在煙囪架構治理上取得決成功，最後，我們引出了本系列的核心話題：中臺架構。在通過兩篇文章對中臺進行了詳細介紹之後，我們將重點放在了數據中臺上，前後介紹了數據中臺的顯著特徵以及建設策略。
希望本系列文章對讀者瞭解並建設中臺特別是數據中臺有所幫助。如果需或許更多數據中臺方面的內容，可參考《大數據平臺架構與原型實現：數據中臺建設實戰》一書。
作者介紹
耿立超，架構師，14年IT系統開發和架構經驗，對大數據、企業級應用架構、SaaS、分佈式存儲和領域驅動設計有豐富的實踐經驗，熱衷函數式編程。目前負責企業數據中臺的架構設計和開發工作，對Hadoop/Spark 生態系統有深入和廣泛的瞭解，參與過Hadoop商業發行版的開發，曾帶領團隊建設過數個完備的企業數據平臺，個人技術博客：https://laurence.blog.csdn.net/ 作者著有《大數據平臺架構與原型實現：數據中臺建設實戰》一書，該書已在京東和噹噹上線。