CN105138615B - 一种构建大数据分布式日志的方法和系统 - Google Patents

Abstract

本发明涉及一种构建大数据分布式日志的方法和系统，包括步骤S1，日志传输子系统从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统；步骤S2，日志存储子系统接收所述日志数据，通过水平扩展的方式存储所述日志数据；步骤S3，批量日志处理子系统提取存储在日志存储子系统中的所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询。本发明能够满足大数据情况下对日志系统可靠性、实时性、高性能和高可扩展性以及可维护性的要求。

Description

一种构建大数据分布式日志的方法和系统

技术领域

本发明涉及大数据处理领域，尤其涉及一种构建大数据分布式日志的方法和系统。

背景技术

在一般的软件系统中并没有用于处理日志的专门的独立的系统，现有软件系统只是简单的把日志写入本地磁盘或者同步到关系型数据库中，以备将来检索时需要。但是在大业务量、高并发且拥有众多服务器集群的大型系统中，以上简单的日志处理方式已经不能满足要求，上述日志处理方式存在以下弊端：

第一是不可靠；因为大型系统是由很多台服务器组成的集群，集群中某个服务器节点出现故障的情况很普遍，那么保存在这个故障服务器上的重要日志数据就有遗失的风险，而且传统的日志备份方式一般是每天定时进行备份，这使得在两个备份周期间产生的数据就无法恢复。

第二是无法满足实时性的要求，因为很多日志数据的价值会随着时间的流逝而减小，比如业务监控系统如果不能实时得到最新的业务日志数据，那么系统正在发生的问题将无法即时的被反馈。

第三是无法满足日志数据处理性能的要求，在大型业务系统中需要处理的日志数据量至少都是GB或TB级别的，如果这些海量数据是存储在单个服务器节点上或是某个关系型数据库中，受单机IOPS(每秒读写操作次数)的限制，其处理性能是非常低下的。因此就迫切需要一种能同时具备可靠性、实时性而且还有较高处理性能的日志系统来满足这些方面的要求。

第四是可扩展性差，随着日志量的增加，数据的处理时间越来越长，性能越来越差，传统的日志处理方式很难简单的靠增加服务器的方式来提升数据处理能力，甚至随着数据量的增长连存储空间都会不够用。另外，随着系统扩展后复杂度增加而带来的可维护性问题也是需要仔细考量的。

除了上述问题，在对日志数据进行挖掘时，一些分布式数据挖掘算法会对数据进行反复循环迭代运算，如果仅仅基于磁盘的分布式文件系统来构建日志系统，因其受磁盘IO的速度限制仍将不可避免的出现性能瓶颈。

发明内容

本发明所要解决的技术问题，是提供一种可靠性好、实时性好、高性能、高可扩展性以及可维护性好的构建大数据分布式日志的方法和系统。

本发明解决上述技术问题的技术方案如下：一种构建大数据分布式日志的方法，包括以下步骤：

步骤S1，日志传输子系统从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统；

步骤S2，日志存储子系统接收所述日志数据，通过水平扩展的方式存储所述日志数据；

步骤S3，批量日志处理子系统读取存储在所述日志存储子系统中的所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步地，步骤S2中，所述水平扩展的方式包括所述日志存储子系统按照预设的数据分片规则将所述日志数据拆分，并发送到多个主数据节点，每个主数据节点对应一个或多个从数据节点，主数据节点将接收到的所述日志数据备份到与其对应的从数据节点中。

进一步地，步骤S1中，所述日志传输子系统还将附带UUID标识的所述日志数据经过负载均衡后经过多个节点实时发送给内存数据库；

所述内存数据库按照预设的数据分片规则将所述实时日志数据拆分，并发送到多个数据库点中进行实时存储；

所述实时数据处理子系统读取存储在所述内存数据库中的所述实时日志数据，并采用MapReduce算法对所述实时日志数据进行处理，生成实时报表供外部业务报表系统进行查询。

进一步地，步骤S3中，所述MapReduce算法包括映射任务和归约任务。

进一步地，步骤S3中，所述批量日志处理子系统能在缓存空间中缓存外部业务报表系统的查询结果，并对缓存空间进行缓存淘汰。

本发明解决上述技术问题的另一种技术方案如下：一种构建大数据分布式日志的系统，包括日志传输子系统、日志存储子系统、批量日志处理子系统、内存数据库和实时数据处理子系统；

所述日志传输子系统用于从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统以及实时发送给所述内存数据库；

所述日志存储子系统用于接收所述日志数据，通过水平扩展的方式存储所述日志数据；

所述批量日志处理子系统用于读取存储在所述日志存储子系统中的所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询；

所述内存数据库用于将接收到的所述实时日志数据拆分，并发送到多个数据库点中进行实时存储；

所述实时数据处理子系统用于读取存储在所述内存数据库中的所述实时日志数据，并采用MapReduce算法对所述实时日志数据进行处理，生成实时报表供外部业务报表系统进行查询。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步地，所述日志传输子系统包括日志传输客户端、负载均衡器和日志接收服务器；

所述日志传输客户端用于接收业务系统产生的所述日志数据，并发送给所述日志接收服务器；所述日志传输客户端还包括一个UUID标识生成单元，用于为每条接收到的所述日志数据生成一个UUID标识；

所述日志接收服务器用于接收所述日志传输客户端发送的所述日志数据，所述日志接收服务器包括多个节点；

所述负载均衡器用于将所述日志接收服务器接收到的所述日志数据分配到所述日志接收服务器的多个节点上，并通过所述多个节点将所述日志数据发送给所述日志存储子系统和所述内存数据库。

进一步地，所述日志存储子系统包括第一数据分片路由器和多个主数据节点以及每个主数据节点对应的一个或多个从数据节点；

所述第一数据分片路由器用于按照预设的数据分片规则将所述日志存储子系统接收到的所述日志数据进行拆分后发送到多个所述主数据节点；

所述主数据节点用于存储所述日志数据；并将所述日志数据发送给所述从数据节点；

所述从数据节点用于接收所述主数据节点发送的所述日志数据并进行存储备份。

进一步地，所述批量日志处理子系统包括第一MapReduce任务管理单元、定时任务管理单元、按小时报表生成单元、按天报表生成单元、第一数据查询结果缓存单元和批量数据查询接口；

所述第一MapReduce任务管理单元用于采用MapReduce算法对所述批量日志处理子系统读取到的所述日志数据进行批量预处理；

所述定时任务管理单元用于使所述MapReduce任务管理单元定时对所述批量日志处理子系统读取到的所述日志数据进行批量预处理；

所述按小时报表生成单元用于根据所述MapReduce任务管理单元的预处理结果以每小时为时间跨度生成按小时报表；

所述按天报表生成单元用于汇总所述按小时报表并生成按天报表；

所述第一数据查询结果缓存单元用于将外部业务报表系统的查询结果缓存在缓存空间中，并对缓存空间进行缓存淘汰；

所述批量数据查询接口用于为外部业务报表系统提供查询接口。

进一步地，所述内存数据库包括第二数据分片路由器和多个数据库节点；

所述第二数据分片路由器用于按照预设的数据分片规则将所述内存数据库接收到的所述实时日志数据进行拆分后发送到多个所述数据库节点；

所述数据库节点用于存储所述实时日志数据；

所述实时数据处理子系统包括第二MapReduce任务管理单元、第二数据查询结果缓存单元和实时数据查询接口；

所述第二MapReduce任务管理单元用于采用MapReduce算法对所述实时日志处理子系统读取到的所述日志数据进行实时处理；

所述第二数据查询结果缓存单元用于将外部业务报表系统的查询结果缓存在缓存空间中，并对缓存空间进行缓存淘汰；

所述实时数据查询接口用于为外部业务报表系统提供查询接口。

本发明的有益效果是：本发明以处理大规模数据为目标，能够满足在大数据情况下对日志系统可靠性、实时性、高性能、高可用性和高可扩展性的要求。其所有内部子系统都被设计为具备分布式水平扩展的能力，使其拥有更好的伸缩性和稳定性，能够容忍某些资源节点的故障，可轻松通过增加更多的服务器实现系统性能成比例地提高。本发明兼顾了磁盘和内存两种数据存储方式的优点，除了能满足日志数据实时处理的基本要求，并使数据挖掘等迭代算法的性能大幅提升。除了提供更好的性能，本发明以面向接口和可配置化为设计原则，基于消息协议与外部系统进行通信，各系统的实现可以随时根据需要进行更改，而不必担心会破坏对方，从而实现了松耦合系统的灵活性和可靠性，并且其基于有向无环图结构和能力对等原则设计构建的日志传输子系统可以使系统内部组网更加灵活，以适应业务长期发展变化的需要。同时本发明还考虑了保证日志数据传输处理过程中的幂等性及缓存算法等若干细节，从而使系统更加健壮。

附图说明

图1为本发明所述构建大数据分布式日志的方法的流程图；

图2为本发明所述所述构建大数据分布式日志的系统整体结构图；

图3为本发明所述日志传输子系统结构图；

图4为本发明所述日志存储子系统结构图；

图5为本发明所述批量日志处理子系统结构图；

图6为本发明所述内存数据库结构图；

图7为本发明所述实时数据处理子系统结构图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

图1为本发明所述构建大数据分布式日志的方法的流程图。

如图1所示，一种构建大数据分布式日志的方法，包括以下步骤：

步骤S1，日志传输子系统从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统；

步骤S2，日志存储子系统接收所述日志数据，通过水平扩展的方式存储所述日志数据后，将所述日志数据发送给批量日志处理子系统；

步骤S3，所述批量日志处理子系统接收所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询。

图2为本发明所述所述构建大数据分布式日志的系统整体结构图。

如图2所示，一种构建大数据分布式日志的系统，包括日志传输子系统、日志存储子系统、批量日志处理子系统、内存数据库和实时数据处理子系统。

图3为本发明所述日志传输子系统结构图。

如图3所示，日志传输子系统包括日志传输客户端、日志接收服务器以及连接日志传输客户端和日志接收服务器的负载均衡器。日志数据由业务系统产生，并通过调用日志数据发送给日志传输客户端进而发送给日志接收服务器。为了保证日志传输处理过程中的幂等性，日志传输客户端为每条日志数据生成一个UUID(通用唯一识别码，UniversallyUnique Identifier)作为日志的唯一标识，而批量日志处理子系统将根据这个UUID来保证每条日志数据的唯一性，避免把多条相同重复的日志数据当作是多条不同的日志数据来处理。

日志接收服务器包括多个节点(节点不一定是物理节点，本发明中附图3可看作是日志接收服务器的一个实例)，由多个节点构成的的日志传输子系统的有向无环图网络使用TCP数据流传输协议以实时高效分发日志数据(TCP是一种面向连接的、可靠的字节流服务，与HTTP协议相比更高效)。每个节点都同时具备接收和发送日志数据的对等能力，可把同一份日志数据按不同需求分发给不同的系统进行处理，这使得可方便的通过添加新节点进行负载均衡或数据转发，提升了系统的可靠性和可扩展性。

如图3所示，日志数据被负载均衡器负载均衡到日志传输子系统的节点1和节点2上，节点1和节点2又把各自接收到的日志数据分别发送给日志存储子系统、内存数据库及日志传输子系统的节点3上。而节点3实际上可以和营销抽奖系统同在一台服务器上，节点3接收到日志数据后，直接调用营销抽奖系统的判断方法对该日志所对应的业务是否中奖进行判断。

日志传输子系统中传输目的地都是可配置化的，新增或修改目的地配置可以即时生效而无需重启系统，这样可以避免了日志传输子系统在重启过程中造成的日志丢失。

图4为本发明所述日志存储子系统结构图。

如图4所示，日志存储子系统包括第一数据分片路由器、主数据节点和从数据节点，主数据节点和从数据节点可以为服务器。

日志数据经由日志传输子系统传输给第一数据分片路由器，第一数据分片路由器根据既定的数据分片规则将日志数据拆分到不同的主数据节点上，为了减少磁盘寻址的开销，系统以固定大小的块为单位存储数据，同时主数据节点会将数据复制给从数据节点作为数据的一个备份，这样在主数据节点出现故障数据丢失时，还能通过从数据节点恢复数据。根据需要一个主数据节点可以同时拥有多个从数据节点。

为了进一步提高日志存储子系统的读写性能(可用性)，根据分布式系统的CAP原则必须要在数据一致性和系统可用性之间进行权衡，这需要牺牲数据的部分一致性来换取系统的高可用性，因此上述的主数据节点和从数据节点间的数据复制过程实际是异步进行的，这导致从数据节点的数据在同一时间和主数据节点相比不是最新的，所以系统并不保证数据的强一致性(即不保证当数据更新完成，后续所有访问都能获得最新的值)，但是系统会保证数据的最终一致性，即在短暂的一段时间后最终所有的访问都将获得最后的更新值。而这种主数据节点和从数据节点的数据短暂不一致的情况对于后面要使用这些数据的批量数据处理子系统来说是完全可以接受的。

日志存储子系统可以通过简单的水平扩展，即增加主数据节点和从数据节点来存储更多的数据，并能由此极大的提高数据读写的性能。

图5为本发明所述批量日志处理子系统结构图。

如图5所示，批量日志处理子系统包括第一MapReduce任务管理单元、定时任务管理单元、按小时报表生成单元、按天报表生成单元、第一数据查询结果缓存单元和批量数据查询接口。

批量日志处理子系统主要使用MapReduce算法对存储在日志存储子系统中的海量日志数据进行并行处理：MapReduce算法由Map(映射)任务和Reduce(归约)任务组成，其中Map任务是可以高度并行的(可以为输入文件中的每个数据块创建一个Map任务)。批量日志处理子系统的第一MapReduce任务管理单元负责MapReduce任务的调度，它把许多Map任务分发给日志存储子系统上的每个节点(包括主数据节点和从数据节点)，Map任务在日志存储子系统的节点上处理保存在该节点上的那部分日志数据，当所有的Map任务都成功完成之后，第一MapReduce任务管理单元将每个Map任务输出的结果按其键值进行合并，并根据键值分发给指定的Reduce任务进行统计(每个键分且仅分给一个Reduce任务)，最后第一MapReduce任务管理单元再把每个Reduce任务处理的结果进行合并输出。通过MapReduce算法先让日志存储子系统的节点自己处理保存在自己节点上的那部分日志数据，然后再把各个局部处理结果进行汇总。这样原本在一个磁盘上的查询压力就被分散到许多不同的节点上，这使得大规模数据处理的性能和服务器节点数目基本成正比，理论上节点数目越多系统性能越好，系统每秒读写操作次数＝单机每秒读写操作次数×服务器数量。

定时任务管理单元用于使所述MapReduce任务管理单元定时对所述批量日志处理子系统接收到的所述日志数据进行批量预处理。

为了进一步提高报表系统的查询效率，批量日志处理子系统会通过按小时报表生成单元和按天报表生成单元对日志数据进行预处理。预处理是以每小时及每天为时间跨度定时按基本的维度对日志数据进行分组统计处理，预处理形成的基础报表会被存储起来，每天的基础报表是根据每小时的基础报表汇总得到的，而外围报表系统实际就是在这些预处理报表数据的基础上进行二次加工来满足各种不同形态的业务需求。

外部的业务报表系统通过访问批量日志处理子系统提供的批量数据查询接口来进行批量数据查询，这种面向接口的设计有助于降低日志系统与周边系统间的耦合度，同时提高系统的内聚性。

另外为了避免大量重复的数据查询请求造成过大的压力，批量日志处理子系统中专门设计了第一数据查询结果缓存单元来缓存以往的查询结果，如果请求的结果在缓存中存在则直接返回缓存中保存的结果，如果不存在则再到分布式存储系统中查询。因为缓存空间是有限的，所以需要一种合理的缓存淘汰算法，在限制缓存大小的情况下尽可能的提高缓存命中率。批量日志处理子系统所使用的缓存淘汰算法对LRU(Least Recently User，近期最少使用算法)和LFU(Least Frequent lyUsed，最不经常使用算法)两种常用淘汰算法进行了整合优化，本发明使用的淘汰算法如下所示：

1.判断是否大于缓存上限。

2.如大于，则淘汰某日期之前的缓存数据。

淘汰规则：

1.如近期被使用，则暂不淘汰(LRU)：通过缓存访问时间判断。

2.淘汰使用最少的缓存数据(LFU)：通过缓存访问计数判断。

重复以上过程，直至小于缓存上限。

图6为本发明所述内存数据库结构图。

如图6所示，所述内存数据库包括第二数据分片路由器和多个数据库节点。

第二数据分片路由器用于按照预设的数据分片规则将所述内存数据库接收到的所述实时日志数据进行拆分后发送到多个所述数据库节点；由数据库节点存储所述实时日志数据。但和日志存储子系统不同的是，没有为内存数据库的数据库节点设计从数据库节点，而且内存数据库中只保存了最近一段时间的日志数据(因为如像实时监控这样的应用并不需要关心太久之前的数据，而且这样在减小数据空间的同时也间接提高了数据处理的性能)，因为对于处理实时数据流的系统来说配置从库也没有太大必要，因为对于实时系统来说数据丢失一般是可以容忍的。

采用内存数据库高效处理那些需要实时处理的数据：内存的读写速度远快于磁盘的读写速度，使用内存数据库可以尽可能快地对最新的数据做出分析并给出结果。比如使用分布式数据挖掘算法在对日志数据进行迭代运算的过程中会产生大量的中间数据，这些中间数据可以存放到内存中，下一个操作可以直接从内存中读取，省去了大量的磁盘IO操作，这对于迭代运算比较多的算法来说效率提升很大。

图7为本发明所述实时数据处理子系统结构图。

如图7所示，实时数据处理子系统包括第二MapReduce任务管理单元、第二数据查询结果缓存单元和实时数据查询接口。

实时日志处理子系统主要是利用了内存数据库的高速读写能力。使用MapReduce算法进行分布式计算处理，使用分布式数据挖掘算法时所产生的过程数据(经历多次MapReduce迭代)。

在实时日志处理子系统中同样使用了缓存，只是由于实时数据流的特性，缓存淘汰算法不用像批量日志处理子系统那么复杂，其设计为只以时间为限制，超过时间期限的缓存就会被清除。

以下为一个具体的实施例。

目前在中国移动无线音乐基地能力开放平台项目中成功实施了该分布式日志系统方案。在具体实施中，尽量使用开源的组件搭建系统，其中分布式日志传输子系统基于开源日志框架Log4J搭建(也可以使用开源项目Apache Flume替代)，分布式日志存储子系统基于开源NoSQL数据库MongoDB搭建(采用MongoDB相比纯Hadoop的一个优势在于其自带的SQL更易使用，当然也可以使用基于Hadoop的面向列的分布式数据库HBase替代MongoDB,但是总体上MongoDB比HBase的维护难度和成本要低),分布式实时日志处理子系统是由采用内存文件系统的MongoDB搭建(可使用开源的分布式计算框架Spark)。日志数据采用JSON格式记录，可无需转换格式直接存储到数据格式为BSON的MongoDB中。

日志生成相关代码：

日志唯一标识生成：

UUID.randomUUID().toString()

使用GSON把日志输出为JSON格式：

new GsonBuilder().disableHtmlEscaping()

.setExclusionStrategies(logExclusionStrategy).create()

.toJson(this)；

日志传输客户端Log4J相关配置：

log4j.log4j.logger.wapLog＝INFO,wapLog

log4j.appender.wapLog＝org.apache.log4j.net.SocketAppender

#发送日志到指定服务器

log4j.appender.wapLog.RemoteHost＝10.25.173.46

log4j.appender.wapLog.Port＝9199

log4j.appender.wapLog.ReconnectionDelay＝5000

log4j.appender.wapLog.Threshold＝INFO

日志接收服务器相关代码：

日志接收服务器Log4J相关配置：

#使用MongoDBAppender传输日志数据到分布式日志存储子系统

log4j.logger.MongoDB＝INFO,MongoDB

log4j.appender.MongoDB＝com.sitech.log.MongoDBAppender

log4j.appender.MongoDB.Threshold＝INFO

log4j.appender.MongoDB.databaseName＝logDB

log4j.appender.MongoDB.collectionName＝log Info

log4j.appender.MongoDB.hostname＝127.0.0.1

log4j.appender.MongoDB.port＝9933

log4j.appender.MongoDB.layout＝org.log4mongo.MongoDbPatternLayout

#使用MongoDBAppender传输日志数据到分布式内存数据库

log4j.logger.cappedLog＝INFO,cappedLog

log4j.appender.cappedLog＝com.sitech.log.MongoDBAppender

log4j.appender.cappedLog.Threshold＝INFO

log4j.appender.cappedLog.databaseName＝logDB

log4j.appender.cappedLog.collectionName＝cappedLog

log4j.appender.cappedLog.hostname＝10.25.173.45

log4j.appender.cappedLog.port＝9944

log4j.appender.cappedLog.layout＝org.log4mongo.MongoDbPatternL ayout

MongoDBAppender继承至开源项目Log4Mongo，但我们对Log4Mongo进行了优化改造，Log4Mongo入库是同步的，在高并发及数据库异常等情况下存在严重性能问题。MongoDBAppende通过增加线程池把Log4Mongo的同布入库改造为异步入库，提高了入库性能及系统稳定性。

MongoDBAppender相关代码：

分布式日志存储子系统MongoDB集群配置(采用分片加主从复制集的结构)相关脚本：

配置两个Mongo配置服务器：

./scmgt/mongodb/bin/mongod --dbpath＝/loginfo/mongodb/config--logpath＝/loginfo/mongodb/log/configLog.log --port＝30000 –fork–directoryperdb

配置两个Mongos路由：

./scmgt/mongodb/bin/mongos –configdb 10.25.173.43:30000,10.25.173.44:30000 --logpath＝/loginfo/mongodb/log/mongos.log--port＝40000 –fork

启动两个分片：

nterleave＝all /scmgt/mongodb/bin/mongod –shardsvr –replset shard1 --dbpath＝/loginfo/mongodb/db/shard1 --nssize＝2000--logpath＝/loginfo/mongodb/log/shard1/opInfoLog.log --port＝9933–fork

nterleave＝all /scmgt/mongodb/bin/mongod –shardsvr –replset shard2 --dbpath＝/loginfo/mongodb/db/shard2 --nssize＝2000--logpath＝/loginfo/mongodb/log/shard2/opInfoLog.log --port＝9933–fork

注意由于系统环境的服务器是NUMA架构的，所以启动mongo时需要使用Linux内核参数nterleave＝all

初始化两个复制集：

#连接到MongoDB实例

./scmgt/mongodb/bin/mongo –port 9933

use admin

config ＝ {_id:’shard1’,members:[{_id: 0,host:’10.25.173.45’},{_id:2,host:’10.25.173.46’}]}；

rs.initiate(config)；

config ＝ {_id:’shard2’,members:[{_id: 0,host:’10.25.173.47’},{_id:2,host:’10.25.173.48’}]}；

rs.initiate(config)；

配置两个分片：

#连接到Mongos路由

./scmgt/mongodb/bin/mongo –port 30000

use admin

db.runCommand({addshard:"shard1/10.25.173.45:9933,10.25.173.46:9933",name:"shard1"})；

db.runCommand({addshard:"shard2/10.25.173.47:9933,10.25.173.48:9933",name:"shard2"})；

配置从库可读：

./scmgt/mongodb/bin/mongo –port 9933

db.getMongo().setSlaveOk()；

日志数据预处理相关数据结构：

每小时报表的字段格式(每天报表是对每小时报表的聚合，其字段格式和每小时报表是一样的)：

在MongoDB中使用MapReduce算法：

分省分渠道统计各接口访问次数及成功率：

Map函数：

内存数据库同样基于MongoDB搭建，但是与分布式日志存储子系统存储于磁盘上不同的是采用了Li nux的Tmpfs内存文件系统作为存储空间。在Linux中Tmpfs同常规的文件系统一样，只是它完全位于内存中，而MongoDB使用内存应射文件(memory-mapped file)来处理对磁盘文件中数据的读写请求，并不对内存和磁盘这两者进行区别对待，只是将文件看作一个巨大的数组，然后按照字节为单位访问其中的数据剩下的都交由操作系统自己去处理，所以MongoDB可以无需任何修改就能运行于内存之中。

挂载16G的Tmpfs：

mount-t tmpfs-o size＝16384m tmpfs/tmp

使用MongoDB的Capped集合存放最近两小时的日志数据：

Capped集合是一种固定大小的集合，当集合的大小达到指定大小时，

新数据会自动覆盖老的数据，这样就不必担心日志会超出Tmpfs的大小，而且Capped集合的数据存储空间是提前分配的，因此拥有相比普通集合更高的性能。系统中使用如下命令创建Capped集合：

db.createCollection("cappedLog ",{capped:true, size:6442450944})；

分布式日志系统对外接口使用HTTP协议，响应数据为JSON格式。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种构建大数据分布式日志的方法，其特征在于，包括以下步骤：

步骤S1，日志传输子系统从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统以及实时发送给内存数据库；

步骤S2，日志存储子系统接收所述日志数据，通过水平扩展的方式存储所述日志数据；

步骤S3，批量日志处理子系统读取存储在所述日志存储子系统中的所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询；

步骤S4、所述内存数据库按照预设的数据分片规则将所述实时日志数据拆分，并发送到多个数据库点中进行实时存储；

步骤S5、实时数据处理子系统读取存储在所述内存数据库中的所述实时日志数据，并采用MapReduce算法对所述实时日志数据进行处理，生成实时报表供外部业务报表系统进行查询；

其中，日志传输子系统包括日志传输客户端、负载均衡器和日志接收服务器；所述步骤S1具体包括：

所述日志传输客户端接收业务系统产生的所述日志数据，并发送给所述日志接收服务器；为每条接收到的所述日志数据生成一个UUID标识；

所述日志接收服务器接收所述日志传输客户端发送的所述日志数据，所述日志接收服务器包括多个节点；

所述负载均衡器将所述日志接收服务器接收到的所述日志数据分配到所述日志接收服务器的多个节点上，并通过所述多个节点将所述日志数据发送给所述日志存储子系统和所述内存数据库。

2.根据权利要求1所述的构建大数据分布式日志的方法，其特征在于，步骤S2中，所述水平扩展的方式包括所述日志存储子系统按照预设的数据分片规则将所述日志数据拆分，并发送到多个主数据节点，每个主数据节点对应一个或多个从数据节点，主数据节点将接收到的所述日志数据备份到与其对应的从数据节点中。

3.根据权利要求1所述的构建大数据分布式日志的方法，其特征在于，步骤S3中，所述MapReduce算法包括映射任务和归约任务。

4.根据权利要求1所述的构建大数据分布式日志的方法，其特征在于，步骤S3中，所述批量日志处理子系统能在缓存空间中缓存外部业务报表系统的查询结果，并对缓存空间进行缓存淘汰。

5.一种构建大数据分布式日志的系统，其特征在于，包括日志传输子系统、日志存储子系统、批量日志处理子系统、内存数据库和实时数据处理子系统；

所述日志传输子系统用于从业务系统接收到日志数据，并为每条接收到的所述日志数据生成一个UUID标识，并将附带UUID标识的所述日志数据经过负载均衡后经过多个节点发送给日志存储子系统以及实时发送给所述内存数据库；

所述日志存储子系统用于接收所述日志数据，通过水平扩展的方式存储所述日志数据；

所述批量日志处理子系统用于读取存储在所述日志存储子系统中的所述日志数据，并采用MapReduce算法定时对所述日志数据进行批量预处理，生成按小时报表和按天报表供外部业务报表系统进行查询；

所述内存数据库用于将接收到的所述实时日志数据拆分，并发送到多个数据库点中进行实时存储；

所述实时数据处理子系统用于读取存储在所述内存数据库中的所述实时日志数据，并采用MapReduce算法对所述实时日志数据进行处理，生成实时报表供外部业务报表系统进行查询；

其中，所述日志传输子系统包括日志传输客户端、负载均衡器和日志接收服务器；

所述日志传输客户端用于接收业务系统产生的所述日志数据，并发送给所述日志接收服务器；所述日志传输客户端还包括一个UUID标识生成单元，用于为每条接收到的所述日志数据生成一个UUID标识；

所述日志接收服务器用于接收所述日志传输客户端发送的所述日志数据，所述日志接收服务器包括多个节点；

所述负载均衡器用于将所述日志接收服务器接收到的所述日志数据分配到所述日志接收服务器的多个节点上，并通过所述多个节点将所述日志数据发送给所述日志存储子系统和所述内存数据库。

6.根据权利要求5所述的构建大数据分布式日志的系统，其特征在于，所述日志存储子系统包括第一数据分片路由器和多个主数据节点以及每个主数据节点对应的一个或多个从数据节点；

所述第一数据分片路由器用于按照预设的数据分片规则将所述日志存储子系统接收到的所述日志数据进行拆分后发送到多个所述主数据节点；

所述主数据节点用于存储所述日志数据；并将所述日志数据发送给所述从数据节点；

所述从数据节点用于接收所述主数据节点发送的所述日志数据并进行存储备份。

7.根据权利要求5所述的构建大数据分布式日志的系统，其特征在于，所述批量日志处理子系统包括第一MapReduce任务管理单元、定时任务管理单元、按小时报表生成单元、按天报表生成单元、第一数据查询结果缓存单元和批量数据查询接口；

所述第一MapReduce任务管理单元用于采用MapReduce算法对所述批量日志处理子系统读取到的所述日志数据进行批量预处理；

所述定时任务管理单元用于使所述MapReduce任务管理单元定时对所述批量日志处理子系统读取到的所述日志数据进行批量预处理；

所述按小时报表生成单元用于根据所述MapReduce任务管理单元的预处理结果以每小时为时间跨度生成按小时报表；

所述按天报表生成单元用于汇总所述按小时报表并生成按天报表；

所述第一数据查询结果缓存单元用于将外部业务报表系统的查询结果缓存在缓存空间中，并对缓存空间进行缓存淘汰；

所述批量数据查询接口用于为外部业务报表系统提供查询接口。

8.根据权利要求5所述的构建大数据分布式日志的系统，其特征在于，所述内存数据库包括第二数据分片路由器和多个数据库节点；

所述第二数据分片路由器用于按照预设的数据分片规则将所述内存数据库接收到的所述实时日志数据进行拆分后发送到多个所述数据库节点；

所述数据库节点用于存储所述实时日志数据；

所述实时数据处理子系统包括第二MapReduce任务管理单元、第二数据查询结果缓存单元和实时数据查询接口；

所述第二MapReduce任务管理单元用于采用MapReduce算法对所述实时日志处理子系统读取到的所述日志数据进行实时处理；

所述第二数据查询结果缓存单元用于将外部业务报表系统的查询结果缓存在缓存空间中，并对缓存空间进行缓存淘汰；

所述实时数据查询接口用于为外部业务报表系统提供查询接口。