1. 项目概述与核心思路先说结论这套系统就是围绕 B站哔哩哔哩视频的弹幕数据走一条「采集 - 存储 - 分布式计算 - 可视化展示」的完整链路。技术栈锁定在 Python、Hadoop、Spark最终输出一个类似数据大屏的管理看板可以看热门视频弹幕量趋势、高频弹幕词、用户活跃时段、弹幕情感分布等。我刚做完这个项目的时候最大的感受是难点并不在于某个单一技术而在于把整个链路串起来。网上很多教程只讲爬虫或者只讲 Spark 单机分析真正能把 Hadoop Spark 可视化搞成一套系统的完整案例反而不多。所以这篇博文不打算泛泛而谈直接把我的设计思路、核心代码、踩坑记录全部摊开你可以照着落地。适合谁来参考如果你是刚学完 Hadoop 和 Spark 基础想找一个综合实战项目练手或者你已经有一个数据分析系统但不知道怎么把 B站弹幕这种半结构化数据高效处理和展示这篇文章都值得看。我不会假设你已经有完整的大数据集群后面会给出单机伪分布式也能跑的方案。1.1 这个系统到底做什么简单举几个实际能用的场景。运营人员想了解某部番剧的弹幕高峰出现在第几集、哪个时间点用户最爱发弹幕内容创作者想知道自己的视频里观众反复提及的关键词是什么做舆情分析的人可能会关注弹幕里的情绪倾向。这套系统把这些需求统一收口定时或手动抓取指定视频的弹幕清洗后存到 HDFS然后用 Spark 跑统计分析最后在浏览器里用图表展示结果。我这里抓取的范围主要包括三类数据弹幕本体内容、发送时间、弹幕池类型、弹幕属性弹幕出现时间点、颜色、字体大小、用户标识匿名用户ID。这里多说一句B站返回的弹幕 XML 里有两个时间字段一个是弹幕在视频中的出现时间progress一个是弹幕发送时的 Unix 时间戳ctime这两者经常被搞混后面我会专门讲怎么处理。1.2 为什么选择 Python Hadoop Spark很多朋友会问弹幕数据量也不至于上亿为什么非要扯上 Hadoop 和 Spark直接用 Pandas 不行吗这里有个取舍逻辑。如果只是分析一两个视频几千条弹幕Pandas 确实够。但是当你把某个分区、某个 UP 主甚至整个分区的话题视频都抓下来弹幕数量会快速膨胀到千万级别甚至更多。这时候单机内存就会成为瓶颈而且你还需要处理多个数据源的合并、反复清洗、多次迭代计算。Spark 的 RDD / DataFrame 模型非常适合这种「一次写入、多次读取」的批处理分析。Hadoop 在这里的定位是存储层。HDFS 对海量小文件的友好度一般但弹幕采集下来我们会按日期或视频ID聚合打包成一定大小的文件所以问题不大。再说很多团队的大数据基础设施已经以 Hadoop 为核心你用 Spark 读写 HDFS 是天然顺滑的。Python 则负责两层工作一是写爬虫抓取弹幕二是做可视化后端和数据处理胶水。PySpark 让我们可以用 Python 写 Spark 任务这样整条链路都不需要切换语言对 Python 开发者非常友好。当然你也可以用 Scala 写分析任务但对于非 JVM 背景的开发者PySpark 的上手成本低很多。2. 环境准备与数据采集2.1 整体数据集与技术栈我用的环境是Ubuntu 20.04 虚拟机Hadoop 3.3.6伪分布式模式Spark 3.4.0on YARNPython 3.9。如果你只有一台机器建议先用伪分布式把流程跑通后续再用三台以上节点做真分布式。需要安装的组件列表Hadoop HDFS YARNSpark我用的是预编译的 hadoop3 版本Python 依赖requests、pandas、pyarrow、flask、flask-cors、pysparkECharts纯前端图表库直接 CDN 引入即可从数据规模上说我测试时抓取了某几个热门分区下的 200 个视频累计弹幕约 1200 万条压缩后存储约 4GB。在一个 4 核 8G 的虚拟机上跑 Spark 任务单次全量分析大概需要 6 分钟。如果只是增量分析最近一天的数据分桶后一般 40 秒内能完成。2.2 B站弹幕数据获取细节B站的弹幕接口一直是公开的老版本可以直接请求视频对应的 XML 文件形如https://comment.bilibili.com/{cid}.xml这个 cid 是视频分P的 ID你通过视频的 BV 号可以调网页接口拿到。后来弹幕升级为 protobuf 格式但旧版 XML 接口在大多数视频上仍然可用而且解析简单。为了稳定复现我这边基于新版接口做因为新版接口返回的是 protobuf需要处理一下二进制格式。先用 requests 拿视频信息import requests import re def get_cid_list(bvid): url fhttps://api.bilibili.com/x/web-interface/view?bvid{bvid} headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders).json() pages resp[data][pages] return [p[cid] for p in pages]拿到 cid 后可以请求弹幕接口。新版接口我这里不展开二进制协议细节建议直接用解析库。老版本 XML 接口有一个坑接口返回的是 GBK 编码直接用 requests 的 text 属性会乱码需要设置resp.encoding utf-8或者干脆用apparent_encoding自动识别。弹幕 XML 的结构大概是d p32.631,1,25,16777215,1680249600,0,abc123,0这条弹幕真有意思/dp 属性用逗号分隔多个字段。第一个是弹幕出现在视频中的秒数第二个是弹幕类型1 为普通滚动弹幕第三个是字号第四个是颜色第五个是发送时的 Unix 时间戳第六个是弹幕池第七个是用户 ID 的 hash 值第八个是 rowid。抓取时注意控制频率特别是批量抓取时不要并发太高。我采用「每个 cid 延迟 1-2 秒」的策略2000 个视频也能在半小时内抓完。如果你用多线程也要设置信号量建议不超过 4 个并发否则容易被风控。2.3 数据清洗与入库抓下来的原始弹幕不能直接用因为存在大量换行符、空白字符、繁体中文、emoji 表情以及一些需要过滤的特殊标记。比如弹幕里的{rainbow}表示彩色弹幕效果分析关键词时要去掉。另外B站弹幕里常有「空降」「打卡」这类词如果做高频词统计需要结合停用词表处理。清洗流程我放在 Python 层避免把垃圾数据写进 HDFSimport re import pandas as pd def clean_danmaku(df): # 去掉花括号特效标记 df[content] df[content].str.replace(r\{[^}]*\}, , regexTrue) # 去除多余空白 df[content] df[content].str.strip() # 去掉长度小于2的纯符号弹幕 df df[df[content].str.len() 2] # 转为字符串类型 df[content] df[content].astype(str) return df清洗之后我会把同一个视频的所有弹幕拼成一个 JSON 文件或者直接按天分桶写入 Parquet 格式。Parquet 的列式压缩比远远好于 JSON 和 CSV在 Spark 里查询速度快很多。实测同一个数据集JSON 格式占 4GB转成 Parquet 后只有 1.1GB查询速度提升约 3 倍。写入 HDFS 的方式很简单hdfs dfs -put /data/danmaku/parquet /warehouse/danmaku如果你习惯用 Python 操作 HDFS可以用hdfs这个库但更稳定的方式是先写本地临时目录再调用 HDFS shell 命令。原因是 Python 的 HDFS 客户端在某些版本上存在连接泄漏问题。3. Spark 分析核心实现3.1 数据分析的维度设计拿到清洗后的数据后要思考一个问题弹幕分析到底分析什么我最终确定了四个核心维度弹幕量趋势按天、按小时统计弹幕数量判断视频热度周期。高频词与热梗从弹幕内容里提取关键词找出观众讨论的焦点。用户活跃度统计用户 ID 的去重数量、发送频率识别核心粉丝。情感倾向对弹幕文本做简单情感打分区分正面、负面、中性。这四个维度刚好对应业务上最常被问到的几个问题。我用 PySpark 写分析任务是为了后续能无缝迁移到集群环境。3.2 弹幕高频词与热梗识别高频词统计最基础但在弹幕场景里有个问题弹幕短、口语化、错别字多、网络热词多。直接分词会得到一堆无意义的词语。我这里采用「先过滤停用词 再统计 n-gram」的方式。停用词表需要自己扩充除了常见中文停用词还要加入弹幕场景专用词「哈哈哈哈」「草」「来了」「前方高能」「泪目」等。这些词本身有意义但如果要分析具体话题它们会淹没真正的关键词。使用 Spark 做分词和统计的代码from pyspark.sql import SparkSession from pyspark.sql import functions as F from pyspark.ml.feature import Tokenizer, StopWordsRemover spark SparkSession.builder.appName(danmaku_analysis).getOrCreate() df spark.read.parquet(hdfs://localhost:9000/warehouse/danmaku) # 简单分词先用空格分隔因为清洗阶段已把弹幕按字符处理 # 这里使用 jieba 分词可以通过 pandas UDF 调用但为了性能我直接按字切分 tokenizer Tokenizer(inputColcontent, outputColwords) words_df tokenizer.transform(df) # 停用词过滤 remover StopWordsRemover(inputColwords, outputColfiltered) filtered_df remover.transform(words_df) # 展开词并统计 result filtered_df.select(F.explode(F.col(filtered)).alias(word)) \ .groupBy(word) \ .count() \ .orderBy(F.col(count).desc()) result.show(20)这里要注意直接用Tokenizer会把「哈哈哈」当一个词也会把「awsl」当一个词效果比 jieba 差一些。如果你对结果要求高可以注册一个 jieba 分词 UDFfrom pyspark.sql.types import ArrayType, StringType import jieba F.udf(returnTypeArrayType(StringType())) def jieba_cut(s): return list(jieba.cut(s))但 UDF 在数据量大时会很慢建议先缩采样测试再全量跑。我最后的方案是先做一次高频词粗筛再对高频词的上下文做 n-gram 分析找出「双字词 双字词」的组合比如「永远」「的神」这种梗。3.3 弹幕时间分布与用户活跃度分析弹幕时间分布可以拆成两个维度视频内时间点和自然时间。视频内时间点能反映作品的节奏感比如「开头 30 秒弹幕密集」说明前奏抓人自然时间点能反映观众的作息规律比如晚上 10 点是发弹幕高峰期。代码实现from pyspark.sql.functions import from_unixtime, hour, minute df df.withColumn(dt, from_unixtime(F.col(ctime))) \ .withColumn(hour, F.hour(dt)) \ .withColumn(video_sec, F.col(progress).cast(int)) # 自然小时分布 hour_stats df.groupBy(hour).count().orderBy(hour) # 视频内时间分布按每10秒分桶 df df.withColumn(bucket, (F.col(video_sec) / 10).cast(int) * 10) bucket_stats df.groupBy(bucket).count().orderBy(bucket)用户活跃度分析就是按用户 ID 去重统计还可以算每个用户的弹幕数量分布识别「弹幕狂魔」。这里有个隐私注意点B站弹幕 XML 里的用户 ID 是经过 hash 后的字符串并不是真实 UID所以分析结果不会泄露真实用户信息。我们只需要将这个 hash 值作为用户标识即可。3.4 情感倾向初探情感分析是弹幕分析里最有意思但最难做准确的部分。弹幕语言高度依赖语境比如「就这」可以是贬低也可以是调侃。我这边用了一个非常朴素但可用的方法构建正负面词典对每条弹幕的情感词打分。词典我直接用了开源的通用中文情感词典再结合弹幕场景扩充了「绝了」「泪目」「破防」「yyds」「tql」等词。打分的时候用 PySpark 的when条件累加pos_words [绝了, 泪目, 破防, 好看, 喜欢, yyds, tql, 神仙, 爱了] neg_words [烂, 垃圾, 弃了, 无语, 差评, 恶心, 血压] def sentiment_score(text): s 0 for w in pos_words: if w in text: s 1 for w in neg_words: if w in text: s - 1 return s sentiment_udf F.udf(sentiment_score, int) df df.withColumn(score, sentiment_udf(F.col(content))) # 统计比例 sentiment_stats df.withColumn(sentiment, F.when(F.col(score) 0, positive) .when(F.col(score) 0, negative) .otherwise(neutral)) \ .groupBy(sentiment).count()注意这种词典法只能作为粗粒度参考想要更细的语义情感需要微调中文预训练模型但那样整个项目的计算成本就会高很多。作为实战项目用词典法先把流程跑通已经能看出大致的情绪分布趋势。4. 可视化系统搭建4.1 架构模式与接口设计分析结果最终要以可视化的方式呈现。我选择用 Flask 作为后端服务ECharts 作为前端图表库。后端通过 API 返回 JSON 数据前端页面用 AJAX 拉取。整体分成三层数据服务层Spark SQL 查询结果导出成 Parquet 或直接读 HDFS 上的聚合表。后端 API 层Flask 提供/api/trend、/api/hotwords、/api/sentiment等接口。前端展示层HTML ECharts动态渲染图表。为什么不用 Django因为这里后端逻辑比较简单Flask 更轻。如果你未来打算加用户权限、后台管理再迁移到 Django 也不迟。接口返回格式统一为{ code: 0, data: { categories: [00:00, 01:00, ...], values: [12, 20, ...] } }这样前端基本不用处理复杂结构直接绑定到 ECharts 的 series 里。4.2 大屏看板实现大屏看板是这套系统的门面我实现了以下模块顶部指标卡展示总弹幕数、视频数、用户数、今日弹幕增量。中间主体弹幕量趋势折线图支持按小时和按天切换。左侧面板高频词 Top30 词云。右侧面板弹幕情感分布饼图以及用户活跃度排行条形图。底部区域视频内弹幕时间密度热力图。用 ECharts 写大屏的要点是「自适应布局」。我用了简单的 flex 布局通过监听 window.resize 事件刷新图表。如果你用的 ECharts 5可以开启media特性。一个核心点多个图表同时请求数据时容易造成接口拥堵。我在前端做了 Promise.all 聚合请求后端也开启了 Flask 多线程from flask import Flask, jsonify from flask_cors import CORS import json app Flask(__name__) CORS(app) app.route(/api/overview) def overview(): # 从预聚合结果读取 data load_overview_data() return jsonify({code: 0, data: data})后端读取的聚合结果我建议在 Spark 任务跑完后把每组统计结果分别写成小体积 JSON 文件Flask 启动时加载到内存。这样请求响应基本在毫秒级而不是每次查 Hive 或者查 HDFS。4.3 关键图表与交互高频词词云用的是 ECharts 的 wordCloud 扩展。ECharts 官方仓库里有词云插件直接引 JS 文件即可。如果部署环境不能访问外网需要把静态文件本地化。弹幕量趋势我用了双折线一条是弹幕总量另一条是去重用户数。两条线放在同一坐标系中能直观看出「弹幕涨了是否真的因为更多人参与」。视频内弹幕密度热力图我把进度按 10 秒分桶横轴是视频进度纵轴是视频分 P 序号颜色越深代表弹幕越密集。这种图最适合对比「第几集最精彩」。交互方面我做了一个简单的筛选器左边选择视频分区如动画、游戏、音乐右侧所有图表联动刷新。前端代码不复杂就是点击事件里重新请求数据function refreshAll() { const region document.getElementById(region).value; Promise.all([ fetch(/api/trend?region${region}).then(r r.json()), fetch(/api/hotwords?region${region}).then(r r.json()), fetch(/api/sentiment?region${region}).then(r r.json()) ]).then(([trend, hotwords, sentiment]) { renderTrend(trend.data); renderHotwords(hotwords.data); renderSentiment(sentiment.data); }); }这里有一个体验细节每次切换筛选器如果数据量较大前端会白屏卡顿。解决办法是先用一个 300ms 的防抖函数等用户停止连续操作后再请求。另外图表更新时不要直接用setOption的全量参数改用merge方式合并更新性能更好。5. 常见问题与排查笔记5.1 数据采集被限制B站对爬虫的识别越来越严格。最典型的报错是请求弹幕接口返回-412状态码表示被风控拦截。我在实际项目里主要通过三个手段规避降低请求频率、设置随机 User-Agent、使用 cookie 池。如果发现 IP 被限制最简单的办法是等几分钟再抓或者通过代理更换出口 IP。但我不建议大规模使用代理因为稳定性差而且代理 IP 质量参差不齐。更好的思路是先抓取视频元数据再根据 cid 分批发弹幕请求每批 1000 个请求休息 5 秒。另外弹幕接口有segment_index参数用来分页获取大视频的弹幕。早期很多教程没提这个导致只能抓到前 600 条弹幕。我当时也是踩了这个坑才注意到老视频弹幕量多必须循环请求每一段for segment in range(1, 20): url fhttps://api.bilibili.com/x/v1/dm/list.so?oid{cid}segment_index{segment} # 解析并拼接如果某段返回为空就可以停止循环这是一个常见的终止条件。5.2 Spark 数据倾斜与 OOM跑高频词统计时遇到最典型的性能问题是数据倾斜某些热词比如「哈哈」的量级远超普通词导致单个 reducer 任务运行极慢。我在 4 核虚拟机上跑 1200 万条弹幕有一个 reducer 跑了 15 分钟还没结束。解决办法有两个方向。第一对高频词统计做两阶段聚合。先在 map 端本地聚合一次再对结果做 shuffle 聚合。Spark 的groupBy自带 Combine 操作但如果你用groupByKey就要小心。第二对可疑热词加随机前缀打散最后再去掉前缀聚合。代码示例from pyspark.sql.functions import concat, lit, rand, regexp_replace # 先加随机前缀0~9 df df.withColumn(word_prefix, concat((F.rand() * 10).cast(int), lit(_), F.col(word))) # 聚合后去掉前缀再聚合一次 stats df.groupBy(word_prefix).count() stats stats.withColumn(word, regexp_replace(word_prefix, ^[0-9]_, )) \ .groupBy(word).agg(F.sum(count).alias(count))OOM 则一般发生在读取 HDFS 大文件后做collect()的时候。注意 Spark 中collect()会把所有结果拉到 Driver数据量大时必然爆。我的习惯是只在最后输出 Top N 时才用collect()中间结果都写入 HDFS 或本地文件。如果你需要把结果传到 Flask终端输出 JSON 文件后通过共享目录读取。5.3 可视化性能优化如果前端同时展示数千个点ECharts 渲染会卡顿。实际弹幕趋势按小时统计后有 24 个点按天统计有几十个点问题不大。但词云如果展示 100 个词每一个词渲染成一个图形在低端设备上可能会有明显卡顿。解决办法是只展示 Top 50并且词云组件开启drawOutOfBound为 false。另一个容易被忽视的问题是时区。Spark 里from_unixtime默认的是本地时区如果你的服务器是 UTC而你人在东八区统计出来的小时分布整体会偏移 8 小时。解决办法是在 Spark Session 初始化时设置spark SparkSession.builder \ .config(spark.sql.session.timeZone, Asia/Shanghai) \ .getOrCreate()建议一开始就加上这个配置不要等到看数据不对劲了再排查。后端接口响应时间如果超过 2 秒多半是每次请求都在重新计算指标。我最终的方案是Spark 任务定时跑产物落地为每小时的快照 JSON。Flask 只读快照不直接跑 Spark。这样实时性虽然降低了一些但交互体验大大提升。如果你需要接近实时的效果可以考虑引入 Redis 做缓存层。写在最后我的个人体会与建议整个项目从零到跑通我大概花了两周时间。中间最耗时的不是写代码而是调数据质量。B站弹幕里的梗、缩写、表情符号远比想象中复杂想要分析结果有说服力清洗环节必须花大力气。我后来养成了一个习惯把清洗规则沉淀成一个 Python 文件每次拿到新数据先跑一遍采样人工看 100 条清洗结果确认没有明显问题后再批量处理。另一个建议是不要一上来就追求炫酷的可视化界面。先把 Spark 分析任务的数据结果用命令行打印出来确认数值合理再考虑画图。如果分析结果是错的再好看的图表也只是精致的垃圾。如果你打算往更深处扩展可以在现有基础上加两块内容一是接入实时流处理用 Spark Streaming 或 Flink 消费 B站直播弹幕二是引入更细致的 NLP 模型做弹幕语义角色识别比如区分「刷梗弹幕」和「真实观点弹幕」。这两个方向都能让系统的分析价值提升一个档次。最后分享一个小技巧开发阶段尽量用「小数据 本地模式」跑通流程比如只抓 10 个视频、5000 条弹幕用spark.masterlocal[*]调试。确认逻辑无误后再用 YARN 模式跑全量数据。这样能省掉大量排队等待时间也能让你更专注于核心分析逻辑。 
长河君 · 2026/10/21 10:26:23 · 阅读 1.2k 从爬虫到可视化：Python/Spark构建B站弹幕大数据分析实战
1. 项目概述与核心思路先说结论这套系统就是围绕 B站哔哩哔哩视频的弹幕数据走一条「采集 - 存储 - 分布式计算 - 可视化展示」的完整链路。技术栈锁定在 Python、Hadoop、Spark最终输出一个类似数据大屏的管理看板可以看热门视频弹幕量趋势、高频弹幕词、用户活跃时段、弹幕情感分布等。我刚做完这个项目的时候最大的感受是难点并不在于某个单一技术而在于把整个链路串起来。网上很多教程只讲爬虫或者只讲 Spark 单机分析真正能把 Hadoop Spark 可视化搞成一套系统的完整案例反而不多。所以这篇博文不打算泛泛而谈直接把我的设计思路、核心代码、踩坑记录全部摊开你可以照着落地。适合谁来参考如果你是刚学完 Hadoop 和 Spark 基础想找一个综合实战项目练手或者你已经有一个数据分析系统但不知道怎么把 B站弹幕这种半结构化数据高效处理和展示这篇文章都值得看。我不会假设你已经有完整的大数据集群后面会给出单机伪分布式也能跑的方案。1.1 这个系统到底做什么简单举几个实际能用的场景。运营人员想了解某部番剧的弹幕高峰出现在第几集、哪个时间点用户最爱发弹幕内容创作者想知道自己的视频里观众反复提及的关键词是什么做舆情分析的人可能会关注弹幕里的情绪倾向。这套系统把这些需求统一收口定时或手动抓取指定视频的弹幕清洗后存到 HDFS然后用 Spark 跑统计分析最后在浏览器里用图表展示结果。我这里抓取的范围主要包括三类数据弹幕本体内容、发送时间、弹幕池类型、弹幕属性弹幕出现时间点、颜色、字体大小、用户标识匿名用户ID。这里多说一句B站返回的弹幕 XML 里有两个时间字段一个是弹幕在视频中的出现时间progress一个是弹幕发送时的 Unix 时间戳ctime这两者经常被搞混后面我会专门讲怎么处理。1.2 为什么选择 Python Hadoop Spark很多朋友会问弹幕数据量也不至于上亿为什么非要扯上 Hadoop 和 Spark直接用 Pandas 不行吗这里有个取舍逻辑。如果只是分析一两个视频几千条弹幕Pandas 确实够。但是当你把某个分区、某个 UP 主甚至整个分区的话题视频都抓下来弹幕数量会快速膨胀到千万级别甚至更多。这时候单机内存就会成为瓶颈而且你还需要处理多个数据源的合并、反复清洗、多次迭代计算。Spark 的 RDD / DataFrame 模型非常适合这种「一次写入、多次读取」的批处理分析。Hadoop 在这里的定位是存储层。HDFS 对海量小文件的友好度一般但弹幕采集下来我们会按日期或视频ID聚合打包成一定大小的文件所以问题不大。再说很多团队的大数据基础设施已经以 Hadoop 为核心你用 Spark 读写 HDFS 是天然顺滑的。Python 则负责两层工作一是写爬虫抓取弹幕二是做可视化后端和数据处理胶水。PySpark 让我们可以用 Python 写 Spark 任务这样整条链路都不需要切换语言对 Python 开发者非常友好。当然你也可以用 Scala 写分析任务但对于非 JVM 背景的开发者PySpark 的上手成本低很多。2. 环境准备与数据采集2.1 整体数据集与技术栈我用的环境是Ubuntu 20.04 虚拟机Hadoop 3.3.6伪分布式模式Spark 3.4.0on YARNPython 3.9。如果你只有一台机器建议先用伪分布式把流程跑通后续再用三台以上节点做真分布式。需要安装的组件列表Hadoop HDFS YARNSpark我用的是预编译的 hadoop3 版本Python 依赖requests、pandas、pyarrow、flask、flask-cors、pysparkECharts纯前端图表库直接 CDN 引入即可从数据规模上说我测试时抓取了某几个热门分区下的 200 个视频累计弹幕约 1200 万条压缩后存储约 4GB。在一个 4 核 8G 的虚拟机上跑 Spark 任务单次全量分析大概需要 6 分钟。如果只是增量分析最近一天的数据分桶后一般 40 秒内能完成。2.2 B站弹幕数据获取细节B站的弹幕接口一直是公开的老版本可以直接请求视频对应的 XML 文件形如https://comment.bilibili.com/{cid}.xml这个 cid 是视频分P的 ID你通过视频的 BV 号可以调网页接口拿到。后来弹幕升级为 protobuf 格式但旧版 XML 接口在大多数视频上仍然可用而且解析简单。为了稳定复现我这边基于新版接口做因为新版接口返回的是 protobuf需要处理一下二进制格式。先用 requests 拿视频信息import requests import re def get_cid_list(bvid): url fhttps://api.bilibili.com/x/web-interface/view?bvid{bvid} headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders).json() pages resp[data][pages] return [p[cid] for p in pages]拿到 cid 后可以请求弹幕接口。新版接口我这里不展开二进制协议细节建议直接用解析库。老版本 XML 接口有一个坑接口返回的是 GBK 编码直接用 requests 的 text 属性会乱码需要设置resp.encoding utf-8或者干脆用apparent_encoding自动识别。弹幕 XML 的结构大概是d p32.631,1,25,16777215,1680249600,0,abc123,0这条弹幕真有意思/dp 属性用逗号分隔多个字段。第一个是弹幕出现在视频中的秒数第二个是弹幕类型1 为普通滚动弹幕第三个是字号第四个是颜色第五个是发送时的 Unix 时间戳第六个是弹幕池第七个是用户 ID 的 hash 值第八个是 rowid。抓取时注意控制频率特别是批量抓取时不要并发太高。我采用「每个 cid 延迟 1-2 秒」的策略2000 个视频也能在半小时内抓完。如果你用多线程也要设置信号量建议不超过 4 个并发否则容易被风控。2.3 数据清洗与入库抓下来的原始弹幕不能直接用因为存在大量换行符、空白字符、繁体中文、emoji 表情以及一些需要过滤的特殊标记。比如弹幕里的{rainbow}表示彩色弹幕效果分析关键词时要去掉。另外B站弹幕里常有「空降」「打卡」这类词如果做高频词统计需要结合停用词表处理。清洗流程我放在 Python 层避免把垃圾数据写进 HDFSimport re import pandas as pd def clean_danmaku(df): # 去掉花括号特效标记 df[content] df[content].str.replace(r\{[^}]*\}, , regexTrue) # 去除多余空白 df[content] df[content].str.strip() # 去掉长度小于2的纯符号弹幕 df df[df[content].str.len() 2] # 转为字符串类型 df[content] df[content].astype(str) return df清洗之后我会把同一个视频的所有弹幕拼成一个 JSON 文件或者直接按天分桶写入 Parquet 格式。Parquet 的列式压缩比远远好于 JSON 和 CSV在 Spark 里查询速度快很多。实测同一个数据集JSON 格式占 4GB转成 Parquet 后只有 1.1GB查询速度提升约 3 倍。写入 HDFS 的方式很简单hdfs dfs -put /data/danmaku/parquet /warehouse/danmaku如果你习惯用 Python 操作 HDFS可以用hdfs这个库但更稳定的方式是先写本地临时目录再调用 HDFS shell 命令。原因是 Python 的 HDFS 客户端在某些版本上存在连接泄漏问题。3. Spark 分析核心实现3.1 数据分析的维度设计拿到清洗后的数据后要思考一个问题弹幕分析到底分析什么我最终确定了四个核心维度弹幕量趋势按天、按小时统计弹幕数量判断视频热度周期。高频词与热梗从弹幕内容里提取关键词找出观众讨论的焦点。用户活跃度统计用户 ID 的去重数量、发送频率识别核心粉丝。情感倾向对弹幕文本做简单情感打分区分正面、负面、中性。这四个维度刚好对应业务上最常被问到的几个问题。我用 PySpark 写分析任务是为了后续能无缝迁移到集群环境。3.2 弹幕高频词与热梗识别高频词统计最基础但在弹幕场景里有个问题弹幕短、口语化、错别字多、网络热词多。直接分词会得到一堆无意义的词语。我这里采用「先过滤停用词 再统计 n-gram」的方式。停用词表需要自己扩充除了常见中文停用词还要加入弹幕场景专用词「哈哈哈哈」「草」「来了」「前方高能」「泪目」等。这些词本身有意义但如果要分析具体话题它们会淹没真正的关键词。使用 Spark 做分词和统计的代码from pyspark.sql import SparkSession from pyspark.sql import functions as F from pyspark.ml.feature import Tokenizer, StopWordsRemover spark SparkSession.builder.appName(danmaku_analysis).getOrCreate() df spark.read.parquet(hdfs://localhost:9000/warehouse/danmaku) # 简单分词先用空格分隔因为清洗阶段已把弹幕按字符处理 # 这里使用 jieba 分词可以通过 pandas UDF 调用但为了性能我直接按字切分 tokenizer Tokenizer(inputColcontent, outputColwords) words_df tokenizer.transform(df) # 停用词过滤 remover StopWordsRemover(inputColwords, outputColfiltered) filtered_df remover.transform(words_df) # 展开词并统计 result filtered_df.select(F.explode(F.col(filtered)).alias(word)) \ .groupBy(word) \ .count() \ .orderBy(F.col(count).desc()) result.show(20)这里要注意直接用Tokenizer会把「哈哈哈」当一个词也会把「awsl」当一个词效果比 jieba 差一些。如果你对结果要求高可以注册一个 jieba 分词 UDFfrom pyspark.sql.types import ArrayType, StringType import jieba F.udf(returnTypeArrayType(StringType())) def jieba_cut(s): return list(jieba.cut(s))但 UDF 在数据量大时会很慢建议先缩采样测试再全量跑。我最后的方案是先做一次高频词粗筛再对高频词的上下文做 n-gram 分析找出「双字词 双字词」的组合比如「永远」「的神」这种梗。3.3 弹幕时间分布与用户活跃度分析弹幕时间分布可以拆成两个维度视频内时间点和自然时间。视频内时间点能反映作品的节奏感比如「开头 30 秒弹幕密集」说明前奏抓人自然时间点能反映观众的作息规律比如晚上 10 点是发弹幕高峰期。代码实现from pyspark.sql.functions import from_unixtime, hour, minute df df.withColumn(dt, from_unixtime(F.col(ctime))) \ .withColumn(hour, F.hour(dt)) \ .withColumn(video_sec, F.col(progress).cast(int)) # 自然小时分布 hour_stats df.groupBy(hour).count().orderBy(hour) # 视频内时间分布按每10秒分桶 df df.withColumn(bucket, (F.col(video_sec) / 10).cast(int) * 10) bucket_stats df.groupBy(bucket).count().orderBy(bucket)用户活跃度分析就是按用户 ID 去重统计还可以算每个用户的弹幕数量分布识别「弹幕狂魔」。这里有个隐私注意点B站弹幕 XML 里的用户 ID 是经过 hash 后的字符串并不是真实 UID所以分析结果不会泄露真实用户信息。我们只需要将这个 hash 值作为用户标识即可。3.4 情感倾向初探情感分析是弹幕分析里最有意思但最难做准确的部分。弹幕语言高度依赖语境比如「就这」可以是贬低也可以是调侃。我这边用了一个非常朴素但可用的方法构建正负面词典对每条弹幕的情感词打分。词典我直接用了开源的通用中文情感词典再结合弹幕场景扩充了「绝了」「泪目」「破防」「yyds」「tql」等词。打分的时候用 PySpark 的when条件累加pos_words [绝了, 泪目, 破防, 好看, 喜欢, yyds, tql, 神仙, 爱了] neg_words [烂, 垃圾, 弃了, 无语, 差评, 恶心, 血压] def sentiment_score(text): s 0 for w in pos_words: if w in text: s 1 for w in neg_words: if w in text: s - 1 return s sentiment_udf F.udf(sentiment_score, int) df df.withColumn(score, sentiment_udf(F.col(content))) # 统计比例 sentiment_stats df.withColumn(sentiment, F.when(F.col(score) 0, positive) .when(F.col(score) 0, negative) .otherwise(neutral)) \ .groupBy(sentiment).count()注意这种词典法只能作为粗粒度参考想要更细的语义情感需要微调中文预训练模型但那样整个项目的计算成本就会高很多。作为实战项目用词典法先把流程跑通已经能看出大致的情绪分布趋势。4. 可视化系统搭建4.1 架构模式与接口设计分析结果最终要以可视化的方式呈现。我选择用 Flask 作为后端服务ECharts 作为前端图表库。后端通过 API 返回 JSON 数据前端页面用 AJAX 拉取。整体分成三层数据服务层Spark SQL 查询结果导出成 Parquet 或直接读 HDFS 上的聚合表。后端 API 层Flask 提供/api/trend、/api/hotwords、/api/sentiment等接口。前端展示层HTML ECharts动态渲染图表。为什么不用 Django因为这里后端逻辑比较简单Flask 更轻。如果你未来打算加用户权限、后台管理再迁移到 Django 也不迟。接口返回格式统一为{ code: 0, data: { categories: [00:00, 01:00, ...], values: [12, 20, ...] } }这样前端基本不用处理复杂结构直接绑定到 ECharts 的 series 里。4.2 大屏看板实现大屏看板是这套系统的门面我实现了以下模块顶部指标卡展示总弹幕数、视频数、用户数、今日弹幕增量。中间主体弹幕量趋势折线图支持按小时和按天切换。左侧面板高频词 Top30 词云。右侧面板弹幕情感分布饼图以及用户活跃度排行条形图。底部区域视频内弹幕时间密度热力图。用 ECharts 写大屏的要点是「自适应布局」。我用了简单的 flex 布局通过监听 window.resize 事件刷新图表。如果你用的 ECharts 5可以开启media特性。一个核心点多个图表同时请求数据时容易造成接口拥堵。我在前端做了 Promise.all 聚合请求后端也开启了 Flask 多线程from flask import Flask, jsonify from flask_cors import CORS import json app Flask(__name__) CORS(app) app.route(/api/overview) def overview(): # 从预聚合结果读取 data load_overview_data() return jsonify({code: 0, data: data})后端读取的聚合结果我建议在 Spark 任务跑完后把每组统计结果分别写成小体积 JSON 文件Flask 启动时加载到内存。这样请求响应基本在毫秒级而不是每次查 Hive 或者查 HDFS。4.3 关键图表与交互高频词词云用的是 ECharts 的 wordCloud 扩展。ECharts 官方仓库里有词云插件直接引 JS 文件即可。如果部署环境不能访问外网需要把静态文件本地化。弹幕量趋势我用了双折线一条是弹幕总量另一条是去重用户数。两条线放在同一坐标系中能直观看出「弹幕涨了是否真的因为更多人参与」。视频内弹幕密度热力图我把进度按 10 秒分桶横轴是视频进度纵轴是视频分 P 序号颜色越深代表弹幕越密集。这种图最适合对比「第几集最精彩」。交互方面我做了一个简单的筛选器左边选择视频分区如动画、游戏、音乐右侧所有图表联动刷新。前端代码不复杂就是点击事件里重新请求数据function refreshAll() { const region document.getElementById(region).value; Promise.all([ fetch(/api/trend?region${region}).then(r r.json()), fetch(/api/hotwords?region${region}).then(r r.json()), fetch(/api/sentiment?region${region}).then(r r.json()) ]).then(([trend, hotwords, sentiment]) { renderTrend(trend.data); renderHotwords(hotwords.data); renderSentiment(sentiment.data); }); }这里有一个体验细节每次切换筛选器如果数据量较大前端会白屏卡顿。解决办法是先用一个 300ms 的防抖函数等用户停止连续操作后再请求。另外图表更新时不要直接用setOption的全量参数改用merge方式合并更新性能更好。5. 常见问题与排查笔记5.1 数据采集被限制B站对爬虫的识别越来越严格。最典型的报错是请求弹幕接口返回-412状态码表示被风控拦截。我在实际项目里主要通过三个手段规避降低请求频率、设置随机 User-Agent、使用 cookie 池。如果发现 IP 被限制最简单的办法是等几分钟再抓或者通过代理更换出口 IP。但我不建议大规模使用代理因为稳定性差而且代理 IP 质量参差不齐。更好的思路是先抓取视频元数据再根据 cid 分批发弹幕请求每批 1000 个请求休息 5 秒。另外弹幕接口有segment_index参数用来分页获取大视频的弹幕。早期很多教程没提这个导致只能抓到前 600 条弹幕。我当时也是踩了这个坑才注意到老视频弹幕量多必须循环请求每一段for segment in range(1, 20): url fhttps://api.bilibili.com/x/v1/dm/list.so?oid{cid}segment_index{segment} # 解析并拼接如果某段返回为空就可以停止循环这是一个常见的终止条件。5.2 Spark 数据倾斜与 OOM跑高频词统计时遇到最典型的性能问题是数据倾斜某些热词比如「哈哈」的量级远超普通词导致单个 reducer 任务运行极慢。我在 4 核虚拟机上跑 1200 万条弹幕有一个 reducer 跑了 15 分钟还没结束。解决办法有两个方向。第一对高频词统计做两阶段聚合。先在 map 端本地聚合一次再对结果做 shuffle 聚合。Spark 的groupBy自带 Combine 操作但如果你用groupByKey就要小心。第二对可疑热词加随机前缀打散最后再去掉前缀聚合。代码示例from pyspark.sql.functions import concat, lit, rand, regexp_replace # 先加随机前缀0~9 df df.withColumn(word_prefix, concat((F.rand() * 10).cast(int), lit(_), F.col(word))) # 聚合后去掉前缀再聚合一次 stats df.groupBy(word_prefix).count() stats stats.withColumn(word, regexp_replace(word_prefix, ^[0-9]_, )) \ .groupBy(word).agg(F.sum(count).alias(count))OOM 则一般发生在读取 HDFS 大文件后做collect()的时候。注意 Spark 中collect()会把所有结果拉到 Driver数据量大时必然爆。我的习惯是只在最后输出 Top N 时才用collect()中间结果都写入 HDFS 或本地文件。如果你需要把结果传到 Flask终端输出 JSON 文件后通过共享目录读取。5.3 可视化性能优化如果前端同时展示数千个点ECharts 渲染会卡顿。实际弹幕趋势按小时统计后有 24 个点按天统计有几十个点问题不大。但词云如果展示 100 个词每一个词渲染成一个图形在低端设备上可能会有明显卡顿。解决办法是只展示 Top 50并且词云组件开启drawOutOfBound为 false。另一个容易被忽视的问题是时区。Spark 里from_unixtime默认的是本地时区如果你的服务器是 UTC而你人在东八区统计出来的小时分布整体会偏移 8 小时。解决办法是在 Spark Session 初始化时设置spark SparkSession.builder \ .config(spark.sql.session.timeZone, Asia/Shanghai) \ .getOrCreate()建议一开始就加上这个配置不要等到看数据不对劲了再排查。后端接口响应时间如果超过 2 秒多半是每次请求都在重新计算指标。我最终的方案是Spark 任务定时跑产物落地为每小时的快照 JSON。Flask 只读快照不直接跑 Spark。这样实时性虽然降低了一些但交互体验大大提升。如果你需要接近实时的效果可以考虑引入 Redis 做缓存层。写在最后我的个人体会与建议整个项目从零到跑通我大概花了两周时间。中间最耗时的不是写代码而是调数据质量。B站弹幕里的梗、缩写、表情符号远比想象中复杂想要分析结果有说服力清洗环节必须花大力气。我后来养成了一个习惯把清洗规则沉淀成一个 Python 文件每次拿到新数据先跑一遍采样人工看 100 条清洗结果确认没有明显问题后再批量处理。另一个建议是不要一上来就追求炫酷的可视化界面。先把 Spark 分析任务的数据结果用命令行打印出来确认数值合理再考虑画图。如果分析结果是错的再好看的图表也只是精致的垃圾。如果你打算往更深处扩展可以在现有基础上加两块内容一是接入实时流处理用 Spark Streaming 或 Flink 消费 B站直播弹幕二是引入更细致的 NLP 模型做弹幕语义角色识别比如区分「刷梗弹幕」和「真实观点弹幕」。这两个方向都能让系统的分析价值提升一个档次。最后分享一个小技巧开发阶段尽量用「小数据 本地模式」跑通流程比如只抓 10 个视频、5000 条弹幕用spark.masterlocal[*]调试。确认逻辑无误后再用 YARN 模式跑全量数据。这样能省掉大量排队等待时间也能让你更专注于核心分析逻辑。