0
| 本文作者： 高婓 | 2016-09-07 17:34 |
編者按：作者Pedro Eugênio Rocha 現(xiàn)任Facebook系統(tǒng)工程師，2016年畢業(yè)于巴西巴拉那州聯(lián)邦大學(xué)信息學(xué)專業(yè)，研究興趣包括數(shù)據(jù)庫與存儲系統(tǒng)，尤其是與分布式系統(tǒng)和大數(shù)據(jù)相關(guān)的數(shù)據(jù)庫與存儲系統(tǒng)。作者在文章中介紹了Cubrick：一種多維內(nèi)存數(shù)據(jù)管理系統(tǒng)。Cubrick是由Facebook開發(fā)的新型分布式多維內(nèi)存數(shù)據(jù)庫管理系統(tǒng)，其目的在于解決大量數(shù)據(jù)資源并行運行所存在的問題。為達(dá)到交互式分析高度動態(tài)數(shù)據(jù)集這一目的，Cubrick運用一種用于管理柱形內(nèi)存數(shù)據(jù)的新策略，這種策略允許在數(shù)據(jù)集的每一個維度中進(jìn)行索引過濾，并有效地實時更新。
大數(shù)據(jù)集實時分析已經(jīng)成為眾多互聯(lián)網(wǎng)公司的廣泛需求。最大限度縮小數(shù)據(jù)生成與數(shù)據(jù)分析之間的時間差使得數(shù)據(jù)驅(qū)動的互聯(lián)網(wǎng)公司能夠及時形成見解，做出決策，最終能夠促進(jìn)自身快速發(fā)展。為了實現(xiàn)實時分析，需要構(gòu)建一個數(shù)據(jù)庫系統(tǒng)，保證該系統(tǒng)能夠連續(xù)不斷地獲取由網(wǎng)絡(luò)日志生成的數(shù)據(jù)流，在數(shù)據(jù)生成幾秒后應(yīng)答查詢需求。鑒于有一些實時數(shù)據(jù)流每秒鐘能夠釋放出幾百萬條記錄，大規(guī)模獲取這些高動態(tài)化數(shù)據(jù)集將面臨越來越多的挑戰(zhàn)。
此外，所有的數(shù)據(jù)庫查詢需要在數(shù)百毫秒內(nèi)完成，為用戶提供一種真實的交互式體驗，以便充分挖掘數(shù)據(jù)的利用價值，但是，事實上，在如此短的時間內(nèi)瀏覽大型數(shù)據(jù)集要求大量并行運行，因而龐大的數(shù)據(jù)資源成為必須的硬件條件。但是，在Facebook過去幾年的工作中，我們觀察過一些實用案例，在這些案例中所有的查詢都經(jīng)過過度過濾，此外，我們只關(guān)注一種超大型數(shù)據(jù)集中的小部分特定子集。例如，一項查詢可能只對某一特定人口統(tǒng)計學(xué)中的一種度量方法感興趣，例如，限定于住在美國的人群，或來自某一特定性別的人群，測定會話量，查詢某一特定群體，或提及某一特定標(biāo)簽?？紤]到應(yīng)用哪些過濾條件取決于數(shù)據(jù)分析師對數(shù)據(jù)集中哪些部分感興趣，這類過濾條件多為點對點模式，使得傳統(tǒng)的一維預(yù)定義的索引變得不那么有效。
Cubrick是由Facebook開發(fā)的新型分布式多維內(nèi)存數(shù)據(jù)庫管理系統(tǒng)，其目的在于解決大量數(shù)據(jù)資源并行運行所存在的問題。為了交互式分析高度動態(tài)數(shù)據(jù)集，Cubrick運用一種用于管理柱形內(nèi)存數(shù)據(jù)的新策略，這種策略允許在數(shù)據(jù)集的每一個維度中進(jìn)行索引過濾，并有效地實時更新。這種數(shù)據(jù)管理策略與一種特殊式且經(jīng)過優(yōu)化的查詢引擎相結(jié)合使得Cubrick成為唯一一種適合交互式實時分析的數(shù)據(jù)管理系統(tǒng)，并且使得Cubrick達(dá)到目前數(shù)據(jù)庫解決方案尚未實現(xiàn)的數(shù)據(jù)管理規(guī)模。
本周印度新德里國際頂級數(shù)據(jù)庫會議(VLDB)上我們即將呈現(xiàn)的論文Cubrick: Indexing Millions of Records per second for Interactive Analytics一文中，我們描述了被命名為Granular Partitioning 的Cubrick新型數(shù)據(jù)管理技術(shù)，詳細(xì)介紹了Cubrick的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，分布式模型與查詢執(zhí)行引擎，并將宣布目前Facebook對這種新型數(shù)據(jù)管理系統(tǒng)的應(yīng)用情況。
通過跳過非必要數(shù)據(jù)來提高過濾性能的傳統(tǒng)數(shù)據(jù)庫技術(shù)要么是基于維護(hù)索引（輔助數(shù)據(jù)結(jié)構(gòu)），要么是基于對數(shù)據(jù)集進(jìn)行預(yù)整理。通過維護(hù)輔助索引（如B+Trees）來提高獲取特定記錄的效率是一種為大多數(shù)數(shù)據(jù)管理系統(tǒng)運用的眾所周知的技術(shù)，且?guī)缀趺恳环NOLTP數(shù)據(jù)管理系統(tǒng)均運用這種數(shù)據(jù)庫技術(shù)。但是，在OLAP負(fù)載中，維護(hù)更新索引的對數(shù)開銷由于被視為表的大小和獲取數(shù)據(jù)速率的度量而被禁止。在存儲痕跡中，大多數(shù)類型的索引（著名的是二級索引）通過增大所占據(jù)的存儲空間來存儲中等結(jié)點和數(shù)據(jù)指示值，以便于在每一欄建立索引可能會致使存儲使用率成倍增長。此外，如何準(zhǔn)確地確定索引欄是點對點查詢面臨的一項挑戰(zhàn)。
在查詢時間內(nèi)有效跳過數(shù)據(jù)的另一途徑是預(yù)整理數(shù)據(jù)集。基于C-STROE架構(gòu)建立的以欄為導(dǎo)向的數(shù)據(jù)庫能夠維護(hù)按照關(guān)鍵字排序的數(shù)據(jù)集的多種復(fù)制版本——也被稱為映射——也能夠被用于有效評估按照關(guān)鍵字排序的每一欄中的過濾器性能。盡管一種與LSM-Tree（日志結(jié)構(gòu)的合并樹）相似的結(jié)構(gòu)被用于攤還插入所帶來的計算成本，隨著所獲取數(shù)據(jù)的規(guī)模不斷擴(kuò)大，仍然需要大量的數(shù)據(jù)重組來保證映射結(jié)果的實時更新。此外， 我們得預(yù)先決定要創(chuàng)建哪些映射機(jī)器相對應(yīng)的排序關(guān)鍵字，這些在由點對點查詢構(gòu)成的數(shù)據(jù)集中難以定義。最后，由于每一次新的映射都是對整個數(shù)據(jù)集的復(fù)制，這種方式不適用于數(shù)據(jù)管理系統(tǒng)的內(nèi)存設(shè)置，這種數(shù)據(jù)管理系統(tǒng)試圖在其內(nèi)存中擬合盡可能多的數(shù)據(jù)集，以避免對硬盤進(jìn)行繁重訪問。
我們已經(jīng)采用一種新方法而非通過預(yù)整理數(shù)據(jù)集或維護(hù)二級索引數(shù)據(jù)結(jié)構(gòu)這兩種方法，來解決如何跳過非必要數(shù)據(jù)以提高過濾器性能這一問題。假定系統(tǒng)中所有的表格都是被每一維度列進(jìn)行分區(qū)排列的，我們對傳統(tǒng)的數(shù)據(jù)庫分區(qū)概念進(jìn)行擴(kuò)展。同時，能夠預(yù)先獲取每一維度列的基數(shù)，這允許我們將數(shù)據(jù)集理解為一個有更小的超立方體構(gòu)成的大立方體，在一定程度上更像一個n維魔方。每一個較小的超立方體（或brick,Cubrick的一種術(shù)語表達(dá)法）代表基數(shù)函數(shù)分配的一個標(biāo)識符，以一種無序且附注的形式在每一列中零散地存儲數(shù)據(jù)。最后，我們假定，所有的字符串值都是經(jīng)過代碼編碼的，內(nèi)部是由單調(diào)遞增的整數(shù)表示的。該假設(shè)便于我們開發(fā)一種僅在原始數(shù)據(jù)層面運行的經(jīng)過優(yōu)化的，精細(xì)的數(shù)據(jù)庫引擎。
與其他多維數(shù)據(jù)庫系統(tǒng)相似，Cubrick的每一列均以一種度量或一種維度進(jìn)行定義，這些維度通常被用于過濾和分組，每一種度量被用于聚合函數(shù)中。圖1闡釋了：在一個由兩個維度——區(qū)間和性別，基數(shù)為4，變化尺寸為2和1，與兩種度量——喜好和評論，構(gòu)成的一個數(shù)據(jù)集例子中，如何為每一模塊分配數(shù)據(jù)記錄。
鑒于有一種連續(xù)性的時間函數(shù)將每一條記錄映射到與之相匹配的目標(biāo)模塊中，而且每一模塊中的數(shù)據(jù)都是無序排列的，這種簡單卻有效的數(shù)據(jù)管理方法考慮到非常有效的記錄插入。此外，如果在搜索空間內(nèi)沒有插入記錄，在查詢時間段內(nèi)，每一模塊都能夠輕松地與查詢過濾器相匹配，并得到梳理。
為了評估Cubrick獲取記錄的速率與獲取記錄通道所占用的CPU，圖8所示為：與CPU占用量相比，每個單一結(jié)點簇每秒獲取的記錄數(shù)量。本實驗得出以下結(jié)論：即使每秒獲取的記錄數(shù)量達(dá)到100萬，每個單一結(jié)點簇所占用的CPU依然處于低水平（20%以下）。
注：當(dāng)獲取不同容量大小的記錄時，每個單一結(jié)點簇的CPU占用情況
圖7所示為在一個72個結(jié)點簇處運行的10TB數(shù)據(jù)集存在的多種潛在查詢，旨在評估我們的索引策略是否有效。X軸代表應(yīng)用過濾器的列，顏色標(biāo)尺為這種過濾器的局限性，或該數(shù)據(jù)集與過濾器之間的匹配百分比。實驗結(jié)果顯示，Y軸上的顏色與位置存在明顯關(guān)聯(lián)性，與X軸上的位置不相關(guān)。換句話來講，不論處于哪一列，當(dāng)運用過濾器時，查詢速率將得到很大程度的提升。
注：在一個72個結(jié)點簇處運行的10TB數(shù)據(jù)集經(jīng)不同維度過濾后存在的多種潛在查詢
請參考我們在2016年國際頂級數(shù)據(jù)庫會議上發(fā)表的論文，獲得完整的實驗方法與結(jié)果。
在過去幾年內(nèi)，F(xiàn)acebbook曾在多個實時（批量）交互式分析應(yīng)用實例中采用Cubrick，Cubrick正在迅速成長為一個更為成熟的全功能數(shù)據(jù)管理系統(tǒng)。關(guān)于如何更加有效地處理具有不同數(shù)據(jù)分布特征的數(shù)據(jù)集與使這種立方體圖式更具動態(tài)化，我們還要進(jìn)行大量的研究求證。我們相信，Cubrick的研發(fā)是我們朝向這一目標(biāo)邁進(jìn)的第一步，不過，目前該研究領(lǐng)域還存在幾個尚未探索且有趣的主題等待我們開展研究。
與本文內(nèi)容相關(guān)的VLDB’16 論文鏈接論文1，論文2
本文由雷鋒網(wǎng)獨家編譯，未經(jīng)允許拒絕轉(zhuǎn)載！
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
