基于SequoiaDB与Pentaho打造开源一体化BI平台

ark43420 发布于 2015/06/26 16:48
阅读 2K+
收藏 4

614日举办的OSC源创会上海站,SequoiaDB巨杉数据库的联合创始人兼CTO王涛,发表了题为基于SequoiaDBPentaho打造开源一体化BI平台的技术分享。这一话题得到了现场观众的热烈响应,那么笔者将总结和整理王涛先生的演讲内容。



以下为演讲主要内容:

Pentaho是什么?

Pentaho是一个2004年成立的公司,主要做的是BI解决方案方面的软件,现在是全球使用最多的企业级开源BI套件。

它所提供的组件主要分成几个大块:

 

BI Server实际上就是前端展现工具。基于Web的,里面有DashboardOLAP这些东西,能够根据预定义的报表和数据模型生成最后的结果图。

 

Report Designer实际上是报表设计工具,用这个来设计出来报表的结构和布局。

 

Mondrian则是OLAP服务器,其中的Workbench可以被用来设计Cube模型,生成的XML配置可以直接被BI Server使用进行报表展现。

 

Data Integrator是做ETL用的,Pentaho除了在展现和建模以外,还提供了一个叫做PDI Data Integrator的工具,用来从不同的数据库和平台之前导数据。比如我们可以针对前端的不同业务,通过PDI把数据导到我们NoSQL数据库或者Hadoop里面,这里面的数据也可以通过PDI与已有的数据仓库连接。

 

Kettle,底下还有一些子项目,像Spoon就是它的图形界面展现部分。Pentaho挺好玩的,ETL这一块特喜欢用厨房用品来命名,估计他们项目经理原来是个厨子。

 

Weka则是做预测分析的。

 

从这些组件的作用可以看出来,PentahoBI这一块提供了非常完善的解决方案,从数据迁移、模型设计、报表设计、到最终的前端展现一条龙都打通了。

 

 

大数据与BI

传统来看,Pentaho主要对接的都是OracleTeradataDB2等传统关系型数据库。而在这个大数据时代呢,所有人都在向NoSQLHadoop靠拢,所以Pentaho也开始支持各种NoSQL以及Hadoop等架构。

除了单纯的存储量的提升和替换,在大数据的环境下,BI的作用提升还有很多方面,包括了

数据仓库的优化、内部大数据服务啊,以及IoT传感器数据的使用,基于全量数据分析的预测机制,360度客户视图等。这些新的应用点都是BI与大数据的结合产生的价值。

 

传统的ETL流程,把数据从数据源抽出来经过各种清洗、脱敏、关联、聚集,到最后出来放到一些数据仓库里面。这样会造成什么问题呢?

 

•       丧失数据精度:这种方式一方面ETL流程非常复杂,同时会将很多原始的数据丢失,也就是所谓的丧失数据精度。

•       T+1:实时性上基本只能做到T+1,也就是分析只能看到昨天的数据,比如对于销售和市场人员来说,只能够看到前一天的销售业绩统计,不能看到当前的情况。

•       数据血缘关系混乱:我们经常看到用户抱怨,说数仓出来的统计报表和财务收入对不上。然后跑去问技术人员,但最后整个技术团队根本没人说得明白数据加工的流程,也就是最后这个报表里面的数字是怎么算出来。

 

不少的大企业存在这样的问题,也就是因为数据在加工的时候经历过太多的流程,各种变换脱敏聚集归纳,而整个流程在经过多年的开发和维护之后,已经没人说得明白每一步都是干啥的了,这样会对整体BI的结论存在不确定性。

 

在大数据时代,我们如何通过大数据技术来简化过去的复杂的ETL呢?

归根结底,过去需要不停ETL的主因是,所有的数据存储平台都是单点的,一旦这个节点在进行在线业务以外做了其他事情,会把前端的在线业务拖死。

另一方面,每个系统处理数据的容量和速度是有限的,因此不可能把企业产生的所有数据一起来跑,只能一个系统跑一部分数据,出来的结果拿过来再和其他的系统结合。所以呢,过去就需要把数据不停地在不同的系统之间倒来倒去。

就好像调鸡尾酒一样。

而大数据平台,解决了数据容量和吞吐量的问题,同时也允许数据的读写分离。在这种情况下,我们可以最大程度地避免数据的倒来倒去。因此,我们的整个平台架构可以这样看。

最下层是数据源,从数据源来的数据直接进入大数据平台,里面可以包括结构化、半结构化和非结构化文件系统存储。而上层的数据挖掘统计分析平台可以直接对接到大数据平台,通过大数据平台作为数据源直接读取数据。

 

SequoiaDBNoSQL

SequoiaDB和传统的关系型数据库相比,这种类型的数据库的特色就是使用JSON文档支持动态数据模型。比如传统的关系型数据库,做什么事情都要把数据切成一个一个的表,然后使用的时候关联起来。而JSON文档存储则可以被认为是面向对象存储,可以直接把一个对象以层次的方式直接存放下来,不需要把一个实体拆成无数的零件。

 

除了数据模型的变化,SequoiaDB另一个特点是把数据在数据库内部进行多份存储,一方面可以保证高可用性,另一方面可以进行读写分离,将不同类型的业务分发到不同的物理盘上,做到实时操作和批处理分析互不干扰。这种模式也是大数据平台的一个基础。所谓大数据平台就好像一个垃圾桶,或者说云存储一样,把任何类型的数据都可以往里面扔,使用的时候随意做结构化、非结构化、实时或批量的检索,并且最大化地保证业务之间的相互独立不干扰。

 

从技术架构上看,作为大数据平台的底层统一数据源,SequoiaDB可以对接上层的多种不同类型中间件框架,包括HadoopSpark、标准SQL引擎或直接使用API访问。使用这种机制,整个平台可以支持实时结构化查询、非结构化数据访问,交互式分析以及批处理分析等各种不同业务.

 

 

NoSQL+BISequoiaDB+Pentaho

因此,在整体解决方案的架构来看,最上层的展现部分为Pentaho,下面使用Hive做中间件处理SQL解析和分布式聚集关联,最下面则是JSON存储。

这种模型一方面能够有效利用到NoSQL灵活数据模型的特性,动态接入不同来源等多变的数据。另一方面我们也可以利用Hive映射不同的字段,供上层Pentaho做报表展现和多维聚集分析。

 

 

Pentaho + Hive + SequoiaDB =报表展现 + SQL引擎 + 非结构化存储


 

 

单从大数据和BI的角度,那么它的基本流程是这样的。

首先从原始系统通过ETL,或直接实时将数据写入大数据平台。这一块可以是Hadoop,或SparkNoSQL数据库。然后在上层通过Mondrian这种OLAP工具做建模,通过BI Server进行展现。

 


 

 

SequoiaDB+Pentaho步骤:(7步)

 

­第一步:生成数据




 

第二步:对接Hive

这一步我们需要在hive这里创建外部表

 

 

第三步:配置Pentaho

在对接PentahoHive的时候,对于Pentaho BI工具需要把hive/hadoop/log4j/clienthttp/zookeeper/thriftserver等一系列依赖jar包导入tomcat/lib目录下。对于mondrian也需要同样的步骤,确保所有的依赖包都存在。

怎样来debug?尝试连接hadoop hiveserver2,然后看catalina.outcatalina.log文件,如果有依赖包缺失会提示的。

如果报告说connection fail,如果确保beeline可以连接上,那么很有可能是hive jdbc和服务端的版本对不上。

 

 

第四步:生成cube

这个是mondrianschema workbench,用这个工具来定义各种维度的。这里还有一个小东西需要注意,mondrian使用了很多像setAutoCommit这种hive直接抛出异常的函数,因此在做schema设计的时候没问题,但是在运行MDX的时候,使用Hive数据源是不行的。

 

第五步:导入mondrain xml

第六步:编辑查询

 

第七步:生成报表

加载中
返回顶部
顶部