AnalyseReport--从实践中走出的报表工具

注：本文图片所演示的数据均为随机数产生。

不求华丽的开篇语，只求平平淡淡认认真真如同流水般的记录一点东西。毕业到现在工作5年，一直都是在商业智能平台分析项目(以下简称BI)。因此多多少少对这类项目有些积累，从后台sql干到前台web,从开发干到设计，各类相关职位都有或多或少的涉及。不说是全能型种子选手，但各个环节基本还是略知一二。

在中国商业智能行业是个典型的长尾领域。因为这和中国企业相关。企业大了，业务就复杂了，层级就多了，产业链就长了。为了让这么多人这么多业务都能按照规则运转，还能加速运转，非得IT工具来帮助才可以。因此才有BI的诞生。中国的BI起步虽然比国外要晚上几十年，照理应该可以照搬国外成功的应用经验或产品，可中国方圆960万平方公里，行业成千上万，民族风俗各异，信息化建设参差不齐，国外的产品拿来往往都会不适应或直接无法实施。这就是我所说的长尾现象。

因此国内才会涌现出大量系统实施集成商，把各种BI所需环节功能或产品为企业量身定制或集成，帮助企业建设高效IT化数据中心与数据分析。

目前国内的BI实施水平绝大多数还是在数据处理、建模、展现这些步骤之上，能做到深入挖掘再分析、预测的并不多，能做到分析预测的基本都是应用的亮点优点了。往往应用最多的就是报表展现了，当然一个好的报表展现也是能为企业业务分析人员提供莫大帮助的，能让概念、理论数据化，形象化。

在我加入拓维之前，BI产品线已经有相应的报表项目组有着自己的报表展现工具(以下简称IMC报表)，IMC报表有着它自己独特的数据建模理念，有基于SVG的图形展现方式(首先我的说即使5年后的今天，在我印象中 IMC的 图形展现是相当不错的。)在我从事4年之久的深度运营项目组从立项之初就选定IMC报表工具作为首选系统报表工具,以Brio报表为辅进行OLAP相关分析。起初IMC与Brio表现的还不错，但随着业务的变化及报表的数量不断增加，IMC与Brio的问题也就暴露的日益明显。因IMC与Brio后台数据建模的独特性以及本身的架构方面的原因，在添加新的功能时改动成本极其高、复杂、不灵活。性能方面也变的差强人意。这里面还发生了一个小故事，我想如果不是这个小故事，我想我也不会自己开发一套报表工具，也就更不会有本文的存在了。

09年初，做了2年后台，写了2年sql的我，被安排做前台开发兼职需求确认与设计，原因是原来的前台java开发人员离职暂时找不到合适人选(天啊~虽然毕业的时候被人称作.net小王子，但java确实用的少，没办法硬着头皮上吧)。当时整个系统报表性能问题已经很突出了(通常情况打开一张报表最快也要40秒左右，这个已经多次向组织反映过，虽有改进，但效果都不理想)，客户也曾多次反映过。一次客户约我去办公室谈需求，刚好要打开一张报表演示。于是让我至今记忆犹新的一幕发生了。客户点击报表菜单后，说了一句”报表真是慢的死，你在这看着，我先去打杯水，然后抽根烟，打开了你就叫我进来啊！”。客户这句话虽然说的不痛不痒。但明显感觉的出是充满不满情绪的。在客户转身出去的1分钟后时间仿佛凝结，我内心不断纠结着，还有一种耻辱感。虽然我可以安慰自己这”破”玩意不是自己弄的。但是我强烈的责任心和职业道德告诉自己如果这次要是再搞不定报表性能问题，我就自己做一个简单的小报表工具。或许这就是知耻而后勇吧。

前文曾提到还有一个选择那就是采用Brio这款报表工具，Brio,在来拓维之前，在西藏经分项目组我大概做了快半年的Brio报表开发工作。理论上如果采用它应该也算是轻车熟路了。但是首先我就否决了它。原因有以下几点:

1)     界面可定制化不高,不能二次扩充界面组件。

2)     数据机制不完善，Brio采用类似文件数据库概念的缓存机制，需要配合定时调度才能正确的刷入展现数据。

3)     开发方式繁琐，每一个报表采用独立bqy文件，如果将来要增加某一个功能或修改某一个bug，那么有1000张报表就要修改1000个bqy文件。

4)     只适合汇总形式报表的开发。

5)     采用ActiveX组件，报表加载缓慢，对大型报表或大数据量报表的时候，容易卡死浏览器或浏览器白屏一段时间。

其实我最担心的还是第三点，修改某个功能点的时候，每一个文件都要修改到。否则容易造成同一个功能可能在A报表是好的，B报表就是坏的。原因可能是一个代码错误什么的。这样的结果就是加班+加班+加班。而且可能还要拖着做测试的兄弟一起来”断背”加班~.

在”山穷水尽”之处，终于决定自己开发一套包容现有系统报表功能，并能不断扩充功能的新报表工具(AnalyseReport,以下简称自定义报表工具为AnalyseReport)，既然决定要做那么当然不能盲目推翻现有的功能，能借鉴的还是要尽量借鉴，于是通过组织关系找到了资深移动电信行业业务专家老哥(谭志勤)，一同参与设计。老哥(谭志勤)当时提出了一个很好也是一直延续至今的想法，通过勾选维度的方式实现“钻取”的功能，替代当时各大BI工具主推用点击字段的方式。另外还找到原IMC报表开发的设计组长阿董(董湘衡) (当初AnalyseReport原型也就是我们两人开发，开发周期也不过是10天左右)，至今AnalyseReport中仍然能见到阿董飘逸的代码风格 ，呵呵 。

设计之初我对AnalyseReport框架提出的一个概念就是”约定化、配置化”、”约定高于配置”。其实这2种概念在开源界早已存在，典范比如Ruby、groovy  grails 框架等。将AnalyseReport中的任何元素组件化，然后通过XML形式的报表配置文件将不同的报表组件、元素、sql组合成一张报表并展现出来。这样做的好处是组件能最大化的重用，并且能生成以XML为基础的中间元数据，可以为以后的可视化设计器以及元数据分析工具提供支撑依据。对于报表配置人员来说他只要知道配置规则即可，不用管具体如何实现，那么这个配置人员就可以定性为是懂得XML语法的后台开发人员，而不是专业的前台web开发人员。要知道在业务把握上需求人员最准确，其次就是后台开发人员了。

就这样AnalyseReport的第一版就如期的完成了，这一版本在湖南数据业务深度运营项目首先得到实施机会。37张数据业务综合报表首先成为了”实验品”，反馈结果出人意料的好。其实这也是站在”巨人”的肩膀上才取的荣誉，我们所做的一些细节上的工作让客户感到满意，如勾选钻取维度，默认财务数字格式化等，通过积极主动与客户反馈交流，不断的添加新的功能和修正已知BUG。最终得到客户的认可，还有客户发来界面评审评测结果。

在那之后越来越多的专题中应用到AnalyseReport。到如今AnalyseReport部署到数据业务深度运营项目组已经15个月了。配置了近400张报表。性能仍然保持能在5秒内打开任何一张报表。

2010年3月初，自己从原深度运营和项目组脱离出来，进入AP 研发部门，在这我要感谢成总 (成驱虎)给了我一个绝好的沉淀机会。人生总是朝着一个认定终点不断追赶着，时间长了，久了就会疲惫。如果有机会能休息并回顾走过来的路，那么才会看清楚自己离当初定下的目标还有多远，才能重新规划与制定新的目标，找到前进的方向与动力。正是加入AP研发部门才让我有时间有精力对AnalyseReport去反思、去沉淀、去思考。3月至4月研发第二版AnalyseReport这段时间里，在保持对原有XML定义不变的基础上新扩充和重构了近三分之二的代码。着实添加了不少实用的新功能。并引入JAVA动态语言Groovy，起初引入Groovy的时候确实担心过风险的问题，目的是为了给以后组件脚本化提供支撑基础，为此我还专门和Groovy社区交流过.(好吧，我承认我的英文很蹩脚，但是借助Google大神还是可以交流的)。有社区朋友提议我是否能共享代码或者将运用项目作为成功项目放到Groovy官方网站的成功案例中。这些我都委婉谢绝了。

在湖南全网手机支付项目中，原本使用的报表工具是Oracle BIEE。其实这是在国外报表界很有名气的后起之秀。但是在全网这个项目中也暴露出不少问题。比如:

1)     对中国式报表表头支撑不是很好，超过3级表头后容易引起BIEE服务器岩机或者死掉。

2)     整个报表框架采用类似JSF的事件交互模式，对服务器要求很高。当交互很多的时候性能表现一般。

3)     报表功能实现规范化，但缺乏二次开发接口，对于一些个性特色的功能实现，较困难 。

4)     报表字段排序，目前仅支持设计期间静态排序，不支持客户自定义字段动态排序。

5)     无原生冻结表头的功能，查看大型报表稍有不方便。

而刚好这些功能点在AnalyseReport的新版本中均能得到支持。于是在手机支付项目经理郭步升的帮助下，向手机支付客户推荐试用了AnalyseReport。之后手机支付也便开始采用AnalyseReport作为报表展现的解决方案之一。

前面说了这么多关于AnalyseReport，那么AnalyseReport作为报表工具又有什么特点呢？我简单的整理了一张主流BI展现工具对比表格,因本人参加工作时间有限，难免存在个人理解偏见，如发现不对，请多多包涵与指教。

表格的描述视角从BI项目的选型去描述。相信能真正认真把表格内容看完的人并不多，(你就直接承认你用鼠标中键滚了几下吧~嘿嘿)。如果用通俗具体的举例方式来说AnalyseReport可能更能让人明白优点在什么地方。

那么现在开始介绍一下优点方面：

一、基于XML+脚本的方式配置报表

摆脱传统的web开发模式，以XML+脚本形成中间元数据规则层，让前后台人员分工更加明确，只要稍加针对XML的培训后台人员也能很方便的配置出报表。

二、汇总报表与分页报表的随意转换

只需要通过设置一个属性，即可实现报表在汇总报表与分页报表的互换。

三、可定制中国特色表头

自定义报表工具支持中国特色多级表头，在处理多级表头的时候快速稳定。没有国外报表工具在处理的时候容易死机、岩机等问题。

四、复杂表头的动态排序

自定义报表工具可以在运行期间客户指定排序字段。并支持复杂表头的排序

五、冻结复杂表头

如同excel的冻结表头功能，自定义报表工具可以实现汇总报表、分页报表、多级表头多维度的冻结功能。

六、多样化的表合计

自定义报表允许设置或定义多样化的表合计项

七、查询性能优越

自定义报表工具设计之初就是以 BI分析为主，考虑了BI应用的复杂性、海量数据等因素。实现了自有的缓存机制，在查询数据的时候充分利用缓存提高性能。

八、可定义表格单元

对于表格单元格可以使用常规的数值，可以默认支持财务格式化，还可根据要求设定图形或链接或友好的TIP提示等等。

九、丰富的图形功能

包含常用的图标分析类型如饼图、柱状图、折线图、预测折线图、平均线柱状图等

11、丰富的二次开发接口

AnalyseReport提供了大量二次开发接口，比如web控件、标题、用户权限、日志管理、皮肤、表单元格等等一系列二次开发接口，部分二次开发接口允许使用Groovy脚本语言开发。

回头才发现自己居然写了这么多~汗！前面洋洋洒洒的介绍了AnalyseReport的一些特性，要想真正把它用好，把它变的好用，还有很多工作需要做，心里明白只有朝着产品化的方向继续前行，才能让AnalyseReport不断进步与完善。