܄

百分点大数据技术团队:互联网舆情系统的架构实践

【数据猿导读】 伴随着互联网技术的发展和新媒体创新应用,人们越来越倾向于通过微博、微信、短视频等社交媒体,表达看法,传播诉求,分享信息、甚至建言献策,收集、处理、挖掘其中的价值,洞察观点、情绪、口碑、社情民意,不仅能够为企业提供商业情报,辅助商业决策,还能为政府机构挖掘社情舆论,提...

百分点大数据技术团队:互联网舆情系统的架构实践

编者按

现代社会是一个信息驱动的社会,每天都有大量的信息产生。据统计,互联网上每天有数十亿条媒体文章产生,在线信息检索超过500亿次。伴随着互联网技术的发展和新媒体创新应用,人们越来越倾向于通过微博、微信、短视频等社交媒体,表达看法,传播诉求,分享信息、甚至建言献策,收集、处理、挖掘其中的价值,洞察观点、情绪、口碑、社情民意,不仅能够为企业提供商业情报,辅助商业决策,还能为政府机构挖掘社情舆论,提升社会治理水平。本文将主要围绕 SaaS 3.0时代,互联网公开数据信息挖掘的特点和趋势,阐述舆情分析系统的架构和实践。

1.舆情分析的业务特点

1.1  信源覆盖广

舆情分析的数据源几乎覆盖所有互联网公开信息,如常见的资讯网站和社交媒体:新华网、腾讯新闻、百度贴吧、论坛、新浪微博、微信、博客等,近几年兴起的自媒体平台和短视频等流媒体应用:小红书、抖音、快手等,人们有更多的渠道可以发声,新时代人人都是自媒体,同时,外媒也是众多跨国公司和政府机构关注的重点,境外主流新闻网站如华尔街日报、纽约时报等和社交媒体如 Facebook、Twitter,甚至 Tik Tok 等,这些舆论阵地都是舆情分析需要覆盖的渠道。

1.2  需求行业多

舆情分析的需求几乎涵盖所有行业,互联网时代,信息传播迅速,网络热点事件频发,企业最怕的就是出现各种不良舆论,危及企业运营,损害品牌形象,舆情监测服务被广泛应用于消费品、汽车、互联网金融、地产、教育、餐饮等行业,同时,在电子政务领域,舆情监测服务也为各级政府机构,提供第一时间的舆情资讯,舆情涉及我们生活的方方面面,舆情监测和管理,核心是对我们周围互联网公开信息的大数据分析和价值挖掘。

1.3  社会价值高

舆情分析服务能为目标客户提供多维度的信息挖掘和高附加值的洞察分析,具有巨大的企业和社会价值:

负面信息挖掘:负面信息发现,是舆情监测的核心价值点,如果不能及时准确地发现负面信息,造成负面舆论发酵,可能对企业带来不可挽回的损失,对政府带来严重的公信力质疑。

竞品信息监测:无论是企业市场人员,还是产品经理,竞品分析都是门必备的通用技能,通过对现有或潜在的竞争产品或者企业进行信息监测、情报挖掘,分析优劣势,往往能帮助企业掌握竞争的主动权。

口碑信息挖掘:针对自身或竞品,进行有针对性的口碑监测,如一款产品的评论分析,可以帮助企业改进产品功能、辅助市场营销策略,提升客户或产品满意度。

事件脉络分析:无论对于互联网热点事件还是产品传播营销,通过对事件细粒度的传播分析,洞察事件发酵脉络,挖掘传播爆点,掌握事件传播路径,为事件处置或营销效果分析提供决策依据。

民生民意调查:通过对互联网事件的舆论监测,挖掘对于互联网事件的公众情绪、公众观点、意见领袖、传播路径,为政府舆情引导、舆情管控提供决策辅助。

1.4  技术挑战大

舆情监测系统,不仅需要具备强大的数据采集和处理能力,还需要具备强大的价值挖掘能力,构建强大的舆情监测系统,往往面临巨大的技术挑战。

数据全面:针对海量的互联网信息,构建强大的数据采集系统,保证数据全面、不遗漏,是舆情监测能力保障的基础。

检索精确:舆情系统能够代替人工精准检索目标数据,这对海量数据的全文检索提出很高的要求,不仅要找到匹配的信息,还要去除干扰,最大化匹配检索意图。

预警及时:舆论环境瞬息万变,企业和政府都期望第一时间掌握舆情动态;舆情监测需要提供7&24小时、近实时信息预警,具备秒级采集、处理、研判和下发机制。

精准研判:除数据采集全面、数据处理及时外,信息挖掘研判的准确性往往是衡量服务竞争力的重要指标,通过不断提升敏感信息研判和相似度判定的准确性,可以最大化降低系统误判率。

标签丰富:除了基本的舆情大数据全流程处理,舆情系统还应该具备更深层次的信息挖掘能力,如标签提取、地域甄别、信息分类、事件发现等,最大化提升附加值挖掘能力,降低人工服务成本。

2.舆情发展的新趋势
 
2.1  精细化运营,实现弯道超车

互联网舆情行业发展多年,玩家众多,传统的舆情分析,场景模式相对固定,竞争趋于白热化;而舆情分析的细粒度需求,如负面关注度、文本相关性等,越来越趋于差异化和定制化,在 SaaS 标品的模式下,如何针对不同的行业客户、不同的分析场景实现平台化、精细化的运营,变得越来越重要,打造业务闭环、构建能够实现差异化运营的平台化产品矩阵,才能实现弯道超车。

2.2  智能化分析,AI 深度应用

舆情分析是 NLP 文本分析的天然阵地,随着近几年AI发展进入快车道,各种技术框架和分析手段层出不穷,为舆情信息挖掘提供了丰富的工具,不仅局限于分词、实体识别、情感判定、关键词提取等底层文本分析技术,诸如主动事件发现、智能化预警研判、智能化信息检索等逐渐落地应用。同时随着 AIOps 的发展,模型算法的工程化落地加速,探索用 AI 代替传统舆情服务中的人工部分,以降低成本。

2.3  业务模式创新,拓展深度和广度

舆情业务模式创新,不仅要横向扩展行业,积累各领域知识,形成不同行业的差异化专业解决方案,还要纵向探索新的分析场景,如针对 KOL 的细粒度监测、针对短视频等流媒体的信息挖掘等,与时俱进,不能禁锢在传统的舆情思维之中。

3.舆情信息的挖掘过程

3.1  基于实时数据流的数据挖掘

互联网舆情,本质上是对互联网公开信息的采集、分析、研判,并产生业务价值,是一个价值数据挖掘的过程,但基于其业务场景和系统要求,与传统的数据挖掘又有很大差别。

传统的数据挖掘任务,一般有如下几个过程:

信息收集 - 数据集成 - 数据加载 - 数据清理 - 数据变换 - 数据挖掘过程 - 模式评估 - 知识表示

ETL阶段进行数据清洗和标准化,挖掘过程综合运用各种信息挖掘算法,如规则推理、机器学习模型、迁移学习算法等,根据模式评估结果,得到反馈,不断循环,达到最优。但在舆情场景下,数据要从互联网源源不断的输入,分析结果要准实时的输出呈现,价值挖掘过程穿插于信息流之中,同时,系统需要具备动态干预的能力,甚至需要设计单独的指标回算机制,保证信息挖掘的前后一致性,如下图所示:

百分点_大数据技术_互联网舆情-1

信息以流式输入到在线处理引擎,经过 ETL 处理标准化的数据,进入数据挖掘过程,如基于规则引擎计算文本指标、通过机器学习算法模型计算文本标签等,这些规则或模型蕴含业务知识,数据计算结果经过存储,呈现给业务人员,后续随着业务的评估和迭代,挖掘中的业务知识会被动态干预,形成知识流动迭代的闭环。

因此,传统的数据挖掘过程,往往是静态的一次性过程,而舆情分析的信息挖掘,是一个流动的不间断过程。

3.2  多工种协作的业务闭环

同时,舆情监测体系的运行,也是一个多方共同参与的过程,不同角色的人员共同协作,不断迭代产生更优的价值挖掘结果,准确及时地呈现给终端客户。

百分点_大数据技术_互联网舆情-2

简单来看,舆情监测系统,主要由数据采集、SaaS 平台、运营工具栈构成。

销售、售前人员负责方案制作、需求转化,客户成单,需求确定后,由数据运营人员跟进,负责客户全生命周期的数据、关键词配置管理、数据监控,客户数据实时进入数据挖掘平台,供舆情分析师团队和客户直接使用,如数据筛选、数据预警、报告制作、信息挖掘分析等。

同时,我们还需要提供丰富的运营分析工具栈,如数据清洗、报告制作、预警干预、数据宏观分析、观点挖掘、事件发现等运营工具,帮助舆情分析师制作人工报告,提供高效率的人工服务。

需要指出的是,在整个舆情服务过程中,舆情监测系统需要能够实时收集业务知识,并反馈到信息挖掘平台,不断优化和提升 SaaS 平台的信息挖掘能力和水平。

舆情分析师的业务经验:舆情分析师是人工服务的价值输出方,能够深刻理解客户的监测需求,沉淀下来的业务知识,将直接录入挖掘平台,动态干预定向客户的分析效果,如客户的定制化负面评价指标、客户的定制分析词库等。

终端用户的行为反馈:系统应该能够自动收集用户的行为数据,以最大限度地降低用户的额外工作,提高系统迭代的效率,如数据的收藏行为、数据的屏蔽行为、数据的浏览行为等。

概括来讲,舆情分析系统是一个基于实时流动信息、多方协作参与的价值信息挖掘平台。

4.舆情系统的架构实践

4.1  基础架构分析

舆情监测系统,可以看做是一个价值信息挖掘的平台体系,重点是两个能力的建设:

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

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

简化版的舆情系统基础架构如下:

百分点_大数据技术_互联网舆情-3

整个架构分为两个层次:

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、移动端、微信小程序等;同时,我们还构建了面向舆情运营分析师的多工种协作平台,将舆情服务的全流程拆解、工具化,提供了支持众包的客户运营、数据清洗、报告制作、预警下发、价值挖掘等独立的工具平台,支持近百人的同时在线协作。

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

4.2  数据流处理方案

基于舆情业务特点,数据处理需要满足以下要求:

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

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

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

百分点_大数据技术_互联网舆情-4

如图所示,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 为例:

百分点_大数据技术_互联网舆情-5

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

使用 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 机制还能自动优化执行逻辑,将并行度一致的算子转化为线程内的方法调用,减少网络通信,提高运行效率。

除了 Flink 自带的任务资源管理,我们还进一步丰富了 Flink 在YARN Session 级别的监控维度,接入 Grafana:

百分点_大数据技术_互联网舆情-6

4.3  数据存储方案

舆情监控平台的核心价值,就是能够提供快速精准的信息检索,并且舆情系统的使用场景具有以下特点:

实时数据价值更高:舆情数据传播趋势特征明显,人们关注的信息大部分集中在7天之内,且信息采集呈现的及时性,往往是分钟级的。

信息检索维度灵活:客户信息筛选的维度是多样的,如根据微博粉丝量、性别、文章段落等。

检索业务处理集中:舆情平台的检索压力有明显的特征曲线,工作时间负载压力大,早晚高峰报告查询集中。

(1)选型发展:

信息检索是舆情系统的核心需求,基于 Lucene 的全文检索引擎是实时数据检索的组件首选,早期我们使用 Solr,但是 Solr 依赖外部组件协调(ZooKeeper),运维成本很高。

2015年,我们引入ElasticSearch(ES)作为平台的底层数据库,提升了舆情数据存储集群的运维效率,也提高了平台存储的稳定性。

随着业务发展,数据量越来越大,即使是已经按照业务拆分的集群隔离也已经不能满足业务查询的性能要求,2017年底,我们做了大幅底层集群优化和硬件升级,从业务集群隔离拓展到多集群、多索引的混合集群模式,版本也升级到了 6.*。伴随产品维度和数据量的增长,2018年我们将 HBase 作为非索引大字段的底层存储,引入基于 Ceph 底层的 OSS 对象数据存储引擎,支撑图片、音视频的存储;架构升级后,支持伴随业务的灵活可扩展的缓存多集群方案。

(2)存储架构:

下图描述了简要的数据写入流程:

百分点_大数据技术_互联网舆情-7

数据写入:

通过数据流计算完成的标准数据,通过 Data Pipeline 同步写入 全量数据仓库 和 ES准实时索引集群,ES 集群存储文本索引字段,构建倒排索引,文档关联的原始 HTML 和 资源(如图片、视频),分别存储到 HBase和 OSS 对象存储平台,构建ES 文档关联。

业务拆分:

按照业务划分,对实时数据敏感的客户,热数据通过 ES 准实时索引构建检索结果,能够做到数据采集到UI呈现低于 30 秒的业务体验,对于预警时效敏感的客户,系统将信息准实时推送给客户,但这部分客户牺牲了一部分的定制化干预功能,如情感标签的定向优化。

对大部分客户,我们根据业务规则分组,将客户的专题规则,经由计算中心,同步计算到可扩展的 ES 业务缓存,这样做到客户专题级别的存储隔离,大幅提高信息检索的性能,同时,在同步计算节点,我们嵌入了可插拔的规则引擎计算插件,可以二次干预标签或者附加值计算,给定点客户提供了更优的数据分析体验,通过不断集群调优和算法改造,实时计算上万客户的全部专题,UI 数据呈现目前已经能做到延迟小于3分钟。

离线备份:

舆情客户数据具有鲜明的时间属性,历史数据关注度和分析价值不高,因此我们对数据除了 T+1 的同步备份外,线上实时 ES 集群只保留最近2年的数据,保证的集群的性能不随数据增量衰减,同时,离线备份的数据,同时用于定期的数据统计任务,服务于舆情分析师,作为长周期报告的数据分析来源。

存储架构的升级和变迁,很大程度上是伴随着系统的负载压力和不断增长的数据和客户增量,不断迭代演进,通过空间换时间,我们目前已经构建了一个超过200个 ES 节点的多集群架构,支撑每天 几十TB级的数据增量,以及上万客户的复杂舆情检索和计算。

4.4  检索优化方案

尽管我们使用 ES作为全文检索的核心引擎,无论数据索引和简单查询,都能做到很好的性能支撑,但是舆情检索有一定的特殊性和复杂性。

检索精度要求:

舆情服务的客户,对于数据检索具有高召回的要求,通过关键词检索,任何匹配关键词、或匹配关键词组合的数据,都应该被及时检索并呈现,但中文语法复杂,对于歧义、包含等语义情况,常常存在分词造成的误差,导致检索召回率降低,造成客户投诉。

检索性能要求:

舆情信息检索过程中,相似文章需要默认折叠,以分页形式展示到前端,而数据实时入库,我们要求折叠数据的计算是实时的,虽然 ES 聚合(aggregation)性能随着社区发展不断优化,但其仍不能很好的处理亿级数据的分页聚合需求,尤其面对超过上千复杂关键词逻辑时,性能会变得更差。

数据相关性要求:

舆情检索是要发现价值信息,而 ES 自身的评分机制,并不能完整反映互联网公开数据的权重,比如网站权重大的网站发布的文章、传播量大的文章、或者负面倾向大的文章,我们往往需要排在数据呈现的前面,即数据的相关性,我们需要做二次的定制。

业务灵活性要求:

为了让信息检索更灵活,我们设计了一套复杂的检索语法,如:或、与、非、距离、字段定制、嵌套检索等,同时一个检索,还需要加入特定的规则干预,如数据定向、黑白名单、屏蔽过滤等,各种附加的操作都对 ES 的检索带来巨大的复杂性。

针对上述种种问题,我们列举部分检索优化点供参考:

(1)集群调优

内存参数优化:内存对于 ES 来说异常重要,单个数据节点,JVM 内存设置为 31G(不超过32G),触发内存指针压缩技术,配置 G1垃圾回收器;同时,Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构,我们至少预留操作系统内存的一半作为 Lucene 的非堆内存,如果物理机内存小于 64G,给到 ES 节点的内存应该不超过内存的 50%;另外,内存交换到磁盘对服务器性能来说是致命的,一般会降低一个数量级,应该配置禁止内存交换(sudo swapoff -a)。

动态分片设置:一个ES  index 的分片,底层对应一个 Lucene 的索引文件,会消耗系统的文件句柄、CPU和内存资源,每个检索请求也会路由分类到每个分片,我们需要综合考虑查询请求的负载和分片的大小,合理设置分片的数量,一般推荐的分片大小是20 ~ 50G 之间,因此在我们的 ES 集群管理中,每天的索引分片数是动态计算的(根据近期数据增量,预估当天数据量,调整创建索引的分片数量)。

定时段(segment)合并:ES 数据写入过程中,会产生大量的段文件,ES 每个分片的资源开销,取决于 segment 的数量,而通过段合并,将较小的分段合并为较大的分段,能减少开销并提高查询性能,但段合并是一项十分耗费性能的操作,我们应该关闭索引的自动段合并,在业务低峰时段(如凌晨)做定时索引段合并。

硬件优化:尽量选配 SSD 硬盘,考虑到成本原因,可以结合业务场景,对业务检索有较高的性能要求的,建议使用 SSD 磁盘,检索不敏感的集群则使用普通磁盘,同时,当 ES 集群上有大量的索引时,通过单节点配置多个挂载磁盘,能够让数据高效的写入不同的磁盘,在硬件性能较差时,能显著提升数据写入的效率。

(2)分词优化

我们知道ES 底层是基于分词的倒排索引,常见的开源中文分词器很多,如 ik 分词器、ansj 分词器、结巴分词器、hanlp 分词器等,但是针对精度要求非常高的舆情数据检索场景,上述分词器均存在不同程度的误差。

ES 的索引字段(analyzed)的分析(analysis)过程如下:

百分点_大数据技术_互联网舆情-8

Character filter 阶段:字符过滤器主要以字符流的方式接收原始文本,经过干预转换,输出字符流,比如特殊字符过滤或者编码转化。

Tokenizer 阶段:即切词阶段,接收一个字符流 ,经过分词器切割拆分为多个 token,并输出一个 token 流。

Token filter 阶段:接收 token 流,通过配置的filter 算法,对每个token进行转化,比如小写转化、停用词删除、同义词引入等,ES也提供了多种预置的 过滤器。

这里需要解决的问题是分词准确性导致的检索召回率问题,比如我们要通过“微贷网”检索数据,无论采用 IK 分词器的 ik_smart 或 ik_max_word,都无法检索出下面这句:“微贷网费用有哪些?”

原因是在分词阶段,在分词词库不添加专有名词“微贷网”的情况下,分词 token 均不包含 “微贷网”,而是“网费”被单独分词,导致检索无法匹配。丰富词库不能对历史数据生效,并不适用舆情实时的数据检索场景。

我们的方案是调整分词,将修饰定制的ik_smart和 shingles Token 过滤器相结合。

Shingles 过滤器是一种特殊的词元过滤器,与N-Gram 不同的是,n-gram 过滤器针对的是单个词汇单元,输出一个字母n-gram 词汇单元序列,而 Shingles 是将一个序列的词汇单元,输出一个单词级别的 n-gram 词组单元序列。


Ik_smart 分词器定制,除了利用IK 分词器的各种中文定制词库外,将其改造为近似的按字标准分词器。

引入Shingles token filter(Word-based N-Gram 过滤器),对分词后的 token 做 N 字滑动切分,那么输入任何 N 个长度的检索词,均能保证该 term 被检索到,而衡量业务场景和索引存储,我们将 N 设定为2,入库的文章均做 2 字分词切分,保证了倒排索引的存储相对最优,同时约定检索关键词字符避免单字,在业务合理范围内,能够做到检索召回接近100%。

output_unigrams = False, 将 ik 分词结果和 shingles 结果分开存储,便于分别检索。

百分点_大数据技术_互联网舆情-9

(3)存储优化

索引拆分:

根据业务场景,做集群拆分,如评论口碑数据与新闻网站数据集群分离,因为这两个场景的业务逻辑不通,查询并发度和分析维度差异很大。

针对单一集群做时间滚动拆分,比如按天创建数据索引,每天一个增量索引,数据检索直接跨索引查询,如前所述,动态规划新建索引的分片数,将单分片的大小维持在 20 ~ 50G最佳。

字段拆分:

ES 是一个全文检索引擎,我们要将用于全文检索、聚合分析的索引存储到 ES,但一些大的文本字段,如 HTML 页面源码等,往往占用大量空间,ES 缓存本身非常宝贵,类似字段不仅会占用大量内存