阿里巴巴的數據處理經歷了四個階段，分別是：
1、數據庫階段，主要是OLTP（聯機事務處理）的需求；
2、數據倉庫階段，OLAP（聯機分析處理）成爲主要需求；
3、數據平臺階段，主要解決BI和報表需求的技術問題；
4、數據中臺階段，通過系統來對接OLTP（事務處理）和OLAP（報表分析）的需求，強調數據業務化的能力。
第一個階段是數據庫階段。
淘寶還只是一個簡單的網站，淘寶的整個結構就是前端的一些頁面，加上後端的DB（DataBase，數據庫），只是個簡單的OLTP系統，主要就是交易的事務處理。
這個階段，互聯網黃頁纔剛剛出現，數據來源大部分還是傳統商業的ERP/CRM的結構化數據，數據量並不大，也就是GB的級別。簡單的DB就能滿足需求。
這裏要說明的是，OLTP的交易場景和OLAP的分析場景區別在於，前者強調高併發、單條數據簡單提取和展示（增刪改查），後者對併發的要求不高，但是需要打通不同的數據庫，比如ERP、CRM、行爲數據等等，並且能夠進行批量的數據處理，也就是通常說的低併發，大批量（批處理）、面向分析（query+計算，用於製作報表）。
隨着淘寶用戶超過100萬，分析需求的比重就越來越大。淘寶需要知道它的交易來自於哪些地區，來自於哪些人，誰在買淘寶的東西等等，於是，就進入了數據處理的第二個階段。
第二個階段是數據倉庫階段。
正如前文所述，OLTP和OLAP對數據存儲和計算的需求非常不一樣，前者處理的是結構化的交易數據，而OLAP對應的是互聯網數據，而互聯網裏面數據量最大的是網頁日誌，90%以上的數據都是點擊（log）什麼的非結構化的數據，而且數據量已經達到了TB的級別。
針對分析需求，就誕生了數據倉庫（DW，DataWarehouse），用Oracle RAC搭建了阿里巴巴第一個DW，解決大量數據的存儲和計算需求，也就是去把非結構化的數據轉化成結構化數據，存儲下來。
這個階段，DW支持的主要就是BI和報表需求。數據庫（DB）這時也在從傳統DB轉向分佈式DB。主要原因是以前交易穩定，併發可控，傳統DB能滿足需求，但是後來隨着交易量的增長，併發越來越不可控，對分佈式DB的需求也就出來了。
隨着數據量越來越大，從TB進入了PB級別，原來的技術架構越來越不能支持海量數據處理，這時候就進入了第三個階段。
第三個階段是數據平臺階段，這個階段解決的還是BI和報表需求，但是主要是在解決底層的技術問題，也就是數據庫架構設計的問題。
這在數據庫技術領域被概括爲「Shared Everything、Shared Nothing、或Shared Disk」，說的就是數據庫架構設計本身的不同技術思路之爭。
Shared Everything一般是針對單個主機，完全透明共享CPU/MEMORY/IO，並行處理能力是最差的，典型的代表SQLServer。
Shared Disk的代表是Oracle RAC，用戶訪問RAC就像訪問一個數據庫，但是這背後是一個集羣，RAC來保證這個集羣的數據一致性。
問題在於，Oracle RAC是基於IOE架構的，所有數據用同一個EMC存儲。在海量數據處理上，IOE架構有天然的限制，不適合未來的發展。阿里巴巴的第一個數據倉庫就是建立在Oracle RAC上，由於數據量增長太快，所以很快就到達20個節點，當時是全亞洲最大的Oracle RAC集羣，但阿里巴巴早年算過一筆賬，如果仍然沿用IOE架構，那麼幾年後，阿里的預計營收還遠遠趕不上服務器的支出費用，就是說，如果不去IOE，阿里會破產。
Shared Nothing的代表就是Hadoop。Hadoop的各個處理單元都有自己私有的存儲單元和處理單元，
各處理單元之間通過協議通信，並行處理和擴展能力更好。中間有一個分佈式調度系統，會把表從物理存儲上水平分割，分配給多臺服務器。
Hadoop的好處是要增加數據處理的能力和容量，只需要增加服務器就好，成本不高，在海量數據處理和大規模並行處理上有很大優勢。
綜上，用一個關鍵詞來概括第三階段就是「去IOE」，建立Shared Nothing的海量數據處理平臺來解決數據存儲成本增長過快的問題。在阿里巴巴，前期是Hadoop，後期轉向自研的ODPS。
第四階段是數據中臺階段。
這個階段的特徵是數據量的指數級增長，從PB邁向了EB級別，未來會到什麼量級，我也說不清楚。
主要是因爲，2015年之後，IOT（物聯網）發展起來，帶動了視圖聲（視頻、圖像、聲音）數據的增長，未來90%的數據可能都來自於視圖聲的非結構化數據，這些數據需要視覺計算技術、圖像解析的引擎+視頻解析的引擎+音頻解析的引擎來轉換成結構化數據。5G技術的發展，可能會進一步放大視圖聲數據的重要性。
線下要想和線上一樣，通過數據來改善業務，就要和線上一樣能做到行爲可監測，數據可收集，這是前提。線下最大量的就是視圖聲數據，而這些數據靠人來手工收集，肯定是不靠譜的，依靠IOT技術和算法的進步，最終會通過智能端來自動化獲取數據。
要使用這些數據，光有視覺算法和智能端也不行，要有云來存儲和處理這些數據，以及打通其他領域的數據。
另一方面，從業務來看，數據也好，數據分析也好，最終都是要爲業務服務的。也就是說，要在系統層面能把OLAP和OLTP去做對接，這個對接不能靠人來完成，要靠智能算法。
目前的數據中臺，最底下的數據平臺還是偏技術的，是中臺技術方案的其中一個組件，主要解決數據存儲和計算的問題；在上面就是一層數據服務層，數據服務層通過服務化API能夠把數據平臺和前臺的業務層對接；數據中臺裏面就沒有人的事情，直接系統去做對接，通過智能算法，能把前臺的分析需求和交易需求去做對接，最終賦能業務。
數據中臺處於計算後臺和業務前臺之間，其內核能力是以業務視角而非技術視角智能化構建數據、管理數據資產，並提供數據調用、數據監控、數據分析和數據展示等多種服務。
承技術後臺，啓業務前臺。基於數據，深入業務。
主要方法論：OneData、OneEntity、OneService
OneData：致力於實現數據的標準和統一，讓數據成爲資本而非成本
OneEntity：致力於實現實體統一，讓數據融通而非以孤島的形式存在
OneService：致力於實現數據服務統一，讓數據複用而不是複製
數據中臺未來一定需要具備三種能力。
第一是數據模型能力。
在業務層面，業務抽象能夠解決80%的共性問題，開放的系統架構來解決20%的個性問題，但同時又要把平臺上的業務邏輯分開，因爲不同的業務邏輯之間可能有衝突。
這在數據中臺就表現爲數據的中心化，也就是數據的高內聚、低耦合，需要對共性問題抽象出業務的規則，建立數據模型，一個好的內聚模塊能夠解決一個事情，同時又要降低模塊和模塊之間的耦合度，讓模塊具有良好的可讀性和可維護性。
這裏的前提是要有真正懂業務能沉澱經驗的人，以及要在企業層面開展數據治理，讓數據能夠準確、適度共享、安全地被使用。
第二是AI算法模型能力。
要實現數據業務化，前提是做到數據的資產化。要能夠從數據原油裏面，去提煉出可以使用的汽油。
比如說數據的標籤化，背後就有投入產出比的考量：通過標籤，廣告主可以非常方便快捷地去建立自己的人羣包，實現精準營銷，同時投放的ROI也是可見的、透明的，廣告主可以自己去評估數據資產的使用情況。
第三是行業的應用能力，也就是我們通常說的數據業務化能力。
數據中臺的核心價值分析：
1、數據中臺是精準服務的基礎能力
今天的浙江移動已經將2000個基礎模型作爲所有數據服務開發的基礎，這些基礎模型做到了“書同文，車同軌”，無論應用的數據模型有多複雜，總是能溯源到2000張基礎表，這奠定了數據覈對和認知的基礎，最大程度的避免了“重複數據抽取和維護帶來的成本浪費。”
曾經企業的數據抽取就有多份，報表一份，數據倉庫一份，地市集市一份，無論是抽取壓力、維護難度及數據一致性要求都很高。
同時，統一的基礎模型將相關業務領域的數據做了很好的匯聚，解決了數據互通的訴求，這點的意義巨大，誰都知道數據1+1>2的意思。
2、數據中臺是業務發展的源動力
在企業內，無論是專題、報表或取數，當前基本是煙囪式數據生產模式或者是項目制建設方式，必然導致數據知識得不到沉澱和持續發展，從而造成模型不能真正成爲可重用的組件，無法支撐數據分析的快速響應和創新。究其原因是模型建設往往是項目式的建設方式，一旦項目結束，在面對業務提出更多需求時，項目模型團隊可能已經撤離了，或者考覈指標早已經隨着項目結束，模型提供者在主觀上沒有太大的積極性去滿足新的需求，如果當初模型的擴展性設計的不好，或者時間太緊，或者系統穩定的需要，往往導致有心無力滿足新的需求，結果是數據模型無法再擴展，成爲事實上穩定的但無用的模型。
其實，業務最不需要的就是模型的穩定，一個數據模型如果一味追求穩定不變，一定程度就是故步自封，這樣的做法必然導致其他的新的類似的數據模型產生，當越來越多的模型都採用自建的方式滿足需求時，意味着老的數據模型就可能要離開歷史舞臺了，而留下的是割裂的成千上萬的模型，也就失去了模型知識沉澱的可能，曾經做過一張幾百個字段的萬能寬表，由於太大後來就沒人敢去動它，隨着新的業務不斷增加，這張寬表的價值卻越來越低直至退出歷史舞臺。
數據模型不需要“穩定”，而需要不斷的滋養，只有在滋養中才能從最初的字段單一到逐漸成長爲企業最爲寶貴的模型資產。其實標籤也一樣，做過不少異動標籤或離網模型，曾經效果不錯，隨着公司轉型流量經營，原來以語音異動判斷爲主的這類標籤開始難以適應變化，但後續已經沒人能改得動它，這個標籤也就退出了歷史舞臺，退出的可不僅僅是一個標籤，這個標籤承載的所有的既有經驗也就被廢棄掉了，想想這些標籤當初花了多大的代價做成就會感覺非常可惜。再以報表爲例，企業報表成千上萬的原因往往也是沒有沉澱造成的，針對一個業務報表，由於不同的業務人員提出的角度不同，會幻化出成百上千的報表，如果有報表中臺的概念，就可以提出一些基準報表的原則，比如一個業務一張報表，已經有的業務報表只允許修改而不允許新增，自然老報表就會由於新的需求而不斷完善，從而能演化成企業的基礎報表目錄，否則就是一堆報表的堆砌，後續的數據一致性問題層出不窮，管理成本急劇增加，人力投入越來越多，這樣的事情在每個企業都在發生。
3、數據中臺是業務創新基礎
企業的數據創新一定要站在巨人的肩膀上，即從數據中臺開始，不能總是從基礎做起，數據中臺是數據創新效率的保障。
搞過機器學習的都知道，沒有好的規整數據，數據準備的過程極其冗長，這也是數據倉庫模型的一個核心價值所在，比如運營商中要獲取3個月的ARPU數據，如果沒有融合模型的支撐，得自己從賬單一層層彙總及關聯，速度可想而知。
很多合作伙伴的數據科學家到一個企業水土不服，除了業務上不熟悉外，往往還面臨着數據準備的困境，取數的高難度導致他難以快速的去驗證想法，企業想借助外力去搞數據創新有時成了一廂情願。
標籤也一樣，企業打造標籤可並不僅僅是做幾個標籤那麼簡單，它需要打造的是一個標籤服務平臺，要能最大限度的規範標籤的格式，接入方式，組合方式，調用方式等等，只有這樣，基於標籤的二次快速創新纔有可能，企業每發佈一個新的標籤，就意味着新增了一種能力，這纔是數據知識的真正傳承。
比如當常駐地模型發佈成爲標籤平臺的一個標籤後，以後凡是涉及到常駐地判斷的都可以直接調用，這極大降低了關於用戶位置數據準備的成本。
在如今的互聯網時代，企業都在全力謀求轉型，轉型的關鍵是要具備跟互聯網公司一樣的快速創新能力，大數據是其中一個核心驅動力，但擁有大數據還是不夠的，數據中臺的能力往往最終決定速度，擁有速度意味着試錯成本很低，意味着可以再來一次。
4、數據中臺是技術發展的源泉
記得筆者剛進企業的時候，要獲得成長一是靠人帶，二是找人問，三是自己登陸各種系統去看源代碼，這樣的學習比較支離破碎，其實很難了解全貌，無法知道什麼東西對於企業是最重要的，獲得的文檔資料也往往也是過了時的。
現在有了數據中臺，很多成長問題就能解決，有了基礎模型，新人可以系統的學習企業有哪些基本數據能力，O域數據的增加更是讓其有更廣闊的視野，有了融合模型，新人可以知道有哪些主題域，從主題域切入去全局的理解公司的業務概念，有了標籤庫，新人可以獲得前人的所有智慧結晶，有了數據管理平臺，新人能清晰的追溯數據、標籤和應用的來龍去脈，所有的知識都是在線的，最新的，意味着新人的高起點。
更爲關鍵的是，數據中臺讓新人擺脫了在起步階段對於導師的過渡依賴，能快速的融入團隊，在前人的基礎上進行創新。
數據中臺天然的統一，集成的特性，有可能讓新人打破點線的束縛，快速構築起自己的知識體系，成爲企業數據領域的專家。