久久精品国产69国产精品亚洲_日韩欧美亚洲一区_免费观看污网站_欧美在线一

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

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

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

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

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

Huge Table的優化主要包括以下幾個方面。

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

只記錄索引的塊信息, 可在提供查詢性能的同時提高加載性能。可快速定位保存記錄的數據塊, 并在塊內查詢數據信息。

只記錄數據塊內的數據區間信息, 在提供查詢性能的同時提高加載性能。通過查詢數據區間確定是否包含數據記錄, 并通過散列函數確定該數據區間是否包含該記錄。

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

Google文件系統是一種分布式、大規模可擴展、面向密集數據存取應用的文件系統。該系統具有很強的容錯能力, 并能在高并發場景下提供很高的聚合訪問性能。GFS在Google有很廣泛的應用, 并涵蓋了眾多產品線及研究項目。當前, Google內部規模最大的GFS集群甚至包括有上千個物理節點, 可提供上百TB存儲能力, 可供數百個客戶端并發訪問。

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

Big Table是一種用于結構化數據存儲、具有強大可擴展能力的分布式系統, 通常規模可達上千個節點、存儲容量可達PB級。目前, Google網頁索引、Google地球、Google金融等產品都在使用Big Table。

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

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

HugeTable是一種結構化的海量數據存儲系統。它支持傳統的SQL查詢, 主要面向于電信方面的應用。基于中國移動前臺業務及后臺系統對性能、功能、可擴展性、可管理性等方面的需求, 我們在開發過程中整合并改進了HDFS、HBase、Hive、ZK等開源軟件。

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

圖1 HugeTable系統架構   下載原圖

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

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

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

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

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

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

塊索引的優勢主要體現在以下3個方面。

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

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

通常在加載數據的同時就可以創建索引。

與加載數據本身相比, 創建塊索引的成本較低。

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

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

圖2 HugeTable查詢框架   下載原圖

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

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

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