爲數據賦能:騰訊TDSQL分佈式金融級數據庫前沿技術

時間 2019-11-25

原文原文鏈接

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~算法

簡介：李海翔，網名「那海藍藍」，騰訊金融雲數據庫技術專家。中國人民大學信息學院工程碩士企業導師。著有《數據庫事務處理的藝術：事務管理和併發訪問控制》、《數據庫查詢優化器的藝術：原理解析與SQL性能優化》，廣受好評。spring

2018年5月11日，騰訊TDSQL團隊爲中國數據庫技術大會DTCC帶來了騰訊最新的數據庫核心技術：TDSQL原創的全態數據的概念和基於歷史態數據的可見性判斷算法。sql

騰訊專家工程師李海翔在DTCC上作了主題爲「爲數據賦能---騰訊TDSQL分佈式金融級數據庫前沿技術」的技術內容分享。本次分享，基於數據庫事務處理的核心技術併發訪問控制技術，TDSQL原創性提出了全態數據的概念和基於歷史態數據的可見性判斷算法，並基於此實現了全時態數據庫。數據庫

以下是本次分享的主要內容。主要包括：TDSQL背景介紹、T-TDSQL原創技術出發點、T-TDSQL核心技術點、T-TDSQL典型應用、T-TDSQL核心理念、項目致謝六個部分。安全

1、 TDSQL概述

TDSQL是一個穩定運行了十年之久的分佈式數據庫，不只支撐了騰訊公司的計費業務，並且還在微衆銀行等金融單位的核心業務系統穩定、高效地運行了四年之久。這幾年，TDSQL在技術層面不斷進步，研發了不少新特性，諸如多級分區、熱點更新、隱含主鍵、分佈式事務等，不只有力的支撐了事務型的數據庫應用，並且在體系結構上也朝Spanner架構上邁進，是一個名副其實的NewSQL系統。性能優化

TDSQL分佈式事務處理技術，有了長足進步，不只表如今基於XA實現了2PC以支持分佈式事務的原子提交，並且在MVCC技術的基礎上，作了創新，使得TDSQL的事務處理技術基於原創技術而不斷髮展。微信

2、原創技術的出發點

TDSQL的原創技術，不是爲技術而技術，而是基於業務的需求，爲解決業務問題而進行的創新。架構

騰訊公司的計費業務系統，是世界上領先的金融雲計費業務系統。這個系統包括SAAS、PAAS、IAAS三個層面。在SAAS層面，包括米大師、雲商店、TDSQL等系統。併發

TDSQL託管帳戶近280億，米大師依託TDSQL進行金融交易,騰訊充值及其相關合做夥伴的日流水量超過150億條，天天處理的交易量超過100億筆。金融數據在TDSQL數據庫中進行結算、對帳、審計、風控數據分析、構建用戶畫像等業務。如王者榮耀遊戲點券的對帳業務、用戶帳戶消費充值變化審計與風控業務等。分佈式

要進行諸如對帳、審計等業務，數據來源有兩部分。一部分數據來源是從不一樣系統（關係數據庫或NoSQL系統）的日誌數據中來，稱爲流水日誌。但某個這樣的系統天天的日誌流水數據近百G且從趨勢看增量數據遞增很快。另外，有些數據是在TDSQL中按時間分表，需在一段時間結束後對按時間分表的數據利用流水日誌進行對帳計算。

對帳主要是解決幾種異常狀況：

系統存在BUG，或者在故障時，未表現出預期的狀況。這可能致使發貨成功扣款不成功，或者扣款成功未發貨的狀況。如騰訊視頻VIP管理系統的充值、發貨。
規避黑客/內部風險。例如不法人員繞過業務系統去給本身充值等舞弊行爲。

這樣的對帳業務種類不少，不一樣的應用其日誌流水格式不徹底相同，TDSQL託管的帳戶須要定時對多級數千種業務和帳戶作數據一致性對帳檢驗。

從技術的角度看，存在四個問題：

應用開發複雜：使用業務日誌，須要業務系統不斷產生日誌信息，而後耗費計算資源對不一樣的日誌格式進行解析，把日誌信息存儲到分析系統。由此帶來了開發的負擔和資源的浪費。
數據邏輯割裂：TDSQL中按時間分表，只能按肯定的時間段進行結算，不能靈活、方便的計算。如計算任意時間段內的數據，按時間段的分表在物理上割裂了數據按時間的邏輯連續特性，須要指定若干個特定的分表才能進行計算。
實時特性丟失：如上兩個問題，隱含地，意味着進行計算的數據須要導入到一個新的分析系統進行計算，導出/導入數據的過程也帶來了資源和時間的消耗、使得分析系統難以具有實時計算特性。
數據管理複雜：另外，日誌等信息，是歷史態數據，須要長期保存。在騰訊公司每日對不一樣格式的、超過150億條流水日誌進行生成、存儲、解析與管理等，這成爲一個巨大的挑戰。

現代的數據庫系統只保留有數據的當前值，而因存儲成本等緣由，歷史態數據被丟棄。而數據做爲重要的資產，無論是當前數據，仍是歷史上曾經存在過的數據，都具備重要價值。所以，歷史態數據存儲、被分析、被挖掘、被反覆使用，是當前互聯網等企業的需求。尤爲是金融類歷史態數據，由於安全、須要被屢次計算的緣由，在騰訊公司的計費業務中，帶有時態屬性的數據被管理的需求日益旺盛。

基於上述緣由，騰訊公司基於TDSQL關係型數據庫研發了時態數據庫 T-TDSQL，由數據庫系通通一管理海量的全時態數據、當前數據，解決了上述四個業務中的問題。

業務痛點的解決，是基於數據庫的特色和業務場景進行深刻分析和思考而得以解決的。

由於數據有價值，因此TDSQL團隊認爲：歷史數據富有價值。這是TDSQL時態數據庫T-TDSQL的核心價值觀。所以，咱們給出了TDSQL對於數據的新的認識。

TDSQL認爲：

數據的狀態屬性，標識數據的生命週期軌跡。數據的生命週期分爲三個階段，每一個階段刻畫數據的不一樣狀態屬性，以標識數據的生命週期軌跡中所處的狀態。

當前態（Current State）：數據項的最新版本的數據，是處於當前階段的數據。處於當前階段的數據的狀態，稱爲當前態。
歷史態（Historical state）：數據項在歷史上的一個狀態，其值是舊值，不是當前值。處於歷史階段的數據的狀態，稱爲歷史態。一個數據項的歷史態，能夠有多個，反映了數據的狀態變遷的過程。處於歷史態的數據，只能被讀取不能再被修改或刪除。
過渡態（Transitional State）：不是數據項的最新的版本也不是歷史態版本，處於從當前態向歷史態轉變的過程當中。處於過渡態的數據，稱爲半衰數據。

這三個狀態，涵蓋了一個數據項的生命週期，合稱爲數據全態（full-state），或稱爲全態數據。在MVCC機制下，數據的三種狀態均存在；在非MVCC機制下，數據只存在歷史態和當前態。

當前態：MVCC或封鎖併發訪問控制機制下，事務提交後的數據的新值處於當前態。
歷史態：MVCC機制下，當前活躍事務列表中最小的事務以前的事務生成的數據，其狀態處於歷史態。在封鎖併發訪問控制機制下，事務提交後，提交前的數據的值變爲歷史態的值，即數據項的舊值處於歷史態。
過渡態：MVCC機制下，被讀取的版本上尚有活躍事務（非最新相關事務）在使用，因最新相關事務修改了數據項的值，其最新值已經處於一個當前態，被讀取到的值相對當前態已經處於一個歷史狀態，故其數據狀態介於當前態和歷史態之間，因此稱爲過渡態。

數據的雙時態屬性，分別爲有效時間屬性、事務時間屬性。

有效時間屬性表示數據表示的對象在時間屬性上的狀況。如Kate中學起止時間是2000-09-01到2003-07-30，而大學起止時間是2003-09-01到2007-07-30，這裏的時間就是有效時間。

事務時間屬性表示數據的某個狀態的時間發生時刻。數據具備其時態屬性，即在什麼時候數據庫系統進行了什麼樣的操做。某項操做在數據庫系統內被封裝爲事務，而事務具備原子性。所以，咱們採用了事務標誌來標識一個數據的事務時態屬性。

從形式上看，有效時間屬性和事務時間屬性，在數據模型中用普通的用戶自定義字段進行表示，只是用特定的關鍵字加以描述，供數據庫引擎進行約束檢查和賦值。

TDSQL團隊指望，構建一個數據庫系統，解決如上問題，新系統應該提供的特性以下：

所以，基於TDSQL的T-TDSQL時態數據庫，有了以下的特性，這些特性，可以涵蓋雙時態的數據應用、數據安全、數據分析、簡化應用開發等四大方面的問題：

3、T-TDSQL的核心技術

T-TDSQL的核心技術之一，是數據模型的定義，全態數據模型和雙時態數據模型的結合，造就了T-TDSQL。

1.T-TDSQL的核心技術一，數據模型

在這個模型中，全態數據體如今了數據項的歷史版本上；時態數據不只有事務時態、還有有效時間時態。而全態數據的歷史態數據，不只能夠追溯數據庫系統的操做發生時間，還能夠追溯發生的操做類型，以下圖中的「Operation」列，能夠知道在數據項上曾經發生的DML操做是UPDATE仍是INSERT仍是DELETE。這是一個很是酷的特性，這使得用戶在T-TDSQL系統中能夠實現「一切過往兼可追溯」的夢想。

2.T-TDSQL的核心技術二，歷史數據轉儲時機

歷史數據的存儲時機，是T-TDSQL的另一個核心技術。

T-TDSQL用全態的數據概念，巧妙地利用MySQL的回滾段和Purge機制，實現了歷史態數據的轉儲。一個原理圖以下：

3.T-TDSQL的核心技術二，一致性快照點

在PostgreSQL中，若是實現本技術，能夠考慮結合多版本的存儲特色，實現當前態數據與歷史態、過渡態的存儲分離，這須要修改已有的數據可見性判斷算法、頁面存儲格式、數據的合併時機、緩衝區的讀寫和heap的構造方式等，更重要的是要實現新的數據一致性快照點。

而T-TDSQL基於MySQL實現了新的數據一致性快照點的構建，於是能夠獲取任什麼時候間段（包括歷史發生過的時間）上的任何狀態的數據。

做爲原創技術，T-TDSQL的核心技術點及其思路，相關論文已經在World Wide Web journal上以題爲《Efficienttime-interval data extraction in MVCC-based RDBMS》發表，詳情可參見：

https://link.springer.com/article/10.1007/s11280-018-0552-7

4、T-TDSQL的典型應用

時態信息處理已經成爲許多新一代數據庫與信息系統的關鍵技術，特別是在金融領域、電子商務、數據倉庫、地籍管理系統、土地利用規劃系統、地理信息系統中扮演着日益重要的角色。

電子商務、金融業務系統中，存在大量的收入、支出、餘額等數據，而且隨着業務的推動，新數據源源不斷地產生，這些數據將在對帳、審計、用戶畫像等業務中發揮重要做用。經過實現事務時態功能，T-TDSQL能快速、精細、實時地獲取這些數據。

在互聯網金融業務中，對帳業務是一個經典的業務。

T-TDSQL爲騰訊的計費對帳業務提供了完美的解決方案。

1.對帳業務

互聯網金融行業對數據的準確性要求極高，而在互聯網環境中，數據不一致或數據錯誤時有發生，所以，經過對帳來下降帳戶餘額等數據錯誤形成的風險十分重要。

在騰訊計費業務中，採用將帳戶餘額表(user)和帳戶流水錶(water)按小時/天爲週期進行比對的方式，來發現帳戶餘額與交易流水的不一致現象，從而及時對錯誤交易進行修正。

傳統的對帳採用按固定時間段（如分鐘/小時/天）爲單位進行對帳。如現對2018年4月11日的交易進行對帳，首先須要獲得4月11日期初帳戶餘額表和期末帳戶餘額表，以及當天的交易流水錶；而後對帳戶表經過按用戶ID分組，並計算每一個用戶的期末餘額減去期初餘額，記爲結果A，對流水錶按用戶ID分組，並將交易金額分組求和，記爲結果B；最後將每一個用戶的結果A和結果B進行比對，若是A=B，則交易沒有問題，不然該用戶在當天的交易存在錯誤。

對於按固定時間段對帳，主要存在如下三個問題：

時效性差：對於錯誤交易，不能當即發現並反饋，延遲了以固定時間段爲單位的一段時間後才能發現錯誤。
對帳不精準：定位錯誤交易較複雜。例如：若是用戶在一天內發生的多筆交易，其中一筆出現了錯誤，經過按天對帳的方式不能直接定位到具體的哪條交易出現錯誤，而只能定位到用戶級別，即仍然須要人工參與，將該錯誤用戶的當天交易都確認一遍，才能找到具體的錯誤交易。
對帳不靈活：按固定時間段對帳，如以天爲單位，則只能等這一天內的增量數據沉澱下來，才能進行對帳，若是有跨天對帳需求（如昨天下午至今天上午），對帳所用數據須要跨多個表才能執行，這可能改變對帳業務的流程。

2.對帳優化

基於本文提出的數據模型和增量計算方法，能夠很好的解決按天對帳所存在的問題。結合3.1.2中的示例，咱們給出在互聯網金融的對帳業務中，增量計算的實際應用。

T-TDSQL能夠基於增量計算的功能將帳戶餘額表(user)和帳戶流水錶(water)進行精準比對，進行流水級別的細粒度對帳，從而即時發現交易錯誤，並能夠當即定位到錯誤的那一條交易，省去繁雜的錯誤交易定位過程。

優化後的對帳的核心思想是：總帳算摘要、細帳筆筆精。

優化後的對帳的效果是：總帳快對、細帳精確、不受時限、任意對帳[1]。

對帳步驟1—總帳對帳：首先讀取給出對帳時間段[s_start,s_stop]內的全部帳戶表數據塊，對每一個數據塊內數據採用與傳統對帳方式相似的公式來確認帳戶狀況，即進行「總期末餘額-總期初餘額=總交易變更」試算[2]，總期初餘額表明s_start時的總餘額，總期末餘額表明s_stop時的總餘額，總交易變更表明每塊內帳戶對應產生的流水，若是有數據塊內的總帳不平，意味着有細帳錯誤，所以要進行步驟二、3所描述的精準對帳。

對帳步驟2—精準對帳—對帳過程：執行以下SQL，將帳戶餘額塊和對應帳戶流水塊進行「快照差鏈接」，返回結果集中每條記錄將含有{交易前餘額，交易後餘額，交易變更}。對應的執行效果圖下圖所示：

精準對帳示意圖

對帳步驟3—精準對帳—精準之意：對步驟2結果裏的每一條返回記錄進行「交易後餘額-交易前餘額=交易變更」的試算[3]（After-Before=Change），便可確認交易是否有誤。若是有不知足此等式的狀況存在，即爲錯誤交易。

錯誤交易主要分爲帳戶表錯誤和流水錶錯誤兩種。例如，上圖中，結果集中第2條元組，不知足試算公式，代表流水ID爲2的交易進行了錯誤的賬戶餘額更新或流水記錄的交易變更值出錯。結果集中的第4條元組，Change字段的值爲NULL，表明該條交易的流水缺失。經過上圖中的表，咱們對各類錯誤狀況進行總結，這些錯誤，都須要在對帳過程當中進行報警。

3.有效時間的時態類應用

基於T-TDSQL的全時態核心技術，本次分享還從雙時態的角度對典型應用作了介紹。以下圖所示。

4.數據安全類應用

基於歷史狀態查詢這一特性，T-TDSQL系統在數據訂正、歷史追蹤等方面，提供靈活強大的數據安全保障功能，能夠大大簡化和加快審計、對帳等業務。

查詢時間段內插入的數據，用於數據統計和追蹤，如統計新開帳戶、異常記錄什麼時候被添加等。

查詢時間段內刪除的數據，在安全保障和數據統計等方面做用顯著，如恢復誤刪的數據、統計銷戶人數等。

查詢時間段內更新的數據，可以追蹤數據異常的發生時間和發生異常前的數據，用於數據異常的修復。

綜合查詢全部狀態的歷史態數據，在數據重演方面，能夠輔助災後恢復，或用於線下演練；數據統計方面，因支持任意時空節點的數據計算，對對帳等業務大有裨益；安全保障方面，簡化了錯誤數據、誤刪數據的追蹤和恢復。

以下是一些安全方面的示例：

除此以外，基於全時態態數據，實現數據重演、更有價值的數據分析和挖掘、使用AI技術對系統自動調優等成爲可能。

5、T-TDSQL的核心理念，爲數據賦能

爲何T-TDSQL要去實現全時態數據庫？

原創技術的背後，是什麼在驅動着T-TDSQL團隊作出這樣的一個全時態數據庫系統？

這些問題，其實更爲重要。挖掘這些問題的緣由，爲倡導原創而努力，當是TDSQL團隊致力於技術分享時更看重的價值因素。

在TDSQL團隊看來，「數據富有價值，歷史數據富有價值」。在業務當中，挖掘數據的價值是很是重要的一環，這也是不少人在思考的內容，認爲任何數據都有價值是頗有意義的。

所以，T-TDSQL項目的思考以後的觀點是「Historical data are valuable. Business is a sword, Technology is only ashield.」。那麼，什麼是盾？什麼是劍？盾和劍之間有什麼關係呢？

在TDSQL看來，技術只是一個防守工具，用於把夢想變成現實。夢想是技術人想利用各類高大上、高精尖的技術解決現實問題的美好願景，諸如分佈式、一致性、快照、RDMA、NVM、AI、全數據挖掘等各類技術的炫酷使用。業務只是一個進攻的工具，用於發現夢想。TDSQL並不倡導業務爲王的觀點，而是左手盾右手劍，兩手都要硬。但僅是左手盾右手劍，行走在技術的江湖，這隻能成就技術人行俠仗義的夢想。其背後，還缺乏靈魂的支柱。

而歷史數據富有價值，在（金融/騰訊/互聯網/一切…）業務中，挖掘數據的價值，更是富有意義。

可是，百尺竿頭更進一步。

數據的創造是由用戶和其業務決定的，他們是創造數據的甲方。數據庫承載了數據的管理職責，是否數據庫系統也能夠參與到數據的創造環節中來呢？

在TDSQL團隊看來，全時態這一律念，正是數據庫系統參與到數據創造環節的最佳契機。數據庫系統爲數據賦於了事務時態、賦於了DML操做過程當中的事件源，甚至可能爲數據之間賦於關聯關係（以下圖中的5W、Lineage），這使得數據庫系統也成爲了數據的創造者。

這就是咱們、TDSQL團隊在技術和業務背後的驅動要素：「爲數據賦能」的理念。

在「爲數據賦能」這個理念的支撐下，基於TDSQL的T-TDSQL所以而誕生。爲數據賦能，於是能讓數據擁有更多的價值，讓數據庫變成數據的生產者，參與數據的創造。下圖代表，爲數據賦能，T-TDSQL從5W角度，讓數據擁有了時間（雙時態，WHEN）、地點（存儲的歷史表，WHERE）、人物（用戶ID，WHO）、對象（全態數據，WHAT）、緣由（DML等操做，WHY）等要素，使得數據再也不僅僅是用戶使用CREATETABLE語句所建立的數據，而是包含了多種由數據庫系統所創造的數據、且在數據的生命週期中融入了數據歷史使其富有縱深的有價值的所有數據。

有了這些，數據庫系統可以更加主動地追溯數據的歷史，推演數據的變遷，預測數據（世界）的將來。