简介:本文是数据存储类论文如何写与舆情方面毕业论文题目范文.
数据存储方案
舆情监控平台的核心价值,就是能够提供快速精准的信息检索,并且舆情系统的使用场景具有以下特点：
实时数据价值更高
舆情数据传播趋势特征明显,人们关注的信息大部分集中在7天之内,且信息采集呈现的及时性,往往是分钟级的.
信息检索维度灵活
客户信息筛选的维度是多样的,如根据量、性别、文章段落等.
检索业务处理集中
舆情平台的检索压力有明显的特征曲线,工作时间负载压力大,早晚高峰报告查询集中.
1、选型发展
信息检索是舆情系统的核心需求,基于 Lucene 的全文检索引擎是实时数据检索的组件首选,早期我们使用 Solr,但是 Solr 依赖外部组件协调（ZooKeeper）,运维成本很高.2015年,我们引入ElasticSearch（ES）作为平台的底层数据库,提升了舆情数据存储集群的运维效率,也提高了平台存储的稳定性.随着业务发展,数据量越来越大,即使是已经按照业务拆分的集群隔离也已经不能满足业务查询的性能要求,2017年底,我们做了大幅底层集群优化和硬件升级,从业务集群隔离拓展到多集群、多索引的混合集群模式.伴随产品维度和数据量的增长,2018年我们将 HBase 作为非索引大字段的底层存储,引入基于 Ceph 底层的 OSS 对象数据存储引擎,支撑图片、音视频的存储;架构升级后,支持伴随业务的灵活可扩展的缓存多集群方案.
2、存储架构
数据写入
通过数据流计算完成的标准数据,通过 Data Pipeline 同步写入 全量数据仓库和ES准实时索引集群,ES 集群存储文本索引字段,构建倒排索引,文档关联的原始 HTML 和 资源（如图片、视频）,分别存储到 HBase和 OSS 对象存储平台,构建ES 文档关联.
业务拆分
按照业务划分,对实时数据敏感的客户,热数据通过 ES 准实时索引构建检索结果,能够做到数据采集到UI呈现低于 30 秒的业务体验,对于预警时效敏感的客户,系统将信息准实时推送给客户,但这部分客户牺牲了一部分的化干预功能,如情感标签的定向优化.
对大部分客户,我们根据业务规则分组,将客户的专题规则,经由计算中心,同步计算到可扩展的 ES 业务缓存,这样做到客户专题级别的存储隔离,大幅提高信息检索的性能,同时,在同步计算节点,我们嵌入了可插拔的规则引擎计算插件,可以二次干预标签或者附加值计算,给定点客户提供了更优的数据分析体验,通过不断集群调优和算法改造,实时计算上万客户的全部专题,UI 数据呈现目前已经能做到延迟小于3分钟.
离线备份
舆情客户数据具有鲜明的时间属性,历史数据关注度和分析价值不高,因此我们对数据除了 T+1 的同步备份外,线上实时 ES 集群只保留最近2年的数据,保证的集群的性能不随数据增量衰减,同时,离线备份的数据,同时用于定期的数据统计任务,服务于舆情分析师,作为长周期报告的数据分析来源.
存储架构的升级和变迁,很大程度上是伴随着系统的负载压力和不断增长的数据和客户增量,不断迭代演进的,通过空间换时间,我们目前已经构建了一个超过200个 ES 节点的多集群架构,支撑每天几十TB级的数据增量,以及上万客户的复杂舆情检索和计算.
检索优化方案
尽管我们使用 ES作为全文检索的核心引擎,无论数据索引和简单查询,都能做到很好的性能支撑,但是舆情检索有一定的特殊性和复杂性.
检索精度要求
舆情服务的客户,对于数据检索具有高召回的要求,通过关键词检索,任何匹配关键词、或匹配关键词组合的数据,都应该被及时检索并呈现,但中文语法复杂,对于歧义、包含等语义情况,常常存在分词造成的误差,导致检索召回率降低,造成客户投诉.
检索性能要求
舆情信息检索过程中,相似文章需要默认折叠,以分页形式展示到前端,而数据实时入库,我们要求折叠数据的计算是实时的,虽然 ES 聚合（aggregation）性能随着社区发展不断优化,但其仍不能很好的处理亿级数据的分页聚合需求,尤其面对超过上千复杂关键词逻辑时,性能会变得更差.
数据相关性要求
舆情检索是要发现价值信息,而 ES 自身的评分机制,并不能完整反映互联网公开数据的权重,比如权重大的网站发布的文章、传播量大的文章,或者负面倾向大的文章,往往需要排在数据呈现的前面,即数据的相关性,我们需要做二次的.
业务灵活性要求
为了让信息检索更灵活,我们设计了一套复杂的检索语法,如：或、与、非、距离、字段、嵌套检索等,同时一个检索,还需要加入特定的规则干预,如数据定向、黑白名单、屏蔽过滤等,各种附加的操作都对 ES 的检索带来巨大的复杂性.
针对上述种种问题,我们列举部分检索优化点供参考：
集群调优
1、内存参数优化
内存对于 ES 来说异常重要,单个数据节点,JVM 内存设置为 31GB（不超过32GB）,触发内存指针压缩技术,配置 G1垃圾回收器;同时,Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构,我们至少预留操作系统内存的一半作为 Lucene 的非堆内存,如果物理机内存小于 64G,给到 ES 节点的内存应该不超过内存的 50%;另外,内存交换到磁盘对服务器性能来说是致命的打击,一般会降低一个数量级,应该配置禁止内存交换.
2、动态分片设置
一个ES index 的分片,底层对应一个 Lucene 的索引文件,会消耗系统的文件句柄、CPU和内存资源,每个检索请求也会路由分类到每个分片,我们需要综合考虑查询请求的负载和分片的大小,合理设置分片的数量,因此在我们的 ES 集群管理中,每天的索引分片数是动态计算的（根据近期数据增量,预估当天数据量,调整创建索引的分片数量）.
3、定时段（segment）合并
ES 数据写入过程中,会产生大量的段文件,ES 每个分片的资源开销,取决于 segment 的数量,而通过段合并,将较小的分段合并为较大的分段,能减少开销并提高查询性能,但段合并是一项十分耗费性能的操作,我们应该关闭索引的自动段合并,在业务低峰时段做定时索引段合并.
硬件优化
尽量选配 SSD 硬盘,考虑到成本原因,可以结合业务场景,对业务检索有较高的性能要求的,建議使用 SSD 磁盘,检索不敏感的集群则使用普通磁盘.
同时,当 ES 集群上有大量的索引时,通过单节点配置多个挂载磁盘,能够让数据高效写入不同的磁盘,在硬件性能较差时,能显著提升数据写入的效率.
分词优化
我们知道ES 底层是基于分词的倒排索引,常见的开源中文分词器很多,如 ik 分词器、ansj 分词器、结巴分词器、hanlp 分词器等,但是针对精度要求非常高的舆情数据检索场景,上述分词器均存在不同程度的误差.
的是单个词汇单元,输出一个字母n-gram 词汇单元序列,而 Shingles 是将一个序列的词汇单元,输出一个单词级别的 n-gram 词组单元序列.
总结：上文点评：该文是关于舆情方面的论文题目可用作相关论文提纲和数据存储文献综述的参考文献.
舆情引用文献:
[1] 云计算和数据存储本科论文开题报告范文 云计算和数据存储方面有关在职研究生论文范文8000字
[2] 数据存储论文例文 数据存储类有关毕业论文的格式范文5000字
[3] 云端毕业论文的格式范文 关于数据存储和在云端方面学年毕业论文范文2万字
