精品久久一区,污黄啪啪网,16女下面流水不遮视频,色婷五月天

在過去的3年中, 隨著用戶規(guī)模的快速增加和移動互聯(lián)網(wǎng)業(yè)務的高速發(fā)展, 每天用戶和服務產(chǎn)生的數(shù)據(jù)規(guī)模已達PB級, 電信運營商面臨著數(shù)據(jù)爆炸式增長的巨大壓力, 可存儲并對海量數(shù)據(jù)進行分析的Hadoop開源系統(tǒng)[1]已成為主流電信運營商、互聯(lián)網(wǎng)公司的研究和應用熱點。然而, Hadoop開源系統(tǒng)并不能完全滿足電信運營商的全部需求 (如交互式查詢、基于索引的分析優(yōu)化、多租戶支持等) 。為解決這些問題, 設計并研發(fā)了Huge Table數(shù)據(jù)倉庫。與Hadoop開源系統(tǒng)相比, Huge Table能支持密集索引、稀疏索引和塊索引, 從而加快了查詢和分析的速度。查詢過程中, Huge Table首先會使用索引。如果沒有索引, 系統(tǒng)則會為用戶提供針對小數(shù)據(jù)量的順序掃描方式和大數(shù)據(jù)量的Map Reduce方式進行查詢。在實際的應用測試評估中, Huge Table的索引和存儲引擎極大地提高了查詢性能, 滿足了現(xiàn)網(wǎng)服務系統(tǒng)的性能需求。

自2009年發(fā)放3G牌照后, 我國現(xiàn)已擁有了上億的移動互聯(lián)網(wǎng)用戶, 他們每天通過手機對互聯(lián)網(wǎng)的訪問產(chǎn)生了高達數(shù)十TB的訪問記錄。這顯然是傳統(tǒng)關系數(shù)據(jù)庫所無法支持的。除存儲容量外, 海量數(shù)據(jù)帶來的更大挑戰(zhàn)是如何加載、查詢和分析數(shù)據(jù)。由于商業(yè)數(shù)據(jù)庫要對數(shù)據(jù)進行排序和建立索引, 所以這是很難加載海量數(shù)據(jù)的。為解決海量數(shù)據(jù)的加載問題, 在數(shù)據(jù)庫中引入了分庫和分區(qū)的技術(shù)措施, 而分庫和分區(qū)則導致了海量數(shù)據(jù)查詢和分析性能的大幅下降。舉例來說, 盡管對建有索引的列進行查詢, 其響應時間也往往都在10 s級。另外, 雖然建立在視圖基礎上的商業(yè)數(shù)據(jù)倉庫針對常用查詢也可獲得很好的查詢性能, 但這些定制化的數(shù)據(jù)倉庫卻很難進行水平擴展。當需要增加節(jié)點時就必須停服, 且節(jié)點的增加并不能使性能得到線性的增長?？傊? 電信運營商希望能夠提供一種海量存儲、高可用、高擴展、支持結(jié)構(gòu)化查詢語言 (SQL) 和快速響應的數(shù)據(jù)倉庫。

據(jù)此云計算應運而生:Google發(fā)布了一系列云計算技術(shù), 如Google文件系統(tǒng) (GFS) [2]和Map Reduce[3];Apache基于GFS和Map Reduce開發(fā)了開源軟件Hadoop分布式文件系統(tǒng) (HDFS) [4]。鑒于HDFS具有優(yōu)越的高可用性和高擴展性, 因此被廣泛地應用到網(wǎng)絡企業(yè)中, 比如Facebook用其部署了超過2 000個節(jié)點的HDFS集群、研發(fā)了Hive[5], 以支持將SQL語句轉(zhuǎn)換為Map Reduce程序。因此, 傳統(tǒng)的基于數(shù)據(jù)庫的企業(yè)應用可運行在HDFS上, 并能獲得云計算的相關特性。

但對電信運營商來說, HDFS和Hive并不能滿足其全部需求 (特別是在多表嵌套查詢處理方面) 。對于一個常見的查詢, 如“select a.a1, b.b1, c.c1 from a, b, c where a.employid=b.employid and a.msisdn=c.msisdn”, 系統(tǒng)會啟動多輪Map Reduce迭代計算, 每輪Map Reduce需通過掃描所有的數(shù)據(jù)記錄來獲得結(jié)果。測試過程中, GB級別的表查詢時間都需數(shù)個小時, 而傳統(tǒng)數(shù)據(jù)倉庫同樣查詢的響應時間只為分鐘級別, 所以開源系統(tǒng)基于索引的分析性能已成了電信運營商進行部署的最大障礙。

通過分析HDFS、Hive和Hbase, 我們提出的一種面向電信運營商的Huge Table能滿足電信運營商的所有需求, 比如功能、性能、擴展性和可管理性等;提出的基于存儲引擎的索引模塊和針對海量數(shù)據(jù)的查詢策略, 可創(chuàng)建密集索引、稀疏索引和塊索引。利用密集索引可準實時地查詢每一條數(shù)據(jù)記錄, 利用稀疏索引可存儲數(shù)據(jù)記錄的塊信息, 利用塊索引可記錄每個塊里面所包含的索引記錄的區(qū)間信息。對于Huge Table來說, 密集索引、稀疏索引和塊索引對大部分查詢都能起到加速作用。在查詢過程中, Huge Table首先利用相關列的索引信息進行查詢。對于沒有索引的列, 用戶可利用Huge Table本身提供的查詢機制優(yōu)化查詢性能。這些查詢機制主要包括針對小數(shù)據(jù)量的順序掃描方式及針對大數(shù)據(jù)量的并行Map Reduce查詢機制。

Huge Table的優(yōu)化主要包括以下幾個方面。

索引項和記錄項是一一對應的。數(shù)據(jù)是按照索引順序進行排列的, 可充分提高查詢性能。

只記錄索引的塊信息, 可在提供查詢性能的同時提高加載性能?？煽焖俣ㄎ槐４嬗涗浀臄?shù)據(jù)塊, 并在塊內(nèi)查詢數(shù)據(jù)信息。

只記錄數(shù)據(jù)塊內(nèi)的數(shù)據(jù)區(qū)間信息, 在提供查詢性能的同時提高加載性能。通過查詢數(shù)據(jù)區(qū)間確定是否包含數(shù)據(jù)記錄, 并通過散列函數(shù)確定該數(shù)據(jù)區(qū)間是否包含該記錄。

分別提供索引查詢接口。針對小數(shù)據(jù)量和大數(shù)據(jù)量分別提供順序掃描接口和Map Reduce查詢接口。

Google文件系統(tǒng)是一種分布式、大規(guī)?？蓴U展、面向密集數(shù)據(jù)存取應用的文件系統(tǒng)。該系統(tǒng)具有很強的容錯能力, 并能在高并發(fā)場景下提供很高的聚合訪問性能。GFS在Google有很廣泛的應用, 并涵蓋了眾多產(chǎn)品線及研究項目。當前, Google內(nèi)部規(guī)模最大的GFS集群甚至包括有上千個物理節(jié)點, 可提供上百TB存儲能力, 可供數(shù)百個客戶端并發(fā)訪問。

MR是一種用于處理海量數(shù)據(jù)的并行編程模型框架, Map函數(shù)用于對輸入的鍵值對進行處理并生成中間結(jié)果鍵值對, Reduce匯總具有相同鍵的所有值并輸出匯總計算結(jié)果。該模型編寫程序能自動并行地運行在大規(guī)模部署的通用商業(yè)計算節(jié)點上。MR運行環(huán)境會自動完成很多并行化工作 (如分區(qū)輸入數(shù)據(jù)、調(diào)度運算任務、處理運行錯誤等) , 這大大降低了并行程序的開發(fā)門檻, 能讓更多的沒有相關經(jīng)驗的用戶方便地利用大規(guī)模分布式系統(tǒng)的資源。

Big Table是一種用于結(jié)構(gòu)化數(shù)據(jù)存儲、具有強大可擴展能力的分布式系統(tǒng), 通常規(guī)模可達上千個節(jié)點、存儲容量可達PB級。目前, Google網(wǎng)頁索引、Google地球、Google金融等產(chǎn)品都在使用Big Table。

GFS、MR和BigTable在Google的成功, 催生了一系列開源軟件, 例如:Hadoop實現(xiàn)了GFS/MR功能, HBase實現(xiàn)了BigTable功能, 而Hive則能將SQL語句翻譯成Map Reduce程序, 可使更多的傳統(tǒng)數(shù)據(jù)庫用戶方便地利用云計算平臺完成他們所熟悉的SQL任務。

此外, Flume[6]和Zookeeper[7]也是非常重要的開源軟件。它們可分別用于數(shù)據(jù)/日志加載和數(shù)據(jù)節(jié)點狀態(tài)管理/分布式鎖。

HugeTable是一種結(jié)構(gòu)化的海量數(shù)據(jù)存儲系統(tǒng)。它支持傳統(tǒng)的SQL查詢, 主要面向于電信方面的應用?；谥袊苿忧芭_業(yè)務及后臺系統(tǒng)對性能、功能、可擴展性、可管理性等方面的需求, 我們在開發(fā)過程中整合并改進了HDFS、HBase、Hive、ZK等開源軟件。

基于HugeTable的各種存儲引擎, 我們設計了密集索引、稀疏索引和塊索引。在查詢過程中, Huge Table首先要檢查是否存在索引。有索引時HugeTable利用索引對數(shù)據(jù)進行快速的定位和掃描, 無索引時Huge Table會根據(jù)數(shù)據(jù)量的大小分別啟動順序掃描或Map Reduce掃描來獲得查詢結(jié)果。HugeTable系統(tǒng)架構(gòu)見圖1。由圖1可知, HugeTable是基于開源軟件Hadoop和Hive研發(fā)的, 開發(fā)了索引機制和查詢模塊。

圖1 HugeTable系統(tǒng)架構(gòu)   下載原圖

下面主要介紹HugeTable索引的設計方案。

在密集索引中, 每條記錄都對應著一條索引項, 如B+樹就是一種典型的密集索引結(jié)構(gòu)。HugeTable的主要存儲引擎都支持主索引和多個二級索引, 數(shù)據(jù)記錄是按照主索引排序的。HugeTable在建表時即需創(chuàng)建主索引, 而二級索引則可在數(shù)據(jù)加載后通過一個MapReduce作業(yè)來創(chuàng)建。

密集索引的優(yōu)勢主要體現(xiàn)在索引列的高性能查詢能力上。例如:采用XXX列索引查詢語句“select*from table1 where id=XXX”時, 只需查詢XXX列索引, 得到記錄位置后即可讀取數(shù)據(jù), 查詢響應時間約為10 ms。當不采用XXX列索引而采用Map Reduce進行數(shù)據(jù)掃描時, 作業(yè)初始化時間則至少為秒級。因此, 密集索引可提高索引列的查詢響應性能, 并降低數(shù)據(jù)IO開銷。

稀疏索引記錄每個數(shù)據(jù)塊所包含的最大和最小鍵值。查詢時, 將待查詢鍵值與每個索引項的最大和最小鍵值進行比較而得到候選索引項。每個索引項包含有多個屬性值 (如最小、最大鍵值和文件塊號) 。數(shù)據(jù)庫中的數(shù)據(jù)以文件塊的方式進行存儲, 文件塊的大小在不同系統(tǒng)中有所不同, 每個文件塊都有對應的編號, 即文件塊號。最大鍵值和最小鍵值分別是指該文件塊內(nèi)所有鍵值中的最大值和最小值。

以電信領域的數(shù)據(jù)倉庫系統(tǒng)為例, 由于系統(tǒng)在一段時間內(nèi)會產(chǎn)生與同一個移動用戶號碼 (MSISDN) 相關的多條日志記錄, 與同一個MSISDN相關的多條記錄都有可能存儲在同一個數(shù)據(jù)塊中, 亦即同一個數(shù)據(jù)塊中可能包含有多條具有相同MSIDSN的記錄。

基于上述特征, 我們提出了塊索引方案。塊索引格式為“<key, file ID, block ID>”, 表示在block ID塊中包含了某個key, 在該塊中可能會包含多個相同的key。以一個具有6.4萬條記錄的數(shù)據(jù)塊中只包含100個不同的MSISDN記錄項的場景為例 (此時可將MSISDN定義為“key”) , 采用密集索引時對同一個塊會產(chǎn)生6.4萬條記錄, 而采用塊索引時只需100條索引記錄。因此與密集索引相比, 塊索引可極大地減少索引數(shù)據(jù)量。

塊索引的優(yōu)勢主要體現(xiàn)在以下3個方面。

與密集索引相比, 由于塊索引的數(shù)據(jù)量較小, 因此讀取索引數(shù)據(jù)的開銷也較小。

在塊索引列上查詢, 可首先通過塊索引過濾掉不滿足條件的數(shù)據(jù)塊, 只讀取相關數(shù)據(jù)塊, 從而提高了查詢性能。

通常在加載數(shù)據(jù)的同時就可以創(chuàng)建索引。

與加載數(shù)據(jù)本身相比, 創(chuàng)建塊索引的成本較低。

以Hive和Hadoop為原型的系統(tǒng), 是將每個SQL查詢都轉(zhuǎn)化為MapReduce查詢來獲得數(shù)據(jù)的。這種方式無法滿足電信數(shù)據(jù)倉庫的實時響應性能需求, 比如:在數(shù)據(jù)倉庫中對字典表進行的查詢, 啟動MapReduce本身的時間要遠大于數(shù)據(jù)本身的掃描時間。此外, 索引一般都比數(shù)據(jù)小很多, 所以掃描索引比數(shù)據(jù)快得多。

針對上述特性, HugeTable提出了如圖2所示的查詢框架。當應用提交一個查詢SQL時, HugeTable首先會分析查詢列的情況:該列有索引時掃描索引就可獲得查詢結(jié)果, 該列無索引時用戶可根據(jù)應用和數(shù)據(jù)量本身的特點選擇不同的查詢方式。比如, 用戶數(shù)據(jù)量較小時可選擇順序掃描查詢方式。由于該方式不需啟動MapReduce, 節(jié)省了啟動時間, 所以能提供實時的查詢響應能力。另外, 當應用需要實時數(shù)據(jù)查詢響應能力時, 也可優(yōu)先選擇該查詢方式;相反, 當用戶數(shù)據(jù)量巨大或應用只需準實時查詢響應能力時, 用戶需選擇MapReduce查詢機制。

圖2 HugeTable查詢框架   下載原圖

HugeTable系統(tǒng)已在中國移動現(xiàn)網(wǎng)系統(tǒng)中進行了大量的應用測試評估 (包括四川音樂基地及諾西網(wǎng)關日志存儲系統(tǒng)) 。作為數(shù)據(jù)倉庫系統(tǒng), HugeTable同時也被用于保存GPRS CDR數(shù)據(jù)。試驗系統(tǒng)的測試集群包括1個HugeTable主控節(jié)點和4個HugeTable數(shù)據(jù)節(jié)點。在四川音樂基地測試中, HugeTable能在規(guī)定的時間內(nèi)進行音樂訂購關系的查詢和分析處理;在諾西網(wǎng)關日志存儲系統(tǒng)測試中, HugeTable在加載過程中能快速地建立有效的索引系統(tǒng), 為高速查詢分析提供了基礎。在后續(xù)的查詢過程中, 稀疏索引也有效地提高了查詢分析性能。

在過去的3年里, 由于用戶和移動數(shù)據(jù)業(yè)務的快速增長, 電信服務提供商面臨著數(shù)據(jù)爆炸式增長挑戰(zhàn)。傳統(tǒng)關系型數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 已出現(xiàn)了伸縮性不足及性價比高的瓶頸, 與此同時云計算數(shù)據(jù)倉庫已提供了RDBMS的限制能力。基于此, 我們研發(fā)了面向電信業(yè)務的HugeTable數(shù)據(jù)倉庫系統(tǒng)。

在HugeTable系統(tǒng)中, 我們設計了稀疏索引用于加速查詢性能, 設計了密集索引用于滿足高性能交互式索引查詢。在索引查詢基礎上, 我們還實現(xiàn)了針對小數(shù)據(jù)量的順序掃描實時查詢和海量數(shù)據(jù)的MapReduce查詢。在對中國移動現(xiàn)網(wǎng)系統(tǒng)的應用評估中, HugeTable的功能和性能均已達到了應用水平。