[发明专利]一种收集数据的系统、客户端和方法

说明书

技术领域

本发明涉及互联网技术领域，具体涉及一种收集数据的系统、客户端和方法。

背景技术

互联网时代的后台数据非常重要而且庞大，比如日志数据和统计数据。这些后台数据可能是后台工程师分析程序运行状况的第一手资料，也可能是业务运营决策所依赖的第一参考。然而大流量的网站一般都有上千万台生产服务器，且分布于各个不同的机房。日志文件或统计数据就会存放在这些网络异构且分布零散的生产服务器上，给日志的收集、传输、汇总及分析带来很大的困难。目前有一些开源的软件可以用来收集这些日志，但也存在着很多不能解决的情况。

目前较为常用的一些开源软件例如Scribe，可以达到简单收集日志数据的目的。

Scribe是当前的一个大型的社交网络服务网站的开源的日志收集系统，在该大型的社交网络服务网站内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统HDFS等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的，高容错的方案。当中央存储系统的网络或者机器出现故障时，scribe会将日志转存到本地或者另一个位置，当中央存储系统恢复后，scribe会将转存的日志重新传输给中央存储系统。其通常与Hadoop结合使用，scribe用于向HDFS中push日志，而Hadoop通过MapReduce作业进行定期处理。

图1是现有的Scribe收集日志的示意图。如图1所示，Scribe从作为种数据源的各应用上收集数据，放到一个共享队列上，然后push到后端的中央存储系统上。当中央存储系统出现故障时，scribe可以暂时把日志写到本地文件中，待中央存储系统恢复性能后，scribe把本地日志续传到中央存储系统上。

各个数据源须通过THRIFT（由于采用了THRIFT，客户端可以采用各种语言编写向scribe传输数据，每条数据记录包含一个category和一个message）。可以在scribe配置用于监听端口的THRIFT线程数（默认为3）。在后端，scribe可以将不同category的数据存放到不同目录中，以便于进行分别处理。后端的日志存储方式可以是各种各样的store，包括：file（文件），buffer（双层存储，一个主储存，一个副存储），network（另一个scribe服务器）等。

但是scribe存在如下缺点：

（1）scribe的一个缺点是前端组织数据不灵活，只能使用两个字段，即catagory和message，在生产服务器的应用程序中，如果想用scribe发送数据，则每条数据只能有catagory和message两个字段，如果想传送多个字段，则必须自己组织数据，将要传送的多个数据合并到message里面。在后期分析数据时还要自己解析message，得到原来的多个字段。这给数据的传输造成了诸多的限制和不便。

（2）另一个缺点是，scribe会接收每一条数据，并把它们忠实地记录在本地缓存，以一定频率批量发送数据，即便两条数据的category和message是一模一样的。这在数据传输量很大、传输频率很高时，容易造成严重的网络堵塞和延迟。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的收集数据的系统、客户端和相应的收集数据的方法。

依据本发明的一个方面，提供了一种收集数据的系统，其中，该系统包括：服务器端和部署于不同生产服务器上的多个客户端，

所述客户端，适于获取生产服务器所产生的对应不同类别业务的数据，将所获取的数据按照对应的不同类别的业务分类存放；

其中，每条数据包含一个以上的字段，不同的字段具有不同的类型，且每条数据的至少一个字段标识有关键码；每种类别业务都有一个对应的定时周期；

所述客户端，进一步适于在每种类别业务对应的定时周期结束时，将所保存的该类别业务的数据中的，标识有关键码的字段的值相同的数据归并为一条数据后发送给所述服务器端；

所述服务器端，适于从各客户端接收数据，并进行存储或转发。

可选地，所述客户端，进一步适于在每种类别业务对应的定时周期结束时，将所保存的该类别业务的数据中的，标识有关键码的字段的值相同的数据归并为一条数据时，对没有标识关键码的字段，按照不同的类型进行不同的归并处理。

可选地，所述客户端，进一步适于在按照不同的类型对没有标识关键码的字段进行不同的归并处理时，采用以下一种或多种的组合：