内容简介:首先,是几个事实:原则上,所有数据都可以用图做分析,只是如果构建分析能力之前不明白图形中的必要元素的组成、关系、关联、方向和趋势等必要关联因素的话,构建的结果只是单纯的点与点之间的
首先,是几个事实:
-
基于图进行关联分析,是非常古老的手段,而近现代的各种技术手段解决的多是由于大量数据所带来的关系多样性的问题,以及其中包含的大量数据的计算性能方面的问题;
-
基于图进行关联分析由于其存在的古老历史,所以,这种方法实际上沉淀了很多通用的方法论;
-
基于图的可视化效果可弥补传统字符串分析方式的一些不足,比如,字符分析往往是基于相同或相似,而无法从数据的走向和方向上看到趋势,从而错失可能的事实或即将形成的事实;
-
基于图的关系分析看似是扁平的,实则是立体的,只是这种立体在可视化效果上并不容易体现,而是需要借助分析者的分析能力来构建;
-
因为这种立体关系需要基于分析人员的能力,所以图关系的展示并非像很多宣传那样可以做到“一眼就懂”,其分析过程也需要依靠专业人员,否则当元素过多而形成杂乱关系时反而会是“一眼就懵”;
-
这种分析能力(工具/平台)并非是直接指向结果的,而更多的是用更好的方式来展示事实,这也是为什么数据即便变的可视了还需要专业分析人员的另一个原因。
原则上,所有数据都可以用图做分析,只是如果构建分析能力之前不明白图形中的必要元素的组成、关系、关联、方向和趋势等必要关联因素的话,构建的结果只是单纯的点与点之间的 连线 ,这与真正的数据之间的 联系 相差甚远,所以,在构建真正的关系图之前需要搞明白几个问题:
-
主节点与属性,以常见的数据类型来说,如果说一个人是主节点,那这个人使用的设备、IP、邮箱、收款账号等等信息都是其属性。这些属性在图形中也是一个节点的形式存在,但却与主节点大有不同。属性会是两个节点建立关系的主要依据 —— 主节点A与主节点B来自同一设备,其联系就来自两个节点的相同属性;
-
属性可能还有其更细粒度的属性,例如,IP地址。在人和人之间的数据关系中,IP地址是公认的弱关联关系,因而是在建立关联时容易被忽略。但实际上,IP也有其自己的属性,如果一个IP属于某个可信的IDC,而且从其对外开放的服务上来看,在某个时间窗口内未曾出现过变化,那么在这个时间窗口内其所属人就很可能是同一个人。这种条件下,IP虽然也不能称为强关系,但至少不会是简单的弱关系了。而在这里,实际上又提到了一个构建立体化图形关系的重要元素 —— 时间,这个后面再说;
-
主节点之间除了用属性关联,还会因动作而关联,A的付款账号向B的收款账号进行了一笔转账,这样的关系在数据层面上体现的并非是两个点上所承载字符串的相同或相似,而是因为两个节点发生了某种动作关系。当然,这个例子只是一种显而易见的关系,在实际复杂数据中想梳理出所有这种动作关系往往是没那么简单的,因为很多关系是隐藏极深的。例如,A和B在某个社交平台发布了同一条消息、附带的是同一张图片。这种情况下,A和B的动作关系实际上是被隐藏起来的。而且没有相关分析经验的人很可能无法在分析能力构建之初设想出这样的关系,这样,一些数据可能就不会被录入到系统中,或是即便录入进去也因为缺少此类关联而浪费;
-
构建立体化的另一重要元素就是时间,时间的流动性可以表现出节点或属性的变化,而这种变化过程中带出的新的关系,就是用于推测和验证最原始节点真伪的重要证据。依然以A、B在社交平台发布同样内容和图片为例,随着时间推移,可能我们就会发现,原来的A、B发布同样的内容,慢慢的变成了A、B、C、D都在发布同样的内容。那么这个时候问题就来了,如果他们的关系只是因为相同而关联的话,这种关联仅仅是平面的。如果通过时间轴进行从过去到现在的不断回放,可能就会发现,在某个时间节点,账号体系中只有A,随后出现B,然后A和B发布同样的内容,再随后C来注册,也发布同样的内容,随后才是D的出现和发布。这个时候,本来扁平的关系就会变的立体,而这个立体图形的顶点显然就是A了;
-
时间轴除了构建立体关系的可能性外,还可以强化或弱化关联。强化关联的问题在属性的时候已经提到了。弱化关联的场景也很多。我见过一些基于whois的分析平台,完全就是在做扁平化的连线不说,而且还在众多节点的关系构建中忽略了时间轴,这就让看起来很丰富的数据变的毫无用处。a.com 指向 1.1.1.1 和 b.com 也指向 1.1.1.1 ,看似强关联的两个域名关系,如果加上时间轴的关系可能就变得不堪一击 —— 两个域名whois的时间,两个域名解析到IP的时间,稍一综合就能看出这种关联的真假;
-
而强调时间轴的另一原因就是,时间轴的加入可以让分析变得更简单。这种简单来自于两个方面,一方面是在特定时间范围内,数据量会变小,让数据的可视元素变少,变得容易解读;另一方面,如上所说的例子中,两个域名指向同一个IP只是一种最简单的场景,在实际场景中经常是多个域名和IP交叉,再加上其他元素,让整张图非常复杂,而在域名和IP(解析)这两个维度融入了时间做逻辑判断的话,就会消除无用的数据。这样的消除动作未必会让可视化的元素大量减少,但却保证了留下的元素和关系变得更精准。精确的关系,也是节省分析精力、提升分析准确度的必要前提;
-
除此之外,方向也是极其重要的指标。相比节点之间的属性关联,节点之间的动作关联最重要的问题就是,动作是有方向的。A打电话给B三次,尚且可以认为A是一个有恒心的推销员,但如果B在每次A电话之后都会回复给A,我就无法认同这个结论了。所以,A和B之间的动作方向就非常的重要;
-
节点之间关联的那条线,应该有粗有细 —— 也就是,权重问题。上面IP关系时曾说到了关系的强弱之分,两个节点之间该如何连线很大程度上与那条线背后的关系是密不可分的,节点间这条线来自于一个IP的重合,与节点间的线来自于设备指纹的重合,其权重必然不同。如果IP和指纹都重合,那其权重应该更大。如果再加上时间轴和业务数据,还有重合,两个节点之间的那条连线就应该粗到不可想象了。除了关系本身的权重之外,数量也是一个关键。如同A和B之间的通话,一次和一百次,必然不同。
关于图的关系分析,大概如此。对这些话做一个简单的回顾和总结:
-
先搞明白自己的数据里有什么
-
再搞明白里面隐藏的关系是什么
-
把关系和分析场景进行嵌套耦合
-
定义好什么是节点、节点之间用于建立关联的属性和动作又都有什么
-
利用好时间轴
-
要看清动作的方向
-
要定义好关系的权重
声明:本文来自Piz0n,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如需转载,请联系原作者获取授权。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Flink 维表关联系列之 Kafka 维表关联:广播方式
- Flink 维表关联系列之 Redis 维表关联:实时查询
- Flink 维表关联系列之 MySQL 维表关联:全量加载
- Flink 维表关联系列之 Hbase 维表关联:LRU 策略
- GORM 关联查询
- springboot关联mybaits
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。