《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > 微博輿情的Hadoop存儲和管理平臺設計與實現
微博輿情的Hadoop存儲和管理平臺設計與實現
2017年電子技術應用第3期
余 輝1,黃永峰2,胡 萍3
1.中國科學院大學,北京100043;2.清華大學 電子工程系,北京100084; 3.清華大學 網絡科學與網絡空間研究院,北京100084
摘要: 隨著Internet技術的迅速發展,網絡輿情監控系統正在得到廣泛應用。網絡輿情監控系統的數據量也急速膨脹,如何高效地存儲和管理這些海量的非結構或半結構化數據成為網絡輿情系統研發中的挑戰課題。傳統的關系數據庫和分布式計算等數據處理的方式也越來越不能適應日益增長網絡大數據。針對微博數據的特點建立了一種面向微博輿情應用的Hadoop存儲平臺的多層體系架構,并采用列數據庫設計多種微博結構化數據的表結構,以及表之間的關系模型。測試結果表明,設計的存儲管理平臺具有檢索響應速度快、可擴展性好等特點。
中圖分類號: TP399
文獻標識碼: A
DOI:10.16157/j.issn.0258-7998.2017.03.030
中文引用格式: 余輝,黃永峰,胡萍. 微博輿情的Hadoop存儲和管理平臺設計與實現[J].電子技術應用,2017,43(3):120-123,131.
英文引用格式: Yu Hui,Huang Yongfeng,Hu Ping. Design and implementation of Hadoop based storage and management platform on the Weibo public opinion[J].Application of Electronic Technique,2017,43(3):120-123,131.
Design and implementation of Hadoop based storage and management platform on the Weibo public opinion
Yu Hui1,Huang Yongfeng2,Hu Ping3
1.University of Chinese Academy of Sciences,Beijing 100043,China; 2.Department of Electronic Engineer,Tsinghua University,Beijing 100084,China; 3.Institute for Science and Network Space Sciences,Tsinghua University,Beijing 100084,China
Abstract: Along with the rapid development of Internet technology continuously, the network public opinion monitor system has been widely used. The amount data of Network public opinion monitoring system has been rapidly expanding, resulting in how to efficiently store and manage the vast amounts of unstructured or semi-structured data become challenge subject in network public opinion system research and development. Traditional relational database and distributed computing and data processing have been becoming more and more not suitable to the increasing network data. This paper establishs a multi-layer architecture based on Hadoop storage platform of Weibo public opinion application according to the characteristics of Weibo data, and uses column database to design a variety of the table structure of Weibo structured data, and the model of the relationships between tables. Test result shows that the designed storage management platform has the charactistics of the rapid reaction rate of retrieve and good scalability, etc.
Key words : opinion analysis;Hadoop;Hbase;cloud storage;cloud computing

0 引言

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

1 相關技術

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

1.1 微博數據結構

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

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

1.2 Hbase

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

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

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

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

jsj3-t1.gif

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

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

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

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

3 微博關系數據的存儲表的設計與實現

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

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

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

3.1 關鍵字索引表

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

jsj3-b1.gif

3.2 用戶屬性表

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

jsj3-b2.gif

3.3 用戶關系表

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

jsj3-b3.gif

3.4 微博屬性表

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

jsj3-b4.gif

3.5 微博關系表

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

jsj3-b5.gif

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

    本節將搭建Apache版本Hadoop2.6分布式集群環境,對本平臺系統性能進行實驗測試和評估,通過SQL語句驗證其實際應用中的性能。

4.1 實驗環境及軟件配置

    表6為服務器集群環境及軟件配置表。用7個服務器使用Apache版本Hadoop2.6分布式集群部署,其中一臺服務器作為主節點Master,其余6臺作為平臺的數據節點Data,系統軟硬件配置見表6。

jsj3-b6.gif

4.2 實驗數據

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

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

jsj3-b7.gif

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

jsj3-t2.gif

5 結論

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

參考文獻

[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云計算平臺的數據處理系統的研究與設計[J].通訊世界:下半月,2015(7):224-225.

[4] 萬川梅.基于大數據下的NOSQL和Mysql融合的數據存儲模型研究[J].數字技術與應用,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.清華大學 網絡科學與網絡空間研究院,北京100084)

此內容為AET網站原創,未經授權禁止轉載。
亚洲一区二区欧美_亚洲丝袜一区_99re亚洲国产精品_日韩亚洲一区二区
久久大综合网| 亚洲欧美视频在线观看| 亚洲天堂av图片| 一区二区三区|亚洲午夜| 国产精品免费视频观看| 久久久久久9999| 亚洲人成网在线播放| 亚洲精品永久免费| 国产精品成人播放| 久久精品一本| 亚洲美女色禁图| 噜噜噜91成人网| 一区二区三区日韩在线观看| 亚洲综合电影| 亚洲高清中文字幕| 欧美亚男人的天堂| 欧美日韩一区二区三| 久久精品女人天堂| 久久精品国产成人| 久久久久久久网站| 久久另类ts人妖一区二区| 久久久久成人精品| 免费精品99久久国产综合精品| 中日韩视频在线观看| 小黄鸭精品aⅴ导航网站入口| 在线观看日韩av| 国产精品久久久久久久久借妻 | 亚洲手机视频| 亚洲一区二区免费| 亚洲性视频网站| 欧美一区二区三区视频免费播放 | 久久www成人_看片免费不卡 | 亚洲最新色图| 一区在线播放视频| 国产精品免费观看视频| 国产欧美精品va在线观看| 欧美精品福利视频| 久久久夜精品| 欧美成年人视频网站欧美| 欧美在线日韩精品| 亚洲视频在线观看免费| 亚洲欧美一区二区三区久久| 99视频在线观看一区三区| 久久精品国产久精国产一老狼 | 欧美高清视频在线| 久久久久久久久蜜桃| 免费观看30秒视频久久| 欧美日韩国产综合视频在线观看中文 | 亚洲免费电影在线观看| 国语自产在线不卡| 国产精品亚洲综合| 欧美三级第一页| 欧美另类变人与禽xxxxx| 久久久久综合一区二区三区| 嫩草国产精品入口| 久久先锋影音av| 久久av红桃一区二区小说| 欧美 日韩 国产一区二区在线视频| 欧美日韩ab| 国产三级欧美三级日产三级99| 国产精品乱码人人做人人爱| 国模精品娜娜一二三区| 国产日本欧美在线观看| 亚洲国产高清在线| 亚洲自拍高清| 亚洲精品一区二区三区不| 欧美在线视频不卡| 欧美久久99| 狠狠色香婷婷久久亚洲精品| 亚洲图片欧美日产| 亚洲一区二区成人| 99精品视频一区二区三区| 亚洲美女一区| 久久精品一二三| 午夜免费日韩视频| 欧美一区二区三区四区在线观看地址| 久久最新视频| 国产精品一区一区| 国产日韩欧美不卡| 91久久精品美女| 亚洲精品网站在线播放gif| 午夜日韩视频| 亚洲高清在线视频| 亚洲裸体俱乐部裸体舞表演av| 欧美一区视频| 欧美午夜精品伦理| 亚洲欧洲偷拍精品| 一区二区精品国产| 亚洲成人资源网| 亚洲国产日韩在线| 亚洲日本中文字幕区| 久久av红桃一区二区小说| 欧美日韩免费高清一区色橹橹| 黄色成人精品网站| 欧美亚洲综合网| 亚洲综合不卡| 久久精品日韩一区二区三区| 欧美色区777第一页| 亚洲国产一区二区在线| 久久精品首页| 久久久久五月天| 国产亚洲精品久久久久久| 国产精品视频999| 亚洲日本欧美| 亚洲精品免费一区二区三区| 久久夜色撩人精品| 国产在线拍偷自揄拍精品| 午夜精品久久| 欧美一区二区成人| 国产精品亚洲аv天堂网| 亚洲午夜高清视频| 亚洲综合第一| 国产精品少妇自拍| 亚洲欧美久久| 欧美一区二区三区在线视频| 国产精品久久久久久久久| 亚洲少妇诱惑| 亚洲男人第一av网站| 国产精品扒开腿爽爽爽视频| 一本色道婷婷久久欧美| 亚洲天堂黄色| 国产精品久久久久久影院8一贰佰 国产精品久久久久久影视 | 国产乱码精品一区二区三区忘忧草| 亚洲视频网站在线观看| 亚洲一区在线观看视频| 欧美在线一级va免费观看| 国产精品伊人日日| 欧美一区二区三区另类| 一本久道久久久| 欧美日韩美女| 在线视频中文亚洲| 亚洲欧美日本在线| 国产欧美日韩| 久久成人18免费网站| 久热精品视频在线观看一区| 在线免费观看日本欧美| 亚洲女同精品视频| 欧美在线视频观看免费网站| 国产网站欧美日韩免费精品在线观看| 欧美一区二区精品久久911| 久久久国产精品一区二区中文| 黄色成人在线观看| 99re6热在线精品视频播放速度| 欧美在线日韩在线| 国产综合久久| 亚洲另类春色国产| 欧美吻胸吃奶大尺度电影| 校园春色综合网| 欧美成年人网站| 一本久道久久综合狠狠爱| 久久本道综合色狠狠五月| 亚洲第一精品影视| 亚洲一区二区三区色| 国产亚洲一区二区三区在线观看| 亚洲国产精品999| 欧美日韩一区二区在线| 午夜在线精品偷拍| 免播放器亚洲一区| 在线视频日韩| 久久亚洲精品伦理| 亚洲精品乱码久久久久久日本蜜臀| 亚洲女女做受ⅹxx高潮| 激情国产一区二区| 一本色道久久综合亚洲精品高清| 国产精品香蕉在线观看| 亚洲国产日日夜夜| 国产精品久久久久久亚洲毛片| 久久高清国产| 欧美视频一区在线| 久久精品成人一区二区三区蜜臀| 欧美日韩成人综合| 午夜精品视频网站| 欧美激情一区在线| 销魂美女一区二区三区视频在线| 欧美高清成人| 午夜精品亚洲| 欧美日韩亚洲一区二区三区在线观看 | 亚洲欧美国产日韩天堂区| 蜜桃精品久久久久久久免费影院| 亚洲最新合集| 免费日韩视频| 午夜精品视频在线观看一区二区| 欧美激情一区二区三区不卡| 欧美一区二区三区日韩视频| 欧美日韩免费区域视频在线观看| 久久精品国产99国产精品澳门| 欧美色精品天天在线观看视频| 亚洲国产精品久久久久婷婷884| 国产精品久久久久久久久婷婷| 亚洲人成在线观看| 国产一区二区在线免费观看| 亚洲午夜精品网| 亚洲国产乱码最新视频| 久久国产日韩欧美| 亚洲视频在线视频| 欧美风情在线观看| 欧美在线亚洲一区| 国产精品推荐精品| 中文精品视频| 亚洲精品你懂的|