極簡實現 TiDB 冷熱數據分層存儲 | He3 團隊訪談

參加 Hackathon 可以接觸到內核、工具、生態各個領域中志同道合的小夥伴，通過他們的項目學習到非常好的創意。大家的想法都很奇妙，充滿了創新力，在平時的研發過程中，很少能接觸到這些，Hackathon 能夠幫助我們打開思維，讓我們知道原來 TiDB 還可以這麼玩。

—— He3 團隊

TiDB 在使用過程中，隨著用戶數據量的持續增長，存儲成本在資料庫總成本中的占比將會越來越高。如何有效降低資料庫存儲成本擺在了許多用戶面前。

在眾多解決方案中，有一種方法是將冷熱數據實現分層存儲。在絕大部分場景中，數據其實都可以分為 「冷數據」 和 「熱數據」。數據劃分的原則，可以根據時間遠近、熱點/非熱點用戶等等。用戶通常隻拜訪一段時間之內的數據，例如近一周或一個月。如果數據不做劃分，必然會導致一定程度上的性能、成本損耗。

在剛剛收官的 TiDB Hackathon 2021 中， He3 團隊就選擇了冷熱數據分層存儲來降低 TiDB 的存儲成本。他們在設計中將熱數據存放在 TiKV 上，將查詢和分析幾率比較少的冷數據存放到便宜通用的雲存儲 S3，同時使 S3 存儲引擎支持 TiDB 部分算子下推，實現 TiDB 基於 S3 冷數據的分析查詢。項目獲得了評委的一致好評，力奪本屆賽事的一等獎。

這個項目為後面 TiDB 與 S3 的整合打下不錯的基礎，在這次 Hackathon 驗證了可行性。它的原理其實很簡單，將冷的數據放到 S3，將算子盡量下推到 S3，通過 S3 原生的 select 功能加速查詢。當然，如果數據已經在 S3，還可以通過 Cloud 上其他的服務，譬如 Athena， 來做更多的查詢聚合操作，加速查詢。這次大家都是在通過 partition 做文章，畢竟根據時間片來分的 partition 是非常常用的一種操作。我們內部現在也在通過 LSM 做一些跟 S3 整合的研究，我還是很期待這些都能在今年看到不少的成果產出。譬如 TiDB Cloud dev tier 集群就可以完全用這套機制來驗證。

—— 評委唐劉點評

為什麼選擇冷熱數據分層存儲這個方向？

He3 團隊的隊長薛港，隊員時丕顯、沈政，都是來自移動雲資料庫團隊的研發工程師，三人平時的工作就是從事雲資料庫服務的開發，降低用戶在雲上使用資料庫的成本是他們一直追求的目標。

在去年 7 月份的 Hacking Camp 中，He3 就曾基於 TiDB 實現了提供 Serverlessdb 服務的 Serverlessdb for HTAP 項目。用戶在使用 TiDB 時可以按使用量付費，不用再像傳統 RDS 需要包年包月，大大降低了用戶使用 TiDB 的成本。該項目也因此獲得了 Hacking Camp 優秀畢業生和最佳應用獎。

隨著產品在移動雲上的落地，很多用戶在使用了一段時間後發現隨好康據量的增加，存儲成本越來越高。薛港解釋道，在公有雲上，塊存儲收費比 S3 對象存儲要高很多，用戶部分場景的數據其實很多是冷數據，完全可以存放在 S3 上。於是在去年 12 月份時，他們就開始思考如何降低 TiDB 的存儲成本。恰好這時 TiDB Hackathon 2021 啟動了，薛港和時丕顯、沈政一商量，就決定將冷熱數據分層存儲作為今年的比賽項目。在答辯時，他們專門用了一頁 PPT 分析了運用該項目後的成本變化：

項目方向定了，接下來就該報名了。隊長薛港在看電視的時候對氦 -3 這種元素產生了興趣，經過了解，發現它可以用作核聚變燃料，比現有的核燃料能量更大，並且只有很少的放射性，是一種清潔高效安全的發電燃料。這種特性和他們對分布式雲資料庫的期望完全一致 —— 安全、高性能、易用、價格便宜，於是 He3 便成了隊名。

在接下來不到一個月的時間中，薛港作為隊長負責整體需求的確認、架構設計、方案驗證以及具體框架的開發。其他隊員主要負責功能開發，時丕顯負責算子下推與數據類型支持，沈政重點在性能優化以及 TPC-H 測試。

該項目解決了什麼問題？

He3 開發的 TiDB 冷熱數據分層存儲項目，能夠以極簡的方式實現冷熱數據分離：

針對普通表：實現 insert into select 的方式完成冷熱數據分離：

• 支持創建 S3 外部表；
• 支持通過 insert into s3_table select from tikv_table where … ，把 TiKV 內部表的數據轉儲到 S3 對象存儲上；
• 支持通過 insert into tikv_table select from s3_table where … ，把 S3 外部表的數據轉儲到 TiKV 內部表。

針對分區表：自動完成分片表轉化成 S3 外部表，保留主表和 S3 外部表的主從關係。

支持通過 Alter 分區表操作，把 TiKV 內部分區表的數據自動轉儲到對應的 S3 外部表中，自動完成以下幾件事：

• 內部 TiKV 分區表數據轉存到 S3 對象存儲中；
• 更改分區表元數據，把 TiKV 內部分區表轉化成 S3 外部表，核心要點保留 S3 外部表和主表的分區關係；
• 刪除 TiKV 內部分區表數據。

轉換後 S3 外部分區表對用戶完全透明，對用戶來說，S3 外部表就是主表的一個分片表。例如針對主表的查詢結果包含部分 TiKV 內部分片表以及部分 S3 外部表對應的分片表數據，那麼返回的結果就會來自兩部分：TiKV 內部分片表，以及 S3 外部表。

保證用戶使用 S3 外部表和 TiKV 內部表沒有任何區別：

• S3 外部表支持所有的數據類型；
• S3 外部表支持所有的算子；
• 優化 S3 外部表操作性能在用戶可接受的範圍內。

通過支持謂詞(邏輯運算、比較運算、數值運算），聚合函數、Limit 等算子下推到 S3 節點，利用 S3 的計算能力提升查詢性能。

為了達到期望所有效果，He3 在此次 Hackathon 中開發修改了 TiDB 一些模塊：

SQL Parser 模塊、系統表模塊

• 增加一個新的系統表，用於保存 S3 元數據， 每一筆記錄對應一個 S3 存儲元數據：包含 S3 的 endpoint, access key, secret key， s3 bucket。insert into mysql.serverobject values(“s3object”,”http://192.168.117.220:9000″,”minioadmin”, “minioadmin”,”s3bucket”)；
• 支持創建外部表，相比普通表增加了 s3option 選型，對應 S3 元數據對象，外部表對應 S3 的存儲路徑：Bucketname/DBName/TableName create table s3_table(id1 int8,id2 char(30)) s3options s3object；
• 支持分片表自動轉換成 S3 外部表

Alter table employees alter partition employees_01 s3options s3object

執行器模塊

• 能夠區分操作表是否是 S3 外部表，如果是外部表，寫入時，數據以 256M 為粒度保存到 S3 的一個對象中 , 當查詢 S3 外部表時，S3 對象會被以流式的方式裝配到 chunk 中，以支持上層算子操作；
• 支持算子下推到 S3 節點，利用 S3 節點的計算能力加速 S3 外部表的性能；
• S3 外部表支持所有的數據類型，存儲在 S3 的數據按 S3 外部表的 schema 對應的數據類型保存到 chunk 裡，相幹列都會基於數據類型編碼；
• 支持 Alter 實現內部分片表數據自動轉儲到 S3 外部表中，同時保留主表和 S3 外部表的主從關係不變。

優化器模塊

少量無法下推 S3 的算子，He3 修改了優化器阻止這部分算子下推。當前不支持的算子，主要就是包含 TopN 算子。

來自性能測試的挑戰

He3 最初設定的目標有兩個：一是希望數據能夠以比較簡單的方式直接實現冷熱數據分離；二是希望冷數據分離到 S3 後，它的查詢性能能夠在合理的時間範圍內。所以一開始就把跑通 TPC-H 作為目標。

項目的冷熱數據分離功能很快就完成了開發，但是接下來他們遇到了一個最大的問題——性能總是無法達標。一開始的方案設計是將全部數據都讀取到 TiDB 上集中處理，但在測試中發現即使只有 10GB 的數據，TPC-H 也跑不出來。三名隊員通過討論、調研、分析，發現 S3 其實也具備一定的計算能力，是否可以把部分計算下推到 S3 ，讓 S3 和 TiKV 一樣能夠承載部分計算？

改變方案後通過幾個場景算子下推，He3 發現性能提升非常明顯，在之後的開發中就將能下推的算子全部下推，項目的整個性能優化每天都會以 20% 的幅度在提升。最終在比賽日上，他們跑通了整個 TPC-H 測試。

He3 在 Hackathon 中的 TPC-H 測試成就

此次 Hackathon 中，其實還有另一支賽隊 Interstellar 也選擇了分層存儲，這也給 He3 隊員們留下了一個有趣的畫面：在 Interstellar 開始答辯時，He3 以為是自己在投屏，手忙腳亂地到處找關閉投屏按鈕，直到對方開始答辯了，他們才意識到原來是兩個隊伍的題目撞衫了。

本次參賽的心路歷程

He3 隊員們其實在去年也參加了 TiDB Hackathon，因為剛接觸 TiDB ，並沒有碰內核。當時心中就埋下一個想法，下次參賽一定要做夠硬的項目。這也是薛港在畢業後就給自己樹立的目標 —— 做資料庫內核，並認為這是一件很酷的事情。於是在今年比賽中， He3 選擇了最硬核的賽道 —— 內核組。

過去一年的工尷尬刁難他們幫助非常大，由於三人平時的工作和 TiDB 結合非常多，在碰到問題的時候就會去想有什麼解決方案，這個過程中很容易產生各種好的 idea。例如這次如何降低 TiDB 存儲成本的問題，他們當時就想出了至少三種方案：第一種是將 TiDB 底層的編碼方式做一些改變，讓 TiDB 的整個壓縮比能夠再下降 50% – 60%；第二種也是一種冷熱數據分離方案，將 LSM-tree 和 S3 集成；第三種就是現在的冷熱數據存儲分層方案。但前兩種方案在 Hackathon 如此短的周期內很難完成，於是他們就採用了第三種方案。

未來， He3 還會從三個方向將該項目持續演進、迭代：

• 通過新的編碼方式以及加速算法，降低數據在 S3 的存儲容量，基於本次比賽中實現的效果再降低 50% 的存儲容量；
• 持續優化 TiDB 對接 S3 的存儲差異性能，在這次比賽的後期，這塊性能每天都有 20% 的性能提升，He3 認為這裡其實還有很大的提升空間；
• 進一步簡化用戶的冷熱數據分離方式。對這次項目的最終實現， He3 其實還有一些遺憾，一開始設計的時候他們想過現在冷熱數據分離還需要 DBA 來做一些操作，如果能將這個工作進一步實現自動化操作，就可以讓冷熱數據分離應用性再上一個臺階，不過由於時間比較有限的原因沒能實現。

此外，除了項目本身繼續完善外，He3 還希望在迭代到一定程度後就將整個產品的代碼提交給社區，用開源的方式回饋社區，大家一起共創。