大数据开源舆情分析系统-数据采集技术架构浅析
輿情系統?中數據采集是一個關鍵部分，此部分核心技術雖然由爬蟲技術框架構建，但抓取海量的互聯網數據絕不是靠一兩個爬蟲程序能搞定，特別是抓取大量網站的情況下，每天有大量網站的狀態和樣式發生變化以后，爬蟲程序能快速的反應和維護。
一旦分布式的爬蟲規模大了以后會出現很多問題，都是種種技術挑戰，會有很多門檻，例如：
1.檢測出你是爬蟲，拉黑你IP(人家究竟是通過你的ua、行為特則還是別的檢測出你是爬蟲的?你怎么規避?)
2人家給你返回臟數據，你怎么辨認?
3對方被你爬死，你怎么設計調度規則?
4要求你一天爬完10000w數據，你一臺機器帶寬有限，你如何用分布式的方式來提高效率?
5數據爬回來，要不要清洗?對方的臟數據會不會把原有的數據弄臟?
6對方的部分數據沒有更新，這些未更新的你也要重新下載嗎?怎么識別?怎么優化你的規則?
7數據太多，一個數據庫放不下，要不要分庫?
8對方數據是JavaScript渲染，那你怎么抓?要不要上PhantomJS?
9對方返回的數據是加密的，你怎么解密?
10對方有驗證碼，你怎么破解?
11對方有個APP，你怎么去得到人家的數據接口?
12數據爬回來，你怎么展示?怎么可視化?怎么利用?怎么發揮價值?
13等等...
在大規模互聯網數據采集時，必須要構建一個完整的數據采集系統。否則，你的項目開發效率和數據采集效率會很低下。同時，還會很多讓你意想不到的問題發生。
開源輿情系統
目錄
開源輿情系統
在線體驗系統
開源技術棧
總體架構
數據處理流程
信源管理
站點畫像
數據抓取
數據暫存
低代碼開發
分布式采集
爬蟲管理
采集分類
反爬策略
采集日志
數據解析
在線體驗系統
- 環境地址：http://open-yuqing.stonedt.com/
- 用戶名：13900000000
- 密碼：stonedt
開源技術棧
- 開發平臺：Java EE & SpringBoot
- 爬蟲框架：Spider-flow & WebMagic & HttpClient
- APP爬蟲：Xposed框架
- URL倉庫：Redis
- web應用服務器：Nginx&Tomcat
- 數據處理和儲存任務發送：Kafka&Zookeeper
- 抓取任務發送：RabbitMQ
- 配置管理：MySQL
- 前端展示：Bootstrap & VUE
總體架構
?（這是最早期系統架構圖）
數據處理流程
?（這是最早期系統設計圖）
信源管理
信源，信息來源的簡稱。
我們需要對采集 類型，內容，平臺，地區 等多種屬性進行管理。我們對此開發了三代信源管理平臺。
一代產品形態
二代產品形態
三代產品形態
站點畫像
采用模擬瀏覽器請求技術實現深度和廣度抓取算法，總體分3個環節,對整個站點進行 1)全站掃描、2)數據儲存、3)特性分析。
-
siteMeta
識別整個網站的結構，并且解析存儲，給每一個抓取的網站都建立一個“小檔案”庫。
? -
siteIndex
在識別基礎上把所有網頁都預存儲下來，并且提取各種特征值進行分析計算，從站點目錄，到站點欄目，以及每個抓取目標頁面都會標記不同的特性參數。
? -
siteFeatures
最后將整體分析演算的結果，還原成這個網站的抓取畫像和特性，以便于機器將會知道采用哪種抓取策略自動去匹配這個網站的特性抓取，基于這樣的設計可以實現大規模數據采集無人值守的效果，也就是百度、谷歌 這些大型搜索引擎實現的數據效果。用“探頭機器人”對整個網站預抓取一遍，相當于一個先頭部隊，把抓取網站的情況搞清楚以后，很快機器就知道采取哪種采集策略，大量需要采集的網站，只有極小的部分需要人工干預采集，而且更不需要編寫一行爬蟲采集代碼，完全是自動化及低代碼化大規模數據采集。
數據抓取
-
自動抓取
有了網站的畫像屬性，就知道匹配那種采集抓取策略了，大部分網站就能自動抓取就自動識別抓取數據，無需人工干預。 -
人工配置
有的網站抓取難度大，采用可視化技術將整個站點的標簽提取出來給開發工程師，他們將可以快速的對網站的抓取進行配置。 我們在采集任何一個網站的時候將會有各種“探頭”對網站的結構，廣告位，關鍵性內容，導航欄，分頁，列表，站點特性，站點數據量，抓取難易度，站點更新頻率，等等。
- 采集模板
為了簡化人工操作，提高工作效率，我們還提供了爬蟲模板。爬蟲模板的意義在于，用戶遇到一個配置繁瑣的站點，不用從頭開始，只需要到爬蟲模板庫里面找類似的模板即可，如圖所示：?
數據暫存
- 暫存
如果把數據直接儲存到系統大數據庫里，一旦有大量采集的臟數據下來就是浪費時間和精力，所有數據都會預演儲存一遍，儲存完成后會有程序對此核對監測，以免數據字段漏存，錯存。 - 預警
如果在暫存環節發現儲存錯誤，將會及時通過郵件發送對研發工程師提醒，告知錯誤內容，讓其對此修正。
低代碼開發
-
配置
目前的爬蟲工廠已經一個低代碼化開發的平臺了，更準確的說，我們不是在上面開發，而且在上面進行爬蟲配置對數據采集抓取。如圖所示：? -
維護
通過低代碼的方式的開發，我們對爬蟲的維護更加方便，只需要在web管理界面中，修改爬蟲抓取配置即可，同時還可以在線調試，查看具體的抓取錯誤日志。否則某一個站點抓取出現問題，都不知道是哪臺服務器上的哪個爬蟲抓取錯誤。各種站點爬蟲的量一旦大起來，維護成本極高。?
分布式采集
-
控制器(master)
爬蟲工廠有一個web控制管理后臺，開發者可以在上面添加需要采集的任務計劃和數據采集抓取的規則策略，控制器只對采集任務下發抓取指令，不做任何抓取操作。
-
分發器(dispatch)
控制器(master)通過rabbitMQ消息將抓取的任務下發給任何一臺執行端， 消息中包含抓取的策略指令及采集目標，分發器只管發送指令和策略。
-
執行器 (downloader)
執行端可以部署在全世界任何一臺能連接互聯網的機器上，只要這臺機器能上網，能接受分發器下發的采集任務 就能把數據采集下來，同時把采集的數據回傳給中央數據倉庫。
爬蟲管理
-
爬蟲狀態
爬蟲分布式在很多臺服務器上，不知道在哪個服務器上的哪個爬蟲程序出了問題是很痛苦的事情，甚至抓取數據量猛增導致服務器掛掉都不知道。所以，需要能對服務器監控，對服務器上每一個爬蟲程序進行監控。監控每個爬蟲運行是否正常，監控每個運行爬蟲的服務器是否正常。
-
采集狀態
抓取的站點時常發生變化，我們就需要知道每個目標采集的站點抓取的數據是否都正常的采集下來了，通過給每個爬蟲編上采集任務編號，展示在web界面上，就可以直觀的看見數據采集下來的效果。通過郵件告警和每天發送郵件統計數據，可以實時對采集狀態進行監控。
采集分類
-
網站采集
一般采取兩種模式，直接http請求查看HTML代碼；另一種是模擬瀏覽器技術，把請求的JS渲染結果還原成HTML代碼，找到HTML標簽和URL路徑進行抓取。
-
公眾號采集
目前基本上就兩個路徑：通過搜狗微信 和 通過公眾號管理后臺。但是這兩個都封的實在太厲害了，經過多種嘗試采用RPA的模式模擬請求人工的操作+代理IP地址，對公眾號數據抓取。但是同時需要有大量的微信公眾號，因為，這種抓取方法是根據公眾號的號進行采集的，沒有公眾號就不知道抓取的目標。
-
app 采集
之前采用在開發環境的電腦上搭建一個WIFI共享讓手機APP連接電腦就能看見傳輸的數據了。目前app的數據采集代價越來越高，上檔次的APP幾乎沒有不加密的。所以，采用Xposed框架對數據采集是最穩定的采集方案了。
反爬策略
-
模擬請求頭
專門有一個數據表記錄存儲及更新各種瀏覽器請求的模擬請求頭，例如：Host、Connection、Accept、User-Agent、Referrer、Accept-Encoding、Accept-Language 等各種組合請求頭參數。
-
代理IP池
光是有代理IP是不夠的，一般穩定的ip池都很貴，而且代理IP資源對于需要采集的數據源來說永遠是匱乏的。換句話說，就需要能充分的利用好代理IP資源。主要實現兩大功能：1)實時檢查代理IP的有效性，拋棄無效的IP，提高爬蟲 請求效率。2) IP_1抓取過 A_網站被封掉了，但是不代表IP_1馬上抓取 B_網站和N_網站也會被封掉，這樣就充分的利用了代理IP。
采集日志
-
日志收集
系統采用了一臺獨立強勁的服務器專門做日志處理的服務器。這臺服務器收集來自四面八方爬蟲執行端和各個不同電信機房傳輸過來的錯誤日志信息。每個應用程序通過logback的kafak插件，寫入消息隊列，再批量寫入專門的 Elasticsearch 日志分析服務器。
-
跟蹤ID
為了能更加有效對問題排查，我們從抓取請求開始到數據存儲完畢。系統就給每個作業打上了唯一的日志標號，這樣的話，無論中間出了什么問題，上一步做了什么操作，執行了什么程序，都能有效的跟蹤和追溯。
-
日志分析
通過數據分析能看出目前哪類采集的數據有問題，當天或者這段時間內大面積的問題主要集中在什么地方，以及具體是哪些網站出了問題，這些抓取出問題的網站是不是重點關注的對象，等等。從面到點的去分析問題。
數據解析
-
自動解析
自動解析主要是用于資訊、招標、招聘，系統采用文本密度算法實現。因為這3個類型的數據雖然大致相同，但是網站多了以后還是千差萬別。如果依靠人工的方式一個個配置或者編寫代碼，將會是一場災難。
-
手動解析
只有在機器無法自動識別的情況下，采用人工配置，將網頁上的字段一一對應的填寫到低代碼爬蟲開發平臺。
總結
以上是生活随笔為你收集整理的大数据开源舆情分析系统-数据采集技术架构浅析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微信登录界面安卓代码_安卓Activit
- 下一篇： java商城系统设计—竞拍