1.1.zebra概述
1.1.1.zebra是什么
如图所示，电信运营商的用户通过连接到互联网中的各种网络设备访问一个网站时，其访问信息会通过在网络中传递，可以收集所有用户的访问日志数据
zebra是对电信运营商收集的用户上网数据进行分析的一个应用程序。通过分析得到的结果可以展现不同小区的上网详情。
注：zebra本意为斑马，命名类似hadoop的方式，好记并无特殊含义！
1.1.2.整体项目演示
如图所示，按天统计应用大类的某个指标，点击某个大类时能看到这个大类中的各个小类的详情。
统计多个小区对同一个网站的访问情况，单击某个小区时可以查看某个小区的不同时间段内的详情
可以通过zookeeper监控整体集的健康状况。
1.1.3.zebra项目需求分析
来源数据格式
如图所示，运营商收集的用户上网日志中一行有很多字段，可能是用户某次短信发送，也可能是用户某次的通话，也可能是http访问或者app内通讯（比如：QQ好友之间聊天）等等。因为我们只需要分析所有的http访问，所以我们需要得到不同小区的上网详情只需要处理下列字段就可以了。
需要分析的列
咪咕音乐
16
TAC
byte
2
TAC
17
Cell ID
Byte
4
UE所在小区的ECI
19
App Type Code
byte
1
业务类型编码，参见附录D XDR类型编码定义
20
Procedure Start Time
dateTime
8
TCP/UDP流开始时间，UTC时间），从1970/1/1 00:00:00开始到当前的毫秒数。
21
Procedure End Time
dateTime
8
TCP/UDP流结束时间，UTC时间），从1970/1/1 00:00:00开始到当前的毫秒数。
23
App Type
byte
2
应用大类
集团规定的18种应用大类，参见《中国移动数据流量DPI识别能力规范》
24
App Sub-type
byte
2
应用小类
根据集团定义的识别规则识别出来的小类, 参见《中国移动数据流量DPI识别能力规范》。
集团未定义的各厂家根据自己的DPI进行识别
27
USER_IPv4
byte
4
终端用户的IPv4地址，如无则填全F
29
User Port
byte
2
用户的四层端口号
31
App Server IP_IPv4
byte
4
访问服务器的IPv4地址，如无则填全F
33
App Server Port
byte
2
访问的服务器的端口
34
UL Data
byte
4
上行流量
单位：字节
对于场景一，定义为从内层IP包头开始计算的数据包大小总和；
对于其他场景，定义为从链路层封装开始计算的数据包大小总和。
35
DL Data
byte
4
下行流量
单位：字节

对于场景一，定义为从内层IP包头开始计算的数据包大小总和；
对于其他场景，定义为从链路层封装开始计算的数据包大小总和。
40
上行TCP重传报文数
byte
4
上行TCP重传报文数
非TCP传输时，此字段填0
41
下行TCP重传报文数
byte
4
下行TCP重传报文数
非TCP传输时，此字段填0
55
HTTP/WAP事务状态
byte
2
HTTP/WAP2.0层的响应码，参见附录A 状态编码
59
HOST
char
64
　访问域名
62
User-Agent
char
256
　终端向访问网站提供的终端信息，包括IMEI、浏览器类型等
63
HTTP_content_type
char
128
HTTP的内容是文字还是图片、视频、应用等，具体编码参考附录A
68
Wtp中断类型
byte
1
WTP层的失败类型
72
业务行为标识
byte
1
0-业务登陆                                                                                                                                                                                                                  1-页面访问
2-刷新
3-未识别；
判断规则详见《业务KPI定义(20130821)》
73
业务完成标识
byte
1
0-业务成功
1-业务失败
2-未识别
成功的判断规则：状态码<400
这是我们需要处理的每行数据中的字段，通过对这些数据的处理，我们可以得到不同小区
的上网详情数据。具体来说，就是把一段时间内的同一个小区内访问同一网站、同一个ip的访问累计起来，就可以得到某小区内的某网站的访问详情。
业务字典
数据流量业务大类分类
序号
业务类型
业务说明
1
即时通信
互联网消息即时收发业务,如：QQ、飞信等
2
阅读
向用户提供在线或离线阅读服务的业务，如：移动手机阅读、熊猫阅读等
3
微博
微博业务，如：移动微博、新浪微博等
4
导航
提供浏览、查询、导航等功能的电子地图类业务，如：谷歌地图、高德导航等
5
视频
向用户提供音视频内容的直播、分享和下载服务的网站和应用（不包括传统意义上基于P2P技术的视频业务），如：优酷、手机电视等
6
音乐
提供音乐在线欣赏和下载服务的网站和应用，如：咪咕音乐、QQ音乐等
7
应用商店
提供应用程序、音乐、图书等内容浏览、下载及购买服务的业务，如：Mobile Market、AppStore等
8
游戏
基于客户端或者网页的游戏业务：QQ游戏、开心农场等
9
支付
电子商务类业务，如：手机支付、支付宝、网银等
10
动漫
提供动漫在线欣赏和下载服务的网站和应用，如：手机动漫、爱看动漫等
11
邮箱
业务，如：139邮箱、QQ邮箱等
12
P2P业务
基于P2P技术的资源共享业务，包括下载和视频两部分，前者如：迅雷、eMule等，后者如：迅雷看看、PPLive等
13
VoIP业务
互联网语音通信业务，如：Skype、Uucall等
14
彩信
彩信业务
15
浏览下载
基于HTTP、WAP、FTP等的普通浏览和下载业务
16
财经
金融资讯、股票证劵类业务，如：手机商界、大智慧等
17
安全杀毒
提供网络安全服务的应用，如：360安全卫士、麦咖啡等；以及网络恶意流量，如：病毒、攻击等
18
其他业务
DPI设备子业务识别能力要求（部分）
业务类型
子业务
序号
子业务名称
优先级
备注
即时通信
1
飞聊
必选
自有业务
2
飞信
必选
3
Gtalk
必选
互联网业务
4
MSN
必选
5
QQ
必选
6
TM
必选
7
阿里旺旺
必选
8
米聊
必选
9
必选
10
人人桌面
必选
11
AOL AIM
可选
12
Gadu_Gadu
可选
13
go聊
可选
14
ICQ
可选
15
IMVU
可选
16
Lava-Lava
可选
17
NetChat
可选
18
Paltalk
可选
19
PowWow
可选
20
TeamSpeak
可选
21
Trillian
可选
22
VZOchat
可选
23
Xfire
可选
24
百度Hi
可选
25
都秀
可选
26
陌陌
可选
27
天翼Live
可选
28
翼聊
可选
29
网易泡泡
可选
30
新浪UC
可选
31
新浪UT
可选
32
雅虎通
可选
需要展现的结果
如图所示，需要根据计算，得到不同小区的上网能力，具体包括：应用的欢迎程度、网站表现、小区上网能力和小区上网喜好。通过点击某个大类下的小类的详情。
1.2.zebra整体分析
1.2.1.zebra整体流程
如下图所示，用户通过网络设备访问达内才高网站，通过电信运营商的被记录成日志的形式，日志数据由运营商收集，并以单位时间形成一个文件的形式存放到本地硬盘上。通过zebra对数据进行分析处理，将处理后的结果放置到关系型数据库中，通过web图形化的方式展示不同小区的上网详情！
1.2.2.zebra整体思路设计
单机处理方式
这种方式会将数据的读取（即从本机的硬盘读取到本机的内存的过程）和运算以及数据持
久化都集中在一台机器上。这台机器要完成数据读取、数据运算和数据持久化工作，压力比较大。
考虑使用多机的处理方式
可以考虑利用人多力量大的思想，使用多台机器合作处理多个文件！
问题：多台机器之间如何协调和分工？哪些机器负责数据读取？哪些机器负责数据的运算？
多机处理方式
这种方式会将数据的读取和传输（传输，即从一台机器的内存到其他机器的内存的过程）交给一台机器，这台机器只负责数据的读取和传输，减轻自身压力！再由其他机器负责数据运算和持久化，提高处理能力。
最终选取方式
我们将集中负责数据读取和分发的机器称之为一级引擎，其他负责运算和数据持久化的
机器称之为二级引擎。
最终方式角描述
我们的方案最终的结构如下：一级引擎负责数据的读取和分发，二级引擎负责数据的计算和持久化。
2.1.技术准备
因为整个项目中运用了java中nio相关的api和大量的urrent包（并发包）中的类和接口，所以我们在正式实现整体项目之前先对nio和并发编程进行学习！
2.1.1.任务的概念
在程序和生活中都有任务的概念，任务本身是一个宽泛的概念，在生活中，一个任务可以是吃一顿饭也可以是一次旅行。在程序中也是如此，可以是读取一个文件，也可以是获取文件的绝对路径。总结来说，任务可大可小，一个大任务可以是通过一堆小任务堆积组成，
即任务是可嵌套的。具体到程序中，一个最小任务就是一个执行单元，所以在不同上下文中所指的任务可能完全不同！所以，我们要在具体的场景下来说明基于这个场景中的任务是什么。
2.1.2.线程递减锁
场景
现有一营销公司，其内部共有三个员工和经理、老板，员工有小王、小李、小张。现在项目经理分配了一个任务，公司有一个Excel文件，内含有1500条客户数据，每条数据都是一条包含客户电话号码的客户的资料，员工根据每条数据的资料给客户打电话进行推销，理分配给三个人每人500条，等这个Excel都处理完以后项目经理向老板申请给大家放假。在这个场景下我们就可以使用线程递减锁来控制整个工作的流程，保证所有人的任务都完成后再由项目经理告知老板工作做完了。
概念
线程递减锁是jdk1.5在uent并发包中提供的一个类CountDownLatch，提供了
高级的类似线程的wati和notify机制。
示例代码
详见zebrademo中关于线程递减锁的示例
总结
一个同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待
2.1.3.阻塞式队列
场景
我们有一个数据生产者（运营商）和一个数据消费者（处理数据的程序），为了使应用程序可以高效的运行，我们需要提供一种等待机制，即在生产者的生产能力较弱时，消费者可以在等到生产者生成数据之后再进行消费，程序不会中断。在这种情境下，生产者和消费者之间要有一个存放数据的容器，这个容器就可以用一个阻塞式队列来充当。
阻塞式队列本身就提供了这种等待机制（我们更习惯称之为阻塞机制，都是一个意思）。
概念
阻塞式队列也是jdk1.5在uent并发包中提供的一中更加方便的添加了阻塞功能的队列。共有两种类型，一种是ArrayBlockingQueue,这种类型的队列在构造时就需要指定队列中能存放的数据的总条数。另一种是LinkedBlockingQueue,这种类型的队列在构造时可以不需要指定队列中的数据的总条数，可以无限扩容（当然需要在jvm可用的内存空间的基础上）。
原理
其实阻塞式队列的本质就是在队列的基础上加上了阻塞机制，可以防止因队列中数据填满造成队列已满异常或队列中没有数据而造成空指针异常。其改进之后表现为，可以在队列中的数据填满后一直等待，直到队列中有空闲位置时才继续插入，或者在队列为空之后一直等待，直到队列中有数据之后再继续取出。
示例
详见zebrademo中关于阻塞式队列的示例
2.1.4.线程池执行器
场景
电信运营商（移动、联通、电信、铁通等）的手机用户的上网数据，使用多个处理线程来进行处理，需要一个任务管理和分配的一种机制，线程池管理器就可以实现这种机制。
概念
场景：多线程程序设计
情况一:线程数据和任务数量正对应，这时候我们一个线程管理一个任务即可
情况二：假如我们的机器的cpu是双核的，我开启两个线程是最高效的，我们想要以最高效的形式进行处理，这时候就会导致一个问题，有一个任务暂时无法处理，这时候我们怎么办？
情况三：我们可以使用一种方式，将其记录下来，等前两个任务处理完成之后再接着处理第三个任务，这样可以一直高效的进行程序处理。
情况四：一下子来了六个任务，如果我们使用的记录方式只能记录有限个数的任务，当待处理的任务填满记录器之后，我们该如何处理？
情况五：这个时候没有更好的办法，我们只能再多开几个线程将待处理任务记录器里面也放不下的任务直接处理了，但是这时候的整体处理效率会降低。
情况六：最复杂的情况，在现在的情境下一下子来了大于六个的任务，核心线程在处理的同时待处理任务记录器也记录满了，重新开了俩线程也都在执行任务，实在没有办法了，只能采取措施将不同的任务拒绝了。
思考：为什么不无限制的多开线程来处理多个任务呢？
原理
线程池执行器，即是一个负责任务分配管理的线程。可针对不同的情况选用不同的应对策略。
示例
详见zebrademo中关于任务管理器的示例
2.1.5.NIO文件读写
详见zebrademo中关于NIO的示例
2.2.预处理（前置清理）
2.2.1.预处理概念
因为我们指定的存放待处理数据的的目录下可能存在一些以前存放的无用数据，可能会影响我们后续的一系列的处理流程，故我们先通过一个前置过程将其删除掉，这个过程我们就称之为预处理（也可以称之为前置清理）。如下图所示。
2.2.2.预处理流程图
需要注意的是，这里要使用递归删除，保证指定的目录下为空。
2.2.3.技术实现demo
du.file;