B站每天需要处理海量数据——包括27万个离线任务、约2万个Ad-hoc查询以及7000个实时业务，这一切背后都依赖一套庞大的大数据平台来支撑。然而，随着规模不断扩大，各类问题也随之而来：任务频繁失败、运行速度缓慢，用户天天前来咨询，团队每周需要应对上千条问题，每个小团队仅答疑一项就要耗费3人天的工作量。如何破解这一难题？他们研发了一款基于大模型的智能诊断助手，效果显著。今天就来深入剖析这套方案的来龙去脉。
01 背景介绍
1. 整体架构和规模
B站的大数据平台整体采用“五层一体”配合“存算分离”的架构。底层是分布式文件系统，中间设有智能调度层，上层运行着Spark、Flink等多种计算引擎，同时整合了实时数据流Kafka、OLAP引擎ClickHouse，以及一系列自建工具和CI/CD平台。
平台的任务量究竟有多大？每天有27万个离线任务、约2万个Ad-hoc查询，以及7000个关键实时业务。如此庞大的体量，自然带来了大量用户咨询——每周超过千条，每个小团队平均需要投入3人天专门回答“任务为什么失败”“为什么变慢了”这类问题。过去，团队不得不安排一位全职人员处理咨询，效率可想而知。
2. 用户的问题
关于离线计算，用户最关注的始终是两点：任务为何失败？任务为何变慢？
（1）任务为什么会失败
- 系统内核的缺陷。有时系统内核升级后，任务未经过充分测试，导致大规模故障。
- 依赖组件的问题。平台数据量庞大、组件众多，任务之间彼此依赖。一旦某个依赖组件升级或出现bug，整个链条就会断裂。
- 数据质量问题。输入数据本身存在缺陷，任务自然会随之失败。
当然，内存相关的问题、资源争抢等也可能导致任务失败。原因五花八门，排查起来极为困难。
（2）任务为什么会变慢
- 硬件老化。硬盘寿命有限，后期读写速度会变得非常缓慢。B站数据磁盘数量巨大，这一现象尤为突出。
- 资源调度问题。用户量增长带来调度压力激增，加上混合部署机制，资源会在不同部门之间动态调整，潮汐时段任务容易受到影响。
- 数据分布问题。数据倾斜或本身存在异常，也会拖慢任务执行速度。
任务失败或变慢的原因如此复杂，靠人工逐一排查简直难以承受。因此，必须借助智能手段来辅助解决。
有趣的是，用户提问往往非常“工程化”——通常是一个链接加一句话，顶多再附带一张截图。这种碎片化的信息，恰恰是大模型最擅长的处理场景。
