随着信息化的普及，报表系统已经成了行业企业的标配，报表的作用越来越大。目前市场上充斥着大量的国内外报表工具，将报表的展现形式体现到了极致，报表风格、统计图样式、多表拼接、报表组合等等，效果已然绚丽夺目。不仅如此，与报表相关的外围产品也在逐渐丰富，像轻量级的OLAP、通用查询、DashBoard等也都成为各大报表厂商产品追逐的对象，为用户提供全面的数据分析统计产品。


现在的报表展现，用一个词来形容——perfect。


但是，当我们透过报表的展现层看报表的运行原理的时候，我们不禁发现这样一个问题：报表的计算性能普遍偏低。


报表展现要经历三个阶段——1、取数；2、计算；3、将计算结果返回客户端展现（大多数是HTML）。

报表工具允许用户将数据取出（从RDB、XML或者其他文件中），再对取出的原始数据进行加工（计算），而报表引擎在计算的时候不仅仅计算数据，而且带有大量诸如边框风格、对齐方式、前景背景色、显示格式等显示样式的计算，增大了内存开销，从而导致数据量越大性能越低。于是大部分用户现在面临这样一个问题：数据量一大（一般大于10w）报表展现就非常慢了。


不仅如此，报表工具为了简化开发难度，允许用户把全部原始数据取出（不通过sql过滤），然后在报表工具里通过表达式进行表间关联和数据过滤。报表计算的负担更重了，报表计算也更慢了。


以上是从报表计算机制上阐述报表计算性能为什么偏低，接下来谈一下报表工具自身的模型限制。


可以说现在的报表工具是为数据统计而生的，但不是为复杂数据统计而设计的。换句话说，现在的报表工具在复杂业务统计（同期比、不规则分组、动态行列等）上往往计算效率偏低。这就迫使很多使用者在DB端写了大量的存储过程完成复杂业务计算，开发效率降低的同时增大了数据库的负担，严重影响数据库性能。


综上，当报表的外衣越来越华丽的同时，请不要忘了数据展现的基础是数据计算，报表计算的快慢直接影响展现的效果。我们可能更需要这样一种报表工具，它能将计算单独剥离，即通过该计算层完成原始数据的加工，这个过程既不带任何展现属性，又能对复杂计算提供良好支持；计算层将加工后的数据（要展现的数据）交给报表的展现层，展现层结合相应的展现样式和风格输出到客户端，从而减少不必要的内存开销，提升报表计算性能、展现速度。


这样的计算层看起来很美好，不过对其要求却颇高，最关键的就是要保证易用性，否则程序员宁愿使用SQL/存储过程；其次得有完备的计算体系，否则有些逻辑算不出来，程序员仍旧要求助于数据库；第三，得有足够快的计算性能，如果算得还不如原来的报表工具快，那要它有什么用！


要满足上述要求，笔者个人认为需要具备几个能力：1、单机并行计算的能力，随着多核机器的普及，这是保证计算性能的基础。

2、拥有有序集合和对象引用的计算能力，对结构化数据来说，这是保证易用性的基础。