解决报表制作的最后障碍-数据源的计算.docxVIP

解决制作报表的最后障碍：数据源的计算报表工具发展至今已经相当成熟，比如近几年崛起的Qlikview，tableau，Spotfire，或者老牌的SAP Visual Intelligence，jasper report，Cognos。但在报表的制作过程中，仍然有一个关键环节未被完全攻破，那就是数据源的计算。数据源计算的目的在于为报表计算出方便可用的结果集。传统的方法是用SQL/SP来进行数据源的计算。但SQL/SP的设计、调试和移植难度都较大，也无法解决不同种类数据源之间的计算、非数据库的计算，更无法解决JasperReport等工具的单数据源限制。要攻破这最后的障碍，我们还需要其他技术手段，典型的有：数据仓库、数据源计算层、语义层、table拼接、API编程。这些方式各有优缺点，下面是我的一点看法。数据库仓库。这是用ETL建立一致的数据视图的一种方式，相关的工具相当成熟，比如Teradata fastload，DB2 data warehouse, Oracle Warehouse Builder。它的好处很多：解决跨库的计算、进行非数据库的计算、积累历史数据，提供较高的性能，降低业务数据库的压力。它的缺点主要是成本高，这种高成本更多的是体现在建立和维护上，而不是产品购买上。数据仓库需要精通技术和业务的双料专家，他们既要精通Perl/VB Script/JAVA/SQL/SP又要熟知业务逻辑。数据仓库还需要进行复杂的数据拆分整合，进行范式设计，设计增量更新算法，需要设计多层的任务调度优先级。为了实现高效和可用的数据仓库，往往还需要不止一次的ETL过程。不可控的成本导致数据仓库的失败率往往很高。语义层。在数据仓库普遍令人失望之后出现了语义层，它用业务术语重新定义了难懂的物理数据模型，让数据库/txt/excel/xml不再严格区分，让报表设计人员能以更友好的方式操控数据。SAP Universes,Qlikview是其中较有特色的。语义层和数据仓库的目标都是建立易于使用的数据源，因此优势基本相同。但建立语义层的环节更少，相对来说更加敏捷，因此所需要的资源和时间也更少，它的建立、维护成本介于数据仓库和数据源计算层之间。语义层的缺陷是计算功能不完整。它一般以wizard为主，辅以简单的数据源合并和计算列功能，但缺乏专业的结构化数据计算脚本，因此用语义层独立进行的数据源计算非常勉强，经常需要数据仓库/ETL作为辅助。全内存计算带来的性能问题也是它的弱点。另外语义层是绑定报表工具的，移植性较差。数据源计算层。这是近几年出现的新方法，试图用通用的方式从根本上解决报表数据源的问题。它们一般都提供了专门针对结构化数据的计算脚本，可以同时读取多种数据库以及非数据库的数据，并可以进行异种数据源之间的相互运算。它们有专业的开发和调试工具，可以降低复杂计算的难度，使得开发效率比SQL/SP更高。另外，与数据库类型和报表无关的特性使他们拥有更好的移植性。集算器和R属于典型的数据源计算层。其中集算器的计算结果是JDBC，报表可以直接调用，但它不支持相关性分析等模型。R与之正好相反，报表难以调用，但支持多种固定分析模型。这种方式一般采用全内存计算，因此单机性能要弱于数据仓库。但它们都支持大数据计算模型（比如hadoop），因此在分布式计算上表现更优秀。Table拼接。这本来是语义层的功能之一，但很多报表工具将它独立出来，作为解决报表多数据源的简化方式，比如jasperReport和Birt。它们只支持单个数据集，如果需要将Oracle和MSSQL中的数据同时展现在一张报表中，就可以使用Table拼接功能。相比其他方法，Table拼接的最大优势是工作量最小，人力成本最低，但功能限制也最多，比如只能进行最简单的拼接，无法进行一般的数据源计算；对非数据库的数据源支持不足；绑定报表工具和数据库，无法移植；全内存计算，性能低。API编程。这是指用报表工具提供的API，以编程的方式计算数据源，并最终返回结果集的方法。绝大部分报表工具都提供了这种方式，比如SAP的CDS框架和Jasper的Bean data source。这种方式拥有最大的灵活性，理论上可以解决任意的数据源计算问题。当然开发的复杂性和难度也是所有方法中最高的。为了访问非数据库的数据源，这种方式普遍采用JAVA等高级语言。这些语言不是SQL/集算器/R这类专业的数据计算语言，因此简单的算法就需要写大篇的代码，复杂的算法更是因为工作量的原因难以实现。事实上，这种方式更多的是作为语义层/table拼接的辅助方法而存在。以上5种方法各有自己适用的场景。Table拼接适合数据库间的简单拼接；API编程适合非数据库的简单计算；数据源计算层适合对移植性要求高，或复杂数据环境中的计算；数据仓库适合对性能要求高的局域网