目前，大多數企業采用Apache Flink與Kafka相結合的方式進行實時數據處理，即kafka從其他端獲取數據后，?刻到Flink進行計算，Flink計算完后結果導入到數據庫，整個過程是數據流式處理。然而，由于Kafka不在磁盤中持久保存數據，在極端情況下，數據可能會丟失。

綜合研究了市場上主流的數據庫和存儲系統以后，筆者發現了一個更有效、更準確的實時數據倉庫解決方案，即通過Pravega+TiDB這種架構組合，來構建實時數據倉庫。

在這篇文章中，我們將重點介紹Pravega分布式流存儲系統、TiDB分布式SQL數據庫能給用戶帶來哪些價值，以及這種組合如何解決Kafka數據持久性挑戰。同時，Pravega+TiDB在自動擴展、實時數據倉庫的高并發性、可用性和安全性等方面有哪些表現。

Pravega——重構流式存儲架構 

Pravega 是Dell Emc開源分布式流存儲系統，也是全球頂級開源基金會CNCF(云原生計算基金會)的沙盒項目。與Kafka和Apache Pulsar相似，Pravega重點解決了流批統一問題。

除此之外，Pravega功能更豐富：

• 自動化擴展能力更強。
• Pravega，是一個完整的存儲接口，提供以 stream 為抽象的接口，支持上層計算引擎的統一訪問。

▲Pravega架構

在分布式系統中，客戶端應用程序和消息系統之間的異步傳遞信息，一般基于消息隊列來實現。提到消息隊列，大家首先會想到Kafka。Kafka是一個基于Zookeeper的分布式日志系統。它支持多分區、多副本和多訂閱者。

可以說，Pravega重構了流式存儲架構，主要為解決Kafka無法解決的問題而建立。作為一個實時流式存儲解決方案，Pravega支持長期數據保留。Pravega在Hadoop分布式文件系統（HDFS）或S3上寫入數據，從而消除了對數據持久性的擔憂。此外，Pravega在整個系統中只存儲一個數據副本，從架構設計上解決了Kafka無法解決的問題。

為什么Pravega勝過Kafka？

你可能會問，"既然已經有了Kafka，為什么還要重新發明輪子？" 答案是，使用Kafka存在一個重要挑戰，那就是數據丟失、數據保留和再平衡問題。Kafka吃的數據比它吐出的多，存在著數據丟失的風險。

• 當你設置acks = all時，只有當所有消費者確認消息被保存時才會返回ACK，不會丟失數據。
• 當acks = 1時，如果leader消費者保存了消息，就會返回ACK。如果leader在備份數據之前就關閉了，數據就會丟失。
• 當acks=0時，Kafka不等待消費者的確認。當消費者關閉時，數據就會丟失。

Kafka沒有提供一個簡單有效的解決方案來將數據持久化到HDFS或S3，所以數據保留成為一個問題。雖然Confluent提供了相關解決方案，但你必須使用兩套存儲接口來訪問不同層的數據。

• 使用Apache Flume通過Kafka -> Flume -> HDFS訪問數據。
• 使用kafka-hadoop-loader通過Kafka -> kafka-hadoop-loader -> HDFS來訪問數據。
• 使用Kafka Connect HDFS通過Kafka -> Kafka Connect HDFS -> HDFS來訪問數據。

消費者再平衡也是有害的。因為新的消費者被添加到隊列中，隊列可能在重新平衡期間停止消費消息。因為提交間隔時間長，消費者可能會重復處理數據。無論哪種方式，重新平衡都可能導致消息積壓，從而增加延遲。

與Kafka相比，Pravega提供了更多的功能。

▲Pravega VS Kafka

Pravega的特別之處在于，使用Apache BookKeeper來處理低延遲、高并發和數據的實時寫入等問題。然而，BookKeeper只作為一個緩存層，用于批量寫入。所有對Pravega的讀取請求都是直接向HDFS或S3發出，以利用其高吞吐量能力。

換句話說，Pravega不使用BookKeeper作為數據緩沖層，而是提供一個基于HDFS或S3的存儲層。這個存儲層既支持低延遲的尾部讀寫，也支持高吞吐量的追趕式讀取的抽象。當數據在BookKeeper和HDFS或S3之間移動時，使用BookKeeper作為獨立層的系統可能表現不佳。相比之下，Pravega可以確保令人滿意的性能。

Pravega的優勢與價值

通常，DBA有三個主要關注點：數據準確性、系統穩定性和系統可用性。

• 數據的準確性是非常重要的。任何數據丟失、損壞或重復都將是一場災難。
• 系統的穩定性和可用性使DBA從繁瑣的維護程序中解脫出來，讓他們將時間投入到改善性系統應用中。

Pravega解決了DBA的這些擔憂。它長期保留保證了數據的安全性，并且以精確的一次語義保證了數據的準確性，尤其是自動擴展性，使系統維護變得輕而易舉。

實時數據倉庫是怎樣一個架構？

問題是，實時數據倉庫應該包含哪些關鍵組成部分？

一個實時數據倉庫通常有四個組成部分：數據采集層、數據存儲層、實時計算層和實時應用層。通過將多種技術整合到一個無縫的架構中，我們可以建立一個可擴展的大數據架構，可以支持數據分析和挖掘，在線交易，以及統一的批處理和流處理等等。

▲實時數據倉庫的四個組成部分

數據存儲層有多種選擇，但不是所有的都適合實時數據倉庫：

• Hadoop或傳統的OLAP數據庫不能提供令人滿意的實時處理。
• 像HBase這樣的NoSQL解決方案可以實時擴展和處理數據，但不能提供分析。
• 獨立的關系型數據庫不能擴大規模以適應大量數據。

然而，TiDB解決了所有這些需求。

為什么選用TiDB？

TiDB是一個開源的分布式SQL數據庫，支持混合交易和分析處理（HTAP）工作負載。它與MySQL兼容，具有水平擴展性、強一致性和高可用性。

與其他開源數據庫相比，TiDB這種HTAP架構更適合于建立實時數據倉庫。TiDB擁有一個混合存儲層，由TiKV（行存儲引擎）和TiFlash（列存儲引擎）組成。這兩個存儲引擎使用TiDB作為一個共享的SQL層。TiDB回答在線事務處理（OLTP）和在線分析處理（OLAP）查詢，并根據執行計劃的成本從任何一個引擎中獲取數據。

▲TiDB HTAP架構

此外，TiDB 5.0引入了大規模并行處理（MPP）架構。在MPP模式下，TiFlash補充了TiDB的計算能力。在處理OLAP工作負載時，TiDB成為一個主節點。用戶向TiDB服務器發送請求，所有的TiDB服務器執行表連接，并將結果提交給優化器進行決策。優化器評估所有可能的執行計劃（基于行、基于列、索引、單服務器引擎和MPP引擎），并選擇最佳計劃。

▲TiDB的MPP模式

例如，一個訂單處理系統在銷售活動中可能會遇到一個突然的流量高峰。在這個高峰期，企業需要進行快速分析，以便及時對客戶行為做出反應和回應。傳統的數據倉庫很難在短時間內應對泛濫的數據，而且可能需要很長的時間來進行后續的數據分析處理。

通過MPP計算引擎，TiDB可以預測即將到來的流量高峰，并動態地擴展集群，為活動提供更多的資源。并且，它可以輕松地在幾秒鐘內響應聚合和分析請求。

當TiDB遇到Pravega

在Flink的幫助下，當TiDB遇到Pravega，構成了一個實時、高吞吐量、穩定的數據倉庫，該數據倉庫能夠滿足用戶對大數據的各種要求，并能一站式地處理OLTP和OLAP工作負載。