數據模式感知的低成本云日志存儲系統

魏鈞宇 張廣艷 陳軍超

（清華大學計算機科學與技術系 北京 100084）

（wei-jy19@mails.tsinghua.edu.cn）

隨著信息技術的發展，計算系統日趨復雜，大型系統的維護和檢查越來越離不開系統產生的監控日志.這些日志數據廣泛存在于各類系統平臺上，并為故障診斷[1-4]、異常檢測[5-9]、用戶畫像[10-11]、系統建模[12-13]和安全檢查[14-15]等多種服務提供支撐.同時為了確保歸檔審計信息的完整與可溯源性，最新出臺的《網絡安全法》也明確規定“采取監測、記錄網絡運行狀態、網絡安全事件的技術措施，并按照規定留存相關的網絡日志不少于六個月”[16]，這又對日志數據提出了長期歸檔存儲的要求.

在現代數據中心中，系統日志有成千上萬個數據產生源，數據規模單日可達上百億條（PB 量級）[17]，該類數據已經儼然成為一類新興大數據.為降低數據存儲成本，有必要對于該類數據進行快速、高密壓縮.另一方面，在使用這類日志時，過長的檢索延遲將會降低查錯和系統運維的效率，進而造成不必要的損失[18]，因此在高密壓縮的同時還需保證能夠快速檢索以獲得需要的信息.日志存儲的總成本包括數據存儲的空間成本、數據壓縮的時間成本和數據檢索的時間成本，而低成本日志存儲系統的設計目標就是要盡可能降低這3 部分成本.

本文結合公共云中日志數據的真實存儲需求，給出了一種云日志數據的低成本存儲范式——數據模式感知的低成本云日志存儲.首先，總結了云日志中的典型數據模式，即靜態數據模式和動態數據模式；然后，給出了基于數據模式感知構建低成本云日志存儲系統的方法；最后，針對國內外若干低成本云日志存儲方法在壓縮率、壓縮速度和檢索延遲等方面進行了對比測試.

此外，結合我們在低成本云日志存儲系統領域的研究提出了幾點經驗與思考，希望為未來大規模數據存儲的相關研究提供參考和幫助.

我們研制的數據模式感知的低成本云日志存儲系統已經應用到某國際著名云廠商的實際生產系統中，降低了2/3 的云日志存儲成本，提升了云服務的服務質量.

1 云日志的數據特點和存儲需求

系統日志原本是程序員在編寫程序時出于調試需要而設計的一種輸出信息.對于小規模軟件來說，通常在調試版本（debug version）中存在小部分的輸出日志，在正式的發行版本（release version）中基本不存在額外輸出的調試信息.但隨著軟件規模的擴大，特別是隨著云計算技術的發展，很多在云場景下運行的大型軟件也會以一定格式持續不斷地輸出日志信息[19-20].這些信息實時記錄了當前系統的運行情況以及處理工作的細節，未來可供調試、歸檔、審計、系統建模等多種應用使用.

在大型商業云中，通常有隸屬于基礎事務部的專業日志存儲團隊，他們將為各類企業運維團隊提供包括日志采集、查詢、分析、歸檔存儲等云原生SLS（system log service）服務.SLS 系統將持續收集來自整個系統中不同應用的日志信息，將這些信息按照時間順序寫入到同一緩沖區內，并對于緩沖區內的日志進行分類、壓縮等進一步處理.在保證將這些日志歸檔存儲一定時間的同時，對外提供對于海量云日志的檢索和分析服務.

本節將結合云日志分類介紹這類新興大數據的具體信息，進一步歸納云日志的數據特點以及相應的存儲需求.

1.1 云日志的分類

對云日志數據可以從多個維度進行分類.從日志的級別出發，可以將云日志分成提示（INFO）、警告（WARNING）和錯誤（ERROR）等不同嚴重等級，對于按照時間順序寫入到同一片緩沖區中的日志，在進行錯誤溯源時，通常可以首先根據嚴重等級進行日志過濾.

從日志的產生機理出發，可以將云日志分成系統日志（system log）、訪問日志（access log）、環境指標（environment metric）三類.系統日志通常由系統軟件產生，主要用于提示、告警和報錯.例如，分布式文件系統HDFS 會記錄緩沖區溢出、網絡異常、塊讀寫錯誤等信息.訪問日志主要記錄用戶對系統的訪問，這部分日志主要在用戶做出某些行為時生成，用于未來出現安全問題時對可疑操作進行溯源或對一段時間內的用戶行為進行建模.例如，在云系統的網絡代理服務器中通常會記錄外部服務器對于某些特定IP地址的訪問.環境指標則由各個服務器定期產生，通常會隨集群心跳信息一起發送到中心協調服務器中.這些信息通常包括了各服務器的當前環境狀態，例如溫度、CPU 利用率、內存占用率等指標.

從對于日志的訪問頻率出發，可以將日志分成在線日志（online log）、近線日志（nearline log）和離線日志（offline log）三類.具體來說，在線日志是指在產生之后需要進行頻繁訪問的日志，例如用于系統建模的日志通常會被輸入到特定的建模軟件中，由建模軟件對其進行頻繁且種類繁多的檢索訪問.和在線日志相對的是離線日志，這類日志在產生之后基本不會進行訪問，例如用戶訪問日志、環境監控日志等，這些日志產生的初衷即是在出現嚴重的錯誤，或者運營商卷入到相關的案件時才會被調用協助案情偵查.近線日志的訪問頻率介于在線日志和離線日志之間，這類日志主要以系統的各種警告、報錯日志為主，廣泛應用于云系統的異常診斷和故障溯源中.很多錯誤通常不會立刻影響前端應用，卻會被系統以警告或者報錯的形式體現在日志之中，因此在進行系統故障診斷時通常需要訪問這類日志.

根據某國際著名云廠商單月內對于PB 量級云日志數據檢索次數的統計，44%的日志在產生之后單月內的訪問次數為零，屬于離線日志；2%的日志單月內的訪問次數超過100，可以歸類為在線日志；剩下的54%的日志則介于二者之間，對它們存在一定數量的訪問，但是訪問頻率較低，屬于近線日志.日志數據寫入時通常會根據未來一段時間內是否進行密集訪問分成在線日志和近線日志：對于在線日志，通常保留原始的日志數據，并通過在數據上建立索引的方法加速數據訪問性能；對于近線日志和離線日志則進行壓縮以降低存儲開銷，未來查錯時可能需要對這些數據進行低延遲檢索.經過一段時間之后，訪問次數為零的日志將被視為離線日志，并進行高密壓縮以滿足歸檔需求.

1.2 云日志的數據特點

通過對某國際著名云廠商的實際生產日志的觀察，我們歸納得到云日志的若干數據特點.

特點1：數據規模巨大、留存時間長.由于云日志通常用于大型軟件或者整個系統級別的查錯，因此需要由統一的日志管理部門來協調整個平臺中產生的各類日志，而所有這些日志的規模單日可以達到PB 量級.另一方面，《網絡安全法》規定這些日志需要留存至少180 天，因此如果直接存儲這些日志數據將帶來巨大的存儲開銷.

特點2：有用信息密度低.盡管云日志的規模龐大，但其中的有用信息密度較低.這一方面是由于日志數據存在較多冗余，例如在執行類似操作時輸出的提示信息完全相同、執行多次訪問時留下的記錄也大同小異等.另一方面是由于在審計和故障溯源的過程中，真正需要的日志條目在所有日志條目中所占的比例極低.例如，在一次云系統的故障溯源過程中，日志庫中可能相關的日志條目總量超過了70億條，而其中真正對錯誤定位有幫助的日志條目僅有391 條.

特點3：訪問延遲敏感.盡管大部分日志數據的訪問頻率較低，但單次訪問通常是一個查錯溯源過程中的必要環節.通過和日志維護團隊的工程師進行交流，工程師通常能接受的單次檢索延遲應當在秒量級，最多不超過分鐘量級，一旦單次檢索超過半小時，將嚴重影響工程師的查錯效率[18].此外，如果日志檢索顯著拖慢了整個溯源過程，就有可能因此耽誤對于致命問題的排查，進而造成更為嚴重的影響.

1.3 云日志的存儲需求

由于日志中有用信息密度低、規模龐大且留存時間較長，對于近線日志和離線日志，通常需要進行壓縮存儲以降低存儲成本.另一方面，對于近線日志和在線日志，由于在檢索時對于延遲較為敏感，還需要在數據調用時保證穩定的低延遲.

上述2 個存儲需求造成了日志存儲面臨高壓縮率和低解壓開銷難以兼得的問題.現有的壓縮工具（包括常見的通用壓縮工具[21-24]和一系列日志專用壓縮工具[25-29]）通常是在兩者之間折中，例如LZMA和PPMd 選擇犧牲解壓延遲以實現高壓縮率，gzip 選擇犧牲高壓縮率以實現低解壓延遲，zstd 則給用戶提供了不同的壓縮等級，允許用戶自行在高壓縮率和低解壓開銷之間折中.日志專用的壓縮方法例如LogArchieve 將日志分桶大小作為一個可調的超參數，分桶越大日志壓縮率越高，但解壓開銷越大；反之分桶越小解壓開銷越小，但日志壓縮率也會相應下降.

那么，是否有同時實現高壓縮率和低檢索延遲的低成本存儲方法呢？事實上，云日志中所隱含的數據模式為我們提供了一種全新的數據存儲思路.

2 云日志中的數據模式

模式，通常是指一個變化的數據集中相對固定的部分.云日志作為一種半結構化數據，其中存在大量的冗余信息，這些冗余信息和有用信息混合在一起便構成了云日志中的若干數據模式.

首先，由于日志數據的產生源頭是用戶定義的結構化輸出語句，因此由同一條結構化輸出語句輸出的日志通常會共享結構化語句體.如圖1 所示，由結構化輸出語句“Time taken %ds”輸出的日志都共享“Time taken <*>s”的冗余字段.

Fig.1 The generation process of the static pattern in log data圖1 日志數據靜態模式的產生過程

其次，在程序執行過程中，同一條結構化輸出語句通常會連續輸出多條日志，這些日志除了具有完全相同的結構化語句體之外，它們的變量值之間也因為程序執行的局部性而共享一些相對固定的部分.例如，在“Time taken <*>s”的例子中，連續的時間戳之間的數值差異不大；在HDFS 中塊的編號通常以“blk_”開頭；在記錄IP 地址的日志中，屬于同一個子網的IP 地址之間通常共享一些相同的字段等等.

本節將首先介紹云日志的兩類代表性數據模式，接下來討論提取云日志數據模式的一些有效方法，為進一步討論數據模式感知的云日志存儲做好準備.

2.1 云日志中的代表性數據模式

已經發現云日志有兩類代表性數據模式：靜態模式和動態模式.

1）靜態模式.我們將日志數據中因共享程序員定義的結構化輸出語句而形成的模式稱為靜態模式.這類模式通常可以通過靜態代碼分析或根據同一公司內的編程規范加以確定.

我們可以將由同一個結構化輸出語句所輸出的日志條目視為一個日志條目組，將同一日志條目組內出現在相同位置的變量視為一個變量組.如果結構化輸出語句中具有x個變量，就會對應x個變量組.例如在圖1 所示的例子中“Time taken %ds”對應的日志條目組中包含4 條日志，變量“%d”對應的變量組中包含4 個變量數值.

2）動態模式.除靜態模式之外，我們將在實際運行中同一個變量組的變量數值由于局部性而共享的相對固定的部分稱為動態模式.對于這類模式，程序員不可能在程序執行前就預先獲知變量的內容，同時這類模式還會隨著程序運行的局部性變化而不斷改變，因此這類模式無法僅僅通過靜態分析程序語句的方法獲得，還必須通過對運行過程中動態產生的日志執行進一步的模式識別才能得到.

動態模式能夠有效地將變量分割成更細粒度的存儲單元.如圖2 所示，左側的4 條日志屬于2 個日志條目組，每一個日志條目組中包含2 個變量組；在右側，我們通過對這4 個變量組的進一步分析得到每一個變量組的動態模式，并可將原有變量組分解成更細粒度的存儲單元.

Fig.2 Examples for static pattern and runtime pattern in log data圖2 日志數據中的靜態模式和動態模式舉例

2.2 日志數據模式的提取

針對云日志的兩類代表性數據模式，人們已經找到了行之有效的提取方法.

1）靜態模式提取方法.靜態模式提取是指從原始云日志數據中獲得對應的結構化輸出語句的過程，它是日志分析領域的一個研究熱點.已有提取方法主要包括基于頻繁序列的方法[7,30-33]、基于聚類的方法[34-35]以及其他基于啟發式的方法，例如基于樹結構[36]、基于日志長度[37]等.相關研究表明[38]，基于解析樹的方法效果最佳，故在這里著重介紹.

基于解析樹的提取方法首先使用一系列預先規定的字符（例如逗號、空格等）將日志條目分割成一系列token 組成的串，然后根據如圖3 所示的解析樹實現靜態模式的提取.該解析樹共有2 層，在第1 層中使用日志條目中包含的token 數量對日志條目進行歸類，具有相同token 數目的日志條目將進一步聚類為同一組.同一組中相似度超過閾值的日志條目將被認為具有同樣的靜態模式，這些條目中出現在同一位置的變量將被存入到特定的變量組中.

Fig.3 Parser tree for static pattern圖3 靜態模式解析樹

在實際執行時，日志解析器將首先采樣一部分日志條目作為訓練集，訓練生成如圖3 所示的解析樹.在實際壓縮階段，嘗試將日志條目匹配到某一訓練階段時生成的靜態模式之中，否則認為該條目出現了失配，所有失配的日志條目將單獨進行壓縮.

基于解析樹的靜態模式匹配策略可以實現對靜態模式的黑盒提取，即在無法獲得日志數據生成代碼的條件下即可完成對于日志數據靜態模式的有效提取.但黑盒提取方法的效果高度依賴于提取過程中所規定的token 分隔符和所設定的相似度閾值，在實際使用時，也可以通過在模式提取階段引入一些靜態模式的白盒獲取方法[39-42]，以提升日志壓縮的效果.

2）動態模式提取方法.動態模式提取是指結合系統運行時輸出日志的特點，提取日志變量中共性部分的過程，主要方法包括2 種：基于樹擴展的自頂向下策略和基于模式合并的自底向上策略.

基于樹擴展的自頂向下策略通常用于變量組中僅包含一種動態模式的情況.如圖4 所示，該策略首先從變量組中隨機挑選一個變量，利用其中包含的非字母、非數字的特殊字符（圖4 中為“_”）將原始變量組劃分成更小的變量組，在這一過程中如果某一個變量不包含當前進行劃分的字符，則被存入到一個獨立存儲單元中進行壓縮.針對劃分完成的更小變量組，該策略將進一步識別變量值之間的公共子串（圖4 中為“F8”）并基于此對變量組做進一步的劃分，如果某一個子變量組中的所有子變量都相同，則將其記為常量并歸入到動態模式之中（圖4 中為“block”）.接下來對于所有的子變量組重復上述流程，直到所有子變量組都無法繼續擴展為止.

Fig.4 Tree-expanding-based top-down runtime pattern extraction strategy圖4 基于樹擴展的自頂向下動態模式提取策略

基于模式合并的自底向上策略通常用于處理重復變量值較多的變量組.如圖5 所示，該策略將首先進行去冗處理，將所有不重復的數值存儲為字典.此時由于原始變量組內的重復變量值較多，字典通常要比原始變量組的規模小很多，因此可以在字典上執行復雜度較高的基于模式合并的動態模式提取策略.該策略首先根據變量中的非字母、非數字的特殊字符提取得到粗模式，之后再將具有相同粗模式的變量合并得到細模式，此時如果粗模式的某一子變量在各個變量值中都保持一致（例如“ERR”），則將其記為常量.最終，根據提取得到的細模式將原始字典進行重排序，將具有相同細模式的變量值進行連續存儲，以方便后續檢索.

Fig.5 Pattern-merging-based bottom-up runtime pattern extraction strategy圖5 基于模式合并的自底向上動態模式提取策略

在實際使用時可以根據變量組內重復變量值的多少將變量組分成兩類：真實變量組（real variable vector）和名義變量組（nominal variable vector）.前者所包含的變量值中重復的相對較少，例如時間戳、具體的延遲數值等；后者所包含的變量值中則重復的相對較多，例如用戶名稱、告警級別等.

真實變量組通常只包含一種動態模式，而名義變量組則包含多種動態模式.因此，針對真實變量組可以采用基于樹擴展的自頂向下策略，針對名義變量組可以采用基于模式合并的自底向上策略.

3 數據模式感知的日志存儲

日志數據模式已在多種日志應用中得到應用.例如，借助解析得到的日志靜態模式來確定不同結構化輸出語句的輸出順序，進而分析程序行為[40]；通過日志動態模式中變量的數值特征檢測異常事件[1].本節重點討論如何利用日志中的數據模式實現日志數據存儲，以同時實現高壓縮率和低檢索延遲，進而構建低成本的云日志存儲系統.

針對離線云日志“寫一次，很少讀”的特點，可以利用日志模式對數據進行更高密度的壓縮.我們發現通過靜態模式提取將日志存儲為若干變量組，一方面，可以從全局上去除日志中因為共享相同的結構化輸出語句而具有的冗余，而又不依賴于通用壓縮方法所使用的去冗手段的窗口大小；另一方面，每一個變量組內的變量數值具有一定的共性特征（動態模式），可以對不同的變量組設計定制化的壓縮編碼方法以提升數據壓縮率.

針對近線云日志“寫一次，多次讀”的特點，我們借助數據模式，找到了可以同時實現高壓縮率和低檢索延遲的日志數據壓縮粒度，即基于靜態模式和動態模式劃分出細粒度存儲單元，對每一個存儲單元可以進行獨立壓縮和獨立解壓.一方面，在對日志數據進行檢索時，同一個存儲單元內的數據傾向于被同時訪問，因此將它們壓縮到一起就避免了訪問過程中的無效解壓；另一方面，可以在壓縮時將各個存儲單元內的數據特點描述為標簽，利用標簽在解壓數據之前就可以對存儲單元進行有效過濾，從而降低檢索操作需要解壓的數據量，進而實現低延遲檢索.

本節將討論2 個我們設計的數據模式感知的日志存儲方法，進而說明這2 種思路的實現過程.我們研制的數據模式感知的低成本云日志存儲系統已經應用到某國際著名云廠商的實際生產系統中，降低了2/3 的云日志存儲成本，提升了云服務的服務質量.

3.1 離線云日志的低成本存儲

我們提出了離線云日志的低成本存儲方法LogReducer，它基于靜態模式對日志數據進行結構化存儲，再為每一個變量組定制化設計編碼方法，最終實現了較高的壓縮率.如圖6 所示，LogReducer 的具體壓縮流程可以分成訓練階段和壓縮階段.在訓練階段，LogReducer 使用靜態模式提取方法在日志樣本上提取得到靜態模式.在壓縮階段，通過靜態模式匹配，將原始日志結構化成若干變量組，再針對每一個變量組有針對性地進行編碼，最后將所有編碼后的變量組壓縮得到最終的壓縮文件.

Fig.6 The architecture of LogReducer圖6 LogReducer 架構

依據變量的數值特點，變量組編碼方法主要包括：

1）時間戳組成的變量組.時間戳變量組在壓縮之后得到的文件中占比普遍較高（極端情況下占比可達70%左右），同時由于在大型數據中心中日志大數據的產生速度很快，相鄰的日志條目之間的時間差值普遍較小.因此，通過引入差分編碼，可顯著提升壓縮率和壓縮速度.

2）存在線性關聯關系的變量組.通過對線性關聯關系的挖掘，可以縮減變量組內數值的大小以提升壓縮效果.例如，一條日志條目同時包含一次寫操作的塊編號、偏移數值和寫入長度.由于很多寫入是連續的，因此針對同一個寫入塊而言，上一次寫入的偏移數值加上寫入大小就等于下一次的寫入偏移.通過利用該方法，可以僅記錄這一關聯關系，而將很多原始變量組中的數值削減為零.

3）數值偏小的整數變量組（包括通過差分處理和關聯關系挖掘之后的變量組）.可以采用彈性編碼策略將數值比較小的整數（很多高位的字節都是零）采用更少的字節來存儲.此外，由于差分處理和關聯關系挖掘引入了很多絕對值較小的負數，該方法也通過移位加比特翻轉的途徑，使用更少字節表示小絕對值的負數.

3.2 近線云日志的低成本存儲

我們提出了近線云日志的低成本存儲方法LogGrep，它借助靜態模式和動態模式將日志分割成細粒度的存儲單元，在保證高壓縮率的同時，通過細粒度單元的高效過濾實現了日志的低延遲檢索.如圖7 所示，LogGrep 在壓縮時首先通過靜態模式解析將原始云日志存儲為變量組，接下來又通過動態模式解析將每一個變量組存儲成若干細粒度的存儲單元，并根據每一個存儲單元內的數據特點生成對應的標簽以支持高效檢索，最后將每一個存儲單元獨立壓縮編碼.LogGrep 在檢索時通過模式匹配和存儲單元過濾得到需要解壓的存儲單元，解壓這些單元并在這些單元上進行檢索定位，在定位到被檢索的目標日志之后，進行日志重構并將結果返回給用戶.

Fig.7 The architecture of LogGrep圖7 LogGrep 架構

LogGrep 使用動態模式對變量組內信息進行抽象和提煉，因此可以在進行真正解壓之前就利用動態模式提前獲知對應的變量組內是否存在要檢索的內容.同時較之于原始的變量組，細粒度的存儲單元內的數據種類較為單一（通常都是整數或都是十六進制數），這就為更精確地標注創造了條件.我們發現如果將所有字符分成6 類（0～9，a～f，g～z，A～F，G～Z，其他），一個靜態模式結構化后的日志變量組平均包含3.1 種字符，而一個經過動態模式結構化處理的細粒度存儲單元則平均僅包含1.5 種字符.

LogGrep 通過動態模式的結構化處理，在過濾階段需要解壓的日志量從原始的整個變量組降低到細粒度的存儲單元，這相當于縮小了變量組的大小，從而降低了檢索延遲.同時，我們發現通過將原始變量組存儲成細粒度存儲單元，每一個細粒度存儲單元獨立壓縮后的大小之和與原始變量組整體的壓縮大小基本相同.換言之，引入動態模式在降低檢索延遲的同時，能夠保持靜態模式帶來的高壓縮率，相當于并沒有因為變量組縮小而給壓縮率帶來負面影響.這主要是因為通過識別變量組中存在的動態數據模式，變量組內的數據冗余要么被提取到動態模式之中，要么就在細粒度存儲單元之內，因此不同存儲單元之間基本不存在冗余，進而可以保證獨立壓縮和整體壓縮的壓縮率相差不大.

基于靜態模式和動態模式的存儲方式，在處理檢索請求時，可以首先在日志的靜態模式以及動態模式中匹配檢索串，確定檢索串中哪些部分屬于靜態模式或動態模式，哪些部分可能被包含在細粒度存儲單元內，這部分可能包含在細粒度存儲單元內的部分被稱為待檢索關鍵字.

圖8 展示了一個在動態模式上進行匹配的例子，對應于在圖4 提取得到的動態模式上匹配“8F8F”串，在整個匹配過程中臨時結果都表示為一個Bitmap，Bitmap 的總長為變量組中的變量值個數，由于屬于同一個靜態模式的變量組長度相同，因此該Bitmap也可用于記錄該靜態模式中對應的日志條目組中的命中情況，如果某一個日志條目在當前的檢索條件下被命中，則Bitmap 對應位置標1，否則標0.對于例子中的檢索串“8F8F”而言，可能有2 種匹配方案：一個是“F8”被包含在模式中，而“8”和“F”均包含在子變量中；另一個是“8”被包含在模式中，而“F8F”被包含在子變量中.對于第1 種情況，對應產生2 個子變量匹配過程A和B，原始結果需要先在A過程中匹配當前已經命中的條目，然后再在B過程中匹配已命中條目.對于第2 種情況則只對應一個匹配過程C.最終結果是上述2 種情況得到的中間結果的并集.

Fig.8 An example for runtime pattern matching圖8 一個在動態模式上進行匹配的例子

在使用細粒度存儲單元標簽和檢索關鍵字進行匹配的過程中，LogGrep 過濾掉不可能包含關鍵字的細粒度存儲單元，解壓剩余的細粒度存儲單元并同檢索關鍵字進行匹配.經過上述的一系列過濾，最終僅需要解壓并檢索少部分的細粒度存儲單元就可以完成對日志大數據的檢索，解決了日志大數據有效信息密度低以及對于檢索延遲要求高的挑戰.

在細粒度存儲單元內進行檢索時，LogGrep 采用定長檢索策略，即在壓縮時根據一個細粒度存儲單元內的最長項將各項進行補齊，由于同一個細粒度存儲單元內各項的長度接近，采用該補齊方法對于壓縮率的影響較小，但在檢索時由于細粒度存儲單元內所有項長度相同，顯著提升了檢索性能.

4 典型低成本云日志存儲方法的比較

基于數據模式感知的思想，國內外多個團隊進行了探索和嘗試，設計了多種低成本云日志存儲方法，典型的有多倫多大學設計的CLP[43]與我們設計的LogReducer[17]和LogGrep[18].其中CLP 主要利用了靜態模式，LogReducer 和LogGrep 同時使用了靜態模式和動態模式.

CLP 使用靜態模式進行日志存儲，它主要采用基于白盒的方法來進行靜態模式的提取，并使用提取得到的靜態模式和相應的變量格式構建倒排表并用作壓縮日志段的索引.在日志檢索時，系統將首先檢查倒排表索引，確定需要解壓的日志塊并進行解壓.CLP 的優點是索引構建迅速，日志寫入速度較高；缺點是不同靜態模式的變量連續存放在一起進行壓縮，壓縮率和檢索性能都相對較低.

LogReducer 針對用于審計的離線日志設計，這部分日志平時的訪問數量幾乎為零，但是一旦被調用，就需要實現無損還原，因此它無法有效支持直接針對壓縮日志的檢索操作，需要在檢索前先將日志還原.

LogGrep 針對近線日志設計，同時滿足云日志的高壓縮率和低檢索延遲的存儲需求.

我們選用15 種某國際著名云廠商的總大小為1.6 TB 的真實生產日志對上述3 種典型的日志存儲方法進行了測評.評價指標主要包括壓縮率、壓縮速度和檢索延遲.其中由于LogReducer 無法支持對于壓縮格式的直接檢索，因此我們設置LogReducer 的檢索延遲得分為0.

圖9 以一種較為直觀的方式顯示了3 種日志數據存儲方法在3 個維度上的性能.在每一類日志上，所有方法在3 個維度的性能都同性能最好的方法做歸一化（壓縮率最高的方法得分為1，檢索延遲最低的方法得分為1），之后將對某一方法某一維度上15種日志的結果計算平均值.

Fig.9 The evaluation of three typical methods圖9 三類典型的日志存儲方法測評

在壓縮率方面，LogReducer 的平均得分為1，相對于其他兩種方法，它在15 種日志中的13 種上都實現了最高的壓縮率.LogGrep 的平均得分為0.78，在LogReducer 未達到最佳的2 種日志上，LogGrep 的壓縮率最高，在最差情況下LogGrep 的壓縮率大概為LogReducer 的一半，這主要是因為LogGrep 在使用靜態模式提取變量組之后，對于所有的變量組都采用了統一的編碼方法，而并非像LogReducer 那樣針對不同類型的變量組采用不同的編碼方法.相比于其它兩類方法，CLP 的壓縮率具有明顯劣勢，其壓縮率得分僅有0.36，這主要是因為它僅使用靜態模式構建檢索時的索引，并未使用該模式實現日志的高密壓縮.

在壓縮速度方面，CLP 的平均得分為1，相比于其他兩類方法具有明顯的優勢，在全部15 種日志上都達到了最佳性能.LogReducer 和LogGrep 的得分分別為0.22 和0.17.相比于CLP，LogReducer 和LogGrep都涉及到黑盒模式提取步驟，該步驟涉及到相對復雜的訓練過程和日志拷貝過程，因此對應的壓縮速度相對較低.

在檢索延遲方面，LogGrep 表現出了明顯的性能優勢，它在全部15 種日志上的檢索延遲都要遠低于CLP，在一些日志上甚至要低2 個數量級，平均來看，CLP 的檢索延遲得分僅有0.04.

如表1 所示，針對不同日志類型和日志存儲需求，可以選用不同的日志存儲方法.當我們僅需要高壓縮率時可以優先選用LogReducer，當我們僅需滿足高壓縮速度時，可以優先選用CLP.LogGrep 可以同時實現需要高壓縮率（壓得狠）和低檢索延遲（查得快）的雙重目標，但它依舊未能攻克如何實現高速模式提取和數據編碼的難題，因此其壓縮速度較差.

Table 1 Storage Requirements and Suitable Storage Methods for Different Logs表1 不同日志類型的存儲需求與適用存儲方法

5 云日志存儲系統設計的經驗與思考

公共云日志數據以其產生迅速、規模龐大、留存時間長、有用信息密度低、訪問延遲敏感等特點對存儲系統提出了新的挑戰，本節將介紹在設計相關低成本存儲系統過程中的經驗與思考，希望能對未來相關領域大數據低成本存儲系統的設計起到借鑒作用.

1）低成本云日志存儲系統設計的核心思路在于以全生命周期的視角考慮數據壓縮和成本縮減，即壓縮存儲系統的設計不僅要考慮高壓縮率和存儲成本，而且還需考慮數據寫入時的壓縮成本和數據在被訪問時的解壓量以及對應的檢索成本.這就要求相關設計者不能顧此失彼，只有通盤考慮了數據的全生命周期才能真正實現數據存儲的低成本.現有的很多壓縮工具（例如LZMA，zstd）僅僅追求高壓縮率和高壓縮速度，默認數據在訪問時必須通過全解壓的方式進行訪問，在設計壓縮算法時并未考慮檢索延遲的因素，這就造成相關方法盡管可以實現較低的存儲開銷但卻無法保證低檢索開銷，極端情況下甚至會造成系統工程師誤判錯誤根因，進而影響整個錯誤溯源的結果.

2）數據模式感知的低成本云日志存儲系統的相關實踐表明，領域專用的低成本解決方案不僅在壓縮率方面優于通用的解決方案，而且帶來了全生命周期設計低成本數據存儲系統的可能.LZMA 和zstd等壓縮工具在壓縮時不考慮數據實際訪問模式的根本原因在于它們屬于通用壓縮方法，在壓縮過程中無法結合實際數據特征調整相應的壓縮策略，進而不僅錯失通過針對性編碼提升數據壓縮率的機會，而且無法達到“壓縮與檢索聯合設計”所能夠同時實現的高壓縮率、低檢索延遲的雙重目標.

3）數據模式感知的低成本云日志存儲系統最大的成功經驗在于通過引入數據模式實現了“壓得狠”和“查得快”這一對看似矛盾的目標的和解.“壓得狠”和“查得快”的矛盾焦點在于數據的壓縮粒度，即將多少數據、哪些數據壓縮到一個存儲單元的問題：如果壓縮粒度過大，更多的數據被壓縮到一起，去冗機會增多，但是每一次訪問時解壓的數據量也隨之增加；反之如果壓縮粒度過小，每次訪問時可以按需要進行解壓，但卻降低了數據去冗的機會.通過挖掘數據模式，我們找到了數據壓縮的最佳粒度，即將數據模式中出現在同一個位置的變量值壓縮到一起，例如靜態模式中的變量組、動態模式中的子變量組等.一方面，該方法可以最大限度保證不同組之間的冗余相對較少，進而保證針對每一個組單獨進行編碼和將所有組放在一起進行編碼的壓縮率差別不大，但前者的編碼粒度顯然更細.另一方面，該方法還能保證屬于同一組內的數據具有一定的共性特征，同時在訪問時也傾向于被一起訪問，這就為有針對性的數據編碼和減少解壓的細粒度的數據過濾提供了可能.

未來的低成本存儲系統設計應當結合數據的全生命周期和領域特征，有針對性地開展數據編碼與壓縮.模式感知的思路不僅可以應用于半結構化的日志數據，在海量非結構化的數據中，也可以探索更為先進的模式識別方法找到對應的模式和變量組，并通過變量組編碼來實現“壓得狠”和“查得快”的雙重目標.

6 總結與展望

本文總結了一類新興的大數據——云日志大數據的數據特點和存儲挑戰，介紹了數據模式感知的低成本云日志存儲系統的核心設計思想.詳細介紹了目前國內外已有的低成本云日志存儲系統所使用的日志數據模式及其具體使用方法，并對若干典型方法進行了測評與分析.最后介紹了我們在設計數據模式感知的低成本云日志存儲系統時的經驗與思考.

目前還沒有一款云日志存儲系統能夠在壓縮率、壓縮速度和檢索延遲這3 個維度上同時達到最優，該目標的主要挑戰在于如何在低提取成本但效果有限的全局模式提取方法與高提取成本但效果更好的局部模式提取方法之間做權衡.希望相關領域的研究可以不斷進步、推陳出新.另一方面，日志壓縮也可以考慮從日志產生的源頭上入手，通過改進程序中的結構化輸出語句和日志產生的方式盡量降低日志數據中的冗余（例如ErrorLog[44]，LogAdvisor[45]等），并最終實現日志程序和日志處理程序的協同設計.

同時，我們也希望看到更多其他領域的大數據存儲可以結合本領域特征有針對性地設計低成本存儲系統，以進一步降低數據存儲成本和能源資源消耗.

作者貢獻聲明：魏鈞宇和張廣艷提出了寫作思路和實現方案；魏鈞宇和陳軍超負責實現并撰寫論文；張廣艷提出指導意見并修改論文.