基于Hadoop集群的大數據新聞可視化平臺的設計

王一高 任耀星 李嘉瑤

（山西農業大學 山西省晉中市 030801）

隨著智能推薦系統的不斷發展和完善，智能推薦算法在各種軟件中得到了應用。智能推薦算法在讓人們毫不費力地瀏覽到自己關心的事物同時給軟件運營商帶來收益，但是長此以往，人們的視野逐漸變窄，眼里的世界不再那么豐富多彩，不能全方位了解和分析客觀事物。因此本文設計了一種全新的新聞可視化平臺，該平臺的目的就在于幫助人們擺脫智能推薦算法，可以快速地按熱詞來瀏覽相關新聞，用最短的時間獲取到最多的信息。

1 系統設計

本文所設計的大數據新聞可視化平臺的系統架構圖見圖1。一般情況下，大數據的處理由數據采集、數據預處理、數據存儲、數據分析與挖掘、數據可視化這五部分構成。本文所設計的大數據新聞可視化平臺依賴于Hadoop 集群實現：數據采集部分使用分布式多進程網絡爬蟲采集互聯網主流新聞媒體的熱榜數據；之后在爬蟲內部進行數據預處理，篩選或刪除掉一些不規則的數據；數據存儲部分使用HDFS 存儲離線數據，使用MySQL 存儲實時處理結果；數據分析部分分為實時數據分析和離線數據分析，通過SparkStreaming 進行實時流數據處理，通過MySQL 或HiveSQL 進行離線數據分析，其中MySQL 的數據分析結果用于數據可視化，HiveSQL 則用于海量離線數據分析。

2 系統實現

2.1 Hadoop高可用集群部署

由于單個NamNode 節點存在單點故障且面對海量數據存在壓力過大的問題，一旦該節點發生宕機，整個集群都會不可用[1]。為了解決上述問題，Hadoop 在2.0 版本中引入了高可用機制，旨在消除單點故障，提供7*24 小時不間斷服務。以典型的高可用集群為例，會有兩個NameNode 節點提供服務，一個NameNode 處于Active 狀態、另一個NameNode 處于StandBy 狀態，當Active 狀態的NameNode 發生宕機時，StandBy 狀態的NameNode 會自動轉為Actie 狀態接續工作。

本文所搭建的高可用集群由3 臺CPU 為2 核、內存為4GB、操作系統為CentOS 7.4 64 位的云服務器組成。主機名分別為：Cluster01,Cluster02,Cluster03。使用Xftp 將相關組件的安裝包上傳到服務器解壓后進行安裝配置。

2.2 分布式Flume日志采集

圖1：系統架構圖

圖2：詞頻統計圖

圖3：熱度趨勢圖

Flume 通常以分布式的形式部署于Hadoop 集群中，它具有高可用和高可靠的特性。Flume 的核心角色是Agent，每個Agent 的內部有三個組件：Source、Sink、Channel。Flume 可以根據用戶的需求進行靈活的定制，可以是單個Agent 采集數據，也可以是多個Agent 之間進行串并聯，共同采集數據。在本文所搭建的分布式Flume日志采集系統中，Cluster02 和Cluster03 的Source 是分布式多進程爬蟲產生的新聞數據，Sink 均對接Cluster01 所部署Flume的Source。Cluster01 的Sink 為Hbase 數據庫和Kafka 消息隊列。爬蟲每半小時運行一次，當Flume 監測到日志文件發生變化時會自動對日志文件的新增內容進行采集和匯總，然后分別傳輸到Kafa消息隊列和Hbase 數據庫中。

2.3 分布式多進程爬蟲部署

經實測爬蟲每次運行會產生4-5 萬條數據，普通的單線程爬蟲在爬取海量新聞數據時顯得力不從心，無法保證在短時間內完成數據的更新。且爬蟲屬于IO 密集型任務，在短時間內會進行大量的讀寫操作[2]。為了加快爬取速度并實現數據的及時更新，需根據爬取任務量對服務器進行負載均衡。依托于Hadoop 集群，分布式多進程爬蟲得以實現[3]。其中Cluster02 和Cluster03 負責爬取數據并將每次爬取的數據寫入緩存文件，與此同時，Cluster02 和Cluster03 上部署的分布式Flume 負責監督并將爬蟲產生的數據傳輸給Cluster01 進行匯總。新聞數據具有很強的時效性，部分新聞媒體的更新頻率很高，所以分布式爬蟲設定每半小時運行一次。

2.4 Kafka消息隊列

Kafka 是一種基于發布-訂閱的分布式消息系統，其具有高吞吐量、低延遲的特性，廣泛應用于消息傳遞、日志收集領域。Kafka 可以將消息持久化存儲在硬盤上，從而規避了數據丟失的風險，并且消費者可以憑借偏移量在一段時間后實現繼續消費。在本文搭建的Hadoop 集群中，Cluster01 節點的Flume 相當于Kafka 的生產者，SparkStreaming 端作為Kafka 消費者接收海量新聞數據進行實時處理。

2.5 SparkStreaming流數據處理

Spark 是一個面向大數據處理而設計的計算引擎，與Hadoop的MapReduce 相比,其內存計算的特性使得其中間結果不必反復寫入磁盤，避免產生大量的IO 開銷，因此可以在短時間內完成對海量數據的處理。SparkStreaming是構建于SparkCore之上的一套框架，具有高吞吐量、容錯的特性，主要用來處理實時流式數據，其將接收到的實時輸入數據流按照時間間隔進行切分后計算處理。其數據源可以是Kafka、Flume、HDFS 等，處理結果支持寫入HDFS 或其它數據庫。

在本文所設計的新聞可視化平臺中，SparkStreaming 程序作為Kafka 的消費者，在取到數據之后使用Jieba 中文分詞對新聞文本切分并進行詞頻統計，為便于數據可視化，將處理結果寫入MySQL數據庫中，為了避免數據冗余，MySQL 數據庫在每次數據更新前都會執行清空指令。

2.6 HBase數據庫

HBase 是一個分布式的、面向列的開源數據庫，是BigTable的開源實現，其構建于HDFS 之上，具有高性能、面向列、可伸縮的特性，廣泛應用于社交信息、搜索引擎、網絡日志等的存儲。HBase 支持通過JavaAPI、HBase Shell、Hive 等進行訪問。將Flume 的Sink 設置為HBase 并創建相應表便可以實現HBase 與Flume 的對接。本文所編寫的分布式爬蟲每半小時運行一次，若每次爬取的數據都寫入HBase 數據庫，則會造成數據冗余，浪費存儲容量，因此離線數據每日只寫入一次。爬蟲采集的新聞按類別可以分為：時政、經濟、法律、軍事、科技、文教、體育、社會等，數據的不斷積累可以構建出專屬的新聞語料庫，這可為日后的機器學習、文本分類、NLP 研究提供數據支撐。

2.7 Hive離線分析

圖4：國內新聞地圖

圖5：國際新聞地圖

圖6：新聞來源及內容

Hive 是一個采用MapReduce 作為計算引擎，HDFS 作為文件系統的數據倉庫工具，Hive 的編程語言為HiveSQL，是一種類SQL 語言，其特點是可以將SQL 查詢轉換為MapReduce 任務進行處理，具有簡單易上手的特點。可以通過在Hive 中創建HBase 的外部表來訪問HBase 中的離線新聞數據并進行大規模數據分析。

2.8 百度Sugar數據可視化

本文采用了百度Sugar 的解決方案，首先將處理后的數據寫入到數據庫中并開放數據庫相應端口，將集群數據庫添加到Sugar 中作為數據源，然后在Sugar 中設計好可視化版式并編寫相應SQL 語句便可以實現數據可視化。且Sugar 支持圖表下鉆功能，提供了優美的界面和強大的交互體驗，可以讓開發者將工作重心更多地放在數據分析與處理而不是前端頁面開發。

2.8.1 熱詞詞頻統計

查詢數據庫中詞頻統計結果的前30 條數據，以橫向柱圖的形式進行展示，見圖2。點擊單個柱子會自動彈框展示包含熱詞的相關新聞。

2.8.2 熱度演變趨勢

根據積累的歷史數據，可以進一步展開數據分析，以橫向柱圖中的熱詞作為關鍵字在數據庫中進行模糊匹配并按日期分組求和，可以得出該熱詞的變化趨勢[4]。以最近的“日本決定向大海排核污染水”新聞為例，查看“日本”的熱度演變趨勢，由圖可以看出在2021-4-12 之后，“日本”的相關熱度驟然增高，見圖3。

2.8.3 新聞地圖

在使用Jieba 分詞器完成中文分詞后，分詞中包含著若干地名信息，將地名信息提取統計之后顯示在地圖上可以構建一幅新聞地圖[5]。本文的新聞地圖由國內新聞地圖（圖4）和國際新聞地圖（圖5）組成。國內新聞地圖以氣泡圖的大小反映該地區新聞數量，國際新聞地圖則以色塊的形式反映國家的新聞數量。點擊區域或國家，均可彈框展示包含該區域或國家的新聞，通過傳遞參數，點擊熱點名會自動使用百度對該內容進行搜索，見圖6。

3 總結與展望

本平臺是一種使用大數據相關技術開發的大數據新聞統計分析平臺，在完成新聞數據可視化的同時構建新聞語料庫。通過爬取全網各大新聞媒體平臺的實時數據，并對其熱榜信息進行聚合，實現對新聞網站的各種信息（來源，分類，熱度信息等）的分析。通過統計分析的數據，將實時新聞熱點進行可視化展示。首先本平臺有助于用戶告別智能推薦，減少不必要信息的干擾，從而更全面的按照自己的需求查看新聞。通過聚合全網信息，客戶可以用較短的時間去快速瀏覽、獲取更多的信息，這種方案簡單高效，是一種全新的新聞獲取思路。并且本文所構建的新聞語料庫可為后續實驗和科學研究提供數據支撐。