TDengine Contributor 鍾宇講述 TSZ 壓縮演算法最佳化背後的故事
TSZ 壓縮演算法是 TDengine 提供的一種可選壓縮演算法,專門用於浮點資料型別。它具有出色的壓縮效能,能夠在有損和無損狀態下都提供更高的壓縮率,甚至比預設壓縮演算法高出一倍,滿足更高的資料儲存需求。利用資料預測技術,TSZ 壓縮演算法更適合處理有規律變化的資料,如時序資料。但需要注意的是,由於其高效的壓縮方法,TSZ 壓縮可能需要更多的時間來執行,因此在 CPU 資源充裕且儲存空間有限的情況下使用效果更佳。
最近,我們就有一條關於“TSZ 壓縮演算法”的“新聞”要和大家分享。
不久前,我們收到了這樣一條訊息,訊息傳送者是來自華中科技大學,武漢光電國家研究中心的碩士研究生鍾宇。在該訊息中,他表示在他們近期的一篇名為《ADT-FSE:A New Encoder for SZ》的學術論文中,針對 TDengine TSZ 壓縮演算法進行了相關改進。隨後鍾宇將這部分開原始碼分享在了 TDengine 的 Github 社群上,成為了 TDengine 開源社群的又一名貢獻者。
為了讓更多富有開源精神、關注 TDengine 的小夥伴們瞭解到這段故事更為詳細的一面,我們對鍾宇進行了一次深入採訪,他將從為何選擇 TDengine 作為研究物件之一、TSZ 壓縮演算法的具體最佳化工作以及參與開源的感受等諸多方面展開分享。
採訪實錄
1、請介紹一下你自己。
感謝邀請,我來自華中科技大學,現在是武漢光電國家研究中心的一名研三碩士。我目前在吳非教授帶領的“磐石新型非易失儲存系統實驗室”(NNSS)課題組。我個人的研究方向主要包括 NVMe 固態盤、壓縮演算法等。22 年 7~9 月份,我在深圳大普微實習期間,與公司的呂濤博士合作完成了最佳化浮點壓縮器 SZ 的論文《ADT-FSE: A New Encoder for SZ》,這篇論文已被收錄在今年的 SC 會議中,SC 是 CCF 認證的超算和儲存領域的頂會。文章中 TDengine 作為時序資料庫(Time Series Database)領域的代表,成為 SZ 演算法應用的一個重要場景。
2、什麼契機讓你接觸到 TDengine,成為 TDengine 的貢獻者?
首/次接觸到 TDengine 是在 SZ 研究開始時,當時聽聞另一位學長準備在畢業設計做有關 TDengine 的研究,在討論時瞭解到 TDengine 中引入了 SZ(即 TSZ)模組,並且整合在開原始碼中。時序資料庫作為一個有前景的、快速發展的領域,一直是我們團隊想要開拓的方向,而 TDengine 在開源社群中的影響不小,並且一個開源且成熟的專案對於我們搞學術研究來說非常友好,因此我們也認為這是一個非常良好的契機。
3、為什麼決定進行 TSZ 壓縮演算法的最佳化工作,最佳化結果如何?詳細描述下原因
因為 SZ 作為一個業界領先的有損浮點壓縮器,其實一直有一個缺點,這一點在 SZ 的開原始碼庫的 README 中也有說明——“SZ 不適合壓縮非常小的檔案”,而在資料庫中,資料通常被切分為小塊進行儲存,例如 TDengine 中預設 4096 行資料為最小儲存單元,如果使用單精度浮點型別(float)儲存,則儲存單元為 16KB。這個大小對於 SZ 動輒壓縮數百 MB 甚至數 GB 的資料來說,已經非常小了,而我們在測試中也發現 SZ 在壓縮該大小的檔案時,出現了壓縮比大幅下降、壓縮解壓緩慢等問題。
我們在大量的測試和量化分析後發現,SZ 壓縮中使用的傳統 Huffman 演算法成為了導致該問題的主要瓶頸,傳統 Huffman 演算法在壓縮結果中儲存一顆 Huffman 樹,以便解碼時能還原出原資料。通常在壓縮大檔案時 Huffman 樹的大小可以忽略不計,但我們的測試表明這顆樹所佔用的空間在小檔案下顯得不可忽略,這是問題的關鍵。
最終我們提出了 ADT-FSE 演算法來替換傳統 Huffman 演算法,這是一種轉碼+壓縮的方式,對原資料進行了一步轉碼,而後使用更先進的熵編碼 FSE 演算法來進行壓縮,完全摒棄了 Huffman 樹的消耗,不僅可以提升小檔案壓縮下的壓縮比,還能提升壓縮解壓速度。在我們的測試中,ADT-FSE 使得 SZ 的解壓速度快了 2x~8x,在 TDengine 中的壓縮比提升了最高 5x。
4、在整個最佳化過程中有沒有遇到一些棘手的問題?如何破解的?
起初對於採用何種演算法替代傳統 Huffman 演算法是難以確定的,我們嘗試了直接使用通用壓縮器 Zstd,或者熵編碼 FSE 替代,但其效果都不是最/佳,在一些情況下會比原始演算法更差。最後我們是在另一個專案的開發中,發現 Zstd 內部有一種壓縮大範圍整數的思路,即先轉碼後壓縮。受其啟發,我們透過對 SZ 的資料進行分析,並對該思路進行學習、改進,最終才提出了最優的 ADT-FSE 演算法。
在 TDengine 場景下的評估中,使用何種資料進行測試也是一個難題,因為我們並沒有接觸過真實場景的時序資料,另外 SZ 更適合壓縮連續性較強的資料。最終我們選擇了同樣開源發表的 UK-DALE 資料集,其記錄了真實家庭用電的電壓資料。
5、你是什麼時候開始關注開源參與開源專案的?你認為開源帶給了你哪些幫助?
從本科期間開始,開源專案一直是我以及身邊的同學們關注的重點。作為學生,開源是我們重要的學習平臺,包括在 Linux 開源庫中學習作業系統底層原理,在 fio、liburing 庫中學習 I/O 相關知識,以及在 Zstd 開源庫中學習壓縮原理,等等。這些優秀的開原始碼讓每個人能接觸到真實的場景和演算法,同時也能學習良好的程式設計習慣。
另一方面,在讀研之後,開原始碼也是開展科研工作必不可少的條件。如若沒有開源,對於較簡單的專案而言,可能花幾周、幾個月復現,然後才可以開展研究工作。而複雜的系統則基本沒有條件進行研究。因此我們在選擇課題時,通常會優先考慮已開源的專案。
6、資料庫很少有將叢集版也進行開源的,你如何看待 TDengine 叢集版開源這件事?
TDengine 的開源很成功,我在 GitHub 上看到其有 2 萬多顆星,這在社群中的影響力非常大。我認為開源可以吸引全球範圍內開發者的廣泛參與,集思廣益,對於專案本身的長遠發展來說是有益的。TDengine 叢集版開源,有助於吸收更多先進的、新鮮的血液,同時也使得使用者對 TDengine 的瞭解更透明,增加其信任度。
7、作為 TDengine 的貢獻者,你如何看待 TDengine 目前的發展?對 TDengine 還有哪些建議?
在開發過程中,我與開源社群的管理人員取得了聯絡,並獲得了他們的很多幫助,合作過程非常愉快且充實。我感受到 TDengine 社群是非常健康且活躍的,濤思對於其開源社群的發展非常重視,我個人認為開源的 TDengine 是很有前景的。建議的話,如果有適合開發者的開發文件,比如說介紹模組所在檔案,開發/除錯的高效指令,對於新的開發者來說效率會更高一些吧。
8、你覺得 TDengine 在時序資料庫領域裡的優勢是什麼?
優勢的話除了開源這一點外,在開發過程中感受到的一點是 TDengine 的生態比較豐富,與很多其他的開源專案和工具整合,能夠給使用者提供廣泛的選擇和靈活性。
9、對於自身的發展,未來是如何考慮的?
現在準備碩士畢業後直接工作吧,因為對我來說讀博的時間成本比較大哈哈哈。畢業後可能繼續在儲存領域工作,此前在大普微和阿里雲分別實習了一段時間,期間做的方向都相對比較底層,涉及到儲存介質和軟體層的互動,之後可能也會往儲存基座的方向發展吧。現在正是在應屆生秋招的時候,今年秋招也比較激烈,大家一起加油吧。
寫在最後
近些年來,隨著 TDengine 的產品功能不斷精進、開源影響力逐漸擴大,越來越多的高校研究生和學者選擇將 TDengine 作為研究課題輸出論文,其中有像鍾宇這樣致力於功能改進的,也有很多著重於分析 TDengine 在工業物聯網、智慧園區、自動駕駛、菸草工業等諸多行業的大資料場景下的應用及效能表現。此前為了幫助社群開發者更直接地進行參考和查閱,我們還針對此類論文進行過一次彙總——《關於 TDengine 的論文資料都在這裡了,等你來取!》。
除了這些外部資料之外,TDengine 也在幫助企業使用者改造資料架構過程中,積累了很多實戰經驗,這些經驗大多由企業開發者執筆創作生成了使用者案例,集中發表在 TDengine 的官網部落格上,大家也可作參考。
如果你針對本次採訪還有更深入的問題想要了解,或者想就資料問題諮詢 TDengine 解決方案架構師,可以新增 小T vx:tdengine,詳細說明你的訴求,我們會給與你及時的幫助。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70014783/viewspace-2996230/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 儲存空間緊張?來看 TDengine TSZ 壓縮演算法如何顯著提升壓縮率演算法
- 我們的20年 | 講述雲安全背後的故事
- 從MySQL到POLARDB, 三位CTO講述遷移背後的故事!MySql
- 騰訊首部帕金森病紀錄片,講述醫學AI背後的故事AI
- 網易·世嘉·CA 為您講述《全面戰爭:三國》代理背後的故事
- 蘋果軟體工程師講述“安全碼自動填充”功能背後的故事蘋果軟體工程工程師
- 天刀手游上線,團隊講述背後的武俠江湖故事創作
- xjbz京東電器攜肖戰獻上賀歲大片《後背》,講述冠軍背後的守護故事
- CNN 模型壓縮與加速演算法綜述CNN模型演算法
- 《一念逍遙》團隊成員講述遊戲開發、上線背後故事遊戲開發
- 時間序列資料壓縮演算法簡述演算法
- Redis持久化背後的故事Redis持久化
- dyld背後的故事&原始碼分析原始碼
- GCC編譯器背後的故事GC編譯
- 愛回收IPO背後的新老故事
- RestCloud ETL 社群版背後的故事RESTCloud
- 為什麼《王者榮耀》的音樂讓人過耳不忘? 天美講述遊戲音訊設計背後的故事遊戲音訊
- 郭超:阿里雲Cassandra背後的故事阿里
- 不用解壓docker commit 後的映象壓縮包DockerMIT
- 開發往事:深度講述2010到2015,微信一路風雨的背後
- 蘋果自動駕駛背後的故事蘋果自動駕駛
- 嵌入式—編譯器背後的故事編譯
- 安能物流 All in TiDB 背後的故事與成果TiDB
- 請求 www.baidu.com 背後的故事AI
- 直播預告|1月31日,專家講解BIG-IP Next背後的故事
- 誰來背鍋?自動駕駛車禍背後的故事自動駕駛
- 壓縮演算法一覽演算法
- 壓縮字串《演算法很美》字串演算法
- 更好的 java 重試框架 sisyphus 背後的故事Java框架
- Ceph Reef(18.2.X)之壓縮演算法和壓縮模式演算法模式
- 【前端軼事】Chrome 小恐龍背後的故事前端Chrome
- 編譯器背後的故事(入門練習)編譯
- 聊聊百度搜尋背後的故事
- 開源筆記軟體 Joplin 背後的故事筆記
- 4399《胡偵探傳說》系列背後的故事
- 騰訊與Github的魔幻會面背後的故事…Github
- 前端效能最佳化——啟用文字壓縮前端
- 從《旅行串串》看小遊戲如何講述一個好的故事遊戲