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

PingCAP 發表於 2022-01-25
參加 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 分析了運用該專案後的成本變化:

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

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


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

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

該專案解決了什麼問題?

He3 開發的 TiDB 冷熱資料分層儲存專案,能夠以極簡的方式實現冷熱資料分離:

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

針對普通表:實現 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 測試。
極簡實現 TiDB 冷熱資料分層儲存 | He3 團隊訪談

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 還希望在迭代到一定程度後就將整個產品的程式碼提交給社群,用開源的方式回饋社群,大家一起共創。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69994146/viewspace-2853904/,如需轉載,請註明出處,否則將追究法律責任。

相關文章