基于Hadoop平台的网络流量分析系统的设计与实现.docx

《基于Hadoop平台的网络流量分析系统的设计与实现.docx》由会员分享，可在线阅读，更多相关《基于Hadoop平台的网络流量分析系统的设计与实现.docx（34页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、摘 要为了解决网络使用过程中产生恶意流量而影响用户体验及网络安全的问题，设计了网络流量分析系统。应用了离线数据分析的方法，采用Hadoop生态系统、WireShark捕获报文工具和数据可视化图表完成了对TCP/IP协议网络流量进行储存和分析的设计。在Windows系统和Hadoop平台相结合的环境下进行了开发实现，结果表明：该系统能够解决恶意流量对网站或企业内网造成安全影响及网络资源占用的问题，具有可直接观测流量走势和存储大小可扩展的优势。关键词：Hadoop；网络安全；恶意流量；网络流量分析AbstractIn order to solve the problem that the user

2、 experience and network security are affected by the malicious traffic in the process of network use, a network traffic analysis system is designed. The design of TCP/IP network traffic storage and analysis is completed by using the method of offline data analysis, Hadoop ecosystem, WireShark captur

3、ing message tool and data visualization chart. The results show that the system can solve the problems of malicious traffic causing security impact on websites or intranets and occupying network resources. It has the advantages of direct observation of traffic trends and scalability of storage size.

4、Key words： Hadoop；Network security；Malicious traffic；Network traffic analysis目 录第一章 课题绪论11.1 研究背景和意义介绍11.2 网络流量及网络攻击11.3 研究现状31.4 论文结构安排3第二章 相关背景技术52.1 系统开发工具52.2 Hadoop生态圈相关技术的简要介绍5第三章 需求分析93.1 可行性分析93.2 安全性分析93.3 系统功能分析103.4 数据流量图10第四章 概要设计134.1 系统各层设计134.2 数据库设计18第五章 算法实现225.1 协议占比算法和宽带使用占比算法225.

5、2 协议长度算法23第六章 系统测试256.1 Hadoop生态组件启动测试256.2 数据库连接测试27第七章 总结28参 考 文 献29致 谢30广东东软学院本科生毕业设计（论文）第一章 课题绪论1.1 研究背景和意义介绍近年来，互联网的发展速度一年比一年快，与此同时，网络流量每天都处于快速增长的状态，网络的规模和结构也变得日渐庞大且复杂，而面对采样时间的增加，数据存储量和计算量与日俱增，需要有一些有效工具可以对其进行管理。此时，对于海量网络流量数据的收集存储和统计分析已成为一个急需解决的问题。除此之外，近年来还有一个涉及面很广泛的问题值得我们留意，那便是网络安全。大多数情况下，网络安全性

6、问题都是人为引起，攻击者总是试图获得某些好处，这样的网络安全事件已经越来越多，慢慢地在各个领域渗透，并逐渐影响受害者的正常生活，比如个人信息被盗取、网站遭受攻击等，严重的还会破坏公共设施甚至是危害国家的某些重要系统，假如是后者，那带来的经济损失更是不可估量，同时还会严重影响社会的繁荣稳定。不论是个人还是企业，甚至是国家，我们都应该重视网络安全，重视“大数据隐私”。当前社会，对于网络流量的储存和分析已经越来越重要了，而对于统计出来的流量进行安全检测和分析更是一个重要的环节，就以网站来举例，对网站分析时我们会不断从网站上获取最新的流量数据，而在这过程中我们其实就已经对网站做了一个初步的监控，我们可

7、以上实时地了解网站的网络流量变化，并通过相关的指标检测是否受到安全攻击，而在企业中，除了相应的安全检测，还可以对内部流量走向做出分析并合理安排，本系统就是用于这一类情景进行网络流量的统计和分析，进而通过相应的指标检测网络安全性，这也是本课题的意义所在。1.2 网络流量及网络攻击（1）网络流量网络流量即为上网过程中传输的数据流量。网络是当今互联网时代的基础设施，信息传递、沟通交流、办公服务等都需要依靠网络来完成，网络的质量直接影响了社会生活和经济发展的质量。伴随着网络的广泛应用、网络接入设备的增加、网络拓扑的结构复杂化，网络流量正处于不断增长的过程中，为有效的管理网络、维护网络安全，需要对网络进

8、行测量和分析。与些同时，基于传统的单机串行方式的数据算法在时间复杂性和空间复杂性上遇到了瓶颈，同时平台信息的存储能力和计算能力已经很难满足我们在实际生活中应用的要求，退而求其次采用数据抽样技术又会明显降低我们测量的准确性和实用性，所以，对于如何高效、快速的对网络流量进行测量、存储和分析是当代社会所研究的一个重点，这也是本次研究的意义之一。（2） 网络流量攻击流量指的是网络资源，也是防火墙处理能力。而网络流量攻击简单而言指的就是DDoS和DoS等类型的网络攻击，这类网络攻击在生活中我们常遇到就有带宽攻击和应用攻击，通常它的攻击方式就是让大数量的数据包去攻击一台或者多台服务器，目的就是让庞大的数据

9、流量去冲垮服务器，让网站处于非正常状态，使得用户无法正常打开或使用，被攻击的对象还有防火墙和路由器，原理相当。此外，再谈谈CC类连接攻击，它也归属于流量攻击，通俗来讲就是模拟多线程用户直接击打被攻击方要害部位的行为，聪明的攻击者会通过代理服务器和网站的大流量页面进行无休止地连接，浪费网站大量的CPU资源，造成其服务器资源疲于供应。同时，无休止的访问代表无休止的连接，这会造成网络阻塞，影响用户访问网站，而为什么说攻击者聪明呢，代理服务器的加入让人很难发现攻击者的位置对其进行反击，所以说CC是一个强横的流量攻击方式。试想一下，一个不知名的网站有多大的概率遭受网络攻击？若不有利可图，很难有人会浪费大

10、量的时间、精力和资源去攻击一个小网站，得不偿失。在这网络安全维护和攻击并存的时代，越多流量访问的地方才越容易遭受网络流量攻击，一个网站很容易遭受竞争者的嫉妒和破坏，有时过大的流量访问不止意味着你受到广大用户的喜欢和支持，也可能是受到了某种流量攻击。攻击者会根据一系列的漏洞，使用合法的数据请求技术，其中就有我们刚提到过的DDoS攻击，我们说过攻击者是很聪明的，代理服务器的出现让DDoS攻击成为当下网络中最难防御的网络攻击之一，同时它的入门门槛非常低，即使是没有基础的群众都能使用，这就使得那些不同懂技术防护的用户极其容易中招。正因如此，DDoS攻击在经济上带来的损失已经稳居榜首，它造成的影响不容小

11、觑。（3） 泛洪攻击常见的泛洪攻击有很多，本论文中主要研究的方向是ARP泛洪攻击。常见的ARP攻击主要有两种，一个是ARP欺骗，另一个则是本流量系统所研究的ARP泛洪攻击，它也被称为拒绝服务攻击。ARP欺骗以盗取数据为目的，通过发送经过伪造的报文去更改网关地址，实现交换网络下的数据嗅探。ARP泛洪攻击则是以捣乱破坏为目的，通过攻击主机，持续发送无法解析的ARP报文，造成设备上的ARP表项溢出，抢占网络带宽和资源，阻碍报文的正常转发。ARP欺骗和ARP泛洪攻击都会影响用户的网络稳定，且容易造成企业和网站的网络事故。假如攻击者想通过这类非法行为获取网站或企业的个人信息的话，造成的利益损失更是不可估

12、量。虽然人们现在对ARP攻击已经有着足够认识，但是对于当前多种多样的ARP攻击，防御能力上还是略有不足。（4）以太网帧攻击在网络中，以太网链路上最底层的含MAC地址的数据包被称为以太网帧，有一种攻击方式源自于它，名为小型帧攻击和巨型帧攻击，它的原理是利用并发送小于40或大于5119的数据包对网络进行攻击，它们可能会成为融合网络的障碍。就以超长帧来举例，如果有一个庞大的数据包在线路上传送，一旦长时间占用线路，就会造成网络延迟，从而影响其他人对线路的使用。而小型帧攻击则是以数量来取胜，影响网络的处理效率。在本系统中就是通过查看数据包长度统计观察这些异常数据包占网络总数据包的百分比来发现是否存在攻击

13、或其他网络问题。1.3 研究现状在互联网发展的前数十年中，有许多的网络流量分析工具被广泛应用其中包括WireShark、Snort、SILK、Tcpdump等，不得不说，这些分析工具功能颇多，既有网络测量又有性能测量，既有主动测量又有被动测量，它们的相继出现为网络流量分析做出了巨大的贡献。网络流量以量为主，里面包含着许多重要的网络信息，比如个人用户信息，系统运行信息等。但是近几年来，随着网络数据流量的爆炸式增长，对网络流量分析的处理和捕获变得极其困难，传统的基于单点的网络流量分析方法已经很难满足高并发的场景，因此分布式网络测量的概念也进入了大众的视野。1随着云计算技术的出现，Hadoop生态圈

14、成为了当代高速运算和存储的一个热点，传统的单点网络流量统计工具遇到大规模或者大流量同时进行的场景，就变得心有余而力不足，更别说是进行流量分析了。Hadoop平台则很好的突破了这一限制，因为它允许更大范围的网络扩展。Hadoop是一个集群，在企业中，当集群的计算能力不足时，我们只需要往集群中加入一个或多个节点，就可以恢复甚至是加快集群的计算速度，这就很好的避免了花钱再买新机器的问题，可以节省大量成本。在如今的互联网时代，基于Hadoop的网络测量研究仍处于初级阶段，如何利用云计算平台的分布式及其高并发的特性来处理网络流量并且利用这些网络流量进行安全分析是当代网络测量的发展方向，也是本次研究的目标

15、方向。21.4 论文结构安排本文一共分为六章，每个章节主要内容如下：第一章首先介绍了本课题的研究背景以及研究意义，接着简要地概括网络流量的含义以及当代网络上经常出现的网络攻击模式和概念，最后总结当前该课题在社会上的研究现状。第二章是对本网络流量系统中使用的开发工具以及Hadoop生态圈相关技术两者的简单介绍。第三章是对本课题的可行性分析、安全性分析以及系统功能分析，最后是流量数据图的展示。第四章是系统的概要设计，即如何收集和存储系统所需要到的数据，并合理地设计各个不同类型的数据库。第五章介绍了本系统中的数据算法是如何实现的，其中包括协议占比算法、协议长度算法、宽带使用占比算法。第六章对系统进行

16、测试，先是对Hadoop平台相关组件的启动测试，然后测试系统连接数据库是否成功。30第二章 相关背景技术2.1 系统开发工具常用的Java开发工具有IDEA，MyEclipse，Eclipse，EditPlus，VSCode等，本次研究使用的是IDEA，全称IntelliJ IDEA，IDEA无论是在企业还是教育界都是一致好评，主要用于Java开发。在我的Java学习过程中，IDEA和Eclipse的使用次数比较多，因为它们在功能上比较齐全，不过两者还是存在一定的差别。用惯了Eclipse，MyEclipse的人换成IDEA会有很多不习惯，但是当你开始使用IDEA后会现在，IDEA的功能不可谓

17、不强大，首先是它人性化的代码补全功能，在开发项目的过程中，很多代码的格式都是一样的，都可以快速补全，对于变量的封装在这一块就体现的淋漓尽致。其次是它的操作界面，简洁明了，可以快速查看编程错误，许多小功能也是完善的十分好，在此不做赘述。2.2 Hadoop生态圈相关技术的简要介绍（1）Hadoop HAHadoop集群是一个对大数据进行存储计算和分析的分布式开源框架，它设备廉价为优势而广受欢迎。Hadoop在分布式系统的体系结构上以分布式文件系统HDFS和计算框架MapReduce为核心构成一个庞大的项目，它的优点是即使用户不了解分布式的底层结构，甚至没有相应的开发基础，依然能够使用Hadoop

18、集群进行数据处理和分析。这几年，大数据处理在互联网中越来越热门，有这一方面技术的人才也越来越吃香，很多人在Java学习地足够深入后都会开始向Hadoop的源码进发，要知道Hadoop是一门实践技术，对提升自己的分布式思维和编程实力具有相当高的学习意义。3我们知道元数据是数据的数据，如果元数据发生破坏，整个HDFS就失去了意义，而在HDFS集群中NameNode容易出现单点故障，导致整个集群无法正常使用，那么元数据的备份和集群就高可用在这个时候就显得十分重要了，所以在Hadoop2版本中引入了HA的方案和YARN架构，基于Zookeeper协调服务实现资源管理及失效恢复功能，即实现Hadoop的

19、高可用。HA集群提供方案其实和原有集群相类似，只不过多了一台待机节点，集群通过ZKFC机制进行监控，当原有活动节点出现故障时，待机节点就会进行切换，代替成为活动节点进行动作，同时负责对外提供服务。待机节点通过获取活动节点共享存储的Meta信息，保证数据的完整性，同时两个节点的信息都时刻汇报给ZKFC，随时待命以保证集群正常运行不间断。Hadoop HA高可用性集群便是通过系统的可靠性和可维护性来度量的，即无故障时间和平均维修时间4，从而我们可以得出，当一年的宕机时间越短，集群的高可用性就越高。（2）分布式文件系统HDFSHDFS分布式文件系统意如其名，用来提供底层数据存储支持。大数据时代，设计

20、一个文件系统需要考虑的方面很多，其中就包括存储格式和利用性等。HDFS就旨在能存储大流量数据，并通过分布式的特点存储到多台机器上。前面我们就说过，集群的其中一个优点就是可扩容，这恰好就是HDFS的优点之一，它适合用来存储大文件。HDFS的特点还有很多，就比如它是流式访问数据，保证快速响应用户写入和读取的请求。HDFS建立在Java上，用来储存大规模数据，它的结构严谨，不允许进行改变，不支持动态储存，适合于储存一次后数据不再变动再进行多次分析的场景。所以HDFS最适于执行批次分析，而它最大的缺点就是无法执行实时分析。总的来说，HDFS就是一个分割大流量数据文件进行存储的集群式文件系统，它支持一次

21、写入多次读取、无法交互、不支持任意修改，其设计的目标在于硬件故障常态化、流式数据访问、大数据集、移动计算比移动数据更经济这四点上。（3）HBaseHBase即Hadoop Database，是根据Google三大论文之一的Big Table概念模式所设计出的一个分布式、列储存形数据库。HBase是基于Java NoSQL数据库，它允许数据进行变动，本身就是一个应用平台，它适用于随机读写储存在HDFS是的数据，所以HBase的定位是处理毫秒级高并发的大数据的一种OLTP实时数据库。我们可以认为HBase是HDFS的一个包装，它的本质是部署在HDFS的非关系型分布式数据库，不支持事务处理，它的表结

22、构由Row、Column Family、Column、Version和Cell组成，在HBase表中，本身没有数据类型这一说法，（4）HiveHive是建立在 Hadoop之上提供SQL方式分析数据的框架，它被称为数据仓库，其本身不负责存储和计算数据，它的原理是通过将SQL语言转換成 Mapreduce程序，并提交到Yarn上运行，读取HDFS上数据进行处理完成操作，我们可以理解为Hive一个逻辑表，与HBase有极大的不同。本次研究也是通过使用HQL语句来代替MapReduce进行数据分析，相比于MapReduce，Hive在企业中得到了更加广泛的应用，因为它拥有更友好的接口以及更低的学习成

23、本。此外，Hive数据仓库需要存储的部分有两个，存储数据的地方也有两个，它将数据文件存储在HDFS上，将用于记录Hive中数据库和表信息的元数据则保存在数据库中。默认情况下Hive自己使用Derby数据为师来存储元数据信息，但是我们更推荐把元数据存储在关系型数据库中例如Mysql数据库，因为Derby一次只能打开一个会话，比较适合做本地开发测试，对于高并发的开发情况并不适用，所以在企业中通常都会删除自带的Derby换成其他关系型数据库，本流量系统用的是Mysql数据库。（5）ZookeeperApache ZooKeeper是一个分布式应用程序协调服务，它提供了一种集中式信息存储服务，可以看做

24、是一个数据库。Zookeeper在分布式系统中的地位很高，在高并发的场景中，单台服务器无法撑起多线程进行同步访问，这个时候就需要到分布式锁来协同共享资源。基于数据库和Redis实现分布式锁没有Zookeeper锁来的简单可靠和高性能，所以它对于Hadoop集群十分重要，常被用来封装易出错的服务。 Zookeeper主要应用在Hadoop和Hbase上，它的底层算法决定了它能用来保证高可用集群的协调和一致性，其中就包括ZKFC故障转移机制和Regionserver管理，它们都是依靠Zookeeper来协调数据。除此之外，Zookeeper还可以在它自带的文件系统里处理数据管理问题，比如命令服务和

25、管理配置。5因此，在本流量分析系统中，Zookeeper除了用来协调Hadoop和HBase之外，还用来管理Flume集群的Agent配置和Kafka集群的Broker服务器，充当存储元数据和交换集群信息的工具，提高集群效率。（6）FlumeFlume是Cloudera开发的分布式日志收集系统，直到现在共发行了两个版本分别为FlumeOG和FlumeNG，均可用于日志数据的采集和解析。Flume比较强调用户的自定义开发，单单是配置种类常用的就有五种，其中包括netcat source监听客户端、syslong tcp source监控网络进行数据收集、使用httpsource监控浏览器、exe

26、c source进行日志数据收集并通过HDFS保存、spool souce监控文件夹新增文件进行日志数据收集并通过file rool sink进行保存等方式，综合来看，它更偏重于数据的传输，数据存储在HDFS或HBase上。Flume由内置的Source、Channel和Sink组成，它们三者都能进行自定义组合并通过event格式的消费数据进行传输。Flume经常和Kafka组成集群使用，在本系统中，共有三台Flume机器，有两负责收集数据并实现负载均衡，另一台负责汇总数据并将不同的数据发送给Kafka消息中间件，保证数据的顺利传输和完整性。（7）KafkaKafka是一个分布式消息订阅系统，

27、官方称之为实时数据处理系统。在系统中，当一个程序向另一个程序发送消息，就会形成一个通道，过程简单明了，但是当程序开始变多起来，他们之间的通信链路就会像蜂窝一般复杂。在这种通信系统中，每个人都做着独立的工作，这样就会赞成很多其他的问题。第一，可能发送重复信息，造成资源浪费。第二，当信息过多无法同步时容易造成信息的丢失。第三，各个程序之间相互依赖耦合度太高。这时，一个消息发布和订阅系统就显得很重要了，当接收者需要时再读取消息，这就是kafka的作用了，保证消息的完整性，同时充当一个消息中间站。Kafka的一个服务器称为一个broker，broker中有一个或多个主题topic，发布者发送各种主题，

28、broker为其排好偏移量，消费者就可以选择需要的topic下的指定偏移量接收消息。在topic中有一个或多个分区 partition，一条消息包含了主题，分区，键和值四个部分，分区器会根据算法指引消息被接收。在一个分区里，数据偏移量是唯一的，消费者需要按顺序读取指定偏移量的数据。Kafka支持MQT，创建一个topic是一个很重的操作，Kafka仅仅可以作为MQT的输入。Kafka提供了流式计算可以做一些数据的初步清理。Kafka是落地磁盘，顺序读取磁盘的速度要远高于内存读取。第三章 需求分析3.1 可行性分析基于Hadoop平台的网络流量分析系统主要目的分析网络流量，通过数据捕获软件对收集

29、的数据包进行统计分析，并将最后的分析结果通过图表形式显示在HTML5页面上。在确定系统的开发目标后，对系统做出以下几方面可行性分析。（1）技术可行性：系统主要使用数据捕获软件+Hadoop下各生态组件+数据库+JAVA+HTML5结合的形式进行开发。对于数据捕获软件，目前市场上对其版本功能已多次完善，界面简洁易懂且功能强大。Hadoop旗下各生态组件符合分布式的开发要求，并专注于大数据的存储和计算，尤其是在Cloudera公司推出CDH后，兼容性和稳定性大大提升。而JAVA和HTML更是广泛的应用在企业开发中，二者结合后，不论是在后台开发，前端设计亦或是数据库的调用开发，都趋于成熟。综上所述，

30、本系统具备开发的技术可行性。（2）社会可行性：当代社会，传统公司已开始跟不上潮流，在未来，互联网公司才是大趋势。互联网公司中，分布式必将盛行，网络安全和管理更是重中之重，互联网公司是离不开网络的，对于网络流量的操作和管理分析更是不可或缺。尤其是在成本上，Hadoop具有极高地位，本系统既易于操作，又易于观察，成本和可行性更是一大亮点。综上所述，本系统具备开发的社会可行性。（3）法律可行性：本系统作为一个自主研发系统，可在各企业中广泛应用，开发环境及代码都已开源，且数据来源于企业本身，所以不存在违法犯法行为。综上所述，本系统具备开发的法律可行性。3.2 安全性分析Hadoop是一个集群，通常都用

31、于企业中，在最初的情况下多用于对大量公共的数据进行管理，用户间的数据信息都能做到很好的保密，所以并不需要考虑到保密安全性。但是随着大数据的发展，内部的用户安全威胁也受到了关注，无论是恶意删除数据或者善意的犯错误删，都可能造成极大的损失。所以本次研究中，对内部保密做了进一步的修改，系统首先对用户配置进行设置，不发放普通用户的root权限，只对可信赖的个别用户发放root密码。同时，系统对文件的位权限控制进行了修改，将HDFS文件包括本地文件的权限组所有者都改为root用户，防止普通用户进行数据删除。63.3 系统功能分析本系统的实现功能是通过对Hadoop集群对TCP/IP协议数据包的离线分析，

32、主要的功能是基于引入的百度Echarts图表实现页面可视化。集群设计由三台服务器构建组成，主节点Bigdata-01、从节点Bigdata-02和Bigdata-03，同时在从节点Bigdata-02上进行HA待机节点设置。集群通过从节点保存数据，然后在主节点上完成分析操作。此外，Hadoop集群可以根据实际需要对节点机器进行扩展。前端页面共有三种图表，分别为饼状图，柱形图，折线图。通过饼状图上的协议类型，选择任意个数的协议，可以更直观的看到协议所占百分比，而折线图和柱形图能实现很直观的查看数据。3.4 数据流量图（1） 协议占比柱形图,如图3-1所示。图3-1 协议占比柱形图（2） 协议长度

33、折线图、协议长度数据视图分别如图3-2，图3-3所示。图3-2 协议长度折线图图3-3 协议长度数据视图（3） 宽带使用占比饼状图，如图3-4所示。图3-4 宽带使用占比饼状图第四章 概要设计4.1 系统各层设计（1）数据源层使用Wireshark对本机2019-12-2517：00-18：00进行一个小时的数据包捕获，其中数据源层的数据结构为：No+Time+Source+Destination+Source port+Destination port+Protocol+Length+Info，如图4-1所示。图4-1 Wireshark捕获内容（2）采集层考虑到数据包以Pacp格式文件既不

34、是按行处理的文体格式也不有固定长度的二进制文件，所以我们通过csv文件格式保存，再另存为带空格符格式的txt文档，最后分别保存在Hadoop集群两台从节点DataNode下的log日志文件中，如图4-2和图4-3所示。图4-2 从节点Bigdata02下的日志内容图4-3 从节点Bigdata03下的日志内容（3）存储层DataNode下的log日志文件我们以Flume+Kafka+Hbase的集群模式导入到HBase数据库中保存。此时，本系统模拟的是实际企业场景，所以用代码将日志文件逐行打印模拟日志产生。并使用Flume下的Spool sources模式，监控文件夹新增 文件进行日志数据收集

35、，日志产生过程如图4-4，图4-5所示。Flume+Kafka收集系统过程如图4-6，图4-7，图4-8，图4-9，图4-10，图4-11所示。除些之外，在Hive数据仓库中，对HBase的数据创建一个外部表进行最直观的查询操作。当收集进行一定的量后，运行HQL，之后将数据另外通过Sqoop导入到Mysql数据库中，方便页面连接查询。具体过程如图4-12所示。图4-4 从节点Bigdata-02模拟产生日志图4-5 从节点Bigdata-03模拟产生日志图4-6 主节点Flmue收集日志图4-7 从节点Bigdata-02 Flume收集日志图4-8 从节点Bigdata-03 Flume收集

36、日志图4-9 主节点Kafka运行状态图4-10 从节点Bigdata-02 Kafka运行状态图4-11 从节点Bigdata-03 Kafka运行状态图4-12 Sqoop将Hive数据转移到Mysql（4） 并行算法层本系统的并行算法层，是通过HQL语句完成，Hive将接收到的SQL语句进行转化为MapReduce完成算法，整个编译过程分为六个阶段，简单来说就是将接收到的SQL进行解析，再通过查询遍历转化为相应的Mapreduce逻辑任务，同时提前优化不必要的数据量。具体过程如图4-13所示。图4-13 Hive中SQL查询的MapReduce作业转化过程（5）服务层本系统服务层使用JD

37、BC API建立Mysql数据库连接。JDBC的意思就是Java数据连接，是Java的一个能执行SQL语句的API接口。JDBC有自己的一套写法，可以访问多种关系型数据库，它提供了统一的借口发表编程开发。在开发过程中，需要引入Jar包，然后配置JDBC和加载驱动，过程方便简单。（6）接口层本系统接口层使用IDEA建立一个基于Maven的WebAPP工程，在Socket端选择实时器WebSocket协议。WebSocket在H5以后提出的一个通讯协议，它的运行依靠于TCP/IP协议，不同于旧web模式中的被动发送消息，它可以实时在客户端和服务器之间互相交换数据，具有节省服务器和带宽资源的优点。7

38、（7）展示层本系统基于百度Echarts图表框架，将数据与图表进行连接呈现。Echarts工具是百度旗下的一个用于统计分析后展示各种图表的js插件，可以自定义样式，简化开发，用于图形可视化。4.2 数据库设计（1） HBase数据库设计对于Hbase来说，最重要的就是rowkey的设计，rowkey需要具有唯一性，且设计时需要遵从长度规则以及主键查询高效的特点，以提高系统性能。所以本系统HBase数据库rowkey的设计为：id+datatime+system.nanotime（），既报文捕获时的ID和时间簇以及插入数据库时的时间纳秒值。而列簇的定义是与捕获的数据相同，即为：id+datati

39、me+source+dst+src port+dst port+protocol，HBase数据库信息如图4-14所示。图4-14 HBase数据库描述（2） Hive数据仓库设计Hive数据仓库相当于是一个逻辑表，所以在执行HQL语句时直接在前面加上insert into table protocol_count、insert into table protocol_length、insert into table src_count就会自动新建适应表，数据类型一般为String和Int，Hive数据仓库描述如图4-15所示。图4-15 Hive数据仓库描述（3） Mysql数据库设计Mys

40、ql数据库的数据内容需要和Hive数据库的protocol_count、protocol_length、src_count三个表保持列名一致，否则无法进行转换。但是数据类型需要根据数据进行修改，protocol_count、protocol_length、src_count三个表的表结构设计分别如表4-16、4-17、4-18所示。表4-16 protocol_count表的数据结构数据结构成员数据类型含义说明protocolvarchar（8）协议名称countint（11）个数统计表4-17 protocol_length表的数据结构数据结构成员数据类型含义说明protocolvarcha

41、r（16）协议名称maxint（11）报文最大长度minint（11）报文最小长度表4-18 src_count表的数据结构数据结构成员数据类型含义说明srcvarchar（16）源地址ipcountint（11）个数统计Mysql数据库描述如图4-19所示。图4-19 Mysql数据库描述（4） Mysql与HBase对比本系统采用两个数据库混合使用，另加上Hive这一逻辑数据仓库，因而需要明确不同类型数据库在系统中的职责和使用范围，以确保系统数据库设计的合理性。在上述文段中，已经明确了各个数据库的数据结构，现在就来分析一下它们之间的优势和不同。相比于Mysql，HBase的架构特点：一是完

42、全分布式(数据分片、故障自恢复)，二是底层使用HDFS(存储计算分离)。由架构看到的能力差异：Mysql运维简单(组件少)、延时低(访问路径短)，Hbase扩展性好、内置容错恢复与数据冗余。由引擎结构(B+ Tree vs LSM Tree)看到的能力差异：Mysql读写均衡、存在空间碎片，HBase侧重于写、存储紧凑无浪费、IO放大、数据导入能力强。从数据访问上看相同之处：数据以表的模型进行逻辑组织，应用对数据进行增删改查。不同之处：Mysql的SQL功能更丰富，事务能力更强。HBase既可以用API进行更灵活、性能更好的访问，也可以借助 Phoenix使用标准SQL访问，只支持单行事务。从

43、生态上看，Mysql一般可独立满足在线应用的数据存储需求，或者与少量组件配合(如缓存、分库中间件。HBase一般需要和较多大数据组件一起配合完成应用场景，场景架构的设计、实施存在较大的挑战。5总结来说，Mysql侧重于在线应用，HBase侧重于大数据量场景。第五章 算法实现本次研究是通过HQL语句代替MapReduce的复杂代码进行统计分析并将分析结果保存在数据库，所以算法部分为sql语句。在此，我们用MapReduce的思路及伪代码进行算法解释。首先，对于协议占比算法和宽带使用占比算法而言，采用的是WordCount词频统计加上Group By(分组排序）和Order By(全排序)，使其有

44、序（字典序），所以他们的算法和代码都是相同的。而对于协议长度算法则是在按照两个字段进行排序的基础上进行长度的最大值 max和最小值min判断。5.1 协议占比算法和宽带使用占比算法协议占比算法的HQL语句为：insert into table protocol_count select protocol，count from protocolflows group by protocol order by protocol desc。宽带使用占比算法的HQL语句为：insert into table src_count select src，count from protocolflows g

45、roup by src order by src desc。对于两个算法而言，数据不一样，但是算法内容完全相同。就以协议占比算法来举例，首先实现的是Mapper接口中的map方法，输入的参数中键是数据库名，value是协议算法中需要到的协议名即数据库中protocol的全部数据，将所有数据拆分成单个数据，每产生一个中间键值对就输出结果，最后写入到OutputCollector中。接着实现Reducer接口中的Reduce方法，得到输出中间结果，最后只要将所有value相加就可以得到各个协议出现的次数。8排序指的是对查询结果进行排序顺序显示，Group By/Order By均需要在Reduce

46、阶段完成。全过程伪代码如下：Alogorithm Function AccountedForInput:Output:OutputCollectorBegin1:map(String Key1, String Value1)2:/map阶段分组处理数据，对出现数据进行累计和标记3:/ Key1: 数据库protocol；Value1: 数据库内容4:for each word p in Value1: 5:EmitIntermediate(p, 1);6：end map 7:reduce(String w, Iterator Values) 8: /reduce阶段进行词频统计和排序9:/ p

47、: 一个协议；Values: 计数列表 10: int result = 0; 11: for each v in Values: 12: Count += ParseInt(v); 13: Emit(AsString(Count);14: compareTo (Key1,Count)15: /函数compareTo用于对统计后的协议进行排序16: Collections.sort(Key1,Key1+n)17: end compareTo18: OutputCollector(key2,value2)19:end reduceEnd5.2 协议长度算法协议长度算法的HQL语句为：insert into table protocol_length select protocol，max(length+0) as max，min(length+0) as min from protocolflows group by protocol order by protocol desc。长度算法对比占比算法，多了一个字段数据，同时多了最大最小值的判断9，所以算法逻辑相对复杂一些，其伪代码如下：Alogorithm Function ProtocolLengt