前文大致已经给大家介绍过集算器和集算器的作用了。可能还会有许多人心存疑惑，这标题不是报表工具的二次革命吗？集算器能为报表工具做些什么？又是怎么能够提升报表计算能力的？又能否提高结构化计算能力？这篇文章会解开大家的疑惑。

优化报表应用结构

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

解释执行降低应用耦合度

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中获得其高吞吐性能。

想了解更多集算器的文章，请继续关注我们。

报表可以理解为多样的布局 + 动态的数据 + 丰富的输出，数据是报表的核心。所有炫动的布局和展示都是建立在真实数据基础上，缺少了真实数据报表则是空洞没有意义的。因此数据源设置是报表数据绑定操作的第一步，也是最核心的一步。

如果说数据是水，数据库或数据文件就是水库，那么数据源就是连接水库的管道，用户看到的数据集是管道里流出来的水。因此信息化工具必须能够支持强大的数据源，兼容的数据源类型必须能够覆盖现有的数据类型。

报表的数据来源可以是数据库（如：SQL Server、Oracle、Mysql、SQLite、Postgresql）等关系型的数据结构，也可以是单独文件（如：Excel、XML、Txt,CSV,Json）等业务系统生成的数据文件，也可以是其他形式（如：WebService、Google Analytics、Salesforce）。

葡萄城报表支持更丰富的数据源格式，不仅支持常用的SQL Server，Oracle，Mysql 等关系型数据库，更能够支持JSON，CSV，XML 等文档型数据源，JSON 数据是Web系统数据传递的DNA，因此支持Json 数据源为用户创建Web端报表提供了极大的便捷性。

常见报表支持绑定数据源方式

1. 根据报表状态将绑定数据源类型分为：

设计时数据源：在设计时为报表设置报表数据源，即设计报表时，已经预先设置报表数据源，用于研发内部、报表小组进行配置、测试报表用。运行时数据源：在运行时为报表设置报表数据源，即动态绑定数据源，用于数据动态生成的报表系统，运行时数据源可在运行时执行相关数据源操作如修改数据库连接字符串。设计时数据源的运行比较广：配置报表、测试、运行报表。而运行时数据库切换数据库连接字符串即可无缝实现数据源在用户现场部署，相对比较容易。

2. 根据绑定的报表数据源数量分为：单数据源：为报表只设置单一的数据源。多数据源:当单一数据源无法满足报表需求时，需要为报表设置多个数据源，报表显示的数据来自多个不同的文件或数据库。

设置报表数据源

每个报表工具都有自己的数据源绑定操作流程，但是无论是哪种报表工具，都包含以下基本步骤。

设置设计时数据源的基本步骤：

1.指定数据源

2.指定数据集

3.将数据集字段与数据控件绑定

设置动态时数据源的基本步骤：

1.添加数据控件

2.设置空数据源及数据集，数据字段

3.将数据字段与数据控件绑定

4.在代码中添加需要的数据源，与设置的数据集对应

葡萄城报表中使用Json 数据源

JSON数据格式已成为互联网的DNA。因此在AR11中我们智慧的开发者们也教会AR来使用JSON 数据源，增加了对JSON 数据的支持：

文件系统

Web服务

REST API

葡萄城报表不仅支持静态时直连JSON数据，也支持为报表绑定运行时JSON数据；页面和RDL 报表均提供了JSON 数据提供器。

JSON 连接字符串和查询语句定义

JSON 数据源的连接字符串包含以下内容：

Json schema 可以是schema URL 或文件路径

内嵌JSON Schema

JSON 数据文件可以是引用外部json 文件的url或路径，这些文件中必须包含 ”xmldoc”关键字。如：

jsondoc=http://xmlfiles/examples/cd_catalog.json

使用”jsondata”关键字将数据内嵌到报表中，如：

jsondata={"employees":[{"firstName":"John", "lastName":"Doe"},{"firstName":"Anna", "lastName":"Smith"},{"firstName":"Peter", "lastName":"Jones"}]}

jsondata支持表达式的使用，表达式可以在运行时使用，如依赖用户使用上下文的json数据源。

数据集查询语句遵循JSON PATH的规范。

1. 新建RDL 报表

2. 添加数据源

2.1 选择JSON 类型

选择Schema

如果您不知道具体的JSON Schema ，推荐网站可根据您的Json Data生成对应的Schema:

http://jsonschema/#/

设置内容

查看连接字符串

3. 添加数据集

右键单击“DataSource1”选择添加数据集

选择可视化查询设计器

JSON查询生成器，会根据您指定的JSON Schema生成具体的Json结构，可根据选择生成查询语句

选择节点后，点击确定，自动生成查询语句，点击确定后，会生成可选的字段名称。

在数据控件中绑定数据

在这里Json数据源就绑定成功了。

当我们在做报表查询时，可以通过参数来控制查询的数据，但有时又想不输入参数时查所有数据，这个能够实现吗？答案是肯定的，没问题，只要在sql里设置条件时把NULL加上就可以了，基本的语句就是：id=? or ? is null。

皕杰报表中输入参数为空时要取全部数据也是用sql加条件 id=? or ? is null形式，但是有几种情况这种方法并不适用。

(一)当参数类型为数组时sql语句用in(?)形式，如果写id in (?) or ? is null，如果输入多个参数时会报语法错误。

解决办法：

sql语句写成 SELECT * FROM test where id in (?) or ?=’!EOF’,然后在对应的第二个数据集参数处写if(@参数名==null,”!EOF”,”!EMF”)即可。例：

(二) informix数据库不支持 id=? or ? is null语法,同样sql中写 id=? or ?=’!EOF’， 然后在对应的第二个数据集参数处写if(@参数名==null,”!EOF”,”!EMF”)即可。

(三) DB2数据库不支持 id =? or ? is null语法。

解决方法同第二种方法。

20世纪30年代，宝 洁诞生了第一位产品经理，全权负责一款肥皂的生产、销售以及全流程的成功。

80多年后，随着互联网的蓬勃发展，出现了越来越多的产品以及和产品相关的各种岗位。；围绕产品的思维与工作方式被越来越多的人所认可，产品成功的思维模型被搬上了课堂。

数据报表，作为一个链接IT部门和业务的中间件，承担着信息沟通的作用：数据展示业务信息，为业务决策提供依据；业务产生数据，最终以数据报表的方式呈现。

同样，我们也可以用产品工作的方式来复盘一下搭建报表系统的整个流程，并且和产品的上线流程做一个对比。

产品的上线流程

市场分析——>竞争分析用户分析——>需求（场景）分析——>功能设计——>开发——>发布——>运营——>迭代

互联网产品初期，在初次面向市场的时候，产品往往是一个MVP（最小可用单元），通过种子用户的反馈，分析使用数据，验证产品的可用性，快速迭代，逐渐修正与完善。

报表系统的上线流程

同行业报表项目参考（行业咨询）——>业务部门需求采集分析——>报表设计——>上线——>end

绝大多数的企业在报表上线之后，都忽视了一个关键动作——运营，以致于IT部门陷入了一个怪圈，疲于应付业务人员的需求，天天加班工作却得不到认可。实际上，系统上线不等于终点，被大量使用与认可才是成功的第一步！

产品如何做运营

1、冷启动

冷启动是什么？冷启动是一个产品刚诞生的一个阶段，此阶段的产品面临着以下问题：

缺少用户及相关资源。产品模式未成熟，能否满足用户，迎合市场趋势仍是未知数

因此，在此阶段的主要目标的作用有：

根据数据分析，验证产品是否满足用户需求验证是否能符合市场趋势验证商业模式是否成立

互联网产品怎么做？

种子用户，聚拢一批符合产品目标人群的用户，获取真实的使用数据MVP（最小可用单元）验证，判断产品是否满足了目标用户的最小可用需求存失分析，依据用户的真实使用数据，分析留存的原因（建立产品优势），放弃部分的流失用户，修正产品的定位。

2、高增长

高增长是指在产品通过市场验证，处于快速发展的阶段，通过运营实现产品用户与价值的持续增长

互联网产品怎么做？

持续推广与曝光精细化运营，针对人群、场景、流程做差异化细分运营的运营策略，提升运营动作的效率最大化基于用户数据分析的产品不断迭代优化

报表系统如何运营

帆软的一家互联网行业客户告诉我们，为了让报表系统被业务部门认可，IT部门在上线报表系统的初期以及推广期主要做了4件事：

1、冷启动阶段

a.寻找种子用户

优先挑选了营运部门的管理层作为种子用户，依据需求为其定制了PC、移动端两张营运报表，报表上线后不断关注其访问量趋势，发现移动端模板的活跃度更高，并且用户对模板的评价非常好，随着口碑的传播，分公司的营运部门也提出了类似的需求，IT部门开始重新考量整个营运部门的需求，为其系统化的搭建报表应用

b.简单的用户数据分析

这个阶段的用户数量和模板数量都还处于一个比较小的数量级，只需要通过用户的访问数据，验证报表是否满足种子用户的需求

2、高增长阶段

a.从三个维度和两类应用场景分析用户的使用数据，关注性能与用户体验，促使报表系统不断优化

三个维度：

1、报表系统的整体访问趋势

——把控报表系统的整体运营状态，研究用户的访问习惯，合理分配资源

2、每一位业务人员的访问趋势

——充分掌握哪些业务人员的数据诉求更为强烈，那他们的数据需求被响应的优先级将会更高；那些一个劲提需求，却没有访问量的部门，我们需要重新核算成本，降低他们的需

求优先级

3、每一张报表的访问趋势与性能体验

——每一张报表都是一个产品，同样也有完整的生命周期，不被需求的报表要及时的淘汰，降低运维成本；访问量火热的报表要纳入优化迭代，提升用户访问感知，深挖需求，扩充业务场景

两类应用场景：

数据大屏/移动端报表

——什么样的数据分析场景更加在哪类终端上访问量更高？我们是否需要为其专门打造一张移动端的模板，更美观的样式，更人性化的交互效果？

b.主动推送与推广

——内容推广

伴随着报表系统的不断迭代，每一次为业务人员扩充的应用场景需要通过渠道来推广与宣传，促进用户的使用率，这个渠道可以是企业内部的宣发平台，也可以通过C端市场中的新媒体渠道（微信公众号等）

——报表推送

业务人员常用的报表可以通过帆软提供的推送功能直接触达最终用户，培养其对报表的使用粘性

帆软能提供哪些帮助

1、固化的用户行为数据分析

FS平台为用户提供了常用的运营数据统计功能

访问量数据：包含平台访问次数、模板访问次数、用户数等内容模板热度：不同模板在周期时间内的访问总数用户行为：不同用户在周期时间内的访问总数，并且区分统计出查询、导出、打印等不同的用户行为性能监控：不同模板的平均响应时间、平均内存等内容

注：模板热度、用户行为、性能监控数据统计需要安装“高级系统监控”插件

借助于常用的运营数据统计，我们可以对报表系统做一个整体的评估，对整体的访问量、模板热度、模板性能做到心中有数

2、深入的用户行为数据分析

作为数据分析的先锋，只要有数据源，没有IT做不了的运营数据分析。FR会将用户的访问数据存储至logdb数据库当中，可以直接通过设计器链接数据库定制运营所需分析模板

我们需要关注logdb数据库中的两张表与一个字段

表：PUBLIC.FR_EXERECORD

该数据表是报表正确执行日志表，即如果报表执行成功，将会在该表中添加一条记录，并在相应字段中填写其对应的信息记录

表：PUBLIC.FR_FSRECORD

该数据表是为了统计一段时间内，系统的使用情况，用于管理员查看在线用户数及用户系统使用情况，因此用户登录决策系统时，将登录信息保存入库，将会在该表中添加一条记录，并在相应字段中填写其对应的信息记录

字段：BROWZER

该字段记录了客户端访问报表所用的浏览器版本以及移动端信息terminal：包含终端类型、app还是h5等信息。例如：“terminal”：{"OS"："app"，"type"："mobile"}

借助于以上内容，我们就可以定制出自己所需的数据分析报表，重新把控报表系统的运营情况，为后续的迭代提供指引

3、主动推送与推广

帆软为每一种报表使用方式与场景都提供了消息推送的服务，包括了：平台消息推送、微信/钉钉消息推送、APP推送、邮件推送等

我用十年，总结出一个改变无数人瞎忙的Excel技巧

什么是Excel最高级的用法？用超复杂的函数公式、还是编写出长长的VBA代码？认为都不是，最高级的Excel用法是：

用最简单的Excel技巧解决复杂的问题

今天分享的不是Excel新功能，而是多年数据分析工作经验总结的一个技巧：数据库式表格。不需要任何函数公式就可以帮你完成复杂的数据提取和分析

什么是数据库式表格？先看看平时我们用的表格样式：

有标题行

有不太规则的文字注释

有合并单元格

同列有不同的数据格式

下面是一个数据库式表格：

第1行为标题行，标题字段无重复

一行行数据规范排列，无合并单元格

同一列数字格式完全相同（标题行除外）

数据式库表格有什么用?

很多同学（特别是集团财务、数据分析岗位）应该在月末或平时，做各种跨年、月的数据汇总或对比表格，多数人都是一个个打开各年、各月的数据报表，一列列、一行行的复制粘贴。如果学会用数据库表格，你会发现你以前都在瞎忙。

以上面的利润表为例，它记载着公司在某个期间的所有收入、成本、费用、利润等数据。

首先，我们把各个公司的利润表数据复制到总数据库中：（如果提取很多公司数据，编写VBA宏程序后只需点一下按钮，不会VBA的就手工复制吧），里面要含必须的字段信息，包括公司名称、年、月等。

然后，生成一个数据透视表备用，修改显示格式为表格样式

接下来，你就可以利用数据透视表，生成各种各样的汇总、对比及分析报表：

1、2017年收入对比表

2、2016年费用对比表

分分钟就可以生成

3、2016年、2017年费用1~3月费用对比表

还可以添加公式，计算2016年2017年1~3月份差异

如果数据库中有计划数，还可以用公式生成完成率。

同样的方法，你只需要在数据透视表中拖拖拉拉、添加计算公式，跨年、月、项目的报表可以随意生成。

按照数据库的储存结构，可以把你工作中所用到的信息全集中到一个表中（如果数据量实在是太大，就分多个数据库式表储存，需要跨表汇总时可以用公式或Power Query实现数据汇总和筛选），原来就是这么干的，工作很省心、省力。如果你会VBA编程，从报表整理成数据库也只需点一下执行代码的按钮就完成。

很多读者看到漂亮的图表都会问“这个怎么做”，“用什么工具实现”。制作漂亮的可视化一般有这样几个方式：

利用Excel内置的图表做一些常规的统计图。高级复杂的譬如动态图表，图表的筛选展示可以通过写VBA来实现。通过R、Python一类的数据分析语言，调用图表功能包，呈现可视化的数据，数据分析常用。借助Echarts、HighCharts、D3.js等开源的可视化插件，嵌入代码，开发成插件包，可视化工程师和前端开发常用。

可视化最实用的场景就是做报表。既然这次的主题是可视化，那小编今天就细细地讲一下酷炫的可视化报表是怎么做的？有哪些基础和高级的可视化图表？代码开发是怎么一回事？大屏又是如何操作？

代表工具FineReport，此前介绍过FineReport的使用场景和功能。大家若不熟悉，可自行和Excel绑定对比。

你用过Excel，却不知还有一款神器“FineReport”这款效率远超Excel的表格工具，没用过就可惜了！

基础图表+表格

柱形图、折线图、饼图、气泡图、散点图等能满足常规的数据统计。拿到数据后，先分析要展示几个维度，选用什么样的图表，需要几个图表展示等。

如何选择图表的类型？

基础图表的制作流程

在FineReport中，图表的操作流程类似Excel，数据准备——插入图表——选择图表类型—选择分类轴、系列名称和系列值——选择图表样式。

各式各样的表格

表格主要在于文字、数字、格间的美感，以及整体的色彩搭配和谐，这些在FineReport中都可通过自定义来是实现。

高级图表

高级图表都是在基本图表的基础上展开来一些新特性。

饼图类：等弧度玫瑰图、不等弧度玫瑰图…

柱形图类：堆积柱形图、百分比堆积柱形图…

条形图类：堆积条形图、百分比堆积条形图…

折线图类：堆积折线图、面积图…

仪表盘类：多指针的仪表盘360度、多指针的仪表盘180度、百分比圆环仪表盘、百分比刻度槽型仪表盘、试管型仪表盘…

雷达图类：普通雷达图、堆积柱形雷达图…

气泡图类：普通气泡图、力学气泡图、十字象限气泡图…

地图类：区域地图、点地图、大数据流向地图…

还有各种组合图，比如“柱形图—折线图、柱形图—面积图、堆积柱形图—折线图、自定义地图”…

其他，还有漏斗图、甘特图、词云、框架图等等。

这些图在FineReport都是现成使用的。在其他工具或其他使用场景中，可由交由可视化工程师开发。

为了高度结合数据分析的过程，更好的理解数据背后的业务意义。可视化图表除了形态还有动态展示部分，就是所谓的动态可视化。

例1：地图的钻取和联动

例2：图表联动

例3：点击词云跳转链接

例4：图表切换

过去这些动态特效和交互属性都要写代码开发，这个在FineReport都已经封装成一个个功能，还有图表缩放、自动刷新、数据提示。再复杂点，就是设动态参数加超链。

利用开源插件开发

就是用市面上开源的数据可视化工具， 譬如Highcharts、D3.js、百度Echarts、蚂蚁金服AntV、GoogleCharts、Raphael.js、Sigma.js、three.js等。

像在7月，我们举办了一场可视化插件开发大赛上，很多开发者开发了令人心动的图表插件。

譬如下方的3D城市全景地图，作者Little使用Echart-GL开源库和MapBox，与地图结合，基于真实地图和基本建筑数据构造都市圈级别的宏大场景，适用于政府部门、连锁企业、LBS提供商等对真实经纬度和展现区域范围敏感的用户。插件的底层是WebGL（Web Graphic Library），它是一个 JavaScript API，用于在任何兼容的 Web 浏览器中渲染 3D 图形。WebGL 程序由用 JavaScript 编写的控制代码和用 OpenGL 着色语言（GLSL）编写的着色器代码构成，这种语言类似于 C 或 C++，可在 GPU 上执行。

比如滚动报表图。传统的决策报表块是静态的，列表不会滚动，数据必须一次性展现，在大屏中效果不够酷炫，无法自动获取最新的数据，除非编写大量的js代码，对一般人来说就只能望洋兴叹。

而插件安装后，可以用图表的形式展现报表，通过设置数据集，显示成类似报表块列表，零代码获取数据库信息并配置自动更新时间，支持通过字段名称配置表头，支持自定义颜色配置等多种丰富的配置项，这样制作的决策报表效果也更酷炫。

数据大屏

大屏展现作为数据可视化的一个典型使用场景，涵盖的知识太多。一个完整的大屏项目从开始调研到实施交付可能需要开发工程师、项目经理、视觉工程师、UI工程师、硬件工程师等等众多专业人员的参与。

于数据大屏设计美学：大屏做成这样，领导不重用你都难！数据大屏的具体制作：4步教你玩转可视化大屏设计｜内附实际操作

-----------------

最后，12月28日晚上20：00，帆软将在知乎上举办 “如何成为企业需要的数据分析人才” Live 直播，教大家如何找到数据职业生涯的破局点，欢迎大家参加！

数据统计分析软件有哪些？哪个数据统计分析软件比较好？这是很多人的疑问。其实在报表项目中，常常会碰到数据库压力很大影响整个系统性能的问题。由下面的传统方案的结构示意图可以看出，所有源数据的存储和计算都放在数据库完成。当并发访问量较大的时候，虽然每个报表的数据量不大，还是会造成数据库压力过大，成为性能的瓶颈。多数数据库厂商提供的jdbc接口传输数据比较缓慢，在并发量较大的情况，对报表系统性能的影响也非常明显。

这种情况时可以考虑采用润乾集算报表提供的本地计算方案。

所谓本地计算，是将一部分计算任务从数据库移出到报表服务器中完成。大多数有一定规模的应用系统中，数据库和应用服务器通常会部署在不同的物理机器上。其中，数据库处于中心地位，要为各个应用系统提供服务。如果运算大部分由数据库完成，则会导致数据库压力过大，而数据库的扩容成本和难度都相当高。而应用服务器则不同，不同应用会有不同的应用服务器硬件，且容易集群扩容。如果能将一部分运算移出数据库，转而由与应用服务器一起部署的报表服务器完成，则会很大程度地减轻数据库压力，并且充分利用应用服务器所在机器的计算能力，提升系统性能。集算报表方案结构示意图如下：

从上图可以看出，润乾集算报表可以将部分数据从数据库转移到报表应用服务器的本地硬盘。这部分数据可以是计算的中间结果，也可以是部分基础数据。集算报表内置了集算引擎，可以通过简洁的脚本进行本地化的数据计算。因此，从数据存储和计算两方面都可以降低数据库压力。

部分数据和计算从数据库转移到报表应用服务器上，可以充分利用应用服务器集群的存储和计算能力。应用服务器无论是单机升级（纵向扩展）或者增加集群数量（横向扩展）都要比数据库服务器的成本低很多。在本地硬盘上读取数据的速度要比数据库jdbc快很多，可以解决这个瓶颈问题。集算引擎还可以进行多线程的并行计算，可以充分发挥应用服务器多cpu、多核的计算能力。因此，润乾集算报表方案是低成本提高报表应用系统性能的优选方案。

下面，通过“某公司客户累计销售额与去年全年销售额对比报表”的制作，来看一下集算报表是如何实现本地化计算的。报表如下图：

这张报表中，2010年1月-10月的客户、订单数、销售额直接来自数据库。2009年全年的订单数、销售额是从报表应用服务器文件系统的temp2009sales.b文件中读取的。“销售额/去年销售额”则是今年和去年的数据共同计算的。报表上部的查询按钮是集算报表提供的“参数模板”功能，具体做法参见教程，这里不再赘述。

首先，要提前用集算器从数据库中读取2009年等各个年份的销售数据，计算好之后，以集算器的二进制编码导出到temp2009sales.b文件中，每年一个文件。中间数据制作好之后，数据库中2009年的数据就可以移除备份了，不再占用数据库的空间。

第二，编写集算器脚本salesProportion.dfx如下：

注意，脚本的参数是：argyear（要查询的年份），argmonth（要查询的月份）。

A1：连接预先配置好的数据源demo。

A2：从数据库中计算取出要查询的年份订单数、销售额。

A3：从前一年的数据文件中取出数据。

A4：将A3中的数据按照A2中的CLIENT字段对齐，A2中有A3中没有的补空行。

A5：利用A2来生成新的续表。其中增加了A4的对应行数据，比如A4(#).C:lastCOUNT就是A4的对应行（#是A2的当前行号）的字段C。

A6：关闭数据库连接。

A7：向报表返回结果集。

第三，在集算报表中定义报表参数（argyear、argmonth）和计算数据集：

上图中，参数名是指dfx定义的参数名称，参数值是指报表提交给集算引擎的值。这里是将报表的两个参数的值传递给集算器的同名参数。

第四，设计报表，如下图：

输入参数计算后，即可得到前面希望的报表。

不晓得大家有没有发现，过去企业搞IT都强调上系统、搞流程，而近几年，IT相关的新闻、会议，都围绕数据。

确实，现在任何一个稍具规模的公司，都在强调数据的重要性。无论是否与IT行业有关，数据都是其必不可少的组成部分，各种各样的数据均需要数据库来承载与维护（无论是大型的数据仓库，如DB，还是流行的Oracle、MySQL、Sybase等）。所以一个好的DBA的作用显得极为重要，不仅需要能够进行日常维护，对于数据库本身的优化（包括数据库系统架构优化与SQL优化）及数据库整体架构设计，也非常重要。小编身边不少IT朋友都将DBA作为近5年奋斗的职位。

但另一方面，随着近几年数据价值的凸显，很多企业的IT部门正通过数据给企业业务层面，经营层面提供有价值的数据信息。数据这块的工作就不单单是停留在数据治理和规划方面，更多需要从数据挖掘对经营对业务有帮助的价值。这也是为什么近几年很多IT人转行往数据分析师、BI分析师，甚至是高精尖的数据科学家发展。

所以，现在IT人要打交道的不仅仅是数据库，还有能将数据转换成经营决策信息的BI报表工具。

为什么需要BI报表工具？

在企业应用中，企业/组织/团体一旦成规模时，数据量是数以万计的，无论数据还是报表都需要协同管理不断更新。面对各大OAERPCRM系统的数据，这时候懂IT的朋友们可能知道，传统用Excel处理数据是hold不住的，即使写SQL也架不住扑面而来的需求。要想快速出报表，快速取数，快速做业务分析需要开放的报表或BI分析工具。FineReport就是其中之一。

FineReport 可以说是全球最好用的商用报表软件：

可以快速灵活地制作报表，搭建统一的数据决策和管理平台，让更多的数据用于业务经营和决策；可以快速开发报表，能做到和各类系统的无缝集成，加快项目的开发，节约了开发的人力和成本。

故事1：7天解决财务半年工作量

集团子公司有个财务总监，每个月都要给集团上报生产数据分析相关的报表，分产品的，汇总的，与去年同期对比，与预算数对比，单耗，能耗（如果这个不准可能影响销售单价），ERP本身只有最基本的业务数据，其他什么都没有。每个月都要加班两个多星期还不一定可以完成，真的是非常辛苦。后来找到我们信息部，沟通了她的需求，希望我们能用代码帮她自动出报表。但即使是代码，这些需求也要写上3天，每月还要重复写。如果其中逻辑稍有理解出错，就要修改。

后来经过一个多星期的沟通，最后在FineReport把这一套报表做出来了，现在她只用输入日期，就能看到当月的分析结果，点击品种就可以钻取单品种的详细结果，以至于到现在对我们IT部门都非常感谢，感觉IT人也得到了尊重。

故事2：二八数据分析，让公司反亏为赢

老K所在集团有一子公司，销售业绩和盈利能力一直都很差，2014年甚至亏损。但该子公司是集团战略的一个重要环节，那只能对这个公司进行业务改进，具体怎么做呢？

结合公司的实际管理情况，IT部门用FineReport搭建了数据决策系统，建立了数据仓库，为数据决策提供基础。财务主题分析、财务主题汇总分析、销售主题分析、销售绩效分析、存货主题、资金主题等模块。

然后，老K拉来子公司的财务数据，做了细致分析：分析哪些产品赚钱？哪些客户赚钱？哪些销售人员赚钱？还真有了大发现：49个产品中只有不到30个产品是赚钱的；给子公司带来利润的下游公司，只有不到20%；为公司创造较多利润的销售人员，也只有57%。于是，老K把这样的结论向上级领导反映，当即就从产品、客户、销售员这三个角度开展改革，砍掉了20%的低毛利产品；重点维护销售额前30%的客户；调整销售利润分配方式。

改革的效果：2016年销量增加1350万，销售费用率下降4.55%，2016年利润916万，比2015年增加457万，利润的增长来源于销量的增长，两年实现利润1,532万。

以上可见，报表/BI工具用得好，是可以给业务带来实实在在的价值的。

“FineReport+”三大技术优势

以FineReport为例，它的本质是一个通用的报表制作和数据可视化工具。就好比Excel，小到可以存储统计数据、制作各式各样的图表、dashboard，大到制作财务报表、开发进销存系统。

1、FineReport+业务系统，打破数据壁垒

一般业务系统自带的报表能力很弱，难以满足企业数据化分析和管理的需求。以OA系统为例，随着企业应用的发展，OA软件越来越重视数据分析与利用，不仅仅数据分析可以形成对信息与流程的管理，更实现对企业数据的有效管理与利用，所以报表应用已经越来越成为企业办公自动化软件（协同办公软件）的一个重要组成部分。但是OA自身报表存在多种先天缺陷：

a. 其数据全部来自于OA系统，而且报表也从属于OA的功能。比如，统计各部门收、发文的数量，统计员工的出勤日等等，无论是从格式还是统计的内容，都相对比较简单而且是固定的，无法从综合的角度体现各类数据的相关性分析。

b. 厂商或服务商在实施时为用户做的报表。用户可能会提出要求，实施服务商负责完成报表的开发。虽然这种方式能比较好地满足用户的需求，但灵活性还远远不够，不能针对后续业务的发展做到随需而动。

所以产品型软件公司在遇到有报表需求的客户时，常会选择和帆软合作，比如用友、金蝶、泛微、致远、万户、蓝凌、神州数码、浪潮，而和FineReport集成的业务系统产品，有OA、ERP、MIS、CRM、TMS、WMS、BPM、EHR、考勤等。

对最终用户而言，使用FineReport可以快速灵活地制作报表，可以搭建统一的数据决策和管理平台，让更多的数据用于业务经营和决策，让业务系统发挥更大的价值。

一般而言，FineReport 可解决如下问题：

市场环境和业务需求多变，无法快速满足变化的报表需求传统SQL+Excel 的方式整合数据做报表，效率低准确性差业务系统数据过于分散形成数据孤岛，难以有效利用缺乏统一的报表管理门户，无法形成全局数据视野，辅助决策

2、FineReport+BI系统，打造数据分析平台

报表和BI本来就界限不明，又如何搭配适用呢？举两个例子。

东北证券的数据平台建设完毕之后，结构化数据初步实现了统一归集，数据报表和图表可视化均可以通过Cognos工具实现。但是，由于Cognos使用繁琐、开发复杂，数据小组一直无法接手该工具，而新需求不断出现，亟需通过系统保存工作中产生的结构化数据，取代excel记录和上报数据的模式。所以，东北证券最后上了FineReport，较为完善的解决了当前数据填报和其他分析需求。

大华技术股份公司用Qlikview搭建了数据分析平台，但是当他们报表需求爆发时，QlikView根本解决不了问题。最后的解决方式是引入finereport，与QlikView并行使用。领导层几个人用QlikView，中间管理层都使用finereport制作的报表。FineReport是专门的报表软件，在易用性、快捷性和对复杂报表的响应要远胜于QlikView。

所以，FineReport+BI系统，赢在开发效率，赢在面向中层、面向固定式、面向复杂报表的定位。无论是传统BI如SAP BO、Cognos、 Oracle BIEE等，还是新型自助式BI如Tableau、FineBI、Qlikview、PowerBI等，都用可以FineReport“+”起来。

3、FineReport+场景需求，定制个性化的业务系统

信息化系统的本质是录入和展示，恰巧FineReport天然支持这两块功能，本身就是一个可视化的系统DIY工具。所以很多使用者直接应用FineReport开发了一些业务系统，如简易出入库系统、项目周报管理系统、酒店客房收入数据系统、考试分析系统、会员管理系统、刷卡考勤系统、报餐系统、微信小秘书等。

现在大屏数据展示的需求越来越多，一般应用于行业博览中心、实时监控中心、集团会议中心、战略指挥中心等场景，视觉效果要求也越来越高。无须专门定制开发，使用FineReport就能轻松制作出酷炫的管理驾驶舱，支持发布到多场景的数据大屏上进行可视化集中管控。

有位CIO说得好，以往IT在任何企业都是支持部门，永远跟在业务后面跑，数据让IT人有了可衡量的价值，是救命稻草。BI/报表工具是好的机器，帮助IT更高效的出报表，管理报表。从将更多的时间花在数据分析上，业务分析项目上，让IT人的价值真正凸显。

首先，我们先来说说数据库是什么？官方说法就是：按照数据结构来组织，存储和管理数据的仓库。数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。比如数据分析，数据整合等等。但是，数据库的使用成本太高，这就像每个人都是程序员一样，所以我在这里说的，是适合所有小白使用的数据库的应用软件。

Excel表格大家的熟悉程度可就非同一般了，我们几乎每天都在与Excel表格为伍，公司的财务报表，人力资源的信息，行政的考勤记录等等都是用Excel记录的，那么，在数据膨胀化的时代，Excel还能满足我们的需求吗？答案就可见一斑了~

首先，我觉得数据库的安全性要比Excel强很多，起码在我编辑到一半数据的时候，即使没有来得及保存，数据库的数据也是不会丢失的，他会永远存在于数据库里，已备我不时之需。但是这一点Excel是做不到的，我想大家都经历过数据录入一半的时候，电脑突然出现故障导致所有数据丢失的事件，当时的懊恼和无助，你可还记忆犹新？？

其次，数据库的数据是可以在线共享的，这种共享是多人可以同时操作一个表格并且数据之间是不会有所干扰的，在此基础上，和你共同协作的人也可以看见你创建的数据，当然这是在你允许的情况下。而Excel的分享只能是不断的通过媒介（比如微信，QQ，邮件）来不断的转发给需要的人，当然转发的同时它已经失去了时效性。而数据最可怕的就是失去时效性。

再有，数据库的数据分析能力远远超过Excel表格，不只是在于他的图表分析，而且有强大的BI功能做数据的大集合，你可以任意将你需要的表格里任意字段提取出来作为你聚合表里的一部分，你甚至可以将不是同一个表格里的数据做任何的运算，这不就是管理层梦寐以求的数据统计报表吗？你还需要在不同的表格里花费大量的时间一点一点计算那可怜的数据吗？

以后所有的数据都将平台化，这是数据时代的大趋势，看看你是在掌握数据还是数据掌握你，就只差一个数据库了~

人们常说“报表做得好，升职加薪少不了”。这就取决于，数据报告的两个重要作用：一是可指导性，是内核，让人看完报表之后恍然大悟“哦，原来问题出在这里”；二是美观性，是包装，让人看第一眼就赞叹“哇塞，这报告666”。

可是，为什么你加班加点做了那么多报表，却依然得到不老板的认可？

问题出在哪呢？

老板需要的是什么样的报表

现阶段，业务人员是如何来满足决策者的数据分析需求的？97%以上是通过Excel手工整理各种报表，不到3%利用了IT技术，实现了报表的自动化。随着决策者对分析的要求越来越高，于是报表越来越多、越来越复杂。在一个Excel页面中，密密麻麻布满了决策者关心的所有内容，只恨屏幕不够大。而这些大量的手工处理，很容易出错，且耗时久。

对上报上来的厚厚一叠报表，绝大多数决策者都会回答：有看，只是一般只看其中的一两张。没有时间，真的感觉有问题，还是直接找人来问了。

这就是问题的关键——我们给决策者提供了大量的报表，为什么帮助不大呢?因为信息一旦过多，就会变成“信息洪水”，大量的报表让决策者深陷“信息洪水”中。

员工再问决策者：希望用什么方式将信息给您呢？领导：希望有问题的时候随时能知道。

决策者这句话的核心有两点：一是有问题才让我知道，没问题的话，其实我也不需要关注。二就是我随时都可以知道。

报表能实现决策者的“希望”吗?答案是否定的。

（1）报表根本无法快速让决策者识别是不是有问题，它只是罗列了一堆数字而已。

（2）无论报表制作者多么厉害，领导想要什么就有什么，基本上也是不可能的。

那么能如何解决这个问题呢? 答案就变得简单了，就是用BI技术，改变决策者获取报表的方式。

报表工具与BI系统的区别

有人说：“我通过一个软件，能自动生成决策者想要的报表，然后再配上一些仪表盘和图表，不就可以了吗?也不见得需要BI。报表软件多简单，哪像BI要规划数据仓库，要ETL，还要建模型，多麻烦”。

以Excel报表和亿信BI来举例，对比一下报表软件与BI系统的区别：

Excel报表应用场景主要是业务报表制作，比如一些企业固定的月报，季报和关键数据指标的统计、展示和分析。主要功能分为三大类：数据展示(报表)、数据查询(参数)和数据录入(填报)，还有报表管理。数据展示报表可分为表格类和图表类。

而亿信华辰的拳头产品亿信BI有领导驾驶舱、图形化建模、自助式即席分析、智能钻取分析等多项功能。他可以构建大型的综合的数据分析平台，也可以作为小型的个性化的解决方案。相比报表，侧重点在于分析，优势在于操作简单、能够处理大量数据，可以实现任意维度、任意分析路径快速实时分析。

从工具角度上讲：

报表工具一般连接的是事务处理型数据库，不能实现多维分析的操作；当然，目前有些报表工具用链接传参的方式实现所谓的钻取，实现复杂，还会有性能的问题。

BI工具一般连接的是多维模型数据库，可以很容易实现各种多维分析的操作，如钻取、旋转和切片等；还能很容易地实现基于指标和维度的拖拽分析和自助分析。

以上两个工具也都可以连接对方的数据库，但发挥不了相应的功能；比如报表工具连接多维数据库后，多维分析操作、拖拽分析和自助分析还是实现不了。

从系统角度来讲：

报表系统一般接入在某个业务系统数据库上，为MIS系统提供灵活的报表查询实现。当然，报表系统在数据量小时也可以连接若干业务系统数据库，实现跨库的关联查询，但这个查询是由报表工具来实现的，实现起来的复杂度和性能依赖于报表工具的能力

BI系统主要包括数据仓库/数据集市、ETL、数据分析、BI应用等多个组成部分和实施过程，最终BI应用中除了有报表展现外，还有多维分析、自助分析、数据挖掘等功能。

从工程化角度来讲：

报表工程相对比较简单，投资可以比较小，实施周期相对较短，见效比较快。

BI工程相对比较复杂，投资比较大，实施周期相对比较长，见效相对较慢，但效果比较好，尤其是在数据整合的数据质量、报表口径统一化、应用性能上有很大的优势。

从发展过程看，一般先是上了报表系统，发现报表系统的若干问题后，再上BI系统。

BI为什么能替代报表

很多企业一直有个误区：认为做了一个报表系统就是用上了BI，其实不竟如此，报表只是BI的一部分。虽然BI应用的结果通常需要报表来展示，但是，BI不仅仅是报表。

报表是数据展示工具，商务智能BI是数据分析工具。商务智能的重点在于商业数据的分析，集成了数据统计、数据展示、数据分析和挖掘的解决方案。

从下图中，可以看到，大数据管理与应用技术发展过程中，数据管理已从报表阶段进化到BI阶段。BI是一个辅助决策的智能系统，它的核心就是帮助企业利用好数据，让决策管理者随时随地获取关键信息，让决策者基于数字决策，最终提高决策水平。

通过报表工具与 BI系统的区别，以及各自的特点，可以得出BI替代报表是趋势，同时也是发展的机遇。抓住机遇、争得先机应是摆在决策者面前的课题。

最后小亿谈点关于BI的价值思考：

BI不是让你相信自己所知道的，而是促使你去思考更多的问题和疑惑。BI迫使我们怀疑得出的结论、回到初步阶段、重新设定假定和条件。它促使我们思考，而不是给出事实。BI可以让你从不同视角查询一系列相关数据，以便在一组不确定的条件下更进一步接近事实。你需要BI工具帮助做出最佳决策，而不是正确决策。BI让决策不再止步于结果。