前言

數(shù)據(jù)中臺的概念從剛剛提出時的火熱到最近的降溫，似乎已經(jīng)加速走過了Gartner技術(shù)成熟度曲線的一半周期：從出現(xiàn)，到受吹捧，到遭質(zhì)疑，再到進(jìn)入低谷。數(shù)據(jù)中臺將逐漸消失，還是在成熟后成為像數(shù)據(jù)倉庫一樣的數(shù)據(jù)基礎(chǔ)架構(gòu)？最終的答案當(dāng)然要由市場給出，但我們想在本書中基于我們的經(jīng)驗(yàn)與思考，介紹數(shù)據(jù)中臺出現(xiàn)的根本原因、它在實(shí)現(xiàn)數(shù)據(jù)價值中的關(guān)鍵作用以及它的建設(shè)方式。

對于數(shù)據(jù)的價值，在大數(shù)據(jù)概念普及多年后的今天，大家應(yīng)該是普遍認(rèn)可的。我一直都在從事與數(shù)據(jù)相關(guān)的工作和研究，1996年在武漢大學(xué)跟隨何炎祥老師做分布式數(shù)據(jù)挖掘方面的研究，2000年在美國馬里蘭大學(xué)做流式數(shù)據(jù)引擎相關(guān)的探索，2005年加入Ask.com做分布式操作系統(tǒng)的數(shù)據(jù)存儲工作。2008年大數(shù)據(jù)概念出現(xiàn)，我在Ask.com做了一個非常明智的決定——使用開源的Hadoop（而不是我們內(nèi)部的分布式操作系統(tǒng)）替代日益昂貴、不堪重負(fù)的Oracle數(shù)據(jù)倉庫，雖然我們的內(nèi)部系統(tǒng)比Hadoop快一個數(shù)量級。替換了Oracle之后，我們還基于Hadoop平臺開發(fā)了一系列數(shù)據(jù)驅(qū)動的產(chǎn)品，滿足了不斷增長的數(shù)據(jù)產(chǎn)品需求。2011年，我加入Twitter并負(fù)責(zé)大數(shù)據(jù)流水線的建設(shè)，我在實(shí)踐中看到公司如何從數(shù)據(jù)中獲取價值，實(shí)現(xiàn)整個企業(yè)的數(shù)據(jù)驅(qū)動。與此同時，我也與硅谷其他公司同行進(jìn)行了廣泛的探討，這些使我堅定了自己的認(rèn)識：未來的企業(yè)一定是數(shù)據(jù)驅(qū)動的企業(yè)，未來的大數(shù)據(jù)一定會和Word、Excel、數(shù)據(jù)庫一樣，成為企業(yè)運(yùn)營人員的必備技能。

雖然數(shù)據(jù)的價值得到普遍認(rèn)可，企業(yè)數(shù)字化轉(zhuǎn)型的必要性也是大部分CEO的共識，但業(yè)界對一個關(guān)鍵問題的看法還遠(yuǎn)沒有達(dá)成一致：數(shù)據(jù)中臺是不是支撐企業(yè)數(shù)字化轉(zhuǎn)型的最合理的數(shù)據(jù)基礎(chǔ)架構(gòu)？在我們與國內(nèi)企業(yè)交流的時候，很多企業(yè)的CEO、CIO仍對數(shù)據(jù)中臺到底應(yīng)該是什么形態(tài)有不少疑問。與之不同的是，硅谷的大多數(shù)知名獨(dú)角獸公司有與數(shù)據(jù)中臺架構(gòu)相似的數(shù)據(jù)基礎(chǔ)架構(gòu)，即數(shù)據(jù)平臺（Data Platform），并以此作為企業(yè)數(shù)字化運(yùn)營的基礎(chǔ)。這些數(shù)據(jù)平臺雖然沒有被稱為中臺，但卻包含了我們通常認(rèn)為中臺需要承載的任務(wù)：打通企業(yè)各個部門之間的數(shù)據(jù)，形成統(tǒng)一的數(shù)據(jù)開發(fā)和使用規(guī)范，在企業(yè)各個部門之間實(shí)現(xiàn)數(shù)據(jù)能力的抽象、共享和復(fù)用。因此，本書試圖找到這些數(shù)據(jù)平臺的架構(gòu)與國內(nèi)普遍認(rèn)可的數(shù)據(jù)中臺架構(gòu)之間的通用理念，并從對業(yè)務(wù)的實(shí)際需求層面探討這些架構(gòu)設(shè)計理念的合理性和必要性。

與傳統(tǒng)技術(shù)中間件不一樣，數(shù)據(jù)中臺雖然也是承接底層數(shù)據(jù)和上層業(yè)務(wù)的中間層，但它的價值更多體現(xiàn)在與業(yè)務(wù)結(jié)合的能力矩陣，而不是簡單的數(shù)據(jù)標(biāo)準(zhǔn)化和報表工具上。各個業(yè)務(wù)部門可以使用不同的技術(shù)中間件，這樣雖然效率可能低一些，但是同樣可以滿足業(yè)務(wù)的要求。然而，分割的數(shù)據(jù)層無法對核心業(yè)務(wù)流程進(jìn)行全局還原和支持，無法實(shí)現(xiàn)數(shù)據(jù)驅(qū)動的全局決策和產(chǎn)品研發(fā)。與傳統(tǒng)的數(shù)據(jù)倉庫受事前建模的限制不一樣，數(shù)據(jù)中臺一般使用數(shù)據(jù)湖來存儲可以反映全局業(yè)務(wù)情況的原始數(shù)據(jù)，能夠?qū)诵臉I(yè)務(wù)流程進(jìn)行更全面、更深入的分析，并在此基礎(chǔ)上加快對市場的認(rèn)識和反應(yīng)，降低產(chǎn)品研發(fā)和試錯的成本，縮短時間。因此，定義好業(yè)務(wù)能力矩陣，讓業(yè)務(wù)部門看到數(shù)據(jù)中臺實(shí)現(xiàn)從0到1的關(guān)鍵數(shù)據(jù)能力，將大數(shù)據(jù)平臺從成本中心變成利潤中心，應(yīng)該是每個企業(yè)建設(shè)數(shù)據(jù)中臺的目標(biāo)。

除了確定對于業(yè)務(wù)的價值之外，建設(shè)數(shù)據(jù)中臺的一個根本問題是技術(shù)架構(gòu)的選擇及設(shè)計。我在Twitter架構(gòu)師委員會擔(dān)任負(fù)責(zé)大數(shù)據(jù)平臺的架構(gòu)師期間，每個星期都會參加由CTO組織的產(chǎn)品架構(gòu)評審和討論會。這些會議給我留下最深印象的不是對各種前沿技術(shù)的討論，也不是架構(gòu)設(shè)計中的技術(shù)難點(diǎn)攻關(guān)，而是技術(shù)架構(gòu)對業(yè)務(wù)的重大影響。很多時候，我們看到一個快速發(fā)展的業(yè)務(wù)因?yàn)樵缙诩軜?gòu)設(shè)計的問題而難以迭代，或者企業(yè)的發(fā)展受限于IT部門的效率。而一個高效的架構(gòu)能夠解放業(yè)務(wù)部門的生產(chǎn)力，真正賦能業(yè)務(wù)人員去完成以前想都不敢想的任務(wù)。其實(shí)數(shù)據(jù)中臺這個概念會在國內(nèi)出現(xiàn)，很大程度上也是因?yàn)榧軜?gòu)的問題。試想一下，如果我們在設(shè)計大數(shù)據(jù)平臺的時候就已經(jīng)考慮到了消除數(shù)據(jù)孤島、應(yīng)用孤島，統(tǒng)一數(shù)據(jù)規(guī)范，那么還需要單獨(dú)建設(shè)一個數(shù)據(jù)中臺嗎？

因此，我們在本書中討論了云原生架構(gòu)對于數(shù)據(jù)中臺的必要性。數(shù)據(jù)中臺的一個天然特性是支持多元異構(gòu)的數(shù)據(jù)以及處理這些數(shù)據(jù)的工具。雖然很多時候孤島的產(chǎn)生有組織架構(gòu)的原因，但是缺乏統(tǒng)一的數(shù)據(jù)平臺，無法快速支持不同部門對數(shù)據(jù)的不同需求，這些也是產(chǎn)生孤島的重要原因——因?yàn)闃I(yè)務(wù)部門需要不斷建設(shè)獨(dú)立的系統(tǒng)以滿足眼前的緊迫需求。在Twitter的大數(shù)據(jù)平臺建設(shè)過程中，公司規(guī)模從300人發(fā)展到4000人，集群規(guī)模從80臺服務(wù)器擴(kuò)展到8000臺服務(wù)器，利用云原生架構(gòu)我們快速滿足了各個部門對不同數(shù)據(jù)的需求，并極大簡化了統(tǒng)一數(shù)據(jù)規(guī)范的工作。各個業(yè)務(wù)部門可以快速自主地在平臺上開發(fā)自己的數(shù)據(jù)應(yīng)用，很少需要額外的系統(tǒng)支持，從而大大降低了出現(xiàn)孤島的可能性。隨著云平臺及容器技術(shù)的不斷成熟，我們認(rèn)為云原生架構(gòu)一定是未來數(shù)據(jù)平臺建設(shè)的必然選擇。

當(dāng)然，選擇一個合適的技術(shù)架構(gòu)只是數(shù)據(jù)中臺建設(shè)的開始，明確了最終目標(biāo)也不能保證實(shí)施一定會成功，我們還需要清晰的實(shí)施路徑和可落實(shí)的方法論。例如：建設(shè)數(shù)據(jù)中臺是否需要改變組織架構(gòu)？如何進(jìn)行頂層設(shè)計以及管理實(shí)施迭代？我們認(rèn)為，雖然數(shù)據(jù)中臺是一個復(fù)雜的項(xiàng)目，但是其建設(shè)流程是非常明確和可控制的。與業(yè)務(wù)中臺建設(shè)一般需要與業(yè)務(wù)組織架構(gòu)對齊不同，數(shù)據(jù)中臺建設(shè)很少要求對現(xiàn)有業(yè)務(wù)流程進(jìn)行大的改動，它的目的是深刻理解當(dāng)前的業(yè)務(wù)流程，提出優(yōu)化建議并提供能力支持。因此，數(shù)據(jù)中臺落地應(yīng)該采取業(yè)務(wù)驅(qū)動、快速落地、小步快跑的方式，而不是一開始就做一把大而全的“萬能鑰匙”。在這個過程中，使用合適的指標(biāo)體系衡量數(shù)據(jù)中臺的投入產(chǎn)出比，以及提供合適的工具賦能業(yè)務(wù)部門，有助于數(shù)據(jù)中臺得到業(yè)務(wù)部門的支持和認(rèn)可，順利完成中臺的實(shí)施。在本書中，我們根據(jù)自己的經(jīng)驗(yàn)和業(yè)界的一些成功實(shí)踐對數(shù)據(jù)中臺建設(shè)方法論進(jìn)行了深入的探討，希望能對讀者有所幫助。

1995年，我作為一名程序員參與了中國農(nóng)業(yè)銀行武漢分行辦公自動化系統(tǒng)的建設(shè)，此后25年，我有幸在國內(nèi)和美國硅谷見證了IT技術(shù)為企業(yè)帶來的運(yùn)營效率的巨大提升。雖然一直在一線，參與了很多有挑戰(zhàn)的技術(shù)工作，但是讓我收獲最大的還是作為企業(yè)技術(shù)管理者和數(shù)據(jù)負(fù)責(zé)人，與CEO、CMO、CIO一起探討如何用數(shù)據(jù)為企業(yè)產(chǎn)生價值，以及作為架構(gòu)師來推動OA、數(shù)據(jù)倉庫、ERP、CRM、大數(shù)據(jù)、人工智能在企業(yè)的各種復(fù)雜場景中的落地。對這兩個方面進(jìn)行交叉審視，可以發(fā)現(xiàn)技術(shù)架構(gòu)和業(yè)務(wù)能力間的獨(dú)特連接：二者看似沒有必然的因果關(guān)系，但在深層次上業(yè)務(wù)能力永遠(yuǎn)是技術(shù)架構(gòu)的推動力、決策者和買單方。從這個角度來講，數(shù)據(jù)庫的出現(xiàn)解決了交易的問題，數(shù)據(jù)倉庫的出現(xiàn)解決了關(guān)系型數(shù)據(jù)高維度的深度分析問題，大數(shù)據(jù)的出現(xiàn)解決了海量異構(gòu)數(shù)據(jù)的存儲和分析問題，而數(shù)據(jù)中臺的出現(xiàn)是為了解決業(yè)務(wù)打通和提供全局?jǐn)?shù)據(jù)能力的問題。數(shù)據(jù)庫、數(shù)據(jù)倉庫、大數(shù)據(jù)已經(jīng)成為企業(yè)IT架構(gòu)不可或缺的部分，我們認(rèn)為，無論數(shù)據(jù)中臺這個名稱是否會繼續(xù)存在，它所涉及的問題都是企業(yè)的數(shù)據(jù)基礎(chǔ)架構(gòu)必須解決的。因此，本書重點(diǎn)討論了對于業(yè)務(wù)需求和架構(gòu)設(shè)計而言數(shù)據(jù)中臺這個概念出現(xiàn)的必然性，也深入介紹了架構(gòu)選擇與業(yè)務(wù)需求之間的聯(lián)系，試圖為正在解決這些問題的企業(yè)和機(jī)構(gòu)提供一些架構(gòu)設(shè)計和落地方案上的參考。

本書是智領(lǐng)云團(tuán)隊(duì)協(xié)作的結(jié)晶，除了署名的三位作者之外，產(chǎn)品經(jīng)理王龍飛、王純、黃艷以及設(shè)計師龔清、市場部劉丹等也在本書的內(nèi)容組織、圖片設(shè)計方面做了大量工作。此外，非常感謝機(jī)械工業(yè)出版社華章公司的編輯楊福川和羅詞亮，他們在本書的寫作過程中提供了大量的幫助和反饋，讓我們得以順利完成本書的寫作。

希望本書能在應(yīng)對數(shù)字化轉(zhuǎn)型挑戰(zhàn)方面為讀者提供一些思路和參考，感謝大家的支持。

彭鋒

2021年4月