讨论：大数据量的报表统计，性能作为第一考虑采取何种方案好

建议先把业务理清楚，然后再考虑实现的方法。

建设数据仓库，更多的是业务上的东西，专家不会帮你优化性能，只是帮你把业务整理好，设计好表。。

BI的话。。。可以看看Pentaho，

http://www.pentaho.com/

里面的Kettle，也就是ETL工具就是你说的，怎么把业务数据倒到数据仓库里面去的工具。。。


看了之后，你可能发现数据仓库+BI不是你想那回事。。。

我曾经做过一个类似的项目，是某银行总行级项目，数据量比你描述有过之无不及。
可以给你一些当时我的建议，只是一些提示：
1.引入嵌入式数据库，（DB4O,berkeley db）等。
2.“分布式计算”和“分步式计算”。
3.产品数据库（oracle,db2等）中基本仅存储结果。
4.优化报表查询。

提示：
    如果你们想做产品就别把逻辑绑定到数据库里，（存储过程是洪水，触发器是猛兽，离他们远点）。

做个标记 慢慢看

并发少，那缓存意义就不大了。

恩，感觉这个问题应该是数据挖掘方面的。关于事务性数据操作方面的优化和分布式计算应先放一放。
首要的是详细的理解业务需求，对数据进行合理的分类，清洗，和预处理。报表的统计应是规律性的数据运算。
通过数据的预处理，实现空间换时间。15G/天数据量不算十分的大，方法适当，就没问题。仅供参考。

给以下建议：
1   数据量大，有些太片面了。一定分析下数据的规律，对数据进行分割存储；
2   数据仓库的思想是很适合作为你开发产品的基础指导；
3   缓存用在恰当的地方，将会发挥很大的威力，但不要过于依赖缓存；
4   并发性从一开始设计上就要关注；

正解，报表部分需求不适当简化的话，就是要整OLAP了，这不是该Java做的。

建议楼主先搞清楚报表部分的解决方案，如果用OLAP或者专门的报表工具（带数据库部分方案的），就只要专心处理OLTP的方案即可。

如果想做实时报表，可以考虑TIBCO的辅助或者FirstBI的方案。

OLAP 感觉

用greenplum吧，这个还要从后台想办法，你指望着用J2EE在程序里面把这个搞定，这个不敢说不能实现，但是花费的代价肯定很大，并且极易出问题。