舆情系统的架构实践

百分点大数据技术团队

舆情监测系统，可以看作是一个价值信息挖掘的平台体系。

基础架构分析

舆情监测系统重点如下：

资源构建能力 通过数据采集和信息挖掘，构建舆情系统的资源基础，形成标准一致的信息输出接口。

业务应用能力 依托底层的舆情资源，构建贴合场景的业务应用，既服务于舆情 SaaS 客户，还服务于人工分析师，输出专业能力的同时，帮助提升组织效率。

整个架构分为两个层次：a.资源层：整合数据采集、计算、存储，形成整体的舆情资产核心能力。b. 业务层：基于舆情场景，构建各种上层应用。具体情况如下：

数据采集层 依托百分点大数据采集系统，构建了超过1000个服务器节点的大规模数据采集集群，覆盖90%以上的全网公开价值信息;包括新闻、报刊、微博、微信、APP、论坛、博客、视频、Facebook、Twitter、短视频等近14个信源数据，本文我们不展开讲述采集系统的构建。

数据计算层 数据计算层承担着舆情数据处理的核心部分，除了采集数据的 ETL 过程，我们还构建了高效、智能的核心指标计算体系，通过高效的流式处理引擎，支撑文本、规则指标的计算，挖掘价值信息。

数据存储层 我们综合构建了适用于实时业务检索和离线数据拉取计算的存储架构，核心基于 ElasticSearch（ES） 和 Hbase 存储实时舆情数据，基于 HBase + Hive（HDFS）构建离线数据仓库，为上层业务分析、数据应用构建提供高效、统一的信息检索服务。

需要指出的是，基于舆情数据应用场景，我们不仅构建了超过100个数据节点的 lambda架构的大数据生态处理平台，支撑每天亿级数据的实时和离线处理，还依托百分点人工智能实验室，结合舆情数据应用闭环，构建了以 GPU 为硬件基础的深度学习文本算力平台，应用先进的迁移学习技术，服务于模型化的指标挖掘。

业务服务层 在业务层，我们将舆情的业务模块化，形成众多独立部署的微服务，将用户管理、话题管理、标签管理、数据检索、多维分析、标签分析等核心业务暴露为统一的 REST 接口，构建了多个调度中心，负责处理舆情报告、预警、数据处理、服务监控等服务。

技术栈主要以SpringCloud框架和容器云 Docker 虚拟化为主，底层基于 Kubernetes 做资源管理和服务编排，构建了超过 200个镜像节点的线上微服务集群，支撑每天近万用户的复杂检索和 API 调用。

业务应用层 我们构建了面向客户的舆情 SaaS 平台，为终端客户提供智能化的舆情监测、舆情分析、舆情报告、舆情预警、专题管理等便捷体验，支持 PC、移动端、微信小程序等;同时，我们还构建了面向舆情运营分析师的多工种协作平台，将舆情服务的全流程拆解、工具化，提供了支持众包的客户运营、数据清洗、报告制作、预警下发、价值挖掘等独立的工具平台，支持近百人的同时在线协作。

作为舆情系统的底层支撑，下面我们将简单分享我们在平台资源层的架构实践，即：高效的数据流处理架构、稳定的数据存储平台、完善的指标挖掘体系。

数据流处理方案

基于舆情业务特点，数据处理需要满足以下要求：a.数据处理高效：数据采集到数据持久化存储，中间的数据处理时间不能超过30s，最大限度保证舆情消息的及时性。b.数据处理稳定：舆情数据有明显的峰谷周期，夜间数据较少，白天出现多个信息波峰，同时互联网舆情事件具有突发性，数据处理平台需要具备削峰填谷的能力。c.开发运维方便：开发友好，运维简单。

百分点輿情实时流处理架构，伴随技术演进，经历了多个阶段。2015年，我们引入了 Storm 作为实时流处理引擎，当时已经能够支撑高效的数据流处理，但随着业务量的增长，计算节点的维护成本越来越高，复杂的业务流程也加大了研发运维的复杂度，硬件资源利用瓶颈时有发生。2019年初，我们最终引入 Flink 作为我们的核心流处理组件，全面升级到以 Flink 为中心的微批处理计算平台。

Storm和 Flink 都是流数据处理领域成熟的开源组件，但二者有着明显的区别，Storm 是基于拓扑（Topology）的无状态无限流处理平台，能够保证数据不丢失，但窗口函数等高级功能支持较弱;而 Flink 是一个统一了流处理和批处理的分布式数据处理引擎，除具备Storm 的高吞吐率、低延迟、可扩展、支持容错外，还支持非常灵活的窗口处理，同时有更好的反压机制，对于保证流处理的稳定性有很大的作用。

Flink 集群由 Flink Master、TaskManager 组成，Flink Master 中对应多个 JobManager，每个 JobManager 负责管理单个 Job 的调度和执行，而 Resource Manager 负责整个集群的内外部资源调度，Flink 可以支持嫁接在 Kubernetes、Mesos、Yarn 等资源调度管理系统之上，结合我们现有的大数据处理平台，我们使用 Yarn 作为我们 Flink 集群的底层资源管理系统。

逻辑上，算子（Operator）是 Flink 最基本的数据处理单元，一个 Job 是由一系列 Task 组成的 DAG，而每个 Task 中是由一个链式的 Operators Chain 构成，因此，我们将舆情数据处理中的数据清洗、标签计算、数据拉通等计算，从 Storm Topology 中的多个 Spout、Bolt 中迁移到重新设计细化的算子序列，让计算单元粒度更细、资源并发度更可控。

以其中一个<数据 Level1 清洗> Job 为例：

我们将数据清洗阶段的各步骤（类型转化、黑名单过滤、媒体来源归一、地域提取、消重）提取成独立算子，单独设置资源和并行度，并且针对全局只读的字典变量（如数据运营设置的网站黑名单、定期更新的网站媒体库、定期更新的标准地理库等），通过广播变量定期更新到各个算子，优雅的动态更新业务规则。

使用 Flink 集群的核心优势：

资源调度 采用统一的 Yarn 作为 Flink 资源调度，相比使用裸机的 Storm，大幅提高了资源利用率，同时使资源伸缩变得更方便。

新的 Flink 集群，在资源利用率持续控制在60%左右的情况下，物理机资源节约了50%，不仅节约了硬件成本，还提高了数据处理的能力。

Flink On Yarn 提供2种任务提交方式：a. Yarn Session：多 Job 共享一个 Flink 集群，YARN 资源共享;b. Flink Run ：独立 Job 独占 Yarn Session，任务间互不影响。

我们使用第二种方式提交，能做到更好的业务资源隔离和集群任务监控。

动态反压机制 Flink 提供比 Storm 更好的动态反压机制，能够动态感知被阻塞的 Operator，自适应地降低源头或上游数据的发送速率，从而维持整个系统的稳定。

针对舆情场景下的数据流量波峰波谷和不确定的热点事件，Flink 集群很好的平衡了数据流速，解决了 Storm 集群频发的高负载故障。

广播变量 Flink提供灵活的广播变量，通过将全局共享的数据广播出去，不同的任务在同一个节点上都能获取，数据只保存一份，相比于分布式缓存，节省了内存开销。

逻辑解耦 Flink 基于细粒度的算子链构建业务任务，把业务抽象成粒度足够小的算子，代码逻辑高度解耦。单个算子可单独配置并行度，其 Operator Chain 机制还能自动优化执行逻辑，将并行度一致的算子转化为线程内的方法调用，减少网络通信，提高运行效率。