在大數據時代，凡是AI類項目的落地，都需要具備數據、算法、場景、計算力四個基本元素，缺一不可。
處理大數據已經不能僅僅依靠計算力就能夠解決問題，計算力只是核心的基礎，還需要結合不同的業務場景與算法相互結合，沉淀出一個完整的智能化平台。
數據中台就是以雲計算為數據智能提供的基礎計算力為前提，與大數據平台提供的數據資產能力與技術能力相互結合，形成數據處理的能力框架賦能業務，為企業做到數字化、智能化運營。
目前，外界與業內很多人對於數據中台的理解存在誤區，一直只是在強調技術的作用，強調技術對於業務的推動作用，但在商業領域落地的層面上，更多時候技術的發展和演進都是需要跟着業務走，技術的發展和進步需要基於業務方的需求與數據場景應用化的探索來反向推動。
這個也就是為什么最近知乎、脈脈都在瘋傳阿里在拆“大中台”？個人猜想，原因是沒有真正理解中台的本質，其實阿里在最初建設數據中台的目的主要是為了提升效率和解決業務匹配度問題，最終達到降本增效。
所以說“拆”是假的，在“拆”的同時一定在“合”，“拆”的一個方面是企業戰略布局層面上的規划，架構升級，如果眼界不夠高，格局不夠大，看到的一定只是表面；另一方面不是由於組織架構龐大而做“拆”的動作，而是只有這樣才能在效率和業務匹配度上，做到最大利益化的解耦。
數據中台出現的意義在於降本增效，是用來賦能企業沉淀業務能力，提升業務效率，最終完成數字化轉型。前一篇數據中台建設的價值和意義，提到過企業需要根據自身的實際情況，打造屬於自己企業獨有的中台能力。
因為，數據中台本身絕對是不可復制的，從BCG矩陣的維度結合各家市場資源、市場環境、市場地位以及業務方向來看，幾乎所有企業的戰略目標都是不一樣的。
一、數據中台演進的過程
從數據處理的維度來聊一聊數據中台經歷的四個階段：數據庫階段、數據倉庫階段、數據平台階段、數據中台階段。
- 數據庫階段：OLTP（事務處理）是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，記錄即時的增、刪、改、查。比如銀行交易、電商交易等
- 數據倉庫階段：數據倉庫系統的主要應用主要是OLAP（聯機分析處理），支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。比如復雜的動態報表分析、用戶價值分析等
- 數據平台階段：其實，目前業界並沒有對大數據平台做統一的定義，一般情況下，只要使用了Hadoop/Spark/Storm/Flink等這些分布式的實時或者離線計算框架，建立計算集群，並在上面運行各種計算任務
- 數據中台階段：指具有全域級、可復用的數據資產中心與數據能力中心，對海量數據進行采集、計算、存儲、加工，同時統一標准和口徑，提供干凈、透明、智慧的數據資產與高效、易用的數據能力來，能夠對接OLTP（事務處理）和OLAP（報表分析）的需求
剛好之前本人經歷過電商公司的0 - 1 - N，就拿電商行業來舉個例子，更好的讓大家理解數據中台演進的四個階段
1、數據庫階段
電商創業早期啟動非常容易，門檻相對來說較低，試錯成本較少。三五個小伙伴組個小團隊，做一個可以下單的前端頁面，雲上搭幾台服務器再加上一個MySQL數據庫，形成一個簡單的OLTP系統，就可以給用戶去使用，它的主要作用用於保證數據持久化存儲和簡單商品交易查詢。
現在估計很多小型電商與小程序創業者的初期都是這么干的，甚至找個外包團隊做完就開始對於市場試錯。
原因很簡單，從ROI來看，項目前期業務數據量不大，簡單的GB級別，每天的訂單和流量數都比較少，后端數據庫只要做簡單的單條數據的查詢和展示就能夠滿足了需求，根本就沒有什么高並發，批量處理等高深技術，就連做在初期做數據統計/分析用Excel就可以滿足需求。
最終，隨着客戶、訂單和外部流量的逐步上升，數據量從GB發展成TB級別，數據庫通過普通查詢存在較大的壓力，只能做升級改造，於是就有了數據倉庫的誕生。
2、數據倉庫階段
隨着業務指數級的增長，數據量增長的同時公司的組織架構慢慢變得龐大、復雜，面臨的問題也越來越多，越來越深入。公司上層關心的問題，從最初簡單的想知道“昨天、今天的GMV”、“上周的PV、UV是多少”、“某品類商品的環比、同比的增長比例是多少”，慢慢演化到希望通過數據進行精細化運營和用戶的價值模型分析。
希望通過數據統計/分析/挖掘，分析出用戶在某種特定的使用場景中，比如“18~25歲女性用戶在過去三個月對服裝類商品的購買行為與節假日促銷活動之間的關系”。
當公司運營和高層，提出此類非常具體的case，希望通過數據統計/分析/挖掘對公司運營決策起到關鍵性作用的問題，其實是很難從業務數據庫從直接調取出來。
原因是由於數據庫是面向事務的設計，數據倉庫是面向主題設計的。數據庫一般存儲在線交易數據，為捕獲數據而設計，在設計上數據庫是盡量避免冗余，一般采用符合范式的規則來設計。
比如，業務數據庫中的數據結構是為了完成商品交易而設計的，不是為了查詢和分析的便利設計的。數據倉庫存儲的一般是歷史數據，為分析數據而設計，在設計上是有意引入冗余，采用反范式的方式來設計。
數據庫和數據倉庫兩個基本的元素都有維表和事實表。（維表是看問題的角度，比如時間，部門、人，維表放的就是這些東西的定義，事實表里放着要查詢的數據，同時有維表的ID）。
因此，數據倉庫的出現，並不是要取代數據庫，而是為了更好的做數據分析和報表需求分析，主要處理OLAP（聯機分析處理）需求。
但是，隨着客戶、訂單和外部流量的逐步上升，數據量從TB發展成PB級別，原來的技術架構越來越不能支持海量數據處理，這時候又有了數據平台的誕生。
3、數據平台階段
第一、企業業務系統過多，彼此數據沒有打通。涉及分析數據的過程當中，需要先從各個系統尋找到相應的數據，然后提取數據進行整合打通，才能做數據分析。在這個過程中人為進行整合出錯率高，分析效果不及時，導致整體的效率低下，數據遷移、數據同步的滯后與錯誤；
第二、業務系統壓力大，架構相對笨重，做數據分析計算消耗資源很大。需要通過將數據抽取出來，經過獨立服務器來處理數據查詢、分析任務，來釋放業務系統的壓力；
第三、性能問題，公司業務越來越復雜，數據量越來越大。歷史數據的積累嚴重，數據沒有得到使用。原始數據系統不能承受更大數據量的處理時，數據處理效率嚴重下降。
於是，通過整合Hadoop/Spark/Storm/Flink等分布式的離線與實時計算框架，建立計算集群，並在上面運行各種計算任務，搭建大數據平台，使得平台具有數據互聯互通、支持多數據集實時同步、支持數據資源管理，實現多源異構數據的整合管控能力；
可以提供完善的大數據分析基礎運行環境，提供統一二次開發接口等能力的，用這些能力來解決大數據存儲與計算問題，提升數據分析效率以及用戶畫像系統/推薦/搜索系統的運用落地。
4、數據中台階段
數據量的指數級增長，從PB發展成EB級別，為了更好的賦能業務，企業啟動中台戰略，打通各個業務線的數據，整合匯集數據，在底層通過技術手段解決數據統一存儲和統一計算問題。
在數據服務層通過數據服務化的Data API的方式，打通數據平台和前台的業務層對接，結合算法，把前台業務的分析需求和交易需求直接對接到中台來，通過數據中台處理和邏輯運算，然后在反向賦能業務，真正做到意義上的『一切業務數據化，一切數據業務化』。
二、數據倉庫、數據平台和數據中台的架構
數據倉庫架構圖
1、采集層
從各種數據源中采集數據和存儲到數據到存儲在基於Hadoop分布式文件系統HDFS上，期間做ETL操作。其中數據采集一般采用Flume收集日志，采用Sqoop將RDBMS以及NoSQL中的數據同步到HDFS上
數據源主要有：日志數據（服務器日志 + 系統日志等）+ 業務數據庫（Mysql、Oracle等）+ 埋點數據（服務端埋點 + 移動端埋點數據等）+ 其他數據（Excel手工錄入的數據、合作伙伴提供的接口數據、第三方爬蟲數據、合法購買的第三方數據等）
2、存儲與分析層
主要有離線計算 + 實時計算
- 存儲系統：基於Hadoop分布式文件系統對采集層的數據進行存儲
- 消息系統：加入Kafka防止數據丟失
- 離線計算：是對實時性要求不高的部分，通常將計算結果保存在Hive中
- 實時計算：使用Spark Streaming、Storm消費Kafka中收集的日志數據，然后通過實時計算，將結果保存在Redis中
- 機器學習：用Spark MLlib提供的機器學習算法
3、共享層
通過離線和實時計算的數據分析與計算后的結果存儲在數據共享層，做數據共享層，主要做數據分發和調度中心。因為通過Hive、MR、Spark、SparkSQL分析和計算的結果，是存儲在HDFS上，業務和應用不可能直接從HDFS上獲取數據。其中使用Kylin作為OLAP引擎做多維度分析
4、數據應用
報表展示 + 數據分析 + 即席查詢 + 數據挖掘
5、任務調度與監控
數據平台架構圖
1、采集層
基於Hadoop分布式文件系統對采集層的數據進行存儲。
- 結構化數據：通過兩種途徑抽取並存放到HDFS分布式文件系統中，能夠序列化的數據，直接存放到HDFS中;不能夠序列化的數據,通過數據整理后統一存放在分布式數據庫環境中, 再經過序列化后和整理后還不能序列化的數據一樣直接存放到HDFS中;
- 半結構化和非結構化數據：各種日志數據(通常序列化半結構化數據)直接存放到HDFS中;點擊流和數據接口中的數據(通常序列化半結構化數據)直接存放到HDFS中；非結構化的數據直接存放到HDFS中
2、數據層
一方面，把相關業務結構化數據和有一定格式關系的半結構化的數據存放在Hadoop Hive數據倉庫中，基於業務需求，按照特定的業務主題域進行數據集市的構建；另一方面把相關業務中半結構化的數據直接存放在HDFS分布
3、計算層
離線計算 + 實時計算
4、應用層
可視化數據分析報表 + 搜索/推薦/廣告具體的場景應用
5、任務調度與監控
阿里數據中台架構圖
- 為了保證快速、高效、高質量數據接入，建立統一數據質量管理平台 + 數據能力中心
- 通過數據采集和接入為切入角度，按照業態接入內部數據（比如淘寶、天貓、盒馬等）+ 外部數據（爬蟲數據、第三方合作數據、埋點數據等）
- 把數據抽取到計算平台，通過以“業務板塊 + 業務過程 + 分析維度”為架構去構建“數據共享中心”，構建OneData體系
- 在數據共享中心的上層，以業務/自然對象 + 萃取標簽“為架構構建“數據唯一中心”，構建OneID體系，打通消費者數據體系、企業數據體系、內容數據體系等
- 經過深度加工后，得到干凈、透明、智慧的數據賦能產品與業務線；通過統一的數據服務中間件“OneService”提供統一數據服務，讓『一切業務數據化，一切數據業務化』
三、數據倉庫、數據平台和數據中台的區別與聯系
數據倉庫、數據平台和數據中台的區別與聯系：
1、在概念層面上
數據平台和數據中台的技術能力都是基於數據倉庫發展而來的，在數據建設理論上一脈相承，他們處理的對象都是海量數據，服務目的、商業價值也同樣類似。其實中平台和中台，兩者在能力上都有對外都提供Open API服務。
一方面，中台是業務應用，不具體代表着某種技術，它不是最終用戶能直接使用的，必須結合企業的各個數據業務場景；另一方面，平台是不帶有業務特征性質的，主要匯集其他人的能力，整合成平台的能力，相對來說是靜態的，而中台是動態變化的本身，需要通過數據驅動的方式來滋養業務，不斷訓練調整業務模型和業務算法提供的能力，提供給其他系統和平台集成的能力。
2、在數據層面上
數據倉庫的數據來源主要來源於RDBMS，其中存儲的數據格式以結構化數據為主，這些數據並非企業全量數據，而是根據企業業務需求做針對性整合、抽取。數據平台和數據中台的數據來源的期望都是全域級的數據，主要有結構化數據、半結構化數據、非結構化數據等
3、在目標層面上
- 數據倉庫基於單機的，一旦數據量變大，會受單機容量、計算以及性能等方面的限制。主要用來做報表分析，目的性相對來說單一，只是針對相關分析報表用到基礎數據，進行抽取、整合、數據清洗和分析。比如，新增一張報表，就要從底層到上層再做一次，流程上相對來說繁瑣；
- 數據平台建立是為了解決數據倉庫不能處理非結構化數據和報表開發周期長的問題以及計算和性能等問題。匯集整合打通數據，數據清洗后，當業務提出需求的時候，把業務方需要的若干個小數據集單獨提取出來，以數據集的形式提供給業務方去使用；
- 數據中台通常會對來自多方面的基礎數據進行數據清洗后，然后按照主題域的概念建立多個以事物為主的主題域；和數據平台在底層建設上都是基於分布式計算平台和存儲平台，理論上可以通過無限擴充平台的計算和存儲能力。目標是都是為了融合整個企業的全域級數據，打通數據之間的隔閡，消除數據標准和口徑不統一的問題。
4、在應用層面上
建立在數據中台上的數據應用場景，不僅僅只是面向於數據報表開發分析與展示處理，更多是將數據變成服務化的方式，然后提供給業務系統。