阿里巴巴技术专家梓澈从多方面带您搞懂QuickBI的OLAP引擎技术原理,首先介绍了BI的国内外现状,然后对QuickBI的定位、使用流程以及客户案例进行详细分析。又对OLAP引擎进行了详细的讲解,最后对未来发展方向与展望进行了深刻的总结。
直播视频回顾
以下是精彩视频内容整理:BI产品介绍
提到BI与OLAP这两个概念,对于很多做数据库的技术人员来说并不陌生,目前国内外都有很多流行的BI产品,比如国外有Tableau、Microsoft Power BI、QlikView,国内有永洪BI、帆软BI、海致BDP等等,这些都是在业界有着良好口碑的BI产品,而阿里云的QuickBI在数据分析和数据可视化领域同样也是一款很好的BI产品。
QuickBI
上图是QuickBI产品的首页,可以看到首页中有关于QuickBI产品的介绍,比如产品特性、基本使用流程、不同版本之间的功能特性以及使用QuickBI的实战场景和垂直的应用场景等等。除此以外还提供了帮助文档和视频使用教程来帮助用户快速学习使用QuickBI产品。
QuickBI的定位
BI随着时代的发展逐渐出现了新型BI和传统型BI的划分,从目前的发展程度来看,传统型BI正在慢慢地衰退,新型BI正处于高速发展的时期。由于传统型BI存在一些问题,这些问题也成为了它发展的瓶颈:
1、传统型BI百分之九十以上的工作都需要专业的IT人员来完成,包括建立底层数据仓库、数据模型以及开发数据报表等,整个流程过于繁琐复杂,成本较高。
2、传统型BI专注于传统数据库的分析,不具备海量数据分析的能力。
3、传统型BI在数据可视化方面偏弱,业务人员在做数据分析查看的时候无法针对数据结果进行二次处理,从而导致可视化方面提供的服务偏少。
相比较而言,新型BI有效的解决了上述问题,QuickBI的定位是通过提供海量数据即席分析、电子报表制作及拖拽式的可视化分析能力,让懂业务的人自助实现数据分析,重塑数据生产的全链路,最终实现人人都是数据分析师。可以从以下几点具体分析这句话的涵义:
- 第一,产品提供了丰富的数频接入,既包括了传统的关系型数据库也包括了各种大数据计算引擎服务,并为海量的数据分析提供了加速引擎,可以向用户提供秒级的查询速度。
- 第二,提供了强大的数据可视化分析能力,比如可以制作类Excel电子表格,在电子表格里提供了大约三百多种常用函数,除此还提供了多种可视化仪表板,能满足用户的各种可视化需求。
- 第三,新型的BI强调的是业务主导和智能自助,IT人员只需要做底层数据准备工作,其余工作全部由业务人员自助完成。
QuickBI使用流程
使用QuickBI进行数据分析大致分为四步:
1、添加数据源: BI支持多种数据源接入,主要有三种,分别是云数据源、用户自建的数据库以及用户本地文件通过touch空间上传到平台中后提供数据分析服务。
2、创建数据集:与数据源建立连接以后可以对表格进行加工,将对表的加工过程固化保存下来避免重复操作。
3、报表制作:整个报表制作分为两个模块,分别是类Excel编辑表格与具有分布可视化图表的仪表板,不论是电子表格还是仪表板都可以提供强大的数据分析服务。
4、报表应用:在完成电子表格或仪表板后就可以把这些电子表格或仪表板构建成数据门户,在数据门户中可以无缝集成用户想要展示的报表,所有的报表也可以用于第三方的嵌入集成,与用户自身的平台无缝集成,除此之外还提供了多种报表功能。
QuickBI功能示例
上图是QuickBI提供的类电子表格,整个电子表格提供的表格分析能力和Excel比较类似,提供了三百多种常用函数,这些函数保持了与Excel几乎相同的使用方式,从而使熟练Excel的人员把经验无缝衔接过来,方便用户的使用。
此图为仪表板的截图,可以看到有20余种数据图表类型,在整个仪表板中可以做许多强大的数据分析的图,提供比较丰富的可视化图表,并且图表之间可以实现图表的联动、图表的跳转以及图表赚取分析等。
QuickBI客户真实使用场景
秦丝科技
秦丝科技在业务运营中比较关注用户的留存率和活跃率等指标,对接QuickBI之后,由技术人员完成底层数据的采集、加工和清洗处理,并将数据导出到数据分析库,接下来由业务人员自助完成报表的开发工作,满足了定制化报表与临时分析两种不同的场景。
青桔科技-货车兄弟
与秦丝科技类似,但是不同的是青桔科技需要将制作的报表与公司自身的管理系统进行集成,解决了员工使用不同系统工作的问题。QuickBI则提供第三平台嵌入集成的功能,比较好的解决了青桔科技的需求。
OLAP引擎的流程分解
一个完整的数据建模和数据分析过程可以分成四大块,首先需要探取数据源的元数据,利用元数据进行数据建模,生成符合规则的数据集,其次需要利用数据集结合可视化图表进行数据分析的工作,创建出查询模型。然后将查询模型进行解析,生成可以匹配当前的数据源的sql语句后,发送到数据源进行数据查询,将查询的结果处理完成后传输到报表上进行可视化展现。
OLAP引擎技术架构图
整个技术架构图可以分为几大块:首先是基础模型,主要包括元数据模型、数据集模型以及查询模型。元数据模型是对元数基本的封装,包含了各种元数据使用价值的属性,如表/视图、字段、主键/外键、索引、分区字段、函数和存储过程,这些属性可以协作用户快速完成数据集建模工作。
数据集模型是对数据源抽象描述的模型,将物理字段映射成抽象的维度,将物理表或视图的映成关联关系,并且可以使用分组、计算字段等高级功能实现复杂的条件表达式和计算表达式。而用户在进行数据分析过程中可以屏蔽各种物理细节,进而简化了用户的使用成本。
查询模型是对数据分析抽象描述的模型,它可以把最终的查询条件抽象成为一个查询模型。由于查询模型是抽象的,基本无法被数据源识别,因此在进行数据查询时会将查询模型转换为数据源可识别的查询语句。查询流程具体包括接口层、路由层和查询引擎层,接口层提供了数据查询表达式(DQX)与数据权限表达式(DAX)两种表达式。路由层主要用于并发控制、路由策略以及数据的封装和异常校验等。
整个QuickBI提供了普通查询引擎与加速引擎两种,这两种引擎功能比较类似,都是将查询模型转化为数据源可识别的查询语句,并在运行中针对各种高级计算的规则对查询结果进行进一步处理。它们最大的区别是底层执行框架存在差异,普通查询可以通过自营的分布式执行框架与底层数据源进行对接,而加速查询则引入了MPP计算框架,与大数据系统进行对接,依靠MPP框架本身的性能实现海量数据的集成响应。
OLAP引擎数据源
数据源可以简单分为几类:包括SQL类数据源,可将其进一步划分为关系数据库与分析型数据库,其次还有NoSQL类数据库、大数据离线计算系统以及API类数据源,最后一种是文件类数据源。
OLAP引擎数据建模
从上图可以看到用户数据库提供了数据源的接入,通过MetadataCrawter抽取出用户数据库中的元数据,然后构建出需要的元数据模型,在元数据模型里提供了几种不同的属性。通过CubeAutoBuilder将元数据模型自动转化为数据集模型,数据集模型描述了整个数据集涉及到的维度、度量、层次、成员以及关联模型。在数据模型中用户除了可以使用元数据模型智能构建的数据集以外,还可以自行进行建模操作。通过构建关联模型可以实现单表模型、新型模型或者雪花模型。整个数据库模型最后以xml格式进行存储,可以通过CubeXmlGenerator把数据模型转化为xml存储格式,相反也可以通过CubeXmlGenerator把xml格式转化为数据集。
OLAP引擎数据查询和路由
前面提到整个接入层包括DQX与DAX,数据查询的第一个过程是接收DQX与DAX,并对这两种表达式进行重组、整形和优化,最终整合成有一个统一的查询模型。智能路由按照用户级别分成多个队列,每个队列都有一定的数量限制,如果用户的产品引擎达到上限,那么就需要在队列中进行等待,否则就可以把它放到RunningPool中。然后通过RoutingPolicy判断一个产品到底属于哪一个查询引擎,这里提供了两种不同的查询引擎,包括普通查询引擎与极速查询引擎,不同的查询引擎走不同的计算框架,最终把计算的查询结果转换为RewRsult数据格式。
查询模型进入查询引擎后会对查询模型进行转化,把查询模型转化为抽象语法树,然后再将语法树转化为试退为各种数据源的SQL语句,将SQL语句放入缓冲管理模块进行判断,如果执行结果存在于缓冲管理模块,直接在缓冲管理模块读出结果。如果不存在,就将数据源的SQL语句转化为查询任务,再将查询任务分到分布式框架里面。分布式框架主要负责与底层数据源的对接,把相应的SQL语句放入数据源内执行并获取查询结果再返还给查询引擎,从而生成一个查询结果集,查询结果集会进行数据转换,最后会根据查询结果集进行内存净化处理。
加速引擎与查询引擎大多类似,唯一的区别在于底层框架的执行,查询引擎是QPI自主研发的一个分布执行框架,而加速引擎则引入了MPP引擎框架,通过MPP框架可以实现针对大数据的秒级查询响应。
未来探索方向
未来的探索方向大致可以分为四个方面:
1、数据分析:扩展更多数据源,丰富更多的可视化图表和布局模式,给用户更好的体验;其次要有监控预警功能、提升OLAP多维分析功能以及大数据处理能力和效率。
2、数据管理:加强元数据的管理,同时提供数据轻量级ETL并实现数据线上线下的打通。
3、集成融合:有两种与用户第三方平台的集成方式分别是报表的嵌入集成与OPEN API,通过这两种方式可以实现QPI产品与用户的自由的系统和平台达到无缝的集成融合。
4、智能:在数据分析智能方面,结合数据挖掘和机器学习内置各种场景化的算法模型;在产品智能方面,结合自然语言、语音识别等技术提升产品易用性。
本文作者:云迹九州
本文为云栖社区原创内容,未经允许不得转载。