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.首先选取一部分种子url
			2.将这些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 Effort
				2.可扩展性
				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架构和原理