歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~

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

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

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

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

一、 TDSQL概述

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

TDSQL分散式事務處理技術，有了長足進步，不僅表現在基於XA實現了2PC以支援分散式事務的原子提交，而且在MVCC技術的基礎上，做了創新，使得TDSQL的事務處理技術基於原創技術而不斷髮展。

二、原創技術的出發點

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

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

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

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

對賬主要是解決幾種異常情況：

1. 系統存在BUG，或者在故障時，未表現出預期的情況。這可能導致發貨成功扣款不成功，或者扣款成功未發貨的情況。如騰訊視訊VIP管理系統的充值、發貨。

2. 規避黑客/內部風險。例如不法人員繞過業務系統去給自己充值等舞弊行為。

這樣的對賬業務種類很多，不同的應用其日誌流水格式不完全相同，TDSQL託管的賬戶需要定時對多級數千種業務和賬戶做資料一致性對賬檢驗。

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

1. 應用開發複雜：使用業務日誌，需要業務系統不斷產生日誌資訊，然後耗費計算資源對不同的日誌格式進行解析，把日誌資訊儲存到分析系統。由此帶來了開發的負擔和資源的浪費。

2. 資料邏輯割裂：TDSQL中按時間分表，只能按確定的時間段進行結算，不能靈活、方便的計算。如計算任意時間段內的資料，按時間段的分表在物理上割裂了資料按時間的邏輯連續特性，需要指定若干個特定的分表才能進行計算。

3. 實時特性丟失：如上兩個問題，隱含地，意味著進行計算的資料需要匯入到一個新的分析系統進行計算，匯出/匯入資料的過程也帶來了資源和時間的消耗、使得分析系統難以具備實時計算特性。

4. 資料管理複雜：另外，日誌等資訊，是歷史態資料，需要長期儲存。在騰訊公司每日對不同格式的、超過150億條流水日誌進行生成、儲存、解析與管理等，這成為一個巨大的挑戰。

現代的資料庫系統只保留有資料的當前值，而因儲存成本等原因，歷史態資料被丟棄。而資料作為重要的資產，不管是當前資料，還是歷史上曾經存在過的資料，都具有重要價值。因此，歷史態資料儲存、被分析、被挖掘、被反覆使用，是當前網際網路等企業的需求。尤其是金融類歷史態資料，因為安全、需要被多次計算的原因，在騰訊公司的計費業務中，帶有時態屬性的資料被管理的需求日益旺盛。

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

業務痛點的解決，是基於資料庫的特點和業務場景進行深入分析和思考而得以解決的。

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

TDSQL認為：

資料的狀態屬性，標識資料的生命週期軌跡。資料的生命週期分為三個階段，每個階段刻畫資料的不同狀態屬性，以標識資料的生命週期軌跡中所處的狀態。

1. 當前態（Current State）：資料項的最新版本的資料，是處於當前階段的資料。處於當前階段的資料的狀態，稱為當前態。

2. 歷史態（Historical state）：資料項在歷史上的一個狀態，其值是舊值，不是當前值。處於歷史階段的資料的狀態，稱為歷史態。一個資料項的歷史態，可以有多個，反映了資料的狀態變遷的過程。處於歷史態的資料，只能被讀取不能再被修改或刪除。

3. 過渡態（Transitional State）：不是資料項的最新的版本也不是歷史態版本，處於從當前態向歷史態轉變的過程中。處於過渡態的資料，稱為半衰資料。

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

1. 當前態：MVCC或封鎖併發訪問控制機制下，事務提交後的資料的新值處於當前態。

2. 歷史態：MVCC機制下，當前活躍事務列表中最小的事務之前的事務生成的資料，其狀態處於歷史態。在封鎖併發訪問控制機制下，事務提交後，提交前的資料的值變為歷史態的值，即資料項的舊值處於歷史態。

3. 過渡態：MVCC機制下，被讀取的版本上尚有活躍事務（非最新相關事務）在使用，因最新相關事務修改了資料項的值，其最新值已經處於一個當前態，被讀取到的值相對當前態已經處於一個歷史狀態，故其資料狀態介於當前態和歷史態之間，所以稱為過渡態。

資料的雙時態屬性，分別為有效時間屬性、事務時間屬性。

有效時間屬性表示資料表示的物件在時間屬性上的情況。如Kate中學起止時間是2000-09-01到2003-07-30，而大學起止時間是2003-09-01到2007-07-30，這裡的時間就是有效時間。

事務時間屬性表示資料的某個狀態的時間發生時刻。資料具有其時態屬性，即在何時資料庫系統進行了什麼樣的操作。某項操作在資料庫系統內被封裝為事務，而事務具有原子性。因此，我們採用了事務標誌來標識一個資料的事務時態屬性。

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

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

因此，基於TDSQL的T-TDSQL時態資料庫，有了如下的特性，這些特性，能夠涵蓋雙時態的資料應用、資料安全、資料分析、簡化應用開發等四大方面的問題：

三、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

四、T-TDSQL的典型應用

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

電子商務、金融業務系統中，存在大量的收入、支出、餘額等資料，並且隨著業務的推進，新資料來源源不斷地產生，這些資料將在對賬、審計、使用者畫像等業務中發揮重要作用。通過實現事務時態功能，T-TDSQL能快速、精細、實時地獲取這些資料。

在網際網路金融業務中，對賬業務是一個經典的業務。

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

1.對賬業務

網際網路金融行業對資料的準確性要求極高，而在網際網路環境中，資料不一致或資料錯誤時有發生，因此，通過對賬來降低賬戶餘額等資料錯誤造成的風險十分重要。

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

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

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

1. 時效性差：對於錯誤交易，不能立即發現並反饋，延遲了以固定時間段為單位的一段時間後才能發現錯誤。

2. 對賬不精準：定位錯誤交易較複雜。例如：如果使用者在一天內發生的多筆交易，其中一筆出現了錯誤，通過按天對賬的方式不能直接定位到具體的哪條交易出現錯誤，而只能定位到使用者級別，即仍然需要人工參與，將該錯誤使用者的當天交易都確認一遍，才能找到具體的錯誤交易。

3. 對賬不靈活：按固定時間段對賬，如以天為單位，則只能等這一天內的增量資料沉澱下來，才能進行對賬，如果有跨天對賬需求（如昨天下午至今天上午），對賬所用資料需要跨多個表才能執行，這可能改變對賬業務的流程。

2.對賬優化

基於本文提出的資料模型和增量計算方法，可以很好的解決按天對賬所存在的問題。結合3.1.2中的示例，我們給出在網際網路金融的對賬業務中，增量計算的實際應用。

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

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

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

對賬步驟1—總賬對賬：首先讀取給出對賬時間段[s_start,s_stop]內的所有賬戶表資料塊，對每個資料塊內資料採用與傳統對賬方式類似的公式來確認賬戶情況，即進行“總期末餘額-總期初餘額=總交易變動”試算[2]，總期初餘額代表s_start時的總餘額，總期末餘額代表s_stop時的總餘額，總交易變動代表每塊內賬戶對應產生的流水，如果有資料塊內的總賬不平，意味著有細賬錯誤，因此要進行步驟2、3所描述的精準對賬。

對賬步驟2—精準對賬—對賬過程：執行如下SQL，將賬戶餘額塊和對應賬戶流水塊進行“快照差連線”，返回結果集中每條記錄將含有{交易前餘額，交易後餘額，交易變動}。對應的執行效果圖下圖所示：

精準對賬示意圖

對賬步驟3—精準對賬—精準之意：對步驟2結果裡的每一條返回記錄進行“交易後餘額-交易前餘額=交易變動”的試算[3]（After-Before=Change），即可確認交易是否有誤。如果有不滿足此等式的情況存在，即為錯誤交易。

錯誤交易主要分為賬戶表錯誤和流水錶錯誤兩種。例如，上圖中，結果集中第2條元組，不滿足試算公式，表明流水ID為2的交易進行了錯誤的帳戶餘額更新或流水記錄的交易變動值出錯。結果集中的第4條元組，Change欄位的值為NULL，代表該條交易的流水缺失。通過上圖中的表，我們對各種錯誤情況進行總結，這些錯誤，都需要在對賬過程中進行報警。

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

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

4.資料安全類應用

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

查詢時間段內插入的資料，用於資料統計和追蹤，如統計新開賬戶、異常記錄何時被新增等。

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

查詢時間段內更新的資料，能夠追蹤資料異常的發生時間和發生異常前的資料，用於資料異常的修復。

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

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

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

五、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語句所建立的資料，而是包含了多種由資料庫系統所創造的資料、且在資料的生命週期中融入了資料歷史使其富有縱深的有價值的全部資料。

有了這些，資料庫系統能夠更加主動地追溯資料的歷史，推演資料的變遷，預測資料（世界）的未來。

六、致謝

本專案在騰訊立項，研究內容和實現過程得到中國人民大學教育部資料工程和知識工程重點實驗室和騰訊公司的參與和支援，特別向專案參與人、支持者致謝。

為從思維、理念、技術等多個角度為本專案做出貢獻的人致敬！

[1]不受時限、任意對賬：對賬的SQL語句中指定快照差即可，FROM子句中涉及的表名等不發生變化，即對賬使用的資料來源沒有改變，故不影響對賬流程。

[2]試算(Spreadsheet)為會計程式中其中的一個流程，它簡單的定義就是在檢查日記簿的所有交易分錄的借方、貸方金額是否有錯誤之情形。但是在做試算檢查時，應每筆交易分錄紀錄後即做此一動作。

[3]試算(Spreadsheet)為會計程式中其中的一個流程，它簡單的定義就是在檢查日記簿的所有交易分錄的借方、貸方金額是否有錯誤之情形。但是在做試算檢查時，應每筆交易分錄紀錄後即做此一動作。

此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1122906?fromSource=waitui

歡迎大家前往騰訊雲+社群或關注雲加社群微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~