抖音、快手資料采集，短視頻監測大屏
本文介紹在資料采集程序中不可或缺的一枚神器——資料采集監控大屏，如果想了解資料采集程序中的一些技術，歡迎查閱我的另外幾篇文章，文末附有兩篇資料采集文章的鏈接，先看下面三張圖：
三張圖，不同的時間段，對應的日采集資料量分別在10萬，30萬，110萬，不斷重繪自己創下的單日采集資料量記錄，可能有人會好奇，為什么最后兩天采集到的資料量有暴增的趨勢，偷偷告訴你們，這兩天是新架構設計方案完成之后，開始測驗的兩天，第一天輕松達到了53W資料，超過之前極大值近兩倍，而第二天更是突破了100W，所以，前面的凹槽，就是新架構開發測驗的時間了，圖片出自資料采集監控大屏，完整圖如下：
通過以上截圖可以得知，目前資料平臺總共采集了近700W資料，而最多一天采集資料達到了110W以上，日處理任務量達到30W以上，還能查看到不同業務通道采集到的不同資料的資料量，這個大屏建設的初衷就是為了監控資料采集平臺各方面的性能，在采集平臺性能優化的同時，監控大屏也在不斷優化自身的性能，占用越來越少的平臺資源，其中最大的優化算是每日采集資料量統計圖，而隨著資料量的不斷增加，不僅平臺壓力越來越大，監控大屏性能也越來越差，統計到的阻塞數量也越來越多，這個阻塞數目，監控的是記憶體中執行緒的阻塞數，如果這個數量越來越多，最直接的后果就是死機，而每天的資料量還在增加，業務也在擴大，硬體資源就那么多，急需尋找新的解決辦法，在這種場景下，資料采集平臺2.0架構設計橫空出世，解決所有阻塞問題，而且將日采集資料量從30萬提升到110萬，理論值從50萬提升到160萬，資料采集平臺2.0架構設計為將來的資料暴增預留了位置，支持分布式的橫向擴展，這樣，隨著以后資料的增長，升級就變得非常簡單了，接下來本篇文章主要介紹這款監控大屏，
監控大屏簡介
監控大屏主要運用資料可視化技術，對采集平臺進行監控，定時重繪平臺運行資料，通過這款監控大屏，曾經發現了平臺的一個死鎖問題，當時問題非常隱蔽，平臺沒有報錯，資料還在增加，通過大屏，意識到資料增長變得有一點慢了，有幾張表沒入庫資料，后來開始排查，發現了平臺死鎖問題，如果該問題沒被發現，后續造成的損失將變得不可控制，監控大屏功能如下：
1.每日采集資料量：統計平臺近期，每天采集到的資料量，以此來判斷平臺在一段時間內的健康狀況和負載情況，可根據該指標制定性能測驗計劃，
2.各主機執行任務統計：統計當前小時，各臺機器執行任務的數量，以此來判斷各個機器的性能以及資源配置，
3.全網資料量：統計整個平臺實時資料量，以此來判斷平臺壓力，確定是否需要升級新架構，
4.當前時間采集資料量：統計當前小時，每張表增加的資料量，對每一類資料是否正確入庫做監控，
5.全網資料分布：統計平臺所有表的資料量，以此來判斷各表壓力，為后續分庫分表提供依據，
6.阻塞數統計：統計個主機中，各個程式阻塞的執行緒數，以此來判斷各機器的性能，阻塞越多，記憶體占用越多，最終將導致機器宕機，理想情況是，此處為空白，即程式運行不阻塞，
7.各類任務執行數：統計不同種類任務，不同狀態任務的數量，以此來判斷平臺執行任務的速度以及正確率，
8.采集速度監控，采用儀表盤監控當前實時的資料采集速度，以及監控程序中出現的采集速度峰值，以此來判斷平臺實時的效率，
通過以上八部分實時資料，即可監控整個資料采集平臺運行狀況，目前該大屏運行超過兩個月，以下列舉幾個常見問題案例：
案例1
如下圖所示，待執行任務有1440個，正在執行任務16個，主機執行任務統計圖為空，且資料超過1分鐘未重繪，
決議：任務無法執行，當前小時已經沒有任務結束
原因及解決方案：
1.任務復雜，短時間內無法執行完成（幾乎不可能有這種情況）
2.程式掛起，無法執行任務，需要重啟程式
3.記憶體不足，程式自動結束，需要重啟程式
4.機器宕機，需要重啟機器，
案例2
如下圖，丟棄任務暴增，
決議：大量任務已達到重試最大次數，或者出現大量已重置用戶
原因及解決方案：
1.出現大量已重置用戶，檢查是否真的出現了大量重置用戶，如確實如此，可不處理，平臺會定時處理該類資料，只需等待20分鐘即可，
2.介面被官方反爬，采集不到資料了，需要升級采集代碼，優化采集策略，
案例3
如下圖，當前時間采集資料量中，只有一兩個表采集到資料且長時間沒有新表加入，
決議：其他表在當前時間都沒有資料入庫
原因及解決方案：
1.當前為定向采集時間，只采集指定型別的資料，正常，無需處理，
2.其他型別的資料決議程序出錯，檢查資料，查看是否會有超長資料，空資料出現，導致決議失敗，如：前期采集到重置用戶時，導致決議器報錯，現已適配，
3.歷史資料中已經存在了采集過的資料，資料沒有新增，正常，無需處理，
4.個別表鎖表，需要排查資料庫，殺死死鎖行程，
案例4
如下圖，各機器整體阻塞較高
決議：該部分統計每個機器上面每一類程式的阻塞情況
原因及解決方案：
1.同一任務阻塞較高，該任務代碼性能不足，需要升級代碼性能
2.同一機器不同任務阻塞較高，該機器硬體不足，需要減少任務量或者升級機器性能，
案例5
如下圖，機器處理任務不平均，有機器“偷懶”，
決議：該機器執行任務相對其他機器明顯偏少
原因及解決方案：
1.機器硬體性能較其他機器低，升級機器，使用相同配置機器，
2.該機器處理任務較復雜，優化取任務策略，不同型別任務隨機獲取
3.該機器的行程假死，需要重啟該機器上運行的行程，
案例6
大屏資料更新正常，處理任務正常，但是資料增量較慢，
決議：資料增長較慢，但是處理任務速度正常，應該懷疑是否是由于丟資料引起
原因及解決方案：
1.有資料未決議，直接跳過，需要排查未處理資料的型別，
2.鎖表，需要手動釋放鎖，修改代碼，所有的寫操作均用主鍵ID
以上為這兩個多月時間中，見過的一些常見案例，此類問題均由該監控大屏拋出，并以解決，
更多抖音，快手，小紅書資料實時采集介面，請查看檔案： TiToData
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/236495.html
標籤：其他