数据处理方法和数据处理装置技术领域
本发明涉及计算机技术领域，具体涉及一种数据处理方法和数据处理装
置。
背景技术
随着互联网发展，数据统计已经越来越重要。例如，某个公司投放广告
之后需要马上知道在当前时刻根据某个条件或者某几个条件统计得到的关于
该广告的数据，例如广告的点击率等。下面以日志数据为例进行描述。对于
数据量不太大的日志数据来说，通过关系型数据库管理系统(mysql或
sqlserver)、文档型数据库(mongo)等数据库完全可以满足对数据的查询和
统计需求。但是对于数据量较大的日志数据来说，如果希望实时对数据进行
统计并得出结果是非常困难的。例如，对于单表数据超过1亿条的情况，如
果希望按每1秒钟,每1分钟,每5分钟,每15分钟,每1小时,每1天等等这样的
时间量度进行查询和统计并得出需要的报表数据，采用mysql，mongo，
sqlserver之类的数据库是很难满足需求的。
发明内容
鉴于上述问题，提出了本发明以便提供一种至少部分地解决上述问题的
数据处理方法和数据处理装置。
依据本发明的一个方面，提供了一种数据处理方法。该数据处理方法包
括：从消息队列中消费日志数据并将所消费的日志数据存储在临时缓存中，
其中，消息队列用于存储来自客户端的日志数据；对存储在临时缓存中的日
志数据中的至少一部分进行整理，以获得经整理的日志数据；以及将经整理
的日志数据存储在文件系统中。
依据本发明的另一个方面，提供了一种数据处理装置。该数据处理装置
包括消费单元、整理单元和存储单元。消费单元用于从消息队列中消费日志
数据并将所消费的日志数据存储在临时缓存中，其中，消息队列用于存储来
自客户端的日志数据。整理单元用于对存储在临时缓存中的日志数据中的至
少一部分进行整理，以获得经整理的日志数据。存储单元用于将经整理的日
志数据存储在文件系统中。
根据本发明提供的数据处理方法和数据处理装置，由于在将日志数据存
储在文件系统之前，先对日志数据进行了整理，也就是对日志数据进行边整
理边存储，因此文件系统中所存储的是已整理好的日志数据。这样，在对日
志数据进行查询时，可以从部分已整理好的日志数据中查询，因此可以节约
数据查询时间，提高对查询请求的响应速度，从而可以实现针对大数据的实
时查询。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技
术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它
目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本
领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，
而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示
相同的部件。在附图中：
图1示出根据本发明一个实施例的数据处理方法的流程示意图；
图2示出根据本发明一个实施例的处理日志数据的工作流示意图；
图3示出根据本发明另一个实施例的数据处理方法的流程示意图；
图4示出根据本发明另一个实施例的数据处理方法的流程示意图；以及
图5示出根据本发明一个实施例的数据处理装置的示意性框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示
了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不
应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地
理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
根据本发明的一个方面，提供一种数据处理方法。图1示出根据本发明
一个实施例的数据处理方法100的流程示意图。
如图1所示，数据处理方法100包括以下步骤。
在步骤S110，从消息队列中消费日志数据并将所消费的日志数据存储在
临时缓存中，其中，消息队列用于存储来自客户端的日志数据。
日志数据(logdata)就是一条日志消息的内在含义。换句话说，日志数
据就是一条日志消息里用来说明为什么生成日志消息的信息。例如，Web服
务器一般会在用户访问Web页面请求资源(图片、文件等等)的时候记录日
志，生成日志数据。如果用户访问的页面需要通过认证，日志消息将会包含
用户名。在Web日志中，每条日志通常代表着用户的一次访问行为。举例来
说，日志数据可以包含访问时间、用户名、用户年龄、访问网页的统一资源
定位符(url)、访问次数等信息。
日志数据包含了大量产品分析人员会感兴趣的信息。举例来说，可以从
日志数据中获取网站每类页面的PV值(PageView，页面访问量)、独立IP
(互联网协议地址)数等。另外，可以从日志数据中计算得出用户所检索的
关键词排行榜、用户停留时间最高的页面等。更进一步地，还可以利用日志
数据构建广告点击模型、分析用户行为特征等等。
消息队列是在消息的传输过程中保存消息的容器。消息队列的主要目的
是提供路由并保证消息的传递。如果发送消息时接收者不可用，消息队列会
保留消息，直到可以成功地传递它。这里的消息就是日志数据。
可选地，消息队列可以存储在集群服务器中。具体地，可以搭建zookeeper
和卡夫卡(kafka)系统来配置高可用消息队列集群，也就是说，可以利用kafka
集群服务器来存储消息队列。
在客户端上运行的应用程序(例如web应用程序)可以将生成的日志数
据以JSON格式写入到消息队列中。举例来说，客户端上的web应用程序在
用户希望查看微博话题时向微博服务器发出请求，微博服务器根据请求返回
该微博话题的相关数据。此后，web应用程序生成关于用户查看了该微博话
题的日志数据并将日志数据以JSON格式写入到消息队列中。
随后，可以从消息队列中消费日志数据。例如，可以利用德鲁伊(druid)
数据库中的实时(realtime)节点来消费日志数据。实时节点可以将所消费的
日志数据存储在实时节点的临时缓存中。
图2示出根据本发明一个实施例的处理日志数据的工作流示意图。为了
描述方便，下文将结合图2来描述数据处理方法的操作过程。然而，可以理
解的是，图2所示的工作流仅是示例而非对本发明的限制，本发明可以具有
其他合理的实现方式。如图2所示，日志数据210写入了消息队列220。随后，
druid数据库的实时节点从消息队列220中消费日志数据并将所消费的日志数
据存储在实时节点的临时缓存(未示出)中。
在步骤S120，对存储在临时缓存中的日志数据中的至少一部分进行整理，
以获得经整理的日志数据。
druid数据库的实时节点230在将日志数据存储在文件系统(localstorage)
260中之前，可以对日志数据进行一些处理。例如，实时节点230可以周期性
地启动后台的计划任务搜索与日志数据相关的持久化索引，后台计划任务将
这些持久化索引合并到一起并生成不可变的数据块。这些数据块包含了一段
时间内的所有已经由实时节点消费的数据，这些数据块可以称为“Segment”。
随后，实时节点可以将这些数据块传送到一个永久持久化的备份存储中，即
本文所描述的文件系统。消费、持久化、合并和传送这些阶段都是流动的，
并且在这些处理阶段中不会有任何数据的丢失。
在步骤S130，将经整理的日志数据存储在文件系统中。
文件系统260可以采用任何合适的文件存储系统实现，例如hadoop分布
式文件系统(HDFS)等，本发明不对此进行限制。可以由druid数据库的实
时节点将经整理的日志数据存储在文件系统260中。在现有技术中，通常直
接将未经处理的日志数据存储在mysql等数据库中。这样，在后期对数据进
行查询时，往往首先将未经整理的日志数据提取出来，再进行统计分析。这
种情况下，如果数据量较大，则需要花费较长的时间进行统计运算，导致查
询结果的反馈时间很长。这样也就很难实现实时查询。例如，对于微博应用
来说，可能往往需要在第二天甚至很多天之后才能统计出当前的热门微博，
而无法在当天即统计出这一天的热门微博。与现有技术不同的是，本发明在
将日志数据存储在文件系统之前，先对日志数据进行了整理，也就是对日志
数据进行边整理边存储，因此文件系统中所存储的是已整理好的日志数据。
这样，在对日志数据进行查询时，可以从部分已整理好的日志数据中查询，
因此可以节约数据查询时间，提高对查询请求的响应速度，从而可以实现针
对大数据的实时查询。
图3示出根据本发明另一个实施例的数据处理方法300的流程示意图。
图3所示的数据处理方法300的步骤S310、S320和S330分别与图1所示的
数据处理方法100的步骤S110、S120和S130相对应。本领域技术人员根据
图1和上文的描述可以理解图3中的上述步骤，为了简洁，在此不再赘述。
根据本实施例，在步骤S330之后，数据处理方法300可以进一步包括步骤S340。
在步骤S340，从临时缓存中删除存储在临时缓存中的日志数据中的至少
一部分，以将新消费的日志数据存储在临时缓存中。
在将经整理的日志数据存储在文件系统中之后，可以删除实时节点的临
时缓存中的对应的原始的、未经整理的日志数据。相当于，实时节点以先入
先出的方式整理日志数据并将经整理的日志数据存储在文件系统中。随后实
时节点删除与经整理的日志数据对应的那部分原始的日志数据以空出缓存空
间。随后实时节点再继续消费新的日志数据并将新消费的日志数据存储在空
闲的缓存空间中。这是一个类似流水线的工作方式。这种工作方式比较高效，
能够满足对大数据的实时处理要求。总的来说，实时节点可以不断地流水线
式地消费、整理并存储日志数据。通过以上方式，可以使得在文件系统中存
储经过整理的日志数据，并且相应地在实时节点的临时缓存中存储未经整理
的日志数据。
可以理解的是，虽然根据本实施例以及图3，步骤S340在步骤S330之后
实施，但是可以理解的是，步骤S340也可以与步骤S330同时实施。
图4示出根据本发明另一个实施例的数据处理方法400的流程示意图。
图4所示的数据处理方法400的步骤S410、S420、S430和S440分别与图3
所示的数据处理方法300的步骤S310、S320、S330和S340相对应。本领域
技术人员根据图3和上文的描述可以理解图4中的上述步骤，为了简洁，在
此不再赘述。根据本实施例，数据处理方法400可以进一步包括以下步骤。
在步骤S450，接收查询请求。
返回参考图2，可以利用外部的查询接口270和druid数据库中的代理
(broker)节点240来接收用户的查询请求。如下所述，代理节点240可以汇
总实时节点230和历史(history)节点250查询到的数据，将查询结果返回给
用户，并且可以负责查询数据的缓存。
在步骤S460，根据查询请求从存储在文件系统中的经整理的日志数据以
及存储在临时缓存中的日志数据中查询期望数据。
代理节点240在接收到查询请求时，可以分别从实时节点230的临时缓
存中以及从文件系统260中获取数据。对于存储在实时节点230的临时缓存
中的日志数据来说，代理节点240可以直接访问实时节点230，请求实时节点
230返回期望数据。而对于存储在文件系统260中的日志数据来说，代理节点
240可以间接经由druid数据库的历史节点250来查询。
历史节点250负责从文件系统下载segment，提供数据查询服务。历史节
点250可分为多个层(tier)，例如热数据放置在一个层，冷数据放置在另外
一个层，以达到冷热数据分开处理的目的。
在步骤S470，对期望数据进行汇总以获得查询结果。
在接收到由实时节点230返回的未经整理的日志数据和由历史节点返回
的经整理的日志数据之后，代理节点240可以对这些数据进行汇总分析。
可以理解的是，用户希望对日志数据进行实时查询，例如希望获知当天
的热门微博。由于日志数据的整理会有一定延时，因此，存储在文件系统260
中的日志数据可能反映的是当前时刻的半小时之前的微博信息，而存储在实
时节点230的临时缓存中的、正在排队等待实时节点230整理的日志数据可
能反映的是当前时刻之前的半小时内的微博信息。这样，可以统一汇总未经
整理的日志数据以及经整理的日志数据来获得当天的热门微博信息。由于存
储在文件系统260中的日志数据已经经过了整理，例如已经基于微博内容、
时间等信息进行了合并，即统计了一定时段内某些微博的阅读量。这样，在
汇总期望数据时所花费的时间会很少。尤其与现有技术相比，由于无需对日
志数据进行大量统计运算，因此查询效率大大增加。
在步骤S480，输出查询结果。
代理节点240在汇总期望数据并获得查询结果之后，可以将该查询结果
返回给发送查询请求的客户端或服务器。这样，可以使得用户实时获得希望
获知的信息。
上述查询方式可以实时高效地获得希望查询的信息。
可选地，接收查询请求、对期望数据进行汇总以获得查询结果和输出查
询结果是利用druid数据库中的代理节点来实现；根据查询请求从存储在文件
系统中的经整理的日志数据以及存储在临时缓存中的日志数据中查询期望数
据是利用druid数据库中的实时节点和历史节点来实现；从消息队列中消费日
志数据并将所消费的日志数据存储在临时缓存中、对存储在临时缓存中的日
志数据中的至少一部分进行整理，以获得经整理的日志数据和将经整理的日
志数据存储在文件系统中是利用实时节点来实现。
结合图2以及上文的描述可以理解本实施例的实现方式，不再赘述。与
其它数据库相比，druid数据库可以满足大数据的处理需求、满足实时的数据
查询需求并且写入性能很高，是一种非常适合应用于大数据处理的数据库。
可选地，S120(320、420)可以包括：将存储在临时缓存中的日志数据
中的至少一部分中的相关联的日志数据进行合并并将经合并的日志数据按照
时间分片，以生成经整理的日志数据。
如上文所述，druid数据库的实时节点可以周期性地启动后台的计划任务
搜索与日志数据相关的持久化索引，后台计划任务将这些持久化索引合并到
一起并生成不可变的数据块(即分片)。数据块包含了一段时间内的所有已
经由实时节点消费的数据。也就是说，数据块是持有某段时间间隔的自包含
数据容器。每个数据块包含列方向的数据，以及这些列的索引。druid数据库
在查询数据时是基于数据块过滤的。
例如，可以以一个小时为单位生成数据块。假设在某一日的13点至15
点这两个小时内，实时节点消费的日志数据如表1所示。
表1示例性的日志数据
时间
网址
点击
13：15
a
1
13：22
b
1
13：25
b
1
13：40
c
1
14：20
c
1
14：30
a
1
14：45
a
1
表1仅简单示出了日志数据的一种示例，以用于说明本发明的实施例。
可以理解的是，表1所示的日志数据的形式并非对本发明的限制。
可以将表1所示的日志数据分为两个数据块，即13点至14点中的日志
数据为一个数据块，14点至15点的日志数据为一个数据块。同时，对日志数
据进行合并。因此，得到在13点至14点的时间段内，a网址的点击数为1次，
b网址为2次，c网址为1次。在14点至15点的时间段内，a网址的点击数
为2次，b网址为0次，c网址为1次。因此，通过上述合并和分片方式可以
获得经整理的日志数据。
可以理解的是，虽然图4示出步骤S450至S480在步骤S440之后实施，
但是可以理解的是，步骤S450至S480可以在任意时刻实施，也就是查询可
以是实时的。
可选地，在步骤S130(S330、S430)之前，数据处理方法100(300、400)
可以进一步包括：建立数据索引，数据索引用于指示经整理的日志数据在文
件系统中的存储位置。
在将经整理的日志数据存储到文件系统之前，实时节点可以建立数据索
引。在后期希望对查询文件系统中的经整理的日志数据时，可以根据数据索
引来找到所需要的日志数据的存储位置。这样，可以使得日志数据的查询更
加方便快捷。
可选地，数据处理方法100(300、400)可以进一步包括：监测存储在文
件系统中的经整理的日志数据的数据量；以及记录在当前记录时刻与前一记
录时刻之间的时段内所存储的经整理的日志数据的数据量。
可以利用druid数据库的协调(coordinator)节点监测存储在文件系统中
的经整理的日志数据的数据量并记录两个相邻记录时刻之间的时段内所存储
的经整理的日志数据的数据量。这样，可以维护存储到文件系统中的日志数
据的数据量，用于日后查看等。
协调节点可以周期性地执行。协调节点可以维持一个与mysql数据库的
连接。协调节点可以将所记录的经整理的日志数据的数据量存储在mysql数
据库中。
根据本发明的另一个方面，提供一种数据处理装置。图5示出根据本发
明一个实施例的数据处理装置500的示意性框图。如图5所示，数据处理装
置500包括消费单元510、整理单元520和存储单元530。
消费单元510用于从消息队列中消费日志数据并将所消费的日志数据存
储在临时缓存中，其中，消息队列用于存储来自客户端的日志数据。
整理单元520用于对存储在临时缓存中的日志数据中的至少一部分进行
整理，以获得经整理的日志数据。
存储单元530用于将经整理的日志数据存储在文件系统中。
消费单元510、整理单元520和存储单元530中的任何一者可以采用任何
合适的硬件、软件和/或固件实现。消费单元510、整理单元520和存储单元
530可以集成在一起或单独采用分开的单元实现，本发明不对此进行限制。
可选地，数据处理装置500可以进一步包括删除单元(未示出)，用于
从临时缓存中删除存储在临时缓存中的日志数据中的至少一部分，以将新消
费的日志数据存储在临时缓存中。
可选地，数据处理装置500可以进一步包括接收单元、查询单元、汇总
单元和输出单元。接收单元用于接收查询请求。查询单元用于根据查询请求
从存储在文件系统中的经整理的日志数据以及存储在临时缓存中的日志数据
中查询期望数据。汇总单元用于对期望数据进行汇总以获得查询结果。输出
单元用于输出查询结果。
可选地，接收单元、汇总单元是利用德鲁伊数据库中的代理节点来实现。
查询单元是利用德鲁伊数据库中的实时节点和历史节点来实现。消费单元510、
整理单元520和存储单元530是利用实时节点来实现。
可选地，整理单元520可以包括合并及分片模块，用于将存储在临时缓
存中的日志数据中的至少一部分中的相关联的日志数据进行合并并将经合并
的日志数据按照时间分片，以生成经整理的日志数据。
可选地，数据处理装置500可以进一步包括索引建立单元(未示出)，
用于建立数据索引，数据索引用于指示经整理的日志数据在文件系统中的存
储位置。
可选地，数据处理装置500可以进一步包括监测单元和记录单元(未示
出)。监测单元用于监测存储在文件系统中的经整理的日志数据的数据量。记
录单元用于记录在当前记录时刻与前一记录时刻之间的时段内所存储的经整
理的日志数据的数据量。
可选地，消息队列存储在集群服务器中。
上文已经描述了数据处理方法的各步骤的实施方式和优点等，本领域技
术人员结合图1至4以及上文关于数据处理方法的描述，可以理解数据处理
装置的具体结构、运行方式及其优点等，本文不对此进行赘述。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固
有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，
构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定
编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，
并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发
明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详
细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或
多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被
一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的
方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中
所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的
那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具
体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要
求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自
适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以
把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可
以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者
单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴
随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或
者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴
随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相
似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它
实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合
意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利
要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器
上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理
解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发
明实施例的数据处理装置中的一些或者全部部件的一些或者全部功能。本发
明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装
置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序
可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这
样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任
何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并
且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施
例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求
的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元
件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借
助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列
举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬
件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可
将这些单词解释为名称。
本发明实施例公开了A1、一种数据处理方法，包括：
从消息队列中消费日志数据并将所消费的日志数据存储在临时缓存中，
其中，所述消息队列用于存储来自客户端的日志数据；
对存储在所述临时缓存中的日志数据中的至少一部分进行整理，以获得
经整理的日志数据；以及
将所述经整理的日志数据存储在文件系统中。
A2、如A1所述的数据处理方法，在所述将所述经整理的日志数据存储
在文件系统中之后，所述数据处理方法进一步包括：
从所述临时缓存中删除所述存储在所述临时缓存中的日志数据中的至少
一部分，以将新消费的日志数据存储在所述临时缓存中。
A3、如A2所述的数据处理方法，所述数据处理方法进一步包括：
接收查询请求；
根据所述查询请求从存储在所述文件系统中的经整理的日志数据以及存
储在所述临时缓存中的日志数据中查询期望数据；
对所述期望数据进行汇总以获得查询结果；以及
输出所述查询结果。
A4、如A3所述的数据处理方法，
所述接收查询请求、所述对所述期望数据进行汇总以获得查询结果和所
述输出所述查询结果是利用德鲁伊数据库中的代理节点来实现；
所述根据所述查询请求从存储在所述文件系统中的经整理的日志数据以
及存储在所述临时缓存中的日志数据中查询期望数据是利用所述德鲁伊数据
库中的实时节点和历史节点来实现；
所述从消息队列中消费日志数据并将所消费的日志数据存储在临时缓存
中、所述对存储在所述临时缓存中的日志数据中的至少一部分进行整理，以
获得经整理的日志数据和所述将所述经整理的日志数据存储在文件系统中是
利用所述实时节点来实现。
A5、如A1至A4任一项所述的数据处理方法，所述对存储在所述临时缓
存中的日志数据中的至少一部分进行整理包括：
将所述存储在所述临时缓存中的日志数据中的至少一部分中的相关联的
日志数据进行合并并将经合并的日志数据按照时间分片，以生成所述经整理
的日志数据。
A6、如A1至A5任一项所述的数据处理方法，在所述将所述经整理的日
志数据存储在文件系统中之前，所述数据处理方法进一步包括：
建立数据索引，所述数据索引用于指示所述经整理的日志数据在所述文
件系统中的存储位置。
A7、如A1至A6任一项所述的数据处理方法，所述数据处理方法进一步
包括：
监测存储在所述文件系统中的所述经整理的日志数据的数据量；以及
记录在当前记录时刻与前一记录时刻之间的时段内所存储的所述经整理
的日志数据的数据量。
A8、如A1至A7任一项所述的数据处理方法，所述消息队列存储在集群
服务器中。
本发明实施例还公开了B9、一种数据处理装置，包括：
消费单元，用于从消息队列中消费日志数据并将所消费的日志数据存储
在临时缓存中，其中，所述消息队列用于存储来自客户端的日志数据；
整理单元，用于对存储在所述临时缓存中的日志数据中的至少一部分进
行整理，以获得经整理的日志数据；以及
存储单元，用于将所述经整理的日志数据存储在文件系统中。
B10、如B9所述的数据处理装置，所述数据处理装置进一步包括：
删除单元，用于从所述临时缓存中删除所述存储在所述临时缓存中的日
志数据中的至少一部分，以将新消费的日志数据存储在所述临时缓存中。
B11、如B10所述的数据处理装置，所述数据处理装置进一步包括：
接收单元，用于接收查询请求；
查询单元，用于根据所述查询请求从存储在所述文件系统中的经整理的
日志数据以及存储在所述临时缓存中的日志数据中查询期望数据；
汇总单元，用于对所述期望数据进行汇总以获得查询结果；以及
输出单元，用于输出所述查询结果。
B12、如B9至B11任一项所述的数据处理装置，所述数据处理装置进一
步包括：
索引建立单元，用于建立数据索引，所述数据索引用于指示所述经整理
的日志数据在所述文件系统中的存储位置。
B13、如B9至B12任一项所述的数据处理装置，所述数据处理装置进一
步包括：
监测单元，用于监测存储在所述文件系统中的所述经整理的日志数据的
数据量；以及
记录单元，用于记录在当前记录时刻与前一记录时刻之间的时段内所存
储的所述经整理的日志数据的数据量。
B14、如B9至B13任一项所述的数据处理装置，所述消息队列存储在集
群服务器中。