Paper Reader:Analysis Farm: A Cloud-based Scalable Aggregation and Query Platform for Network Log Analysis

2016-04-19

15 min read

这篇论文的主要内容是实现了要给日志分析的原型系统，其最底层使用OpenStack虚拟，数据存储层使用mongoDB。文中通过几个实验阐述了这一套架构的可扩展性和可行性。作者是上海交大的几个同学。我主要翻译相关技术内容，其研究实际背景和人称与原文可能多有所出入。论文地址

#0. 摘要

网络监控数据可以提供与网络数据状态相关的信息。通过频繁的探针、取样、记录网络活动，生成的大量监控数据给忘了数据分析提供了大量的计划和挑战。作者的目标是构建一个可扩展的平台来分析网络日志，并命名为了Analysis Farm（以下简称AF）。其目标是快速的聚合运行和灵活的日志数据查询，技术选择OpenStack开源的云资源管理工具和类关系型数据库的文档型NoSQL——mongoDB。这套技术架构来做日志存储和分析设备。将这两种技术的扩展性结合起来，获得满足存储扩展、计算扩展和灵活查询。原型系统使用10个mongoDB服务器，来聚合10分钟内高达3百万条的记录和预估每日4亿条数据的即席查询。在这篇文章中作者阐述AF的背景和目标、架构和一些测试结果。相信AF会对那些从事大数据日志分析开发的。

什么叫即席查询：在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所以可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。

#1. 引言

网络监控给管理员提供了网络情况的信息洞悉并对网络管理的起到基础角色。作为提升高质量网络服务的前提条件，网络监控方法发生了变化。随着DPI的进步，终端用户的行为数据粒度更小，比如，访问ip就可以从大量的原始流量中提取出来。为了提供更好的网络服务，交大的网络信息中心部署了大量的中间网络和边界网络设备，用来监控从物理层到应用层的网络状态。最近又部署了DPI来分析流量，来识别应用层协议。当应用层会话结束，DPI将触发一个日志记录收集会话。这个日志记录将汇报学校中每一个会话。这个日志记录将对下面两方面有用。边界带宽优化、网络事件追踪。

虽然DPI提供了基本的日志分析功能，但是这远远没有达到作者的需求，例如，其聚合粒度太大，查询模式是固定的。为了更好的控制聚合和查询过程，作者决定开发一个自己的日志分析平台，AF。这个平台主要实现如下数据仓库功能：存储日志、聚合日志、查询日志。

系统的设计目标如下：

存储扩展性：日志数据被预估每天超过4亿条的写入，并占用350G的容量空间。可以实现要给容纳所有数据的可扩展的解决方法吗？
计算扩展性：日志分析是一个计算密集的任务。日志数据可能太大而不能被单机处理。可以实现计算能力的扩展吗？
查询灵活性：一般来说，查询请求模式是并不是预定义的，可能针对各种可能的字段匹配。可以使用一个数据模型来有效处理即席查询码？

作者的目标是探索使用云技术和新的数据模型大型日志分析的可能性。系统和经验确定了一个基于云的架构是能够提供扩展需求的，使用OpenStack，这种开源的云计算技术工具及来构建私有云。在数据存储方面，新颖的NoSQL系统通过放宽ACID的要求来提高系统的可用性和可扩展性。使用mongoDB，一个NoSQL，来存储数据。其特征包括基于文档的数据格式、类SQL的查询、分布式和mapreduce功能。

在这篇文章中，分享其经验，这篇文章为基于云的日志分析提供基础，通过合适的云构建技术和数据存储技术，成功的搭建了一个分析平台，来满足日志聚合和查询的需求。其他的应用场景的需求也应从AF获得不错的表现。

这篇论文通过如下内容组成：在第二节中，进一步阐述研究背景和目标，在第三节中，阐述架构，并阐述怎么达到存储扩展性和计算扩展性查询灵活性。第四节，实验和结果。相关的工作在第五节中。第六节为总结。

#2. 网络分析研究背景

##A. 系统总览

传统的日志分析任务是数据聚合和数据查询。图一展示了整个系统从边界路由到分析平台的部署。

##B. 分析任务

目前，平台主要承担两类的日志分析任务。

IP组流量矩阵聚合：ip组涉及到手动创建的地址组来分辨用户和ISP。ip组包括一些内网分类和外网isp。ip组流量矩阵将会表示出哪个组合、哪个应用使用带宽。当前的流量矩阵式作为路由策略的基础。新聚合的流量矩阵应该需要报告新的路由策略后的流量改变。为了反应近乎实时的网络状态，ip组流量矩阵需要每10分钟聚合一次。聚合操作十分简单。首先，匹配时间段的日志记录。然后再依据（Source Group, Destination Group, Application）来分组。最后计算每组的数据流量并获得结果。然而当操作进行实时完成时，就是一个挑战，需要3百万的数据记录10分钟内完成。
日志查询，在这个任务中，希望通过查询任何属性（比如，ip地址、端口和应用服务等）。查询结果必须在一个可以接受的时间返回。一个复杂的查询语句是被期望的，并且不会给查询模式增加负担。当它运行在日均4亿的日志数据据上时，需要重新考虑数据存储。

作者无法满足上述两个任务。首先，将日志数据按获得顺序存储，而聚合操作在时间顺序上处理是更佳的。然而，查讯会变得十分缓慢，因为当查询不是以时间顺序匹配就会进行全表查询。因此，转而使用开源的RDBMS。因为，可扩展性不是RDBMS的首要，其给集群配置提供了不必要的复杂性。并且，在ACID的限制下，其性能也无法满需要，虽然并不需要在应用中完全支持ACID。

在下一节介绍完成的设计目标。

#3. 平台的实现

本节将描述怎么在云端实现需要的存储、计算和查询挑着。基于云的解决方案允许作者将将硬件层和软件层的扩展性结合到一起。实现的成果能够满足需要。

##A. 架构一览

如图2，AF可以被分成3层，保留硬件资源池、IaaS层、应用层。

硬件资源池：硬件资源池提供了包括cpu、内存、存储、网络的集中视图。它反映了资源的可用性和工具。通过添加到资源硬件池，服务器、存储和网络设备被准备被调度。现在，在私有云拥有20台物理服务器，2个intel6核的Xeon cpu，96gb内存和10g的以太网适配器。拥有400tb的，被挂在到iSCSI上。更多的硬件可以动态地添加到池内，而不被现有应用引起冲突。
IaaS层：IaaS层封装硬件资源到自包含的系统镜像。例如一个虚拟机。在的实践中，部署4、8、16或者32个实例的时间花销基本一致，总共为5分钟。虽然，在运行一个KVM虚拟机时，很难调节cpu的数量和内存大小，额外的硬盘空间可以动态的添加到实例中。通过OpenStack功能套件来实现硬件资源池管理和IaaS功能。总之，按需部署虚拟机和动态存储添加为维持多种虚拟集群提供了足够的可用性。
应用层：在作者的应用中，应用层部署的MongoDB集群，其包括运行不同mongoDB服务器守护进程的虚拟机。在MongoDB的术语中，服务器又不同的角色，因此也有不同的资源要求。mongos作为要给分配者，拥有2个处理器和4g内存和10g硬盘空间。一个config服务器存储集群的信息和比mongos多一点点的硬盘空间。mongod存储和分析日志数据，作者开始为每个mongod配备了2个cpu单元和25g内存和2t硬盘空间。

##B. 描述挑战

在这个小节中，作者阐述结合各层的可扩展性，来达到存储、计算和查询挑战。

存储扩展：为了存储4亿的日志数据，MongoDB数据库每天需要350g的容量，相比开始就初始化10t的容量，作者更倾向于开始只申请2t的容量，然后再增量的添加行的数据块设备。新的块设备从应用层上开始添加。首先，mongod服务器检查到容量的不足，并且检查内存是否被索引耗尽。在的经验中，当存储容量超过85%、内存使用大于60%时，就需要扩展容量。然后，mongod调用IaaS层的python API来添加存储。当收到上方的请求时，IaaS层挂载新的请求存储（一般为1tb）给虚拟机实例，虚拟机将获得新的块设备。然后，操作系统添加新的块设备来给LVM卷，并在线重新调整文件系统。正在运行的mongod实例对于存储扩展过程是不知道的。在存储扩展试验中。MongoDB的服务器没有被终端，和明显的性能下降。一般来说，扩展要给t的服务器容量花费不超过12分钟，其中90%的时间被花费在文件系统的调整。
计算能力升级：相比垂直扩展，例如单机提升cpu和内存。MongoDB集群更适合使用水平扩展来提升计算性能。在MongoDB的分片集群中，数据存储在几个mongod。比如查询和MapReduce数据库操作，在分片中提供的并行计算能够很好的提高。

MongoDB的MapReduce功能是简化的MapReduce程序范式。这是一个很好的数据聚合工具。如图3阐述，MongoDB集群中的MongoDB实例并行执行MapReduce计算。一旦MongoDB获得MapReduce的请求。mongos会将请求分配到所有的mongod。一旦收到MapReduce的请求，每个mongod开始自己的mapper和reducer，聚合其自己的数据，并将结果返回给mongos。每个mongod的计算时并行执行的。mongos进行最后的reduce操作并获得最后的聚合结果。查询也可以如图3一样的操作。

mongos收到查询请求并分配下去。然后所有的mongod并行执行查询请求。最后mongos再组合结果。从这个层面上说，添加新的mongod服务器可以提高集群的整体性能。添加mongod从mongos开始，首先，mongos监测到系统的压力。例如整体的cpu使用率达到50%，内存使用超过90%。然后，mongos调用IaaS接口来不是性的mongod虚拟机。当新的mongodb实例已经准备好，mongos将其添加到集群中。最后，集群在MongoDB服务器中提供了自动的数据再平衡。

在添加mongod服务器的过程中，MongoDB服务也是可以访问的，虽然可以看到在再平衡过程中，读取操作有着轻微的性能下降。总之，MongoDB集群从mongodb服务器数量中获得了更多的cpu来计算和更多的内存来存储索引。在第4节中，作者将阐述，通过添加mongod服务器来提供MapReduce的性能。

查询的灵活性：MongoDB被选中和分析平台的原因除了包括分布式和可扩展性，还有其数据模型的丰富性。MongoDB有与RDBMS类似的数据模型。基本的单元在MongoDB被称之为文档。一个文档在RDBMS中与一个关系非常相似，其被定义为键值对，键与栏名（属性名），值与栏值（属性值）。

MongoDB的类json查询语句是直观的。为了组成复杂的查询语句，MongoDB提供了内建的操作符，比如数学操作符、逻辑操作符、赋值操作符、正则操作符等。如将性能问题放至一边，这可以产生很灵活的查询。其他的一些优化方法，例如组合索引，调优查询操作迅速等都可以应用到MongoDB中。由于其内存映射存储引擎，MongoDB在使用内存上市非常巨大的，特别是添加大量的索引。所以管理员需要小心地设计索引。在第4部分的例子中阐述更多的内容。

#4. 性能评估

为了评估系统的可行性，进行了两个聚合和查询实验。这些实验被用来设计模拟网络分析的工作，包括mapreduce聚合和灵活的查询。

##A. 实验设置

在实验中，mongos配置了2个cpu单元和8g内存和10g硬盘容量，config配置2个cpu和8g、50g硬盘容量，mongod有2个cpu和24g内存和2t硬盘空间。为了比较3个不同的MapReduce，3个应用以不同的mongod数量来实施。

日志记录数据从网络边界的DPI引擎中获得。使用3个应用并存储3个整天的数据量。在聚合实验中，3个应用各使用不同的聚合数据源。观察到3个不同的数据在整体日志记录中，只有4%的不同。也随机化了一些实验条件。因此，尽管使用不同的数据，但是实验统计还是可以反映出不同配置的应用性能差距。

##B. 聚合实验结果

在这个子小节中，将测试了日志聚合的速度（mapreduce）。集群配置有3个不同应用配置的比较，1x farm为单机上4个mongod实例。4x farm上有4个mongod实例分别部署在4台服务器上。8x farm则有8个实例分别部署在8台服务器上。

平均上，每个数据集包括4亿2千4百万的日志记录，大概使用了352g的容量空间。测试过程如下：1).随机选择一个数据包含的时间。2).执行日志聚合3).记录执行时间处理的总数据量还有处理速度。

像表1所展示的，所有的farm在10分钟内完成了聚合操作。当节点从4扩展到8时，数据处理的性能也差不多提高到一倍。尽管1x 4x有同样的mongod节点，但是性能却只有一半。有两个原因可以解释：

1. 68g的索引，无法单独存到一台机器的24g的内存中。当索引需要在内存和硬盘之间频繁交换时，mongoDB开始的过滤操作会执行得非常慢。
1. 4个实例共享2个cpucpu将会是瓶颈。这个实验阐述了水平扩展的能力，通过添加更多的mongod服务器，系统将能处理更多的数据集。

C. 查询实验

通过进行任意字段的即席查询，并计算时间。在接下来的实验中，8x 集群将分析包含4亿多数据并且建立了62g的索引。所谓比较，作者进行了3种查询，都是与实际工作相关的查询。在每类查询中，有3个不同的时间范围，包括10分钟、30分钟、60分钟。

建立了一个索引来假设数据的扫描，被表示为（starttime, srcIP, destIP, application）。

首要期望是衡量日志的查询速度。使用随机的参数来查询数据。mongoDB的hint()函数被用来观察查询细节，路由索引使用，执行时间和扫描数据量等。数据的平均表现量被提交。

1). 查询指定ip发起的会话：在这个测试中，查询指定ip在某时间范围内的所有网络会话。匹配的日志数据的srcIP值将于指定ip相同。这个查询可以被表达为如下mongodb的格式，其中IP地址和开始时间都是随机的，endTIme将依据startTime来测试时间范围（上述）。
```
 db.log.find ( {
  "starttime":{$gt:startTime, $lte:endTime},
  "endtime": {$gt: starTime, $lte :NOW},
  "srcIP" : ip
 } )
```

如表2所示，查询时间是可以被接受的，使用hint()可以得知，查询使用了（starttime, endTIme, srcIP）索引，基本都是达到7万条数据每秒。

2). 查询指定IP参与的会话:在这个使用中，作者查询指定ip在指定时间范围内的参与到的所有会话。查询表达如下，其ip地址、startTime、endTime与上一次实验类似。
```
  db.log.find({
   "starttime":{$gt:startTime, $lte:endTime},
   "endtime": {$gt: starTime, $lte :NOW},
   "$or": [{"srcIP":ip}, {"dstIP":ip}]
  })
```

如表3所示，查询IP参与的会话比上个实验大概差6倍。索引(startime,endTIme,srcIP)被使用。但是索引并不匹配查询元祖（startTime，endTIme，dstIP），这导致更多的数据被扫描。所以，尽管查询速率比上个实验略低，但是总的查询还是要更加耗时。

3). 查询Ip对的会话：在最后的实验中，查询了所有的HTTP会话记录只有符合指定的IP对和时间范围相比其他协议，HTTP是在实践中更加普遍的例子。查询语句如下。随机参数与上述方法相同。
```
 db.log.find ( {
  "starttime":{$gt:startTime, $lte:endTime},
  "endtime": {$gt: starTime, $lte :NOW},
  "$or": [{"srcIP":ipA, "dstIP":ipB},
   {"srcIP":ipB, "dstIP":ipA}],
  "app": "http"
 } )
```

在消减到没有匹配的情况后，平均表现如表4，查询速度是相比更快，这是因为在更多的条件下，只有很少一部分日志记录被匹配。hint()指明了使用的索引为（starttime,endtime,srcIP,dstIP,app），这个完美地匹配期望的查询。因此，平均扫描的数量比上个实验的更少。然而，$or逻辑操作符和更加复杂的匹配条件降低了扫描速度，扫描速度比第一个实验还低。

4). 总结：MapReduce和查询实验阐述了系统的可行性。在测试的8x farm，就是应用系统的原型配置。mongoDB成功地在可接受的时间内聚合了10分钟的数据和即席查询。

#5. 相关工作

日志分析是数据分析任务中的一种。loggly.com为用户提供了’日志即服务’，并在日志的云服务基础设施中组建自己的日志分析应用。用户可以导入期日志，设计日志过滤器和聚合模型，并且选择合适的数据可视化工具。Yotta.com提供了简单可用的网络性能分析器，这个工具也是基于网站日志的。他们在mongoDB集群中存储和分析网络日志。loggly提供了云环境的灵感。Yotta从传统RDBMS转移到NoSQL系统，给提供了尝试mongoDB的依据。然而，接下来的几个方面使得作者不能直接使用他们的解决方案：1).作者的日志数据比他们的大得多，loggly只允许每天最大导入12g的日志。考虑开销以及管理的灵活性，作者自己构建私有的云平台。yotta也不能处理这么多的数据量。因此，Yotta相应的处理技术，比如分片、MapReduce，在原型中实现。2).对作者的应用场景，日志查询也是与日志聚合一样重要的。loggy以string存储日志记录，并支持正则表达的搜索功能。然而这种方法对数据类型是不要去的，也没有提供灵活的网络日志分析查询。Yotta专注于日志聚合，而不提供单独的日志查询。因此，作者在一个数据库中存储数据并通过实验来验证查询性能。

#6. 总结和未来方向

在本文中，作者期望一个可扩展的网络日志分析平台，其目标快速的聚合和灵活的查询。通过结合基于云基础设施的可扩展性和NoSQL数据存储系统，作者构建了一个系统原型。系统的可扩展性依赖于存储扩展、计算性能设计和灵活的查询。在评估实验中，系统在规定的时间内成功地完成了聚合任务和描述的可用的即席查询。

为了工作在生产环境上部署系统。这需要高可用性，和虚拟设备的在线迁移，数据库的副本集也在考虑中。另一个关注点是封装的API，例如REST、Java，来让用户来衡量日志分析的能力。

这篇论文与实验室的项目遇到的问题十分相似，通过这篇论文，可以明确mongoDB还是适合分析任务的数据库。我们应该专注mongoDB的集群内容，而底层的一些虚拟化过程应忽略。

Paper Reader:Analysis Farm: A Cloud-based Scalable Aggregation and Query Platform for Network Log Analysis

See Also