作者介紹：王天宜，TiDB 社群部門架構師。曾就職于 Fidelity Investment，Softbank Investment，擁有豐富的資料庫高可用方案設計經驗，對 TiDB、Oracle、PostgreSQL、MySQL 等資料庫的高可用架構與資料庫生态有深入研究。
資料倉庫是公司資料發展到一定規模後必然需要提供的一種基礎服務，也是“資料智能”建設的基礎環節。早期數倉多為離線模式，主要處理的是 T+1 的資料，随着網際網路時代的到來，實時資料處理的場景日益增多，離線數倉已無法滿足業務發展的實時性需求。為更好的解決業務場景的實時化需求，實時數倉建設已成必然态勢。
實時數倉相較于離線數倉，主要處理的是 T+0 的資料，實時性更高，完美契合業務高效運轉的需求。在架構上，實時數倉通常使用 Flink 來消費 Kafka 中的資料，将資料流實時的寫入資料庫中。這種方案雖然解決了資料處理的時效問題，但很多時候，由于 Kafka 沒有落盤機制，可能在極端的情況造成消息隊列中資料丢失。
針對上述問題，筆者調研了頁面上的資料庫與存儲引擎，發現了能徹底解決 Kafka 落盤問題的，更高效準确的實時數倉新方案。
首先，在資料庫的選擇上，考慮可擴充性更高的分布式資料庫 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 倍性能差異。在資料分析性能上擁有顯著優勢。
偶遇 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 來觀察執行情況。
參考閱讀：
1. TiDB 簡介
2. Pravega官方網站
3. TiDB TPC-H 性能對比測試報告
4. 成為一棧式資料服務生态： TiDB 5.0 HTAP 架構設計與場景解析