一种高效的海量舆情数据信息集群匹配方法与流程

本发明涉及数据处理技术，特别涉及一种高效的海量舆情数据信息集群匹配方法。
背景技术：
：舆情信息，就是指在民众社会政治态度的收集、整理、分析、报送、利用和反馈的信息运动过程中，用以客观反映舆情状态及其运动情况的资讯、消息、音信、情报、指令、数据和信号。目前,网上可以获取很多互联网舆情信息,这些舆情信息对于企业来说都非常重要；舆情信息的正负面、转载量、阅读量、传播速度都时刻反应企业在公众心目中的形象。但是互联网舆情信息并没有关联是哪些企业发生负面舆论，所以很多企业都无法实时监控本企业在当前时段所有的舆情信息。目前，企业数量众多，而从网络上爬取的互联网舆情信息最多时达到每分钟多达上百条，同时企业信息又分为企业全称信息和企业简称信息，所以每条舆情信息都需要和这些企业的全称信息匹配；同时每一条舆情包括标题、转载量、内容等重要信息，而且大部分舆情信息有包含企业全称或者企业简称的内容都在舆情文章的中部或者尾部，所以这对于企业名称的匹配速度也是一大问题。而且匹配的速度必须严格控制在毫秒内，否则到最后会导致舆情信息堵塞，影响企业舆情信息的实时性。技术实现要素：为解决上述问题，本发明提供一种高效的海量舆情数据信息集群匹配方法，包括如下步骤：s100、将flume部署至各个舆情采集服务器上，并通过flume采集从互联网爬取的舆情数据信息；s110、将从flume采集到的舆情数据信息存储到kafka消息队列中；s120、从kafka实时消费舆情数据，并利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配；s130、将匹配成功后的关联数据信息展示到各个web系统上。进一步地，在步骤s110中将从flume采集到的舆情数据信息存储到kafka消息队列中，为了对企业舆情数据做离线数据分析，还包括：将从flume采集到的舆情数据信息同时存储到hdfs消息队列中。进一步地，在步骤s120中利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配时，把所有企业信息均加载至spark内存中。进一步地，在步骤s120中利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配时，若企业信息容量超过内存，则spark会保存至本地文件，再采用hash散列的算法把每个企业信息分发到不同的work中与舆情数据信息进行匹配。进一步地，在步骤s120中利用已部署的spark集群对匹配的舆情信息添加企业唯一标识，若匹配到多家企业则进行信息分裂，产生多笔关联信息。进一步地，在对企业信息处理前，对企业信息数据进行清洗处理。进一步地，步骤s100中根据数据量动态调整舆情采集服务器的部署数量。本发明提供的高效的海量舆情数据信息集群匹配方法，搭建了一个集群匹配架构来解决时效性差和匹配速度慢等情况，所以采用集群匹配方式，是因为单台服务器处理能力有限，所以匹配速度会很慢；而采用集群方式匹配时，可以把所有企业根据hash散列进行切分，然后分配到不同的服务器上，那么每个服务器所匹配的数量就相对减少，进而匹配速度和时效性就得到保障。测试结果表明，在采用该集群匹配方式后，从匹配速度、实时性上都有了很大的提高。附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。图1为本发明提供的高效的海量舆情数据信息集群匹配方法流程图；图2为本发明提供的高效的海量舆情数据信息集群匹配的架构示意图。具体实施方式为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本发明实施例提供一种高效的海量舆情数据信息集群匹配方法，如图1和图2所示，包括：s100、将flume部署至各个舆情采集服务器上，并通过flume采集从互联网爬取的舆情数据信息；本步骤中，优选地，可以根据数据量动态调整舆情采集服务器的部署数量，因为舆情数据可能存在很多台服务器，所以配置多个agent收集不同服务器的舆情数据，这里的agent可以动态增删，以保证及时采集各个服务器爬取的舆情数据；s110、将从flume采集到的舆情数据信息存储到kafka消息队列中；本步骤中，存储在kafka消息队列中的是实时数据，如果处理离线数据，则本步骤中还可以包括：将从flume采集到的舆情数据信息同时存储到hdfs消息队列中；保存至hdfs一份数据，是因为在不同场景下(舆情的匹配信息不用实时显示在web系统上时，可以采用离线的方式对数据进行分析，比如分析每个企业舆情的正负面的比率、分析舆情同比上个月和环比去年的数据，这些都可以用离线分析)，可以对企业舆情数据做离线数据分析，根据企业舆情信息的正负面、转载量等信息分析企业的健康状态；保存至hdfs是可选的，具体可以参考是否需要用于离线数据分析。如果需要离线数据分析，需要把舆情数据保存至hdfs，然后可以用离线分析工具hive或者spark-sql进行离线数据分析，如果只是实时分析，可以直接省略保存至hdfs的步骤；存在kafka中的主要目的是为了防止某个时间段舆情数据过多，导致第三步匹配的时候无法及时匹配，从而导致过多舆情数据阻塞无法及时匹配成功，所以用一个消息队列作为缓冲；s120、从kafka实时消费舆情数据，并利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配；选择spark集群的原因主要是spark集群是基于内存的计算模型，所以在企业信息和舆情信息匹配时是在内存中完成，匹配速度会非常快；优选地，本步骤中，在利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配时，可以把所有企业信息均加载至spark内存中，若企业信息容量超过内存，则spark会保存至本地文件；优选地，本步骤中，在利用已部署的spark集群对舆情数据信息和企业信息进行实时匹配时，还可以采用hash散列的算法把每个企业信息分发到不同的work中与舆情数据信息进行匹配；为了匹配的精确度和速度提高，在上述步骤中，对企业信息处理前，对企业信息数据进行清洗处理，比如把企业全称转换成企业简称、清洗简称比较通用的词语等清洗处理工作；s130、将匹配成功后的关联数据信息展示到各个web系统上。为了进一步详细解释说明提供的方法，下面以一个具体的操作实例进行说明。测试的企业总量为360万条，匹配的舆情信息为(一条舆情信息大概在5000字以上)：xxx企业拖欠工资。步骤1：准备工作：需要5台linux操作系统的物理机(最低配置5台),配置为16g内存，6核。步骤2：把flume安装至各个舆情采集服务器，然后配置source、channel、sink,其中sink配置为hdfs推送路径和kafka推送路径步骤3：安装hadoop环境，两台安装namenode,三台安装zookeeper,五台安装datanode,主要配置如表1所示：表1host1host2host3host4host5namenodenamenodezookeeperzookeeperzookeeperyarnmanageryarnmanagernodemanagernodemanagernodemanagerkafkakafkakafkadatanodedatanodedatanodemastermasterworkworkwork步骤4：安装spark环境，并配置spark-streaming从kafak实时消费数据。步骤5：清洗企业目录，主要工作是把企业全称转换成企业简称，比如包括“有限公司”、“集团”、“xxx市”等词语的公司通过正则转换成企业简称。步骤6：手工清洗简称比较通用的词语，比如“xxx市之所以公司”，这个简称是“之所以”，这样如果用简称匹配舆情信息就会出现很多错误的匹配，所以对于这种简称，需要维护一个数据，让这些企业排除在外。步骤7：开始匹配时，需要把所有企业都加载到spark内存中，如果企业信息超过内存，spark会保存至本地文件，再采用hash散列的算法把每个企业分发到不同的work中，这样在匹配的时候每个work匹配的企业舆情信息就比较均衡。经过步骤1～7，采用集群进行企业和舆情信息匹配和传统的单机匹配效果对比如表2所示：表2匹配速度是否会内存溢出是否能实时匹配集群匹配0.1～0.5秒否是单机匹配6～15秒是否根据测试结果，在采用集群匹配方式后，无论从匹配速度、实时性上都有了很大的提高。最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。当前第1页12