微眾銀行 TiDB HTAP 和自動化運維實踐

語言: CN / TW / HK

本文根據微眾銀行資深數據庫架構師黃蔚在 DevCon 2022 上的分享整理,主要講述了微眾銀行對於 HTAP 架構的探索和實踐情況,以及提升大規模分佈式數據庫運維效率的經驗。

內容將從四個方面展開:HTAP 技術的演進歷程、微眾銀行在 HTAP 技術的選型以及實踐、在大規模分佈式數據庫自動化運維的優化實踐、TiDB 在微眾銀行的未來規劃。

TiDB HTAP 架構的演進

我們知道一項新技術的出現和發展,其背後往往有兩個原因:一是因為業務驅動,追求客户的極致體驗;二就是技術的發展,通過一些新技術的創新和應用,進一步降低硬件成本、開發成本或整體維護成本。HTAP 其實也是在這樣背景下誕生的。

我們首先來看傳統的數據架構有哪些瓶頸或者有哪些優化點。我們知道,按照負載類型劃分,系統一般分為 OLTP 和 OLAP,OLTP 在金融場景一般是包括像交易、轉賬、營銷等,面向的是客户,追求的是極致體驗,如果有問題很可能就會影響用户體驗,甚至造成用户損失。所以 OLTP 要求的是耗時短,並且處理的數據量相對小。

而我們還要基於這些用户產生的數據做商業分析、數據挖掘,根據分析結果來進行決策,比如進行戰略方向上的調整。所以衍生出來了 OLAP,通常專門用來做一些分析。而 OLTP 和 OLAP 的負載不一樣,也就意味着技術底座是不一樣的,所以一般是將兩者分開,這個時候就需要通過 ETL 的方式把數據傳輸到 OLAP 上做分析,但是這個傳輸的過程在時效性上會比較差,同時架構也會比較複雜,但優勢是這套架構非常成熟,尤其是自從大數據三駕馬車的論文出來之後,大數據的整個生態變得更加成熟,使用也更廣泛。

1.png

隨着業務的發展,業務對於時效性的要求越來越高,比如希望實時對用户進行客羣圈選、畫像分析、實時洞察,或者做金融場景的風控,這時候就誕生出了 Kappa 架構。

Kappa 架構的核心就是流式處理, OLTP 系統產生的 CDC 或者 Message 通過 Kafka 消息隊列傳輸到常見的流處理技術組件比如 Flink、Spark Streaming 進行處理,最終到 Serving DB 來存放這些數據並實時對外提供服務。而對於 Serving DB 的要求首先是擴展性要好,同時受限於流式處理暫時沒法完全取代批處理,那就意味着在 Serving DB 上還需要做一定的 OLAP 分析。其實 TiDB 在這個架構裏也有一定的使用量,比如 Flink 要存放一些中間態數據或者進行維表關聯,對於 DB 也需要一定的擴展性,此時 TiDB 的擴展能力正好可以滿足。

這個架構的核心特點就是準實時處理,而且在工程實踐上非常豐富。而這個架構的劣勢是組件很多,學習的成本相對高,並且整個鏈路很長,意味着在數據一致性的保證上會比較困難。所以,大家就在想能不能在一個數據庫同時去承載 OLTP 跟 OLAP 業務呢?不需要去做額外的數據同步,不需要去學習額外的組件,所以就衍生出了 HTAP 數據庫的概念。

它的架構很簡潔,但是實現技術難度也非常高。雖然這幾年 HTAP 非常火,但是工程實踐相對較少,像傳統的 Oracle 12c In-Memory Column Store、Google Spanner PAX 其實都算是行列混存的架構,TiDB 也有自己的 HTAP 實現。HTAP 架構的難度是怎樣做資源隔離,怎樣做一致性保證,如何做 OLTP 和 OLAP 的負載平衡等等。

接下來談談 TiDB HTAP 架構的演進,我們如何基於業務需求去做選型以及對應的實踐情況。

圖中,我們看到 TiKV 為了讓數據均衡,容易做分佈式調度,會把數據分成很多小片,也就是 Region,Region 在 TiKV 這一側是強同步的,我們可以看到綠色線條是實線。而 TiFlash 的創新點就是沒有打破原來 TiKV 的架構,而是新增一個列式引擎,直接通過 Raft Log 的方式同步到 TiFlash,因為列式存儲天然對於 OLAP 場景是比較友好的,所以還要做一個行轉列的處理。我們可以看到 TiKV 到 TiFlash 的同步線是一條虛線,意味着這是一個異步過程。那麼又如何保證在 TiFlash 上的查詢是強一致的呢?這裏其實做了一些優化,每次收到讀取請求,TiFlash 中的 Region 副本會向 Leader 副本發起進度校對(一個非常輕的 RPC 請求),只有當進度確保至少所包含讀取請求時間戳所覆蓋的數據之後才響應讀取,所以如果有同步延遲,就會需要等待,甚至有可能在 TiFlash 的查詢會超時,在實踐中我們發現有些場景對於 OLAP 的一致性要求並沒那麼高,而在 6.0 版本的 TiFlash 提供了 Fast Scan 這個功能,降低一致性的保障,但可以提升讀寫速度。

2.png

我們看到 TiDB HTAP 架構隔離性非常好,因為列存跟行存完全獨立,同時 TiFlash 藉助了 MPP 並行計算框架,並且是基於 Clickhouse 底座,所以天然具備向量化計算引擎的一些 OLAP 特性。同時,TiDB HTAP 架構創新性地通過 Raft Log 來同步保證了一致性,同時也可以通過 Fast Scan 功能來降低一致性,提高讀寫速度。進一步的,TiDB 的產品迭代非常快,有一些特性是我們也非常期待,比如説低成本的硬盤支持、更準確的優化器等。

微服務分佈式鏈路追蹤和微服務治理場景下的 HTAP 實踐

在銀行場景下我們怎樣選型 HTAP 技術呢?微眾銀行的基礎架構是基於 DCN 的分佈式架構,也就是單元化,一筆簡單的交易可能涉及到幾十甚至上百個微服務在背後支撐,所以微服務的調用量很大。那麼我們怎樣快速地進行定位異常問題呢?比如説一筆交易或者一個系統如果有異常,怎樣快速地知道哪裏出問題了?這裏就需要藉助可觀測的方式。可觀測一般都會談到 Trace、Metrics、Log 這三個基本元素。

基於微眾銀行 DCN 的分佈式架構,如果兩個用户分屬不同的 DCN,要進行交互比如轉賬,就需要通過 RMB 可靠消息總線來進行交互。我們為了保存完整全量的微服務調用關係,會旁路地消費一份服務之間的調用消息,把這些信息存到 TiDB。為什麼存到 TiDB 呢?我們行內交易量特別大,TiDB 正好能提供擴展性,同時 TiDB 支撐的併發量也很大,每秒達到了 20 萬+ 這樣一個量級。

3.png

我們可以通過這些 Trace 信息去追蹤這一筆交易涉及的不同服務、不同的子系統之間調用的詳細信息,比如説源端、目標端調用的耗時,調用返回的狀態,有沒有報錯等,這是微觀層面的追蹤。微服務場景下,服務數量非常多,種類也多,調用關係很複雜,我們怎樣從全局的角度瞭解整個微服務的架構是否健康,是否存在問題,比如有沒有流量突增,有沒有系統性的問題?所以衍生出了服務治理這個系統。服務治理的要求是能夠實時知道微服務整個調用關係的信息,所以我們就把 TiKV 存儲的 Trace 信息實時同步到 TiFlash,同時我們預定義很多的度量指標,比如實時分析整個服務的健康度,整個子系統調用的次數排名,是否存在流量突增,耗時的變化等。

基於這些度量指標,我們再通過決策引擎去得到一個最優的治理策略。我們的決策可以分成兩部分,第一個是自動決策,通過度量指標直接把需要去治理的動作下發到生產環境的微服務的應用或者容器。第二個是輔助決策,生成一個決策值,人工進行判斷,根據經驗或者根據一些特定的閾值觸發相應的策略,再下發到真正的生產環境。我們看到整個系統形成了一個閉環,從生產環境產生消息,到分析消息,再通過度量產生決策,最後又反向去影響我們的生產環境,讓整個微服務的精細化管理越來越好,這是我們在 HTAP 選型的一個場景。

當然我們也遇到了一些挑戰,第一是集羣非常大,第二是在這麼大規模的集羣下還要跟 TiFlash 結合。所以我們形成了相關的實踐經驗。首先,集羣很大,如何穩定運行?我們從幾個方面進行入手:第一,TiDB 的組件 PD 可能會存在個別單點瓶頸,所以我們把大集羣 Region 總數控制在一定範圍;第二,控制單個 TiKV 實例的 Region 數量,對於一些歷史歸檔或者相對冷的數據,心跳維持不用太頻繁,所以我們開啟了 Hibernate Region 功能,減輕單個實例可能產生的瓶頸問題。

4.png

其次,TiDB 架構中 OLTP 的負載使用的是 TiKV,OLTP 往往面對的是客户,直接關係到用户體驗的問題,我們認為在極端情況下 TiFlash 有異常的時候,不希望它影響到 TiKV,因此我們建立了一個快速熔斷機制,目的是在 TiFlash 全部異常的情況下儘可能對 TiKV 的影響最小。我們還在超大集羣 POC 時做了很多暴力驗證,比如説把 TiFlash 全部直接關停,比如製造一些網絡擁塞,IO、CPU 資源跑滿等。在驗證過程中我們也發現了很多問題,也相應都做了修復,我們認為未來在超大集羣的使用上,HTAP 架構的健壯性會越來越好。

剛剛提到,TiKV 跟 TiFlash 需要聯動,集羣很大,又要做數據的生命週期管理。TiKV 是做鏈路追蹤,我們希望它的數據保留的時間比較長,比如 7 天,7 天之外的就刪掉,TiFlash 做的是實時分析,我們希望保存數據的天數少一點,比如 3 天,這兩邊的清理策略是不一樣的。這時候就會有一個問題,TiKV 跟 TiFlash 雖然物理上是隔離的,但 PD 調度是共用的,很可能會產生相互影響。舉個簡單例子,我們在超大集羣下往往需要去提前規避寫入熱點問題進行提前打散。我們發現在打散的時候會影響正常寫入,發現本質原因是打散動作首先會在一個 Region 上進行打散,最終再會去 scatter 均衡,而均衡背後有 Remove Peer 動作,就是把本地的 Peer 刪掉,再調到其他節點上,而 Remove Peer 會有資源的佔用。

5.png

因為寫入同樣也會觸發分裂,同樣也會需要 Remove Peer 功能,這時候就產生了互斥。我們在整個實踐中發現,各個調度參數之間可能會相互影響,所以需要找到參數之間的相互干擾的因素,再找到一個最佳的平衡點。最後,我們通過右下角這張圖對相關參數進行了深入研究和調試,最終實現了超大集羣下 TiKV+TiFlash 的穩定聯動,可以確保 20 萬+ 每秒的持續寫入並不會產生明顯抖動。

TiFlash 實際上也是一個 OLAP 的引擎,在很多場景裏會拿 TiFlash 去跟一些 OLAP 傳統組件去對比,比如拿 TiFlash 跟 Clickhouse 去對比。我們在真正的業務場景中發現用户的需求場景很多,對應的技術要求也不一樣,所以細分下來發現像有些分析場景,可能對於實時性要求很高,有些場景可能計算量很大,維度很固定,希望做一些預計算,還有一些交互式的,希望靈活和快速返回,所以我們通過細分業務場景以及對應的技術要求的細化,最終找到了不同的 OLAP 組件所對應的場景和最佳實踐。

6.png

我們也對 TiFlash 和 Clickhouse 做了一個簡單對比,可以很明顯地看到 Clickhouse 在硬件成本以及單表的性能上有很大優勢,而 TiFlash 在運維成本、開發成本以及實時更新有不錯的優勢。所以我們認為 OLAP 組件沒有銀彈,我們可以通過這種組合的方式,通過在各個 OLAP組件之上增加一箇中間層來統一來提供服務給業務,讓業務不用感知具體的引擎或組件,對用户來説,只需要去滿足業務需求就好了。

TiDB HTAP 的場景推薦有哪些呢?第一個肯定是 HTAP 型的交易系統,OLTP 是一定要用的,同時我們要結合 OLTP 把數據同步到 TiFlash 進行實時分析,這是第一種最經典的場景。第二種,我們知道 TiDB 有 DM 工具,可以把多個 MySQL 的數據快速地同步匯聚到一個 TiDB 集羣,多源匯聚到 TiDB 後,TiDB 可以是一個數據中台、一個數據倉庫或者是一個數據集市,再結合 TiFlash 的分析能力,快速地進行業務分析或業務監控,所以多源數據的匯聚和實時分析是第二個場景。第三個場景,就是上面提到的,把 TiDB 作為一個單純的 OLAP 組件使用,當然成本會較高,因為如果只使用用 TiFlash,還是需要從 TiKV 進行數據同步。但是 TiDB 的好處就是開發成本比較低。

7.png

基於微信機器人的 TiDB 數據庫運維優化

目前 TiDB 在微眾銀行的集羣規模越來越大,從 2021 年開始的 20 多個集羣到現在已經接近 60 個集羣,數據的總容量也接近 800T,同樣使用 TiDB DM 的量也非常大,應用的業務類型也特別多,包括貸款、存款、理財、科技管理、基礎科技,應用的場景包括聯機、批量、歸檔、管理平台等等。在數據增長快,應用規模大,業務場景類型多,重要性高的情況下,同時還要符合合規要求,因此在 TiDB 大規模分佈式數據庫的運維上,我們也進行了很多探索,比如怎樣更高效地運維和使用分佈式數據庫。

8.png

我們有三個方面的總結:第一,做標準化的 SOP,對於業務接入,日常變更和故障處理,我們都需要一些標準化的流程;第二,這麼大規模的集羣量,我們希望運維工作可以 Work Smart,也就是更加高效地處理遇到的問題,我們引進了微信機器人,把集羣診斷、巡檢這些工作都自動化了;最後,開源有一個最大的好處就是能看到源碼,所以我們希望可以從源碼側去解析,這樣有些疑難問題我們可以更加深入,更加快捷地去發現問題,同時提供更理想的優化方案。

接下來看看我們基於微信機器人的 Smart 運維工作。可以看到,我們的 DBA 只需要通過微信,通過一部手機就可以對一些場景進行快速處理。以往,在銀行,對於遇到一些生產的告警,我們需要去登陸 VPN,輸入 Token,在其他的內部系統又要做二次登錄校驗,整個過程耗時比較長。而針對一些比較緊急的告警,登錄到服務器,已經過去了不少時間,所以我們希望針對一些特定合適的告警場景,快速地去響應,所以我們基於微信機器人的方式進行了優化,分成幾個層次。

9.png

第一,通過 TiDB 自帶的 TiUP 工具來做一些數據採集,包括集羣信息和主機的 CMDB 信息,把這些信息全量入庫。每天定時去把收集的信息進行分析巡檢,輸出一個報告。第二,在自動診斷這塊,我們在 TiDB 上會遇到一些常見高頻的問題,比如內存高、OOM、熱點、慢查詢、執行計劃突變等,我們把這些問題處理會形成一個知識庫,並且生成對應的分析引擎,如果觸發了對應告警,就會自動地觸發根因分析,並且生成推薦根因。在生成推薦根因的時候,我們還會模擬爬蟲在 Grafana 上把最近的半小時的 Overview,包括一些監控視圖、實例信息截圖生成一個圖片,結合剛才的推薦根因一起推送到我們的手機微信上。DBA 立馬就可以看到告警發生可能的原因是什麼,並且我們還可以快速地進行執行,處理相應問題。

我們在微信機器人上提供了一個交互的快速執行方式。比如可以對一些慢查詢進行 Kill,比如 restart TiDB Server,當然前提一定是安全合規,我們對一些高危命令會增加預審批流程,同時我們會預定義一些白名單的命令。最終可以看到,我們從巡檢、數據採集、自動診斷以及交互式的快速執行四個維度來整體提升數據庫的運維效率。

這裏是 Smart 運維的效果圖,可以看到像 tiup display、show processlist,以及 kill 慢查詢,restart server 等一系列動作,都可以通過一部手機去完成,我們內部稱為微信機器人的運維方式,這種方式提升了數據庫的運維效率。

10.png

最後做一個簡單的展望,我們希望未來繼續沉澱 HTAP 技術在金融場景的探索和落地經驗,形成金融場景的最佳實踐。同時,我們希望未來能夠把內部的一些運維工具,比如 DM 自動化校驗平台、自動診斷平台等開源出去,能夠和大家進行深入的交流和共創。 最後,隨着國產化的進程,我們也會推動 TiDB 在國產 ARM 服務器上的進一步擴大使用。