大数据量统计

最近在做一个统计项目的改造，对两张日志表进行分析统计，最后形成报表。这两张日志表现在每天的数据量在1亿左右，大小在30G左右，对我有用的数据大概为20G。因为这量个日志是成上升趋势的，所以我设计出来的系统应该能应对每张表2亿的数据量。

之前的做法是用了3台节点机，1台主控机，来进行统计。节点机分id段分别统计（比如node1统计id为1-5千万，node2统计5千万-1亿，1亿到1.5亿，这些都是可以配置的，并且如果数据量超过1.5亿，增加一台机器再配置一下就ok了），最后由主控机完成汇总。改造原因无非是代码很乱，出错不断，统计很耗内存等。

仔细的分析了一下需求，其实逻辑不复杂，基本就是根据不同的字段来分段，去重，count等，这样的数据量显然不能直接用sql去group by，count什么的。我想起之前看过berkeley db的一些知识，berkeley db的本地文件数据库以及它的大吞吐量，很适合这个场景。

我的做法：两张日志表可以在spring中起两个job，分段读取（可以每次读50W的），每次读取到数据后把数据分给不同的handler去处理相应统计，统计的临时数据记入bdb，数据读取完毕后再分别汇总各自的数据，存入数据库。为了防止意外情况，对于月统计的临时数据入数据库。bdb的数据每天统计完了清理掉。

这样做的好处：
1.减少读写数据库的频率，我们的数据库是很多应用共用，频繁的读取数据库会对其他应用有影响。
2.充分利用本地硬盘，能够避免oom的情况。
3.还没有测试过，不过个人认为一台机器8G的内存应该就可以搞定，这样就节省了3台机器。
4.在想……

本人水平有限，欢迎有经验的同学提出宝贵意见。谢谢！

评论

40 楼 leadyu 2009-05-26  

pcwang 写道

Joo 写道

纵向：定时或者定量出发子进程处理日志文件，然后清空日志文件，吧分析的中间结果累计到别处，一天下来再作多次中间结果的计算，跟ETL有点类似；
横向：加大计算能力，并行吧。主要是不太清楚你日志文件是什么格式，不知道用map-reduce能不能搞定。即便是在单核机器上，楼主你不会写的单线程处理吧？

每次读取数据是单线程，处理数据的时候是用多线程处理，等处理完一批再读取数据。
由于项目开发时间非常紧急，hadoop之前没怎么接触过（只是听过），需要加强学习。

楞要用mysql去处理，确实有点难为，如果LZ做的是BI应用，还是采用专门的数据仓库吧，毕竟数据仓库加载大批量数据是相当快的，几亿甚至几十亿从文件到表也是相当快的，和自己去处理不是一个数量级。

如果仅仅是平常应用中的一些特殊分析功能，没用数据仓库，倒是可以考虑下怎么并行处理日志文件，提高速度，但是日后统计分析基于mysql还是很慢，可以考虑把统计全放后台做，把最终结果计算出来，前台再展现统计结果，这个思路和数据仓库是一致的。

39 楼 pcwang 2009-05-21  

Joo 写道

纵向：定时或者定量出发子进程处理日志文件，然后清空日志文件，吧分析的中间结果累计到别处，一天下来再作多次中间结果的计算，跟ETL有点类似；
横向：加大计算能力，并行吧。主要是不太清楚你日志文件是什么格式，不知道用map-reduce能不能搞定。即便是在单核机器上，楼主你不会写的单线程处理吧？

每次读取数据是单线程，处理数据的时候是用多线程处理，等处理完一批再读取数据。
由于项目开发时间非常紧急，hadoop之前没怎么接触过（只是听过），需要加强学习。

38 楼 ahua3515 2009-05-21  

问题就在于1亿多的数据在1张表中
如果按字段分表可能好解决一些 

做直接sql    mysql数据库估计吃不消的 吧？

可以利用游标，将需要的的内容导到文件
再按需字段hash 出不同结果文件

相信1台机子2g的机子也可以处理完任务（只要hash切分的够平衡）

37 楼 liujunsong 2009-05-21  

强烈建议你抛开数据库,直接走数据文件来解决这个问题.
其实原理也很简单,
第一步,把数据库的内容变成数据文件,按照一定规则切成多个文件,文件名有规律
第二步,写程序一个文件一个文件读取统计,把结果再写回数据库去.

这样做的效果就是利用硬盘空间,而不占用数据库的访问,也不占用过多的内存.
不过DBA就没有用武之地了.

36 楼 quiii 2009-05-21  

- -!  大量数据统计 数据库很不靠谱 hadoop之

35 楼 Joo 2009-05-21  

纵向：定时或者定量出发子进程处理日志文件，然后清空日志文件，吧分析的中间结果累计到别处，一天下来再作多次中间结果的计算，跟ETL有点类似；
横向：加大计算能力，并行吧。主要是不太清楚你日志文件是什么格式，不知道用map-reduce能不能搞定。即便是在单核机器上，楼主你不会写的单线程处理吧？

34 楼 yshao81710 2009-05-20  

单纯的统计的话，不用楼主说的那么复杂吧，程序里做循环每次读100条进行统计，应该不成问题吧。应该花不了多长时间吧。

33 楼 chj733 2009-05-20  

数据仓库无外乎是上面这些方法的结合，并行计算，ETL等等，现在楼主的情况，要去找非常专业的数据仓库技术做支持，时间是否太久了？

我觉得使用多个文件存储中间数据，java或者C解析文件做汇总，不失为一个好办法，如果存在join的逻辑在里面，会比较麻烦

采用数据库来做，也就是多张小表加并行SQL,最好的多会话的，就是会消耗主机CPU，存储IO等资源，这个可以放在非高峰期来做，持续的时间其实是可以估算的，存储的IO吞吐量可以用表扫描粗略计算出来，走对正确的查询计划就可以了

个人觉得程序能处理的尽量程序做，数据库最好不要封装任何业务逻辑，毕竟他只是个持久层，所scale out比应用层要困难的多

32 楼 lovejavaei 2009-05-20  

pcwang 写道

超级潜水员 写道

应该查查数据仓库的概念，将生产数据库的数据每天定时导出到另外一个数据库（数据仓库中叫ＯＤＳ），然后在ＯＤＳ上面直接跑你的统计就行,跑完如果需要再将统计好的数据导回原有数据库。这样就对原有数据库没有影响了。

而且如果mysql有性能问题，ODS你可以使用Oracle啊.

恩，非常感谢超级潜水员同学的建议。
之前也看过一些关于数据挖掘和数据仓库的概念，没有深入的了解过（曾经有一个。。。等到用的时候才后悔莫及。。。），恶补之。
但是公司资源有限，比如mysql换oracle这就是不可能的（不过mysql未来还是未知的，呵呵）。

建议很好，强烈建议看看有关数据仓库的东西，直接在业务数据上做统计分析是不现实的，尤其是你这么大的数据量，想任何招都是徒劳。ods，data mart，data warehouse应该是你考虑的方向，也是你的分析系统发展的方向

31 楼 jin_nth 2009-05-19  

pcwang 写道

genius 写道

可以考虑一下表分区！

多谢建议，采用垂直分区的确是个好办法，可以把我需要的字段和不需要的字段划分到不同的分区，或许会提高查询速度。
我看javaeye上对mysql数据库分区介绍的文章不是很多。也不清楚到底是否在不影响其他应用的同时也能满足我的需求。需要做一些测试先。

MySQL 5.1的分区功能目前还很不完善，要部署的最好还是谨慎一点。

30 楼 seemoon 2009-05-19  

用文件处理会更好，利用数据库显得过于复杂。
用文件处理除了资源占用低效率高的好处外，还可以使用并行计算来提高数据处理速度，甚至完全可以利用awk进行快速处理。
以前做过电信cdr记录处理，都是文件存储然后传输，parsing写入oracle数据库做进一步的其他处理如计费。

29 楼 zhaomingzm_23 2009-05-19  

为什么不用 hadoop

28 楼 yisafe 2009-05-19  

个人觉得写得很多不怎么清楚，不过能处理那么大的数据和容量数据，的确很有挑战性

27 楼 pcwang 2009-05-18  

genius 写道

可以考虑一下表分区！

多谢建议，采用垂直分区的确是个好办法，可以把我需要的字段和不需要的字段划分到不同的分区，或许会提高查询速度。
我看javaeye上对mysql数据库分区介绍的文章不是很多。也不清楚到底是否在不影响其他应用的同时也能满足我的需求。需要做一些测试先。

26 楼 leadyu 2009-05-18  

pcwang 写道

超级潜水员 写道

引用

仔细的分析了一下需求，其实逻辑不复杂，基本就是根据不同的字段来分段，去重，count等，这样的数据量显然不能直接用sql去group by，count什么的。

数据量还不是很多，就一台数据库group by ,count什么就行了。
一个晚上跑两三个小时也就出来了。

整得这么复杂

我们用的mysql，前面说过了，我们的数据库里面不仅仅是一个应用去连，1亿多的数据用group by，或者distinct，count的，dba真的会杀人...

mysql做OLAP的活？1亿多的数据在SybaseIQ里，小意思

25 楼 genius 2009-05-17  

可以考虑一下表分区！

24 楼 heroczx 2009-05-17  

用AWK效率相当高

23 楼 woaiwofengkuang 2009-05-17  

哈哈，我最近也刚做了个类似的功能，我们是每天分析全量的数据放入向个Txt文件中。其它应有就不用现访问我们的库了。可以直接读取我们生成的文件，进行相应的功能开发。我的做方是用多线程来跑，每个线程都读取一定量的数据。每个线程都将数据写向不同的文件。
简单的比喻：
我的表里有1000000条数据我要分成10的文件来存放那么每个文件也就要存100000条。在这里分10个线程一个线程去跑100000条数据。此处和简单的分页没什么不同。

22 楼 cauherk 2009-05-16  

几个思路
1、前沿化。使用hadoop，设计好map和reduce，多整一些低端，大硬盘的设备，每天都实时的去跑任务。
2、就地解决。老实的采用主从复制，既然是日志，几亿条数据中少几个，相信没有谁责怪你的。从数据库就可以每个夜晚安安静静的分析去了。
3、稍加改变。一个表放那么多数据干嘛？是想帮mysql测试bug？最简单的方案，采用url的hash分区或者分表，同时几乎采用按天分表或者分区。并行数据的导入或者分析，总比一个个来好吧。前面也有人说过了，分段进行分析，分析好了就放在着，后面慢慢用。也节省了不少能源。
一个好的方案往往就是最简单的方案，别把这个事情整的很复杂。

21 楼 tanbamboo 2009-05-16  

我之前的一个项目也有类似的需求，只是数据量可能稍微少一些。

这里面涉及两个方面：数据、统计
先说统计，就是根据统计规则，对每条记录的一些字段进行匹配处理，然后更新统计结果。
数据：包括原始数据、单次统计处理的统计结果、汇总后的统计结果。

我考虑可以采用以下几种方法：
1. 数据入库前进行实时统计处理
这个方法就是在每个数据源的入库流程前，插入统计分析模块，进行实时统计，然后统计分析的结构作为一个新的数据源，汇总到收集系统。
这个方案的优点：少了一次业务数据(日志信息)的查询与传输的代价，当数据量很大的时候，这个代价似乎不小的。
缺点就是：需要在数据源的处理流程中，插入一个统计分析模块，可能对系统有些影响，另外一个就是，有些统计分析的需求(比如出重)，在单个数据源的地方，可能处理的不对。

2. 周期性对入库后的数据进行统计分析
周期性的查询出原始数据的一个片段，进行统计分析处理，把统计结果汇总。如此反复循环，即可完成全部的统计分析处理。
其中对原始数据的分片，需要根据一定的规则，保障不重复、不丢失。
另外，如果原始数据的表里面已经创建了一些索引的话，在可以的情况下，查询原始数据的时候可以有效利用(比如直接count ... group by ...)，这相当于把一部分的统计分析的计算代价由入库时索引器承担了。

统计分析的计算代价是无可避免的(无论是在入库前、入库时、查询原始数据后)，只是所处的位置不同而已。

最终我感觉，数据统计分析，其实就是预定制统计规则的BI而已，而BI就是可以按需执行统计分析。