據(jù)全站爬取：從單機腳本到分布式采集的工程實踐)
做直播數(shù)據(jù)采集這段時間最容易被一句話帶偏的就是“全站爬取”這個詞。很多人以為把某魚直播首頁上的直播間循環(huán)請求一遍就算全站了可真正開始跑才發(fā)現(xiàn)直播平臺的數(shù)據(jù)不是一個靜態(tài)頁面而是由狀態(tài)快照、實時彈幕、禮物榜單和主播信息組合起來的動態(tài)系統(tǒng)。標題里藏著兩個難點站點級覆蓋和近實時增量。這篇文章記錄了我在某魚直播數(shù)據(jù)全站爬取這個方向上從單機腳本一路調整到分布式采集的完整過程包括數(shù)據(jù)模型怎么拆、任務怎么調度、存儲怎么選以及最后為什么必須在合規(guī)邊界上踩剎車。想拿這套思路去搭直播數(shù)據(jù)倉庫的或者正在糾結“為什么自己的采集腳本跑兩天就廢了”的人應該能從里面找到答案。1. 拆解數(shù)據(jù)模型全站爬取到底要拿到哪幾類數(shù)據(jù)1.1 直播間狀態(tài)是爬蟲的“地面部隊”全站爬取的第一步不是去找彈幕接口而是把直播間的狀態(tài)數(shù)據(jù)鋪開。一個直播間在一段時間內是什么狀態(tài)屬于哪個分類標題變沒變這些數(shù)據(jù)構成了整個分析體系的地基。我習慣把狀態(tài)數(shù)據(jù)分成三層來收集。第一層是房間元信息包括房間 ID、主播稱號、房間標題、所屬分區(qū)。第二層是動態(tài)狀態(tài)也就是當前是否開播、開播時長、當前熱度、在線人數(shù)、封面圖版本。第三層是歷史狀態(tài)比如開播時間點、下播時間點、今日直播時長累計。這三層數(shù)據(jù)出現(xiàn)的頻率完全不一樣采集難度也完全不一樣不能放在同一個更新周期里處理。實際操作里房間元信息相對穩(wěn)定變化粒度是小時級甚至天級。動態(tài)狀態(tài)變化非?？鞜岫瓤赡軒酌腌娋吞鴦右淮伍_播下播更是在任何時間都可能發(fā)生。歷史狀態(tài)通常需要自己根據(jù)動態(tài)狀態(tài)的記錄去推導平臺很少直接給你一個“昨日直播時長”的字段更多時候你得把快照序列拉出來自己算。如果把全站爬取理解成維護一張巨大的“房間在線狀態(tài)表”那這張表的行數(shù)是全站房間數(shù)列數(shù)就是上面的那些狀態(tài)字段。真正考驗工程能力的是這張表的更新策略全量重建一次的成本有多高增量更新的延遲能不能壓到分鐘級。1.2 熱度與在線人數(shù)是一種特殊的時間序列熱度值和在線人數(shù)在語義上很容易混淆但在數(shù)據(jù)采集上必須分開處理。熱度通常是平臺自己定義的一個綜合指標由禮物、彈幕、觀看時長、互動頻次等因子加權計算出來在線人數(shù)則更接近真實的同時觀看人數(shù)。兩個字段的更新頻率不一樣量級也可能差很遠混在一個字段里會污染后續(xù)所有分析。我踩過的一個典型坑是把“熱度”當“在線人數(shù)”存又用同一個采集頻率去抓。結果熱度值在晚高峰的波動幅度大得離譜而在線人數(shù)反而平穩(wěn)最后畫出來的曲線像兩個完全不同的東西。解決辦法也很簡單在建表時把兩個字段拆開記錄各自的采集間隔并且在數(shù)據(jù)字典里注明來源字段名。時間序列數(shù)據(jù)還有另一個副作用就是數(shù)據(jù)量增長非?？?。假設全站有幾十萬個直播間每 30 秒采一次快照一天下來就是幾億行。這個量級如果用普通關系型數(shù)據(jù)庫硬扛寫入會成為瓶頸查詢也會越來越慢。所以熱度類的數(shù)據(jù)從一開始就應該考慮列式存儲或者壓縮策略更友好的方案后面第 4 節(jié)我會詳細說存儲選型。1.3 彈幕與禮物事件信息密度最高也最難處理彈幕和禮物都是事件類型的數(shù)據(jù)它們的共同特點是“只在發(fā)生的那一刻有價值”。禮物記錄還能通過貢獻榜、熱門禮物榜間接拿到歷史片段彈幕幾乎只能靠實時訂閱。全站爬取彈幕的難點不在于拿到一條彈幕而在于同時維持大量直播間的長連接并且保證斷線重連時不丟窗口。禮物數(shù)據(jù)的采集又有自己的問題。進入一個直播間時頁面上通常只會展示最近一段時間的貢獻榜超過窗口期的記錄就再也看不到了。這意味著禮物數(shù)據(jù)不能靠事后補采必須在榜單滾動更新期間頻繁輪詢把每次看到的榜單位保存下來再做增量對比才能還原出一個接近完整的禮物流。彈幕內容本身還有一個非常敏感的屬性它會攜帶用戶的發(fā)言內容和用戶名有可能是個人信息。所以我現(xiàn)在的做法是要么只統(tǒng)計彈幕條數(shù)和互動密度不落庫具體內容要么在落庫之前強制脫敏把用戶名、頭像、IP 這類能識別到個人的字段全部去掉。這個習慣一開始就要養(yǎng)成因為數(shù)據(jù)一旦進了倉庫再想起來處理就晚了。2. 采集路徑掃列表、輪狀態(tài)、聽事件三條路同時走2.1 全站爬取不是“一個抓取循環(huán)”能搞定的很多初學者寫爬蟲習慣用一個循環(huán)去做所有事情請求 URL、解析 HTML、存結果然后再請求下一個 URL。這套邏輯對靜態(tài)門戶站夠用但對直播平臺完全行不通。直播數(shù)據(jù)是分層變化的有的信息要掃描有的信息要輪詢有的信息要實時監(jiān)聽三種模式的作用域和請求頻次完全不同。掃描模式用于發(fā)現(xiàn)新直播間和更新房間元信息。典型入口是平臺主頁的分區(qū)列表進入每個分區(qū)后繼續(xù)翻頁拿到主播房間列表。這個模式的請求頻率可以很低比如每 5 到 10 分鐘跑一遍因為新開播不會頻繁得離譜。輪詢模式用于熱度、在線人數(shù)、榜單類數(shù)據(jù)頻率要分業(yè)務場景定。監(jiān)聽模式用于彈幕和禮物事件走的是長連接或者消息通道不能像 HTTP 請求一樣隨意控制頻率。如果非要用一句話總結全站爬取 低頻掃描房間列表 中頻輪詢狀態(tài)快照 高頻監(jiān)聽事件通道三個子系統(tǒng)之間通過“房間 ID”這個主鍵串聯(lián)起來。誰要是把三種數(shù)據(jù)都放進同一個循環(huán)里最后不是漏數(shù)據(jù)就是把接口打爆。2.2 一個可落地的混合采集偽代碼下面這個偽代碼并不代表某個平臺的具體接口而是說明三種模式在工程上應該怎么組合。我習慣用異步客戶端統(tǒng)一處理 HTTP 部分再用一個簡單的任務函數(shù)把不同采集頻率封裝起來。import asyncio import httpx import time async def scan_room_list(client, category_id): # 掃描模式低頻用于發(fā)現(xiàn)房間 rooms [] for page in range(1, 10): resp await client.get( fhttps://api.example.com/{category_id}/rooms?page{page} ) rooms.extend(resp.json().get(rooms, [])) await asyncio.sleep(0.5) return rooms async def poll_room_status(client, room_id): # 輪詢模式中頻用于更新快照 resp await client.get( fhttps://api.example.com/room/{room_id}/status ) return resp.json() async def listen_danmaku(room_id, callback): # 監(jiān)聽模式高頻用事件通道而不是 HTTP # 這里省略具體連接邏輯核心是收到消息后立刻回調 pass async def main(): async with httpx.AsyncClient(timeout10) as client: categories [game, talk, music] all_rooms [] for cate in categories: all_rooms await scan_room_list(client, cate) for room in all_rooms: status await poll_room_status(client, room[room_id]) save_snapshot(status) await asyncio.sleep(1)這段代碼里我刻意把三個模式的函數(shù)分開不是為了好看而是為了讓后續(xù)擴展更順。掃描模式發(fā)現(xiàn)新房間輪詢模式更新已有房間監(jiān)聽模式處理實時事件三者之間通過數(shù)據(jù)庫或者消息隊列解耦而不是在函數(shù)內部互相調用。這樣后期如果某段邏輯掛了不會影響另外兩端。2.3 開播檢測到底什么時候去抓一個新房間全站爬取的時效性很大程度取決于“開播檢測”做得好不好。新直播間出現(xiàn)時如果沒有被及時加入采集隊列后續(xù)所有相關數(shù)據(jù)都會延遲。反過來如果掃描太頻繁又會對服務端造成無效壓力。我的做法是把開播檢測拆成兩級。第一級是全量低峰掃描比如凌晨 3 點到 6 點之間把所有分區(qū)完整跑一遍重建一次房間名單。第二級是增量高峰掃描白天用較短間隔輪詢熱度高的分區(qū)因為新開播的主播往往會集中在活躍分區(qū)。兩級掃描的結果合并后才進入正式的輪詢和監(jiān)聽隊列。這里有一個容易忽略的點房間 ID 不會復用但主播可以重新開播。所以判斷“要不要采集”時不能只看房間 ID 是否已經(jīng)存在還要看最近的直播記錄是否已經(jīng)結束。如果上次記錄顯示該房間下播超過 10 分鐘再出現(xiàn)狀態(tài)更新就要當作一次新的直播會話來處理在數(shù)據(jù)上打一個新的會話 ID。3. 任務調度與增量更新從單機隊列到可控的分布式3.1 直接開幾十個線程亂跑是最容易翻車的做法很多人為了追全站速度第一反應是“開線程池每個線程各抓各的”。我也干過這事兒結果是沒過多久就收到了一連串的風控提示而且數(shù)據(jù)出現(xiàn)了大量重復。問題不在并發(fā)本身而在于這些線程沒有共享狀態(tài)根本不知道哪些房間已經(jīng)抓過、哪些接口正在被同一個 IP 高頻調用。對機器來說一次請求發(fā)出去遠比重試一次請求便宜。真正合理的調度不是讓所有任務并發(fā)執(zhí)行而是把所有任務放進一個隊列由調度器統(tǒng)一控制出隊速率。單機場景可以用線程安全的隊列加一個簡單的限速器分布式場景則要把隊列抽出來放到獨立的消息中間件里讓多個 worker 從同一個源取任務。我最初在單機上用的方案其實很樸素把房間 ID 排成一個列表用一張狀態(tài)表記錄每個房間最近一次成功采集的時間然后每隔固定秒數(shù)檢查一次看看現(xiàn)在該抓哪些房間。這樣每個房間的輪詢周期相對穩(wěn)定不會出現(xiàn)“某個房間 1 秒抓了 10 次另一個房間一整天沒被抓過”的尷尬情況。3.2 調度隊列里不止有房間 ID還有“溫度”隊列里的任務如果只有一個房間 ID那么熱點房間和冷門房間會被同等對待這是很大的浪費。熱度高的直播間需要高頻輪詢冷門直播間可能一天只需要確認幾次狀態(tài)就可以了。所以我給每個任務加了一個“溫度”概念用最近幾次快照的熱度值來決定下一次采集間隔。舉個例子一個熱度過萬的房間我可能每 20 秒輪詢一次熱度在一千到一萬之間的房間每 60 秒輪詢一次熱度低于一千的冷門房間每 5 分鐘輪詢一次。這樣看起來像是一個動態(tài)優(yōu)先級隊列高熱度任務優(yōu)先低熱度任務降頻。實現(xiàn)上并不復雜快照入庫時帶著熱度值調度器從數(shù)據(jù)庫里讀一下最近一次熱度就能算出下一次執(zhí)行時間。這種“溫度調度”還有一個額外的好處當某個直播間因為熱門事件突然涌入大量觀眾時它的熱度上升采集頻率也會自動跟著上升保證不遺漏關鍵時段的數(shù)據(jù)。等熱度回落頻率再降下來資源就自動釋放給其他房間。3.3 調度器需要檢查點不怕中途掛掉就怕從頭再來任何長期運行的采集任務都一定會遇到進程重啟、服務器斷電、網(wǎng)絡長時間中斷的情況。如果調度器沒有檢查點機制重啟后要從頭掃一遍全站房間列表效率會非常低而且會給對方服務器造成無謂的重復壓力。檢查點的核心是把“已經(jīng)完成的任務狀態(tài)”持久化下來。我在單機版本里用了一張很小的表字段就三個任務類型、任務 ID、最近完成時間。每次完成一個房間的狀態(tài)更新就更新這條記錄。重啟之后調度器先讀這張表凡是“最近完成時間”在合理范圍內的房間都不用重新掃描直接從之前停留的位置繼續(xù)。這個方法聽著簡單但真的能省掉大量無效請求。全站房間數(shù)量在幾十萬這個量級時一次全量重建可能需要好幾個小時而有了檢查點中途哪怕掛掉十次每次重啟都只要幾分鐘就能回到正確的工作狀態(tài)長期跑下來的效率差距非常明顯。4. 數(shù)據(jù)落地明細層與聚合層分倉庫4.1 明細層保存“發(fā)生了什么”方便回溯直播數(shù)據(jù)采集完成后第一個存放地應該是明細層也就是原始事件庫。這里的表結構不能按業(yè)務報表來設計而應該按“數(shù)據(jù)發(fā)生的語義”來設計。我常用的三張明細表是直播間狀態(tài)快照表、禮物榜單變化表、彈幕互動統(tǒng)計表。狀態(tài)快照表的每一行代表“某個房間在某時刻的狀態(tài)”字段包括房間 ID、采集時間、開播狀態(tài)、分類、熱度、在線人數(shù)。禮物榜單變化表稍微特殊一些因為榜單是變動的我采用“每輪輪詢保存整個榜單排名”再加一個“榜單版本號”這樣能還原出禮物沖榜過程。彈幕互動統(tǒng)計表的粒度可以壓到“房間 x 每分鐘彈幕條數(shù)”這種粒度既能支撐互動趨勢分析又不會把原始文本全部落下來。明細層不要怕數(shù)據(jù)量大反而應該怕數(shù)據(jù)被提前聚合。一旦你把原始快照聚合成小時級平均值后面再做精細化分析就沒有素材了。所以我始終堅持明細表只做輕加工字段命名統(tǒng)一、時間字段固定為 UTC、把平臺返回的原始字段保存在一個備用列里其余盡量保持原樣。4.2 明細層建表的幾個硬要求通過實踐我總結了明細層建表時最需要注意的四個點缺一不可。第一必須有明確的唯一鍵。狀態(tài)快照表用room_id event_time唯一標識一行禮物榜單表用room_id round_id rank這樣即使采集任務重復寫入數(shù)據(jù)庫時也可以靠唯一鍵去重。第二時間字段必須帶時區(qū)信息我統(tǒng)一存 UTC展示層再轉本地時間。第三盡量使用分區(qū)表按天或者按小時分區(qū)刪除過期數(shù)據(jù)時直接刪分區(qū)不用跑 DELETE 語句。第四原始響應要留一份至少是 JSON 字段這樣解析出問題時還能回頭修數(shù)據(jù)。下面是一個簡化但能直接用的快照表結構CREATE TABLE room_snapshot ( room_id BIGINT NOT NULL, event_time DATETIME NOT NULL, is_living TINYINT NOT NULL DEFAULT 0, category VARCHAR(64) NOT NULL DEFAULT , hot_value BIGINT NOT NULL DEFAULT 0, online_count INT NOT NULL DEFAULT 0, title_hash CHAR(32) NOT NULL DEFAULT , raw_data JSON DEFAULT NULL, PRIMARY KEY (room_id, event_time) ) ENGINEInnoDB PARTITION BY RANGE (TO_DAYS(event_time)) (...);注意我為什么放了一個title_hash而不是直接放 title。標題會反復變化直接把長標題放進來既占空間又不好做比較所以我只存一個哈希值用來判斷標題是否發(fā)生變化。真要分析標題內容時再單獨拉一份標題變更日志不會污染主表。4.3 聚合層解決“查詢太慢”的問題明細表存了原始數(shù)據(jù)之后查詢端的噩夢就開始了。一個簡單的問題比如“昨晚熱度超過十萬的房間有多少個”如果直接掃全表可能要把上億行翻一遍。所以必須有一層提前計算好的聚合表按業(yè)務常見維度做匯總。我常用的聚合粒度是“房間 x 分鐘”和“房間 x 小時”。分鐘級聚合表可以從快照表算出每分鐘的平均熱度、最大在線人數(shù)、彈幕條數(shù)小時級聚合表再對分鐘級做一次減采樣得到更長時間的曲線。聚合任務用定時腳本在后臺跑每天凌晨把前一天的數(shù)據(jù)全部補齊。這里最關鍵的一點是聚合表不是替代明細表而是明細表的索引。查詢端先打聚合表發(fā)現(xiàn)粒度不夠再用明細表查原始事件。只要這層配合起來即使數(shù)據(jù)量到了十億行級別常見的 Top N、趨勢圖、會話時長這類分析也能在秒級返回。5. 實際踩坑任務積壓、重復消費和狀態(tài)漂移5.1 高峰期請求積壓隊列反榨了數(shù)據(jù)庫第一次跑全站采集時我以為只要隊列夠長就沒事結果某個晚上熱門事件突然爆發(fā)直播間數(shù)量短時間翻了一倍所有 worker 都在拼命消費寫入速度反而跟不上最后數(shù)據(jù)庫連接被耗盡整個任務站點直接卡死。問題的根子不在 worker 速度而在寫入能力有限。后來我加了兩個機制一是寫入端改成批量寫攢夠 100 條或者攢夠 1 秒再統(tǒng)一落庫吞吐量提高了一大截二是隊列增加反向壓力控制當寫入端積壓超過閾值時調度器會自動降低掃描頻率寧可少采一些臨時數(shù)據(jù)也不能把核心鏈路拖垮。流量高峰時最忌諱的是“全渠道火力全開”?，F(xiàn)在我的做法是預設幾檔流量模式默認模式、高峰模式、降級模式。高峰模式下只保留熱度靠前的房間高頻采集冷門房間直接降頻等高峰期結束再補采。這樣不會錯過最有價值的頭部數(shù)據(jù)也不會讓整個系統(tǒng)沖垮。5.2 冪等寫入重復數(shù)據(jù)是怎么悄無聲息出現(xiàn)的全站爬取一定會遇到數(shù)據(jù)重復。原因很多輪詢和監(jiān)聽兩條鏈路可能同時采到同一個事件網(wǎng)絡超時導致客戶端重試但前一次請求實際已經(jīng)成功了消息隊列在消費端重啟后重新投遞了未確認的消息。任何一條鏈路出問題都會往庫里塞重復數(shù)據(jù)。如果表結構從一開始就設計了唯一鍵重復寫入會被數(shù)據(jù)庫擋住但這還不夠因為在應用層你可能要做多輪聚合重復數(shù)據(jù)還是會影響統(tǒng)計。真正的辦法是從源頭打冪等標簽每個事件生成一個唯一的業(yè)務 ID比如彈幕用平臺返回的消息序號狀態(tài)快照用room_id 采集時間戳禮物榜單用room_id 榜單版本號。一旦建立冪等鍵整個數(shù)據(jù)處理管道就有了約束。后續(xù)無論哪一環(huán)重復處理只要最終寫入時校驗唯一鍵就不會把數(shù)據(jù)翻倍。這個設計雖然不起眼但省掉了我很多查重復的深夜時間。5.3 狀態(tài)漂移你以為下播了其實只是網(wǎng)絡抖動直播狀態(tài)字段是最容易誤導人的。某個房間因為網(wǎng)絡波動熱度突然暴跌到接近零如果采集端把這個快照當作“已下播”入庫后面的直播時長統(tǒng)計就全錯了。這種問題叫狀態(tài)漂移典型的解決辦法是引入“確認窗口”。我的經(jīng)驗是一個房間要連續(xù) N 次快照都顯示下播狀態(tài)才真正標記為下播。N 的大小取決于采集間隔通常 TTL 5 到 10 分鐘。同理開播狀態(tài)也需要連續(xù)確認避免把瞬間的接口異常當成開播。處理狀態(tài)漂移的關鍵是在入庫前過濾而不是入庫后再修正。入庫前過濾的好處是下游拿到的數(shù)據(jù)是干凈狀態(tài)不用每個人自己再去判斷。如果真要支持更精細的分析我建議在快照表上加一個session_id字段把連續(xù)的直播時段歸到同一個會話里后續(xù)計算時長、場次的時候直接按會話分組就行。6. 邊界和底線爬之前必須想清楚的幾件事6.1 數(shù)據(jù)源授權是全站爬取的最大約束寫完上面這些工程細節(jié)我必須把話拉回到一個經(jīng)常被刻意回避的問題全站爬取的數(shù)據(jù)源授權邊界在哪。這個問題不是一句“抓公開信息沒問題”就能帶過去的。公開頁面上能看到的數(shù)據(jù)不等于你有權把這些數(shù)據(jù)全量搬運、存儲、轉賣。我在任何采集項目啟動前都要先做兩件事。第一看平臺服務條款和 robots 協(xié)議明確哪些路徑明令禁止自動化訪問。如果平臺條款明確不允許批量采集那生產(chǎn)環(huán)境跑這種采集就存在違約風險能不做就不做。第二看數(shù)據(jù)屬性。涉及個人信息的字段比如昵稱、頭像、個人簽名能改成哈希值就改成哈希值能刪掉就別留。很多團隊在初期只顧著追求數(shù)據(jù)量等用到數(shù)據(jù)時才發(fā)現(xiàn)字段里全是不可碰的內容那時候再洗數(shù)據(jù)成本和風險都是災難級的。我在自己的項目里采用“最小化采集”原則只要業(yè)務不需要彈幕原文就不采彈幕原文只要業(yè)務不需要禮物背后的用戶昵稱就不采用戶昵稱。少一個敏感字段就少一個默認風險。6.2 脫敏存儲和留存周期要形成制度光說不存沒用采集系統(tǒng)要把脫敏規(guī)則和留存周期做成代碼的一部分。我在明細表的寫入鏈路里加了一道脫敏層所有從網(wǎng)絡響應的字段都必須通過字段白名單校驗不在白名單里的字段直接丟棄白名單里包含的敏感字段再經(jīng)過hash處理才允許入庫。留存周期問題同樣重要。直播熱度數(shù)據(jù)和分析結果通常并不需要永久保留。我一般給原始快照設 30 天的保留期超過 30 天的直接清分區(qū)聚合表保留 180 天只有長期分析的統(tǒng)計結果才長期保存。這樣既能控制存儲成本也減少了因為數(shù)據(jù)長期滯留而帶來的合規(guī)風險。6.3 灰度上線先小范圍驗證再全站鋪開最后一個建議聽起來很“不極客”但在全站爬取里反而最保命先灰度。不要第一天就上全量任務而是先挑幾個分區(qū)、幾個典型房間跑一跑觀察請求成功率、數(shù)據(jù)完整度、延遲和風控表現(xiàn)?；叶绕谕ǔＮ抑辽俦Ａ羧煲驗橹辈テ脚_的數(shù)據(jù)有很強的周內周期性周一跑出來的情況周六晚上大概率會不一樣?；叶韧ㄟ^之后再逐步擴大范圍。擴大過程中要持續(xù)觀察兩個指標一個是任務積壓量另一個是風控觸發(fā)的頻率。一旦風控觸發(fā)頻率明顯上升就要立刻回退采集頻次而不是硬沖。全站爬取的長期運營拼的不是某一天抓了多少數(shù)據(jù)而是能不能穩(wěn)定地每天把數(shù)據(jù)完整地補回來?；仡^看我自己的實踐這個項目最后能穩(wěn)定跑下去靠的不是某一個聰明的算法而是把掃描、輪詢、監(jiān)聽三套模式拆開用一致的調度框架管住頻率用冪等鍵和狀態(tài)確認擋住重復和漂移再在存儲層把明細和聚合分開。如果你也要做類似的事情我建議你先從一個小范圍開始把調度節(jié)奏調順了再談全站。多花點時間在設計數(shù)據(jù)邊界上后續(xù)踩坑的機會就會小很多。 直播數(shù)據(jù)全站爬?。簭膯螜C腳本到分布式采集的工程實踐
做直播數(shù)據(jù)采集這段時間最容易被一句話帶偏的就是“全站爬取”這個詞。很多人以為把某魚直播首頁上的直播間循環(huán)請求一遍就算全站了可真正開始跑才發(fā)現(xiàn)直播平臺的數(shù)據(jù)不是一個靜態(tài)頁面而是由狀態(tài)快照、實時彈幕、禮物榜單和主播信息組合起來的動態(tài)系統(tǒng)。標題里藏著兩個難點站點級覆蓋和近實時增量。這篇文章記錄了我在某魚直播數(shù)據(jù)全站爬取這個方向上從單機腳本一路調整到分布式采集的完整過程包括數(shù)據(jù)模型怎么拆、任務怎么調度、存儲怎么選以及最后為什么必須在合規(guī)邊界上踩剎車。想拿這套思路去搭直播數(shù)據(jù)倉庫的或者正在糾結“為什么自己的采集腳本跑兩天就廢了”的人應該能從里面找到答案。1. 拆解數(shù)據(jù)模型全站爬取到底要拿到哪幾類數(shù)據(jù)1.1 直播間狀態(tài)是爬蟲的“地面部隊”全站爬取的第一步不是去找彈幕接口而是把直播間的狀態(tài)數(shù)據(jù)鋪開。一個直播間在一段時間內是什么狀態(tài)屬于哪個分類標題變沒變這些數(shù)據(jù)構成了整個分析體系的地基。我習慣把狀態(tài)數(shù)據(jù)分成三層來收集。第一層是房間元信息包括房間 ID、主播稱號、房間標題、所屬分區(qū)。第二層是動態(tài)狀態(tài)也就是當前是否開播、開播時長、當前熱度、在線人數(shù)、封面圖版本。第三層是歷史狀態(tài)比如開播時間點、下播時間點、今日直播時長累計。這三層數(shù)據(jù)出現(xiàn)的頻率完全不一樣采集難度也完全不一樣不能放在同一個更新周期里處理。實際操作里房間元信息相對穩(wěn)定變化粒度是小時級甚至天級。動態(tài)狀態(tài)變化非?？鞜岫瓤赡軒酌腌娋吞鴦右淮伍_播下播更是在任何時間都可能發(fā)生。歷史狀態(tài)通常需要自己根據(jù)動態(tài)狀態(tài)的記錄去推導平臺很少直接給你一個“昨日直播時長”的字段更多時候你得把快照序列拉出來自己算。如果把全站爬取理解成維護一張巨大的“房間在線狀態(tài)表”那這張表的行數(shù)是全站房間數(shù)列數(shù)就是上面的那些狀態(tài)字段。真正考驗工程能力的是這張表的更新策略全量重建一次的成本有多高增量更新的延遲能不能壓到分鐘級。1.2 熱度與在線人數(shù)是一種特殊的時間序列熱度值和在線人數(shù)在語義上很容易混淆但在數(shù)據(jù)采集上必須分開處理。熱度通常是平臺自己定義的一個綜合指標由禮物、彈幕、觀看時長、互動頻次等因子加權計算出來在線人數(shù)則更接近真實的同時觀看人數(shù)。兩個字段的更新頻率不一樣量級也可能差很遠混在一個字段里會污染后續(xù)所有分析。我踩過的一個典型坑是把“熱度”當“在線人數(shù)”存又用同一個采集頻率去抓。結果熱度值在晚高峰的波動幅度大得離譜而在線人數(shù)反而平穩(wěn)最后畫出來的曲線像兩個完全不同的東西。解決辦法也很簡單在建表時把兩個字段拆開記錄各自的采集間隔并且在數(shù)據(jù)字典里注明來源字段名。時間序列數(shù)據(jù)還有另一個副作用就是數(shù)據(jù)量增長非?？?。假設全站有幾十萬個直播間每 30 秒采一次快照一天下來就是幾億行。這個量級如果用普通關系型數(shù)據(jù)庫硬扛寫入會成為瓶頸查詢也會越來越慢。所以熱度類的數(shù)據(jù)從一開始就應該考慮列式存儲或者壓縮策略更友好的方案后面第 4 節(jié)我會詳細說存儲選型。1.3 彈幕與禮物事件信息密度最高也最難處理彈幕和禮物都是事件類型的數(shù)據(jù)它們的共同特點是“只在發(fā)生的那一刻有價值”。禮物記錄還能通過貢獻榜、熱門禮物榜間接拿到歷史片段彈幕幾乎只能靠實時訂閱。全站爬取彈幕的難點不在于拿到一條彈幕而在于同時維持大量直播間的長連接并且保證斷線重連時不丟窗口。禮物數(shù)據(jù)的采集又有自己的問題。進入一個直播間時頁面上通常只會展示最近一段時間的貢獻榜超過窗口期的記錄就再也看不到了。這意味著禮物數(shù)據(jù)不能靠事后補采必須在榜單滾動更新期間頻繁輪詢把每次看到的榜單位保存下來再做增量對比才能還原出一個接近完整的禮物流。彈幕內容本身還有一個非常敏感的屬性它會攜帶用戶的發(fā)言內容和用戶名有可能是個人信息。所以我現(xiàn)在的做法是要么只統(tǒng)計彈幕條數(shù)和互動密度不落庫具體內容要么在落庫之前強制脫敏把用戶名、頭像、IP 這類能識別到個人的字段全部去掉。這個習慣一開始就要養(yǎng)成因為數(shù)據(jù)一旦進了倉庫再想起來處理就晚了。2. 采集路徑掃列表、輪狀態(tài)、聽事件三條路同時走2.1 全站爬取不是“一個抓取循環(huán)”能搞定的很多初學者寫爬蟲習慣用一個循環(huán)去做所有事情請求 URL、解析 HTML、存結果然后再請求下一個 URL。這套邏輯對靜態(tài)門戶站夠用但對直播平臺完全行不通。直播數(shù)據(jù)是分層變化的有的信息要掃描有的信息要輪詢有的信息要實時監(jiān)聽三種模式的作用域和請求頻次完全不同。掃描模式用于發(fā)現(xiàn)新直播間和更新房間元信息。典型入口是平臺主頁的分區(qū)列表進入每個分區(qū)后繼續(xù)翻頁拿到主播房間列表。這個模式的請求頻率可以很低比如每 5 到 10 分鐘跑一遍因為新開播不會頻繁得離譜。輪詢模式用于熱度、在線人數(shù)、榜單類數(shù)據(jù)頻率要分業(yè)務場景定。監(jiān)聽模式用于彈幕和禮物事件走的是長連接或者消息通道不能像 HTTP 請求一樣隨意控制頻率。如果非要用一句話總結全站爬取 低頻掃描房間列表 中頻輪詢狀態(tài)快照 高頻監(jiān)聽事件通道三個子系統(tǒng)之間通過“房間 ID”這個主鍵串聯(lián)起來。誰要是把三種數(shù)據(jù)都放進同一個循環(huán)里最后不是漏數(shù)據(jù)就是把接口打爆。2.2 一個可落地的混合采集偽代碼下面這個偽代碼并不代表某個平臺的具體接口而是說明三種模式在工程上應該怎么組合。我習慣用異步客戶端統(tǒng)一處理 HTTP 部分再用一個簡單的任務函數(shù)把不同采集頻率封裝起來。import asyncio import httpx import time async def scan_room_list(client, category_id): # 掃描模式低頻用于發(fā)現(xiàn)房間 rooms [] for page in range(1, 10): resp await client.get( fhttps://api.example.com/{category_id}/rooms?page{page} ) rooms.extend(resp.json().get(rooms, [])) await asyncio.sleep(0.5) return rooms async def poll_room_status(client, room_id): # 輪詢模式中頻用于更新快照 resp await client.get( fhttps://api.example.com/room/{room_id}/status ) return resp.json() async def listen_danmaku(room_id, callback): # 監(jiān)聽模式高頻用事件通道而不是 HTTP # 這里省略具體連接邏輯核心是收到消息后立刻回調 pass async def main(): async with httpx.AsyncClient(timeout10) as client: categories [game, talk, music] all_rooms [] for cate in categories: all_rooms await scan_room_list(client, cate) for room in all_rooms: status await poll_room_status(client, room[room_id]) save_snapshot(status) await asyncio.sleep(1)這段代碼里我刻意把三個模式的函數(shù)分開不是為了好看而是為了讓后續(xù)擴展更順。掃描模式發(fā)現(xiàn)新房間輪詢模式更新已有房間監(jiān)聽模式處理實時事件三者之間通過數(shù)據(jù)庫或者消息隊列解耦而不是在函數(shù)內部互相調用。這樣后期如果某段邏輯掛了不會影響另外兩端。2.3 開播檢測到底什么時候去抓一個新房間全站爬取的時效性很大程度取決于“開播檢測”做得好不好。新直播間出現(xiàn)時如果沒有被及時加入采集隊列后續(xù)所有相關數(shù)據(jù)都會延遲。反過來如果掃描太頻繁又會對服務端造成無效壓力。我的做法是把開播檢測拆成兩級。第一級是全量低峰掃描比如凌晨 3 點到 6 點之間把所有分區(qū)完整跑一遍重建一次房間名單。第二級是增量高峰掃描白天用較短間隔輪詢熱度高的分區(qū)因為新開播的主播往往會集中在活躍分區(qū)。兩級掃描的結果合并后才進入正式的輪詢和監(jiān)聽隊列。這里有一個容易忽略的點房間 ID 不會復用但主播可以重新開播。所以判斷“要不要采集”時不能只看房間 ID 是否已經(jīng)存在還要看最近的直播記錄是否已經(jīng)結束。如果上次記錄顯示該房間下播超過 10 分鐘再出現(xiàn)狀態(tài)更新就要當作一次新的直播會話來處理在數(shù)據(jù)上打一個新的會話 ID。3. 任務調度與增量更新從單機隊列到可控的分布式3.1 直接開幾十個線程亂跑是最容易翻車的做法很多人為了追全站速度第一反應是“開線程池每個線程各抓各的”。我也干過這事兒結果是沒過多久就收到了一連串的風控提示而且數(shù)據(jù)出現(xiàn)了大量重復。問題不在并發(fā)本身而在于這些線程沒有共享狀態(tài)根本不知道哪些房間已經(jīng)抓過、哪些接口正在被同一個 IP 高頻調用。對機器來說一次請求發(fā)出去遠比重試一次請求便宜。真正合理的調度不是讓所有任務并發(fā)執(zhí)行而是把所有任務放進一個隊列由調度器統(tǒng)一控制出隊速率。單機場景可以用線程安全的隊列加一個簡單的限速器分布式場景則要把隊列抽出來放到獨立的消息中間件里讓多個 worker 從同一個源取任務。我最初在單機上用的方案其實很樸素把房間 ID 排成一個列表用一張狀態(tài)表記錄每個房間最近一次成功采集的時間然后每隔固定秒數(shù)檢查一次看看現(xiàn)在該抓哪些房間。這樣每個房間的輪詢周期相對穩(wěn)定不會出現(xiàn)“某個房間 1 秒抓了 10 次另一個房間一整天沒被抓過”的尷尬情況。3.2 調度隊列里不止有房間 ID還有“溫度”隊列里的任務如果只有一個房間 ID那么熱點房間和冷門房間會被同等對待這是很大的浪費。熱度高的直播間需要高頻輪詢冷門直播間可能一天只需要確認幾次狀態(tài)就可以了。所以我給每個任務加了一個“溫度”概念用最近幾次快照的熱度值來決定下一次采集間隔。舉個例子一個熱度過萬的房間我可能每 20 秒輪詢一次熱度在一千到一萬之間的房間每 60 秒輪詢一次熱度低于一千的冷門房間每 5 分鐘輪詢一次。這樣看起來像是一個動態(tài)優(yōu)先級隊列高熱度任務優(yōu)先低熱度任務降頻。實現(xiàn)上并不復雜快照入庫時帶著熱度值調度器從數(shù)據(jù)庫里讀一下最近一次熱度就能算出下一次執(zhí)行時間。這種“溫度調度”還有一個額外的好處當某個直播間因為熱門事件突然涌入大量觀眾時它的熱度上升采集頻率也會自動跟著上升保證不遺漏關鍵時段的數(shù)據(jù)。等熱度回落頻率再降下來資源就自動釋放給其他房間。3.3 調度器需要檢查點不怕中途掛掉就怕從頭再來任何長期運行的采集任務都一定會遇到進程重啟、服務器斷電、網(wǎng)絡長時間中斷的情況。如果調度器沒有檢查點機制重啟后要從頭掃一遍全站房間列表效率會非常低而且會給對方服務器造成無謂的重復壓力。檢查點的核心是把“已經(jīng)完成的任務狀態(tài)”持久化下來。我在單機版本里用了一張很小的表字段就三個任務類型、任務 ID、最近完成時間。每次完成一個房間的狀態(tài)更新就更新這條記錄。重啟之后調度器先讀這張表凡是“最近完成時間”在合理范圍內的房間都不用重新掃描直接從之前停留的位置繼續(xù)。這個方法聽著簡單但真的能省掉大量無效請求。全站房間數(shù)量在幾十萬這個量級時一次全量重建可能需要好幾個小時而有了檢查點中途哪怕掛掉十次每次重啟都只要幾分鐘就能回到正確的工作狀態(tài)長期跑下來的效率差距非常明顯。4. 數(shù)據(jù)落地明細層與聚合層分倉庫4.1 明細層保存“發(fā)生了什么”方便回溯直播數(shù)據(jù)采集完成后第一個存放地應該是明細層也就是原始事件庫。這里的表結構不能按業(yè)務報表來設計而應該按“數(shù)據(jù)發(fā)生的語義”來設計。我常用的三張明細表是直播間狀態(tài)快照表、禮物榜單變化表、彈幕互動統(tǒng)計表。狀態(tài)快照表的每一行代表“某個房間在某時刻的狀態(tài)”字段包括房間 ID、采集時間、開播狀態(tài)、分類、熱度、在線人數(shù)。禮物榜單變化表稍微特殊一些因為榜單是變動的我采用“每輪輪詢保存整個榜單排名”再加一個“榜單版本號”這樣能還原出禮物沖榜過程。彈幕互動統(tǒng)計表的粒度可以壓到“房間 x 每分鐘彈幕條數(shù)”這種粒度既能支撐互動趨勢分析又不會把原始文本全部落下來。明細層不要怕數(shù)據(jù)量大反而應該怕數(shù)據(jù)被提前聚合。一旦你把原始快照聚合成小時級平均值后面再做精細化分析就沒有素材了。所以我始終堅持明細表只做輕加工字段命名統(tǒng)一、時間字段固定為 UTC、把平臺返回的原始字段保存在一個備用列里其余盡量保持原樣。4.2 明細層建表的幾個硬要求通過實踐我總結了明細層建表時最需要注意的四個點缺一不可。第一必須有明確的唯一鍵。狀態(tài)快照表用room_id event_time唯一標識一行禮物榜單表用room_id round_id rank這樣即使采集任務重復寫入數(shù)據(jù)庫時也可以靠唯一鍵去重。第二時間字段必須帶時區(qū)信息我統(tǒng)一存 UTC展示層再轉本地時間。第三盡量使用分區(qū)表按天或者按小時分區(qū)刪除過期數(shù)據(jù)時直接刪分區(qū)不用跑 DELETE 語句。第四原始響應要留一份至少是 JSON 字段這樣解析出問題時還能回頭修數(shù)據(jù)。下面是一個簡化但能直接用的快照表結構CREATE TABLE room_snapshot ( room_id BIGINT NOT NULL, event_time DATETIME NOT NULL, is_living TINYINT NOT NULL DEFAULT 0, category VARCHAR(64) NOT NULL DEFAULT , hot_value BIGINT NOT NULL DEFAULT 0, online_count INT NOT NULL DEFAULT 0, title_hash CHAR(32) NOT NULL DEFAULT , raw_data JSON DEFAULT NULL, PRIMARY KEY (room_id, event_time) ) ENGINEInnoDB PARTITION BY RANGE (TO_DAYS(event_time)) (...);注意我為什么放了一個title_hash而不是直接放 title。標題會反復變化直接把長標題放進來既占空間又不好做比較所以我只存一個哈希值用來判斷標題是否發(fā)生變化。真要分析標題內容時再單獨拉一份標題變更日志不會污染主表。4.3 聚合層解決“查詢太慢”的問題明細表存了原始數(shù)據(jù)之后查詢端的噩夢就開始了。一個簡單的問題比如“昨晚熱度超過十萬的房間有多少個”如果直接掃全表可能要把上億行翻一遍。所以必須有一層提前計算好的聚合表按業(yè)務常見維度做匯總。我常用的聚合粒度是“房間 x 分鐘”和“房間 x 小時”。分鐘級聚合表可以從快照表算出每分鐘的平均熱度、最大在線人數(shù)、彈幕條數(shù)小時級聚合表再對分鐘級做一次減采樣得到更長時間的曲線。聚合任務用定時腳本在后臺跑每天凌晨把前一天的數(shù)據(jù)全部補齊。這里最關鍵的一點是聚合表不是替代明細表而是明細表的索引。查詢端先打聚合表發(fā)現(xiàn)粒度不夠再用明細表查原始事件。只要這層配合起來即使數(shù)據(jù)量到了十億行級別常見的 Top N、趨勢圖、會話時長這類分析也能在秒級返回。5. 實際踩坑任務積壓、重復消費和狀態(tài)漂移5.1 高峰期請求積壓隊列反榨了數(shù)據(jù)庫第一次跑全站采集時我以為只要隊列夠長就沒事結果某個晚上熱門事件突然爆發(fā)直播間數(shù)量短時間翻了一倍所有 worker 都在拼命消費寫入速度反而跟不上最后數(shù)據(jù)庫連接被耗盡整個任務站點直接卡死。問題的根子不在 worker 速度而在寫入能力有限。后來我加了兩個機制一是寫入端改成批量寫攢夠 100 條或者攢夠 1 秒再統(tǒng)一落庫吞吐量提高了一大截二是隊列增加反向壓力控制當寫入端積壓超過閾值時調度器會自動降低掃描頻率寧可少采一些臨時數(shù)據(jù)也不能把核心鏈路拖垮。流量高峰時最忌諱的是“全渠道火力全開”?，F(xiàn)在我的做法是預設幾檔流量模式默認模式、高峰模式、降級模式。高峰模式下只保留熱度靠前的房間高頻采集冷門房間直接降頻等高峰期結束再補采。這樣不會錯過最有價值的頭部數(shù)據(jù)也不會讓整個系統(tǒng)沖垮。5.2 冪等寫入重復數(shù)據(jù)是怎么悄無聲息出現(xiàn)的全站爬取一定會遇到數(shù)據(jù)重復。原因很多輪詢和監(jiān)聽兩條鏈路可能同時采到同一個事件網(wǎng)絡超時導致客戶端重試但前一次請求實際已經(jīng)成功了消息隊列在消費端重啟后重新投遞了未確認的消息。任何一條鏈路出問題都會往庫里塞重復數(shù)據(jù)。如果表結構從一開始就設計了唯一鍵重復寫入會被數(shù)據(jù)庫擋住但這還不夠因為在應用層你可能要做多輪聚合重復數(shù)據(jù)還是會影響統(tǒng)計。真正的辦法是從源頭打冪等標簽每個事件生成一個唯一的業(yè)務 ID比如彈幕用平臺返回的消息序號狀態(tài)快照用room_id 采集時間戳禮物榜單用room_id 榜單版本號。一旦建立冪等鍵整個數(shù)據(jù)處理管道就有了約束。后續(xù)無論哪一環(huán)重復處理只要最終寫入時校驗唯一鍵就不會把數(shù)據(jù)翻倍。這個設計雖然不起眼但省掉了我很多查重復的深夜時間。5.3 狀態(tài)漂移你以為下播了其實只是網(wǎng)絡抖動直播狀態(tài)字段是最容易誤導人的。某個房間因為網(wǎng)絡波動熱度突然暴跌到接近零如果采集端把這個快照當作“已下播”入庫后面的直播時長統(tǒng)計就全錯了。這種問題叫狀態(tài)漂移典型的解決辦法是引入“確認窗口”。我的經(jīng)驗是一個房間要連續(xù) N 次快照都顯示下播狀態(tài)才真正標記為下播。N 的大小取決于采集間隔通常 TTL 5 到 10 分鐘。同理開播狀態(tài)也需要連續(xù)確認避免把瞬間的接口異常當成開播。處理狀態(tài)漂移的關鍵是在入庫前過濾而不是入庫后再修正。入庫前過濾的好處是下游拿到的數(shù)據(jù)是干凈狀態(tài)不用每個人自己再去判斷。如果真要支持更精細的分析我建議在快照表上加一個session_id字段把連續(xù)的直播時段歸到同一個會話里后續(xù)計算時長、場次的時候直接按會話分組就行。6. 邊界和底線爬之前必須想清楚的幾件事6.1 數(shù)據(jù)源授權是全站爬取的最大約束寫完上面這些工程細節(jié)我必須把話拉回到一個經(jīng)常被刻意回避的問題全站爬取的數(shù)據(jù)源授權邊界在哪。這個問題不是一句“抓公開信息沒問題”就能帶過去的。公開頁面上能看到的數(shù)據(jù)不等于你有權把這些數(shù)據(jù)全量搬運、存儲、轉賣。我在任何采集項目啟動前都要先做兩件事。第一看平臺服務條款和 robots 協(xié)議明確哪些路徑明令禁止自動化訪問。如果平臺條款明確不允許批量采集那生產(chǎn)環(huán)境跑這種采集就存在違約風險能不做就不做。第二看數(shù)據(jù)屬性。涉及個人信息的字段比如昵稱、頭像、個人簽名能改成哈希值就改成哈希值能刪掉就別留。很多團隊在初期只顧著追求數(shù)據(jù)量等用到數(shù)據(jù)時才發(fā)現(xiàn)字段里全是不可碰的內容那時候再洗數(shù)據(jù)成本和風險都是災難級的。我在自己的項目里采用“最小化采集”原則只要業(yè)務不需要彈幕原文就不采彈幕原文只要業(yè)務不需要禮物背后的用戶昵稱就不采用戶昵稱。少一個敏感字段就少一個默認風險。6.2 脫敏存儲和留存周期要形成制度光說不存沒用采集系統(tǒng)要把脫敏規(guī)則和留存周期做成代碼的一部分。我在明細表的寫入鏈路里加了一道脫敏層所有從網(wǎng)絡響應的字段都必須通過字段白名單校驗不在白名單里的字段直接丟棄白名單里包含的敏感字段再經(jīng)過hash處理才允許入庫。留存周期問題同樣重要。直播熱度數(shù)據(jù)和分析結果通常并不需要永久保留。我一般給原始快照設 30 天的保留期超過 30 天的直接清分區(qū)聚合表保留 180 天只有長期分析的統(tǒng)計結果才長期保存。這樣既能控制存儲成本也減少了因為數(shù)據(jù)長期滯留而帶來的合規(guī)風險。6.3 灰度上線先小范圍驗證再全站鋪開最后一個建議聽起來很“不極客”但在全站爬取里反而最保命先灰度。不要第一天就上全量任務而是先挑幾個分區(qū)、幾個典型房間跑一跑觀察請求成功率、數(shù)據(jù)完整度、延遲和風控表現(xiàn)?；叶绕谕ǔＮ抑辽俦Ａ羧煲驗橹辈テ脚_的數(shù)據(jù)有很強的周內周期性周一跑出來的情況周六晚上大概率會不一樣?；叶韧ㄟ^之后再逐步擴大范圍。擴大過程中要持續(xù)觀察兩個指標一個是任務積壓量另一個是風控觸發(fā)的頻率。一旦風控觸發(fā)頻率明顯上升就要立刻回退采集頻次而不是硬沖。全站爬取的長期運營拼的不是某一天抓了多少數(shù)據(jù)而是能不能穩(wěn)定地每天把數(shù)據(jù)完整地補回來?；仡^看我自己的實踐這個項目最后能穩(wěn)定跑下去靠的不是某一個聰明的算法而是把掃描、輪詢、監(jiān)聽三套模式拆開用一致的調度框架管住頻率用冪等鍵和狀態(tài)確認擋住重復和漂移再在存儲層把明細和聚合分開。如果你也要做類似的事情我建議你先從一個小范圍開始把調度節(jié)奏調順了再談全站。多花點時間在設計數(shù)據(jù)邊界上后續(xù)踩坑的機會就會小很多。