这些年跟很多BI客户打过交道，在数据存储上一般有这些形式：
1. 开源数据库，大多数是MySQL；
2. 基于Hadoop平台的">HBase；
3. 直接保存为日志，一般用Zlib等算法压缩；
4. 商用OLTP数据库，例如Oracle。
5. 商用列式数据库，例如Sybase IQ。
这些客户遇到的典型问题如下：
报表运行太慢，所以一般要结合Scheduler模块在夜间生成报表，再推送给订阅者。这种应用很常见。但客户的交互需求被严重抑制。举个例子，一张夜间生成的报表是关于近三天的数据，客户看到了这个报表之后，也许想结合三天之前数据进行比对。
不过，要么现有报表系统不提供更改参数功能，要么提交更改的参数之后，报表运行非常缓慢，需要长达数十分钟甚至数小时的等待。
时至今日，BI从展现为主已经进化到交互为主，所谓探索式BI。传统BI系统，难以满足客户的需求。
针对以上情况，客户开始想办法解决。
有的客户选择了商用列式数据库，例如国内电力行业的很多客户，但也许是因为商用产品还不够好，在性能上依旧很难满足需求。很多查询性能，甚至还达不到交易数据库Oracle的水平。
有的客户在考虑一体机这一类商用产品，但费用很难承受。据我们了解，国内的某家IT制造商，花费数百万购买的一台一体机，只能运行两三个关键报表，还时常宕机罢工。听到这个情况之后十分惊讶。
有的客户在考虑MPP数据仓库这类商用产品，不过多数MPP数据仓库产品以数据存储量计费，费用依旧高昂。而且现有MPP数据仓库却依旧无法让客户进化到探索式BI，因为MPP数据仓库有自己的先天缺陷，尤其是关联(Join)。目前针对关联的性能优化一般有三种办法：
如果BI系统需要Fact Table同Dimension Table做关联，一般将Dimension Table复制在各个存储节点。
如果BI系统需要Fact Table同Fact Table做关联，一般采用Hash机制在各个存储节点分布Hash值相同的数据。这种办法需要提前预见，而且一旦数据分布算法确定下来，刚性而难以改变。
Materialized Query。这种老旧的办法生命力依旧旺盛。当某个Query运行代价高昂且很难被优化时，我们依然看到MPP数据仓库产品的技术白皮书中看到这样的建议。
迄今，MPP数据仓库给人一种价格虽高但不能完全解决问题的印象。在建设BI系统的时候，往往需要DBA进行非常精细的存储设计。这里的存储设计也是刚性的，一旦上线灵活性极差。
基于开源项目搭建大数据系统，虽然产品的获取是免费的。但对实施团队的人数和技术水平有较高要求，成本并不低，而且项目风险高。很多客户其实并不适合基于开源大数据项目，反倒应该基于商业产品搭建大数据系统，而不是赶时髦在Hadoop这样的项目上投资，商业产品能降低实施团队的专业要求，项目风险可控，所以成功率比较高。
在硬件技术（尤其是网络传输技术）并未取得巨大进步之前，我们的客户最需要的是实用的、廉价的大数据系统。这种大数据系统的预算不会动辄上百万，二十万之内就可以开始。
对于关联(Join)之类的问题，要求商用产品能合理应对即可。
数据分析往往具备连续时间段的特点，近一周近一个月近半年，绝大多数查询所访问的数据都连续集中在连续的时间段上。也就是说，基于时间段进行数据分割往往比基于Hash进行数据分割更容易优化。对于关联，在尚未出现完美方案之前，完全可以用MPP数据集市(Data Mart)的思路去解决。
释放大数据价值，需要廉价大数据系统。