（一）KAFKA統一數據推送接口
1) 非空校驗
處理邏輯：除標題爲空數據直接存入異常MySQL庫中外，其他類型的數據直接流到數據質量校驗步驟進行分析；
2) 數據質量校驗
主要是根據每個字段設置的校驗規則，對其進行相應的校驗處理。
3) 二次排重處理：
由於Bloom Filte中的元素只可以添加，不可以被刪除。又由於數據量較大(每天5000W左右)，長時間會耗費很多內存資源，投入較大。
同時，排重庫中並不需要保留所有的歷史記錄，比如只保留最近半年或一年的記錄，如何自動清除歷史記錄，又成了新的問題。
所以，最後決定使用Redis的XX類型數據，利用Redis自身特性，對主鍵key設置自動過期時間，減少運維的難度和成本。
4) 數據清洗處理
目前主要是對異常網站和特殊關鍵詞進行清除。
處理對象：【正常】數據
5) 數據矯正處理：
由於輿情繫統對數據的時效性有較強的要求，爲了保證數據覆蓋度，減少人工補錄帶來的工作量，需要對發現的異常數據進行二次加工，然後推送到kafka。
處理對象：【異常】數據
u 標題矯正
根據數據質量校驗中的五條規則，對數據進行二次清洗，然後推送到流程下一步。如果標題爲空，則直接丟棄。
u 內容矯正
內容矯正主要分兩種情況：空和非空。其各自的處理邏輯如下所示：
1) 內容爲空
此時進行一下處理：
① 使用URL調用正文獲取接口，進行二次獲取；
② 如果仍然爲空，則使用標題作爲內容進行推送，但是進行標識，以便kafka進行分發時，不發送信息到APP客戶端，增強用戶體驗；
2) 內容非空
此時主要根據數據質量校驗中的檢測結果，對其進行二次清洗。主要包括：刪除html內容，清楚特殊關鍵詞、亂碼等情況。
u 發佈時間矯正
主要是根據非空規則和質量規則中，針對發佈時間的校驗結果，對其做相應的矯正。如：
① 爲空，則用採集時間填充
② 大於採集時間，則用採集時間填充；
③ 格式不符合要求，則規範爲”yyyy-MM-dd hh:mm:ss”格式等。
u URL矯正
1) 臨時參數矯正
該種情況在搜索採集時比較常見。一般情況下是每個鏈接後面加一個時間戳參數，每搜索一次變一次，導致數據大量重複。所以，需要清除臨時參數，還原鏈接本貌。比如：搜狗微信搜索採集時。
1) HTTP和HTTPS協議矯正；
有些信息可能因爲來源的不同，導致網絡協議不同，鏈接其實是指向同一條信息。此時，需要對http和https進行矯正、統一。
u 網站名稱矯正
1) 根據域名矯正
由於元搜索採集的信息，可能會沒有網站名稱信息，需要和信源系統進行關聯獲取填充。
u 數據類型矯正
1) 根據域名矯正
把某一域名的數據全部更改爲新的數據類型。
該種情況主要出現在綜合搜索、或者欄目類型配置錯誤的情況，導致kafka數據分發異常，影響產品用戶體驗。
比如罵街的評論信息錯誤標識爲新聞，導致只顯示新聞信息的APP等產品的用戶體驗降低；
6) 數據推送日誌
u 需記錄字段
包括但不限於：
① 接口服務ID
② 接口名稱（方法名）
③ 接口接受請求時間
④ 推送結束時間
⑤ 接口接受數據量
⑥ 校驗異常數據量
⑦ 推送kafka成功量
⑧ 推送kafka失敗量
⑨ Kafka的Topic名稱
⑩ 推送人(信源系統用戶ID)：以便快速定位採集人
⑪ 採集器ID：以便快速定位採集器，查詢相關問題
未來計劃
（一）優化服務器監控
優化現有的服務器監控策略，使其和採集策略進行協調；
（二）優化採集器運維
能夠根據採集相關資源(如服務器資源)，自動根據設定的規則，進行部署的自動調整，以便使資源利用最大化。
如需三期完整文檔，請關注公衆號，回覆“監控”獲取。
相關閱讀：
爬蟲系列之數據質量監控（一）
本文分享自微信公衆號 - 十點數據（crawler-small-gun）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。