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

简介: 注:本文图片所演示的数据均为随机数产生。   不求华丽的开篇语,只求平平淡淡认认真真如同流水般的记录一点东西。

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

20103月初,自己从原深度运营和项目组脱离出来,进入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展现工具对比表格,因本人参加工作时间有限,难免存在个人理解偏见,如发现不对,请多多包涵与指教。

 

          

功能

二级功能

BIEE

BRIO

AnalyseReport

对操作系统的支持

UNIX

Linux

Windows

对关系数据库的支持

Oracle

Sybase

SQL Server

Informix

×

×

DB2

Access

×

×

×

BI部署的复杂度

高中低

中间件的支持

IIS

×

 

×

Tomcat

JBOSS

WebSphere

BEA

B/S架构支持

 

B/S支持方式

HTML

×

ASP/JSP页面

×

×

×

控件/插件方式

×

×

B/S浏览器

Firefox

×

×

Explorer

多语言支持

Chinese

English

数据导出格式

Excel

Word

×

×

可实现

Text

×

×

可实现

HTML

×

可实现

PDF

通过打印导出PDF

×

分析结果发布方式

WEB

E-mail

×

×

可实现

File

×

×

Fax/Mobile

×

×

可实现

打印功能

是否可进行调整

×

×

打印是否美观

×

×

权限/安全管理

是否支持用户权限管理

√允许二次开发

分析主题权限管理

√允许二次开发

字段权限管理

×

×

×

维度权限管理

×

×

×

是否支持SSL

×

是否支持LDAP协议

×

×

×

文档丰富程度

丰富的联机帮助文档

×

用户操作指南

二次开发手册

×

错误指南

×

×

×

报表开发/操作便易性

是否支持可视化拖曳

×

是否提供丰富自备函数

×

×

是否支持二次开发功能

×

×

是否提供二次开发接口

×

×

是否支持自定义SQL

半支持

半支持

易学程度

中等

容易

美观程度

美观

中等,不可扩充或自定义

较好,可自定义

告警功能

自定义等级

×

自定义颜色

×

自定义告警指标

×

告警发布方式

×

×

×

定时任务

是否支持定时任务报表

×

×

是否支持查询条件动态设置

//////时报表的定制

×

定时任务报表的分发功能

×

×

基本报表功能

自定义维度成员

自定义指标

多表头支撑

表头冻结

通过第3JS实现

钻取功能

  • 上钻下钻
  • 任意钻取
  • 预定义钻取路径

旋转功能

×

×

×

切片切块

数据过滤功能

×

×

数据列排序功能

可以静态排序,不支持动态排序

×

基本图形功能

  • 多坐标轴支持
  • 饼图
    堆叠
  • 三维
  • 折线
    散点

    雷达
  • 仪表盘
  • 组合图形
    其他

基本统计分析功能

80/20分析

×

×

绝对值分布分析

×

现状分析方法

  • 比重分析
  • 排序分析
  • 平衡性分析
  • 方差分析
  • 80/20区间分析
  • 进度分析
  • 强度分析
  • 异常值分析

×

×

×

发展分析方法

  • 基比分析
  • 环比分析
  • 增长率分析
  • 同期比分析

×

扩展功能

数据挖掘扩展

  • 决策树
  • 神经网络
  • 时间序列趋势预测模型
  • 多元回归线性/非线性预测模型

×

×

只有线性回归

数据抽取扩展

×

×

×

建模工具

×

×

单独的报表工具

×

元数据管理工具

×

×

嵌入其他管理软件

×

×

×

负载平衡功能

×

多机冗余和故障点恢复功能

×

×

×

对中国式报表的支持度

一般

一般

重点功能

部署方式灵活性

灵活

灵活

灵活

复杂报表制作难易程度

中等

容易

最终客户掌握使用报表工具的难易程度

常规处理容易,特殊处理较难

常规处理容易,特殊处理较难

通过xml文件配置报表

具有丰富的分析功能,如最优/最差分析、例外分析、排名分析、比较分析

×

×

×

提供报表调度功能,即在非高峰时间调度报表,生成报表结果

×

允许用户设置一定的预警条件,即当报表中某一项满足一定条件时,以特定的格式(包括特殊字体、特殊符号或图片)显示此项

×

提供用户订阅报表的能力,即允许用户通过一定的时间频度订阅报表,将报表执行结果发送到相应位置

×

×

×

提供数据缓存机制,使重复进行的查询操作无需频繁直接查询数据库,从而减少网络传输,全面提高即席查询性能

提供资源控制机制。系统管理员能够监控查询的运行进程,并停止长时间运行的查询,控制资源使用效率

×

×

用户设立不同的查询优先级,实现数据仓库资源的合理分配用户设立不同的查询优先级,实现数据仓库资源的合理分配

×

×

商务因素

价格高低

用户授权许可

产品,服务另外付费

产品,服务另外付费

产品

技术支持服务的完善

完善

完善

对硬件设备的要求

中等

 

 

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

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

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

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

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

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

 

 

 

 

 

 

三、可定制中国特色表头

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

 

 

 

 

四、复杂表头的动态排序

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

 

 

 

 

五、冻结复杂表头

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

 

 

 

 

六、多样化的表合计

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

 

 

 

 

七、查询性能优越

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

 

八、可定义表格单元

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

 

 

 

 

九、丰富的图形功能

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

 

 

 

 

11、丰富的二次开发接口

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

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

目录
相关文章
|
7月前
|
数据采集 SQL 数据可视化
大数据可视化技巧:借助PowerBI提升数据故事讲述力
【4月更文挑战第8天】Power BI助力大数据可视化,支持多种数据源连接,如SQL Server、Excel,提供数据清洗与转换功能。通过选择合适图表类型、运用颜色和大小强化表达,创建交互式仪表板。讲述数据故事时,注重故事主线设计,利用叙事技巧引导观众,并添加文本说明。分享已完成报告,提升数据驱动决策能力。动手实践,体验Power BI的强大与易用。
186 0
|
4月前
|
存储 机器学习/深度学习 数据管理
震惊!Delta Lake 以非凡之力掌控表的多个版本,开启数据管理奇幻之旅
【8月更文挑战第27天】Delta Lake作为大数据领域的一种高效数据湖存储层,其版本管理功能确保了数据的可靠性与可追溯性。通过记录所有表更改的事务日志,在系统故障或误操作情况下可恢复至特定版本。不同版本的数据独立存储并标记唯一标识符,便于管理和对比。此外,Delta Lake还采用了诸如自动合并小文件、支持索引和分区等策略来优化查询性能。这些特性共同使得Delta Lake成为一种强大且灵活的数据版本管理工具,在数据仓库、机器学习等多种场景下展现出巨大价值。
37 0
|
关系型数据库 MySQL Java
阿里一线专家多年架构优化经验凝聚,手撸595页MySQL笔记
有史以来“最全”SpringBoot实战派,让开发像搭积木一样简单
|
消息中间件 分布式计算 Kubernetes
爆款阿里P5到P7晋升之路,九大源码文档助我超神果然努力幸运并存
前言 相信有许多的程序员,工作了这么多年;但是依然不知道自己掌握的技术栈+项目,究竟达到了阿里的什么职级,还有薪资水平是什么样的;
|
人工智能 前端开发 数据可视化
High&NewTech:来到了21世纪的第3个十年,各行业数字化迫在眉睫,全民编程也势不可挡。但,问题来了,编程,一定需要写代码么?那么,传说中的iVX工具,与编程到底又有什么暧昧关系?
High&NewTech:来到了21世纪的第3个十年,各行业数字化迫在眉睫,全民编程也势不可挡。但,问题来了,编程,一定需要写代码么?那么,传说中的iVX工具,与编程到底又有什么暧昧关系?
High&NewTech:来到了21世纪的第3个十年,各行业数字化迫在眉睫,全民编程也势不可挡。但,问题来了,编程,一定需要写代码么?那么,传说中的iVX工具,与编程到底又有什么暧昧关系?
|
SQL Python
热饭的测开成果盘点第四期:sql共享平台
本期介绍的是一个django平台,它是我在18年时做的一个sql共享平台,整个最大的亮点我觉得就是的优美风格的尝试。
热饭的测开成果盘点第四期:sql共享平台
|
测试技术 API Python
热饭的测开成果盘点第六期:在线编辑脚本平台
本期介绍的是一个django平台,它是我在18年的第一次大胆尝试在线维护脚本组装脚本。
热饭的测开成果盘点第六期:在线编辑脚本平台
|
SQL Shell API
热饭的测开成果盘点第二十四期:diy数据构造平台
不多bb,直接上图。 该平台可让同事自行去设计 数据构造功能。包括sql/api/shell等等。 由我带着心鹏君开发完成。设计巧妙,可爱。 自行设计页面输入,描述等。
热饭的测开成果盘点第二十四期:diy数据构造平台
|
运维 监控 数据可视化
一文详解网易数帆数据生产力方法论
2021 年,网易数帆大数据团队正式提出数据生产力的理念,数据生产力从广义上讲,是指“通过使用数据,带来组织生产力的提升”;从狭义上讲,是指“数据采集、清洗、加工、可视化等数据处理和数据治理的软件生产能力以及持续运营能力”。
280 0
一文详解网易数帆数据生产力方法论