大数据量统计

原始数据是两张收集系统（另外一个已有系统）得到的日志表，储存在mysql数据库中，两张日志表都是每天一张，数据库会保存近一周的日志表。每天的日志表数据量都在亿级。我需要做的就统计前一天的日志表，根据一些字段排重等操作算出一个数值。
举个简单的例子：比如一张表中有refer_url（前导页面url），juid（浏览器标识，11位字符串）。需要统计出每天和每月所有前导页面（取顶级域名分组）的用户数（juid排重），并按照用户数排序。
例如:前导页面http://www.iteye.com/，用户数10000。
这是个比较简单点的统计，像这样的统计差不多一天有10多个。
程序一般都是在凌晨对前一天的数据进行统计。

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

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

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

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

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

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

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

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

用AWK效率相当高

可以考虑一下表分区！

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

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

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

为什么不用 hadoop