當提到“實時分析”，大家腦海裏首先浮現的是大屏上不斷跳躍閃爍的數字和波動的曲線，讓人有種縱觀全局的掌控感。類似這樣的場景多出現在資源監控或是領導駕駛艙大屏展示中，這些都屬於“實時分析”中比較簡單的應用場景，用於及時瞭解數據變化。
對於企業來說，不僅要及時觀察覈心指標的變化，更重要的是瞭解其變化背後原因。通過對數據展開探索式的分析，獲得對業務較爲全面的洞察理解，從而爲後續的運營決策、營銷決策、風控決策等等提供信息支撐。在電商節的促銷活動中，電商平臺和商家們都密切關注着活動期間實時的交易數據流量。通過實時的分析這些活動流量數據，比如用戶活躍率，轉化率等關鍵指標信息，可幫助平臺和商家們及時調整相關活動計劃策略，從而提升整個活動的營銷收入與效益。
從上述業務場景中可以清晰的看到，業務查看數據報告不再是僅侷限於實時的數據，而且還希望通過結合歷史數據進行更加全面性的探索分析，甚至有些場景下需要兩者數據進行相融合分析。想要實現這些時效性更高的業務需求，背後是非常複雜的一系列技術難題，這也就促使了人們開始了對批流一體分析的探索之路。
批流一體架構面臨的挑戰
傳統架構
數據倉庫的架構隨着業務分析實時化的需求也在不斷演進，但在數據分析平臺的最初起步階段，爲了滿足實時分析需求，傳統方案的做法一般都會將實時分析和歷史批量數據分析拆分成2種不同的獨立架構，形成如下圖片所示的異構環境：
在這樣完全不同的獨立異構環境下，不管是從部署架構層面，還是從數據存儲介質層面都可以說是完全不一致的，這就使得在技術實現上面臨比較大的挑戰。
- 分別維護實時分析與離線分析兩套不同架構的服務，對於系統運行的穩定性，後續應用升級，故障處理等都會比較複雜和繁瑣；
- 分別設計、管理實時分析與離線分析兩套不同的數據模型，離線分析可以通過關聯獲取更加豐富的數據，而實時分析爲了保障數據時效性能只能是簡單的寬表形式進行處理，而且開發流程較繁瑣；
- 因實時數據與離線數據存儲介質的割裂，最終導致兩者數據在存儲時就相互隔離，更無法對兩者進行統一的數據週期管理；
- 在數據服務層中需要根據應用層進行定製化的開發，爲不同的應用提供不同的數據服務，同時也使得這個查詢服務層的維護成本增加不少。
以上這些限制使開發和運維工作都變得的相當困難，不能靈活地應對業務敏捷多變的取數需求。
Lambda 架構
於是基於這種傳統方案的進一步演化，在大數據生態下誕生的Lambda架構開始嶄露頭角。在Lambda架構中，數據處理分爲 Speed Layer、Batch Layer 和 Serving Layer 三個部分。
- Speed Layer 負責實時處理數據，計算邏輯直接對接流數據，儘量縮短數據處理的延遲，但由於流數據天生的數據質量不可控，儘管縮短了數據處理時間，但可能犧牲數據的正確性和完整性；
- Batch Layer 負責批量規模性處理數據，可以保證數據的正確性和處理規模
- Serving Layer 負責融合 Speed 和 Batch 兩個部分的數據能力，對外提供簡單一致的數據訪問視圖。
但在實際應用的過程中，發現 Lambda 架構也存在着一些不足，雖然它使用的是同一架構環境，但是它也同樣存在類似傳統架構那樣較複雜的維護工作。企業需要維護兩個複雜的分佈式系統，即Batch Layer和Speed Layer，並且保證他們邏輯上產生相同的結果輸出到服務層中。
Kappa 架構
因此爲了將Batch Layer和Speed Layer進行統一架構，業界由Kafka團隊提出了新的Kappa架構，基於Streaming是新的DB（數據庫）的設計思想，要將所有的數據消費都基於Kafka，形成統一的數據出口，後續數據處理都基於流式（Kafka）數據源。
這個架構是隨着Kafka上數據加工能力的提升而受到大家關注（特別是Flink框架加持，顯著提升流數據處理能力）。Kappa試圖解決多個計算引擎帶來的開發、運維難題，只保留實時一套代碼和數據。但在實踐中，我們發現數據處理的複雜度不完全是一個單向的流式處理可以全部支持的，比如數據模型的演化，歷史數據的修補更新，緩慢變化維的處理等等，都需要更靈活的數據建模能力。
基於上述對傳統方案、Lambda、Kappa 這些數據架構的討論，以及企業應用的實際需求，我們認爲在數據架構的靈活性、加工邏輯的便捷性、數據模型治理等角度還有更優解。接下來，我們將從批流一體架構這關鍵部分：數據模型、數據生命週期以及查詢服務，進行探討，爲正在進行批流一體選型企業提供一些參考。
基於 Kyligence 的批流一體大數據分析架構探索
基於統一數據模型、生命週期管理、查詢服務等批流一體分析中的關鍵訴求，以及對上述各種方案的探索，最後我們選取基於Lambda架構對Kyligence產品進行升級，打造出批流一體的企業級產品應用。
數據模型
我們知道數據的分析都離不開模型設計作爲基礎，模型是數據加工的目標和方法，是數據計算邏輯，也是數據分析的對象。這裏我們把模型分爲實時模型和歷史模型，實時模型爲追求數據處理的時效性設計，因此要避免計算邏輯複雜，歷史模型爲分析的完整性設計，因此需要更豐富的指標含義和數據治理能力。從業務分析的角度上出發，兩者之間還是存在共同的特徵，兩者之間的關係可以用如下圖示來總結。
從圖上實時模型與歷史模型的共同特點分析，兩者模型是融合統一的。比如兩個模型中的事實表通常都是相同的，可以使用公共的分析維度和指標語義進行數據分析，這就要求批流一體的平臺可支持兩個模型的統一定義，設計和管理，避免模型重複開發和模型不一致。歷史模型是實時模型的超集，歷史模型涵蓋了實時模型的能力，增強了分析的能力（更多維度、更細的粒度、全局去重指標等）。
由於處理實時和歷史數據的計算引擎不同，利用其各自優勢，實時模型繼續使用流式計算引擎對接流式數據源，歷史模型基於大數據平臺的並行能力，進行大規模多數據源的融合計算。同時歷史模型利用數倉理論中成熟的多維分析方法論，提供緩慢變化維管理、歷史數據刷新等能力，增強數據治理。通過對模型定義的統一管理，避免了數據處理邏輯的重複開發，更保證了指標定義的一致性。
數據生命週期
模型統一了，數據還是不同計算引擎加工，不可以允許兩份數據共同提供查詢服務，會引起服務能力的不一致，典型是數據結果重複。因此還需要解決數據生命週期如何管理。實時數據流與歷史數據集，可以說是兩條完全平行不相同的數據流，如下圖所示：
需要將兩份存儲進行統一的數據規整，面對不同的分析場景處理方式各有不同。實時數據爲保證時效性，會犧牲一定的數據“質量”（原始數據採集質量不可控，數據晚到，缺少數據質量實時修正流程等），這對於一些監控場景是夠用的，可以接受“不那麼較真”的數據質量；對於分析型的場景來說這樣是不可容忍的，需要保證數據的正確性，需要對實時數據進行相應的“修訂”纔可以和歷史數據進行統一的整合。
所以當實時流數據“沉澱”爲歷史數據時，需要可以有一定的流程進行實時數據的規整和修正，可以通過實時處理修正（數據重放），也可以是通過離線處理修正（一般稱爲Enrichment，比如關聯更多數據源），這就要求批流一體的平臺需要有不同的場景下的數據治理能力，不能簡單把實時數據沉澱爲歷史數據，而要提供多種數據修正的處理能力。
查詢服務
SQL語言是數據分析師最熟悉的查詢方式，提供標準的SQL語法支持，成爲對接數據應用層面尤爲關鍵的一環。過去我們曾採用HBase、Redis等多種技術實現查詢服務層，甚至要求實時層和歷史層採用不同的API，由應用自行判斷合適的查詢引擎，這給應用開發帶來了更高的門檻。
因此，爲了簡化服務層接口，需要針對實時分析與歷史分析的不同業務場景，自動將查詢請求路由到相應的數據集進行檢索並返回，同時還需要具備將兩者數的查詢融合能力，而不是分別從異構系統中取出數據，再在Data Service層用笨拙的編碼或人工方式進行合併。這也就要求批流一體的平臺既要支持實時分析與歷史分析的獨立查詢，也要支持兩者數據查詢的融合能力。
方案優勢
Kyligence 作爲大數據領域OLAP解決方案的先行者，產品本身支持實時數據與歷史數據的多維數據分析能力，而基於此的統一產品架構設計，爲後續打造批流一體融合分析架構提供了良好的基礎支持。下圖便是Kyligence產品提供基於全Spark計算引擎的批流一體架構設計：
從上面的架構圖中可清晰的看到在中心位置上是元數據模型的統一管理，這是批流一體實現中比較關鍵的部分，然後再結合Lambda架構的優勢，便能較好的解決我們在前文涉及的那些挑戰：
- 模型統一管理方面：改進實時數據模型過去只能支持單一Kafka Topic數據的寬表主題，讓其也能和歷史模型一樣，並共享相同的維度表數據，可實現標準星型和雪花模型設計，從而也實現了對模型的統一設計管理；
- 數據生命週期方面：藉助於Lambda架構優勢，將實時與歷史數據處理分開並行進行處理，這樣的設計不僅很好的保護已有的歷史數據資產不做變更或以較小的代價改動，而且能夠使用歷史數據對實時不滿足的地方進行修正並覆蓋，對於監控類或其他“低數據質量”要求的場景也可以直接將實時數據沉澱爲“歷史”數據。爲不同的應用場景提供更加靈活的數據生命週期管理；
- 統一查詢服務方面：開發智能的查詢路由作爲查詢服務統一查詢入口，支持標準的ANSI SQL語法，通過對元數據模型的識別，可分別對實時數據集與歷史數據集進行探測並解析，返回查詢請求所預期的數據結果，同時以超快的響應速度支持。
在整個“實時”業務支持與實現過程中，對比其它架構中企業需要運維底層複雜的基礎架構，以及在實現流程上繁瑣的代碼開發工作來說，企業現在只需要其上面進行模型設計與管理，以及數據生命週期定義的操作，極大地提升了工作效率，同時減輕了運維工作負擔和成本投入。
小結
基於 Lambda 架構升級改造後的 Kyligence 批流一體分析融合架構，不僅解決批流一體中關鍵部分的支持，同時結合 Kyligence 的其它優勢，整套方案可更便捷地在企業落地。例如圖形界面化的友好操作、支持 Hive 和 Kafka 兩種數據源、無縫集成主流的 BI 平臺等。
目前，我們正將這套方案應用於一家大型金融機構的數據平臺中。對於批流一體的最優解，我們在實踐中不斷探索和迭代。後續，我們將陸續發佈文章，總結項目中的最佳實踐。如果想了解更多批流一體方案的進展，請關注我們的公衆號。
關於作者
李森輝，Kyligence 解決方案架構師，擁有豐富的軟件開發與架構設計經驗，熟悉大數據數倉平臺建設，目前主要負責金融行業類的大數據數倉平臺解決方案設計。