物聯網鄰域近期如火如荼，互聯網和傳統公司爭相布局物聯網。作為物聯網鄰域數據存儲的***時序數據庫也越來越多進入人們的視野，而早在 2016 年 7 月，百度云在其天工物聯網平臺上發布了國內***多租戶的分布式時序數據庫產品 TSDB，成為支持其發展制造，交通，能源，智慧城市等產業領域的核心產品，同時也成為百度戰略發展產業物聯網的標志性事件。

壓縮對于時序數據庫是至關重要的。因為時序數據庫面對的物聯網場景每天都會產生上億條數據。眾所周知，在大數據時代的今天數據的重要性是不言而喻的，數據就是公司的未來。但如果無法對這些時序數據進行很好的管理和壓縮，那將給客戶帶來非常高的成本壓力。

如前文提到的，工業物聯網環境監控方向的客戶，一年產生 1P 的數據，如果每臺服務器 10T 的硬盤，那么總共需要 100 多臺。按照每臺服務器 3 萬來算，一年就需要 300 萬的支出，這還不包括維護人員的成本。

壓縮是個非常大的話題，本文希望能夠先從大的宏觀角度給出一個輪廓，講述壓縮的本質，壓縮的可計算性問題。再從時序數據壓縮這一個垂直領域，給出無損壓縮和有損壓縮各一個例子進行說明，希望能夠拋磚引玉。

壓縮的故事

先來講個有關壓縮的故事，外星人拜訪地球，看中了大英百科全書，想要把這套書帶回去。但這套書太大，飛船放不下。于是外星人根據飛船的長度，在飛船上畫了一個點。這樣外星人心滿意足的返回了自己的星球，因為這個點就存儲了整個大英百科全書。

這個并不是很嚴謹的故事，卻道出了壓縮的本質：用計算時間換取存儲空間。外星人在飛船上畫的點非常有技術含量，可以說是黑科技，代表一個位數非常長的不循環小數。而這串數字正代表了整個大英百科全書的內容。

壓縮的兩個問題

再來回答兩個宏觀的問題，幫助我們認識在壓縮這件事上哪些是我們能做的，哪些是不能做的。

***個問題：是否存在一個通用的壓縮算法(Universal Compression)，也就是說某個壓縮算法能夠壓縮任意的數據。答案是否定的，并不存在這樣的通用壓縮算法。

用反證法可以做個快速的證明。假設存在通用的壓縮算法，也就是說有個壓縮算法，對于長度為 n 的字符串，總能壓縮到長度小于 n 的字符串。總共有 2^n 個長度為 n 的不同字符串;但卻只有 2^n-1 個長度小于 n 的字符串。那么必定存在兩個長度為 n 的字符串 A,B，經過壓縮得到同一個字符串。這樣解壓縮算法沒有辦法正確的解壓。所以假設錯誤，并不存在通用的壓縮算法。

第二個問題：是否能寫出一個函數，輸入字符串，可以得到這個字符串最短表示的長度。答案也是否定的，也就是說我們無法證明某個算法是***的算法。柯爾莫哥洛夫復雜性的不可計算性解釋的就是這個問題。用的也是反證法，有興趣的朋友可以自行百度了解(注 1)。

這兩個問題的答案，告訴我們三件事情，

1. 壓縮算法的選擇需要具體情況具體分析，不可壓縮的字符串總是存在。
2. 不要妄圖獲得***的壓縮算法，它是不可計算的。因為總有你想不到的壓縮算法存在。舉個例子，[一百萬個 0 的字符串，以“foo”作為 key，經過 AES 加密算法的 CBC 模式得到的字符串]。這串字符串看起來完全是隨機的，不可壓縮的。但我卻用 43 個中文(中括號之間的內容)就表示了出來。
3. 壓縮是件很難很有技術含量的事情，需要不斷的挖掘，才能將他做到更好。

時序數據壓縮

針對不同的數據，會有不同的壓縮，大致壓縮的對象可以分為文檔、音頻、視頻等。如果直接采用文檔的壓縮算法用于時序數據，效果并不理想。下圖是一些常用的壓縮算法的 benchmark，可以看到壓縮率那一欄***也只能夠達到 3 左右的壓縮率(壓縮率 = 原始數據大小 / 壓縮后的數據大小)。更多壓縮算法可以查看注 2。

如果要得到更好的壓縮率，我們需要采取更加適合時序數據的壓縮算法。時序數據的壓縮可以分為無損壓縮和有損壓縮。

無損壓縮

無損壓縮是說被壓縮的數據和解壓后的數據完全一樣，不存在精度的損失。對數據的壓縮說到底是對數據規律性的總結。時序數據的規律可以總結為兩點：1、timestamp 穩定遞增、2、數值有規律性，變化穩定。下面來舉個例子。

上圖是一組時序數據，如果我們一行一行的看感覺壓縮有點困難，但如果我們一列一列的看，壓縮方案就呼之欲出了。

先看 timestamp 那一列是等差遞增數列，可以用 [1467627245000,1000,4] 來表示。1467627245000 代表了***個時間，1000 代表后一個時間比前一個時間的大 1000，4 代表了這樣的規律出現了 4 次。如果一共有 100 個這樣規律的 timestamp，那就意味著，我們用 3 個 Long 型就可以表示出來。timestamp 壓縮率高達 33。

再進一步觀察看 value 那一列，如果取差值，可以得到(6，-5，2，-5)，全部都加 5 得到(11，0，7，0)，這些數值都可以用 4bit 來表示。也就是用 [23,5,4,0xb0700000] 來表示(23，22，24，25，24)。其中的 4 代表后續一共有 4 個數。如果這樣的規律一直維持到 100 個 Int 的 value，就可以用 16 個 Int 來代表，壓縮率高達 6.3。

具體的情景會復雜很多，在此只是簡單舉個例子。InfluxDB 無損壓縮算法在其頁面上有完整的闡述(注 3)，可以配合開源源碼進行更加深入的理解。針對于浮點數類型，Facebook 在 Gorilla 論文中(注 4)提到的非常高效的無損壓縮算法，已經有很多文章進行分析。InfluxDB 對于浮點型也采用這個算法。

有損壓縮

有損壓縮的意思是說解壓后的數據和被壓縮的數據在精度上有損失，主要針對于浮點數。通常都會設置一個壓縮精度，控制精度損失。時序數據的有損壓縮的思路是擬合。也就是用一條線盡可能的匹配到這些點，可以是直線，也可以是曲線。

最有名的時序數據有損壓縮是 SOIsoft 公司的 SDA 算法，中文稱為旋轉門壓縮算法。

在上圖中，紅色的點是上一個記錄的點，空心的點是被丟掉的點，綠色的點是當前的點，黑色的點是當前要記錄的點。

可以看到圖左邊，當前點和上一個記錄點以及壓縮精度的偏差值形成的矩形可以包含中間的點，所以這些點都是可以丟掉的。

再看圖右邊，當前點和上一個記錄點形成的矩形無法包含中間的點，所以把上一個點記錄下來。如此進行下去，可以看到，大部分的數據點都會被丟掉。查詢的時候需要根據記錄的點把丟掉的點在插值找回來。

有損壓縮除了可以大幅減少存儲成本。如果結合設備端的能力，甚至可以減少數據的寫入，降低網絡帶寬。

總結

雖然判斷壓縮算法***是不可計算的，但是設計好的壓縮算法仍然是可計算的問題。可以看到，前面提到的時序數據的無損壓縮有損壓縮算法都會基于時序數據的特征采取方案，達到更好的壓縮率。現在 deep learning 非常的火，讓人很好奇它是不是可以給數據壓縮帶來新的方案。

注 1：請點擊

注 2：請點擊

注 3：請點擊

注 4：請點擊