集算报表

集算报表：报表工具的二次革命

计算引擎

产生背景

报表工具是润乾的主打产品，我们在这方面积累了丰富的经验，当然，也有教训。

现代的报表工具主要解决两个环节的问题：一方面是呈现，也就是把数据以表格或图形的方式展现出来；另一方面是数据计算，即计算出源数据中没有和不能直接呈现的数据，比如一些公式格、分组汇总排序等等。

这里说的报表，主要是指用户事先确定好格式和数据运算规则的报表，我们俗称为固定报表。自助报表，也就是业务用户可以自己简单拖拽可以完成的报表，不在此类。自助报表的话题我们会专门再讲。

十年前润乾首先提出了非线性报表模型，带来了报表工具的第一次革命。这个模型从根本上解决了报表（特别是中国式报表）的复杂格式以及表内的计算问题，以此模型的润乾报表也因此取得了一定的成功，现在这个模型已经成为报表工具的标准了。

但是，有了这样的报表工具，报表开发是否就很好做了？

“并不是！”

报表工具常常会宣称自己支持“零编码开发报表”，润乾报表当然也不例外地喊过这个口号，但要认真分析下来，这是一句空话。

为什么呢？我们发现，数据库中的原始数据有时并不能直接用作报表工具的数据源去呈现，而需要一系列运算转换过程，有的过程还非常复杂。

有报表开发经验程序员都知道，为报表编写复杂SQL是经常的事，存储过程以及事先准备的中间数据也是家常便饭，有时SQL和存储过程不好写的运算还需要采用自定义数据源即JAVA程序来处理。总之都需要大量的程序编码。

虽然大部分报表还是相对简单的，这类复杂报表总数上并不算多，但其占用的开发工作量却会占绝对的大头，开发10个用报表工具能直接完成的简单报表所用的时间可能也做不了一个需要编码才能准备好数据的报表。

那么，提升报表工具的计算能力可否解决这个问题吗？

广义地说是可以的，这就是集算器的产生背景。

但是，由于数据量和数据转换具有分步性的特征，而报表工具在呈现环节的计算一般都是状态式和全内存方式，这样，无论在容量和复杂度方面都只能是很少部分地缓解这个问题而已，即使是润乾报表这样以计算能力为核心优势的报表工具也不行，数据源开发工作量依然很大，这也是我们这些年的经验。

提升报表工具的计算能力不能放在呈现环节，需要给报表应用结构中增加一个数据准备环节，这就是集算器的作用。

换句话说，当代的报表工具已经把呈现环节的格式及相关计算问题解决得很好，但在数据准备阶段仍然差得很远，需要有另外的计算手段来弥补，而集算器就是这个计算手段。

理解集算器

集算器是一种程序设计语言，它有自己的语法体系。和普通的程序设计语言一样，集算器也是由程序员编码代码后执行获得计算结果。与报表工具中的计算目标不同，集算器并不追求零编码，而是追求简单编码。

集算器不是面向对象的程序设计语言，没有复杂的类继承和重载概念，有BASIC这类初级程序设计水平的程序员都能很快掌握。集算器是解释执行的动态语言，可以在运行过程中拼出代码执行，这样可以获得更大的灵活性，进一步降低程序设计的复杂度。

与Java等高级语言相比，集算器中提供了大量与结构化计算相关的基础对象和方法，这类运算在数据分析及报表数据准备中非常常见，因而可以使得代码比Java要短得多。

大家都知道SQL用来实现很零碎的多步运算很不方便，特别是与次序相关的运算，程序员常常要把数据从数据库中取出来用Java等完成。而集算器则正好在这方面做了强化，相当于把SQL与Java的优势统一起来，让程序员可以既可享受到类似SQL的批量集合式计算、又能获得类似Java的灵活性。

集算器虽然在大多数情况下的语法要比SQL更简单易写，但并不能取代SQL。数据从数据库读出的IO成本相当高，有些涉及数据量太大的简单运算，数据读出的耗时远远超过运算本身，这种情况还是放在数据库中运算更合适。

集算器本身是用Java开发的，与Java有天然的兼容性，而且集算器的设计定位就是被集成，所以与Java的集成性非常好，特别地，对于Java报表工具，用集算器为之提供数据源非常方便。集算器提供标准的JDBC接口，报表工具可以象访问普通数据库一样访问集算器，集算器的jar包也可以和报表工具一起部署发布，完全无缝集成。

这一点与其它如perl,python,R等其它脚本语言不同，这些语言在某种程度上也方便用于实现许多结构化计算（细纠起来还是不如集算器专业），但很难被报表工具调用。

降低报表开发难度

降低开发难度从而提高开发效率是集算器的设计初衷，是最容易理解的作用，前面已有粗略介绍。

这方面的细节内容太多，我们会再做一个专门话题详细讲述集算器如何解决报表开发中的各种具体难题以及与常规手段的对比。在这里只做总结性地阐述。

比Java和SQL更易写

如前所述，集算器的设计目标是为了解决报表的数据准备，而目前这个工作一般采用Java或复杂SQL完成，存储过程及中间表也可以算作是SQL。

与Java这类没有提供直接结构化计算的语言相比，采用集合化语法的集算器代码会更为短小，这很容易理解，毕竟集算器基于Java提供了更高层的类库和方法。

短小不仅仅是写得快，而且还能容易理解和排错。一个页面内能看到更多的代码，从而能更完整地理解代码的含义。使用集算器编码时，伪实代码的比例大约是只有 1.5:1，绝大多数报表的数据准备算法可以在一个屏幕内显示出来。

而使用Java就很难这样，几十行代码下来仅仅能做个简单的汇总，一个完整的业务逻辑动辄需要几百行代码，翻看到后面时已经忘了前面是怎么做的了。

除了代码本身简短的外，集算器特有的网格式编码和调试方式还能进一步强化这个特色。程序员可以在一行写多句相关的代码，某句长代码不必完全显示出来从而不影响查看算法整体结构，循环可以用更直观的方式呈现，单步执行和单元格变量可以随时查看每一步的结果而提高调试效率。

这些，都可以让程序员专注于数据计算中的业务逻辑而非技术细节。

与SQL这类本身就支持结构化计算的语言相比，集算器完善了对分步计算、集合化、有序计算和对象引用等几方面的支持。对于日期和字串等运算，集算器也比大部分SQL提供了更丰富的方法。

许多情况用SQL也不是写不出来，但不能直接按自然思维实现，很费脑筋，这种代码放时间长了程序员自己都会忘了是怎么写出来的，给将来的维护也造成麻烦。

集算器代码则没有这些问题，符合自然思维习惯，即使是与SQL相同的思路也能更清晰地表达，很容易理解和维护。

比报表中计算更广泛

报表工具一般都可以完成计算列、分组排序等运算。基于非线性报表模型的工具还提供了跨行组和相对格与格集引用方案，可以完成相当复杂的运算。

报表呈现环节的计算是一种状态式的计算。所谓状态式计算，就是把所有计算表达式一次性都写出来，由报表工具根据依赖关系决定计算次序。这种直接把运算写到布局中的好处是很直观，在依赖关系不太复杂时能一目了然地了解各单元格的运算目标。

但是，在依赖关系较为复杂，计算需要分成多步时，这种状态式计算就显得困难了。还有的时候，计算的中间结果并不要呈现，这样就会出现隐藏格。隐藏格不仅将很大程度地破坏状态性运算的直观性，而且还会导致运算效率低下，占用更多内存。

比如要列出销售额占前一半的大客户，这时就有典型的过程性计算，在报表中要使用隐藏行列手段将不该列出来的条目隐藏，而不能直接过滤掉。再比如带明细的分组报表要按汇总值排序，这需要先分组再排序，而采用状态式计算的报表工具无法控制这个次序，这个报表也就无法完成了。

对于这类过程性计算或需要隐藏格的复杂报表，采用集算器在数据准备阶段完成计算，报表只负责呈现及少量的直观计算，可以有效地保留状态式计算的优势。把复杂运算到集算器完成，过程虽然多了一步，但结构更为清晰。

数据准备还能解决动态数据源和数据集的问题。报表使用的数据源一般是在报表工具中配置的，不能根据参数动态选择，而使用集算器数据源时就可以用脚本控制连接不同的数据源。通用查询报表要求数据集取数SQL不能简单地用参数控制，而要整体替换，支持宏的

报表工具能够一定程度地解决这个问题，但面对要将宏计算后才能拼进SQL的复杂场景也会感觉困难，而采用集算器数据集则无论是否支持宏、需要多复杂的宏计算都可轻松应对。

数据准备不仅能解决报表中的计算，还能协助处理格式。比如许多报表工具都支持纵向分栏，但很少有报表工具支持横向分栏，对这种需求无法处理。而采用集算器可以方便地将原数据集变换成横向拼接过的数据集，报表工作只要用普通的模板呈现一个列数更多的数据集即可。再比如许多报表工具不支持末页补足空行，也可以用集算器在返回数据集时补。

一致的多样性数据源支持

报表的数据源并不只是关系数据库，还可能是TXT或json等文件，而文件没有计算能力，所以常常要有一个过程将这些数据导进数据库，增加开发工作量。

如果采用集算器准备数据，则可以直接用这些文件作为数据源去生成报表，不需要导入数据库的过程。

数据库包括NoSQL数据库、文件包括HDFS文件，对于集算器来讲都是数据源。集算器自有的计算能力可以使这些计算能力不一的多样性数据获得通用一致的计算能力。比如文件几乎没有计算能力，MongoDB对JOIN和GROUP运算支持不足，各家SQL对窗口函数的支持程度不同、日期与字串处理能力也普遍不足且风格迥异。这些数据源都能基于集算器采用一致通用的方案来计算，而这将意味着更低的移植成本以及学习难度。

优化报表应用结构

虽然提高开发效率是集算器的初衷，但优化报表业务的应用结构才是集算器更重要的作用。可以说，集算器的出现是报表工具的二次革命。

解释执行降低应用耦合度

Java是编译型语言，代码需要事先编译才能执行，虽然也有动态加载技术，但在难度和复杂度都要大许多，一般应用程序员不常使用。这种情况下，采用Java编写报表数据准备算法将导致报表部分与主应用程序的高耦合性，具体来讲有这么两方面：

1.Java程序要和主应用一起编译并一般放在一起部署，这样用报表工具在外部开发出

的报表模板报表就需要和应用程序中数据准备算法配合才能工作，难以将本来相对

独立的报表功能作为一个模块处理。

2.相对于主程序，报表的修改更为频繁，如果牵涉到数据源的变动，则必须要改写相

应的Java程序，导致整个应用重新编译部署，很难做到热切换。

如果用集算器替换Java实现数据准备算法，则能有效地降低主应用程序与报表功能的耦合度：

1.集算器写出来的算法也是类似报表模板的外置文件，不需要和主应用程序一起编译

打包，而可以和报表模板放在一起管理维护，从而使报表功能模块化。

2.集算器是解释型执行的语言，在修改时不需要涉及主应用程序，只要把集算器脚本

替换就可以，很容易做到热切换。

另外，Java编写的算法一旦加载执行就会占据内存不再释放，即使相应的报表不再被访问。而使用集算器就不会有这个问题，算法执行完比后会立即释放，不再占用内存。

算法外置减少存储过程

采用存储过程实现数据准备算法和用Java类似，依然会造成耦合度的问题，只不过不是报表与主应用程序之间的耦合，而是报表与数据库之间的耦合：

1.存储过程存放在数据库中管理，报表模板在外部文件系统中管理，两者要对应起来

麻烦度很大

2.存储过程修改时需要申请一定的管理员权限做重编译，虽然不象Java那样难以做到

热切换，但数据库高权限的频繁使用会带来安全隐患。

3.比Java更糟糕的是，数据库及其中的存储过程可以被多个应用程序共享，如果管理

不善，很容易造成多个应用之间的高耦合，时间长了会搞不清楚某个存储过程在被

哪些应用调用，越来越混乱。

存储过程本身编写难度并不小，且强计算型代码的性能也不佳，原则上在报表业务中应当尽量少用存储过程，除非个别涉及数据量巨大难以移出库外计算的情况。

频繁使用存储过程要求高超的管理能力和巨大的管理成本，但这是大多数应用开发团队不具备的能力或不能承担的成本。

同样地，采用集算器也可以极大程度地减少数据库中的存储过程，算法外置后与报表模板一起存放管理，完全归属于应用本身，不仅降低与应用其它部分的耦合，更不会造成与其它应用的耦合。

数据外置减少中间表

所谓中间表，是指因为数据量或计算复杂等原因，直接基于源数据生成报表在性能和复杂度方面不可容忍，事先将数据整理汇总成的某个中间结果。报表的开发基于这些中间表进行，可以降低难度和提高性有

因为不可能为每个报表的每种参数状态计算中间结果，在生成报表时还需要进行一些即使较为简单的计算，也就是要求这些中间结果仍有计算能力。最容易获得的计算能力来自数据库，因此这些中间数据经常会被存储到数据库中。

与存储过程类似，使用中间表也会造成数据库管理的混乱。

关系数据库中的表是以线状方式存储的，相当于没有分类，各个应用用到的中间表混到一起，很难搞清楚。想管理好就需要强有力的控制能力，比如规定中间表的命名规则并保证得到执行，但强化管理常常是以牺牲开发效率为代价的。

如果管理不善，就会导致中间表越来越多，这其实是现实应用建设中经常看到的结果。有些数据库中会积累出上万个表，绝大多数都是为报表服务的，其中有相当多部分已经没有意义了，但因为不清楚有哪些应用还在使用这些表而只能保留，相应的ETL过程也仍然在毫无意义地浪费计算资源向其更新数据。

数据外置可以有效地减少中间表。

中间数据一般都是由不再改变的历史数据计算出来的，完全不需要数据库的事务一致性能力，因为是导出的冗余数据，也不需要很高级的安全稳定要求，存在数据库中仅仅为了获得计算能力。如果我们有办法让中间数据存放在文件系统中且拥有计算能力，那就没必要让这些数据占据昂贵的数据库空间了。

集算器能够实现这一目标。

外置的中间数据可以使用文件系统的树形结构管理，与报表模板及数据准备算法统一存储，而集算器可以使这些数据继续拥有强大的计算能力为报表服务。这样，不仅管理简单方便，而且可以少占用数据库空间而成本更低，再者，文件系统还有比数据库更高效的IO性能，更适应于报表业务。

混合运算实现T+0报表

关系数据库强大的事务一致性能力目前在业界尚无有效的替代者，为保证交易的完整性，当期还在变动的数据仍然有必要存放到关系数据库中。

然而，为了实现T+0报表，我们还需要把历史数据继续存放在当期数据库中一起计算，而历史数据常常要庞大得多，这会要求我们建设更大容量的数据库，显然会导致更高昂的成本。而且这个量并不可能一直增长上去，太大了会直接影响当期交易业务的性能。

为了解决这一矛盾，通常的办法是只保留部分历史数据在当期库中，把远期的历史数据被移出独立成库，这样的结果是只能查看近期的报表或远期的报表，但不能查看混合的报表，不能做到真正的T+0报表。

当然，还可以把当期交易库和远期历史库混合运算生成T+0报表，这就需要跨数据库的混合计算能力。

理论上许多数据库都支持这种跨库运算，一般是将外库数据映射进本库，实际运算时要取数据到本库执行，这样在应用中的性能和稳定性都较差，实施成本不低。而且历史库的容量较大但不需要事务一致性的功能，很可能被建设成与当期库类型不同的数据库，这样数据库厂商本身提供的跨库运算机制就更难实施。

集算器可以完成这个混合计算任务。

集算器自有的计算引擎不依赖于某个数据库，各库内的数据计算仍由各库进行，将各自的运算结果取到由集算器汇总处理，再将结果传给报表工具去呈现，从而即可实现全面的T+0报表。显然，这种机制还方便横向扩展，历史库可以有多个不同类型的数据库。

而且，在集算器的支持下，历史数据还不必一定要以数据库的形式存放，可以存储在IO 性能更好的文件系统中，配合集算器的集群服务，可以在更低廉的成本下获得更好的性能。

直接使用多样性数据源

集算器支持多样性数据源。比如NoSQL数据源，文件数据等，都可以被集算器直接计算而不必导入关系数据库，这样可以不再建设多余的数据库，成本更低而且降低数据不一致的风险。

这些非关系数据库在某些方面比关系数据库更强，只是计算能力不足或不同，如果用集

算器辅助，则可以保留其原有的优势。比如MongoDB的对追加型日志数据的吞吐能力就远远超过普通关系数据库，但结构化计算能力较弱，用集算器来弥补则可以数据继续保留在MongoDB中获得其高吞吐性能。

提升报表运算性能

集算器优于报表引擎

集算器的性能大多数情况优于报表引擎，这样如果把一些计算从呈现环节移出到数据准备环节，将会获得更好的运算性能。

多个数据集对齐呈现是很常见的报表形式。数据对齐是典型的JOIN运算，而在报表模板中，对齐关系是单元格之间用表达式各自定义的，这样在实现运算时只能采用遍历方式对齐，复杂度是平方级的。而采用集算器则可以事先将多个数据集对齐再提交报表工具用单数据集呈现，借鉴SQL的实现，集算器采用了更高效的HASH算法来完成JOIN，复杂度是线性级的。对于有序的数据集，集算器还可以采用二分查找算法定位，但用报表很难在单元格中描述这种运算。

报表引擎采用的状态式计算方案要么无法利用中间结果，每次计算都只能从原始数据和单元格开始，有些涉及单元格集合的运算效率会更低；要么就采用隐藏格来保持中间结果，这又会占用太多内存，而Java程序的性能对内存相当敏感。而且，报表计算时是带着单元格外观属性一起进行的，这会占用更多内存。

使用集算器事先准备数据则没有这些问题，过程式计算可以方便地复用中间结果，只进行纯粹的数据计算，不涉及隐藏格和外观属性，内存使用效率更高。

报表单元格之间复杂的依赖关系导致多线程并行计算非常困难，而集算器则天然支持并行计算，特别是涉及数据库文件等外存数据的时候，可以充分利用现代CPU多核的优势。

我们知道，数据库的JDBC性能较差，而报表性能又严重依赖于取数环节。如果数据库负担不沉重时，可以采用多线程并行的方式同时建立多个数据库连接从数据库分段取数，实际测试表明可以达到几倍的性能。但报表工具一般无法直接实现这个效果，借助集算器就可以很轻松地实现了。

使用缓存能够有效地改善用户响应速度方面的体验，高端的报表工具一般都提供缓存功能。但报表工具的缓存机制比较死板，要么全有要么全没有，不能只缓存报表的某个部分，两个报表有共同部分也无法复用缓存，难以分别缓存指定不同报表在不同参数下的不同生存周期。毕竟报表工具采用可视化的配置方案，很难设置过多复杂的参数。

采用集算器准备数据时则可以实现可控缓存的效果，集算器是程序代码，可以由开发者灵活决定使用缓存的时刻及范围的策略，这样就可以实现报表的部分缓存、多个报表之间缓存复用、以及不同缓存的不同生存周期。

集算器对数据库的性能优势

我们知道，文件系统的IO性能要好于数据库，这是因为数据库要为将来可能发生的写操作预留空隙，存储不够紧致且管理要复杂些。

实际测试也表明，基于Java的集算器对大数据量的遍历性能能优于基于C语言的Oracle 执行SQL，在使用多线程时差距会更明显。如果再考虑到数据库JDBC的性能损耗，使用文件数据源配合集算器运算的方案将比基于数据库存储数据获得好得多的性能。

在内存够大时可以事先将数据读入内存以获得更高的运算性能。集算器支持内存记录的引用，用这种方式表达的连接运算与传统SQL的外键对应方式相比，不仅运算描述更为简单，运算性能也高得很多。实际测试表明，集算器的指针连接方式能比同容量的Oracle外键连接方式快出一倍以上。

在脚本执行方面，测试表明，集算器代码解释执行性能也极大幅度地优于Oracle存储过程代码。这样，对于难以直接使用SQL写出的过程性复杂运算，如果有将数据外置使用集算器运算，将好于在库内使用存储过程运算。

与存储过程的低效不同，大多数情况下SQL的执行效率很高。但如果SQL过于复杂，有许多JOIN和GROUP等嵌套在一起时，SQL可能会表现出很糟糕的性能，原因是数据库不能正确地优化复杂SQL的执行路径，而SQL不提倡分步的语法让程序员实施干预相当困难。这时，采用步骤化的集算器指挥和辅助SQL运算可能缓解这个问题，相当于由程序员干预了执行路径。我们曾有过一个案例，将一句复杂SQL拆成多个子句分别执行后再由集算器汇总重这些结果返回给报表，获得了数倍的性能提高。

当然，也不是所有运算集算器的性能都占优。实际测试发现，集算器的文件索引性能要低于Oracle，目前还在进一步优化中。另外，Java程序的内存使用效率较低，同样内存容量可装载的数据量远小于基于C语言开发的数据库，在涉及数据量和内存容量基本相当时数据库的优势会更大。

是否使用文件系统加集算器替代数据库运算，需要根据实际情况具体决定。

多数据源集群汇总

集算器的多线程机制还可以用于操纵多个数据库以集群方式并行计算以获得更高性能，这个优势还可以横向扩展。

前述的T+0报表即可用于多数据库集群方案。多个数据库分别分段存储数据，每个数据库的数据量都不大。集算器以并行方式发出SQL要求各个数据库分别计算，收到结果集后在集算器端再汇总后输出给报表工具，常见的过滤、分组汇总等运算都可以很方便地完成。数据量进一步增长时可以再增加更多的数据库分段以实现横向扩展。

数据库本身的集群方式，无论是配置复杂度还是环境成本要求都远远高于这种方案。采用集算器实现多数据库集群还允许数据库不同构，比如可以将小型机上的Oracle与PC服务器上的MySQL集群起来。自有的计算引擎和多线程机制可以把这些分立的数据库有机地集合起来。

这个方案要求各个分段数据库的运算除了最后汇总外不再有关联，但实际运算时会发生所有分段数据都要与共同的维表做连接的现象，这时可以把维表冗余地复制到每个分段数据库中。一般业务系统中不可分段的维表都远小于可分段的事实数据，这种冗余方案可以有效减少节点之间的传输，而采用数据库本身的集群一般不能自由控制冗余方案。

另外，集算器本身也有可集群的服务器，这样可以将上一段所说的某些场合下文件系统配合集算器运算的高性能利用起来。这个问题不是这里的重点，我们会再做个专题讲述集算服务器的应用方案。

集算报表

集算报表用于面向程序员开发固定报表，可理解为原润乾报表4的升级版。

固定报表是指事先开发好、用户输入参数后由程序计算出结果的报表，这些报表一般都具有业务逻辑和计算过程复杂的特点。对应地，有些相对简单的报表可由业务用户自行编制，称为自助报表，润乾有另一款产品来解决。

集算报表是中间件产品，不是一个面向终端用户直接可用的应用系统，必须由程序员集成到应用中。集算报表没有提供用户权限以及管理看板、KPI分析等功能，这些需要应用程序员进一步封装。集算报表没有直接提供移动端APP，但可以输出基于HTML5和SVG的报表和图形，程序员可以轻松地定制出需要的APP。集算报表也不是交互分析产品，可以基于链接功能开发出关联报表以实现出钻取效果，但并不是专业的交互分析工具。

集算器和报表工具的集合体

在润乾报表中集成了集算器的运算引擎，就形成了集算报表，也就是集算器和报表工具的一个集合体，这从名字就能看出。

集成了集算器，当然前面所说的那些好处都可以在集算报表中得到体现。另外，由于都是自家产品，两者在在结合时仍有一些独到的优势。

Java程序之间的API调用会获得更高的效率，但要长期保持已开放API的兼容性会增加许多技术成本，而JDBC恰好是业界最常用的结果集返回标准，为了保证兼容性和应用广泛性，集算器对外的接口设计成标准的JDBC而没有放开普通的API调用。

但同一公司的产品就没有这个问题了，集算报表没有用JDBC方式与集算器连接，而是用了更高效的API调用。

以API方式集成了运算引擎后，集算报表就可以提供脚本数据集，对于简单的集算脚本可以直接在报表工具里写几行代码，和报表模板一起存储，而且能够共享报表模板中设置的数据源。这样不仅让报表开发更为简洁，而且管理一致性更容易得到保证，毕竟两个要配合使用的文件（报表模板与集算脚本）总不如一个合并文件管理更方便。

使用API方式连接，集算器脚本不仅可以返回数据集，还可以改写报表的宏（参数）值。使用宏可以使报表获更灵活，但有些宏值需要一些运算拼接后才能更好地应用（比如从基本字段列表拼出一个报表表达式），而报表工具没有这种运算能力，目前的方案一般是要求上

层传入已经拼好的宏值，信息重复且带来工作量。

API方式还可以返回JDBC接口不支持的层次结果集，这在报表中较为常见，比如主从式报表、分组报表。集算器本身支持多层数据的计算和处理，但JDBC标准不支持，在返回时必须转换成单层数据。而集算报表没有采用JDBC与集算器接驳，这样就可以直接接收多层数据做进一步呈现。

多层数据的好处有两个，一方面是呈现模板更简单，多层主从和分组表只要有一个数据集，不需要再做多个数据集的关联；另一方面是性能更好，在集算器准备数据阶段已经把关联计算完毕，报表环节只要直接呈现，无须再次计算关联。

集算器还支持图形绘制，提供了逻辑坐标体系，可以用于绘制一般统计图组件不能直接支持的图形，不过目前只支持平面静态图形，以后会逐步完善动画地图等功能。

由于JDBC接口标准并没有图形相关的尺寸属性，目前集算器还只能向Java程序返回绘制好的图形，不能直接返回给报表工具。而集算报表不使用JDBC，可以利用内部API接收集算器绘制的图形去呈现，让报表中出现更丰富的自定义图形。

呈现环节

集算报表延用了原润乾报表的内核，并在此基础上重点做了如下一些优化精简：

1.报表中函数和表达式改用了集算器的语法风格，保证学习的一致性

2.统计图外观做了优化，增加光照效果，以及支持移动设备的SVG图形等

3.增加对第三方开源图形包的支持，特别地可以集成第三方地图

4.增加对动态多层报表的支持以及更方便的数据集定位语法

5.剥离原有的填写功能，专心致力于BI目标的业务，填写功能另外发展

6.取消原有的语义层，专注于固定报表，自助报表功能也另行发展

7.取消了附加数据集，用集算脚本和数据集定位语法实现

集算报表在呈现环节上继承了非线性报表模型，因而也能继续支持多源分片、行列对称、灵活格间计算等复杂报表功能。非线性报表模型已经这成当前国内报表业界的标准，其细节这里就不再赘述了。

可视化是近年较热门的话题。广义地讲，报表也是数据可视化的一种形式，但我们一般所说的可视化一般是指将数据以图形方式呈现，特别是用动画效果呈现数据的特征。

可视化在技术上主要有两个环节的难点，一是图形（或动画）呈现，二是数据准备。图形（动画）本身是个较专业的领域，涉及种类繁多，而且缺乏统一的模型，一般都只能逐个实现，工作量非常巨大。好在近来业内出现了许多功能强大的开源图形包，能让开发者以较少的工作量即获得很好的可视效果。

同报表类似，图形要呈现的数据往往也不是直接就有的，仍然需要复杂的计算过程才能准备好。

集算报表开放了集成第三方图形包的接口，程序员可以将自己熟悉的开源图形包嵌入到集算报表的单元格中，利用集算引擎准备数据，并通过报表传送给图形包，从而实现丰富的可视化效果。

移动呈现也是近期的热点，许多报表厂商自己提供了移动端APP。但作为中间件产品，

集算报表没有也不能直接提供移动端APP，APP是完整功能应用的一环，其中会涉及用户权限、资源组织等各种与应用场景密切相关的管理类功能，无法事先做好。事先做好的APP 常常不能匹配现场管理规则而无法使用，且又缺乏集成性，难以再编程。

集算报表提供能适应移动端呈现的HTML5输出格式，支持纯javascript的图形绘制，并为移动端增加了长按事件，确保开发人员能轻松地将集算报表嵌入到自己写的APP中，实现适应实际业务规则的APP。

对比理解

国内的报表工具产品基本都已采用了非线性报表模型，因而在呈现环节上与集算报表的差别不大；但在数据准备环节仍然是传统的硬编码方式，和集算报表没有可比性。所谓零编码制作报表只能适应很简单的报表，虽然数量并不少，但所占工作量并不大。

国外的报表工具大都仍在采用落后的条带控件式模型，在报表呈现环节就效率低下，而且有相当多格式并不算很特别的报表根本无法完成，特别是涉及多数据源的情况。在数据源准备环节更是完全没有。

报表工具是国内产品大幅优于国外产品的领域。

OLAP产品常常是报表工具厂商进一步发展的方向。与专业的报表工具相比，OLAP虽然也能完成一些报表呈现，但都是规律性很强的简单报表，其擅长点在于针对报表实现交互式的变换。另外，OLAP产品的集成性相对较差，不方便嵌入到应用系统中。集算报表不提供这些自动交互功能（可以用链接功能实现有钻取效果的关联报表），但能开发复杂得多的报表，而且集成性非常好。

还有些报表工具厂商会基于报表工具实现报表应用系统，将用户权限、报表发布管理等功能功能都加进去，用户直接可用，但普遍集成性较差，难以二次开发。集算报表则专心实施中间件策略，以优秀的集成性由行业集成商完成这些外围有行业和地域特征的功能。