从 Bilibili Analyzer 到云边大数据框架：Kafka、HDFS、Spark 与 Hive 实践

这次想把什么跑起来

Bilibili Analyzer 最初解决的是公开视频数据的采集、热度分析和内容观察。继续做下去以后，我想借它实践一套完整的大数据运行环境：从 Linux 开始，自己搭建并串起 Kafka、HDFS、Spark 和 Hive。

这次扩展不是为了给原项目增加一个单独的产品功能，而是为了理解数据链路、组件配置和运行维护。云端负责持续采集和保存数据；边端在具备运行条件时启动大数据组件，完成整理、计算和结果回传。

为什么用了云边结构

边端 Ubuntu 装在移动硬盘上，不会一直在线。它偶尔上线的特点，构成了一个真实的边端约束：云端不能因为边端不在线就停止采集，边端再次上线后则需要接住之前积累的批次，继续完成处理。

这样就不只是安装组件。任务交接、数据分层、结果回传和故障恢复都会变成需要实际处理的问题。

这次已经验证的部分

V1 已完成并验收了从云端批次、Kafka、HDFS Bronze/Silver/Gold、Spark/Hive 计算，到结果回传和故障恢复的完整流程。移动硬盘上的 Ubuntu 作为边端，上线后启动运行环境并处理积压批次。

一次实际的 503 演练

一次 Gold 结果回传时，Spark 已经完成分析，但 Agent 上传结果时云端返回 HTTP 503。任务停留在 UPLOADING 状态。

Agent 没有重新执行 Spark，而是把结果文件、重试次数和下一次重试时间持久化到本地 SQLite/spool。Agent 重启后读取这份状态，只继续上传结果。

云端使用 run_id 和 result_version 做幂等校验。最终结果只发布一次，没有丢数据，也没有产生重复结果。

这次演练让我确认了两件事：计算完成和结果发布可以分开恢复；上传重试不会把一次任务变成多份结果。

接下来继续补什么

下一阶段会继续补监控、告警和更长期的运维能力，包括任务状态、采集链路、计算失败和结果回传的可观测性。

组件职责、数据流和恢复状态已整理到 云边大数据框架实践，项目的完整说明在 Bilibili Analyzer 项目页。