3.1　數字化轉型的4個階段

在2018年IBM和Forrester Consulting聯合發布的報告《數字化轉型的深層實質》中，數字化轉型的任務由3個主要系統承擔：SoE（System of Engagement，行動系統）、SoI（System of Insight，洞察系統）和SoR（System of Record，記錄系統）。SoR將系統需要的數據記錄下來，SoI負責從數據中發現洞見，而SoE負責根據洞見來引導行動。雖然數字化轉型的模型有多種表現方式，但其主要功能和建設內容還是這三個方面。

到目前為止，數字化轉型經歷了4個不同的發展階段，分別是信息化階段、數據倉庫/數據集市階段、數據湖/大數據平臺階段、人工智能/數據中臺階段。這四個階段的主要建設成果對應著數字化轉型各方面的目標，并推動這些目標付諸實現。下面，我們來具體談談數字化轉型的這四個階段。

3.1.1　信息化

所謂信息化，在業務層面，就是把面向交易的數據、所有的業務系統用計算機管理起來；在技術層面，采用的技術是關系型數據庫、各種范式的管理以及聯機事務處理過程（On-Line Transaction Processing，OLTP）。這個階段的主要任務是把生產行為、交易行為數字化，涉及的IT系統包括但不限于以下系統。

·買賣行為：網頁商城、傳統柜臺業務系統

·進銷存：ERP、財會系統

·客戶管理：CRM

·供應鏈管理：SCM

·生產管理：MES

·傳感系統：各種傳感器

信息化是所有數據系統和數字化運營的根本，需要注意的是，信息化不是一步到位的。隨著新業務的出現，新系統的信息化必須與現有系統協調發展，倘若無法完成SoR的需求，就會造成信息丟失、數據割裂。

不過，這個階段主要依賴的OLTP在作為分析工具時存在明顯不足。在OLTP系統中統計一些基本數據很容易，但是進行面向歷史的綜合分析則會非常困難。例如，要統計每天的銷售情況、庫存情況非常容易，而如果涉及“過去30天按地區、用戶性別、年齡、產品類別的銷售分類”或者“哪些產品在過去一年內因為庫存不足造成過銷售流失”之類的數據，統計起來將會非常困難且效率低下。這是因為在OLTP系統中，歷史數據并沒有專門的存儲和查詢優化，查詢將會影響到生產數據庫，而且無法直接查詢某些歷史數據（如某個用戶過去30天賬戶余額的變化），也無法自由探索不同維度的組合，維度稍微多一些，數據庫就撐不住了。因此使用OLTP數據庫無法高效地支持“快速全面的商業洞見”。于是，數據倉庫和數據集市應運而生。

3.1.2　數據倉庫（數據平臺1.0）

數據倉庫（Data Warehouse）及其分支數據集市（Data Market）就是為了解決OLTP的不足，完成數字化轉型中SoI的需求。它們把OLTP中的數據采集過來，做成面向歷史、主題、分析的數據集，進而可以輕松做出上述OLTP難以做出的分析。

圖3-1所示為20世紀90年代的數據倉庫架構，它與今天常見的數據倉庫架構圖其實差別并不大。在這個階段大家第一次意識到數據本身的價值，因此這一階段的成果可以稱為數據平臺1.0。

圖3-1　20世紀90年代的數據倉庫架構

雖然數據倉庫解決了OLTP的問題，但是大家發現，當要做某一個業務統計時，通常需要在數據倉庫中做一個擁有數百個龐大字段的表去查詢，以至于速度太慢，于是就出現了數據集市。

數據集市還是為了解決效率和限制的問題。在技術層面，它與數據倉庫類似，但在業務層面，它是針對單個業務域、主題域、面向分析的數據庫，它去掉了對事務性（Transactional）的要求，保留了關系型和低一級的范式。因此，它的范式要求沒有那么高，有一些信息冗余，但數據查詢不需要很復雜的SQL，比較高效且容易實現。

但在數據倉庫發展了十多年之后，隨著互聯網時代的到來，數據倉庫還是暴露了很多問題。一個較為明顯的問題就是，由于數據倉庫的數據只來源于業務系統功能，只能提供一些匯聚的業務信息，所以能做的功能有限，無法提供個性化的信息以及一些非傳統業務數據源的信息。例如，每個訪問網站的用戶按照順序訪問過哪些網頁、點過哪些鏈接、什么時候離開網站，這些個性化的信息數據倉庫都無法提供。

另外，一些非傳統業務數據源的信息，例如引導用戶訪問的推薦鏈接、用戶的IP地址、每個請求網站響應的時長，一般存儲在服務器日志中，每天所產生的數據量是業務數據量的幾千上萬倍，而且包含很多價值未知的數據，如果都存儲到數據倉庫中，其效率之低和限制是無法想象的。在最開始的時候（2006年以前），有很多公司試圖用傳統技術（如Teradata）來解決這個問題，但都以失敗告終。例如，作為原美國四大搜索引擎公司之一的Ask.com，曾經試圖在廣告商和渠道商的維度上加上地區、內容類別、人群信息等維度，做成深度分析的數據倉庫。但即使使用成本高達數百萬美元的Oracle集群也需要兩天時間才能算完一天的數據，這顯然是不值得做的。

除了性能和效率的問題之外，數據倉庫有一個重大的局限是其提供的數據能力受到先驗經驗的限制。數據倉庫中的數據經過了高度聚合或處理，從流程上來說比較依賴其在建設時的頂層模型設計。數據在建模和入庫的時候需要預先設置Schema和分析主題，而很多數據模型和分析主題的設計比較依賴設計者的經驗。如果需要分析的主題或者提供的數據服務在這些預制的數據模型之外，就需要進行比較大的系統改動。這是很多早期的數據倉庫建設沒有帶來令人滿意的效果的重要原因之一。

3.1.3　大數據平臺（數據平臺2.0）

大數據平臺（Big Data Platform），包括其中的關鍵組件數據湖（Data Lake），打破了數據倉庫中數據存儲和處理的局限，提升了SoR的效率，可以存儲和記錄更多的數據，也加強了SoI的能力，可以進行很多以前無法完成的查詢。此時也出現了很多基于數據驅動的應用，提供SoE的功能。

數據湖在業務層面實現了業務系統的如實快照（貼源層），可以高效存儲日志數據、埋點數據、媒體數據、爬蟲數據；在技術層面，采用HDFS、Hive、MongoDB、對象存儲等技術，解決了個性化信息和非傳統業務源信息的分析難題。這個階段的數據平臺開始能夠處理業務數據之外的各種數據，因此可以稱為數據平臺2.0。

在這個階段，數據倉庫和數據集市基于大數據技術得到了進化。在業務層面，它們聚合了更多的數據源，支持更豐富維度的聚合分析；在技術層面，采用了MPP（Vertica、GP）、SQL-on-Hadoop（Presto、Impala、Hive）、高維度分析（Kylin）等技術手段；而在需求方面，這個階段數據倉庫和數據集市的需求與傳統的數據倉庫和數據集市是類似的，只是運用了更多大數據技術，更多的是做非傳統關系數據庫。在這個階段，不再需要Transactional、關系型、范式。

在這個階段還出現了新型數據庫NoSQL。正如其名，NoSQL不是基于SQL的數據庫，它包含鍵-值存儲（Key-Value Store）、文檔數據庫、對象數據庫、圖數據庫等。例如HBase、Cassandra、ClickHouse等鍵-值存儲可以提供海量個性化數據（用戶/產品畫像、標簽體系）的存儲和訪問（業務的、分析的）。

后來又出現了實時數據、流式數據，從而可以對實時、流式處理的需求進行更快速的響應。比如，根據某個用戶在第一分鐘內的行為就能夠馬上對其進行個性化推薦，這就是實時、流處理的威力。Twitter于2013年收購流處理框架Storm，就是因為Twitter的廣告有很強烈的實時需求，當用戶點擊一條推文時，馬上就可以為這個用戶推送合適的廣告。只有這種實時流數據才會用到Storm、MQ、Kafka這樣的技術。

之后出現的半結構化數據、對象數據處理技術（如JSON API、文檔數據庫、對象數據庫）可以快速響應業務變更，從而克服了關系型數據難以變化、媒體存儲效率低下的問題。例如，對于傳統的關系型數據庫，增刪字段、改變數據庫的邏輯是一件非常麻煩的工作，而對于半結構化數據、對象數據，這樣的業務變更就會非常容易。

總的來說，雖然在大數據平臺階段基于大數據技術實現的數據倉庫和數據集市與傳統的數據倉庫和數據集市在名稱上相同，在業務層面的需求也一致，但前者能夠滿足更多的數據源和更豐富維度的聚合分析，并能夠實現更高維度的數據分析。

可見，基于大數據技術實現的數據倉庫和數據集市與傳統的數據倉庫和數據集市還是存在較大差異。因此在本書中，我們將基于大數據技術實現的數據倉庫和數據集市稱為大數據數倉、大數據數集，以示區分。

3.1.4　數據中臺（數據平臺3.0）

通過上面三個階段的描述我們看到，信息化、數據倉庫、大數據平臺已經逐步提供了SoR、SoI、SoE的功能，如此一來似乎所有的問題都已經解決。那么，現有的數字化轉型體系究竟還有哪些局限，非得要數據中臺來做不可？

正如我們在本書開篇拋出的問題，基于計算與存儲結構提供標準統一、可鏈接萃取的數據中臺，包含數據采集研發、鏈接與萃取、數據資產管理、統一數據服務，這不都是大數據平臺應該提供的功能、應該做的嗎？為什么還有那么多公司要建設數據中臺呢？

讓我們再回頭來看看阿里巴巴對于數據中臺需要解決的問題的描述：“各個部門數據重復開發，浪費存儲與計算資源”“數據標準不統一，數據使用成本高”“業務數據孤島問題嚴重，數據利用效率低”。原來，在很多企業中，這些本應在大數據平臺階段解決的問題并沒有得到考慮和解決，因此需要一個新平臺來為大數據平臺“打補丁”，而這個新平臺就是所謂的“數據中臺”。因為硅谷的很多企業在大數據平臺階段就已經考慮到并解決了上述問題，所以硅谷并沒有出現“數據中臺”的概念。

這個階段的數據平臺強調對SoR、SoI、SoE功能實現全局管理和規范化，提升數字化轉型的效率和能力，可以稱為數據平臺3.0。