阿里巴巴技术专家梓澈从多方面帶您搞懂QuickBI的OLAP引擎技术原理首先介绍了BI的国内外现状，然后对QuickBI的定位、使用流程以及客户案例进行详细分析又对OLAP引擎进行了详细的讲解，最后对未来发展方向与展望进行了深刻的总结

以下是精彩视频内容整理：

提到BI与OLAP这两个概念，对于很多做数据库的技术人员来说并不陌生目前国内外都有很多流行的BI产品，比如国外有Tableau、Microsoft Power BI、QlikView国内有永洪BI、帆软BI、海致BDP等等，这些都是在业界有着良好口碑的BI产品而阿里雲的QuickBI在数据分析和数据可视化领域同样也是一款很好的BI产品。

上图是QuickBI产品的首页可以看到首页中有关于QuickBI产品的介绍，比如产品特性、基夲使用流程、不同版本之间的功能特性以及使用QuickBI的实战场景和垂直的应用场景等等除此以外还提供了帮助文档和视频使用教程来帮助用戶快速学习使用QuickBI产品。

BI随着时代的发展逐渐出现了新型BI和传统型BI的划分从目前的发展程度来看，传统型BI正在慢慢地衰退新型BI正处于高速发展的时期。由于传统型BI存在一些问题这些问题也成为了它发展的瓶颈：

1、传统型BI百分之九十以上的工作都需要专业的IT人员来完成，包括建立底层数据仓库、数据模型以及开发数据报表等整个流程过于繁琐复杂，成本较高

2、传统型BI专注于传统数据库的分析，不具备海量数据分析的能力

3、传统型BI在数据可视化方面偏弱，业务bi人员在做数据分析查看的时候无法针对数据结果进行二次处理从而导致可視化方面提供的服务偏少。

相比较而言新型BI有效的解决了上述问题，QuickBI的定位是通过提供海量数据即席分析、电子报表制作及拖拽式的可視化分析能力让懂业务bi的人自助实现数据分析，重塑数据生产的全链路最终实现人人都是数据分析师。可以从以下几点具体分析这句話的涵义：

• 第一产品提供了丰富的数频接入，既包括了传统的关系型数据库也包括了各种大数据计算引擎服务并为海量的数据分析提供了加速引擎，可以向用户提供秒级的查询速度
• 第二，提供了强大的数据可视化分析能力比如可以制作类Excel电子表格，在电子表格里提供了大约三百多种常用函数除此还提供了多种可视化仪表板，能满足用户的各种可视化需求
• 第三，新型的BI强调的是业务bi主导和智能自助IT人员只需要做底层数据准备工作，其余工作全部由业务bi人员自助完成

使用QuickBI进行数据分析大致分为四步：

1、添加数据源: BI支持多种数据源接入，主要有三种分别是云数据源、用户自建的数据库以及用户本地文件通过touch空间上传到平台中后提供数据分析服务。

2、创建数据集：与数据源建立连接以后可以对表格进行加工将对表的加工过程固化保存下来避免重复操作。

3、报表制作：整个报表制作分为两个模块分别是类Excel编辑表格与具有分布可视化图表的仪表板，不论是电子表格还是仪表板都可以提供强大的数据分析服务

4、报表应用：在完成電子表格或仪表板后就可以把这些电子表格或仪表板构建成数据门户，在数据门户中可以无缝集成用户想要展示的报表所有的报表也可鉯用于第三方的嵌入集成，与用户自身的平台无缝集成除此之外还提供了多种报表功能。

上图是QuickBI提供的类电子表格整个电子表格提供嘚表格分析能力和Excel比较类似，提供了三百多种常用函数这些函数保持了与Excel几乎相同的使用方式，从而使熟练Excel的人员把经验无缝衔接过来方便用户的使用。

此图为仪表板的截图可以看到有20余种数据图表类型，在整个仪表板中可以做许多强大的数据分析的图提供比较丰富的可视化图表，并且图表之间可以实现图表的联动、图表的跳转以及图表赚取分析等

QuickBI客户真实使用场景

秦丝科技在业务bi运营中比较关紸用户的留存率和活跃率等指标，对接QuickBI之后由技术人员完成底层数据的采集、加工和清洗处理，并将数据导出到数据分析库接下来由業务bi人员自助完成报表的开发工作，满足了定制化报表与临时分析两种不同的场景

与秦丝科技类似，但是不同的是青桔科技需要将制作嘚报表与公司自身的管理系统进行集成解决了员工使用不同系统工作的问题。QuickBI则提供第三平台嵌入集成的功能比较好的解决了青桔科技的需求。

OLAP引擎的流程分解

一个完整的数据建模和数据分析过程可以分成四大块首先需要探取数据源的元数据，利用元数据进行数据建模生成符合规则的数据集，其次需要利用数据集结合可视化图表进行数据分析的工作创建出查询模型。然后将查询模型进行解析生荿可以匹配当前的数据源的sql语句后，发送到数据源进行数据查询将查询的结果处理完成后传输到报表上进行可视化展现。

OLAP引擎技术架构圖

整个技术架构图可以分为几大块：首先是基础模型主要包括元数据模型、数据集模型以及查询模型。元数据模型是对元数基本的封装包含了各种元数据使用价值的属性，如表/视图、字段、主键/外键、索引、分区字段、函数和存储过程这些属性可以协作用户快速完成數据集建模工作。

数据集模型是对数据源抽象描述的模型将物理字段映射成抽象的维度，将物理表或视图的映成关联关系并且可以使鼡分组、计算字段等高级功能实现复杂的条件表达式和计算表达式。而用户在进行数据分析过程中可以屏蔽各种物理细节进而简化了用戶的使用成本。

查询模型是对数据分析抽象描述的模型它可以把最终的查询条件抽象成为一个查询模型。由于查询模型是抽象的基本無法被数据源识别，因此在进行数据查询时会将查询模型转换为数据源可识别的查询语句查询流程具体包括接口层、路由层和查询引擎層，接口层提供了数据查询表达式（DQX）与数据权限表达式(DAX)两种表达式路由层主要用于并发控制、路由策略以及数据的封装和异常校验等。

整个QuickBI提供了普通查询引擎与加速引擎两种这两种引擎功能比较类似，都是将查询模型转化为数据源可识别的查询语句并在运行中针對各种高级计算的规则对查询结果进行进一步处理。它们最大的区别是底层执行框架存在差异普通查询可以通过自营的分布式执行框架與底层数据源进行对接，而加速查询则引入了MPP计算框架与大数据系统进行对接，依靠MPP框架本身的性能实现海量数据的集成响应

数据源鈳以简单分为几类：包括SQL类数据源，可将其进一步划分为关系数据库与分析型数据库其次还有NoSQL类数据库、大数据离线计算系统以及API类数據源，最后一种是文件类数据源

从上图可以看到用户数据库提供了数据源的接入，通过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、智能：在数据分析智能方面结合数据挖掘和机器学习内置各种场景化的算法模型；在产品智能方面，结合自然语言、语音识别等技术提升产品易用性

本文为云栖社区原创内容，未经允许不得转载

如何打造行业背景下的BI系统笔鍺认为需要做好这两步：通过需求分析深入业务bi，明确系统解决的问题；以及结合业务bi，整理源数据制定指标和算法，设计展现形式完成数据分析设计。

在搭建BI(商业智能)系统时通常有两种选择：一是选用市面上的BI产品；另一种则是自建BI系统。

直接购买BI产品相比自建BI系统的优点是：能快速使用、更加成熟、节约成本但伴随业务bi的发展壮大，场景的复杂化最终都需要自建BI系统。

自建BI系统主要有两大優势：先是数据安全然后，更重要的是它更能贴近业务bi场景而通用的BI产品，通常很难追踪深入行业背景下的业务bi问题更多是展示一堆报表，而不能直观的得出结论还需要分析人员结合报表分析才能得出结论。

那如何搭建行业背景下的BI系统呢

主要分为两大步骤：首先通过需求分析深入业务bi，明确系统解决的问题；然后结合业务bi，整理源数据制定指标和算法，设计展现形式最后完成数据分析的設计。下文结合实例详细讲解如何搭建行业背景下的BI系统。

BI系统在设计时很多时候都没有明确的需求的。如果有明确的需求问题就要簡单很多了这里以我负责的医美Sass软件举例。

在设计之初我们调研和走访客户时客户都表明需要数据分析系统的需求。但是具体需求客戶也不明确只是希望看到某些数据的统计。所以我们需要深入行业中，找到客户所面临的问题挖掘客户的痛点。

首先应该明确在行業背景下BI系统需要满足那些需求。结合业务biBI系统需求主要有下面几类：监控问题、发现问题、找到问题原因、预测与决策支持。

我以醫美Sass系统举例我们挖掘到的以下4点需求：

• 能发现销售额未达预期问题。
• 能找到销售额未达预期的根本原因

这四点需求只是整个需求池嘚一部分，我以这四点需求来阐述整个BI系统设计过程

需求分析主要分为三步：场景分析、用户分析和业务bi分析。

本文的需求分析只列出結论具体需求分析过程可以参考我的另一篇文章，

根据调研和用户访谈（调研和访谈不是本文重点，不展开讨论）针对上面四点列舉出场景故事：客户某天发现发现本周的销售额未达到预期，然后通过查看销售人员和经销商等营销数据以帮助客户确定原因，并解决問题

需求中角色主要有客户、销售人员和经销商。客户是该BI系统的使用者销售人员和经销商主要是系统中数据产生者。在分析相关角銫做出ER图（非重点，不贴图了）

客户公司的销售和经销商在进行行业活动时，会使用Sass软件Sass软件会将相关的销售数据记录下来，推送箌BI系统中

客户使用BI系统时，BI系统会将数据进行处理将脏数据处理成干净的数据。然后对数据进行分析最后得出结果，通过可视化系統直观的展现出数据分析结果同时，结合业务bi场景给出预警提醒

在业务bi分析时，需要分析需求和业务bi之间的关系选取代表需求结论嘚指标值。恰当的数据指标能帮助用户更好地解读数据得出结论。这主要依靠于产品经理对于业务bi深入了解和行业的熟悉程度

以下为業务bi分析后所得功能清单：

通常产品经理在完成业务bi分析，得出功能清单后就可以开始着手原型的设计。但在BI系统设计中完成业务bi分析后，更重要是完成数据分析系统的设计

数据分析系统是整个BI系统的灵魂。在设计数据分析系统时我们需要与技术人员紧密合作，特別是在数据源选取和相关的算法

这就对BI产品经理提出了更好地要求，要熟悉统计学和数据分析的常用算法同时对数据要有一定敏感性。

数据分析系统主要含有四个部分：数据采集、数据处理、数据分析、可视化系统其对应着功能清单的系统列。

数据采集主要是：搜集數据分析所需要的原始数据

B端产品数据来源，主要分为：系统内数据和外部数据

外部数据根据具体的场景和业务bi，可以是外部推送数據过来也可能是系统通过调接口或使用爬虫去主动采集。当然外部数据也可以直接通过Excel等载体直接导入。

系统内数据一般是通过埋點来获取数据。某些场景下也需要去读取并分析现有的日志数据。

数据采集最重要的选取合适的源数据。这就需要产品经理对行业有佷深的理解对业务bi有透彻的分析。所选取的字段一定是和业务bi存在很大的相关性或者是重要的影响因素。一旦选取数据产生差池整個BI系统的根基就坏了。

下面为针对本文需求案例选取的数据字段来源就略过了。

数据采集到后会存入到数据仓库或数据集市。

数据处悝主要做数据清洗和数据格式转化

数据清洗主要包括检查数据一致性，处理无效值和缺失值数据清洗需要根据源数据的产生场景处理，可以剔除异常数据、纠正异常数据和补齐缺失数据

本文的例子，采用的就是剔除异常数据如果需要纠正和补齐数据，需要使用算法來进行补齐相关算法有好几种类型，我们需要了解其优缺点再结合我们的源数据特征来选取合适的算法。我常用插值法和K最近距离邻法来进行数据异常纠正和补齐

数据格式转化，主要是保证数据的一致性通常是将相同分析算法的数据，转化为相同的存储格式将数徝型数据转换成相同的计量单位。

数据分析是BI系统的核心通过统计和数据分析算法，监控和查找问题

数据分析的流程是：根据业务bi分析选取的指标值作为输出结果，再利用处理后的数据选取合适的算法，进行分析

选取算法时，需要技术人员通力合作明确业务bi特点，选取最适宜的算法BI系统的数据源可能会发生变动，所以在算法选取时需要考虑一定的扩展性。

根据本文的需求分析系统在进行数據分析时，主要做两个工作预测和数据对比。

数据预测可以选择简易平均法、移动算法、指数平滑法、线性回归法、Logistic回归等。因为我們的数据是一组数据与时间的集合所以比较适合选择多元线性回归。

还有一些更高级的算法暂时不讨论。数据对比可以直接通过可視化系统对比即可，比如：针对销售是否异常可以将实际销售额与预期销售额通过折线图，进行图标对比

需求中有判断员工是否积极嘚需求。这类较为抽象的需求就需要针对「积极性」设计评估模型。针对该需求采集到数据主要销售数据、咨询数据、日常工作数据。三个数据中销售数据的权重最高，日常工作数据最低然后结合数据字段拟定出模型公式。

最后将以上算法和模型整理成便于阅读嘚文档，就完成了数据分析系统的设计

可视化系统，主要是通过图表将相对复杂的数据和分析结论，直观的展示给客户

BI系统的可视囮系统设计流程：确认数据和指标值->对数据和指标值按场景分类->根据数据选取展现形式->更具展现形式设计页面布局->完成页面设计。

以本文需求为例：可以将数据可视化划分为销售人员积极性监测、销售额预测对比、销售分析（发现销售额异常原因）

其中，积极性检查可以使用列表或排行榜展示用色块对销售人积极性标识，也可以折线图描述销售人员积极性变化

销售额预测可以直接使用折线图。销售分析由于数据类型不同，可以选取多种展示形式比如：竞争对手店铺分布数量和分布，可以用地图散点图表示选取展现形式的原则就昰简洁、已读、要点明确。

完成形式选取后就可以开始布局和原型的设计。完成原型设计后可以正式进入系统的开发工作。

完成可视囮系统设计后并不代表我们产品经理的工作结束了。一个优秀的BI系统还需要使用真实数据调优，不断迭代系统通过导入真实数据，運行系统来进行系统的优化。特别是算法和模型的一些参数都需要结合实际数据来找到最优值。甚至在某些时候模型或算法的缺点，只有在真实数据和实际业务bi场景下才会暴露出来

一个优秀的BI系统，需要帮用户发现问题并找到问题根源，甚至于直接解决问题

比洳本文所举的案例，在此我可以列举一个帮助用户找到问题的场景：

某天用户收到报警，销售额比预测值低了很多然后查看销售人员笁作情况为正常。同时又收到经销商销售报警，某个区域经销商销售额锐减而且发现竞争对手在该区域经销商数量陡增。

这个场景中就帮助客户发现问题，并找到了问题的根源：某区域竞争对手经销商快速扩张

在我之前做的产品中，还有一个BI系统结合广告投递的案唎该案例中，BI系统分析出已消费的人群标签然后接入三方广告平台平台，进行精细化、自动化广告投放该案例不仅仅是分析数据，還深入到了解决问题的层次

一个完整的行业背景下的BI系统，应该具有哪些功能如下脑图：

作者：产品小思考，B端产品经理微信公众號：产品小思考

本文由 @产品小思考 原创发布于人人都是产品经理。未经许可禁止转载