轻量级OLAP分析工具发布

 

分析工具详细介绍

基本信息

用户的数据展示需求是多种多样的，我们的分析工具不能100%的满足所有的展示需求。但是我们希望通过我们的分析工具的20%的代码来满足用户数据展示的80%的需求，同时我们对剩下20%的需求提供自定义接口，允许用户进行自定义开发。

我们的分析工具是一套轻量级基于统计数据的数据查看工具。

· 轻量级、寄生式系统

· 跨数据库平台，跨操作系统，跨浏览器

· 支持OLAP样式的数据展示格式

· 图形支持

· 和用户的交互性较好

分析工具与其他工具的区别

	优点	缺点
分析工具	数据展示格式灵活 能更大程度上满足用户的数据需求 带有图形展示	支持的数据量最大不要超过2千万
报表工具	展示能支持更加复杂的数据格式	展示格式固定 一般不带图形展示 缺乏和用户的交互
OLAP工具	重量级数据查看 大数据量的支持很好	目前还没有跨数据库产品的OLAP产品出现 OLAP使用的CUBE的转换效率比较低，维护所需要的技术门槛高

功能展示

总体页面

用户界面介绍

维度输入选择

以最大程度减少用户输入为原则,分析工具提供多种维度输入组件.

日期选择框

 树形选择框

普通多选组件

 单选组件

 对比框输入:对比框是分析工具实现多层次数据展示的灵魂组件,通过多tab的多选择项,我们的数据就会按照相应的顺序进行下钻.

 多指标的数据展示

 多维度多层次数据展示

 图形选择框

可以在图形选择框上选择所要查看的图形,选择查看的指标,选择对应的数据

多指标的折线图

 多层次的图形展示

单层次的图形展示 

分析配置界面介绍

数据源配置:支持目前主流的4种数据库(Oracle,MsSql,DB2,Mysql)

 表信息的元数据配置,用来描述表的元信息数据.支持视图,多种模板表策略

 维度配置

 分析配置

分析基本信息配置:设置分析的访问表,视觉布局以及可能涉及到的二次开发配置

 分析的指标配置:配置指标展示的中文标识,结算别名,指标对应的列,指标的合计方式,指标的单位,数据格式等信息.

 分析的维度应用配置:配置维度对应的列,维度的操作符,维度的展示组件,组件展示的参数等信息

 分析的结果集计算配置:配置结果集的计算公式,数据展示格式等信息

更多信息请关注www.groob.net

 

评论

5 楼 senvon 2014-09-19  

novembersky 写道

xcl1984611 写道

mondrain对数据源的sql支持要求比较高，大数据实时查询的数据库大多不能支持完备的sql语法呀

在做这个东西之前,确实研究过一点mondrain,后来发现里面的代码比较差劲,另外作为mondrain的好基友----jpivot ,那个展示真不是一般人看的

另外上面同学说的,mondrain的效率太差,不但是sql支持有问题,另外mondrain把大量的数据都是加载到内存,用内存来做cube,导致运行一个cube基本服务器就废了

要想自己的元数据层和真实的数据库同步,中间的etl过程一定要包含元数据的解析
我在公司的时候,顺手写了个etl,是整个数据生产线上的一环,下次有机会,我把etl开源出来

4 楼 novembersky 2014-08-14  

xcl1984611 写道

居然碰到一个和我工作这么类似的家伙了,为了回复,好不容易通过邮件找回了这个已经遗忘了快4年的JavaEye的ID,真的觉得咱么做的东西这么有缘

你应该是负责后台数据处理的吧,这点和我完全一致啊,这个产品的最大卖点,其实还是无需建cube的即时分析,当初我也是这么做的,通过类BO的语义层的定义,建立出数据的关联关系.界面上拖拽维度和指标,根据定义态的表头树形结构,生成left join的group语句,形成一个小的数据集合面从聚集后的小数据集中（伪Cube）取数，通过这种方式把数据处理的重担压在了数据库端，当时整个功能都实现了，后来因为一些原因（薪资，团队），我离开了。

离开后，我找了家靠谱点的公司，还是做这方面的工作，不过已经转向了OLAP实现方向，后端用的mondrian，就目前的感觉来看，真心建议你用mondrian替掉数据聚集这一部分，jpivot的前后端数据模型转换部分及数据展现部分，可以自己接手替掉，mondrian已经挺成熟的了，至于不用建cube就分析这点，即席分析这条路已经足够了，动态元数据+分析主题自动化。

就目前我的一点观点：

自己的展现界面(web,cs,手机,pad)+自己的展现模型层+olap层(mondrain)+自己的语义层+自己的元数据层

这条路可以提供一个完整的BI技术平台 (etl和数据挖掘这个完全可以直接拿开源的来后续整合)

mondrain对数据源的sql支持要求比较高，大数据实时查询的数据库大多不能支持完备的sql语法呀

3 楼 xcl1984611 2012-11-24  

xcl1984611 写道

居然碰到一个和我工作这么类似的家伙了,为了回复,好不容易通过邮件找回了这个已经遗忘了快4年的JavaEye的ID,真的觉得咱么做的东西这么有缘

你应该是负责后台数据处理的吧,这点和我完全一致啊,这个产品的最大卖点,其实还是无需建cube的即时分析,当初我也是这么做的,通过类BO的语义层的定义,建立出数据的关联关系.界面上拖拽维度和指标,根据定义态的表头树形结构,生成left join的group语句,形成一个小的数据集合面从聚集后的小数据集中（伪Cube）取数，通过这种方式把数据处理的重担压在了数据库端，当时整个功能都实现了，后来因为一些原因（薪资，团队），我离开了。

离开后，我找了家靠谱点的公司，还是做这方面的工作，不过已经转向了OLAP实现方向，后端用的mondrian，就目前的感觉来看，真心建议你用mondrian替掉数据聚集这一部分，jpivot的前后端数据模型转换部分及数据展现部分，可以自己接手替掉，mondrian已经挺成熟的了，至于不用建cube就分析这点，即席分析这条路已经足够了，动态元数据+分析主题自动化。

就目前我的一点观点：

自己的展现界面(web,cs,手机,pad)+自己的展现模型层+olap层(mondrain)+自己的语义层+自己的元数据层

这条路可以提供一个完整的BI技术平台 (etl和数据挖掘这个完全可以直接拿开源的来后续整合)


另外 有兴趣的话,可以给我发email,交个朋友吧.  [e-mail]

2 楼 xcl1984611 2012-11-24  

居然碰到一个和我工作这么类似的家伙了,为了回复,好不容易通过邮件找回了这个已经遗忘了快4年的JavaEye的ID,真的觉得咱么做的东西这么有缘

你应该是负责后台数据处理的吧,这点和我完全一致啊,这个产品的最大卖点,其实还是无需建cube的即时分析,当初我也是这么做的,通过类BO的语义层的定义,建立出数据的关联关系.界面上拖拽维度和指标,根据定义态的表头树形结构,生成left join的group语句,形成一个小的数据集合面从聚集后的小数据集中（伪Cube）取数，通过这种方式把数据处理的重担压在了数据库端，当时整个功能都实现了，后来因为一些原因（薪资，团队），我离开了。

离开后，我找了家靠谱点的公司，还是做这方面的工作，不过已经转向了OLAP实现方向，后端用的mondrian，就目前的感觉来看，真心建议你用mondrian替掉数据聚集这一部分，jpivot的前后端数据模型转换部分及数据展现部分，可以自己接手替掉，mondrian已经挺成熟的了，至于不用建cube就分析这点，即席分析这条路已经足够了，动态元数据+分析主题自动化。

就目前我的一点观点：

自己的展现界面(web,cs,手机,pad)+自己的展现模型层+olap层(mondrain)+自己的语义层+自己的元数据层

这条路可以提供一个完整的BI技术平台 (etl和数据挖掘这个完全可以直接拿开源的来后续整合)

1 楼 jetliu1987 2011-11-12  

楼主的这个东西我蛮感兴趣的，现在我主要开发ETL工具，有机会交流一下。