蔣 旭 孫 磊 譚煒波

1(天津市海量數(shù)據(jù)處理技術(shù)實驗室 天津 300384)2 (天津神舟通用數(shù)據(jù)技術(shù)有限公司 北京 100094) (jiangxu@bjsasc.com)

大數(shù)據(jù)時代已經(jīng)到來，數(shù)據(jù)庫中存儲的數(shù)據(jù)越來越多，這對原有的傳統(tǒng)關(guān)系型數(shù)據(jù)庫體系結(jié)構(gòu)[1]提出了非常大的挑戰(zhàn).傳統(tǒng)關(guān)系數(shù)據(jù)庫在聯(lián)機事務處理領(lǐng)域具有豐富的理論研究成果，但隨著大數(shù)據(jù)的到來，數(shù)據(jù)分析需求顯得越發(fā)強烈，傳統(tǒng)關(guān)系數(shù)據(jù)庫原有的行式存儲引擎、B-Tree索引結(jié)構(gòu)[2]、行級并發(fā)訪問控制機制等方面都不能夠滿足大數(shù)據(jù)分析的需求.同時在擴展性方面，傳統(tǒng)的基于單機的垂直擴展模式，已經(jīng)無法滿足目前大數(shù)據(jù)環(huán)境下計算復雜度的要求，因此要設計一種更加合理的水平擴展機制滿足計算性能擴展的需求.

此外，大數(shù)據(jù)安全問題已成為制約大數(shù)據(jù)發(fā)展的關(guān)鍵因素之一，從安全的角度考慮，大數(shù)據(jù)的到來會產(chǎn)生新的挑戰(zhàn)：由于將所有的數(shù)據(jù)都存儲在分布式環(huán)境中，大數(shù)據(jù)對于現(xiàn)有的存儲和防范措施可能提出新的挑戰(zhàn)；另一方面大數(shù)據(jù)更加容易成為網(wǎng)絡攻擊的顯著目標，大數(shù)據(jù)中數(shù)據(jù)量比較大，它的信息量也比較大，而且成本比較低，所以黑客更加樂意去攻擊；大數(shù)據(jù)加大了隱私泄露的風險.

本文從深入分析和提煉大數(shù)據(jù)場景下的真實需求，探索能夠滿足大數(shù)據(jù)存儲需要的工程解決方案，滿足我國對數(shù)據(jù)庫國產(chǎn)化進程中的需要.

1 現(xiàn)有技術(shù)路線分析

目前，國外大數(shù)據(jù)存儲領(lǐng)域主要包括兩大研究方向：以互聯(lián)網(wǎng)公司為代表的基于非關(guān)系型的NoSQL存儲平臺(代表產(chǎn)品為Hadoop[3-5],Cassandra等)；以傳統(tǒng)數(shù)據(jù)庫廠商為代表的并行分布式數(shù)據(jù)庫存儲平臺(代表產(chǎn)品為Exadata[6-9],Greenplum[10],Vertical，Netezza等).

1.1 宏觀分析

大數(shù)據(jù)存儲方案的宏觀分析重點關(guān)注的設計指標是存儲結(jié)構(gòu)、并行架構(gòu)、普適性3個方面.

1.1.1存儲結(jié)構(gòu)分析

1.1.2并行架構(gòu)分析

國外數(shù)據(jù)庫巨頭的多機MPP并行計算發(fā)展脈絡，是基于傳統(tǒng)的數(shù)據(jù)庫中的各種查詢優(yōu)化理論發(fā)展而來的，其理論積累和延續(xù)性優(yōu)于以Hadoop為代表的開源體系.以Hadoop為代表的開源體系的多機并行處于如何進行復雜業(yè)務并行的階段，而數(shù)據(jù)庫體系下的商業(yè)運營公司在經(jīng)過幾年的培育期之后，目前已經(jīng)處于如何設計更加友好的用戶體驗和如何讓多機并行對用戶更透明的階段.

單主機內(nèi)的處理能力越來越強，如何能夠更好地利用單機的性能，這也是系統(tǒng)垂直擴展能力的體現(xiàn).這一點也是在當前多機并行浪潮下，單機SMP并行非常容易被大家忽略的，在單機上的處理性能差別達到5倍甚至10倍，多機的擴展就會顯得蒼白無力.

1.1.3普適性分析

無論是大數(shù)據(jù)的應用還是傳統(tǒng)的中小型應用系統(tǒng)，數(shù)據(jù)存儲系統(tǒng)的普適性都是非常重要的非技術(shù)指標.互聯(lián)網(wǎng)公司的需求是確定且單一的，對于大數(shù)據(jù)中心，數(shù)據(jù)存儲平臺的需求是紛繁復雜的，因此存儲系統(tǒng)的普適性十分重要，要能夠適應“海量存儲、高速裝載、檢索、統(tǒng)計、分析、更新等”各種需求，其本質(zhì)是具備自管理特性的復雜存儲體系.當前開源陣營中的任何產(chǎn)品均是為滿足特定需求而設計，難以滿足大數(shù)據(jù)中心的建設需求.傳統(tǒng)數(shù)據(jù)庫廠商在存儲普適性設計中具有多年商業(yè)運營經(jīng)驗，以Oracle Exadata為代表的產(chǎn)品中的混合存儲結(jié)構(gòu)就說明了這一點.

1.2 微觀分析

大數(shù)據(jù)存儲方案微觀分析，重點關(guān)注的技術(shù)指標是精確查詢、統(tǒng)計查詢、復雜查詢3方面.

1.2.1精確查詢分析

精確查詢方面，索引是最為重要的性能提升手段，對于精確查詢性能問題主要集中在3個方面：索引模型、緩存模型和代價評估模型.

索引模型：靜態(tài)索引模型較易處理，帶有更新機制和并發(fā)控制的非靜態(tài)索引，開源引擎目前的支持大多存在設計缺陷，難以保證事務完整性.傳統(tǒng)數(shù)據(jù)庫廠商在這方面的處理具有較大的技術(shù)優(yōu)勢，且Oracle等廠商也在分析型應用方面取得了突破.

緩存模型：開源引擎一般都是依賴于底層文件系統(tǒng)的緩存模型進行緩存管理.而在軟件架構(gòu)層面上，緩存設計應更貼近計算層，其對數(shù)據(jù)熱點的判定更為準確，傳統(tǒng)數(shù)據(jù)庫在這方面已經(jīng)取得了豐碩的研究成果.

代價評估模型：開源引擎還基本沒有涉及，其大多基于規(guī)則優(yōu)化引擎進行優(yōu)化，優(yōu)化器設計較為簡陋，傳統(tǒng)數(shù)據(jù)庫在代價優(yōu)化方面已經(jīng)積累了豐富的理論和實踐經(jīng)驗，在代價評估方面開源引擎也必然要經(jīng)歷傳統(tǒng)數(shù)據(jù)庫漫長的歷史演進過程.

對于將來TB級大內(nèi)存大行其道的時候，更加精細化的索引模型和緩存策略必然成為主要的技術(shù)難點，而開源產(chǎn)品在這方面的積累十分有限，因此給后續(xù)的研發(fā)工作帶來一定的困難.

1.2.2統(tǒng)計查詢分析

統(tǒng)計查詢方面，存儲平臺的吞吐量十分關(guān)鍵，提升吞吐量主要有2種技術(shù)手段：水平擴展性和垂直擴展性.

水平擴展性：原來Hadoop等開源平臺的發(fā)展初期，在水平擴展性方面優(yōu)于傳統(tǒng)數(shù)據(jù)庫，也是其主要優(yōu)勢所在，但經(jīng)過這么多年的發(fā)展，以Share-Nothing為代表的MPP并行數(shù)據(jù)庫產(chǎn)品的出現(xiàn)，已經(jīng)吞噬了這一優(yōu)勢.

垂直擴展性：開源平臺要遠差于傳統(tǒng)數(shù)據(jù)庫，我們曾經(jīng)做過一個實際測試，對比了當前Hadoop平臺中使用較廣的一種存儲引擎Lucene和國內(nèi)數(shù)據(jù)庫廠商的HCC壓縮存儲引擎.在影響統(tǒng)計查詢性能十分關(guān)鍵的表掃描操作性能中，單線程Lucene的掃描性能不到100萬行秒，而HCC壓縮存儲引擎的掃描性能為550萬行秒.這種性能的差距是無法利用水平擴展和廉價設備所能彌補的.

1.2.3復雜查詢分析

面向復雜查詢，當前開源陣營中最為出色的當屬Hive和Pig，但其計算性能也被業(yè)界所詬病.由于其優(yōu)化器簡陋，缺乏合理的理論支撐，僅能滿足復雜查詢分析的功能需求，在性能表現(xiàn)方面不盡人意.在開源陣營內(nèi)部也出現(xiàn)了各種聲討Hive的聲音，但對于傳統(tǒng)數(shù)據(jù)庫幾十年發(fā)展而來的復雜查詢優(yōu)化經(jīng)驗，不是開源陣營幾年時間可以達到的，其道路還是十分漫長的.

綜上所述，傳統(tǒng)數(shù)據(jù)庫廠商的技術(shù)發(fā)展路線更加符合國產(chǎn)數(shù)據(jù)庫的技術(shù)脈絡，同時其在接口標準化程度、產(chǎn)品通用性、性能優(yōu)化技術(shù)的理論成熟度和產(chǎn)品發(fā)展的集約型程度等方面都要優(yōu)于互聯(lián)網(wǎng)公司的NoSQL相關(guān)產(chǎn)品，因此本次大數(shù)據(jù)存儲平臺將主要依托于此技術(shù)路線進行設計與實現(xiàn).

2 平臺設計

依據(jù)技術(shù)路線分析，大數(shù)據(jù)存儲平臺采用國外商用數(shù)據(jù)庫廠商的技術(shù)路線進行頂層設計，將大數(shù)據(jù)存儲平臺劃分為4個系統(tǒng)，分別為：平臺中心服務系統(tǒng)、平臺元數(shù)據(jù)存儲系統(tǒng)、平臺代理服務系統(tǒng)和平臺存儲訪問系統(tǒng).

2.1 平臺軟件架構(gòu)

平臺軟件架構(gòu)設計時，充分利用傳統(tǒng)關(guān)系數(shù)據(jù)庫已有的基于代價的查詢優(yōu)化技術(shù)、SMP優(yōu)化技術(shù)、緩存優(yōu)化技術(shù),設計并實現(xiàn)基于Share-Nothing的MPP平臺架構(gòu).在存儲引擎層面采用了行列混合存儲模型對原有的行式存儲引擎進行改造，整個平臺的總體軟件架構(gòu)如圖1所示.

在大數(shù)據(jù)平臺的總體架構(gòu)中，平臺中心服務系統(tǒng)相當于平臺的“大腦”.通過多機并行優(yōu)化引擎，實現(xiàn)MPP并行流水線計劃的生成與下發(fā)，并通過異步高速通信引擎實現(xiàn)對執(zhí)行狀態(tài)的統(tǒng)一控制和管理.其通過統(tǒng)一的元數(shù)據(jù)管理策略，實現(xiàn)了外部應用透明化.對外提供統(tǒng)一的單一接入點，實現(xiàn)對分布式表的各種存儲模型管理.圖2所示為平臺中心服務的系統(tǒng)架構(gòu).

圖1 大數(shù)據(jù)存儲平臺總體架構(gòu)

圖2 平臺中心服務系統(tǒng)架構(gòu)

代理服務系統(tǒng)主要完成對平臺中心服務系統(tǒng)下發(fā)任務的執(zhí)行，設計平臺代理服務系統(tǒng)的目的主要是為了分解平臺中心服務系統(tǒng)的壓力，使其不負責任務執(zhí)行，避免單一主節(jié)點成為性能瓶頸點.平臺代理服務系統(tǒng)采用在每個處理節(jié)點內(nèi)獨立部署的模式，其功能也較為簡單，主要包括任務執(zhí)行、資源管理、數(shù)據(jù)交換、心跳檢測和網(wǎng)絡管理幾個部分，具體總體系統(tǒng)架構(gòu)圖如圖3所示：

圖3 平臺代理服務系統(tǒng)架構(gòu)

圖4 平臺存儲訪問系統(tǒng)架構(gòu)

平臺存儲訪問系統(tǒng)負責執(zhí)行平臺代理服務系統(tǒng)下發(fā)的所有任務，是大數(shù)據(jù)平臺中唯一具有真實運算能力的系統(tǒng).大數(shù)據(jù)具有靜態(tài)半靜態(tài)的特征，并且其查詢需求混合了檢索類和統(tǒng)計類2種不同需求，因此需要在存儲、檢索和統(tǒng)計方面的性能和建設成本方面進行重點設計.

本文針對大數(shù)據(jù)實際應用場景的實際需求，提出的改進點[11-13]主要包括：

1) 大數(shù)據(jù)存儲優(yōu)化技術(shù).采用行列混合壓縮(HCC)技術(shù)，對數(shù)據(jù)進行壓縮存儲，降低數(shù)據(jù)存儲成本，同時提升IO為主要瓶頸的統(tǒng)計分析類查詢的執(zhí)行性能.

2) 大數(shù)據(jù)索引優(yōu)化技術(shù).針對面向大數(shù)據(jù)場景設計的HCC壓縮引擎，建立智能索引、Hash索引等特有索引優(yōu)化手段，使得壓縮態(tài)數(shù)據(jù)可以達到與非壓縮態(tài)數(shù)據(jù)同樣的查詢響應時間.

3) 大數(shù)據(jù)檢索優(yōu)化技術(shù).設計針對在大數(shù)據(jù)場景下，高并發(fā)類精確檢索查詢的優(yōu)化手段(例如：電信網(wǎng)上營業(yè)廳的清單查詢等).

4) 節(jié)點內(nèi)多核SMP并行計算技術(shù).主要用來解決統(tǒng)計分析類查詢執(zhí)行效率低下的問題.

根據(jù)上述改進策略，基于傳統(tǒng)關(guān)系數(shù)據(jù)庫系統(tǒng)進行改造后的平臺存儲訪問系統(tǒng)的系統(tǒng)架構(gòu)如圖4所示：

2.2 平臺拓撲架構(gòu)

大數(shù)據(jù)存儲平臺采用了基于MPP的Share-Nothing架構(gòu)，因此在拓撲架構(gòu)中也同樣具備這一特點.平臺內(nèi)的各系統(tǒng)部署在每個獨立存儲服務器內(nèi)，并通過千兆或萬兆網(wǎng)絡進行點對點連通.每個存儲節(jié)點具有自己獨立計算和存儲資源，最大限度地發(fā)揮多機并行的處理優(yōu)勢，圖5所示為平臺拓撲架構(gòu)：

圖5 平臺拓撲架構(gòu)

2.3 關(guān)鍵技術(shù)及解決思路

2.3.1MPP多機并行查詢技術(shù)

本文所使用的是基于Share-Nothing的無共享分布式設計架構(gòu)，無共享架構(gòu)的優(yōu)點在于可以充分利用每個計算和存儲單元的性能，實現(xiàn)吞吐量的最大化.同時無共享架構(gòu)在全數(shù)據(jù)分析中不可避免地需要進行數(shù)據(jù)分發(fā)操作，降低數(shù)據(jù)分發(fā)流量是多機并行計算架構(gòu)設計的重點.本文的大數(shù)據(jù)存儲平臺的設計方案如圖6所示.

該設計方案采用MOVE CODE TO DATA的優(yōu)化策略，即將計算放到各數(shù)據(jù)存儲節(jié)點，實現(xiàn)低網(wǎng)絡負載設計，通過頂層設計，在算子級別對計算進行分解，形成更細粒度的可下降多節(jié)點的并行執(zhí)行算子；MPP并行的分布式計算規(guī)則較為復雜，下面以分組統(tǒng)計為樣例，描述一下本方案中設計的分布式計算過程，具體計算過程如圖7所示.

圖6 MPP并行計算設計思想

圖7 多機并行分組計算流程圖

首先，將查詢請求分發(fā)到每個數(shù)據(jù)處理節(jié)點上，并在每個處理節(jié)點執(zhí)行查詢，生成中間統(tǒng)計結(jié)果；

其次，每個數(shù)據(jù)節(jié)點的代理服務，將各節(jié)點的統(tǒng)計結(jié)果，按照分組列Hash并進行P2P分發(fā)，使得相同分組間的中間統(tǒng)計結(jié)果分布到同一節(jié)點內(nèi)；

最后，在每個節(jié)點內(nèi)完成最終的分組統(tǒng)計計算.

2.3.2多租戶的數(shù)據(jù)隔離

圖8為神通安全數(shù)據(jù)庫集群系統(tǒng)在多租戶環(huán)境下實現(xiàn)數(shù)據(jù)隔離的組件模塊，包括2個在特權(quán)域Domain0中的軟件模塊：1個針對數(shù)據(jù)隔離；另1個針對網(wǎng)絡隔離；此外包括1個標記服務(labeling service)部署在底層共享存儲設備上；另外針對每個用戶部署1個系統(tǒng)內(nèi)核級信息流追蹤組件，安裝在所有愿意使用用戶實例上.

圖8 集群系統(tǒng)的安全隔離框架

通過Domain0來管理系統(tǒng)，云租戶可以指定安全策略并運用部署在云服務提供商那里的標記服務來自動分配標記到他們的數(shù)據(jù)，這樣，就可以追蹤所有在租戶實例內(nèi)進程和文件之間的信息流，如果租戶的數(shù)據(jù)不符合規(guī)定地流向了另一個租戶的虛擬機或是云外的網(wǎng)絡，Domain0里的執(zhí)行組件就會終止類似的數(shù)據(jù)交換.網(wǎng)絡隔離組件主要干擾對共享硬件資源的多租戶探測：通過中央數(shù)據(jù)庫重寫租戶虛擬實例的IP地址，首先阻止攻擊者探測租戶的真實IP地址，同時調(diào)節(jié)ping值返回時間，使得同一臺物理主機上虛擬機之間的ping時間值和不同物理主機之間的ping時間值是相同的.

2.3.3稀疏索引技術(shù)

本文在大數(shù)據(jù)索引技術(shù)上，揚棄了傳統(tǒng)關(guān)系數(shù)據(jù)庫的行級索引機制，而是設計并使用了基于壓縮包級別的稀疏索引技術(shù).基于稀疏索引技術(shù)，可以最大限度地降低索引的大小，從而使得檢索操作更多地利用內(nèi)存進行.本文設計了智能索引，用于解決近似有序列檢索問題，其設計原理如圖9所示.

在此基礎上進一步發(fā)展，設計了基于包級別的Hash，其主要目的是替代傳統(tǒng)B-Tree索引，具體設計原理如圖10所示.

圖9 智能索引設計原理

圖10 稀疏Sparse Bitmap哈希索引原理圖

通過此改進設計，使得基于K-V檢索的索引大小降低90%以上，有效地提高了內(nèi)存利用率和大數(shù)據(jù)檢索性能.

2.3.4基于負載均衡調(diào)整的在線擴展技術(shù)

本文設計了基于二級數(shù)據(jù)分發(fā)映射的數(shù)據(jù)分布架構(gòu)，以保證大數(shù)據(jù)存儲平臺中的各種數(shù)據(jù)分布模型均可實現(xiàn)不移動數(shù)據(jù)的在線平滑擴展模式，二級分發(fā)的設計原理如圖11所示：

圖11 二級分發(fā)映射設計原理圖

3 應用測試驗證

以某電信集團公司無線網(wǎng)絡優(yōu)化平臺實際應用場景為基礎測試支撐，在數(shù)據(jù)裝載、壓縮比、數(shù)據(jù)統(tǒng)計、精確查詢和DML等主要指標對基于本方案實現(xiàn)的大數(shù)據(jù)平臺和國外同類產(chǎn)品進行了較為全面的測試對比驗證.如表1～8所示.

表1 數(shù)據(jù)裝載性能對比

表2 壓縮比對比

表3 小時級匯總統(tǒng)計性能對比

表4 天級匯總統(tǒng)計性能對比

表5 周級匯總統(tǒng)計性能對比

表6 精確查詢性能對比

表7 數(shù)據(jù)刪除性能對比

表8 數(shù)據(jù)更改性能對比

4 結(jié) 論

本文針對通用關(guān)系數(shù)據(jù)庫發(fā)展階段，提出了一種實現(xiàn)大數(shù)據(jù)存儲平臺的衍生設計方案，通過應用測試驗證表明：

1) 基于低網(wǎng)絡負載優(yōu)化技術(shù)的MPP架構(gòu)，使得平臺具備多機并行計算能力；

2) 設計了一種在多機環(huán)境下基于多租戶的安全機制；

3) 基于稀疏索引技術(shù)，提升了平臺在大數(shù)據(jù)場景下的精確查詢性能；

4) 基于負載均衡調(diào)整的在線擴展技術(shù)，使得平臺具備在線水平擴展能力.

因此本文所提出的大數(shù)據(jù)存儲平臺，能夠適應目前大數(shù)據(jù)中心建設需求，具有一定工程應用價值，在一定程度上提升了國產(chǎn)大數(shù)據(jù)產(chǎn)品的競爭力.

[1]Garcia-Molina H, Ullman J D, Widom J. Database System Implementation[M]. Englewood Cliffs, NJ: Prentice Hall, 2000

[2]Bitmap Index vs. B-tree Index: Which and When[EB/OL]. [2017-12-15]. http://www.oracle.com/technetwork/articles/sharma-indexes-093638.html

[3]Chang F, Dean J, Ghemawat S, et al. Bigtable: A distributed storage system for structured data[J]. ACM Trans on Computer Systems, 2008, 26(2): 4-6

[4]Ghemawat S, Gobioff H, Leung S T. The Google file system[J]. Communications of the ACM, 2003, 37(5): 29-43

[5]Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1): 107-113

[6]Osborne K, Johnson R, P?der T. Expert Oracle Exadata[M]. Apress, 2011

[7]張瑞. Oracle Exadata技術(shù)淺析[EB/OL]. [2017-12-15]. http://www.hellodb.net/2010/02/oracle_exadata.html

[8]Oracle, Oracle Exadata Database Machine Technical Whitepaper[EB/OL]. [2017-12-15]. http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/exadata-technical-whitepaper-134575.pdf

[9]Oracle Exadata Database Machine [EB/OL]. [2017-12-15]. http://www.oracle.com/us/products/database/exadata/overview/index.html

[10]EMC. Greenplum數(shù)據(jù)庫技術(shù)白皮書[EB/OL]. [2017-12-15]. http://www.greenplum.com/products/greenplum-database

[11]馮柯. 邁向100TB：電信業(yè)海量數(shù)據(jù)存儲中的數(shù)據(jù)庫實踐[EB/OL]. [2017-12-15]. http://wenku.it168.com/d_00000700.shtml

[12]北京寰信通科技有限公司. SYBASE IQ紅寶書[M]. 北京: 中國水利水電出版社, 2008

[13]System Administration Guide: Volume 1 [EB/OL]. [2017-12-15]. http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00170.1540/doc/html/title.html