您好, 访客   登录/注册

基于多维数据的关系人分析方法研究

来源:用户上传      作者:丁洪丽

  摘要:针对只利用单数据源进行关系人发现不准确、不完备的问题,研究利用多维数据的关系人分析方法。针对航班和火车出行数据,采用同行规律挖掘算法得到与目标人物一起出行的同行关系人;针对话单数据,采用通联规律统计算法得到与目标人物有通话的通联关系人;针对出行数据和话单数据,采用会面关系人分析方法得到与目标人物有会面的会面关系人;根据重点关系人发现规则从上述关系人得到重点关系人。实验结果表明,本文提出的方法在关系人分析方面是十分有效的。
  关键词:同行规律挖掘;通联规律统计;会面关系人分析;重点关系人分析
  中图分类号:TP311 文献标识码:A
  文章编号:1009-3044(2020)01-0001-04
  1概述
  关系人分析主要是从大量数据中挖掘出潜在的、不为人所知的、人与人之间的各种关系。随着现有数据获取技术手段的提高,获取的各种人类行为数据量剧增,话单数据、出行数据是其中的典型代表,其中潜藏着各种类型的人物关系,这些人物关系可支撑嫌疑人查找、团伙发现、商品推销等应用,如何从这些海量数据中挖掘人物关系及其类型变得尤为重要。
  传统方法在进行关系人分析时仅采用单一数据源进行处理,只利用话单数据进行重点关系人发现,其缺点是容易出现漏判和误判情况。
  利用话单数据进行关系人分析是比较常用的方法,一般将通话次数多、通话时间长的人员列为重点关系人。然而现在网购已经成了大家的习惯,随之而来的快递员、外卖送餐员越来越多。如果目标人物经常网购买东西或者定外卖,那么其与快递员或者外卖送餐员的通话次数就很多,利用传统分析方法,很容易将快递员或者外卖送餐员等日常关系人判断为目标人物的重点关系人,产生误判;另外还存在某些重点关系人和目标人物通话次数并不多的情况,利用传统分析方法,这些重点关系人就被过滤掉了,产生漏判。所以话单数据仅适合发现通联度高的关系人。
  利用航班和火车等出行数据也可以进行重点关系人发现,但也可能存在误判和漏判的情况。经常一起出行的人大多可认为是重点关系人,但也存在两个没有任何关系的出差达人经常一起出行的情况;另外不是所有的关系人都会经常一起出行。所以出行数据仅适合发现同行度高的关系人。
  针对上述问题,我们提出一种基于多维数据的关系人分析方法。本方法采用多数据源进行关系人发现,将处理过程进行融合,判定结果既互相补充又交叉验证,减少了漏判和误判的情况。
  基于多维数据的关系人分析方法流程示意图如图1所示。
  2关系人分析方法研究
  2.1同行关系人分析
  针对航班和火车出行数据,采用同行规律挖掘算法挖掘与目标人物姓名一起出现的频繁项目2一项集得到与目标人物一起出行的同行关系人列表。同行关系人列表项包括目标人物姓名、目标人物证件号码、同行关系人姓名、同行关系人证件号码和同行次数。
  同行规律挖掘算法(cRM,Co-occurrence Rule Mining)流程图如图2所示,具体为:
  相关概念如下:
  ·k-项集:如果事件A中包含k个元素,那么称这个事件A为k项集。
  ·支持度:指事件A和事件B同时发生的概率。
  ·最小支持度:由用户定义的衡量支持度的一个阈值,表示项目集在统计意义上的最低重要性。
  ·频繁项目集:事件A满足最小支持度阈值的事件。
  CRM的实现流程如下:
  a]CRM预读数据,对出行数据中的旅客姓名进行排序。
  b)排序后,CRM将扫描一遍整个数据集,生成一个只包含一个项目的项集。计算在事务集合中的支持度,并据此得到初始的单项目频繁项目集F.(即卜项集),随后的每一轮搜索(假设接下来进行第k轮搜索1都分为3步:
  1)将算法第(k-1)轮搜索生成的频繁项目集集合作为种子集合产生候选项集集合Ck;
  2)扫描整个事务数据库,计算候选项集集合Ck中每个候选项集的支持度;
  3)本轮搜索的最后,算法计算出候选项集集合Ck中每个候选项集的支持度,并将符合最小支持度要求的候选项集加入k-项集Fk。
  值得注意的是,第b)步中1)由合并和剪枝两步完成:
  1)合并:将两个(k-1)一频繁项目集合并来产生一个可能的k-候选项集c。两个频繁项目集的前k-2个项目都相同,只有最后一个项目不同,则该候选项集被加入候选项集集合Ck中。
  21剪枝:判断合并步中得到的候选项集集合中的候选项集c的所有(k-1)一子集是否都在(k-1)一项集Fk-1中,若其中任何一个不在(k-1)一项集中,则c必然不是频繁项目集,则将c从候选集Ck中删除。
  同时,在第二步的整个计算过程中,并不需要将整个数据集加载入内存,只需要在内存中保留一条事务记录,这一特点使得CRM可以用于处理非常巨大的数据集。算法仅需对数据集扫描K次,K是最大项集的大小,在本文中,K=2。
  针对时间效率这一挑战,为了确保频繁项目集生成的高效性,本算法首先对航班和火车出行数据中的旅客姓名进行排序,同时,本算法采用逐级搜索,所以很方便就能够在某一轮搜索完成后就停止。这一点在实际应用中很重要,因为很多情况下过长的频繁项目集或规则并无实际应用,无須将它们找出。
  2.2通联关系人分析
  针对话单数据,采用通联规律统计算法得到与目标人物有通话的通联关系人列表。通联规律统计算法包括通联频次统计和通联时长统计。如图3所示,通联频次统计模块查询话单数据得到目标人物的全部通话记录,遍历全部通话记录,统计所有对端号码的通联频次,通联频次降序排列,得到通联关系人列表1。如图4所示。通联时长统计模块查询话单数据得到目标人物的全部通话记录,遍历全部通话记录,统计所有对端号码的通联时长,通联时长降序排列,得到通联关系人列表2。通联关系人列表项包括目标人物姓名、目标人物证件号码、目标人物电话号码、通联关系人姓名、通联关系人证件号码、通联关系人电话号码、通联频7欠/通联时长。   2.3会面关系人分析
  针对出行数据和话单数据中的位置信息,利用会面规则得到与目标人物有会面行为的会面关系人列表。会面关系人列表项包括目标人物姓名、目标人物证件号码、会面关系人姓名、会面关系人证件号码和会面次数。
  以下会面规则满足任意一条,即可判定分析对象和目标人物有会面行为。
  会面规则1:分析对象在目标人物的停留地点范围内同时出现过且出现时间≥CXSJ分钟;分析对象至少属于同行关系人列表或者通联关系人列表之一。
  会面规则2:分析对象与目标人物在活动路线上同时出现过且并行时间≥BXSJ分钟;分析对象至少属于同行关系人列表或者通联关系人列表之一。
  其中CXSJ、BXSJ可根据需要进行设置。
  会面关系人分析方法流程图如图5所示。会面关系人分析模块遍历出行数据和话单数据中的位置信息时空序列,11查找与目标人物在停留地点同时出现的人,判定出现时间是否≥CXSJ分钟,判断是否属于同行关系人或通联关系人,得到满足会面规则1的会面关系人;21查找与目标人物在活动路线上并行出现的人,判定并行时间是否≥BXSJ分钟,判断是否属于同行关系人或通联关系人,得到满足会面规则2的会面关系人;3)去除重复的关系人,得到最终的会面关系人。
  2.4重点关系人分析
  针对同行关系人列表、通联关系人列表和会面关系人列表中的数据,利用重点关系人发现规则判定得到重点关系人列表,重点关系人列表项包括目标人物姓名、目标人物证件号码、目标人物电话号码、重点关系人姓名、重点关系人证件号码、重点关系人电话号码。
  以下重点关系人判定规则满足任意一条,即可判定分析对象为目标人物的重点关系人。
  规则1:关系人同时存在于同行關系人列表、通联关系人列表和会面关系人列表,将其加入重点关系人列表;
  规则2:关系人同时存在于同行关系人列表、通联关系人列表和会面关系人列表中的任意两个表中,将其加入重点关系人列表。
  规则3:关系人只存在于同行关系人列表,同行次数排序前10,将其加入重点关系人列表。
  规则4:关系人存在于通联关系人列表,通联频7欠/通联时长排序前10,将其加入重点通联关系人列表。
  规则5:关系人存在于会面关系人列表,会面次数大于2,将其加入重点关系人列表。
  规则6:关系人只存在于通联关系人列表,通联频次或通联时长排序前10,但是目标人物与此关系人存在如下通联规律:通话时间点规律经常在中午11:00-13:00期间,通话位置在同一基站位置内,且通话前后目标人物位置相对固定,但关系人位置在不停变化。此关系人疑似外卖送餐员,可将此关系人从重点关系人列表移除。
  通话时间点规律具体为:
  将00:00-24:00区间分成若干个时间段,将用户号码每次通话的事件发生日期时间映射到每个时间段、统计每个时间段的通话次数,得出通话时间点规律。
  进一步的,经过以上规则得到的重点关系人列表需要根据证件号码进行去重处理。
  3实验结果及分析
  针对出行数据和话单数据,本文搭建了一个关系人分析演示系统。演示系统采用基于松耦合架构进行设计的B/S架构,应用服务开发基于J2EE的设计开发规范,采用Java语言开发,前端采用JavaScfipt开发,数据库方面采用impala数据库。把出行数据和话单数据提交给演示系统进行关系人分析。针对分析对象ABRAMOWICZORYSHLOMO,同行关系人发现模块的结果如图6所示。通联关系人发现模块的结果如图7所示。会面关系人发现模块的结果如图8所示。系统最终给出重点关系人列表,并以关系网络图的形式展示目标人物的关系网络,如图9所示。经过对比分析,系统给出的结果相比采用单一数据源进行重点关系人发现得到的结果更加准确,完备。
  4结束语
  本文提出的基于多维数据的关系人分析方法采用多数据源进行关系人发现,将处理过程进行融合,判定结果既互相补充又交叉验证,减少了漏判和误判的情况,解决了只利用单一的数据源进行关系人发现不准确、不完备的问题。
转载注明来源:https://www.xzbu.com/8/view-15143854.htm