蔣 旭 孫 磊 譚煒波

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

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

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

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

1 現有技術路線分析

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

1.1 宏觀分析

大數據存儲方案的宏觀分析重點關注的設計指標是存儲結構、并行架構、普適性3個方面.

1.1.1存儲結構分析

1.1.2并行架構分析

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

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

1.1.3普適性分析

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

1.2 微觀分析

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

1.2.1精確查詢分析

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

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

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

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

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

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

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

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

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

1.2.3復雜查詢分析

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

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

2 平臺設計

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

2.1 平臺軟件架構

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

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

圖1 大數據存儲平臺總體架構

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

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

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

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

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

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

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

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

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

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

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

2.2 平臺拓撲架構

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

圖5 平臺拓撲架構

2.3 關鍵技術及解決思路

2.3.1MPP多機并行查詢技術

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

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

圖6 MPP并行計算設計思想

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

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

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

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

2.3.2多租戶的數據隔離

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

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

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

2.3.3稀疏索引技術

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

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

圖9 智能索引設計原理

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

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

2.3.4基于負載均衡調整的在線擴展技術

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

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

3 應用測試驗證

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

表1 數據裝載性能對比

表2 壓縮比對比

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

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

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

表6 精確查詢性能對比

表7 數據刪除性能對比

表8 數據更改性能對比

4 結 論

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

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

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

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

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

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

[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技術淺析[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數據庫技術白皮書[EB/OL]. [2017-12-15]. http://www.greenplum.com/products/greenplum-database

[11]馮柯. 邁向100TB：電信業(yè)海量數據存儲中的數據庫實踐[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