1200字范文,内容丰富有趣,写作的好帮手!
1200字范文 > 4.大数据架构详解:从数据获取到深度学习 --- 数据获取

4.大数据架构详解:从数据获取到深度学习 --- 数据获取

时间:2020-12-31 22:55:13

相关推荐

4.大数据架构详解:从数据获取到深度学习 --- 数据获取

大数据技术的核心是从数据中获取价值,而第一步就是要弄清楚有什么数据,怎样获取。4.1 数据分类 数据的分类有很多种,按照数据形态划分为结构化数据和非结构化数据。结构化数据如传统的Data Warehouse 数据;非结构化数据有文本数据,图像数据,自然语言数据等。结构化数据,结构固定,每个字段有固定的语义和长度,计算机程序可以直接处理;非结构化数据,计算机无法直接处理,需要先对数据进行格式转换或信息提取。按照数据的来源和特点,电信的数据又可以分为原始数据,用户面详单信令,信令数据等。4.2 数据获取组件 数据来源不同,获取的技术也不同.电信特有的探针技术,以及获取网页常用的爬虫,采集日志数据的组件Flume。4.3 探针 4.3.1 探针原理 打电话,手机上网,背后承载的都是电信的路由器,交换机等设备的数据交换。从电信的路由器,交换机把数据采集上来的专有设备是探针。根据放置的位置不同,分为内置探针和外置探针。内置探针:探针设备和电信已有设备部署在同一个机框内,直接获取数据。外置探针:在现网中,大部分网络设备已经部署完毕,无法移动原有的网络,这时就需要外置探针。外置探针主要由以下几个设备组成:1.Tap/分光器:对承载在铜缆,光纤上传输的数据进行复制,并且不影响原有两个网元间的数据传输。2.汇聚LAN Switch:汇聚多个TAP/分光器复制的数据,上报给探针服务器3.探针服务器:对接收到的数据进行解析,关联等处理,生成xDR,并将xDR上报给分析系统,作为其数据分析的基础。探针通过分光器或得到数据网络中各个接口的数据,然后发送到探针服务器进行解析,关联等处理.4.3.2 探针的关键能力 1.大容量2.协议智能识别传统的协议识别方法采用SPI(Shallow Packet Inspection)检测技术。但SPI仅仅分析IP报四层以下的内容,根据tcp/udp的端口来识别应用。许多传统和新兴的应用采用了各种端口隐藏技术来逃避检测,比如在8000端口上进行http通信,在80端口上进行skype通信,在2121端口上开启ftp服务等。因此,仅通过第四次端口信息已经不能真正判断流量中的应用类型,更不能应对基于开放端口,随机端口甚至采用加密等方式进行传输的应用类型。要识别这些协议,无法单纯依赖端口检测,而必须在应用层对这些协议的特征进行识别。除了逃避检测的情况外,目前还出现了运营商和OTT合作的场景。协议智能识别技术能够深度分析数据包所携带的L3~L7/L7+的消息内容,连接的状态/交互信息等,从而识别出详细的应用程序信息。3.安全的影响探针的核心能力是获取通信的数据,但随着越来越多的网站使用HTTPS/QUIC加密L7协议,传统的探针能力就会受到极大的限制。比如像分析YouTube的流量,只有通过解析L7协议才能知道用户访问的是YouTube,所以加密之后会影响探针的解析能力,很多业务就无法进行。现在业界尝试使用深度学习来识别协议,如360设计了一个5~7层的深度神经网络,能够自动学习特征并识别每天数据中的50~80种协议。4.IB(InfiniBand)技术InfiniBand架构是一种支持多并发链接的"转换线缆"技术。4.4 网页采集 4.4.1 网络爬虫 网络爬虫的基本工作流程如下:1.首先选取一部分种子url2.将这些url放入待抓取的url队列3.从待抓取url队列中取出待抓取的url,解析dns,得到主机的ip,并将url对应的网页下载下来,存储到已下载网页库中。此外,将这些url放入已抓取url队列4.分析已经抓取的网页内容中的其他url,并将url放入待抓取的url队列,从而进行下一轮循环抓取策略:1.深度优先遍历策略2.宽度优先遍历策略3.反向链接数策略4.PartialPageRank策略5.OPIC策略6.大站优先策略更新策略:1.历史参考策略2.用户体验策略3.聚类抽样策略系统架构:1.主从模式2.对等模式4.4.2 简单爬虫Python代码示例 4.5 日志收集 4.5.1 Flume 3.Flume 架构分析1.系统特点1.可靠性end-to-end, Store on Failure, Best Effort2.可扩展性3.可管理性4.功能可扩展性4.5.2 其他日志收集组件 4.6 数据分发中间件 4.6.1 数据分发中间件的作用 数据采集上来后,需要送到后端的组件进行进一步分析,前端的采集和后端的处理往往是多对多的关系。在前端的采集和后端的处理之间需要一个消息中间件来负责消息转发,以保证消息的可靠性,匹配前后端的速度差。传统的日志分析系统提供了一种离线处理日志的可扩展方案,但若要实时处理,通常会有较大的延迟。而现有的消息(队列)系统能够很好的处理实时或者接近实时的应用,但未处理的数据通常不会写到磁盘上,这对于Hadoop之类(一小时或者一天只处理一部分数据)的离线应用来说,可能存在问题。kafka正是为了解决以上问题而设计的,它能够很好的处理离线和在线应用。kafka 架构:1.生产者(Producer):消息和数据生产者2.代理(Broker):缓存代理,kafka核心功能3.消费者(Consumer):消息和数据消费者设计要点:1.直接使用Linux文件系统的cache来高效缓存数据2.采用Linux zero-copy 提供发送性能。传统的数据发送需要发送4次上下文切换,采用sendfile系统调用后,数据直接在内核态交换,系统上下文切换减少为2次。4.6.2 Kafka架构和原理

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。