抖音、快手數據採集,短視頻監測大屏

抖音、快手數據採集,短視頻監測大屏

本文介紹在數據採集過程當中不可或缺的一枚神器——數據採集監控大屏,若是想了解數據採集過程當中的一些技術,歡迎查閱個人另外幾篇文章,文末附有兩篇數據採集文章的連接。先看下面三張圖:
image.png
image.png
image.png
三張圖,不一樣的時間段,對應的日採集數據量分別在10萬,30萬,110萬,不斷刷新本身創下的單日採集數據量記錄,可能有人會好奇,爲何最後兩天採集到的數據量有暴增的趨勢,偷偷告訴大家,這兩天是新架構設計方案完成以後,開始測試的兩天,第一天輕鬆達到了53W數據,超過以前極大值近兩倍,而次日更是突破了100W,因此,前面的凹槽,就是新架構開發測試的時間了。圖片出自數據採集監控大屏,完整圖以下:
image.png
經過以上截圖能夠得知,目前數據平臺總共採集了近700W數據,而最多一天採集數據達到了110W以上,日處理任務量達到30W以上,還能查看到不一樣業務通道採集到的不一樣數據的數據量。這個大屏建設的初衷就是爲了監控數據採集平臺各方面的性能,在採集平臺性能優化的同時,監控大屏也在不斷優化自身的性能,佔用愈來愈少的平臺資源,其中最大的優化算是每日採集數據量統計圖。而隨着數據量的不斷增長,不只平臺壓力愈來愈大,監控大屏性能也愈來愈差,統計到的阻塞數量也愈來愈多,這個阻塞數目,監控的是內存中線程的阻塞數,若是這個數量愈來愈多,最直接的後果就是死機。而天天的數據量還在增長,業務也在擴大,硬件資源就那麼多,急需尋找新的解決辦法,在這種場景下,數據採集平臺2.0架構設計橫空出世,解決全部阻塞問題,並且將日採集數據量從30萬提高到110萬,理論值從50萬提高到160萬。數據採集平臺2.0架構設計爲未來的數據暴增預留了位置,支持分佈式的橫向擴展,這樣,隨着之後數據的增加,升級就變得很是簡單了,接下來本篇文章主要介紹這款監控大屏。數據庫

監控大屏簡介

監控大屏主要運用數據可視化技術,對採集平臺進行監控,定時刷新平臺運行數據,經過這款監控大屏,曾經發現了平臺的一個死鎖問題,當時問題很是隱蔽,平臺沒有報錯,數據還在增長,經過大屏,意識到數據增加變得有一點慢了,有幾張表沒入庫數據,後來開始排查,發現了平臺死鎖問題。若是該問題沒被發現,後續形成的損失將變得不可控制。監控大屏功能以下:
1.每日採集數據量:統計平臺近期,天天採集到的數據量,以此來判斷平臺在一段時間內的健康情況和負載狀況。可根據該指標制定性能測試計劃。
image.png
2.各主機執行任務統計:統計當前小時,各臺機器執行任務的數量,以此來判斷各個機器的性能以及資源配置。
image.png
3.全網數據量:統計整個平臺實時數據量,以此來判斷平臺壓力,肯定是否須要升級新架構。

4.當前時間採集數據量:統計當前小時,每張表增長的數據量,對每一類數據是否正確入庫作監控。
image.png
5.全網數據分佈:統計平臺全部表的數據量,以此來判斷各表壓力,爲後續分庫分表提供依據。
image.png
6.阻塞數統計:統計個主機中,各個程序阻塞的線程數,以此來判斷各機器的性能,阻塞越多,內存佔用越多,最終將致使機器宕機。理想狀況是,此處爲空白,即程序運行不阻塞。
image.png
7.各種任務執行數:統計不一樣種類任務,不一樣狀態任務的數量,以此來判斷平臺執行任務的速度以及正確率。

8.採集速度監控,採用儀表盤監控當前實時的數據採集速度,以及監控過程當中出現的採集速度峯值,以此來判斷平臺實時的效率。
image.png
經過以上八部分實時數據,便可監控整個數據採集平臺運行情況。目前該大屏運行超過兩個月,如下列舉幾個常見問題案例:性能優化

案例1

以下圖所示,待執行任務有1440個,正在執行任務16個,主機執行任務統計圖爲空,且數據超過1分鐘未刷新。
image.png
解析:任務沒法執行,當前小時已經沒有任務結束
緣由及解決方案:
1.任務複雜,短期內沒法執行完成(幾乎不可能有這種狀況)
2.程序掛起,沒法執行任務。須要重啓程序
3.內存不足,程序自動結束。須要重啓程序
4.機器宕機。須要重啓機器。架構

案例2

以下圖,丟棄任務暴增。

解析:大量任務已達到重試最大次數,或者出現大量已重置用戶
緣由及解決方案:
1.出現大量已重置用戶。檢查是否真的出現了大量重置用戶,如確實如此,可不處理,平臺會定時處理該類數據,只需等待20分鐘便可。
2.接口被官方反爬,採集不到數據了。須要升級採集代碼,優化採集策略。分佈式

案例3

以下圖,當前時間採集數據量中,只有一兩個表採集到數據且長時間沒有新表加入。
image.png
解析:其餘表在當前時間都沒有數據入庫
緣由及解決方案:
1.當前爲定向採集時間,只採集指定類型的數據。正常,無需處理。
2.其餘類型的數據解析過程出錯。檢查數據,查看是否會有超長數據,空數據出現,致使解析失敗。如:前期採集到重置用戶時,致使解析器報錯,現已適配。
3.歷史數據中已經存在了採集過的數據,數據沒有新增。正常,無需處理。
4.個別表鎖表。須要排查數據庫,殺死死鎖進程。性能

案例4

以下圖,各機器總體阻塞較高
image.png
解析:該部分統計每一個機器上面每一類程序的阻塞狀況
緣由及解決方案:
1.同一任務阻塞較高。該任務代碼性能不足,須要升級代碼性能
2.同一機器不一樣任務阻塞較高。該機器硬件不足,須要減小任務量或者升級機器性能。測試

案例5

以下圖,機器處理任務不平均,有機器「偷懶」。
image.png
解析:該機器執行任務相對其餘機器明顯偏少
緣由及解決方案:
1.機器硬件性能較其餘機器低。升級機器,使用相同配置機器。
2.該機器處理任務較複雜。優化取任務策略,不一樣類型任務隨機獲取
3.該機器的進程假死。須要重啓該機器上運行的進程。優化

案例6

大屏數據更新正常,處理任務正常,可是數據增量較慢。
解析:數據增加較慢,可是處理任務速度正常,應該懷疑是不是因爲丟數據引發
緣由及解決方案:
1.有數據未解析,直接跳過。須要排查未處理數據的類型。
2.鎖表。須要手動釋放鎖,修改代碼,全部的寫操做均用主鍵ID
以上爲這兩個多月時間中,見過的一些常見案例,此類問題均由該監控大屏拋出,並以解決。


線程

更多抖音,快手,小紅書數據實時採集接口,請查看文檔: TiToData架構設計

相關文章
相關標籤/搜索