TDSQL | 在整個技術解決方案中HTAP對應的混合交易以及分析系統應該如何實現？

從主交易到傳輸，到外掛式解決方案，每個廠商對HTAP的理解和實驗方式都有自己的獨到解法，在未來整個資料解決方案當中都會往HTAP中去牽引。**那麼在整個技術解決方案中HTAP對應的混合交易以及分析系統應該如何實現？**

本文是騰訊雲資料庫總經理林曉斌先生在《DTCC 2021中國資料庫技術大會》演講實錄，將詳細解讀HTAP資料庫應用時間場景和未來發展趨勢，帶大家共同探討HTAP資料庫解決方案。

**資料分析其實一直都在，只是現在對實時性要求越來越高**，之前相關報表統計，第二天早上上班之前得到結果就可以，現在要求分鐘級得到結果。 同時隨著資料量變大，這對計算的要求就更高，客戶需求也隨之越來越嚴苛。

去年**第七次全國人口普查**中，給應用後臺分析時間非常短暫，整個資料量非常大，我們也深刻感覺到HTAP這種系統解決方案的必要性。騰訊也一直致力於這個系統構建，今天想跟大家分享一下我們對HTAP系統的理解。

**為什麼需要HTAP？**一個生態內需要支援TP和AP的工作負載，這幾乎是要求實時性同時了，看上去好像是兩個系統，實際上我們對系統要求更希望看上去是一個。系統需求有哪些呢？第一個是低延遲，通常所說的延遲是一個請求寫下去就有反饋給客戶端，這種都是毫秒級的。而現在提到的延遲是指一個資料寫進去之後，多久能從分析系統裡體現出分析系統的結果，目前已經達到了分鐘級別。如果你告訴客戶資料寫下去以後，2個小時可以構建到分析系統裡，這是不可行的。

同時在效能吞吐方面，我們知道AP系統儲存、尤其是在查詢能力或單點併發方面比較具有優勢。那TP系統怎麼跟上AP吞吐能力和一致性？我們看到業界在做解決方案時，無論是構建同一個系統架構，還是傳輸服務內部做資料傳輸重建，模型都是差不多的，都是在解決資料的一致性，但是資料的強一致性是個非常大的挑戰。

一個基本的HTAP架構應該是什麼樣的呢？借用騰訊自己的內部解決方案來舉例，我們第一代架構是比較傳統TP和AP做比較明顯的分開，對應用來說可以統一成一個入口。能夠在TP側寫入，通過DTS打通。如果做兩個同步資料庫之間傳輸，做資料校驗和穩定性，AP、TP資料往往結構是異構的，所以要做儲存格式轉換。這個點其實是如何做到通用性對系統的考驗，比方說針對一個具體應用很好做，但是如果做成通用的雲上服務就很難了。

**那怎麼做到雲上服務？**可以靈活定製，甚至可以用拖拽來進行業務定製。當資料傳輸到這，後臺就由AP列出來做資料分析的能力，目前已基本實現了主流MySQL和TDSQL等解決方案。這麼一套系統比單獨一個挑戰更大，它不只是在檢查每一個元件是否健康、資料是否保持一致性，還要檢查同步服務延遲以及預測延遲風險，預測多久可以做到，我們當然希望實現分鐘級、秒級的延遲，但是TP端業務量突然增大，就需要分析出當前主要延遲在哪個位置，同時還要預估出多久可以恢復，這個對系統診斷的要求很高。

現在診斷系統構建還是比較方便的，這是一個比較常見的架構。可以看到國內有很多把HTAP做到整個系統的資料庫，基本上都是把元件擴充套件外延搭積木，整體流程變化不大。我們之前也看到過一些解決方案，比如直接在TP系統上做分析，或是直接在AP系統上TP能力，目前來看也沒有很成功的案例。在開始做大規模資料分析的時候，如果沒有做資料重建其實是很難呈現的，我們跑下來之後，也加深了我們這方面的認知，專業事件還需要有專業模組去做。

**那麼我們說的這個架構痛點是什麼？**如果匯入太快，會造成AP系統負載高，會影響查詢性。如果匯入慢一點，會有延時，影響到實時性。不同業務有不同的容忍時間，可以給我們系統提供一些引數調整。

在資料一致性這塊，尤其是實時一致性方面會有更強烈的挑戰，比方說有些資料要求馬上能用，當然不是所有的，這時候就需要做一些跨元件語句，不同資料就通過普通傳輸，要求嚴苛資料就需要提供一致性的語句。過一段時間資料再需要同步的要求，我們就要做跨系統的同步，包括一致性。

**水平擴容方面，基本可以做到自動化**，考慮到這個資料還有人去消費，外部系統的強耦合，當一個TP系統有標準的流程，需要考慮到這個系統跟AP系統聯動，它的日誌合併邏輯，日誌的持續邏輯都需要訪問進去，這是目前系統遇到的一些挑戰。

這些問題並不是百分之百能解決，但是我們可以有一些改進方法，基本思路用一句話來講怎麼解決這個痛點？提供源到端的全鏈路閉環。從使用者視角來說就是一個入口，一個出口，甚至入口和出口做到同一個，降低接入難度。一個系統複雜度就在那裡，降低使用者使用的難度，就是把難度在系統內部消化，我們思路就是提供一整套解決方案，讓使用者感覺到他使用一個系統，把資料同步、延遲、一致性校驗等工作在系統內部去實現，使用者不用關心這些細節。

基本實現細節，在雲端通過無鎖遷移，通過binlog訂閱從P同步資料，降低TP節點的影響。在AP側，這套系統能跑得比較順暢，但是在AP側的改動是非常大的。傳統引擎接進去能不能運作？真正實現聯動，也需要對AP系統做很多改造，把自己主動接入進去做同步，以及提供資訊，主動把資訊暴露出來，給整個診斷系統去診斷，去發現問題。

同時通過DTS批量寫入，AP系統單獨寫入是很慢的，可能一秒寫兩三萬，一般解法是通過批量寫入，通過這種方式去匯入，提高AP系統的吞吐量。但是需要核心暴露關鍵指標，自動調節批量大小和寫入頻率，實現寫入自動擁塞控制。固定頻率或者拿到一些反饋，通過RT，通過數量等方式來調整寫入的速度。現在整個思路會反過來，AP系統自己寫的時候，一邊把資訊暴露給外面，瞭解這個系統接下來能接受多大寫入量，用這種方式來調節視窗。經過我們的實踐，這種方式是比較簡單的，一方面能夠保證AP系統能寫進去，另外也不會導致浪費。

**我們也可以通過不同資料型別去做區分**，有些資料是實時的，這一行資料強同步，超過80%資料應用是可以接受TP寫完，在通過AP旁路方式寫進去，保證最終一致性，讓DTS和AP、TP系統形成聯動，避免出現黑盒，這樣調整能力會比較高，通過這樣方式實現系統穩定性。

除了保證系統的穩定性和一致性，還有系統的實時性，實時性往往可以調節，所以穩定性是非常重要的，最擔憂的問題是寫進去以後過5分鐘查不出來，卻不知道原因，所以穩定性是比較重要的，需要對系統內部資訊有非常明確瞭解。

資料一致性在這裡的要求，要求自動對映。在生產系統裡常規資料寫入，資料庫裡面有邏輯日誌，這些日誌可以環節資料的內化，同步到系統當中。另外DDL同步要求更高，有兩個原因，一個是DDL裡面沒有全部資訊，如果想加一個、減一個列，但是你只有一個列的資訊，沒有整個表的資訊，這樣對就需要有模組對整個系統的元資訊進行管理。另外就是實時性，一旦DDL出現延遲，可能會影響後續更改資料的同步，所以DDL語句同步也很重要。我們想讓系統放在公有云上，大家都知道用MySQL，但是用TDSQL，建立完之後就可以了，如果我們希望整個系統可以自治好用，實際上DDL同步是非常關鍵的。

binlog改寫也非常重要，讓後續UPDATE/DELETE同步的一致性和實施性的完整方案得以保證，日誌變更改寫怎麼做到讓AP系統也能夠理解，這一塊設定是非常重要的，是屬於比較好接入的，我們也積累了很多專家工程師，對日誌做充分補充，讓這三類資料得以保證。

另外在資料一致性方面，**TP系統的幾類挑戰包括資料型別挑戰**，第二是TP系統做遷移的挑戰，另外AP系統本身也有擴容的需求。AP系統做水平擴容也是一樣，保證這個系統從閉環推動，整個過程做ReSharding，這個過程怎麼做到業務寫入和讀取資料能夠實現無感知，現在比較常見的做法是先有一個AP，設定節點，然後再進行擴充套件，做資料同步和拆分，拆完以後再切過去，但是這個成本比較高。我們目前正再探索一些本地擴容的方法，這樣成本會更低，另外擴容速度也會更高一些，在這裡面有很多挑戰。

後續我們認為HTAP的服務可能需要增加Controller的角色，管理所有節點，包括對整個叢集資訊結構的控制，做到統一管理。第二個是加入節點和水平過載過程中，叢集統一管理，目前每個元件單獨管理，也是比較大的挑戰。因為對目前實現來說是架構上比較大的改變，我們相信當我們要實現最終的，從源到端閉環，要有統一入口，對語序做自動識別，所有查詢都要做分析、解析，去判斷往哪一個系統接入，做到這一步我們才認為是構建完整的HTAP架構。

**目前騰訊雲服務已經能滿足較高的生產需求，包括公有云專案已經驗證過我們有這個能力構建一套HTAP系統服務整個業務**，當然我們的挑戰還有很多，可能十幾年前硬體有瓶頸，之後是網路訪問的瓶頸，到慢慢我們發現一個新的挑戰，這個挑戰我們並不能提前做準備，很可能這個需求一直存在，只是受限於各個系統發展。現在分鐘級已經不能夠滿足使用者的要求了，目前我們看這個路線有可能實現秒級資料構建完成，但是需要更多的細節的把握和優化，核心的點還是AP系統怎麼無縫銜接到整個體系裡，把內部資訊暴露出來提供給整個系統的能力，最終保證系統的穩定性，這是我們認為這個系統的最大挑戰。

目前來看是錦上添花的工作，可能再過一兩年又會變成新的景象，我們做資料庫行業的同學們還是很興奮的，因為我們發現了一個可以讓我們深耕，又可以明確感知到在生產或者生活領域的系統當中，這是我今天的分享，感謝大家。