Raqsoft

概述很多时候用户不仅需要操作本地的报表模板，还要操作远程服务器上的报表模板，比如修改远程服务器的报表或者将本地模板上传至远程服务器等。为了满足这种需求，润乾报表提供了远程服务接口。远程服务器相当于客户端与服务器之间的一个中间层，通过与服务器建立连接，可实现对不同用户权限的控制、查看和保存服务器上的文件、上传新文件到服务器等。远程服务菜单是通过用户自定义类，实现润乾报表提供的 com.raqsoft.ide.custom.Server 接口添加的。接口说明可参考自定义远程服务小节。菜单介绍

在《润乾报表多维分析功能漫游》一文中我们已经见识了润乾报表分析控件的妙处：可视化的拖拽模式，灵活的计算方式，脱离敲打复杂多变的查询语句，只需要动动鼠标就可以获取所需要的数据。除了多维分析外，润乾报表还有dashboard分析界面那就是仪表盘，简称DBD，即大屏和分析控件的结合。 DBD可以通过图表、图形等视觉元素，将多个来源的数据中所蕴含的信息的趋势、异常和模式展现出来。接下来让我们看看当大屏与分析控件结...

什么是轻量级？抛开技术术语，从效果上看就是为了实现操作目的，使用更轻便、更省时的方法；那么什么是高性能呢？最直接的说法就是比常用方法更加高效、更快。下面就来介绍润乾提供的这一套轻量级、高性能的多维分析套件。轻量级的准确含义，是相对于重量级框架而言的一种程序设计模式。轻量级的优点在于对容器没有依赖性，易于配置，更加通用，启动时间较短，并能充分减少开发复杂度；而高性能，则是指相比于常用方法而言，获取期望结果更加快速、准确的实现方法。具体到润乾报表，这里将给大家介绍通过多维分析页面对简单SQL进行查询。

如果你曾经出国旅游，尤其是去欧洲自由行，有没有在餐馆点菜的惨痛经历？（当然金拱门、K 记不算……），面对菜单上一个个似是而非的单词，有没有忧桑? 有没有惆怅？有没有很……呃，饥饿？同样，在做前端业务查询时，如果你不清楚 SQL 这种“点菜”的语言，那么怎么去找那些字段、设那些条件？是不是也有同样的忧桑、惆怅……和饥饿感？不过，现在不一样了，因为我们有了润乾报表 V2018 查询控件！TA 就像自助餐厅里琳琅满目的锅碗瓢盆，把深藏在数据库（后厨？）里的数据清清楚楚地呈现在你面前，任由你挑选组合，随时随

哈哈哈哈，打不过我吧，没有办法我就是这么强大，哈哈哈哈，追不上我吧，没有办法被我打败啦，哈哈哈哈，看不见我吧，分析权限根本没在怕！所谓数据分析的权限控制，就是指针对不同的用户分别配置不同的访问规则，使他们在登录后看到的数据不一样。有些东西不是你想看，想看就能看的，想看还得问问俺老孙答不答应…首先我们来捋捋分析的权限是如何体现在数据中的。一、分析中的用户权限在很多应用系统中，经常有两个典型的用户，root 和 guest。对于数据分析来说，root 用户权限最大，可以查询全部表的信息； gue

自定义表格样式多维分析展现报表时，润乾报表提供了一套默认的表格样式，统一的表格样式可以使业务人员减少报表美化的工作量。然而默认的样式不可能迎合所有用户的审美，为此润乾提供了自定义表格样式的功能，供用户实现个性化的需求，下面小编就来教你如何改变默认表格的样式。先来看下默认的表格样式，下面是一个统计雇员完成订单情况的报表：多维分析表格的样式实际上是通过一个模板报表来控制的，我们先来看下这个模板报表的内容，在设计器中打开 [安装根目录]\report\web\webapps\demo\WEB-IN

小编我本着先客户之忧而忧的服务宗旨，思前想后还是觉得之前的《把 Excel 透视表搬到 WEB 上》和《给一句 SQL 就能做多维分析》对多维分析的介绍不太够，所以今天特地再来唠唠如何对程序数据集做多维分析。访问 JavaAPIAPI是应用程序编程接口，程序开放API就是开放接口，开放后接口返回的程序数据就可以被其他程序调用了。问题来了，在俺们多维分析中怎样才能对API接口返回的程序数据做分析呢？简单，其实是分分钟搞定的事儿！步骤一：最最重要的前提，要麻烦程序猿自定义类，把要返回

在《给一句 SQL 就能做多维分析》中我们介绍了润乾报表可以基于一句 SQL 来做数据库数据分析，今天我们来继续说道说道，看看下面这个例子：这个分析数据集来自回款单，由回款单 ID，回款日期，金额，销售 ID 四个字段组成。对应的 sql 为：select 回款单 ID, 回款日期, 金额, 销售 ID from 回款单下图左边的报表就是按照销售 ID 这个维度分组，对回款金额进行汇总分析的结果：多维分析就是这么简单，写一条 sql 语句，拖拖拽拽就出炉了。像上面这个例子，如果列名是英文

在《给一句 SQL 就能做多维分析》中我们介绍了润乾报表可以基于一句 SQL 来做数据库数据分析，今天我们来继续说道说道，看看下面这个例子：这个分析数据集来自回款单，由回款单 ID，回款日期，金额，销售 ID 四个字段组成。对应的 sql 为：select 回款单 ID, 回款日期, 金额, 销售 ID from 回款单下图左边的报表就是按照销售 ID 这个维度分组，对回款金额进行汇总分析的结果：多维分析就是这么简单，写一条 sql 语句，拖拖拽拽就出炉了。像上面这个例子，如果列名是英文

提起 Excel 一定都不陌生，尤其是里面的数据透视表，对于需要进行聚合分析的情况，根据原始数据勾勾选选就能完成，用起来是倍儿爽吧。那么，操作起来这么省心的功能要是能移到 WEB 上，嵌入俺的应用程序里，是不是就完美了？so easy! 雷锋同志马上来教你做这事儿。主角登场——润乾报表多维分析！下面就先以 Excel 文件作为数据源，与各位小伙伴分享一下多维分析的应用案例，欢迎各位热烈围观，优雅吐槽：Excel 文件内容为如下：这个格式很普通，第一行是标题，后面就是一行行的数据了

是不是还在为成千上万的数据处理不完而苦恼？是不是一想到要处理这些数据就头大？今天又要为整理这些枯燥的数据加班怎么办？——不要担心！不要担心！润乾来拯救你！DQL分组分析的神秘力量会协助你顺利完成数据的操作与分析，加班？不存在的！隔壁组的老王和老李都羡慕哭了。分析控件功能拖拽字段首先从分析控件本身的功能入手——打开分析页面第一件事是做什么呢？对啦，当然是要展示报表了~脱离敲打复杂的查询语句，只需要动动鼠标就可以获取所需要的数据。第一步就是要将所需要的字段拖拽到指标数据区。这里是第一

实践目标 一个DBD(又称Dashboard、仪表盘)，是通过多维分析(OLAP)的方式制作多个表格报表、统计图报表，同时与参数控件混合展示的一个复杂数据视图。它可能依赖多个数据集。 这些DBD元素并不是简单的叠加，而是互相关联的。从业务角度看，每个图、表分别体现同一个主题的不同侧面；局部单个图表与整体的外观风格协调一致；共享参数作用于多个图表，实现整体联动。 本篇通过制作一个完整的DBD，逐步体验这个过程中的功能细节。DBD制作页面概览...

实践目标之前实践中了解了润乾BI多个模块的功能，现在用一个管理系统把它们串联组合起来，形成一个完整的BI系统。BI产品是一个针对多维分析的系统大多数BI产品最终的表现形式是一个完整的管理系统，管理多维分析相关的资源，数据源、预制CUBE、制作的多维分析，基于用户角色权限控制谁能使用、制作、查看哪些资源。润乾也提供了一个拿来直接能用的BI管理系统 ：润乾报表中心。它管理的内容比较多，除了传统的润乾报表、大屏Dashboard、填报表，也包括模块化方式实现的多维分析、自助查询。用户系统润

实践目标了解基于DQL语义层的自助查询如何做明细、分组查询，以及用什么方式应对表间的关联。最后了解其源代码，以及与之前DQL多维分析的共性。自助查询概览不同于多维分析，有时只想查询出数据/下载数据，这时润乾专门提供了一个自助查询页面，和分析页面一样，也是基于元数据树，但更细致的实现了DQL查询能力。左上是一些功能按钮，右上列出raqsoftConfig.xml配置的所有DQL类型数据源，选其中一个做自助查询。最左侧把所有的分组维度单独列出来，中间是元数据树，可选各级字段以及对

实践目标通过解构润乾多维分析系统，阅读关键源代码，详细了解其能力构成，从而总结出使用它的指导意见。润乾多维分析系统的特殊性现在主流多维分析系统都是BS结构的，大多是一个多用户WEB系统，用户在浏览器上操作，向WEB服务器发出请求，WEB服务器再从数据库(或文件)里获得数据返回给界面。同时设计了一种用户角色权限方案，内置在系统中。还能对系统中的数据源/数据集/分析文件/系统日志等各种资源进行管理。往往是一个重度、密不可分的WEB系统，买来即用，基本上不涉及二次开发。润乾多维分析比较特殊，整体比

实践目标大数据时，可能被分割开存入多个数据库中以分摊计算量，这些数据库可能因为设计作用不同（比如是当期库和历史数）而导致其数据结构不一定完全相同。用元数据可以把它们统一映射成一个逻辑表，DQL Server将实时向各个分库发出SQL执行，取得结果数据再联合起来，给前端多维分析提供数据。多版本迭代的项目数据一个长期运营的项目，数据结构会存在迭代现象。比如不再发生变动的历史数据用另外的数据库存储；又或者数据结构随业务发生了变动或更换了数据库，用新结构的数据库存储以后的数据。新版本数据结构的命名规

实践目标数据量大的基础表，做多维分析时会比较慢，通过汇总表预先缓存一些聚合数据，然后在元数据中设置好基础表和汇总表的关系，最后达到这样的效果：在界面上做多维分析感觉不到汇总表的存在，后台的DQL Server能自动选用合适汇总表提速查询。大数据量的基础表和基于它的汇总表项目中的订单表可能有上亿条数据，基于它做分组汇总，速度会比较慢，这时如果预先把一些常用的汇总数据计算出来，并存入专门的汇总表，再做分组汇总分析时，直接从汇总表得到数据就会比较快，如订单表中的订单金额(amount)、订单日期(de

实践目标数据量大的基础表，做多维分析时会比较慢，通过汇总表预先缓存一些聚合数据，然后在元数据中设置好基础表和汇总表的关系，最后达到这样的效果：在界面上做多维分析感觉不到汇总表的存在，后台的DQL Server能自动选用合适汇总表提速查询。大数据量的基础表和基于它的汇总表项目中的订单表可能有上亿条数据，基于它做分组汇总，速度会比较慢，这时如果预先把一些常用的汇总数据计算出来，并存入专门的汇总表，再做分组汇总分析时，直接从汇总表得到数据就会比较快，如订单表中的订单金额(amount)、订单日期(de

实践目标有些维度有层次关系，比如产品的多级类别；年、月、日；国、省、市，这几个有层次关系的维度有可能存储在同一个字段中，比如005006008中包含了三级类别的编码，日期字段中则隐含了年维、月维。通过在语义层中预定义这些层次关系，把隐含的维度明晰定义出来，以方便界面中做多维分析。认识维度的层次修改测试库，给产品表增加分类ID、引入日期两列。一个产品可以归类为一级类别、二级类别、三级类别三种，分类ID的编码特点是每3位代表一个级别。各级分类的名称在产品分类表(product_categor

实践目标元数据中定义了整个数据库的表信息，在使用它时，要控制某些用户不能看某些表、某些字段、或不能看表中的某些数据。控制参与多维分析的表、字段范围由元数据生成的字典文件，之前已经认识过，它里面有个分类项功能，简单说就是挑选一些表、字段、维度，组成一个完整的大分类，给某些特定用户使用，从而限制他们看到的信息范围。比如下面的“员工分析”这个分类中，就去掉了订单、产品相关的表，区域表中去掉了区域级别字段：在多维分析jsp中设置使用上面这个orders.dct，同时设置使用“员工分析”这个分类项

实践目标定义完元数据，部署到DQL Server后，再进行多维分析(OLAP)时，体会后续界面操作、概念理解上的难易，探究DQL查询语言对多维分析的实际提升效果；同时，进一步探测DQL查询能力的完备性。融入关联关系的元数据树上一节设置了关联关系的元数据orders.lmd中，表名、字段名设置成中文语义：部署到DQL Server中，在WEB多维分析系统里针对它做多维分析，能看到元数据中设置的关联关系已经体现到元数据树上，如订单表的销售ID展开后，关联到员工(销售)表：隐式的关联多

实践目标偶尔用SQL做多维分析会比较方便，但如果经常做这类事务，每次都可能写重复的SQL，就会存在麻烦，通过使用预定义的语义层改善这些问题。基于SQL做多维分析的烦恼l 数据库中的表名、字段名几乎都是英文，甚至是缩略字母，每次都需要用AS转成中文的业务名。l 时不时会有一些计算字段，用到时每次都要编写计算表达式。l 事实表中只有代码值，对应的名称值经常是存储在另外的维表中，每次要写JOIN。预定义元数据语义层打开编辑元数据的设计器（{安装目录}/report/bin/dql.ex

实践目标了解怎么制作多维分析中展示结果的报表模板，演示一个模板中组合多种展示方式。制作一个报表我们用SQL类型数据集制作一个普通报表，查询employees库的部门经理表：制作好的报表，预览能看到数据：使用参数字段制作模板接下来通过修改上面这个报表制作成多维分析模板，来自数据集的固定字段要改成参数字段，先定义每个字段的参数：报表中通过${参数名}的方式使用这些参数字段：把模板保存到WEB-INF/files/rpx/目录后，就能用于

实践目标修改默认的显示风格；动态选用预先设计的多套显示风格。修改默认的显示风格对employees表中first_name，gender两个维度进行分析，默认生成的表格是下面这样：通过修改WEB-INF/files/style.rpx可以重新定义这些格子的前景色、背景色、或对齐方式等外观，可以看到默认的外观和页面显示一致：有标题、分组、指标三类单元格，指标可以从1~n多设计几个，选出多个指标字段时，会依次采用：重新做报表时，看到重新设计的显示风格已

实践目标了解多维分析界面的构成，然后实现界面上功能的取舍定制，用frame方式把多维分析嵌入自己的界面。解析多维分析界面对dept_manage表的数据做多维分析，下面是完整的study2.jsp以及展示页面主要有三个部分：上部工具条、分析操作区域、分析结果报表窗口（允许有多个报表窗口）。上部工具条是一些功能按钮；分析操作区域可以连续创建多个分析报表，每个报表针对不同的数据集。控制功能按钮的显隐顶部的工具条只想显示保存/打开两个按钮，用JS变量guid

实践目标体验较大计算量和较大结果集SQL在多维分析中的响应表现，用缓存方式提高响应速度；多维分析的报表中展示大量明细数据时，用大报表技术避免耗用过多内存、甚至内存溢出。大计算量SQL做多维分析下面这个SQL查询出平均工资最高的五万员工，需要大表employees（30万条）、salaries（284万条）关联、做分组汇总、最后按平均工资排序：页面在60秒之后才显示出结果：把性别拖到左表头上，统计这五万人中男、女性员工各有多少，这个动作仍然需要等待60秒才会

实践目标给定SQL，对其查询结果进行多维分析。测试数据及配置employees是一套开源的Mysql测试数据，下载后把它导入本地的Mysql数据库中，看到有8个互相关联的表：在润乾报表的配置文件WEB-INF/raqsoftConfig.xml中增加employees库的JDBC数据源，多维分析的jsp里能直接使用这里配置好的数据源名称emps，它主要配置url、driver、user、password四个属性：预定义待分析的SQL在study3.jsp中，在

现在市场上开源 BI 产品比较多，各个产品的侧重点不同，有的以报表为主、有的以可视化为主、有的以查询分析为主。这里我们选取了一些主流的开源 BI 产品，从产品功能、可视化能力、数据源支持以及使用文档等方面进行对比，希望对你有帮助。Superset由Airbnb贡献的轻量级BI产品，目前在GitHub上有3万多颗星，其受欢迎程度可见一斑。Superset提供了Dashboard和多维分析两大类功能，后者可以将制作的结果发布到Dashboard上也可以单独使用。数据源方面，Superse

基于单表（宽表、CUBE）的多维分析有一整套标准体系，各大BI产品在这方面的差异主要也是体现在界面风格上，在查询功能方面几乎没有差别，并没有多少对比的必要。但多表关联时的多维分析情况就很不一样了，各厂家都对JOIN操作进行了界面可视化，希望业务人员自己拖拖拽拽就能搞定，进而减少具体业务需求对技术人员的依赖。但生成宽表的过程并没有一套业界通行的规范，各个厂家有自己的实现方法，结果会导致查询功能和可用性产生较大的差异，本文将对比国内主流几款BI产品在这方面的不同。BI中的关联需求下面以一个很常见的进销存

”一图胜千言”，图形是报表展示中不可或缺的内容，没有图形的报表是没有灵魂的，所以大家在做报表工具选型考察的时候，都会很关注图形。关注点基本有如下几条：1. 自有图形的种类自有图形通常是指工具内置的图形，不需要再扩展和引入。自有图形是报表的基本功能，它决定了报表工具的下限。2. 对第三方图形的支持程度，以及特殊图形的绘制能力当自有图形满足不了需求时就需要扩展，可以对接第三方，也可以自定义。虽然大部分需求可能使用自有图形就能满足，但遇到特殊需求时工具的扩展能力十分重要，这决定了报表工具的上限

本次仍然评测这几款主流的报表工具：润乾报表、帆软报表、Smartbi、永洪 BI、亿信。之前在多源关联分片报表中验证了各个报表工具的多数据源关联功能，这些产品都能支持多数据源，但对不同类型数据源的支持程度并不一样。目前常用的关系型数据库基本上都提供 jdbc 接口，所有报表工具都支持，这里就不做详细说明，下面主要看下几种数据源的支持情况：1、 文件数据源，如 Excel、txt、csv 等。2、 webservices 接口数据源，如服务返回的 json 或 XML 格式数据3、 非关系型数据库

有些报表查询出的数据行数可达千万甚至上亿，这类报表通常被叫做大报表，大多数情况下都是些清单明细数据报表，也有少量分组报表。针对大报表，如果像常规报表一样，将数据一次性全取再交给前端呈现是不可行的。一是等待时间太长，用户体验差；二是很可能导致内存溢出造成应用崩溃。那么，目前的报表产品是如何解决这一问题的呢？本文将调研并测试几款报表产品的大报表解决方案，还是针对这三款产品：润乾报表、帆软报表、Smartbi，均为最新版本。首先了解下各家的解决方式或机制。解决机制帆软帆软提供两种引擎，行式

报表呈现有这么几个阶段：取数、报表计算、生成 html 及页面渲染，报表计算是考察报表性能中较为重要的一环。多数据源（集）关联报表是一种计算量随规模增长较大的报表，适合用于进行此项测试。本文将对比报表的关联运算性能，产品依然是三款：润乾报表、FineReport、smartbi，均使用最新版本，涉及报表数据来源为同库同表。测试采用多数据集间关联计算，报表格式很简单，具体可参考下面的说明。用例POS 交易情况统计，统计所有商户（包括还未使用但已申请且开头 pos 刷卡业务的），使用本行 pos 机

报表上的计算比较复杂，常常是内存计算，报表工具能支持的容量也就是个重要的技术指标。我们当然希望报表占用的内存尽量少，这样同样内存空间可以容纳更大的报表（更多的单元格），也能支持更大的并发数量。本文将对比报表工具的容量及相关性能，看同样的内存（可用 jvm）空间下，谁能支持更多的单元格数，以及同样规模报表的计算性能。产品还是三款：润乾报表 V2018、FineReport V10.0、smartbi V9，涉及报表数据来源的均为同库同表。测试的用例都是最简单的报表格式，具体可参考下面的说明。用例一

报表上的计算比较复杂，常常是内存计算，报表工具能支持的容量也就是个重要的技术指标。我们当然希望报表占用的内存尽量少，这样同样内存空间可以容纳更大的报表（更多的单元格），也能支持更大的并发数量。本文将对比报表工具的容量及相关性能，看同样的内存（可用 jvm）空间下，谁能支持更多的单元格数，以及同样规模报表的计算性能。产品还是三款：润乾报表 V2018、FineReport V10.0、smartbi V9，涉及报表数据来源的均为同库同表。测试的用例都是最简单的报表格式，具体可参考下面的说明。用例一