今天的熱搜想必大家也看到了，12306崩潰。其實，12306真的很厲害，對于它來說，幾乎每天都是雙11，但是它很少出現宕機的情況，架構的設計是一方面，我今天要講的實時計算也是一方面。

前些時間我講過BI，那麼對于BI來說，穩定性最重要的一點就是實時計算。

1、從現代數倉架構角度看實時數據平台

現代數倉由傳統數倉發展而來，對比傳統數倉，現代數倉既有與其相同之處，也有諸多發展點。首先我們看一下傳統數倉（圖1）和現代數倉（圖2）的模塊架構：

傳統數倉

現代數倉

傳統數倉大家都很熟悉，這裡不做過多介紹，一般來說，傳統數倉隻能支持T＋1天時效延遲的數據處理，數據處理過程以ETL為主，最終産出以報表為主。

現代數倉建立在傳統數倉之上，同時增加了更多樣化數據源的導入存儲，更多樣化數據處理方式和時效（支持T＋0天時效），更多樣化數據使用方式和更多樣化數據終端服務。

現代數倉是個很大的話題，在此我們以概念模塊的方式來展現其新的特性能力。

現代數倉之所以“現代”，是因為它有多平台架構、數據虛拟化、數據的近實時分析、敏捷交付方式等等一系列特性。

我們也在此總結提取了現代數倉的幾個重要能力，分别是：

• 數據實時化（實時同步和流式處理能力）
• 數據虛拟化（虛拟混算和統一服務能力）
• 數據平民化（可視化和自助配置能力）
• 數據協作化（多租戶和分工協作能力）

（1）數據實時化（實時同步和流式處理能力）

數據實時化，是指數據從産生（更新至業務數據庫或日志）到最終消費（數據報表、儀表闆、分析、挖掘、數據應用等），支持毫秒級／秒級／分鐘級延遲（嚴格來說，秒級／分鐘級屬于準實時，這裡統一稱為實時）。

這裡涉及到如何将數據實時的從數據源中抽取出來；如何實時流轉；為了提高時效性，降低端到端延遲，還需要有能力支持在流轉過程中進行計算處理；如何實時落庫；如何實時提供後續消費使用。實時同步是指多源到多目标的端到端同步，流式處理指在流上進行邏輯轉換處理。

但是我們要知道，不是所有數據處理計算都可以在流上進行，而我們的目的，是盡可能的降低端到端數據延遲，這裡就需要和其他數據流轉處理方式配合進行，後面我們會進一步讨論。

（2）數據虛拟化（虛拟混算和統一服務能力）

數據虛拟化，是指對于用戶或用戶程序而言，面對的是統一的交互方式和查詢語言，而無需關注數據實際所在的物理庫和方言及交互方式（異構系統／異構查詢語言）的一種技術。用戶的使用體驗是面對一個單一數據庫進行操作，但其實這是一個虛拟化的數據庫，數據本身并不存放于虛拟數據庫中。

虛拟混算指的是虛拟化技術可以支持異構系統數據透明混算的能力，統一服務指對于用戶提供統一的服務接口和方式。

數據虛拟化

（3）數據平民化（可視化和自助配置能力）

普通用戶（無專業大數據技術背景的數據從業人員），可以通過可視化的用戶界面，自助的通過配置和SQL方式使用數據完成自己的工作和需求，并無需關注底層技術層面問題（通過計算資源雲化，數據虛拟化等技術）。以上是我們對數據平民化的解讀。

其中數據虛拟化和數據聯邦本質上是類似技術方案，并且提到了自助BI這個概念，我前幾天講的FineBI就是國内自助BI的領軍人物，和國外的Tableau齊名。

（4）數據協作化（多租戶和分工協作能力）

技術人員應該多了解業務，還是業務人員應該多了解技術？這一直是企業内争論不休的問題。而我們相信現代BI是一個可以深度協作的過程，技術人員和業務人員可以在同一個平台上，發揮各自所長，分工協作完成日常BI活動。這就對平台的多租戶能力和分工協作能力提出了較高要求，一個好的現代數據平台是可以支持更好的數據協作化能力的。

我們希望可以設計出一個現代實時數據平台，滿足以上提到的實時化、虛拟化、平民化、協作化等能力，成為現代數倉的一個非常重要且必不可少的組成部分。

2、從典型數據處理角度看實時數據處理

典型的數據處理，可分為OLTP、OLAP、Streaming、Adhoc、Machine Learning等。這裡給出OLTP和OLAP的定義和對比：

從某種角度來說，OLTP活動主要發生在業務交易庫端，OLAP活動主要發生在數據分析庫端。那麼，數據是如何從OLTP庫流轉到OLAP庫呢？如果這個數據流轉時效性要求很高，傳統的T＋1批量ETL方式就無法滿足了。

我們将OLTP到OLAP的流轉過程叫Data Pipeline（數據處理管道），它是指數據的生産端到消費端之間的所有流轉和處理環節，包括了數據抽取、數據同步、流上處理、數據存儲、數據查詢等。

這裡可能會發生很複雜的數據處理轉換（如重複語義多源異構數據源到統一Star Schema的轉換，明細表到彙總表的轉換，多實體表聯合成寬表等）。如何支持實時性很高的Pipeline處理能力，就成了一個有挑戰性的話題，我們将這個話題描述為“在線管道處理”（OLPP, Online Pipeline Processing）問題。

因此，本文所讨論的實時數據平台，希望可以從數據處理角度解決OLPP問題，成為OLTP到OLAP實時流轉缺失的課題的解決方案。下面，我們會探讨從架構層面，如何設計這樣一個實時數據平台。

1、定位和目标

實時數據平台（Real-time Data Platform，以下簡稱RTDP），旨在提供數據端到端實時處理能力（毫秒級／秒級／分鐘級延遲），可以對接多數據源進行實時數據抽取，可以為多數據應用場景提供實時數據消費。作為現代數倉的一部分，RTDP可以支持實時化、虛拟化、平民化、協作化等能力，讓實時數據應用開發門檻更低、叠代更快、質量更好、運行更穩、運維更簡、能力更強。

2、整體設計架構

概念模塊架構，是實時數據處理Pipeline的概念層的分層架構和能力梳理，本身是具備通用性和可參考性的，更像是需求模塊。圖6給出了RTDP的整體概念模塊架構，具體每個模塊含義都可自解釋，這裡不再詳述。

下面我們會根據上圖做進一步設計讨論，給出從技術層面的高階設計思路。

由圖7可以看出，我們針對概念模塊架構的四個層面進行了統一化抽象：

• 統一數據采集平台
• 統一流式處理平台
• 統一計算服務平台
• 統一數據可視化平台

同時，也對存儲層保持了開放的原則，意味着用戶可以選擇不同的存儲層以滿足具體項目的需要，而又不破壞整體架構設計，用戶甚至可以在Pipeline中同時選擇多個異構存儲提供支持。下面分别對四個抽象層進行解讀。

（1）統一數據采集平台

統一數據采集平台，既可以支持不同數據源的全量抽取，也可以支持增強抽取。其中對于業務數據庫的增量抽取會選擇讀取數據庫日志，以減少對業務庫的讀取壓力。平台還可以對抽取的數據進行統一處理，然後以統一格式發布到數據總線上。這裡我們選擇一種自定義的标準化統一消息格式UMS（Unified Message Schema）做為統一數據采集平台和統一流式處理平台之間的數據層面協議。

UMS自帶Namespace信息和Schema信息，這是一種自定位自解釋消息協議格式，這樣做的好處是：

• 整個架構無需依賴外部元數據管理平台；
• 消息和物理媒介解耦（這裡物理媒介指如Kafka的Topic, Spark Streaming的Stream等），因此可以通過物理媒介支持多消息流并行，和消息流的自由漂移。

平台也支持多租戶體系，和配置化簡單處理清洗能力。

（2）統一流式處理平台

統一流式處理平台，會消費來自數據總線上的消息，可以支持UMS協議消息，也可以支持普通JSON格式消息。同時，平台還支持以下能力：

• 支持可視化／配置化／SQL化方式降低流式邏輯開發／部署／管理門檻
• 支持配置化方式幂等落入多個異構目标庫以确保數據的最終一緻性
• 支持多租戶體系，做到項目級的計算資源／表資源／用戶資源等隔離

（3）統一計算服務平台

統一計算服務平台，是一種數據虛拟化／數據聯邦的實現。平台對内支持多異構數據源的下推計算和拉取混算，也支持對外的統一服務接口（JDBC／REST）和統一查詢語言（SQL）。由于平台可以統一收口服務，因此可以基于平台打造統一元數據管理／數據質量管理／數據安全審計／數據安全策略等模塊。平台也支持多租戶體系。

（4）統一數據可視化平台

統一數據可視化平台，加上多租戶和完善的用戶體系／權限體系，可以支持跨部門數據從業人員的分工協作能力，讓用戶在可視化環境下，通過緊密合作的方式，更能發揮各自所長來完成數據平台最後十公裡的應用。

以上是基于整體模塊架構之上，進行了統一抽象設計，并開放存儲選項以提高靈活性和需求适配性。這樣的RTDP平台設計，體現了現代數倉的實時化／虛拟化／平民化／協作化等能力，并且覆蓋了端到端的OLPP數據流轉鍊路。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!