張晗,周敏奇
(華東師范大學數據科學與工程學院,上海200062)
面向CLAIMS基于Smart物化策略的列存儲設計與實現
張晗,周敏奇
(華東師范大學數據科學與工程學院,上海200062)
物化是列存儲數據庫查詢中必不可少的操作,物化策略和物化技術在查詢執(zhí)行過程中起著至關重要的作用.因此設計一種針對列存儲數據庫的物化策略尤為重要.提前物化生成的元組中存在無關屬性;而延遲物化對選擇率較高的查詢可能無法優(yōu)化其性能,且某些列會被訪問多次.針對以上缺點,本文提出了有別于上述兩種策略的策略——Smart物化策略.本文提出了在邏輯查詢計劃中使用結構——projection,該結構是由用戶選取查詢所需的屬性來生成的,相當于對全表進行物理上的切分;在查詢開始時,能減少直接加載到內存的數據量,避免額外的開銷.在構建邏輯查詢計劃過程中,Smart物化策略將projection作為掃描操作標準來對數據進行按列劃分,根據一組語句集中對列訪問的相關性來對下一次查詢所需要的列進行預測,將所需要的列加入到一個最合適的projection中來進行物化.本文通過在分布式內存數據庫CLAIMS上使用TPC-H數據集來驗證其有效性.
projection;Smart物化;數據壓縮
隨著互聯網技術的發(fā)展、計算機硬件的不斷更新、企業(yè)及政府信息化的不斷深入,行存儲數據庫所涉及應用的復雜性越來越高.海量數據管理、實時數據分析、商務智能、決策支持等應用對系統的可擴展性、數據分析的實時性提出了新的挑戰(zhàn).在實時海量數據分析方面,基于行存儲的傳統關系型數據庫技術逐漸顯得性能低下,并形成了數據處理技術的瓶頸,尤其是在超大數據集的匯總、關聯操作方面操作開銷越來越大.而列式數據庫系統采用基于按列存儲的存儲策略,適用于面向企業(yè)決策分析領域的實時數據分析處理,尤其在金融交易數據分析上應用廣泛.
按列存儲在復雜數據查詢中,因其只讀取相關列的數據,大大減少內存數據量和I/O(Input/Output)開銷,從而提高了查詢的效率;同時,在列上建立索引使得信息檢索的速度達到秒級.數據壓縮是列存儲數據庫的顯著特點之一,通過算法將數據文件進行合理壓縮,減少存儲的數據量.現有列式存儲引擎C-store[1]可以直接對壓縮數據格式進行操作,減少了操作過程中的數據量,提高了讀操作的速度.對于現代CPU(Central Processing Unit)而言,CPU在緩存中找到有用的數據稱為命中;當緩存中沒有CPU所需的數據時(未命中),CPU才訪問內存.所以,CPU訪問內存的頻率越低(也稱未命中頻率),查詢的效率就越高,在列式數據庫中使用數據成組迭代技術有助于提高緩存的命中.同時,列式存儲具有高度的可壓縮性,從而提高了CPU的吞吐量.延遲物化作為列式存儲的關鍵技術之一,其使得查詢引擎并不直接在物理上的數據進行操作,而是以指針形式處理數據,保證數據的完整輸出,盡可能地推遲構建元組的時間.然而物化作為影響列存儲數據庫的性能關鍵,最需要考慮的問題是何時將不同列組合構建成新的元組.提前物化會導致在構建過程中添加與查詢語句無關的屬性,而延遲物化通過推遲元組的構建,從而達到構建元組屬性最少、生成元組最少的效果;但是某些列會訪問兩次以上,浪費了CPU資源.針對上述問題,本文提出了一種Smart物化方式,不同于傳統的提前物化和延遲物化,該物化方式僅將相關屬性構建進元組中,同時在該策略中使用projection的結構來避免對某些列訪問兩次,造成CPU資源的浪費.本文主要貢獻在以下3個方面.
(1)提出了一種新的物化策略—–Smart物化.
(2)為CLAIMS系統底層設計列存儲引擎.
(3)在CLAIMS系統上驗證Smart物化策略的有效性.
論文的內容安排如下:第1節(jié)主要介紹列存儲數據庫使用的相關技術;第2節(jié)介紹現有列存儲數據庫中的物化策略;第3節(jié)介紹基于Smart物化的優(yōu)化方案;第4節(jié)主要針對基準數據集TPC-H與不同的分布式內存計算模型進行性能對比;第5節(jié)總結Smart物化策略在數據分析系統以及CLAIMS系統上性能的提升.
按列存儲的概念早在1985年的論文[2]中即已提出,簡稱DSM(A Decomposition Storage Model),是列數據庫的雛形,但是這種技術在當時并沒有得到足夠的重視.近些年來,在以Michael Stonebraker、Daniel J.Abadi、Peter Boncz為首的一批專家的大力提倡下,圍繞列存儲數據庫的商業(yè)價值以及列數據庫主要關鍵技術(包括存儲壓縮、延時物化、成組疊代、查詢優(yōu)化、索引、加密等)的研究和應用快速發(fā)展,在金融數據分析領域開辟出了一條新道路.文獻[3]明確指出,在不斷變化的時代中,指望一個數據庫產品就能夠一統天下的日子已經一去不復還了.目前開源列數據庫有C–Store、rasdaman、MonetDB等,商用列數據庫有Sybase IQ、Vertica Analytic Database、ParAccel Analytic Database、EXASOL EXASolution等.
在當前計算速度快速增長的時代,I/O漸漸成為硬件瓶頸,計算帶寬遠遠高于I/O帶寬,盡管數據存儲的硬件從原先的普通硬盤SATA發(fā)展到SSD,數據持久化方式從HDFS發(fā)展到內存中的mem-cache,I/O的劣勢仍然明顯.雖然在現有數據庫中使用了多種方式來平衡計算與I/O速度的差距,但是考慮到商用的使用環(huán)境,將數據進行壓縮仍顯得尤為必要[4-5].
公式(1)說明了數據壓縮的必要性,同時性能指標如下.
其中,B為I/O帶寬,C r表示壓縮比,Q為查詢帶寬,D為解壓縮帶寬,R為生成結果的帶寬,B C r表示數據傳輸的帶寬,即表示數據處理過程的帶寬.查詢過程中主要分為兩個階段,數據傳輸階段和數據處理階段.數據傳輸主要的瓶頸是I/O,在分布式情況下網絡傳輸也作為衡量指標;數據處理細分為兩個階段,數據解壓縮和數據查詢,這個階段主要的開銷在于CPU的處理速度上.這兩個階段與生產者和消費者模型類似,哪個環(huán)節(jié)慢就會拖累整個過程,并成為生成結果的帶寬.當I/O為瓶頸時,數據傳輸的開銷會更大,此時CPU會等待數據從磁盤導入到內存中,對數據進行解壓縮.此外當集群計算資源不足時,解壓縮速度越快,查詢時間也越短.但在計算資源富足時,則壓縮比越大越好.使用專門針對列式存儲的壓縮算法,有助于執(zhí)行引擎直接對壓縮數據進行操作.在開源的存儲引擎parquet、ORC中,都將數據壓縮作為必要的操作.
1.1.1 字典壓縮
字典壓縮模式可能是在當今數據庫中最為常見的一種壓縮模式.通過這種方式可以將經常使用的模式替換成很小的編碼,建立編碼與被替換的模式之間的映射關系,將這樣的映射關系作為字典進行查詢.如圖1所示.
字典壓縮的優(yōu)勢是將每個屬性的內容映射成簡短的編碼,以此來調高屬性元素的頻繁度.如果在列上建立索引,可將不同元組屬性中的相同成分保存在同一條目中,減少保存元組所需要的條目.
然而列式存儲的字典壓縮也存在一定缺陷,例如,基準測試集TPC-H中的大表LINEITEM中的屬性L EXTENDEDPRICE,經由字典壓縮后,生成的字典表的耗時較大,增加了額外的開銷.
圖1 字典編碼Fig.1 Dictionary coding
1.1.2 行程編碼
行程編碼將列中相同元素統一轉換成一個值進行表示,這種方案比較適合已經排過序且大小比較合理的列,通過三元組進行管理(值、起始位置、長度).
如果使用行存儲,那么存儲的數據必須是稀疏的或是大量重復的數據,否則產生的三元組的數量將會接近元組的數量,產生更大的額外開銷.面對TPC-H數據集,該編碼幫助減少的數據量也非常有限.它比較適用于已經排好序的、包含極少不同元素的列存儲數據,比如交易操作的數據集.
1.1.3 位圖編碼
當列中的元素個數有限時,位圖編碼更為合適.該方法通過0或1來表示元素在某位置上是否存在來進行編碼,將元組轉換成為二元組的形式(元素值、表示出現位置的位圖).行存儲利用這種編碼方式來生成索引,來提高查詢速度.相比較行存儲,列式存儲更為直接的將數據進行轉換和去重.在無序和較少不同元素的列中,位圖編碼發(fā)揮的作用更大.然而當數據選擇率高時,生成的位圖會更加稀疏,不利于存儲.所以使用位圖編碼時,應該更加慎重考慮使用場景.
1.1.4 輕量級壓縮
字典壓縮、行程編碼、位圖編碼等3種壓縮方式,對按列存儲的數據格式的優(yōu)化簡單而直接,然而各自都存在缺點.針對測試數據集TPC-H來說,LINEITEM中的屬性L EXTENDEDPRICE不管用哪種壓縮方式都不能將壓縮比提高到0.4.面對較大的數據量,需要使用通用壓縮的方法以將該列切分成數據塊進行壓縮.相比較重量級壓縮,通用壓縮雖然不能極大地壓縮數據達到最好的壓縮比,但極快的解壓縮速度是其優(yōu)點.在優(yōu)化分布式數據庫的網絡方面,解壓縮速度是作為考慮的因素.Snappy[6]壓縮具有較快的速度、高穩(wěn)定性和較好的魯棒性,其壓縮速度可達到250 MB/s,無需匯編代碼.Google數據中心大量使用了該算法進行壓縮,壓縮數據達到PB級,可以保證其穩(wěn)定性.我們選用該壓縮算法作為CLAIMS系統壓縮方案中的一個算法.
CLAIMS是分布式內存OLAP系統,主要提供高可用的實時查詢和數據的實時注入.作為關系型數據庫,支持SQL92標準,設計采用傳統迭代器模型并使用彈性流水線并發(fā)提高查詢速度[7].作為內存數據庫,CLAIMS將數據加載到內存中駐存,數據在內存中進行計算,避免了多余的I/O開銷[8].作為分布式數據庫,CLAIMS采用主從節(jié)點的模式(Master/Salve),集群中有唯一的主節(jié)點作為任務的調度者,主要負責接收SQL語句,解析并生成查詢計劃樹,通過任務調度器將任務分發(fā)給其他從節(jié)點,收集并匯總從節(jié)點返回的結果信息;從節(jié)點主要計算主節(jié)點分發(fā)的任務,并將執(zhí)行結果返回給主節(jié)點.
主節(jié)點(Master)由SQL解析器(SQL Parser)、查詢優(yōu)化器(Query optimizer)、元數據管理器(Catalog)、資源管理器(Resource)、任務調度器(Scheduler)、協調器(Coordinator)等6個部件組成;而從節(jié)點(Salves)主要包括執(zhí)行器(Executor)、資源管理器(Resource)、本機調度器(Coordinator)和存儲引擎(Stroage)等4部分.如圖2所示.
圖2 CLAIMS架構Fig.2 The architecture of CLAIMS
本文在實現的物化方案中智能地調整元組構建所需的屬性,使其物化產生的元組在一系列查詢語句中達到較好的效果.
執(zhí)行一個查詢計劃的原始方法是對運算進行適當的排序,并且將每個運算的結果存儲在磁盤上直到它被另一個運算所需要,這種策略叫做物化.在現今硬件技術的發(fā)展下存儲設備單位價格降低,大容量內存成為可能,因此可以將較大的中間結果物化到內存中,以此來提高查詢性能.物化技術作為提高數據庫查詢性能的重要手段是數據庫領域研究的熱點,例如Vertica通過對延遲物化和提前物化這兩種物化策略的權衡,選擇代價較低的物化策略,來提高查詢速度.本文通過分析大數據的數據特征以及影響物化的操作、查詢語句的頻率和列與列之間的相關性,提出基于列存儲的分布式內存數據系統的物化策略.
提前物化是盡可能早的構建元組,以便在查詢計劃中生成需要的元組值.在列存儲數據庫中,列數據將被加載到內存中進行解壓縮,并被拼接成行數據.提前物化的好處是,列在查詢過程中被訪問,將其直接物化到中間結果中,減少了額外訪問的開銷.但會帶來以下問題:所有數據都被解壓縮;無關屬性添加到元組增加了查詢的開銷;內存資源不足.
延遲物化針對壓縮的列式數據有著很高的性能,例如列數據庫c-store中所實現的列式查詢引擎可以直接針對壓縮數據進行操作[9].同時,延遲物化能在查詢計劃中推遲構建元組時間,以生成較少的元組,提高查詢速度.由Daniel的文章[10]中可以知道在查詢中延遲物化的效果會更加好,特別是復雜查詢語句.在列式執(zhí)行引擎中,join操作最為影響性能,尤其是有很高選擇率的join操作或者join操作生成的結果接著進行聚合操作的情況,而針對復雜join操作使用延遲物化策略能夠得到良好的性能.但是延遲物化也有一定缺陷,它會在查詢計劃中導致某些列被多次訪問.假設某列首先通過匹配謂詞來獲得位置信息,然后再次訪問來獲取值;當查詢過程中沒有使用到索引時,列是被訪問了兩次,例如在join操作之后再進行排序就會造成額外的成本開銷.即使在查詢過程中使用流水線模式和高速緩存,CPU的計算資源依然會有一部分浪費在查找數據塊位置上.具體見算法1.
上述算法表述:從判定條件的條件F中,將條件所在的列分別用位向量選擇標定;生成的位向量與相關列進行邏輯與運算;根據之后生成的查詢結果物化元組,如果SQL語句中有聚集操作,需將物化的元組進行聚集操作;生成最后的結果.
針對前兩種物化策略的缺陷進行優(yōu)化的Smart物化是基于動態(tài)projection來進行物化的策略.基于動態(tài)projection的關系型數據庫可以選擇查詢樹中任何一個算子進行物化操作.在查詢計劃樹中向上迭代邏輯projection,直到在任何需要的算子位置進行物化[11-12].該物化策略在行存儲CLAIMS系統進行驗證.
CLAIMS系統中存在名為projection的結構,實際上是一種在行式存儲中減少數據量的結構.在數據注入這一過程中,根據建表與構建projection的信息,將元組按照用戶自定義projection所含有的屬性成分生成新的元組[13],以此來避免過多不必要的數據加載到內存中,將內存池的大小控制在一個可控的范圍內,不會使得某一臺機器因為內存不足而宕機
在同一表上會有多個projection,projection是行存儲直接進行物化的標準,每一個projection在數據注入階段,都會生成一個符合自己模式(schema)的元組.這就導致同一元組的不同屬性可能會落盤多次,數據在內存中產生了冗余,大大浪費存儲空間;而頻繁地執(zhí)行換入換出策略將產生大量的I/O操作,降低了查詢速度[14].
圖3 projection的結構Fig.3 The structure of projection
為了解決上述問題,本文將數據由行存儲轉換成列存儲,將projection僅僅作為邏輯結構在查詢樹中向上迭代,根據查詢優(yōu)化器執(zhí)行列剪枝,將邏輯結構的projection中的屬性不斷優(yōu)化,減少所需要的屬性個數.為了保證數據可以復用,根據一段時間內輸入的查詢語句生成最優(yōu)的projection,將projection中對應的列式結構進行物化,從而降低數據的選擇率,減少數據量,加快查詢速度.
盡管在邏輯查詢計劃中以projection進行操作的,但實際上底層數據存儲的形式是按照列進行存儲的,projection只是持有屬性的元數據,因此在同一個表構建多個projection時,內存僅僅維護一份數據,在確定物化的時機時,會生成最優(yōu)的projection;同時底層文件系統存儲的列式結構數據將根據最優(yōu)的projection生成數據并物化到內存中.
目前Hbase以及Facebook開發(fā)的persto數據庫的底層設計都是列簇的形式.列簇不是將元組拆分成單列,而是將多列以簇的形式作為整體進行管理.Hbase表中的每一列,都歸屬于某一列簇,而列簇僅僅是表的一部分.projection由原來的全表部分屬性的組合,重新定義為列簇.細化projection的投影范圍,將原有projection由列簇projection替代.
圖4 projection中的列簇Fig.4 The family of column in projection
根據每次查詢產生的查詢樹,向上迭代projection得到最優(yōu)projection[15],將其物化結果存放在內存中.而當同一組的每條查詢語句得到的最優(yōu)projection相差不大時,則生成最大包含的projection,以保證每條語句所需要的列信息都囊括在當前的projection中.然而這會造成projection漸漸擴張成為全表的projection,這樣就無法減少數據選擇率.
針對projection的動態(tài)生成,需要檢測查詢語句與projection中列的相關性.通過每次查詢產生需要的列來與全表中列進行權重的更新.我們選取權重較大,且相差不多的列生成projection.具體見算法2.
對于每一條屬于Q中的q來說,參考表中屬性進行聚類,并分配到第i個簇中.通過與簇中語句進行比較距離,距離主要是兩條SQL語句中相同屬性的個數來確定.如果語句q與ri屬性有差距不大,那么將不相同的屬性設置一個權重添加到第i個簇中.每一個簇中的屬性列表就是構成projection的參考.使用貪心算法確定ri中的哪些屬性應該用來動態(tài)生成projection.
根據查詢語句的不斷變化,該算法將延遲地改變projection的屬性.projection在擴張與收縮的物化過程中,一直保留一份projection,此方案減少了內存中冗余的數據,同時也減少了I/O操作,其代價的僅為內存中元組切分或拼接的操作,顯然開銷是微不足道的.
基于CentOS release 6.5(Final)系統,CPU型號為Intel(R)Xeon(R)CPU E5-2620 0@ 2.00 GHz,雙路,共12核,可超線程到24核,每各節(jié)點擁有165 G的內存和1T大小的硬盤,每個節(jié)點之間通過千兆網進行互聯.選取標準的基準數據TPC-H進行測試,分別測試擴展因子為1、10以及100的數據,其中TPC-H數據集有8個事實表.TPC-H是用3NF實現的,TPC-H基準測試的度量單位是每小時執(zhí)行的查詢數—–QphH@size,其中,Qph是Query-per-hour(每小時查詢),H表示每小時系統執(zhí)行復雜查詢的平均次數,size表示數據庫規(guī)模的大小,它能夠反映出系統在處理查詢時的能力[16].
本文將Smart物化實現于分布式內存關系型數據庫CLAIMS上,以此來進行其性能評估. CLAIMS是開源的分布式內存數據庫,運行在NUMA架構的集群上,支持數據實時注入和實時查詢.列式存儲的缺點是在寫過程中增加了拆分元組的操作,增加了CPU的開銷,而在讀操作上進行了優(yōu)化.同時,數據在內存中的復用也作為性能考核的指標,不過內存中數據的復用是顯然的,隨著構建projection的增加,先前版本會不斷地增加數據量,造成內存和磁盤上的數據膨脹,同時頻繁的換入換出也增加了I/O的開銷.
實驗1:將列式版本與之前版本進行內存中數據量的比對
在CLAIMS上構建全表大小的projection以及不同種的projection,原CLAIMS以行的形式存儲,必然會造成數據的冗余,從而增加了內存的負擔以及I/O開銷.圖中可以看到數據量在列式的情況下并沒有多余的增長,而原CLAIMS內存中的數據在不斷的膨脹.同時操作系統也會頻繁地進行換入換出操作,降低查詢效率.
圖5 內存中的數據量Fig.5 The delay of three materialization strategies in di ff erent query
表1 在不同SQL語句中3種物化策略的時延Tab.1 Simulation results of parametric estimation
通過比較表中查詢語句的結果可以得出,Smart物化在初期的物化時延其實與延遲物化是一樣的.但隨著查詢語句間相關性的比對,projection將被保持在一個最大包含的相關屬性的范圍內,在后期則不再需要進行物化操作,而能將之前生成好的元組直接給下一次查詢進行使用,減少了I/O以及物化的開銷;同時如果某一列的權重過低,Smart物化策略會重新進行物化,排除掉這一列.
CLAIMS系統當前版本并不支持列式存儲的格式,同時數據會在構建表的過程中造成冗余. Smart物化策略解決了列數據在何時物化成元組,同時Smart物化能盡量減少物化過程中的元組數量.在不同的執(zhí)行語句中,不同的選擇率導致需求的projection不盡相同,但是通過動態(tài)收縮projection的大小,物化過程中元組的數據量大小能夠得以維護.
[1]STONEBRAKER M,ABADI D J,BATKIN A,et al.C-store:A column-oriented DBMS[C]//International Conference on Very Large Data Bases.DBLP,2005:553-564.
[2]COPELAND G P,KHOSHAFIAN S N.A decomposition storage model[C]//ACM SIGMOD International Conference on Management of Data.ACM,1985:268-279.
[3]STONEBRAKER M,ETINTEMEL U.“One Size Fits All”:An idea whose time has come and gone[C]// International Conference on Data Engineering.IEEE,2005:2-11.
[4]CORMACK G V.Data compression on a database system[J].Communications of the ACM,1985,28(12): 1336-1342.
[5]黃鵬,李占山,張永剛,等.基于列存儲數據庫的壓縮態(tài)數據訪問算法[J].吉林大學學報(理學版),2009,47(5):1013-1019.
[6]Google Snappy[EB/OL].[2017-04-01].https://github.com/google/snappy.
[7]WANG L,ZHOU M,ZHANG Z,et al.Elastic pipelining in an in-memory database cluster[C]//ACM SIGMOD. ACM,2016:1279-1294.
[8]SIKKA V,RBER F,GOEL A,et al.SAP HANA:The evolution from a modern main-memory data platform to an enterprise application platform[J].Proceedings of the Vldb Endowment,2013,6(11):1184-1185.
[9]ABADI D,MADDEN S,FERREIRA M.Integrating compression and execution in column-oriented database systems[C]//ACM SIGMOD International Conference on Management of Data.DBLP,2006:671-682.
[10]ABADI D J,MYERS D S,DEWITT D J,et al.Materialization strategies in a column-oriented DBMS[C]// 2007 IEEE 23rd International Conference on Data Engineering.IEEE,2007:466-475.
[11]CORNELL D W,YU P S.An ef f ective approach to vertical partitioning for physical design of relational databases [J].IEEE Transactions on Software Engineering,1990,16(2):248-258.
[12]BRYANT R E,HALLARON D R O’.深入理解計算機系統[M].龔奕利,雷迎春,譯.北京:機械工業(yè)出版社,2011.
[13]IDREOS S,KERSTEN M L,MANEGOLD S.Self-organizing tuple reconstruction in column-stores[C]//ACM SIGMOD International Conference on Management of Data.ACM,2009:297-308.
[14]楊傳輝.大規(guī)模分布式存儲系統[M].北京:機械工業(yè)出版社,2013.
[15]BRUNO N,CHAUDHURI S.To tune or not to tune?:A lightweight physical design alerter[C]//International Conference on Very Large Data Bases.VLDB Endowment,2006:499-510.
[16]TPC Benchmark H[EB/OL].[2017-04-01].http://www.tpc.org/tpch/.
(責任編輯:李藝)
Design and implementation of Smart materialization for column-store in CLAIMS
ZHANG Han,ZHOU Min-qi
(School of Data Science and Engineering,East China Normal University, Shanghai 200062,China)
Materialization is a necessary operation in the process of query execution. Materialization strategy and materialization technology play an important role in the process of query execution.Therefore,it is necessary to design a materialization strategy for column-store database.According to the shortcomings of early materialization and later materialization,we provide a strategy named Smart materialization that are dif f erent from the two strategies mentioned above.Here we need to def i ne a concept in the logical query plan—projection,the structure is used to select the desired attributes,the physicaltable is cut by column,to ensure that the structure at the beginning of the query can reduce the direct load to memory of the amount of data,to avoid additional overhead.In the logical query plan,the projection is divided by columns,and the next required columns are predicted according to the relevance of the query in a set of queries,and the required columns are stabilized in one of the most appropriate projection.We use the data set of TPC-H to verify its validity worked on the disturbed in-memory database—CLAIMS.
projection;Smart materialization;data compression
TP311
A
10.3969/j.issn.1000-5641.2017.05.004
1000-5641(2017)05-0030-10
2017-06-19
國家自然科學基金(61672233)
張晗,男,碩士研究生,研究方向為內存數據庫系統.E-mail:chxiaoyifeng1992@gmail.com.
周敏奇,男,副教授,研究方向為對等計算、云計算、分布式數據管理、內存數據庫管理系統. E-mail:mqzhou@sei.ecnu.edu.cn.