彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於遊刃必有餘地矣 ----- 庖丁解牛

前言：隨著移動互聯網、IoT、5G等的應用和普及，一步一步地我們走進了數字經濟時代。隨之而來的海量數據將是一種客觀的存在，並發揮出越來越重要的作用。時序數據是海量數據中的一個重要組成部分，除了挖掘分析預測等，如何高效的壓縮存儲是一個基礎且重要的課題。同時，我們也正處在人工智能時代，深度學習已經有了很多很好的應用，如何在更多更廣的層面發揮作用？深度學習的本質是做決策，用它解決具體的問題時很重要的是找到契合點，合理建模，然後整理數據優化loss等最終較好地解決問題。在過去的一段時間，我們在用深度強化學習進行數據壓縮上做了一些研究探索並取得了一些成績，已經在ICDE 2020 research track發表（Two-level Data Compression using Machine Learning in Time Series Database）並做了口頭彙報。在這裡做一個整體粗略介紹，希望對其它的場景，至少是其它數據的壓縮等，帶來一點借鑑作用。

1. 背景描述

1.1 時序數據

時序數據顧名思義指的是和時間序列相關的數據，是日常隨處可見的一種數據形式。下圖羅列了三個示例 a）心電圖，b）股票指數，c）具體股票交易數據。

關於時序數據庫的工作內容，簡略地，在用戶的使用層面它需要響應海量的查詢，分析，預測等；而在底層它則需要處理海量的讀寫，壓縮解壓縮，採用聚合等操作，而這些的基本操作單元就是時序數據，一般（也可以簡化）用兩個8 byte的值進行統一描述。
可以想象，任何電子設備每天都在產生各種各樣海量的時序數據，需要海量的存儲空間等，對它進行壓縮存儲及處理是一個自然而然的方法。而這裡的著重點就是如何進行更高效的壓縮。

1.2 強化學習

機器學習按照樣本是否有groundTruth可分為有監督學習，無監督學習，以及強化學習等。強化學習顧名思義是不停得努力得去學習，不需要groundTruth，真實世界很多時候也沒有groundTruth，譬如人的認知很多時間就是不斷迭代學習的過程。從這個意義上來說，強化學習是更符合或更全面普遍的一直處理現實世界問題的過程和方法，所以有個說法是：如果深度學習慢慢地會像C/Python/Java那樣成為解決具體問題的一個基礎工具的話，那麼強化學習是深度學習的一個基礎工具。
強化學習的經典示意圖如下，基本要素為State，Action，和Environment。基本過程為：Environment給出State，Agent根據state做Action決策，Action作用在Environment上產生新的State及reward，其中reward用來指導Agent做出更好的Action決策，循環往復….
而常見的有監督學習則簡單很多，可以認為是強化學習的一種特殊情況，目標很清晰就是groudTruth，因此對應的reward也比較清晰。

強化學習按照個人理解可以歸納為以下三大類：

• DQN：Deep Q network，比較符合人的直觀感受邏輯的一種類型，它會訓練一個評估Q-value的網絡，對任一state能給出各個Action的reward，然後最終選擇reward最大的那個action進行操作即可。訓練過程通過評估"估計的Q-value“”和“真正得到的Q-value”的結果進行反向傳遞，最終讓網絡估計Q-value越來越準。
• Policy Gradient：是更加端到端的一種類型，訓練一個網絡，對任一state直接給出最終的action。DQN的適用範圍需要連續state的Q-value也比較連續（下圍棋等不適用這種情況），而Policy Gradient由於忽略內部過程直接給出action，具有更大的普適性。但它的缺點是更難以評價及收斂。一般的訓練過程是：對某一state，同時隨機的採取多種action，評價各種action的結果進行反向傳遞，最終讓網絡輸出效果更好的action。
• Actor-Critic：試著糅合前面兩種網絡，取長補短，一方面用policy Gradient網絡進行任一state的action輸出，另外一方面用DQN網絡對policy gradient的action輸出進行較好的量化評價並以之來指導policy gradient的更新。如名字所示，就像表演者和評論家的關係。訓練過程需要同時訓練actor（policy Graident）和critic(DQN)網絡，但actor的訓練只需要follow critic的指引就好。它有很多的變種，也是當前DRL理論研究上不停發展的主要方向。

2. 時序數據的壓縮

對海量的時序數據進行壓縮是顯而易見的一個事情，因此在學術界和工業界也有很多的研究和探索，一些方法有：

• Snappy：對整數或字符串進行壓縮，主要用了長距離預測和遊程編碼（RLE），廣泛的應用包括Infuxdb；
• Simple8b：先對數據進行前後delta處理，如果相同用RLE編碼；否則根據一張有16個entry的碼錶把1到240個數（每個數的bits根據碼錶）pack到8B為單位的數據中，有廣泛的應用包括Infuxdb；
• Compression planner：引入了一些general的壓縮tool如scale, delta, dictionary, huffman, run length和patched constant等，然後提出了用靜態的或動態辦法組合嘗試這些工具來進行壓縮；想法挺新穎但實際性能會是個問題；
• ModelarDB：側重在有損壓縮，基於用戶給定的可容忍損失進行壓縮。基本思想是把維護一個小buff，探測單前數據是否符合某種模式（斜率的直線擬合），如果不成功，切換模式重新開始buff等；對支持有損的IoT領域比較合適；
• Sprintz：也是在IoT領域效果會比較好，側重在8/16 bit的整數處理；主要用了scale進行預測然後用RLC進行差值編碼並做bit-level的packing；
• Gorilla：應用在Facebook高吞吐實時系統中的當時sofa的壓縮算法，進行無損壓縮，廣泛適用於IoT和雲端服務等各個領域。它引入delta-of-delta對時間戳進行處理，用xor對數據進行變換然後用Huffman編碼及bit-packing。示例圖如下。
• MO：類似Gorilla，但去掉了bit-packing，所有的數據操作基本都是字節對齊，降低了壓縮率但提供了處理性能；
• …

還有很多相關的壓縮算法，總的來說：

1. 它們基本都是支持單模式，或者有限的偏static的模式進行數據的壓縮；
2. 很多為了提高壓縮率，都用了bit-packing (甚至有損壓縮），但對越來越廣泛使用的並行計算不太友好；

3. 兩階段的基於深度學習的壓縮算法

3.1 時序數據壓縮的特性

時序數據來源於IoT、金融、互聯網、業務管理監控等方方面面，形態特性相差很多，然後對數據精確度等的要求也不盡相同。如果只能有一種統一的壓縮算法進行無差別對待地處理，那應該是基於無損的、用8B數據進行數據描述的算法。
下圖是阿里雲業務中一些時序數據的示例，無損是從宏觀還是微觀層面，數據的pattern都是五花八門的，不僅僅是形狀曲線，也包括數據精度等。所以壓縮算法很有必要支持儘量多的一些壓縮模式，然後又可以既有效又經濟地選擇其中一種進行壓縮。

對於一個大型的商用的時序數據壓縮算法，需要重點關注三個重要的特性：

• Time correlation：時序數據有很強的時間相關性，然後對應的數據基本上是連續的。採樣間隔通常是1s，100ms等；
• Pattern diversity：如上圖，pattern及特性差距會很大；
• Data massiveness：每天、每小時、每秒需要處理的數據量都是海量的，總體處理數據至少是在每天10P的level，對應的壓縮算法需要高效且有高吞吐率。

3.2 新算法核心理念

追本溯源，數據壓縮的本質可分為兩階段：首先Transform階段把數據從一個空間轉化到另外一個更規則的空間，然後在差值編碼階段用各種各樣的辦法較好的標識變換後的差值。
根據時序數據的特點，可以定義以下6個基本的transform primitives（可擴展）。

然後定義以下3中基本的differential coding primitives（可擴展）。

接下來把上面的兩種tools排列組合進行壓縮？這樣可行但效果肯定是不太好，因為模式選擇和相關參數的cost比重太高了，需要2B（primitive choice + primitive parameter）的控制信息，佔了8B需要表達數據的25%。
更好的應該是對數據的特性進行抽象化分層表達，示意圖如下。創建一個控制參數集較好的表達所有的情況，然後在全局(一個timeline)層面選擇合適的參數來確定一個搜索空間（只包含少量的壓縮模式，譬如4種）；然後在具體進行每個點的壓縮時，遍歷從中選擇出最好的那一種壓縮模式進行壓縮。控制信息的比重在~3%。

3.3 兩階段壓縮框架AMMMO

AMMMO（adatpive multiple mode middle-out）整體過程分為兩個階段，第一階段確定當前這條時間線的總體特性（確定9個控制參數的具體值）；然後在第二階段在少量的壓縮模式中遍歷並查找最後的一種進行壓縮，具體框圖如下。

第二階段的模式選擇沒有難度，邏輯簡單適合高效率執行；第一階段確定各參數值（9個這裡）得到合適的壓縮空間有比較大的挑戰，需要從理論上的300K多個排列組合選擇裡找出合適的那一個。

3.4 基於規則的模式空間選擇算法

可以設計一種算法，譬如創建各個壓縮模式的效果記錄牌(scoreboard），然後遍歷一個timeline裡的所有點並進行分析記錄，然後再經過統計分析比較等選擇最好的模式。一些顯而易見的問題有：

• 選擇的評估指標是否理想？
• 需要人工去思考並編寫程序，有較多的實現，debug和maintain的工作量；
• 如果算法中的primitive，壓縮模式等做了改變，整個代碼都需要重構，基於上面的選擇不是理論選擇，需要一種自動且較智能的方法支撐不停的演化等。

4. 深度強化學習

4.1 問題建模

簡化上面的整個模式空間選擇算法如下圖，我們可以把這個問題等同於多目標的分類問題，每個參數就是一個目標，每個參數空間的取值範圍就是可選擇的類目數。深度學習在圖像分類，語義理解等方面證明了它的高可用性。類似地，咱們也可以把這裡的模式空間的選擇問題用深度學習來實現，把它當做一個multi-label的classification問題。

用什麼樣的網絡？考慮到識別的主要關係是delta/xor, shift，bitmask等為主，cnn不恰當，full-connect的mlp比較合適。相應地，把一條時間線上的所有點，如果1小時就是3600個共3600*8B，有些太多，考慮到同一timeline內部一段一段的相似性，把32個點作為一個最基本的處理單元。
接下來，怎麼去創建訓練樣本？怎麼給樣本尋找label呢？
在這裡我們引入了強化學習，而不是有監督的學習去訓練，因為：

• 去創建有label的樣本很難：32個樣本256B，理論上sample有256^256中可能性，對每個這種樣本，需要遍歷300K的可能性才能找出最好的那一個。創建及選擇sample，create label的工作量都非常大；
• 這不是普通的one-class-label問題：給定一個樣本，並不是有唯一的最好的一個結果，很有可能很多的選擇都能取得相同的壓縮效果；N class（N基本不可知）的訓練又增加了很多難度；
• 需要一種自動化的方法：壓縮的tool等參數選擇很有可能是需要擴展的，如果發生整個訓練樣本的創建等都需要重新再來。需要一種自動化的辦法。

用什麼樣的強化學習呢？DQN，policy gradient, 還是actor-critic? 如前面分析，DQN是不太適合reward/action不連續的的情況，這裡的參數，譬如majorMode 0和1是完全不同的兩種結果，所以DQN不合適。此外，壓縮問題一方面不容易評價另外網絡也沒有那麼複雜，不需要actor-critic。最終我們選擇了policy gradient。
Policy gradient常見的loss是用一個慢慢提高的baseline作為衡量標準來反饋當前的action是否合適，但這裡並不太合適（效果嘗試了也不太好），因為這裡sample的理論block(256^256) state太多了一些。為此，我們專門設計了一個loss。

得到了每個block的參數後，考慮到block的相關性等。可以用統計的辦法，聚合得到整個timeline的最終參數設置。

4.2 深度強化學習網絡框架

整體的網絡框架示意圖如下：

在訓練端：隨機選擇M個block，每個block複製N份，然後輸入到有3個隱含層的全連接網絡中，用region softmax得到各參數各種choice的概率，然後按照概率去sample每個參數的值，得到參數後輸入到底層的壓縮算法進行實際壓縮並得到壓縮值。複製的N個block相互比較計算loss然後做反向傳播。loss的整體設計為：

fn(copi)描述了壓縮效果，比N個block的均值高就正反饋，Hcs(copi)是交叉熵，希望得分高的概率越大越確定越好；反之亦然。後面的H（cop)是交叉熵作為正則化因子來儘量避免網絡固化且收斂到局部最優。
在推理端，可以把一個timeline的全部或局部block輸入到網絡中，得到參數，做統計聚合然後得到整個timeline的參數。

5. 結果數據

5.1 實驗設計

測試數據部分一方面隨機選取了阿里雲業務IoT和server兩個大場景下共28個大的timeline；另外也選取了時序數據分析挖掘領域最通用的數據集UCR。基本信息如下：

對比算法選取了比較有對比性的Gorilla，MO和Snappy。因為AMMMO是兩階段的壓縮算法框架，第一階段的參數選擇可以有各種各樣的算法，這裡選用了Lazy（簡單粗暴的設置一些普世參數），rnd1000Avg（隨機1000次取效果平均值），Analyze（用人工代碼的算法)和 ML（深度強化學習的辦法）等。

5.2 壓縮效果對比

首先從整體壓縮率來看，AMMMO兩階段自適應多模式的壓縮比起Gorila/MO等有明顯的效果提升，平均壓縮率提升在50%左右。

然後ML的效果怎麼樣呢？下圖在ML的視野對比了測試集B上的壓縮效果，總的來說，ML相比人工精心設計的算法略好，比隨機平均等明顯好很多。

5.3 運行效率

AMMMO借鑑了MO的設計思想，移除了bit-packing，不僅僅在CPU上能高速運行，也特別適合於並行計算平臺如GPU。此外AMMMO分兩階段，其中第一階段的性能會差一些，但很多時候，譬如對一個特定的設備過去2天的數據，全局壓縮參數是可以複用的。下圖描述了整體的性能對比，實驗環境為“Intel CPU 8163 + Nvidia GPU P100"，其中AMMMO的代碼使用了P100。

從上圖中看出，AMMMO在壓縮端和解壓縮端都能達到GB/s的處理性能，性能指標還是很不錯的。

5.4 算法學到的效果

深度強化學習訓練的網絡從最終效果上看著不錯，那它是不是真的有學到有意義的內容呢？下標對比了3中算法在幾個測試集上的表現，可以看出，ML版本的參數選擇和分析算法/最優效果選擇是差不多的，特別是在byte offset和majorMode的選擇上。

這種壓縮的全連接網絡參數表象會是怎麼樣的？對第一層進行了參數heatmap可視化（正的參數為紅色，負的為藍色，值越大顏色越亮），如下：

可以明顯看到32個點在相同的byte上有很多規則的操作，豎線（如果跨越byte則混淆情況），可以認為是在對應的位置上做delta或xor運算等。然後數字變動最大的Byte0的參數也比較活躍。
綜上，深度學習學到的東西還是挺有解釋性的。

6. 相關人員和致謝

在整個過程中，Yanqing peng，飛刀，汪晟，樂予，麥君和Yue Xie等一起付出了很多的努力，特別感謝飛刀老師的方向指引和總體判斷；
此外，特別感謝矽厲等在工作中給予的支持，感謝德施等在業務上給予的幫助和支持。