第二部分 关于基础组件与介绍
基础信息库种类
基础信息库是账户或者自然人的纯真数据库查询系统。系统内积累存储的数据包括有:
ü 手机号归属信息
ü IP数据纯真库
ü GPS信息对应地址信息
ü 域名空间身份信息
ü 3G分组域通讯信息
ü VPN服务器基础信息
ü VPN服务器日志信息(最新的区域时间段)
ü 国内运输系统基础数据
ü 网络帐号密码查询系统
ü 网络帐号详情搜索查询
3S定位技术
3S 是通过遥感技术(RS)、地理信息系统(GIS)、全球定位系统(GPS)实现位置确认技术的统称;是利用空间技术、传感技术、卫星定位与导航技术与现代计算机技术和现代通信技术结合实现多学科高度集成的对空间信息进行采集、分析处理、表达与传播的现代信息技术。
遥感技术主要用于获取地理信息数据的获取与收集,现在日常的终端设备基本都可以获取到当前的地理事物的空间数据。全球定位系统主要用于地理事物的空间定位(通常是gps 或者北斗);地理信息系统主要用于地理信息数据的管理,更新,分析等。三者之间的关系如下图:
数据计算与可视化展示
按照数据的特有属性设定展示数据分布热力图,数据的特有属性类似:空间、年龄、学历、用户设定属性等。
从各种网络数据中分析提取其中的社交数据,对相应的社交数据进行分析展现,人物之间的联系网络关系图,结合基本数据库的信息,确定人物的网络与实际地理信息空间位置,配合地理信息系统将数据体现展示到离线地图或在线地图上。实际展示方式有:网络关系图,用户分布图,用户潮汐图,单个用户轨迹图,还会体现社交数据属性的统计并形成报表。
对于网络论坛、微信、微博等类似数据,以帖子本身为参照物分析查找对这一帖子的参与讨论转发的账户进行追溯账户参与时候所在的地理个空间或者其他相关的实名认证信息数据。形成关系图为指导矩形树图为辅的展现形式进行可视化展示;并对分析结果进行统计,生成图表。
数据可视化图表库有很多种选择,按照目前的情况有一下几种可以考虑:
ü D3 :强大的js库,并且免费。但是易用性比较差。入门门槛比较高,学习难度相较于其他图表库比较高,但是效果确实很棒。
ü Echarts:百度提供的一套图表库,中文文档全。文件更小但功能也很强 大;有着灵活的打包方式,可以自由选择系统需要的图表和组件,满足不同 数据的处理需求和搭配方案,让数据呈现方式更个性和完美。
ü Okaycharts: 国内一款免费开放的一款JS图表库,支持普通图表,部分三维图表和地图。重要的支持动态刷新,图表缩放等交互。还提供可视化设计并导出JS代码。
网络数据的采集
网络数据采集,是一个很浩大的一个工程。包含网络爬虫,数据清洗,数据归类等等。
数据采集数据流
数据采集部分采取多点多终端进行采集网络各式的数据,通过数据采集集群进行数据清洗和去重操作,将无效数据过滤出去。进过高速缓存队列,传给外网数据服务器;数据服务器会对数据进行数据合法话检查,如有空缺将填充默认数值。通过数据库本身数据同步和备份将数据分散到各个内网的数据服务器上。
内网数据服务器会对数据进行初步的分类删选和数据的纯真处理对应,并提供原数据的备份。通过SPOOl技术将数据同步传输到HBase数据库上(前期数据积累量不是很大,可以延缓,直接在原有集群上做数据分析)。下图为数据流:
数据采集子系统框架设计
开发一个通用的爬虫系统,可以通过参数驱动内部逻辑调度。比如参数里指定抓取新浪微博,爬虫终端就会调度新浪微博网页扣取规则抓取节点数据,调用存储规则存储数据,不管什么类型最后都调用同一个类来处理。只需要设置抓取规则,相应的后续处理就交给爬虫终端,进行爬取数据。整个爬虫模块使用了 xpath、正则表达式、消息中间件、多线程调度框架(参考)。xpath 是一种结构化网页元素选择器,支持列表和单节点数据获取,好处可以支持规整网页数据抓取。
整个子系统设计有几个部分:资源管理、反管制管理、爬虫任务管理、守护服务等。看一下整个组件图:
- 资源管理:配置感兴趣的数据源分类体系、爬取规则等基本资源的管理维护。
- 反管制管理:某些数据网站会限制爬虫或者禁止爬虫访问,配置可以绕过网站监控的机制就是反管制机制。一般网站的管制有:
- 一定时间内单个IP访问次数,没有哪个人会在一段持续时间内过快访问,除非是随意的点着玩,持续时间也不会太长。可以采用大量不规则代理IP来模拟。
- 一定时间内单个帐号访问次数,正常人不会这么操作。可以采用大量行为正常的账号,行为正常就是普通人怎么在社交网站上操作,如果一个人一天24小时都在访问一个数据接口那就有可能是机器人了。
- 爬虫任务管理:指通过url,结合资源、反监控抓取数据并存储;爬虫系统规则设置很多正则表达式,或者使用htmlparser、jsoup等软件以便解决硬编码结构化数据的抓取的问题。
- 守护服务:指不管什么系统都可能出问题,如果对方服务器宕机、网页改版、更换地址等问题,爬虫终端都需要第一时间知道,这时守护服务就起到出现了问题及时发现并通知工作人员。
框架搭建起来基本可以解决大量的爬取数据的需求。通过界面进行资源管理、反管制规则、数据获取规则、消息中间件状态、数据监控图表等操作,还可以通过后台调整资源分配并能动态更新保证抓取不间断。
如果一个任务的处理特别大,可能需要抓取24个小时或者几天。例如抓取一条微博的转发,转发次数为30W次,如果按照线性去抓取会消耗很长时间,系统的效率就体现出来;如果能把这30W拆分很多小任务,那并行计算能力就会使效率提高很多。下图是在Hdoop下进行并行爬取数据的框架图:
总体系统框架
系统整体设计按照分层设计的思想,将平台所需要提供的服务按照功能划分成不同的模块层析,每一个模块层次只和相邻的上下层产生数据交互(每层都设计有边界接口),避免跨层的交互。这样各个功能模块的内部是高内聚的,而各个模块之间却是松散耦合的。这样设计有利于实现平台的高可靠性、高扩展性、并且容易维护。平台处理数据达到质的飞跃,Hadoop集群最初的配置不能满足需求的时候,只需要在基础设施层添加一些Hadoop的服务节点服务器即可,而对其他的模块层不需要做任何改动,并且对用户也是完全透明的。下图为平台的整体设计框架:
基础设施层
基础设施层包含有:软件环境层、基础服务调用接口。运行环境层为基础设施层提供运行时环境,它由2部分构成,即操作系统和运行时环境。
操作环境使用CentOS 6.6 x86_64。为了提高磁盘的IO吞吐量,这里不会选择安装RAID驱动,将分布式文件系统的数据目录分布在不同的磁盘分区。软件环境层体要求:
项目名称 |
项目版本 |
说明 |
JDK |
1.7 |
Hadoop相关的需要java运行环境 |
GCC/G++ |
4.4以上 |
数据计算、结构数据存储分析需要gcc编译器 |
Python |
2.5 以上 |
Hadoop Streaming运行MapReduce任务时,需要python运行时 |
Node.js |
3.3以上 |
数据可视化展现的运行环境 |
Zookeeper |
3.6.5 |
管理集群分布式协同同步、域名管理 |
Hadoop |
2.6.0 |
分布式文件系统、计算框架(MapReduce) |
基础服务调用接口由三部分组成:任务调度服务、Hbase、Hive。为用户网关层提供基础服务调用接口。
- 任务调度控制台是MapReduce任务的调度中心,分配各种任务执行的顺 序和优先级。用户通过调度控制台提交作业任务,并通过用户网关层的Hadoop客户端返回其任务执行的结果。其具体执行步骤如下:
ü 任务调度控制台接收到用户提交的作业后,匹配其调度算法;
ü 请求ZooKeeper返回可用的Hadoop集群的JobTracker节点地址;
ü 提交MapReduce作业任务;
ü 轮询作业任务是否完成;
ü 如果作业完成发送消息并调用回调函数;
ü 继续执行下一个作业任务。
- HBase是基于Hadoop的列数据库,为用户提供基于表的数据访问服务。
- Hive是在Hadoop上的一个查询服务,用户通过用户网关层的Hive客户 端提交类SQL的查询请求,并通过客户端的UI查看返回的查询结果,该接 口可提供数据部门准即时的数据查询统计服务。
用户网关层
用户网关层用于为终端客户提供个性化的调用接口以及用户的身份认证,是用户唯一可见的平台操作入口。终端用户只有通过用户网关层提供的接口才可以与平台进行交互。网关层初步提供3个个性化调用接口:
- Hadoop客户端是用户提交MapReduce作业的入口,并可从其UI界面查看返回的处理结果。
- Hive客户端是用户提交HQL查询服务的入口,并可从其UI界面查看查询结果。
- Sqoop是关系型数据库与HBase或Hive交互数据的接口。可以将关系型数据库中的数据按照要求导入到HBase或Hive中,以提供用户可通过HQL进行查询。同时HBase或Hive或HDFS也可以将数据导回到关系型数据库中,以便其他的分析系统进行进一步的数据分析。
用户网关层可以根据客户的实际需求可无限的扩展、灵活的配置。
客户应用层
客户应用层是各种不同的终端应用程序,可以包括:各种关系型数据库,报表,网络行为分析,网络活动轨迹分析,数据等量区域分布,网络账户联络关系,各种数据统计及分析,网络账户的纯真数据查询及定位,系统任务配置,数据采集等。
分析结果呈现
将数据分析结果,可视化展示。对应系统中的最高应用层 — 客户应用层。 客户直接使用客户应用层查看分析结果。
下图是客户应用层与用户网关层的交互组件图(外围系统管理部分不包含):
基础分析交互图
v 例如:
“amir 在2016年5月16日在朋友网上发表一篇日志,回复了一些留言,并发表心情,更新了自己的个人资料并且装扮了自己的空间。”
该账户行为,我们能得到很多信息数据:帐号名称、登陆朋友网时间、上网使用IP、日志内容、给那些人回复了帖子、那些人给amir留言、心情内容、个人资料信息、装扮空间的内容等信息。
得到了这么多数据以后要怎么去使用呢?下来简单的说一下平台内能做什么样的处理:
- 网络行为分析:根据设定IP和时间范围。关联有关这一设定的所有网络数据,统计在这一段时间内本IP在这一范围内,这一账号访问过那些网站并对这些数据做出分类与统计,形成饼状图、柱状图;生成根据分类行程报表。结合设定的专题情报模型,分析这一行为是否有参考价值。
- 网络活动轨迹:全网数据分析amir帐号,在指定时间范围内使用那些IP进行访问朋友网和每次访问朋友网的时间,配合IP纯真基础信息库进行定位。将得到的数据投射到Google离线地图上画出账号近期活动的空间轨迹。
账户活动范围
- 数据分布分析:分析帐号所有的有关数据,确定近期目标关注事件或者个人爱好、活动范围频繁度等等,行程热力分布图。
热力分布图 联系人分布
- 网络账号联络关系:根据帐号在留言板的回复情况确定,客户与好友的关系情况。进而分析好友的信息,进行二次分析。画出帐号的三级联系人关系图(人物网络)。对联系频繁,判定关系好联系人进行标注。
关系图1 默认载入完成后
关系图2 选择某节点后的效果
- 数据统计及分析:统计帐号活动的频率,分析帐号使用IP的上网方式。如果是手机3G或者4G上网,则可以分析出手机号相关个人信息,借助客户特有资源库调出该手机号近期的使用情况,作为参考。
- 账户纯真数据查询:得到帐号的实名认真信息;上网时候的地理位置,确定目标是否是在家里,还是工作但闻或者其他地方;根据数据内容分析目标当前状态喜怒安乐等信息。生成报表。
下图为系统生成的报表样例:
附录 1:
常用的分布式文件系统
n Lustre:SUN公司开发,在Linux下运行,以C/C++开发的集群并行文件系统。采用分布式的锁管理机制来实现并发控制,元数据和文件数据的通讯链路分开。虽然在性能、可用性和扩展性上有一些优点,但是缺点也同样明显:需要特殊设备的支持,并且分布式的元数据服务器管理还没有实现。
n MogileFS:一个开源的分布式文件系统。主要特点包括:应用层组件、无单点故障、自动文件复制、具有比RAID更好的可靠性、无需RAID nigukefs支持。缺点包括:用Perl编写,有依赖模块的问题,安装过程中需要其他库和模块的支持,对于不懂Perl的人,安装和使用很困难。MogileFS不支持对一个文件内部的随机或顺序读写,不支持视频拖动,因此只适合做一部分应用,如图片服务、静态HTML服务等;MogileFS过度依赖数据库,包括它的高可用性也需要靠数据库的HA实现。
n FastDFS:一个专用的文件系统,和MogileFS比较类似,需要使用专门的API来访问,不是通用的文件系统,不能Mount成PATH的形式使用。只使用于一些特定的应用领域,比如网站存储图片、视频文件等。
n NFS:Linux直接在内核予以支持,使用方便,发展多年,比较成熟。但是可扩展性差,难以应用于大量存储节点和客户端的集群式(cluster)系统;文件服务器对客户端不透明,维护困难;缓存管理机制采用定期刷新机制,可能会产生文件不一致;不支持数据复制、负载均衡等分布式文件系统的高级特性,很容易出现系统的性能瓶颈;另外,NFS服务器的更换需要系统暂停服务,对于异地服务的支持能力不够。对于追求海量数据吞吐量、存在成千上万个客户端和存储节点的互联网应用来说有点力不从心。
n HDFS:Hadoop的文件系统,其目的是向应用数据提供高吞吐量访问的分布式文件系统,基于GFS的开源实现。其最大的优点包括:无需替换现有系统,而是利用该分布式文件系统增强现有系统的处理能力。
HDFS可以从已有系统上接手海量数据的处理,使已有系统可以专注于其设计目的,如实时交易数据处理、交互式商业智能,这些海量数据处理包括但不限于同步数据吞吐、处理、交换大规模数据等。
HDFS可以从任意多的数据源吞入任何类型的数据,来自多个数据源的数据可以按任何需要的方式合并或聚合,从而实现任意单一系统无法实现的深度分析。
HDFS不处理索引和关系,所以在HDFS中存储数据时不用考虑将来如何分析这些数据。在和数据库交互方面,
HDFS支持JDBC,而大部分数据库都支持数据的批量导入/导出。
HDFS设计为存储海量数据以及按需要向任意系统传递数据,数据可以经常性地从关系型数据库系统导入到HDFS中,经过这样的调整,关系型数据库可以专门用来处理交互式任务,而复杂的分析工作就可以按离线的方式交由HDFS来完成,对实施系统没有任何影响。
海量数据比较理想的存储方案是分布式文件系统,而分布式文件系统中,HDFS是比较理想的一款。
附录2:
主流的搜索引擎项目对比
n Lucene:Java家族中最为耀眼的一款开源全文搜索引擎。提供了完整的查询引擎和索引引擎,没有中文分词引擎,需要自己去实现,因此用Lucene去做一个搜素引擎需要自己去架构.另外它不支持实时搜索。Lucene进行过C++移植版本叫CLucene,她使用C++编写,所以理论上要比Lucene快。
n Sphinx:C++语言写的开源搜索引擎,也是现在比较主流的搜索引擎之一,在建立索引的事件方面比Lucene快50%,但是索引文件比Lucene要大一倍,因此Sphinx在索引的建立方面是空间换取事件的策略,在检索速度上,和Lucene相差不大,检索精确度方面Lucene要优于Sphinx,另外在加入中文分词引擎难度方面,Lucene要优于Sphinx.其中Sphinx支持实时搜索,使用起来比较简单方便。
n Solr:Java开发的独立的企业级搜索应用服务器,提供类似于Web-service的API接口;基于Lucene的全文检索服务器,也算是Lucene的一个变种,很多一线互联网公司都在使用Solr,也算是一种成熟的解决方案。
n Elasticsearch:Java语言开发的,基于Lucene构造的开源,分布式的搜索引擎。设计用于云计算中,能够达到实时搜索,稳定可靠.。Elasticsearch的数据模型是JSON。实时性能优越;安装配置简单;RESTful API 和 JSON 格式的文档型数据,降低开发调试的难度。另外,Tire 这个 Gem 可以简单方便的与 ActiveRecord 整合。Elasticsearch自带了中文分词,支持中文搜索,但是,可以换用更高效精确的分词插件。
选用那个搜索引擎,需要结合数据模型和具体业务。考虑在海量数据处理系统框架内,Elasticsearch或者Solr 是最为理想的选择。Elasticsearch自带中文分词,并且支持分布式,容易上手,确信Elasticsearch更适合。