01.前言

我前面做了很多行業(yè)研究和案例分享，但是都是企業(yè)級的講解，感覺都不夠簡單，不夠落地，這里我用一個最清晰的訂單服務的演進過程，來深度剖析雙中臺的關系。

成都創(chuàng)新互聯(lián)服務項目包括桂陽網(wǎng)站建設、桂陽網(wǎng)站制作、桂陽網(wǎng)頁制作以及桂陽網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，桂陽網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到桂陽省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

02. 一個訂單服務的演進過程

訂單服務是最常見的場景，下面我們用一個電商領域的常見訂單服務的演進過程來詳細剖析雙中臺為什么會出現(xiàn)，它們的價值以及關系。

第一階段：單應用訂單服務

下圖是一個典型的電商訂單服務的流程，用戶號在某電商自營APP下一個產(chǎn)品訂單，這個應用吧訂單數(shù)據(jù)保存到數(shù)據(jù)庫里。

第二階段：多應用訂單服務

該電商企業(yè)拓展了多個渠道，構建了另外的電商APP，提供給用戶使用。于是，用戶下訂單就有了兩個方法，分別在不同的應用里，比如自營APP和微信小程序，這是最典型的兩個渠道。而真實的情況是一個電商企業(yè)會有非常多的渠道，有自營的，還有代運營的，還有線下的POS系統(tǒng)，還有合作伙伴通過API接入的，多個應用會同時創(chuàng)建訂單。

這樣帶來的問題很明顯：

• 用戶體驗不佳，一個用戶不能看到在不同渠道的訂單。
• 數(shù)據(jù)一致性差，訂單數(shù)據(jù)分散在不同的應用系統(tǒng)中，數(shù)據(jù)不一致，同步復雜。
• 維護困難，當一個訂單邏輯發(fā)生了變化，所有的應用邏輯都要重寫，帶來的很大的維護工作量，響應慢。

在這種情況下，為了能夠掌握全局的銷量情況，往往企業(yè)會構建數(shù)據(jù)倉庫系統(tǒng)，將不同系統(tǒng)的數(shù)據(jù)都通過ETL的方式抽取到數(shù)據(jù)倉庫中進行分析，這也就是OLAP的過程，但是由于數(shù)據(jù)量比較大，處理過程復雜，往往OLAP都是T+1以上的響應速度，也就意味著，比如企業(yè)要想看所有渠道的銷量分析報表，只能看到一天以前的，而不能看實時的數(shù)據(jù)，如下圖所示。

上圖的橘黃色箭頭表示在線交易處理流程，是生成數(shù)據(jù)的過程，而綠色箭頭表示在線分析處理流程，是抽取處理分析的過程。

這是典型的數(shù)據(jù)倉庫和商業(yè)智能的場景，而這樣的數(shù)據(jù)利用的問題也是很明顯的：

• 數(shù)據(jù)分析不實時，不能夠實時出報表。
• 數(shù)據(jù)倉庫往往都是單體架構，受限于數(shù)據(jù)的處理計算能力，擴展能力不強，往往只能分析一個階段的數(shù)據(jù)。
• 響應慢，ETL的過程依賴于預設的分析主題設計，當要分析的數(shù)據(jù)結構發(fā)生變化時需要重新設計抽取邏輯，導致響應慢。

以上是現(xiàn)在很多企業(yè)典型的應用和數(shù)據(jù)架構，在這個基礎之上，有了數(shù)據(jù)中臺和業(yè)務中臺的產(chǎn)生。

數(shù)據(jù)中臺業(yè)務用例：精準營銷

下圖是典型的數(shù)據(jù)中臺的業(yè)務用例：精準營銷。

利用分布式的數(shù)據(jù)架構替換傳統(tǒng)的數(shù)據(jù)倉庫，將ETL的過程更換成ELT的過程，結合批流一體的架構，保證數(shù)據(jù)的全面覆蓋，源數(shù)據(jù)抽取，實時數(shù)據(jù)和歷史數(shù)據(jù)并存。在這個基礎上，數(shù)據(jù)中臺借助機器學習等算法能力，構建精準營銷模型，能夠供前臺業(yè)務應用直接調用，而不需要做成報表以可視化的形式提供給業(yè)務人員，業(yè)務人員根據(jù)自己的經(jīng)驗在去做手工的用戶運營。

這是一個典型的數(shù)據(jù)智能化的過程，通過數(shù)據(jù)中臺，整合了企業(yè)所有應用系統(tǒng)的全域數(shù)據(jù)，通過分布式存儲和計算能力，結合人工智能技術和算法，為業(yè)務系統(tǒng)提供直接可調用的實時數(shù)據(jù)和智能服務。

業(yè)務中臺業(yè)務用例：訂單中心

智能化是所有的企業(yè)希望達到的目標，但是智能化對于數(shù)據(jù)的質量要求很高，而多個分別創(chuàng)建訂單服務，導致的問題很明顯，而且隨著前臺應用系統(tǒng)的不斷增多，業(yè)務數(shù)據(jù)化的過程越來越復雜，導致數(shù)據(jù)與真實的業(yè)務出現(xiàn)了很多的不一致和偏差。同時，隨著業(yè)務變化的速度越來越快，同時維護多個訂單服務的工作量很大，響應速度越來越慢，這種情況，就要求對于所有的訂單服務進行抽象，復用和包裝，這就是業(yè)務中臺出現(xiàn)的原因。

如下圖是最簡單的業(yè)務中臺的服務，也就是訂單中心的服務，所有的前臺應用當需要創(chuàng)建訂單的時候，統(tǒng)一調用業(yè)務中臺的訂單服務，由這個服務統(tǒng)一生成產(chǎn)品訂單，從而保證了訂單邏輯的一致性和維護的高響應性。

雙中臺共存業(yè)務用例：動態(tài)價格

數(shù)據(jù)中臺不僅為前臺應用直接提供調用服務，并且也能夠為業(yè)務中臺提供服務。下圖是典型的雙中臺共存的業(yè)務用例：動態(tài)價格。

這個場景在很多需要實時計算動態(tài)價格的業(yè)務中存在，比如機票預訂和滴滴打車的下單服務中。

業(yè)務中臺統(tǒng)一為不同的應用提供訂單生成服務，而在生成訂單的過程中，需要根據(jù)不同用戶的情況，動態(tài)計算一個價格，這種情況下，業(yè)務中臺就需要調用數(shù)據(jù)中臺中的動態(tài)價格計算模型。

所以，數(shù)據(jù)中臺是同時為業(yè)務中臺和業(yè)務前臺提供數(shù)據(jù)和智能服務的。

業(yè)務中臺和數(shù)據(jù)中臺的關系

通過上面一個典型的訂單服務的幾個泛化場景的演進過程，我們粗淺的分析了業(yè)務中臺和數(shù)據(jù)中臺應用的典型業(yè)務用例，我們可以簡單的總結為：

業(yè)務中臺解決的是業(yè)務數(shù)據(jù)化的問題，數(shù)據(jù)中臺解決的是數(shù)據(jù)智能化的問題。

03. 業(yè)務中臺解決業(yè)務數(shù)據(jù)化的問題

目前大部分的企業(yè)系統(tǒng)都是業(yè)務數(shù)據(jù)化的系統(tǒng)，所有的OLTP應用也都是為了實現(xiàn)業(yè)務數(shù)據(jù)化的目的，而業(yè)務中臺解決的是業(yè)務數(shù)據(jù)化過程中的如下問題：

• 一致性問題，將處理邏輯相似的業(yè)務流程封裝成業(yè)務中臺的服務，從而保證業(yè)務的一致性，也保證了業(yè)務數(shù)據(jù)化后的數(shù)據(jù)一致性問題
• 響應力問題，通過對業(yè)務中臺服務的復用，提高業(yè)務前臺系統(tǒng)開發(fā)的效率從而提高響應力
• 維護性問題，將多個服務抽象成一個，提升系統(tǒng)的可維護性
• 性能問題，通過微服務，容器化技術，能夠針對性的解決高并發(fā)的服務需求問題，實現(xiàn)硬件資源的共享，解決性能問題

總的來講，業(yè)務中臺是為了業(yè)務更高效，更準確，更彈性的數(shù)據(jù)化。

更簡單的說，業(yè)務中臺解決的是生產(chǎn)數(shù)據(jù)過程中的問題。

4. 數(shù)據(jù)中臺解決數(shù)據(jù)智能化的問題

數(shù)據(jù)中臺是為了讓所有的業(yè)務流程都能夠盡可能的利用數(shù)據(jù)產(chǎn)生的洞察，促進流程的優(yōu)化，讓業(yè)務更加智慧。所以，數(shù)據(jù)中臺解決的是數(shù)據(jù)智能化的問題：

• 通過分布式數(shù)據(jù)架構，解決傳統(tǒng)單體架構數(shù)據(jù)系統(tǒng)比如數(shù)據(jù)倉庫、中心式數(shù)據(jù)湖的問題
• 通過數(shù)據(jù)模型/報表服務化方式，實時被業(yè)務應用所調用，提升業(yè)務的實時性
• 通過融合企業(yè)全域數(shù)據(jù)，提升數(shù)據(jù)的一致性和準確性

05.總結

業(yè)務中臺是為了讓企業(yè)更好的響應業(yè)務同時生產(chǎn)數(shù)據(jù)，業(yè)務更加彈性。

數(shù)據(jù)中臺是構建彈性的數(shù)據(jù)基礎設施，為了讓企業(yè)更好地利用數(shù)據(jù)，讓業(yè)務更智慧。

數(shù)據(jù)中臺的終局是怎樣的呢?

網(wǎng)站欄目：一個具體場景剖析業(yè)務中臺和數(shù)據(jù)中臺的關系
分享URL：http://uogjgqi.cn/article/cdpichp.html