HugeTable結(jié)構(gòu)化海量數(shù)據(jù)存儲系統(tǒng)

#HugeTable——結(jié)構(gòu)化海量數(shù)據(jù)存儲系統(tǒng)摘要：面對大量的通信數(shù)據(jù)，以Hadoop為基礎(chǔ)的開源系統(tǒng)并不能完全滿足電信運(yùn)營商的全部需求，比如說實(shí)時(shí)響應(yīng)。因此，電信運(yùn)營商亟需一種能夠同時(shí)滿足其功能、性能、擴(kuò)展性和可管理性等全部需求的存儲機(jī)制，一種針對電信運(yùn)營商在線服務(wù)的數(shù)據(jù)倉庫HugeTable應(yīng)運(yùn)而生。關(guān)鍵字：云計(jì)算數(shù)據(jù)倉庫HugeTable引言云計(jì)算是IT技術(shù)發(fā)展的最新趨勢，正受到業(yè)界和學(xué)術(shù)界的廣泛關(guān)注。云計(jì)算是在分布式處理、并行處理和網(wǎng)格計(jì)算等技術(shù)的基礎(chǔ)上發(fā)展起來的，是一種新興的共享基礎(chǔ)架構(gòu)的方法，它可以自我維護(hù)和管理龐大的虛擬計(jì)算資源（包括計(jì)算服務(wù)器、存儲服務(wù)器、寬帶資源等等），從而提供各種IT服務(wù)。用戶在使用云計(jì)算提供的服務(wù)時(shí)按需付費(fèi)，這不僅降低了使用門檻，也極大地節(jié)省了開銷。由于云計(jì)算存在著巨大的潛在市場，Google，IBM，Microsoft，Amazon，HP，Yahoo，Oracle等國際知名大公司都已經(jīng)涉足云計(jì)算。云計(jì)算也開始在電信、金融等需要大規(guī)模并行處理的領(lǐng)域得到應(yīng)用，比如中國移動(dòng)研究院開發(fā)的云數(shù)據(jù)挖掘平臺BCGPDM和云數(shù)據(jù)庫產(chǎn)品——HugeTable。背景Google和Apache發(fā)布了一系列的技術(shù)，比如Google的GFS和MapReduce,Apache的HDFS。這些技術(shù)憑借著其優(yōu)越的高可用性和高可擴(kuò)展性，被廣泛地應(yīng)用在網(wǎng)絡(luò)企業(yè)中。像Facebook利用部署了超過2000個(gè)節(jié)點(diǎn)的HDFS集群，為了支持SQL，Hive支持將SQL語句轉(zhuǎn)換為MapReduce程序。因此，傳統(tǒng)的基于數(shù)據(jù)庫的企業(yè)應(yīng)用能夠運(yùn)行在HDFS上，從而獲得云計(jì)算的相關(guān)特性。盡管如此，對于電信運(yùn)營商來說，HDFS和Hive并不能滿足其全部需求，特別是實(shí)時(shí)查詢處理。比如一個(gè)常見的查詢，“select*fromstudentwherestudentId=@studentId”,系統(tǒng)會啟動(dòng)MapReduce進(jìn)行計(jì)算，MapReduce需要通過掃描所有的數(shù)據(jù)記錄來得出結(jié)果，這個(gè)過程往往要浪費(fèi)大量時(shí)間。所以開源系統(tǒng)的實(shí)時(shí)性成為在電信運(yùn)營商中進(jìn)行部署的最大障礙。通過分析HDFS，Hive和HBase，一種面向電信運(yùn)營商的數(shù)據(jù)倉庫應(yīng)運(yùn)而生HugeTable。HugeTable能夠滿足電信運(yùn)營商的所有需求，比如功能、性能、擴(kuò)展性和可管理性。HugeTable簡介HugeTable是一種結(jié)構(gòu)化海量數(shù)據(jù)存儲系統(tǒng)，支持傳統(tǒng)的SQL查詢，主要面向電信應(yīng)用?；陔娦胚\(yùn)營商前臺業(yè)務(wù)及后臺系統(tǒng)對性能、功能、可擴(kuò)展性、可管理性等方面的需求，在開發(fā)過程中整合并改進(jìn)了HDFS、HBase、Hive、Flume、ZK等開源軟件。HugeTable提出了兩種新穎的存儲引擎：半隨機(jī)的HT-HFile和半列存儲HT-RCFile。和開源系統(tǒng)相比，HugeTable可以同時(shí)創(chuàng)建密集索引和稀疏索引，用來加快查詢速度。在查詢過程中，HugeTable首先查詢索引，如果查詢列上沒有索引，則利用HT-HFile和HT-RCFile存儲引擎來優(yōu)化MapReduce查詢過程?；贖DFS和Hive開發(fā)了一種新的存儲引擎，并在此之上引入了索引機(jī)制以支持實(shí)時(shí)查詢。HugeTable是基于開源軟件Hadoop和Hive研發(fā)的。如圖1所示，通過開發(fā)了HFile存儲引擎、索引機(jī)制、HTLoader加載器和管理模塊，進(jìn)而實(shí)現(xiàn)存儲引擎純文本文件是使用HDFS時(shí)最主要的存儲引擎格式，現(xiàn)有系統(tǒng)在針對HDFS所存儲的數(shù)據(jù)進(jìn)行SQL查詢時(shí)，往往需要掃描全部數(shù)據(jù)集，比如像是“select*fromstudentwherestudentld=@studentld"這樣簡單的語句也要遍歷所有的數(shù)據(jù)，可想而知其效率是很低的。為了克服上述問題，在HugeTable中重新設(shè)計(jì)實(shí)現(xiàn)了HT-HFile、HTRCFile等存儲引擎。HT-HFile與純文本文件相比，HT-HFile是半結(jié)構(gòu)化存儲引擎。如圖2所示，數(shù)據(jù)以數(shù)據(jù)庫的形勢存儲，其中的數(shù)據(jù)記錄按主索引(pi)進(jìn)行排序。例如，Key是主關(guān)鍵字，且KeyO<Keyl,Keyl<Key2。這樣的布局可避免大范圍的數(shù)據(jù)掃描。即在以主關(guān)鍵字進(jìn)行查詢時(shí)保證了較高的效率。需要注意的是，同一批加載的數(shù)據(jù)，在數(shù)據(jù)塊內(nèi)部，數(shù)據(jù)是完全按照主索引(pi)進(jìn)行排序的。但是在數(shù)據(jù)塊之間，并不能保證其全局有序，因此，HugeTable首先從數(shù)據(jù)源加載數(shù)據(jù)，然后將數(shù)據(jù)劃分成為“塊”，在每個(gè)塊內(nèi)對數(shù)據(jù)記錄進(jìn)行排序并將結(jié)果保存在HDFS上。因此將HF-HFile作為一種半隨機(jī)的存儲引擎。DataBlock0Key0Value0\Key1Value1DataBlockn\KeynValuenMetaBlockIndex圖2HT-HFile數(shù)據(jù)結(jié)構(gòu)圖HT-HFile通過減少掃描的數(shù)據(jù)量來加速查詢處理請求。在不采用HT-HFile作為存儲引擎時(shí)，MapReduce需要掃描所有的數(shù)據(jù)，以便找到需要處理的數(shù)據(jù)記錄。當(dāng)采用HT-HFile存儲引擎時(shí)，MapReduce作業(yè)可以直接讀取需要出庫的數(shù)據(jù)記錄的起始位置，從而降低數(shù)據(jù)查詢處理時(shí)的數(shù)據(jù)量。HT-RCFileHT-HFile適合于對整行記錄的存儲，每次數(shù)據(jù)的讀寫均以行(row)為單位。但是，在數(shù)據(jù)倉庫系統(tǒng)中，經(jīng)常會出現(xiàn)僅對一個(gè)具有大量列(column)的表的某個(gè)列進(jìn)行處理的現(xiàn)象。在這種場景下，借鑒RCFile的思路設(shè)計(jì)了一種半列存儲引擎。如圖3所示，在HT-RCFile中，數(shù)據(jù)按照塊存儲，塊之間數(shù)據(jù)隨機(jī)，塊內(nèi)數(shù)據(jù)則按列存儲。圖3HT-RCFile數(shù)據(jù)結(jié)構(gòu)圖HT-RCFile的加載速度與TextFile相當(dāng)且比列存儲數(shù)據(jù)倉庫更高，而將數(shù)據(jù)從TextFile轉(zhuǎn)化為HT-RCFile的開銷則很小。除此之外，HT-RCFile的主要優(yōu)勢在于其較高的查詢性能。對于只對部分列做處理的操作，采用其他存儲引擎時(shí)，MapReduce需要讀取所有列的數(shù)據(jù)，而當(dāng)采用HT-RCFile存儲引擎時(shí)，則只需要讀取相關(guān)的列而過濾掉不相關(guān)的列。因此，HT-RCFile可以避免不相關(guān)數(shù)據(jù)的讀取,從而提升了查詢處理的性能。HugeTable索引設(shè)計(jì)在這一部分主要介紹HugeTable索引的設(shè)計(jì)方案。密集索引在密集索引中，每條記錄都對應(yīng)著一條索引項(xiàng)，如B+樹就是一種典型的密集索引結(jié)構(gòu)。HugeTable的主要存儲引擎都支持主索引和多個(gè)二級索引，數(shù)據(jù)記錄是按照主索引排序的。HugeTable在建表時(shí)即需創(chuàng)建主索引，而二級索引則可在數(shù)據(jù)加載后通過一個(gè)MapReduce作業(yè)來創(chuàng)建。密集索引的優(yōu)勢主要體現(xiàn)在索引列的高性能查詢能力上。例如：采用ID列索引查詢語句“select*fromstudentwhereID=xx"時(shí)，只需查詢ID列索引,得到記錄位置后即可讀取數(shù)據(jù)，查詢響應(yīng)時(shí)間很短。當(dāng)不采用ID列索引而采用MapReduce進(jìn)行數(shù)據(jù)掃描時(shí)，作業(yè)初始化時(shí)間則至少為秒級。因此，密集索引可提高索引列的查詢響應(yīng)性能，并降低數(shù)據(jù)I/O開銷。稀疏索引稀疏索引記錄每個(gè)數(shù)據(jù)塊所包含的最大和最小鍵值。查詢時(shí)，將待查詢鍵值與每個(gè)索引項(xiàng)的最大和最小鍵值進(jìn)行比較得到候選索引項(xiàng)。每個(gè)索引項(xiàng)包含有多個(gè)屬性值（如最小、最大鍵值和文件塊號）。數(shù)據(jù)庫中的數(shù)據(jù)以文件塊的方式進(jìn)行存儲，文件塊的大小在不同系統(tǒng)中有所不同，每個(gè)文件塊都有相對應(yīng)的編號，即文件塊號。最大鍵值和最小鍵值分別是指該文件塊內(nèi)所有鍵值中的最大值和最小值。利用索引優(yōu)化的查詢策略以Hive和Hadoop為原型的系統(tǒng)，是將每個(gè)SQL查詢都轉(zhuǎn)換為MapReduce查詢來獲得數(shù)據(jù)的。這種方式無法滿足電信數(shù)據(jù)倉庫的實(shí)時(shí)響應(yīng)性能需求，比如：在數(shù)據(jù)倉庫中對字典進(jìn)行的查詢，啟動(dòng)MapReduce本身的時(shí)間要遠(yuǎn)大于數(shù)據(jù)本身的掃描時(shí)間。此外，索引一般都比數(shù)據(jù)小很多，所以掃描索引比掃描數(shù)據(jù)快得多。針對這個(gè)特征，HugeTable提出了如圖3所示的查詢框架。圖3HugeTable查詢框架當(dāng)應(yīng)用提交一個(gè)查詢SQL時(shí)，HugeTable首先會分析查詢列的情況：該列有索引時(shí)掃描索引就可獲得查詢結(jié)果，該列無索引時(shí)用戶可根據(jù)應(yīng)用和數(shù)據(jù)量本身的特點(diǎn)選擇不同的查詢方式。比如，用戶數(shù)據(jù)量較小時(shí)可選擇順序掃描查詢方式。由于該查詢方式不需要啟動(dòng)MapReduce，節(jié)省了啟動(dòng)時(shí)間，所以能提供實(shí)時(shí)的查詢響應(yīng)能力。另外，當(dāng)應(yīng)用需要實(shí)時(shí)數(shù)據(jù)查詢響應(yīng)能力時(shí)，也可以優(yōu)先選擇該查詢方式；相反，當(dāng)用戶數(shù)據(jù)量巨大或者應(yīng)用只需準(zhǔn)實(shí)時(shí)查詢響應(yīng)能力時(shí)，用戶需選擇MapReduce查詢機(jī)制。參考文獻(xiàn)：Hadoop/HugeTable:—種面向電信行業(yè)的云數(shù)據(jù)倉庫周大錢嶺計(jì)算機(jī)科學(xué)第8期第3