某鱼直播全站数据采集实战：从协议解析到架构选型

做直播数据分析的朋友应该都有过这种经历拿着一个平台的业务问题却发现平台把所有数据都锁在自家后台里对外只留了一小扇门。我这次接到的任务是“某鱼直播数据全站爬取”说白了就是把某鱼这个直播平台上的主播信息、直播间状态、热度变化、弹幕互动、礼物收支这些公开数据按自己的业务节奏成体系地采集到本地数据库。如果你正准备做直播行业分析、想给内容运营搭建数据看板或者就是想练手大规模采集后转做数据可视化这篇文章的内容应该能派上用场。我会把从需求拆解到方案落地整条路径完整记录下来包括我踩过的坑和最后稳定运行的方案。1. 需求拆解与整体设计1.1 先搞明白“全站”的边界在哪“全站爬取”这四个字听起来唬人但真要一上来就把整站所有页面都抓一遍既不现实也没必要。这里的“全站”在实际业务里一般指把某个直播平台的核心公开数据做全量覆盖和持续跟踪。具体到某鱼这个场景主要分为几块分类与榜单数据首页各分区游戏、娱乐、户外等下的直播列表以及各类人气榜单、礼物榜。直播间详情房间号、标题、主播昵称、所属分类、热度值、开播时间、直播间标签。实时互动数据弹幕内容、发送者、发送时间礼物赠送记录礼物名、价格、赠送人和接收人。主播维度数据关注数、公告、历史开播时长等。在做技术设计之前必须先把这些问题问清楚要覆盖多少个分类、需要多高频度更新、数据保留多长时间、最终用来支撑什么分析结论。我当时在需求确认阶段就和业务方来回对了好几轮最后敲定了“分类直播间列表每小时全量扫描一次、热度值和在线状态每分钟跑一遍、弹幕和礼物以直播间为维度实时接入”的整体节奏。节奏定下来后面所有模块的设计都有据可依。这里有一个很多人容易犯的误区一听到“全站爬取”第一反应是写个多线程脚本把能看到的链接全部抓下来也不管数据有没有用。结果就是磁盘空间被日志和重复数据撑爆真正能用于分析的字段却没几个。所以做任何采集项目之前先花半天时间把数据字典列出来比直接上手写代码重要得多。1.2 为什么选择协议解析而非页面渲染某鱼这类直播平台页面渲染方式越来越重直接请求HTML再抽数据存在几个痛点首屏数据是动态加载的纯静态请求拿不全页面结构改动频繁XPath和CSS选择器写着写着就失效爬页面性能也差千级直播间的并发采集根本跑不动。所以我在方案里主选接口和协议通道页面解析只作为兜底。直播平台内部的Web API通常会返回结构化JSON弹幕和礼物这类实时数据走WebSocket长连接把这两个通道打通数据质量和采集效率都有保证。页面抓取可以用来做接口缺失字段的补充校对但绝不作为主线。实际开发中接口调用还有一个容易被忽略的好处数据字段是半结构化的能拿到什么字段、字段类型是什么在响应里都写得清清楚楚。相比之下HTML解析不仅慢而且页面里混着大量广告位和推荐位的数据抽离的时候很容易抽错或者抽重。协议接口虽然偶尔也会改字段名但改动频率远低于页面结构。2. 数据架构与存储方案2.1 表结构设计的基本思路采集数据的最终目的是给后面的数据分析用表结构不能拍脑袋。我当时建了房间表、弹幕表、礼物表、热度流水表四张核心表外加一张采集任务日志表用来排查问题。房间表主要存静态属性房间号、标题、主播昵称、所属分类、开播时间、当前状态。热度值这种每秒都在变的东西不适合放这张表我单独建了热度流水表每分钟插入一条记录这样后续做趋势分析特别方便。弹幕和礼物表都按直播间ID和时间建了复合索引查“某个直播间某时间段内的弹幕词频”这类统计时索引能直接命中。在建表阶段有几个细节值得注意字符集统一用utf8mb4不然表情类弹幕会写入失败房间号这类字段虽然看起来是数字但长度可能超过普通INT的范围我用BIGINT时间字段统一用DATETIME别混着时间戳用不然后面做时间窗口查询时老要转格式写SQL都觉得憋屈。2.2 从MySQL到ClickHouse的取舍一开始我把所有数据都丢进MySQL但跑到一周之后就发现热度流水和弹幕数据膨胀得很厉害。尤其弹幕高峰期一个万人直播间一小时就能产出上万条记录全站压测时MySQL的写入开始出现瓶颈。后来我把分析类的热度流水和弹幕数据迁到了ClickHouse理由很直接这两类数据都是典型的时序数据写入是追加式的查询是范围聚合式的正好是ClickHouse的强项。MySQL只保留房间表和礼物表这类维度型数据。这个调整之后采集端的写入瓶颈基本消失查询分析响应也比之前快了一个量级。注意不是所有场景都要上ClickHouse。如果你的数据量级在百万以下MySQL加索引加分区完全够用只有到了千万级并且要做实时聚合分析列式存储的优势才会真正体现出来。2.3 存储容量与数据保留策略全站爬取的数据增长速度快得超出我的预期。最开始我只盯着功能没认真算容量结果磁盘告警的时候已经晚了。后来我留了一个保留策略热度流水保留90天弹幕保留30天原始JSON报文保留7天。非核心的临时表和日志文件每天凌晨清理一次超过保留窗口的数据自动归档到冷存储。容量这块我给后来的人一个建议上线第一周每天记录一次各类表的数据量和磁盘占用增速拿这个数字线性外推就能知道什么时候需要扩容。我踩过的坑是没算增量只看了当前占用的大概数字结果三个月后某天早上磁盘直接打满整个采集链路因为写不进去集体罢工。3. 采集模块核心实现3.1 直播间列表采集直播间的全量列表我直接走某鱼Web端的分区接口。这类接口通常返回JSON格式数据字段比较完整。核心代码如下基于常见实践补充import requests import random def fetch_room_list(category_id, page): url https://openapi.某鱼.example.com/room/list params { sort: hot, cid: category_id, page: page, pageSize: 60, } headers { user-agent: random.choice(UA_LIST), referer: https://www.某鱼.example.com/, } resp requests.get(url, paramsparams, headersheaders, timeout10) data resp.json() if data.get(code) 0: return data[data][list], data[data][hasNext] return [], False这里有一个容易被忽略的点接口返回的热度值字段名在不同分类下可能不一样有的叫heat有的叫hot_value还有藏在一层嵌套对象里的情况。我写字段映射脚本时专门做了兼容把每种来源都登记清楚避免后面统计口径对不上。分页参数也要多看一眼。不同的接口可能用的是page加pageSize也可能是offset加limit甚至还有用cursor游标的。我当时没仔细看文档写了个固定翻页逻辑结果到第20页之后数据永远重复。排查半天才发现是翻页参数写错了位置。3.2 弹幕实时采集弹幕采集是最有意思的部分。某鱼的弹幕走的是WebSocket通道拿到房间ID之后要先建立长连接再按协议格式发送鉴权包和数据包。import asyncio import json import websockets async def listen_barrage(room_id, handler): ws_url fwss://barrage.某鱼.example.com/ws/v1/room/{room_id} async with websockets.connect(ws_url) as ws: auth_packet { type: join-room, data: { room_id: room_id, platform: web, version: 1.0 } } await ws.send(json.dumps(auth_packet)) while True: raw await ws.recv() msg json.loads(raw) if msg.get(type) chat-message: await handler(parse_chat_msg(msg))协议字段的命名和类型不同版本会有差异接入前最好先用一个测试房间抓几百条真实消息做字段对照。我当时就是拿着真实弹幕数据把字段含义一个一个确认清楚再开始写解析逻辑实测下来省了很多返工。弹幕消息的负载格式通常会有一层base64编码的嵌套尤其是加长弹幕、礼物弹幕这类特殊消息解包的时候容易把人绕晕。我的建议是先把一条完整的原始消息保存成JSON文件作为解析的锚点。后面复制字段时有个参照比盯着文档猜要快得多。3.3 礼物与互动数据解析礼物记录同样可以从WebSocket消息里解析关键是要把礼物名、礼物价格、赠送人、赠送对象和时间戳这几个字段拆准确。礼物字段在不同类型消息里结构差异很大有的在extend字段里有的直接平铺在data对象里。我做了个消息分类器按照message_type先分流再分别解析避免了大量解析异常。礼物消息的解析还有一个衍生问题同一个礼物在不同直播间的展示名可能不同甚至同一个礼物会有“礼物名数量”的组合格式。我在解析后做了一层标准化处理把礼物名映射到一个统一的编号体系比如“火箭”统一为G001“办卡”统一为G002。这样后续统计礼物收入时才不会被同义名称干扰。经过一段时间的运行就能明显观察到礼物消息的时间规律晚上8点到11点是明显高峰周末比工作日高出不少。这些规律后来在做平台生态分析时成了很好的辅助信息也让我更理解数据采集合规运行的意义。3.4 增量更新与任务调度全站数据不可能每时每刻都重抓增量更新是必须的。我用APScheduler做定时调度核心策略是分级任务任务级别执行频率覆盖范围Level 1全量直播间列表同步每小时1次所有分类的直播房间信息Level 2热度与状态刷新每1分钟1次在播房间的热度、开播状态Level 3弹幕/礼物接入实时WebSocket核心目标房间Level 4数据清理归档每天1次过期日志、临时表分级调度有一个明显的好处任务之间不会互相阻塞。就算L1的全量同步因为网络原因卡住了L2的热度刷新还能正常执行最多就是某个分类的数据暂时没有更新不会影响整体采集体系的运转。调度系统的另一个关键能力是任务状态可视化。我在每个任务执行时都写一条日志到库里记录开始时间、结束时间、状态、涉及数据量。排查问题时直接查日志表比翻几百MB的日志文件轻松太多。这也是我后来加上的最初没这东西出问题全靠猜。4. 反爬应对与稳定性保障4.1 常规反爬手段和应对思路某鱼的反爬主要集中在几个层面请求头校验、频率限制、行为分析、WebSocket连接鉴权。我的原则是不搞对抗只做规避。什么意思呢就是老老实实模拟正常用户的访问行为用合理的频率、随机的间隔去请求不做高频强撸不尝试破解验证码不绕过登录鉴权。一旦触发频率限制就主动降低并发、暂停一段时间等风头过去再继续。如果某个接口开始频繁返回验证码我基本会先停掉该部分采集检查是不是请求头里的标识不完整或者某段时间内的请求频率太集中。盲目靠高频请求硬冲往往最后连IP都被拉黑得不偿失。这里我想多说一句爬虫圈子里经常有人把反爬对抗说得特别玄乎好像不搞点骚操作就抓不到数据。但在我这个项目里真正起作用的恰恰是“克制”。把频率控制在目标平台可接受的范围内把请求的细节做得像正常用户绝大部分数据都能稳定拿到。激进方案它可能在短时间拿到更多数据但跑不了几天就被拉黑还得换一批身份继续折腾。4.2 IP资源的选型与轮换策略做全站采集稳定的IP资源几乎是绕不开的。我对比过两种方案自己租用服务器和购买第三方IP服务。自己租用需要稳定带宽和足够多的IP段运维成本不低直接买第三方IP资源服务又要注意按量计费、IP质量和可用率。最终我选的是混合模式核心采集任务用相对稳定的住宅IP批量列表扫描用价格便宜的动态拨号IP池。IP资源池在代码里我做了一层可用性校验。每次取出一个IP先用它请求一次轻量接口做连通测试连续失败三次就标记为失效并自动剔除每分钟检测一次池中可用IP数量低于阈值时告警保证采集链路不会因为没有可用IP而中断。class IPPool: def __init__(self, redis_client): self.redis redis_client def get_ip(self): ips self.redis.lrange(ip_pool, 0, -1) if not ips: return None return random.choice(ips).decode() def mark_invalid(self, ip): self.redis.zincrby(ip_fail_count, 1, ip)这套逻辑虽然简单但很实用。最初我没做失效淘汰结果有些坏IP反复被选中导致请求连续超时整批任务被判定为失败。加上校验和淘汰之后采集成功率稳定在99%以上。4.3 采集频率与请求间隔的节奏控制频率控制是反爬应对里最见功夫的地方。我这边把请求分成了两个维度来控单IP每秒最多不超过几个请求单个任务线程里的请求间隔在1到3秒之间随机。多个目标域名的并发总量也有上限不是想开多少开多少而是按照任务优先级动态分配。具体实现上我用了一个全局计数器记录每个IP的秒级请求次数超过阈值就直接在内存里拦截不再发请求。配合随机延迟整体请求曲线看起来就像一群不同习惯的用户在刷页面而不是一台机器在疯狂输出。这个策略在压测时发挥了很大作用。最开始我把并发开到很大结果不到十分钟整个采集任务就被平台限制了日志里全是请求超时和验证码提示。把频率降下来、请求间隔随机化之后反而跑得很稳连续一周没有出现大规模封禁。这让我深刻理解了一个道理爬虫的稳定性更多是设计出来的而不是靠硬扛堆出来的。4.4 数据采集失败的重试与补偿机制网络环境再稳定也免不了偶发失败。我在所有采集模块里都加了重试机制重试策略采用指数退避第一次失败等1秒第二次等2秒第三次等4秒最多重试5次。超过次数就把任务标记为失败进入补偿队列。补偿队列是解决“短时故障丢数据”的关键。比如某个小时段列表接口正好在升级采集任务一直在失败这时候业务方晚上看数据时就会发现少了那一段。补偿队列会把失败任务的参数存下来等接口恢复后按照原计划参数重新执行一次把缺失的数据补上。提示补偿队列不需要太复杂一张表加上一段定时扫描的逻辑就够用。但千万别省略否则任何一次长时间的网络波动都会在你下游的数据分析环节制造看得到却说不清的缺口。5. 上线后的排查与优化实录5.1 WebSocket连接被高频断开连续运行一段时间后我发现有些房间的WebSocket连接会被主动断开重连又断开几乎无法正常采集弹幕。初步怀疑是连接数量太多或者心跳包发送间隔不合理。我调整了连接策略为每个直播间维护一个独立连接但增加了心跳包发送频率并在断开后加入指数退避重连退避间隔从1秒倍增到30秒。修改后连接稳定性明显改善弹幕数据漏采率大幅下降。后来我也意识到不能把所有直播间的弹幕都实时接进来会消耗大量连接资源。我对房间按热度做了筛选只有热度值超过某个阈值的房间才开启实时弹幕采集。热度低的小直播间弹幕量本身不大每隔几分钟拉一次弹幕快照就够用了。这样既降低了连接压力也覆盖到了核心数据。5.2 数据入库时出现大量重复弹幕和热度流水表跑了一段时间后发现数据量比预期大不少查了下库里居然有大片重复记录。原因出在WebSocket的重连机制上重连后服务端可能把缓冲期间的最近消息重新推送一遍采集端没有做幂等去重。解决方式是在采集端增加一个内存布隆过滤器对每条消息的唯一ID做去重达到一定量级后批量写入临时表再由定时任务做一次基于唯一键的合并。这样既保证了实时性也把重复率降到了可控范围。如果是MySQL我建议在可能产生重复的字段上直接建唯一索引例如弹幕的唯一ID、热度流水的时间戳和房间号的联合字段。唯一索引会挡住绝大多数的重复写入剩下的由采集端去重逻辑处理。两条路同时走重复率几乎可以降到零。5.3 任务积压导致采集延迟某个深夜L1全量列表同步任务因为目标接口升级两个小时内没有成功执行导致后面依赖房间列表的L2、L3任务全部积压。等我早上看到告警的时候热度数据已经缺了一大段。我在调度系统里补充了失败重试、队列积压监控和异常告警三类能力任务失败先按指数退避重试最多三次积压超过设定阈值就触发告警并暂停低优先级任务每个关键步骤都接入告警通知。这套机制之后帮我避免了好几次类似的连锁故障。有一个小的设计心得任务调度不要做成单线程的串行队列。某个任务卡住别让其他任务陪着等。我后来把所有任务都拆成独立进程用消息队列串起来任何单个任务卡死都不会影响其他模块。系统稳定性的提升是肉眼可见的。5.4 数据质量校验最容易忽略的一环数据采集得再多质量不行后面分析也白搭。我专门写了一个校验脚本每天对房间列表做总数比对记录采集到的直播间总数和昨天同时段的差异超过阈值就报警对热度和弹幕字段做空值率、异常值检测确保入库数据是可信的。比如热度值正常情况下不会有负数也不会突然跳变到几千万如果发现在没有大型赛事直播的时段出现了异常的尖峰那八成是采集解析时把某个字段拼错了。这种问题靠人眼查是查不出来的必须依赖自动校验脚本。提示数据质量校验并不复杂但它能帮你在分析阶段省下大量反查脏数据的时间属于典型的“前期多花一小时后期少花一整天”的投入。6. 合规边界与扩展心得6.1 爬取边界怎么守爬虫的能力边界和责任边界任何时候都得分开看。技术上做到某鱼全站爬取完全可行但“可以做”和“应该做”是两回事。我在推进项目时坚持几个原则只采集公开可见的数据不触碰用户隐私字段和需要登录后可见的信息采集频率以不给目标服务器造成明显压力为准数据仅用于内部分析不对外转售不用于任何可能骚扰用户的场景。这个边界定下来后面做任何技术决策都有了一个清晰的判断标尺。另外还有一点容易被忽略采集数据的使用方式要符合数据相关法律法规。做行业分析、做内容趋势研究这都没有问题但如果拿全站数据去二次售卖或用于不正当竞争那就越界了。我自己在给业务方交数据时都会附带一个数据使用说明明确各字段的采集来源和合理使用范围。这样既保护了自己也帮业务方规避了潜在风险。如果接口持续返回验证码、频繁限制访问我会第一时间判断是不是采集端节奏出了问题而不是想着去对抗强解。技术可以很强但没必要把对抗作为目标最终数据质量高、采集链路稳才是关键。实际跑过这个项目之后你会明显感觉到一个稳定运行三个月不出大故障的采集系统远比一个功能花哨但动不动挂掉的爬虫有价值。6.2 后续可以怎么扩展这套采集体系跑稳之后往上能做的方向其实很多把热度流水分时段聚合做出全平台的热度走势图对弹幕做分词和情感分析看各分区的内容氛围差异把礼物数据对应到主播收入配合开播时长做生态榜单。这些方向对现在的数据基础来说几乎是拿来就能用。我个人还想做一套直播热度预测的东西用历史热度和弹幕活跃度做特征训练一个简单模型去预估下个时段的热度走势。直播平台的流量波动其实很有规律早晚高峰、周末效应、赛事拉动这些都是肉眼可见的强信号只要数据采集链路稳定这类分析落地难度并不高。对刚接触这类项目的朋友我建议先从单一功能入手选一个分类下的直播间列表做一个单机版的采集脚本把数据落到SQLite或者MySQL里跑通之后再考虑全站并发和实时弹幕。大而全的方案不是不行但调试和排错的复杂度会成倍增长先跑通主干再补枝叶是更稳妥的路径。6.3 最后分享一点踩坑体会做全站爬取这类项目真正难的从来不是单一的采集技术而是把“目标拆解、数据建模、采集调度、质量保障、异常处理”整条链路串起来的能力。一个粗糙的爬虫脚本跑几百条数据可能没问题但放到全站千万级数据量的场景里数据库连接管理、线程并发控制、磁盘空间规划、任务失败恢复这些事都会变成真正的瓶颈。踩过几次坑之后我的体会是别急着写爬虫代码先把数据模型和调度架构想清楚。很多团队做采集项目失败不是不会写请求而是数据没有一个好去处、任务没有一个好调度、故障没有一个好恢复机制。先把这几点夯实全站爬取就是一个工程问题一步一步解就行。