本文根據微眾銀行資深資料庫架構師黃蔚在 DevCon 2022 上的分享整理，主要講述了微眾銀行對於 HTAP 架構的探索和實踐情況，以及提升大規模分散式資料庫運維效率的經驗。
內容將從四個方面展開：HTAP 技術的演進歷程、微眾銀行在 HTAP 技術的選型以及實踐、在大規模分散式資料庫自動化運維的最佳化實踐、TiDB 在微眾銀行的未來規劃。
TiDB HTAP 架構的演進
我們知道一項新技術的出現和發展，其背後往往有兩個原因：一是因為業務驅動，追求客戶的極致體驗；二就是技術的發展，透過一些新技術的創新和應用，進一步降低硬體成本、開發成本或整體維護成本。HTAP 其實也是在這樣背景下誕生的。
我們首先來看傳統的資料架構有哪些瓶頸或者有哪些最佳化點。我們知道，按照負載型別劃分，系統一般分為 OLTP 和 OLAP，OLTP 在金融場景一般是包括像交易、轉賬、營銷等，面向的是客戶，追求的是極致體驗，如果有問題很可能就會影響使用者體驗，甚至造成使用者損失。所以 OLTP 要求的是耗時短，並且處理的資料量相對小。
而我們還要基於這些使用者產生的資料做商業分析、資料探勘，根據分析結果來進行決策，比如進行戰略方向上的調整。所以衍生出來了 OLAP，通常專門用來做一些分析。而 OLTP 和 OLAP 的負載不一樣，也就意味著技術底座是不一樣的，所以一般是將兩者分開，這個時候就需要透過 ETL 的方式把資料傳輸到 OLAP 上做分析，但是這個傳輸的過程在時效性上會比較差，同時架構也會比較複雜，但優勢是這套架構非常成熟，尤其是自從大資料三駕馬車的論文出來之後，大資料的整個生態變得更加成熟，使用也更廣泛。
隨著業務的發展，業務對於時效性的要求越來越高，比如希望實時對使用者進行客群圈選、畫像分析、實時洞察，或者做金融場景的風控，這時候就誕生出了 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 這個功能，降低一致性的保障，但可以提升讀寫速度。
我們看到 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 萬+ 這樣一個量級。
我們可以透過這些 Trace 資訊去追蹤這一筆交易涉及的不同服務、不同的子系統之間呼叫的詳細資訊，比如說源端、目標端呼叫的耗時，呼叫返回的狀態，有沒有報錯等，這是微觀層面的追蹤。微服務場景下，服務數量非常多，種類也多，呼叫關係很複雜，我們怎樣從全域性的角度瞭解整個微服務的架構是否健康，是否存在問題，比如有沒有流量突增，有沒有系統性的問題？所以衍生出了服務治理這個系統。服務治理的要求是能夠實時知道微服務整個呼叫關係的資訊，所以我們就把 TiKV 儲存的 Trace 資訊實時同步到 TiFlash，同時我們預定義很多的度量指標，比如實時分析整個服務的健康度，整個子系統呼叫的次數排名，是否存在流量突增，耗時的變化等。
基於這些度量指標，我們再透過決策引擎去得到一個最優的治理策略。我們的決策可以分成兩部分，第一個是自動決策，透過度量指標直接把需要去治理的動作下發到生產環境的微服務的應用或者容器。第二個是輔助決策，生成一個決策值，人工進行判斷，根據經驗或者根據一些特定的閾值觸發相應的策略，再下發到真正的生產環境。我們看到整個系統形成了一個閉環，從生產環境產生訊息，到分析訊息，再透過度量產生決策，最後又反向去影響我們的生產環境，讓整個微服務的精細化管理越來越好，這是我們在 HTAP 選型的一個場景。
當然我們也遇到了一些挑戰，第一是叢集非常大，第二是在這麼大規模的叢集下還要跟 TiFlash 結合。所以我們形成了相關的實踐經驗。首先，叢集很大，如何穩定執行？我們從幾個方面進行入手：第一，TiDB 的元件 PD 可能會存在個別單點瓶頸，所以我們把大叢集 Region 總數控制在一定範圍；第二，控制單個 TiKV 例項的 Region 數量，對於一些歷史歸檔或者相對冷的資料，心跳維持不用太頻繁，所以我們開啟了 Hibernate Region 功能，減輕單個例項可能產生的瓶頸問題。
其次，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 會有資源的佔用。
因為寫入同樣也會觸發分裂，同樣也會需要 Remove Peer 功能，這時候就產生了互斥。我們在整個實踐中發現，各個排程引數之間可能會相互影響，所以需要找到引數之間的相互干擾的因素，再找到一個最佳的平衡點。最後，我們透過右下角這張圖對相關引數進行了深入研究和除錯，最終實現了超大叢集下 TiKV+TiFlash 的穩定聯動，可以確保 20 萬+ 每秒的持續寫入並不會產生明顯抖動。
TiFlash 實際上也是一個 OLAP 的引擎，在很多場景裡會拿 TiFlash 去跟一些 OLAP 傳統元件去對比，比如拿 TiFlash 跟 Clickhouse 去對比。我們在真正的業務場景中發現使用者的需求場景很多，對應的技術要求也不一樣，所以細分下來發現像有些分析場景，可能對於實時性要求很高，有些場景可能計算量很大，維度很固定，希望做一些預計算，還有一些互動式的，希望靈活和快速返回，所以我們透過細分業務場景以及對應的技術要求的細化，最終找到了不同的 OLAP 元件所對應的場景和最佳實踐。
我們也對 TiFlash 和 Clickhouse 做了一個簡單對比，可以很明顯地看到 Clickhouse 在硬體成本以及單表的效能上有很大優勢，而 TiFlash 在運維成本、開發成本以及實時更新有不錯的優勢。所以我們認為 OLAP 元件沒有銀彈，我們可以透過這種組合的方式，透過在各個 OLAP元件之上增加一箇中間層來統一來提供服務給業務，讓業務不用感知具體的引擎或元件，對使用者來說，只需要去滿足業務需求就好了。
TiDB HTAP 的場景推薦有哪些呢？第一個肯定是 HTAP 型的交易系統，OLTP 是一定要用的，同時我們要結合 OLTP 把資料同步到 TiFlash 進行實時分析，這是第一種最經典的場景。第二種，我們知道 TiDB 有 DM 工具，可以把多個 MySQL 的資料快速地同步匯聚到一個 TiDB 叢集，多源匯聚到 TiDB 後，TiDB 可以是一個資料中臺、一個資料倉儲或者是一個資料集市，再結合 TiFlash 的分析能力，快速地進行業務分析或業務監控，所以多源資料的匯聚和實時分析是第二個場景。第三個場景，就是上面提到的，把 TiDB 作為一個單純的 OLAP 元件使用，當然成本會較高，因為如果只使用用 TiFlash，還是需要從 TiKV 進行資料同步。但是 TiDB 的好處就是開發成本比較低。
基於微信機器人的 TiDB 資料庫運維最佳化
目前 TiDB 在微眾銀行的叢集規模越來越大，從 2021 年開始的 20 多個叢集到現在已經接近 60 個叢集，資料的總容量也接近 800T，同樣使用 TiDB DM 的量也非常大，應用的業務型別也特別多，包括貸款、存款、理財、科技管理、基礎科技，應用的場景包括聯機、批次、歸檔、管理平臺等等。在資料增長快，應用規模大，業務場景型別多，重要性高的情況下，同時還要符合合規要求，因此在 TiDB 大規模分散式資料庫的運維上，我們也進行了很多探索，比如怎樣更高效地運維和使用分散式資料庫。
我們有三個方面的總結：第一，做標準化的 SOP，對於業務接入，日常變更和故障處理，我們都需要一些標準化的流程；第二，這麼大規模的叢集量，我們希望運維工作可以 Work Smart，也就是更加高效地處理遇到的問題，我們引進了微信機器人，把叢集診斷、巡檢這些工作都自動化了；最後，開源有一個最大的好處就是能看到原始碼，所以我們希望可以從原始碼側去解析，這樣有些疑難問題我們可以更加深入，更加快捷地去發現問題，同時提供更理想的最佳化方案。
接下來看看我們基於微信機器人的 Smart 運維工作。可以看到，我們的 DBA 只需要透過微信，透過一部手機就可以對一些場景進行快速處理。以往，在銀行，對於遇到一些生產的告警，我們需要去登陸 VPN，輸入 Token，在其他的內部系統又要做二次登入校驗，整個過程耗時比較長。而針對一些比較緊急的告警，登入到伺服器，已經過去了不少時間，所以我們希望針對一些特定合適的告警場景，快速地去響應，所以我們基於微信機器人的方式進行了最佳化，分成幾個層次。
第一，透過 TiDB 自帶的 TiUP 工具來做一些資料採集，包括叢集資訊和主機的 CMDB 資訊，把這些資訊全量入庫。每天定時去把收集的資訊進行分析巡檢，輸出一個報告。第二，在自動診斷這塊，我們在 TiDB 上會遇到一些常見高頻的問題，比如記憶體高、OOM、熱點、慢查詢、執行計劃突變等，我們把這些問題處理會形成一個知識庫，並且生成對應的分析引擎，如果觸發了對應告警，就會自動地觸發根因分析，並且生成推薦根因。在生成推薦根因的時候，我們還會模擬爬蟲在 Grafana 上把最近的半小時的 Overview，包括一些監控檢視、例項資訊截圖生成一個圖片，結合剛才的推薦根因一起推送到我們的手機微信上。DBA 立馬就可以看到告警發生可能的原因是什麼，並且我們還可以快速地進行執行，處理相應問題。
我們在微信機器人上提供了一個互動的快速執行方式。比如可以對一些慢查詢進行 Kill，比如 restart TiDB Server，當然前提一定是安全合規，我們對一些高危命令會增加預審批流程，同時我們會預定義一些白名單的命令。最終可以看到，我們從巡檢、資料採集、自動診斷以及互動式的快速執行四個維度來整體提升資料庫的運維效率。
這裡是 Smart 運維的效果圖，可以看到像 tiup display、show processlist，以及 kill 慢查詢，restart server 等一系列動作，都可以透過一部手機去完成，我們內部稱為微信機器人的運維方式，這種方式提升了資料庫的運維效率。
最後做一個簡單的展望，我們希望未來繼續沉澱 HTAP 技術在金融場景的探索和落地經驗，形成金融場景的最佳實踐。同時，我們希望未來能夠把內部的一些運維工具，比如 DM 自動化校驗平臺、自動診斷平臺等開源出去，能夠和大家進行深入的交流和共創。
最後，隨著國產化的程式，我們也會推動 TiDB 在國產 ARM 伺服器上的進一步擴大使用。
<div class="is-flex is-flex-direction-row is-justify-content-center">
<div class="is-flex is-flex-direction-column">
<a target="_blank" class="button is-link mx-5"
href="/product-community/"
style="background-color: #4fc172;">
下載 TiDB 社群版
</a></div>
<div class="is-flex is-flex-direction-column">
<a target="_blank" class="button is-link mx-5"
href="/contact#submit-form"
style="background-color: #3a40e1;">
諮詢 TiDB 企業版
</a></div>
<div class="is-flex is-flex-direction-column">
<a target="_blank" class="button is-link mx-5"
href="https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.5-release"
referrerpolicy="no-referrer-when-downgrade" style="background-color: #3a40e1;">
免費試用 TiDB Cloud
</a>
<div style="font-size:12px; text-align:center">適用於中國出海企業和開發者</div></div>
</div>