大數據實時分析平臺(以下簡稱PB-S)旨在提供端到端的實時數據處理能力(毫秒/秒/分鐘延遲)，能夠從多個數據源提取實時數據，為多個數據應用場景提供實時數據消費。作為現代數據倉庫的壹部分，PB-S可以支持實時、虛擬化、普及、協作等能力，使得實時數據應用開發門檻更低、叠代更快、質量更好、運行更穩定、運維更簡單、能力更強。
總體設計思想
我們統壹並抽象了用戶需求的四個層次:
統壹數據采集平臺
統壹流式處理平臺
統壹計算服務平臺
統壹數據可視化平臺
同時，它還保持了對存儲層的開放性原則，這意味著用戶可以在不破壞整體架構設計的情況下選擇不同的存儲層來滿足特定項目的需求，用戶甚至可以選擇管道中的多個異構存儲來提供支持。下面分別對四個抽象層進行解釋。
1)統壹數據采集平臺
統壹的數據采集平臺可以支持從不同數據源進行完全提取和增強提取。其中，業務數據庫的增量提取會選擇讀取數據庫日誌來減輕業務數據庫的讀取壓力。平臺還可以對提取的數據進行統壹的處理，然後以統壹的格式發布到數據總線上。這裏，我們選擇定制的標準化統壹消息格式UMS(Unified Message Schema)作為統壹數據采集平臺和統壹流處理平臺之間的數據層協議。
UMS附帶了名稱空間信息和模式信息，這是壹種自我定位和自我解釋的消息協議格式。這樣做的好處是:
整個架構不需要依賴外部元數據管理平臺；
消息與物理媒介解耦(這裏的物理媒介是指卡夫卡的話題，星火流的流等。)，所以可以通過物理介質支持多個消息流的並行和消息流的自由漂移。
該平臺還支持多租戶系統和配置簡單清理的能力。
2)統壹的流處理平臺
統壹流處理平臺將消耗來自數據總線的消息，並且可以支持UMS協議消息或普通JSON格式消息。同時，該平臺還支持以下功能:
支持可視化/配置//SQL，降低流邏輯的開發/部署/管理門檻。
支持配置模式冪等落入多個異構目標庫，保證數據的最終壹致性。
支持多租戶系統，實現計算資源/表資源/用戶資源的項目級隔離。
3)統壹計算服務平臺
統壹計算服務平臺是數據虛擬化/數據聯合的壹種實現。平臺內部支持多異構數據源的下推計算和拉入混合計算，外部支持統壹服務接口(JDBC/REST)和統壹查詢語言(SQL)。由於該平臺可以提供統壹的服務，因此可以基於該平臺構建統壹元數據管理、數據質量管理、數據安全審計和數據安全策略等模塊。該平臺還支持多租戶系統。
4)統壹的數據可視化平臺
統壹的數據可視化平臺，結合多租戶和完善的用戶體系/權限體系，可以支持跨部門數據從業者的分工和協作能力，讓用戶在可視化環境中通過緊密合作，更好地發揮各自的優勢完成數據平臺最後十公裏的應用。
以上是基於整體模塊架構，采用統壹的抽象設計和開放的存儲選項，提高靈活性和需求適應性。該RTDP平臺設計體現了現代數據倉庫的實時/虛擬化/普及/協作能力，覆蓋了端到端的OLPP數據流鏈路。
具體問題和解決方案
接下來基於PB-S的整體架構設計，我們將從不同的維度來討論這個設計需要面對的問題和解決方案。
功能考慮主要討論這個問題:實時管道能處理所有的ETL復雜邏輯嗎？
正如我們所知，對於像Storm/Flink這樣的流計算引擎，它是基於每個項目進行處理的；對於Spark Streaming流計算引擎，按照每個mini-batch處理；對於離線批量運行的任務，按照日常數據處理。因此，處理範圍是數據的壹個維度(範圍維度)。
此外，流式處理面向增量數據。如果數據源來自關系數據庫，那麽增量數據往往指的是增量變更數據(修訂)。相對批處理是面向快照數據的。所以，展現形式是數據的另壹個維度(變化維度)。
單個數據的更改維度可以投影並聚合到單個快照中，因此更改維度可以聚合到範圍維度中。所以流處理和批處理的本質區別在於數據範圍的維度不同。流處理單元是“有限範圍”，批處理單元是“全表範圍”。“全表範圍”數據可以支持各種SQL運算符，而“有限範圍”數據只能支持部分SQL運算符。
復雜的ETL不是單個操作符，而是經常由多個操作符組成。從上面可以看出，簡單的流處理並不能很好地支持所有的ETL復雜邏輯。那麽如何在實時管道中支持更復雜的ETL操作符並保持時效性呢？這就需要“有限範圍”和“全表範圍”處理的相互轉換能力。
想象壹下:流處理平臺可以在流上支持合適的處理，然後實時放下不同的異構庫。計算服務平臺可以定時(時間可以設定為每隔幾分鐘或更短)批量混合計算多源異構庫，並將每批計算結果發送到數據總線上繼續流轉。這樣，流處理平臺和計算服務平臺形成計算閉環，各自擅長運營商處理，數據在不同頻率觸發流的過程中被各個運營商轉化。理論上，這種架構模式可以支持所有的ETL。
2)質量考慮
上面的介紹也引出了兩種主流的實時數據處理架構:Lambda架構和Kappa架構。關於這兩種架構的介紹，網上有很多資料，這裏就不贅述了。Lambda架構和Kappa架構各有優缺點，但都支持數據的最終壹致性，在壹定程度上保證了數據質量。Lambda架構和Kappa架構如何取長補短，形成壹定的融合架構，會在其他文章中詳細討論。
當然，數據質量也是壹個非常大的話題。僅僅支持重運行和回註並不能完全解決所有的數據質量問題，只是從技術架構層面給出了補充數據的工程方案。關於大數據的質量，我們還會討論壹個新的話題。
3)穩定性考慮
本主題涉及但不限於以下幾點。這裏有壹個簡單的處理方法:
高可用性HA
整個實時管道鏈路應選擇高可用性組件，以保證理論上的整體高可用性；支持數據關鍵環節的數據備份和回放機制；支持業務關鍵環節的雙運行融合機制。
SLA保證
在保證集群和實時流水線高可用的前提下，支持動態擴容和數據處理流程自動漂移。
彈性抗脆性
基於規則和算法的資源彈性擴展
事件觸發動作引擎的故障處理
監測和預警
集群設施、物理管道和數據邏輯層面的多方面監測和預警能力。
自動操作和維護
能夠捕獲和歸檔丟失的數據，處理異常情況，並具有定期自動重試機制來修復問題數據。
上遊元數據更改阻力
上遊業務庫需要兼容性元數據更改。
實時流水線處理顯式字段
4)成本考慮
本主題涉及但不限於以下幾點。這裏有壹個簡單的處理方法:
人力成本
通過支持數據應用的普及，降低人才的人力成本。
資源成本
支持動態資源利用，減少靜態資源占用造成的資源浪費
運行和維護成本
通過支持自動運維/高可用/彈性抗漏洞機制，降低運維成本。
試錯成本
通過支持敏捷開發/快速叠代來減少試錯成本。
5)敏捷考慮
敏捷大數據是壹套理論體系和方法論，在之前的文章中已經有所描述。從數據使用的角度，敏捷考慮意味著:配置、SQL、普及。
6)管理考慮
數據管理也是壹個非常大的話題，這裏我們將重點介紹兩個方面:元數據管理和數據安全管理。在現代多倉庫、多數據存儲選擇的環境下，統壹管理元數據和數據安全是壹個非常具有挑戰性的課題。我們會分別考慮這兩個方面並在實時管道的各個鏈接平臺上給予內置支持，同時也可以支持外部統壹的元數據管理平臺和統壹的數據安全策略。
以上是大數據實時分析平臺PB-S的設計方案。