構建實時數倉 - 當 TiDB 偶遇 Pravega

作者介紹: 王天宜,TiDB 社區部門架構師。曾就職於 Fidelity Investment,Softbank Investment,擁有豐富的數據庫高可用方案設計經驗,對 TiDB、Oracle、PostgreSQL、MySQL 等數據庫的高可用架構與數據庫生態有深入研究。

數據倉庫是公司數據發展到一定規模後必然需要提供的一種基礎服務,也是“數據智能”建設的基礎環節。早期數倉多爲離線模式,主要處理的是 T+1 的數據,隨着互聯網時代的到來,實時數據處理的場景日益增多,離線數倉已無法滿足業務發展的實時性需求。爲更好的解決業務場景的實時化需求,實時數倉建設已成必然趨勢,這也是 HTAP 數據庫的重要能力之一。

實時數倉相較於離線數倉,主要處理的是 T+0 的數據,實時性更高,完美契合業務高效運轉的需求。在架構上,實時數倉通常使用 Flink 來消費 Kafka 中的數據,將數據流實時的寫入數據庫中。這種方案雖然解決了數據處理的時效問題,但很多時候,由於 Kafka 沒有落盤機制,可能在極端的情況造成消息隊列中數據丟失。

針對上述問題,筆者調研了頁面上的數據庫與存儲引擎,發現了能徹底解決 Kafka 落盤問題的,更高效準確的實時數倉新方案。

首先,**在數據庫的選擇上,考慮可擴展性更高的分佈式數據庫 TiDB,從數據庫層面解決海量數據存儲的問題,其次是分佈式流存儲引擎 Pravega,解決使用傳統消息隊列數據丟失問題和自動伸縮難題,提高了實時數倉系統的並行性,可用性與安全性。**以下將詳細分析。

TiDB 偶遇 Pravega

Pravega 是一款 DellEMC 開源的流存儲項目,並已經進入 CNCF 的 sandbox 階段。從功能上來看,除與 Apache Kafka、Apache Pulsar 相似,Pravega 提供了 stream、schema registry。除此之外,Pravega 最重要特點是: (1) 無需應用程序感知的自動伸縮能力 (auto-scaling) 和 (2) 是一個完整的存儲接口,提供以 stream 爲抽象的接口支持上層計算引擎統一的訪問。

分佈式消息傳遞一般都基於可靠的消息隊列,在客戶端應用和消息系統之間異步傳遞消息。提到消息隊列,無論如何都無法繞過 Kafka。Kafka 是一個分佈式、多分區、多副本、多訂閱者,基於 Zookeeper 協調的分佈式日誌系統。Pravege 是在使用 Kafka 實踐中總結出來的新的架構。

Pravega 重構了流式存儲的架構。作爲流式實時存儲的解決方案,應用程序可以直接將數據持久化到 Pravega 中。也正是因爲 Pravega 將數據落盤到 HDFS/S3 上,可以不再受限於數據的 retention,並且整個大數據流水線中數據只存儲了一份。

Pravega 爲何要再造輪子

作爲一個粗淺的 Kafka 使用者,有三個問題使我感到困擾:

  • 丟數據的問題,喫進的數據多,吐出的數據少,offset 提交了,會存在丟數據的風險。

  • acks = all,只有當所有消費者確認保存了消息時,纔會返回 ack,不會丟數據。

  • acks = 1,當 leader 消費者保存消息就返回 ack,接收的 leader 如果確認後沒有來得及備份就掛了,會丟數據。

  • acks = 0,不等待任何確認,接收方掛掉時會丟數據。

  • Kafka 數據受限於 retention,沒有簡單高效的 hdfs/S3 落盤方案。商業版本雖然提供了這個功能,但是數據一旦搬運後,你必須使用2套存儲接口混合訪問處於不同層級的數據。

  • 引入 flume,可以走 kafka -> flume -> hdfs 的鏈路。

  • 引入 kafka hadoop loader,可以走 kafka -> kafka hadoop loader -> hdfs 的鏈路。

  • 引入 kafka-connect-hdfs,可以走 kafka -> kafka-connect-hdfs -> hdfs 的鏈路。

  • Consumer rebalance 過程危害甚多。

  • 在 consumer reblance 的過程中可能會因爲增加 cunsumer 導致暫停隊列的消費。

  • 在 consumer reblance 的過程中可能因爲提交間隔長,引發重複消費的問題。

  • 暫停消費和重複消費都有可能導致消息積壓,reblance 結束後存在消費突刺的問題。

那麼在 Pravega 造輪子的過程中,解決了那些問題呢?以下爲 Pravega 與 Kafka 的對比

Pravega 的特別之處在於,雖然它與不少開源產品一樣,也使用 Bookkeeper 去處理並行實時數據低延遲寫問題,但是 Bookkeeper 在 Pravega 中只作爲數據聚合寫(batch write)到 HDFS/S3 的第一階段(唯一例外是在節點意外故障後做恢復的時候)。所有對 Pravega 讀都直接作用到 HDFS/S3 上以利用它們的高吞吐能力。

所以 Pravega 並不把 BookKeeper 當做數據緩存層,而只是提供了一個基於 HDFS/S3 新的存儲層用來同時滿足“低延時尾讀尾寫”和“高吞吐追趕讀”的抽象。因此,不像大部分使用“分層”設計的項目那樣,當數據在 BookKeeper 和 HDFS/S3 之間移動時候性能將無法保證。

迴歸到痛點問題

大部分的 DBA 或者運維人員最關心的有三件事:數據的正確性,系統的穩定性,以及系統的易用性。數據的正確性是 DBA 的立身之本,數據丟失,數據損壞,數據重複對於公司來說都是巨大的打擊;穩定性與易用性解放了 DBA 的雙手,讓 DBA 從繁複的運維工作中解脫出來,有更多的時間關注與架構選型和系統適配的問題。

從這三點來看,Pravega 確實解決了絕大部分運維人員的痛點問題。Long-term retention 保證了數據的安全,Exactly-Once Semantics 保證了數據的準確性,Auto-scaling 使得維護本身變得輕鬆。這些特點令人更願意對 Pravega 進行深一步的調研與適配。

TiDB 與 Pravega 的實時數倉新方案

之前,TiDB 5.0 發佈後,其 MPP 架構主要是將業務負載切分成若干的任務下推到多個服務器和節點上。在每個結點的計算任務完成後,合併成最終結果交付給用戶。在 TiDB 5.0 中,TiFlash 會全面補充 TiDB 的計算能力,TiDB 在 OLAP 場景下就會退化成一個 master 節點。基於 MPP 架構,用戶會向 TiDB Server 發送查詢 SQL,這個查詢 SQL 會由共享的 TiDB 服務器來承擔。這些 TiDB 服務器會進行 Join,然後交給優化器去決策。優化器會把使用行存、列存、某些索引、單機引擎、MPP 引擎,或者是使用不同組合產生不同的執行計劃,都納入到同一個代價模型中進行評估,最後選出一個最優的執行方案。

在一些訂單交易系統,可能因爲促銷活動在短時間內迅速達到業務高峯。往往這種瞬時流量高峯需要我們能夠快速的進行分析類的查詢,從而在限定時間內給出反饋以影響決策。傳統的實時數倉架構很難承載短時間內的流量高峯,隨之的分析操作可能會需要大量的時間來完成。如果使用傳統的計算引擎,可能無法做到秒級的聚合分析操作。有了 MPP 計算引擎,就可以**將能預測的流量高峯轉換成擴容的物理成本,做到秒級的響應。**在 MPP 計算引擎的加持下,TiDB 能夠更好的處理分析類型的海量數據查詢。

實時數倉方案的架構

實時數倉經歷了三個重要的里程碑

  • Storm 的出現打破了 MapReduce 的單一計算方式,讓業務能夠處理 T+0 的數據;

  • Lambda 到 Kappa 架構的進化,將離線數倉轉化爲實時數倉;

  • Flink 的出現給出了批流一體更好的實踐方式。

實時數倉的架構一直是在不停變化的。很多時候,當我們剛剛選定一套架構模型的時候,數據倉庫的技術棧仍在高速迭代。我們無法預測到 Lambda,Kappa之後會出現什麼樣的技術架構,但可以通過現在的架構窺探一二。一般來說,我們可以將實時數倉劃分爲四個部分:實時數據採集端,數據倉庫存儲層,實時計算層,實時應用層。多技術棧的融合可以幫我們構建一套無邊界的大數據基礎平臺,幫助我們同時支撐分析挖掘,業務上線和批流處理。

需求探索:構建 Pravega + Flink + TiDB 的實時數倉

隨着數字化轉型的推進,越來越多企業正面臨前所未有的數據規模,隨着商業競爭的日趨加劇,無論是外部的用戶還是公司內部的決策已經無法依賴時效性不佳的離線數據分析,需要更實時的數據分析,甚至是對正在發生的交易數據進行分析,以支撐更加敏捷的商業決策。

舉例來說:

  • 風控場景的最佳效果是防患於未然,所以事前事中和事後三個方案中,以事前預警和和事中控制效果最好。這要求風控系統一定要有實時性。

  • 電商大促期間希望能夠平穩及時的監控到銷售的情況而非歷史數據。

傳統上,以 Hadoop 還是分析型數據庫爲基礎的數據分析 / 數據倉庫方案都存在着無法良好支持實時分析的障礙;類似 HBase 等 NoSQL 方案雖然可以支持很好的擴展性和實時性,但無法提供所需的分析能力;而傳統單機數據庫則無法提供數據分析所需的擴展性。

在集成了 TiFlash 之後,TiDB 實現了 OLTP 與 OLAP 的結合,既可以應用於事務性數據庫場景,可以應用於分析性數據庫場景,也可以在 OLTP 業務中劃分出獨立的區域完成分析類查詢。藉助與 Flink,TiDB 可以很好的與 Pravega 適配,提供實時的、高吞吐的、穩定的數倉系統。滿足用戶在大數據場景中對各類數據的分析需求。

🌟 初次嘗試:使用 Pravega + Flink 將數據流入 TiDB

爲了方便讀者更好的理解,我們在 github tidb-pravega-quick-start 中提供了一個基於 docker-compose 的 Pravega -> Flink -> TiDB 的通路。在 docker-compose 啓動後,可以通過 Flink SQL Client 來編寫並提交 Flink 任務,並通過 HOST_IP:8081 來觀察執行情況。

當前,TiDB + Pravega 構建實時數倉方案面向社區招募體驗官!數倉新方案搶先體驗,還可額外獲取 TiDB 社區及 Pravega 社區精美周邊。您在探索實踐的過程中有任何問題,社區提供一定技術支持~ 感興趣的小夥伴,趕快掃碼報名吧!

👇 數倉新方案,掃碼搶先試用 👇

補充閱讀:爲什麼選擇 TiDB ?

TiDB 是一款 HTAP 爲特點的數據庫,定位於在線事務處理/在線分析處理 HTAP(Hybrid Transactional / Analytical Processing)的融合型數據庫,具備一鍵水平伸縮,強一致性的多副本數據安全,分佈式事務,實時 HTAP 等重要特性,同時兼容 MySQL 協議和生態,遷移便捷,運維成本低。

相較於其他開源數據庫,TiDB 在實時數倉的構建中,既能夠用來存儲高併發的事務數據,又能應對複雜的分析類查詢,對於用戶來說無疑是非常友好的。從 4.0 開始,TiDB 引入了 TiFlash 列存引擎,可以將實時業務需求與分析類的需求在存儲層中做物理隔離,此外 TiDB 還具備以下優勢

  • 基於行存和列存的 HTAP 架構:

  • 提供完整的索引以及針對明細數據精確定位的高併發訪問,滿足高 QPS 的點查。

  • 高性能的 MPP 框架以及可更新的列存引擎,在數據進行更新之後,可以實時的同步修改到列存引擎,使得系統可以用分析型數據庫的讀取性能訪問最新數據,滿足用戶的實時查詢需求。

  • 一套入口同時滿足 AP 和 TP 需求,優化器會自動根據請求的類型決定是進行TP 類訪問,索引選擇,還是列存或則 MPP 計算模式,簡化架構的複雜度。

  • 彈性擴縮容:對線上環境的 TiDB、PD、TiKV 組件進行靈活便捷的擴縮容而不會對生產環境產生影響,操作透明。

  • SQL 標準與兼容 MySQL 協議:支持標準的 SQL 語法,包括聚合,JOIN,排序,窗口函數, DML、online DDL 等功能,用戶可以通過標準的 SQL 對數據進行靈活的分析運算。

  • 管理簡單:使用 TiUP 工具可以快速的完成集羣環境的搭建部署;正常運行時不需要依賴其他系統,運維上手簡單;提供自帶的監控系統,方便進行性能瓶頸分析和問題排查。

另外,在架構上,TiDB 在實時數倉場景中的應用也具備獨特優勢。

首先,內核設計,TiDB 分佈式數據庫將整體架構拆分成了多個模塊,各模塊之間互相通信,組成完整的 TiDB 系統。對應的架構圖如下:

  • TiDB Server:SQL 層,對外暴露 MySQL 協議的連接 endpoint,負責接受客戶端的連接,執行 SQL 解析和優化,最終生成分佈式執行計劃。

  • PD (Placement Driver) Server:整個 TiDB 集羣的元信息管理模塊,負責存儲每個 TiKV 節點實時的數據分佈情況和集羣的整體拓撲結構,提供 TiDB Dashboard 管控界面,併爲分佈式事務分配事務 ID。

  • 存儲節點

  • TiKV Server:負責存儲數據,從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region,每個 Region 負責存儲一個 Key Range(從 StartKey 到 EndKey 的左閉右開區間)的數據,每個 TiKV 節點會負責多個 Region。

  • TiFlash:TiFlash 是一類特殊的存儲節點。和普通 TiKV 節點不一樣的是,在 TiFlash 內部,數據是以列式的形式進行存儲,主要的功能是爲分析型的場景加速。

其次,TiDB 5.0 通過 TiFlash 節點引入了 MPP 架構這使得大型表連接類查詢可以由不同 TiFlash 節點分擔共同完成

當 MPP 模式開啓後,TiDB 會通過代價決策是否應該交由 MPP 框架進行計算。MPP 模式下,表連接將通過對 JOIN Key 進行數據計算時重分佈(Exchange 操作)的方式把計算壓力分攤到各個 TiFlash 執行節點,從而達到加速計算的目的。加上之前 TiFlash 已經支持的聚合計算,MPP 模式下 TiDB 可以將一個查詢的計算都下推到 TiFlash MPP 集羣,從而藉助分佈式環境加速整個執行過程,大幅度提升分析查詢速度。

Benchmark 測試顯示,在 TPC-H 100 的規模下,TiFlash MPP 提供了顯著超越 Greenplum,Apache Spark 等傳統分析數據庫或數據湖上分析引擎的速度。藉助這套架構,可以直接針對最新的交易數據進行大規模分析查詢,並且性能上能夠超越傳統離線分析方案。同時,測試結果顯示 TiDB 5.0 在同等資源下,MPP 引擎的總體性能是 Greenplum 6.15.0 與 Apache Spark 3.1.1 兩到三倍之間,部分查詢能達 8 倍性能差異。在數據分析性能上擁有顯著優勢。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章