目前，大多數(shù)企業(yè)采用Apache Flink與Kafka相結(jié)合的方式進(jìn)行實(shí)時(shí)數(shù)據(jù)處理，即kafka從其他端獲取數(shù)據(jù)后，?刻到Flink進(jìn)行計(jì)算，F(xiàn)link計(jì)算完后結(jié)果導(dǎo)入到數(shù)據(jù)庫，整個(gè)過程是數(shù)據(jù)流式處理。然而，由于Kafka不在磁盤中持久保存數(shù)據(jù)，在極端情況下，數(shù)據(jù)可能會(huì)丟失。

綜合研究了市場上主流的數(shù)據(jù)庫和存儲(chǔ)系統(tǒng)以后，筆者發(fā)現(xiàn)了一個(gè)更有效、更準(zhǔn)確的實(shí)時(shí)數(shù)據(jù)倉庫解決方案，即通過Pravega+TiDB這種架構(gòu)組合，來構(gòu)建實(shí)時(shí)數(shù)據(jù)倉庫。

在這篇文章中，我們將重點(diǎn)介紹Pravega分布式流存儲(chǔ)系統(tǒng)、TiDB分布式SQL數(shù)據(jù)庫能給用戶帶來哪些價(jià)值，以及這種組合如何解決Kafka數(shù)據(jù)持久性挑戰(zhàn)。同時(shí)，Pravega+TiDB在自動(dòng)擴(kuò)展、實(shí)時(shí)數(shù)據(jù)倉庫的高并發(fā)性、可用性和安全性等方面有哪些表現(xiàn)。

Pravega——重構(gòu)流式存儲(chǔ)架構(gòu) 

Pravega 是Dell Emc開源分布式流存儲(chǔ)系統(tǒng)，也是全球頂級(jí)開源基金會(huì)CNCF(云原生計(jì)算基金會(huì))的沙盒項(xiàng)目。與Kafka和Apache Pulsar相似，Pravega重點(diǎn)解決了流批統(tǒng)一問題。

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

• 自動(dòng)化擴(kuò)展能力更強(qiáng)。
• Pravega，是一個(gè)完整的存儲(chǔ)接口，提供以 stream 為抽象的接口，支持上層計(jì)算引擎的統(tǒng)一訪問。

▲Pravega架構(gòu)

在分布式系統(tǒng)中，客戶端應(yīng)用程序和消息系統(tǒng)之間的異步傳遞信息，一般基于消息隊(duì)列來實(shí)現(xiàn)。提到消息隊(duì)列，大家首先會(huì)想到Kafka。Kafka是一個(gè)基于Zookeeper的分布式日志系統(tǒng)。它支持多分區(qū)、多副本和多訂閱者。

可以說，Pravega重構(gòu)了流式存儲(chǔ)架構(gòu)，主要為解決Kafka無法解決的問題而建立。作為一個(gè)實(shí)時(shí)流式存儲(chǔ)解決方案，Pravega支持長期數(shù)據(jù)保留。Pravega在Hadoop分布式文件系統(tǒng)（HDFS）或S3上寫入數(shù)據(jù)，從而消除了對(duì)數(shù)據(jù)持久性的擔(dān)憂。此外，Pravega在整個(gè)系統(tǒng)中只存儲(chǔ)一個(gè)數(shù)據(jù)副本，從架構(gòu)設(shè)計(jì)上解決了Kafka無法解決的問題。

為什么Pravega勝過Kafka？

你可能會(huì)問，"既然已經(jīng)有了Kafka，為什么還要重新發(fā)明輪子？" 答案是，使用Kafka存在一個(gè)重要挑戰(zhàn)，那就是數(shù)據(jù)丟失、數(shù)據(jù)保留和再平衡問題。Kafka吃的數(shù)據(jù)比它吐出的多，存在著數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

• 當(dāng)你設(shè)置acks = all時(shí)，只有當(dāng)所有消費(fèi)者確認(rèn)消息被保存時(shí)才會(huì)返回ACK，不會(huì)丟失數(shù)據(jù)。
• 當(dāng)acks = 1時(shí)，如果leader消費(fèi)者保存了消息，就會(huì)返回ACK。如果leader在備份數(shù)據(jù)之前就關(guān)閉了，數(shù)據(jù)就會(huì)丟失。
• 當(dāng)acks=0時(shí)，Kafka不等待消費(fèi)者的確認(rèn)。當(dāng)消費(fèi)者關(guān)閉時(shí)，數(shù)據(jù)就會(huì)丟失。

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

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

消費(fèi)者再平衡也是有害的。因?yàn)樾碌南M(fèi)者被添加到隊(duì)列中，隊(duì)列可能在重新平衡期間停止消費(fèi)消息。因?yàn)樘峤婚g隔時(shí)間長，消費(fèi)者可能會(huì)重復(fù)處理數(shù)據(jù)。無論哪種方式，重新平衡都可能導(dǎo)致消息積壓，從而增加延遲。

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

▲Pravega VS Kafka

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

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

Pravega的優(yōu)勢與價(jià)值

通常，DBA有三個(gè)主要關(guān)注點(diǎn)：數(shù)據(jù)準(zhǔn)確性、系統(tǒng)穩(wěn)定性和系統(tǒng)可用性。

• 數(shù)據(jù)的準(zhǔn)確性是非常重要的。任何數(shù)據(jù)丟失、損壞或重復(fù)都將是一場災(zāi)難。
• 系統(tǒng)的穩(wěn)定性和可用性使DBA從繁瑣的維護(hù)程序中解脫出來，讓他們將時(shí)間投入到改善性系統(tǒng)應(yīng)用中。

Pravega解決了DBA的這些擔(dān)憂。它長期保留保證了數(shù)據(jù)的安全性，并且以精確的一次語義保證了數(shù)據(jù)的準(zhǔn)確性，尤其是自動(dòng)擴(kuò)展性，使系統(tǒng)維護(hù)變得輕而易舉。

實(shí)時(shí)數(shù)據(jù)倉庫是怎樣一個(gè)架構(gòu)？

問題是，實(shí)時(shí)數(shù)據(jù)倉庫應(yīng)該包含哪些關(guān)鍵組成部分？

一個(gè)實(shí)時(shí)數(shù)據(jù)倉庫通常有四個(gè)組成部分：數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)層、實(shí)時(shí)計(jì)算層和實(shí)時(shí)應(yīng)用層。通過將多種技術(shù)整合到一個(gè)無縫的架構(gòu)中，我們可以建立一個(gè)可擴(kuò)展的大數(shù)據(jù)架構(gòu)，可以支持?jǐn)?shù)據(jù)分析和挖掘，在線交易，以及統(tǒng)一的批處理和流處理等等。

▲實(shí)時(shí)數(shù)據(jù)倉庫的四個(gè)組成部分

數(shù)據(jù)存儲(chǔ)層有多種選擇，但不是所有的都適合實(shí)時(shí)數(shù)據(jù)倉庫：

• Hadoop或傳統(tǒng)的OLAP數(shù)據(jù)庫不能提供令人滿意的實(shí)時(shí)處理。
• 像HBase這樣的NoSQL解決方案可以實(shí)時(shí)擴(kuò)展和處理數(shù)據(jù)，但不能提供分析。
• 獨(dú)立的關(guān)系型數(shù)據(jù)庫不能擴(kuò)大規(guī)模以適應(yīng)大量數(shù)據(jù)。

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

為什么選用TiDB？

TiDB是一個(gè)開源的分布式SQL數(shù)據(jù)庫，支持混合交易和分析處理（HTAP）工作負(fù)載。它與MySQL兼容，具有水平擴(kuò)展性、強(qiáng)一致性和高可用性。

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

▲TiDB HTAP架構(gòu)

此外，TiDB 5.0引入了大規(guī)模并行處理（MPP）架構(gòu)。在MPP模式下，TiFlash補(bǔ)充了TiDB的計(jì)算能力。在處理OLAP工作負(fù)載時(shí)，TiDB成為一個(gè)主節(jié)點(diǎn)。用戶向TiDB服務(wù)器發(fā)送請(qǐng)求，所有的TiDB服務(wù)器執(zhí)行表連接，并將結(jié)果提交給優(yōu)化器進(jìn)行決策。優(yōu)化器評(píng)估所有可能的執(zhí)行計(jì)劃（基于行、基于列、索引、單服務(wù)器引擎和MPP引擎），并選擇最佳計(jì)劃。

▲TiDB的MPP模式

例如，一個(gè)訂單處理系統(tǒng)在銷售活動(dòng)中可能會(huì)遇到一個(gè)突然的流量高峰。在這個(gè)高峰期，企業(yè)需要進(jìn)行快速分析，以便及時(shí)對(duì)客戶行為做出反應(yīng)和回應(yīng)。傳統(tǒng)的數(shù)據(jù)倉庫很難在短時(shí)間內(nèi)應(yīng)對(duì)泛濫的數(shù)據(jù)，而且可能需要很長的時(shí)間來進(jìn)行后續(xù)的數(shù)據(jù)分析處理。

通過MPP計(jì)算引擎，TiDB可以預(yù)測即將到來的流量高峰，并動(dòng)態(tài)地?cái)U(kuò)展集群，為活動(dòng)提供更多的資源。并且，它可以輕松地在幾秒鐘內(nèi)響應(yīng)聚合和分析請(qǐng)求。

當(dāng)TiDB遇到Pravega

在Flink的幫助下，當(dāng)TiDB遇到Pravega，構(gòu)成了一個(gè)實(shí)時(shí)、高吞吐量、穩(wěn)定的數(shù)據(jù)倉庫，該數(shù)據(jù)倉庫能夠滿足用戶對(duì)大數(shù)據(jù)的各種要求，并能一站式地處理OLTP和OLAP工作負(fù)載。