目前，外界與業內很多人對於數據中台的理解存在誤區，一直只是在強調技術的作用。為了統一大家的認知，更加清晰的認識數據中台出現的意義。本文將從數據平台進化演變的角度，對數據中台進行深入的介紹。
前 言
在大數據時代，凡是AI類項目的落地，都需要具備數據、算法、場景、計算力四個基本元素，缺一不可。處理大數據已經不能僅僅依靠計算力就能夠解決問題，計算力只是核心的基礎，還需要結合不同的業務場景與算法相互結合，沉澱出一個完整的智能化平台。數據中台就是以雲計算為數據智能提供的基礎計算力為前提，與大數據平台提供的數據資產能力與技術能力相互結合，形成數據處理的能力框架賦能業務，為企業做到數字化、智能化運營。
目前，外界與業內很多人對於數據中台的理解存在誤區，一直只是在強調技術的作用，強調技術對於業務的推動作用，但在商業領域落地的層面上，更多時候技術的發展和演進都是需要跟着業務走，技術的發展和進步需要基於業務方的需求與數據場景應用化的探索來反向推動。這個也就是為什麼知乎、脈脈都在瘋傳阿里在拆“大中台”？個人猜想，原因是沒有真正理解中台的本質，其實阿里在最初建設數據中台的目的主要是為了提升效率和解決業務匹配度問題，最終達到降本增效，所以說“拆”是假的，在“拆”的同時一定在“合”，“拆”的一個方面是企業戰略布局層面上的規劃，架構升級，如果眼界不夠高，格局不夠大，看到的一定只是表面；另一方面不是由於組織架構龐大而做“拆”的動作，而是只有這樣才能在效率和業務匹配度上，做到最大利益化的解耦。
數據中台出現的意義在於降本增效，是用來賦能企業沉澱業務能力，提升業務效率，最終完成數字化轉型。前一篇數據中台建設的價值和意義，提到過企業需要根據自身的實際情況，打造屬於自己企業獨有的中台能力。
因為，數據中台本身絕對是不可複製的，從BCG矩陣的維度結合各家市場資源、市場環境、市場地位以及業務方向來看，幾乎所有企業的戰略目標都是不一樣的。如果，有人說能把中台賣給你、對於中台的解讀只講技術，不講業務，只講產品，不講業務，不以結合企業業務目標來解決效率和匹配度為目的的都有耍流氓嫌疑。數據中台的使命和願景是讓數據成為如水和電一般的資源，隨需獲取，敏捷自助，與業務更多連接，使用更低成本，通過更高效率的方式讓數據極大發揮價值，推動業務創新與變革。
為了進一步統一大家的認知，更加清晰的認識數據中台出現的意義，本篇按順序介紹如下:
數據中台演進的過程
數據倉庫、數據平台和數據中台的概念
數據倉庫、數據平台和數據中台的架構
數據倉庫、數據平台和數據中台的區別與聯繫
1
數據中台演進的過程
從數據處理的維度來聊一聊數據中台經歷的四個階段：數據庫階段、數據倉庫階段、數據平台階段、數據中台階段。
數據庫階段：OLTP（事務處理）是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，記錄即時的增、刪、改、查。比如銀行交易、電商交易等
數據倉庫階段：數據倉庫系統的主要應用主要是OLAP（聯機分析處理），支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。比如複雜的動態報表分析、用戶價值分析等
數據平台階段：其實，目前業界並沒有對大數據平台做統一的定義，一般情況下，只要使用了Hadoop/Spark/Storm/Flink等這些分布式的實時或者離線計算框架，建立計算集群，並在上面運行各種計算任務，具有數據互聯互通、支持多數據集實時同步、支持數據資源管理、實現多源異構數據的整合管控；提供完善的大數據分析基礎運行環境，提供統一二次開發接口等能力的，就算的上理解上的大數據平台。主要是為了解決大數據存儲計算 + 數據應用管理 + 任務監控 + 數據資產管理 + 開發管理 + 可視化報表需求等
數據中台階段：指具有全域級、可復用的數據資產中心與數據能力中心，對海量數據進行採集、計算、存儲、加工，同時統一標準和口徑，提供乾淨、透明、智慧的數據資產與高效、易用的數據能力來，能夠對接OLTP（事務處理）和OLAP（報表分析）的需求，從業務架構設計到模型設計，從數據研發到數據服務，做到數據可管理、可追溯、可規避重複建設，強調的是數據業務化的能力。
數據中台經歷的四個階段
剛好之前本人經歷過電商公司的0 - 1 - N，就拿電商行業來舉個例子，更好的讓大家理解數據中台演進的四個階段
1、數據庫階段
電商創業早期啟動非常容易，門檻相對來說較低，試錯成本較少。三五個小夥伴組個小團隊，做一個可以下單的前端頁面，雲上搭幾台服務器再加上一個MySQL數據庫，形成一個簡單的OLTP系統，就可以給用戶去使用，它的主要作用用於保證數據持久化存儲和簡單商品交易查詢。
現在估計很多小型電商與小程序創業者的初期都是這麼乾的，甚至找個外包團隊做完就開始對於市場試錯。原因很簡單，從ROI來看，項目前期業務數據量不大，簡單的GB級別，每天的訂單和流量數都比較少，後端數據庫只要做簡單的單條數據的查詢和展示就能夠滿足了需求，根本就沒有什麼高並發，批量處理等高深技術，就連做在初期做數據統計/分析用Excel就足於滿足需求
當用戶、商品和流量上升的時候，可以採取兩種過渡方案。方案一是對於查詢速度慢、性能不足，升級單機配置，通過緩存優化 + 數據庫優化（SQL語句優化、SQL索引優化、分庫分表、SQL腳本優化）+ 內存優化 + 線程池優化 + 使用NIO通信機制 + 阻塞隊列（程序優化），虛擬機（docker）+ SSD + 合適的IO模型等方式對單機配置做最大性能上的優化；方案二是改變原有的模式，加服務器和多個業務數據庫，對數據庫表進行分庫分表加單索引、雙索引以支撐業務交易的穩定和高並發，通過這種方式來支撐業務數字和指標，同樣可以快速的從業務數據庫里查詢出來。
最終，隨着客戶、訂單和外部流量的逐步上升，數據量從GB發展成TB級別，數據庫通過普通查詢存在較大的壓力，只能做升級改造，於是就有了數據倉庫的誕生。
2、數據倉庫階段
隨着業務指數級的增長，數據量增長的同時公司的組織架構慢慢變得龐大、複雜，面臨的問題也越來越多，越來越深入。公司上層關心的問題，從最初簡單的想知道“昨天、今天的GMV”、“上周的PV、UV是多少”、“某品類商品的環比、同比的增長比例是多少”，慢慢演化到希望通過數據進行精細化運營和用戶的價值模型分析。希望通過數據統計/分析/挖掘，分析出用戶在某種特定的使用場景中，比如“18~25歲女性用戶在過去三個月對服裝類商品的購買行為與節假日促銷活動之間的關係”。
當公司運營和高層，提出此類非常具體的case，希望通過數據統計/分析/挖掘對公司運營決策起到關鍵性作用的問題，其實是很難從業務數據庫從直接調取出來。
原因是由於數據庫是面向事務的設計，數據倉庫是面向主題設計的。數據庫一般存儲在線交易數據，為捕獲數據而設計，在設計上數據庫是盡量避免冗餘，一般採用符合範式的規則來設計。比如，業務數據庫中的數據結構是為了完成商品交易而設計的，不是為了查詢和分析的便利設計的。數據倉庫存儲的一般是歷史數據，為分析數據而設計，在設計上是有意引入冗餘，採用反範式的方式來設計。數據庫和數據倉庫兩個基本的元素都有維表和事實表。（維表是看問題的角度，比如時間，部門、人，維表放的就是這些東西的定義，事實表裡放着要查詢的數據，同時有維表的ID）。
因此，數據倉庫的出現，並不是要取代數據庫，而是為了更好的做數據分析和報表需求分析，主要處理OLAP（聯機分析處理）需求。
但是，隨着客戶、訂單和外部流量的逐步上升，數據量從TB發展成PB級別，原來的技術架構越來越不能支持海量數據處理，這時候又有了數據平台的誕生。
3、數據平台階段
第一、企業業務系統過多，彼此數據沒有打通。涉及分析數據的過程當中，需要先從各個系統尋找到相應的數據，然後提取數據進行整合打通，才能做數據分析。在這個過程中人為進行整合出錯率高，分析效果不及時，導致整體的效率低下，數據遷移、數據同步的滯後與錯誤；
第二、業務系統壓力大，架構相對笨重，做數據分析計算消耗資源很大。需要通過將數據抽取出來，經過獨立服務器來處理數據查詢、分析任務，來釋放業務系統的壓力；
第三、性能問題，公司業務越來越複雜，數據量越來越大。歷史數據的積累嚴重，數據沒有得到使用。原始數據系統不能承受更大數據量的處理時，數據處理效率嚴重下降。
於是，通過整合Hadoop/Spark/Storm/Flink等分布式的離線與實時計算框架，建立計算集群，並在上面運行各種計算任務，搭建大數據平台，使得平台具有數據互聯互通、支持多數據集實時同步、支持數據資源管理，實現多源異構數據的整合管控能力；可以提供完善的大數據分析基礎運行環境，提供統一二次開發接口等能力的，用這些能力來解決大數據存儲與計算問題，提升數據分析效率以及用戶畫像系統/推薦/搜索/廣告系統的運用落地。
4、數據中台階段
數據量的指數級增長，從PB發展成EB級別，為了更好的賦能業務，企業啟動中台戰略，打通各個業務線的數據，整合彙集數據，在底層通過技術手段解決數據統一存儲和統一計算問題，在數據服務層通過數據服務化的Data API的方式，打通數據平台和前台的業務層對接，結合算法，把前台業務的分析需求和交易需求直接對接到中台來，通過數據中台處理和邏輯運算，然後在反向賦能業務，真正做到意義上的『一切業務數據化，一切數據業務化』。
2
數據倉庫、數據平台和數據中台的概念
數據倉庫、數據平台以及數據中台圖
數據倉庫、數據平台和數據中台概念
數據倉庫是為企業所有級別的決策制定過程，提供所有類型數據支持的戰略集合。它是單個數據存儲，出於分析性報告和決策支持目的而創建。可以為需要業務智能的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。是一個相對具體的功能概念，是存儲和管理一個或多個主題數據的集合，為業務提供服務的方式主要是分析報表
數據平台是在大數據基礎上出現的融合了結構化和非結構化數據的數據基礎平台，變成一個集數據接入、數據處理、數據存儲、查詢檢索、分析挖掘等、應用接口等為一體的平台，為業務提供服務的方式主要是直接提供數據集
數據中台是全域級、可復用的數據資產中心與數據能力中心，可以提供乾淨、透明、智慧的數據資產與高效、易用的數據能力，使得業務能夠數字化運營，為業務提供服務的方式主要是提供數據服務能力
數據倉庫的優勢是具有元數據，通過表的方式很好的規整了數據。數據需要加工，數倉是通過分層的模式，每往上走一層，數據信息損耗會逐漸增加
數據平台優勢是可以提供高級分析功能和數據資源管理中心，主要有數據互聯互通，支持多數據集實時同步；支持數據資源管理，實現多源異構數據的整合管控；提供完善的大數據分析基礎運行環境，提供統一二次開發接口等
數據中台具有一個全局的元數據管理系統，管理的方式同樣是以表為主，粒度到字段級別。數據中台這個元信息包含了各個子存儲的元信息，以數據中台需要的形態進行組織，變成數據資產管理中心，通過數據地圖來來進行承載，就像互聯管道一樣做數據分發中轉管理，可以很好的找到我們要的數據以及對數據進行關聯和處理、分析，進一步加速企業從數字化轉型為業務價值的過程
3
數據倉庫、數據平台和數據中台的架構
數據倉庫架構圖
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”提供統一數據服務，讓『一切業務數據化，一切數據業務化』
4
數據倉庫、數據平台和數據中台的區別與聯繫
數據倉庫、數據平台和數據中台的區別與聯繫：
1、在概念層面上
數據平台和數據中台的技術能力都是基於數據倉庫發展而來沒，在數據建設理論上一脈相承，他們處理的對象都是海量數據，服務目的、商業價值也同意類似。其實中平台和中台，兩者在能力上都有對外都提供Open API服務。
一方面，中台是業務應用，不具體代表着某種技術，它不是最終用戶能直接使用的，必須結合企業的各個數據業務場景；另一方面，平台是不帶有業務特徵性質的，主要彙集其他人的能力，整合成平台的能力，相對來說是靜態的，而中台是動態變化的本身，需要通過數據驅動的方式來滋養業務，不斷訓練調整業務模型和業務算法提供的能力，提供給其他系統和平台集成的能力。
2、在數據層面上
數據倉庫的數據來源主要來源於RDBMS，其中存儲的數據格式以結構化數據為主，這些數據並非企業全量數據，而是根據企業業務需求做針對性整合、抽取。數據平台和數據中台的數據來源的期望都是全域級的數據，主要有結構化數據、半結構化數據、非結構化數據等
3、在目標層面上
數據倉庫基於單機的，一旦數據量變大，會受單機容量、計算以及性能等方面的限制。主要用來做報表分析，目的性相對來說單一，只是針對相關分析報表用到基礎數據，進行抽取、整合、數據清洗和分析。比如，新增一張報表，就要從底層到上層再做一次，流程上相對來說繁瑣；
數據平台建立是為了解決數據倉庫不能處理非結構化數據和報表開發周期長的問題以及計算和性能等問題。彙集整合打通數據，數據清洗後，當業務提出需求的時候，把業務方需要的若干個小數據集單獨提取出來，以數據集的形式提供給業務方去使用；
數據中台通常會對來自多方面的基礎數據進行數據清洗後，然後按照主題域的概念建立多個以事物為主的主題域；和數據平台在底層建設上都是基於分布式計算平台和存儲平台，理論上可以通過無限擴充平台的計算和存儲能力。目標是都是為了融合整個企業的全域級數據，打通數據之間的隔閡，消除數據標準和口徑不統一的問題。
4、在應用層面上
建立在數據中台上的數據應用場景，不僅僅只是面向於數據報表開發分析與展示處理，更多是將數據變成服務化的方式，然後提供給業務系統，比如面向用戶的畫像系統，搜索/推薦/廣告營銷系統等。
