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