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