一个老鸟的BI之路——转自他人的报表工具java报表软件以及bi的经验分享

闲来无事看到一篇帖子，颇有感触，特此转发一下！

原文链接：https://blog.csdn.net/qq_36128242/article/details/83746582 

这人一上年纪就爱回忆之前的事情，转眼间参加工作已经十几年，今天闲来无事写写这些年和BI的那些事，经验分享谈不上，只要能让看到这篇文章的人少走点弯路、在BI的道路上少受点伤，那总是有点用处的。

    大学时学的计算机科学与技术，06年毕业后进入了帝都的一个非知名软件公司，正好赶上做一个“BI”项目，问领导啥是“BI”？领导劈了啪啦说了一通，没听懂，好吧，内事不决问百度，外事不决问google，查了下说的也是云里雾里，不过大体上可以知道BI主要分几方面：

1：报表

2：多维分析

3：ETL

4：数据仓库

    用户更关心的是前端数据展现，所以貌似报表和多维分析相对重要一些，主要是直观。之后了解了下要做的项目，主要是关于报表，项目组的人也都没接触过，当时技术大拿想要自己写代码实现，不过领导考虑到工期和需求复杂度，决定还是先找成熟的工具看看，06年国内的信息化建设相对还是比较滞后，尤其是各种工具软件，搜了下国外的工具主要是“水晶报表”（当时的NO.1，现在很少能听到了），国内的有几家，不过让人印象深刻的是国内有个润乾报表在网上和水晶各种PK，提出特有的模型解决复杂报表他们称自己发明的这个叫非线性报表模型），产品选型是痛苦的，大家都不懂，不过甲方的优势就是反正我掏钱，你们都得听我的，把几家公司叫过来现场PK，找了几个比较典型报表分别让几家公司的人制作，具体细节记不太清了，貌似是有张特“变态”的表，水晶直接没法做，国内几家工具弄来弄去，最后选择的润乾报表，那就它吧。

      工具定了，接下来就是培训，做表，不会做了就骚扰下客服，疑难的有公司大拿去搞定，除了不定时加会班以外总体来说比较顺利，最后上线，happy…….。

简单总结下:06年选择的报表工具是国内的一个不是太知名的公司而没有选择当时名气很大的水晶，后来想了下还是国内外需求的不同，老外想事情比较简单，他们只要能够快速的看到数就行，也就是表样简单，要求的是一个快，而国内不同，国内要的是一个全，恨不得一张报表把他所有想看的都展示全，所以优先国外工具很难达到，实际上05、06也是一个重要的分水岭，之后在报表工具上主要是国产软件的天下了。

      之后又陆陆续续做了几个项目，大多数还是和报表相关，个人也在从开始的小菜鸟变成了手下有那么几个人的小头头，心态也有了些变化，用现在的话说就是有点“膨胀”，又接了一个项目，做为负责人来说总是想表现下自己，之前都是用的工具软件，并且收费不算低，自己去做或者找些开源工具不就能剩下工具钱，为公司节省成本了么，所以这个项目上没有购买工具，用的开源的“IReport”，开始做的也挺快，都是技术出身，看看文档、接口说明基本都能做，结果遇到了一个貌似挺简单的需求，IReport不支持，提交修改人家是开源的也没人管，自己去搞也搞不定，当时就懵了，最后加工期、让用户改需求，弄的很是不愉快，最后总算在各种煎熬中完成了项目，最后成本一核算，貌似是省了工具陈本，结果开发周期长了，人工成本直接就上来了，没省下成本不说，弄的用户体验也很差。

总结：一个项目的成本可以简单划分为：工具成本+人工成本，也许省了工具成本，但是在帝都来说，高昂的人工成本打开时制约整个项目的核心要素，而作为一个项目负责人更应该评估整个项目，做出合理选择。最后领导一句话现在还记忆犹新：“专业的事情还是让专业的人去做”。

       之前关于的BI主要是关于报表方面，后来随着业务人员能力的提升，在一些大型项目上，通常会要求业务人员自己在页面端去做分析，也就是BI中的“多维分析”，国内多款软件也号称自己能够实现，也看了之前比较熟悉的润乾，发现分析这是一个短板，操作方式、展现形式上很难达到用户需求，所以基本形式就是：国内的报表软件+国外的分析工具，固定的报表由开发人员设计，分析工具采用国外的软件（当时用的多的是congos和BO），小项目就报表工具+自己写页面,自己写页面有一个难点，虽说前台页面更符合客户操作习惯，但是在底层数据建模上难度较大，很难高效的将分散的数据整合在一起，每个项目都需要单独开发，代码复用率太低，所以应对中小项目最合理的方式是有一个工具能满足一下两点：

一：建模足够强大，能灵活的将分散数据高效的关联在一起，大概占整个工具的70%左右的功能，是整个工具的重中之重。

二：不同项目的业务人员对前端操作方式要求不同，所以最好能够前端开源，提供各种接口供开发人员进行调用，灵活的定制满足于各行各业的前端需求，也方便与页面和自己项目的整合。

最近又考察了下多款工具软件，发现润乾挺符合这种需求，当然其他工具也都有相应的解决方案，只是不同人的理解不同，见仁见智。

       一个系统人们最关心的就是稳定性了，通常来说数据量的大小直接决定了系统能否平稳运行，之前见到最常见的问题就是“内存溢出”，在32位时代，本身并不大的JVM要分配给web服务器+应用，留给系统运行的也就1G，数据量一大直接就down了，对于单次取大数据量集群也无能为力，基本方法就是通过ETL工具先对数据进行加工处理，上数据仓库，或者就是各种存储过程生成中间表，结果导致一个数据库中有大量临时表的存在，而且不同项目组共用一个数据库，都是各自为战，之前有个项目的终端用户想要优化数据库结构，找了几家集成商碰了下头，看了下数据库，几百张临时表，谁也不知道哪个是干什么的，在国内，能够按照需求文档去设计数据库结构的并且更改数据库结构后再去完善需求文档、编写说明的那更寥寥无几，最后不了了之了。所以数据结构的说明文档尤为重要，如后续要更改或者加临时表等一定要留下相应文档做说明。

      之前常见的数据库类型是oracle、sqlserver、mysql等，都是基于标准的sql，只要能熟悉一种数据库，其余类型操作基本都类似，只不过是具体函数和个别语法进行更改即可，但在2013年左右互联网+概念的提出，原先一直雄霸数据库市场的oracle现在感觉有点力不从心，hadoop、mongodb等分布式数据库应用逐步广泛，这就给BI市场或者各项目组带来了新的机遇和挑战，说机遇是这些数据库从机制上对大数据提供了更好的支持，同样由于是新提出的技术，如何能高效、灵活、方便的处理这些数据变的尤为重要，因为均是nosql，熟悉某种数据库并不代表对另一个数据库玩也的转，这就需要项目开发人员或者各工具厂商为此做出更多的工作，能够同时支持各种各样的数据库类型，降低项目开发中的学习成本。

总结：在BI中，报表做为直接呈献给终端用户的工具看似非常重要，但是经过多年的发展，报表需求并未发生根本的变化，前段看了一个项目的需求，发现报表和几年前的需求没什么变化，无非是样式上更加丰富、组合更加多些，用几年前的技术完全能够实现，在考察时发现润乾居然将报表定价为5000元一套，还不如一个三线城市普通程序员的月工资，可见现在软件成本门槛之低。未来会更加侧重对数据的处理上，如何快捷的从多样的数据库中取数、如何快速的从大量的数据中读取数据、如何高效的计算各类复杂的数据、更或者是否能够有自己的机制去存储大数据替换原有数据库、是否能提供一整套解决方案解决各类BI需求，做为一个从事BI行业多年的“老鸟”，吾将继续为之奋斗，希望国内各工具厂商继续努力，为推动国家的信息化进程贡献自己的力量。

注：本文中提到多次提到工具“润乾”，是否该工具最好，其他工具不行？并不是，只是个人用起来比较顺手，多年来一直能够满足项目的需求，“适合的永远是最好的，专业的事情交给专业的去做”。
---------------------