0 引言

    隨著Internet技術的迅速發(fā)展，全球各大互聯(lián)網(wǎng)公司的網(wǎng)絡輿情監(jiān)控系統(tǒng)也蓬勃發(fā)展起來,網(wǎng)絡輿情監(jiān)控系統(tǒng)所獲得的數(shù)據(jù)量急速膨脹。傳統(tǒng)的網(wǎng)絡計算、并行計算、分布式計算等數(shù)據(jù)處理的方式越來越不能滿足快速查詢、存儲、處理日益增長的數(shù)據(jù)的需要^[1]。在此基礎上云計算的概念應運而生。云計算的新穎之處在于它幾乎可以提供無限的廉價存儲和計算能力，未來存儲模式將改變目前的存儲模式,不再存放在個人計算機及服務器上,而是存放在云服務器中,同時所有的計算、存儲、處理工作也將在云服務器完成,這樣給企業(yè)及各廠商帶來很多便利,節(jié)省存儲設備和軟件應用的投入成本。本文將網(wǎng)絡中大量各種不同類型的存儲設備通過應用軟件集合起來協(xié)同工作，并且將關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫聯(lián)合應用，設計出一個快速檢索查詢、海量數(shù)據(jù)存儲、批量數(shù)據(jù)處理的多層體系架構的系統(tǒng)，且對外提供數(shù)據(jù)存儲和業(yè)務訪問功能，保證數(shù)據(jù)的安全性，并節(jié)約存儲空間^[2]。

1 相關技術

    基于微博輿情的Hadoop存儲主要包括微博的數(shù)據(jù)結構和Hbase兩個部分。

1.1 微博數(shù)據(jù)結構

    (1)數(shù)據(jù)的語義不同,非結構化數(shù)據(jù)內容不一，描述不同的問題。現(xiàn)在對數(shù)據(jù)的非結構化管理通常以文件形式，保留原始的非結構化數(shù)據(jù)非常重要，可以針對不同的研究需求。但這導致對不同非結構化數(shù)據(jù)使用不同處理方案，最終時間會大大增加，無法快速獲得重要信息。而且用戶一般想專注于自己的研究模塊，不希望進行文件的預處理工作。

    (2)數(shù)據(jù)格式不同,各網(wǎng)站基于不同的框架產(chǎn)生大量不同格式的數(shù)據(jù)，從而形成大量不同的非結構化數(shù)據(jù)。無法使用統(tǒng)一的方式來管理和使用這些數(shù)據(jù)。

1.2 Hbase

    HBase是一個基于分布式文件系統(tǒng)HDFS、面向列、開源的數(shù)據(jù)庫。Hbase數(shù)據(jù)表由主鍵、列族、時間戳三部分組成。每個表都有一個主鍵、一個或多個列簇，每個列簇可以包含任意數(shù)量的列，且一個列族中的列名不能相同。HBase有多種數(shù)據(jù)導入方式，最直接的方法是在Java程序中獲取Hbase中的HTable類執(zhí)行Hbase的客戶端API，進行數(shù)據(jù)的增、刪、改、查^[3]。

    在Hbase的概念中，RegionServer對應于集群中的一個節(jié)點，而一個RegionServer負責管理多個Region。一個Region代表一張表的一部分數(shù)據(jù)，所以在Hbase中的一張表可能會需要很多個Region來存儲其數(shù)據(jù)，但是每個Region中的數(shù)據(jù)并不是雜亂無章的，Hbase在管理Region時會給每個Region定義一個Rowkey的范圍，落在特定范圍內的數(shù)據(jù)將交給特定的Region，從而將負載分攤到多個節(jié)點上，充分利用分布式的優(yōu)點^[4]。另外，Hbase會自動的調節(jié)Region處在的位置，如果一個RegionServer變得Hot(大量的請求落在這個Server管理的Region上)，Hbase就會把Region移動到相對空閑的節(jié)點，依次保證集群環(huán)境被充分利用。

2 基于Hadoop的微博數(shù)據(jù)存儲管理平臺的體系結構設計

    本文根據(jù)微博數(shù)據(jù)的特點，采用Hadoop技術，建立了多層結構的存儲和管理架構，如圖1所示。基于Hadoop的微博數(shù)據(jù)存儲管理平臺的體系結構主要由五個層面組成：原始數(shù)據(jù)層、數(shù)據(jù)預處理層、數(shù)據(jù)存儲層、NewSQL轉換層、數(shù)據(jù)應用層。

    (1)原始數(shù)據(jù)層：該主要是采集與保存新浪、搜狐、網(wǎng)易和騰訊等主流微博網(wǎng)站的原始數(shù)據(jù)。為保證微博數(shù)據(jù)的實時性，采用實時數(shù)據(jù)獲取工具每個小時自動對微博網(wǎng)址進行爬取，獲取前一個小時數(shù)據(jù)。

    (2)數(shù)據(jù)預處理層：該層主要功能包括兩部分工作。一是數(shù)據(jù)抽取，利用數(shù)據(jù)挖掘技術從原始數(shù)據(jù)中抽取出有效的信息，包括用戶信息、微博信息以及用戶微博之間的相互關系等；二是進行數(shù)據(jù)清洗，主要將一些采集過程中出現(xiàn)的錯誤數(shù)據(jù)和不一致性數(shù)據(jù)過濾。

    (3)數(shù)據(jù)存儲層：該層主要是用來存儲結構化數(shù)據(jù)和元數(shù)據(jù)。因此，在該層引入了Mysql和Hbase兩個數(shù)據(jù)庫。對清洗后的微博數(shù)據(jù)進行分析設計，采用分割、建立索引等方法成功加載進Hbase和Mysql數(shù)據(jù)庫。在具體實現(xiàn)中，使用HBase作為原始數(shù)據(jù)庫，而Mysql作為元數(shù)據(jù)。通過Mysql中的用戶信息和微博信息，快速獲取Hbase對應的用戶屬性、用戶關系、微博屬性、微博關系。能在毫秒中提取相關信息，從而實現(xiàn)高效的實時查詢。

    (4)NewSQL層：該層主要為Hbase的客戶端API和二級索引。NewSQL層是Hbase和Mysql的SQL引擎層，在此層實現(xiàn)Mysql查詢Hbase數(shù)據(jù)的映射與轉換工作。具體來講在此層實現(xiàn)了兩種功能：一是Mysql的數(shù)據(jù)庫的獨立查詢，查詢微博總數(shù)、用戶總數(shù)、微博內容等基本信息；二是Mysql的數(shù)據(jù)庫和Hbase的數(shù)據(jù)庫聯(lián)合查詢，通過查詢MySql中字段信息，調用Hbase的API查詢HBase數(shù)據(jù)庫，進行實時訪問。通過此層對外提供各類包括用戶屬性、微博屬性查詢，以及用戶間轉發(fā)回復評論等關系在內的查詢接口，實現(xiàn)數(shù)據(jù)查詢的易用性目標^[5]。

3 微博關系數(shù)據(jù)的存儲表的設計與實現(xiàn)

    Hadoop存儲和管理平臺采用了NewSQL存儲結構，它將傳統(tǒng)關系型數(shù)據(jù)庫Mysql和非關系型數(shù)據(jù)庫Hbase相結合，這種存儲結構不僅獲得了關系型數(shù)據(jù)庫的查詢速率快、支持復雜類查詢同時支持事務處理等優(yōu)點，也獲得非關系型的優(yōu)點，即極大的擴展性，可擴展到數(shù)十PB，以及建設成本低、數(shù)據(jù)安全的優(yōu)點。

    Mysql的設計上面采用分表存儲，每一百萬條記錄存儲到一張表中且建立索引，提升查詢速率。Hbase的設計上面采用RowKey的MD5加密且分區(qū)，使數(shù)據(jù)平均的分布在每臺RegionServer上面，防止數(shù)據(jù)傾斜到一臺RegionServer。

    最后，考慮到需要快速查找用戶信息、用戶之間的關系、微博信息、微博之間的關系，從而建立關鍵字索引表、用戶屬性表、用戶關系表、微博屬性表、微博關系表。

3.1 關鍵字索引表

    表1為關鍵字索引表。采用Mysql設計，存儲用戶的微博主要內容。通過關鍵字查詢用戶感興趣的內容，可以快速提取博文內容以及用戶信息。

3.2 用戶屬性表

    表2為用戶屬性表。采用Hbase設計，存儲用戶的基本屬性。其中包括：1個Rowkey和2個列族，Rowkey為用戶的唯一id，兩個列族分別為用戶屬性列族、關系屬性列族。

3.3 用戶關系表

    表3為用戶關系表。采用Hbase設計，存儲用戶之間關系狀態(tài)。關注關系分為兩種：單向的關注關系和雙向的好友關系。比如兩個用戶A和B之間，如果A關注B，而B沒有關注A，這就是一種單向的關注關系；如果A關注了B，同時B也關注了A，那么雙方是一種雙向的好友關系。其中包括：1個Rowkey和1個列族，Rowkey為用戶的唯一id，一個列族為用戶關系屬性列族。

3.4 微博屬性表

    表4為微博屬性表。采用Hbase設計，存儲微博文章的基本信息。其中包括：1個Rowkey和2個列族，Rowkey為微博URL作為唯一id，兩個列族即微博屬性列族和關系屬性列族。

3.5 微博關系表

    表5為微博關系表。采用Hbase設計，存儲用戶使用微博的發(fā)文、評論、轉發(fā)、回復信息。其中包括：1個Rowkey和1個列族，Rowkey為用戶的id，列族即微博關系屬性列族。

4 存儲管理平臺的性能測試與分析

    本節(jié)將搭建Apache版本Hadoop2.6分布式集群環(huán)境，對本平臺系統(tǒng)性能進行實驗測試和評估，通過SQL語句驗證其實際應用中的性能。

4.1 實驗環(huán)境及軟件配置

    表6為服務器集群環(huán)境及軟件配置表。用7個服務器使用Apache版本Hadoop2.6分布式集群部署，其中一臺服務器作為主節(jié)點Master，其余6臺作為平臺的數(shù)據(jù)節(jié)點Data，系統(tǒng)軟硬件配置見表6。

4.2 實驗數(shù)據(jù)

    實驗采用的是通過爬蟲技術從新浪、網(wǎng)易、搜狐等主流微博獲取的真實微博數(shù)據(jù)。通過去噪清洗，將一些采集過程中出現(xiàn)的錯誤和不一致性數(shù)據(jù)過濾并進行結構化處理后，獲得用戶節(jié)點數(shù)6 015萬，用戶關系數(shù)13 953萬,微博節(jié)點數(shù)53 413萬，用戶微博關系數(shù)為44 012萬。

    表7為數(shù)據(jù)平臺常用API查詢用時。根據(jù)需求選取6 000萬個重要人物在平臺上對項目常用的API（用戶節(jié)點查詢、用戶屬性查詢、用戶關系查詢、微博節(jié)點查詢、微博屬性查詢、微博關系查詢）進行SQL查詢用時測試。由于數(shù)據(jù)需多次測試，且在Hbase查詢中blockcache命中率對讀性能影響十分大，對此將分開啟和關閉緩存兩組進行測試。

    由表7可知，在已有數(shù)據(jù)下，項目常用API的利用SQL語句查詢50%分位值用時皆在16 ms以內，99%分位值也均在20 ms以內，能夠很好地滿足平臺的實時性要求。由圖2數(shù)據(jù)可知，隨著數(shù)據(jù)規(guī)模的增大，存儲平臺的數(shù)據(jù)查詢用時并不出現(xiàn)顯著增長。即使在用戶節(jié)點數(shù)達到6 000萬的規(guī)模下，不開啟緩存也能保持功能查詢平均用時在14 ms以內。特別是對指定重點人物的多次查詢，在緩存命中的情況下能保持用時在8 ms以內。由于本存儲系統(tǒng)基于HDFS文件系統(tǒng)搭建，其分布式架構本身具有良好的擴展性與可靠性。故本存儲平臺能夠成功地滿足實時性、可擴展性和易用性等要求。

5 結論

    本文建立了一套面向微博輿情分析的Hadoop存儲和管理系統(tǒng)。本系統(tǒng)可以安全、海量存儲微博數(shù)據(jù)，通過關系型數(shù)據(jù)庫Mysql和非關系型數(shù)據(jù)庫Hbase兩者的優(yōu)點進行SQL交互，實現(xiàn)海量數(shù)據(jù)存儲、實時數(shù)據(jù)查詢、快速檢索響應、可橫向擴展等優(yōu)點，有效解決了傳統(tǒng)關系型數(shù)據(jù)庫在存儲數(shù)據(jù)單一、存儲空間受限、不可橫向擴展存儲空間等缺點。

參考文獻

[1] SULLIVAN J.China′s Weibo：Is faster different?[J].New Media & Society，2014，16(1)：24-37.

[2] CHANG F，DEAN J，GHEMAWAT S，et al.Bigtable：A distributed storage system for structured data[J].ACM Transactions on Computer Systems(TOCS)，2008，26(2)：4.

[3] 潘夢云，李國玉，李燕.基于Hadoop云計算平臺的數(shù)據(jù)處理系統(tǒng)的研究與設計[J].通訊世界：下半月，2015(7)：224-225.

[4] 萬川梅.基于大數(shù)據(jù)下的NOSQL和Mysql融合的數(shù)據(jù)存儲模型研究[Ｊ].數(shù)字技術與應用，2014，2(2)：96-96.

[5] LEE C H，ZHENG Y L.Automatic SQL-to-NoSQL schema transformation over the MySQL and HBase databases[C].IEEE International Conference on Consumer Electronicstaiwan，2015：426-427.

作者信息:

余  輝1，黃永峰2，胡  萍3

(1.中國科學院大學，北京100043；2.清華大學 電子工程系，北京100084；

3.清華大學 網(wǎng)絡科學與網(wǎng)絡空間研究院，北京100084)