天天点外卖，你知道百度外卖的流量分析是怎么做的吗？

大家晚上好，我是百度外卖大数据研发中心的研发工程师龚廖安，我2013年11月加入百度，2015年11月加入百度外卖，一直从事大数据相关的研发工作，现负责百度外卖大数据产品方向的整体研发工作。今晚非常荣幸地给大家介绍Apache Kylin在百度外卖流量分析平台的应用与实践。

本次课程的内容包括流量分析的数据问题、技术选型、Apache Kylin解决方案、Kylin在百度外卖的其他应用场景这四个章节。

首先，我们将看看流量分析所面临的数据处理的技术难点有哪些；其次，针对上述技术难点，我们是怎么进行技术方案的尝试和选型，并最终选择Apache Kylin作为数据问题的解决方案；然后，将具体介绍怎么通过Kylin数据建模，解决流量分析中的数据问题；最后，我们将看看Kylin在外卖其他大数据场景中的应用。

01

好，接下来我们开始的第一章节的内容。

在这一章节，我们将直面流量分析的数据问题。主要内容包括两部分：第一，我将给大家介绍什么是百度外卖的流量分析平台，了解流量分析的业务场景。第二，在了解业务场景后，再看看我们将要面对的数据问题有哪些？

流量分析平台是通过对进入百度外卖App的流量从路径、大区、城市、商圈、终端、版本、渠道等多个维度进行分析，帮助活动运营、渠道运营、产品经理、产品运营、大区经理等角色更好的了解其业务的流量情况，从而进一步优化业务。

在流量分析平台中有一个非常重要的概念，就是路径。什么是路径呢？路径就是用户在百度外卖App里浏览所走过的页面、频道、位置、内容、按钮等。

下面给大家举一个路径的例子：一个用户通过点击百度外卖首页的八大金刚（餐饮）进入了频道二级页面，在频道二级页面的banner中选择了一个商户进入这个商户的点菜页。点完菜后点击“选好了”按钮，进入订单页，并点击“去支付”按钮提交订单。那么这个用户的路径就是：首页八大金刚餐饮->频道二级页banner->点菜页选好了->订单页提交订单。这是一个用户从进入百度外卖到最后下单的完整路径。

用户的路径在我们的后台系统中是怎么记录的呢？首先在用户端，我们会进行日志埋点，用户浏览后会生成相应的日志，然后通过我们的日志流式ETL过程将用户浏览的路径存入数据仓库中。

刚才例子中的路径在我们的数据仓库中是怎么记录的呢？首页八大金刚的首页对应P01，八大金刚对应position_group为A-3，餐饮对应的content_id为A0001。频道二级页banner对营的页面为p02，positon_group为B-1，点菜页选好了对应的页面为P05，position为E-0-1，订单页提交订单对应的页面为P08，position为H-0-1。在我们的数据仓库中，会把这些字段按列存储在对应的表中。

我们记录用户路径深度的级数有Me+p01~p08，总9级，Me是记录用户当前所在的页面，且每一级又有position_group、positon_id、content_id和content_type这4中类型，所以路径维度字段有36个。可以说标示路径的维度是非常多的。

了解完路径后，我们看看流量分析平台要做哪些事情呢？

流量分析平台对流量的分析有下面这些需求。我们分析的粒度在时间和空间上要分别细化到小时和商圈。分析的种类包括漏斗分析、趋势分析、数据对比、分布分析等。路径可以分析到全量路径。

下面这张图是流量分析平台的界面，可以看到进行的漏斗分析和趋势分析。

在了解了业务场景后，我们看看流量分析平台面临哪些挑战。总的来说，流量分析平台面临的问题主要是数据生产和查询速度的挑战。

首先是数据维度多，在流量分析中，基础维度有9个，路径维度36个。（基础维度主要是时间、城市、商圈、版本、渠道等）。

第二：数据量大，流量分析每天依赖的基础日志数据有2.5亿行。常用路径每天生产的数据是700w行，全量路径每天要生产2亿行，并且需要保留最近3个月的数据，总的数量达到百亿级别。

第三：查询场景多，刚才说到流量分析的场景非常多，每种场景对数据的要求和分析角度都是不一样的。漏斗分析关注的是路径维度的pv/uv，订单、流水的趋势分析关注的是订单、流水在时间上的变化，数据对比关注的是同样的指标和上周同期的对比。

此外，流量分析的维度可以自由选择，这样使得查询场景更难固化。当然每种查询场景都可以通过定制化的SQL来聚合计算，但场景非常多，如果只是在应用层去适配，开发成本太高。

最后是对查询速度的要求，流量分析平台要给用户提供在线查询服务，响应速度需要秒级别，太慢了用户是接受不了的。

02

下面我们看到第二章节。这一部分主要介绍我们针对流量分析平台中遇到的数据问题怎么进行尝试和技术选型，最终选择Kylin作为问题的解决方案。这一章节分为两部分，第一部分是我们在中间表方案中进行的尝试，第二部分介绍两种MLOAP查询引擎，Kylin和Druid的对比。

针对数据产品中比较固化且需要秒级响应的查询场景，我们一般的解决方案是每天凌晨对前一天的数据在数据仓库中，通过Impala/Hive对数据进行聚合，并将聚合后的表导入到Mysql或Greenplum，即GP中进行查询。

针对流量分析平台的数据场景，我们最初也是这样进行尝试的。但流量分析平台的数据量大、维度多、查询场景复杂，我们也对中间表方案进行了一些改造，以解决数据生产过程成本高、数据导入慢、数据查询慢的问题。下面将简单讲述我们尝试的三个中间表方案。

方案 1：

通过开放式Sql，利用Impala的计算能力，将基础数据进行聚合并导入到Mysql的一个大宽表中。由于很多指标和维度通过一个Sql计算不了，所以数据会多次插入Mysql，并通过联合主键保证数据不重复。这种方案的优点是数据生产过程简单、查询条件简单、查询速度满足要求。

但这个方案的问题有3个：1、维度组合导致数据量大，数据生产插入Mysql慢，插入需要半小时以上，当然这个时间还是可以接受的。2、由于Mysql主键数量的限制，导致方案不可行。我们这里有近40个维度需要去重，但我们使用的Mysql只能支持16个主键。

方案2：

下面我们看看方案2。方案一的主要问题是主键太多，为什么联合主键会这么多，主要是路径维度太多，但其实每个路径用的的维度不会这么多。所以我们就考虑是不是可以根据路径对数据生产过程进行拆分，每个路径对应一个数据生产过程，这样维度数就能够满足联合主键数量的限制。

所以我们对方案1进行了改造，每条路径对应一个中间表，各个不同的路径并行插入，提高数据插入效率。但这个方案也有问题，就是如果路径太多，则中间表的数量也会很多，导致数据生产的维护成本太高，如果后面要做全量路径的话，那中间表几乎是不可维护的。由于中间表数量大，数据重复，导致Mysql的空间不够。

由于流量分析平台前期分析的路径是有限的，所以当时的问题主要是集中在Mysql存储空间和数据写入的效率上，所以我们继续尝试一种直接在集群内部进行数据生产的方案。

方案3去掉了Mysql的存储。中间表用Impala生产后存放在集群上，并通过我们的自动同步工具，将中间表同步到GP中，对外提供查询服务。由于Impala没有主键的概念，所以每次生成的数据都会单独生成一个表，还需要对数据进行二次聚合。这个方案数据生产快了很多，但数据生产过程比较复杂，且仍遗留中间表数量的问题。

总的来说，中间表方案的问题有以下几个。

1、流量分析平台维度和指标多，导致数据在数仓中聚合的成本越来越高，开发效率低。2、Mysql性能达不到要求，主要体现在往Mysql中插入数据和查询数据的时间长。3、如果舍弃Mysql，如果用Impala+GP方案生产数据，则流程太复杂。4、UV计算不准确，这个问题是中间表方案无法解决的，因为计算UV需根据用户进行去重，但我们的中间表的聚合不能做到用户级别的中间表，如果做到用户级别，那就是明细数据了，所以用中间表的话，我们无法对用户去重来计算UV，只能做简单的加和，从而导致UV不准确。5、中间表方案的查询场景相对固定，查询的数据只能是中间表预先设定好的数据，如果有新的数据查询场景在中间表中不能满足需求，则需要开发新的中间表生产流程。

所以，我们需要调研更高效的、满足流量分析平台场景的OLAP引擎。

经过调研，我们发现对OLAP引擎需求主要体现在支持的数据量、查询性能、灵活性三个方面。数据量是指能支持多大的数据量，是百万、千万、亿还是百亿？性能是指对查询请求的响应速度，是毫秒级、秒级、分钟级还是小时级？灵活性是指能够支持什么样的查询需求，明细还是聚合？离线还是实时？是否支持SQL查询？目前业界没有一个查询引擎能在这三方面做到完美，所以需要根据业务场景进行取舍，选择合适的查询引擎。

那么对于流量分析平台，我们的业务场景对这三方面的要求是什么样的？在数据量上，流量分析平台需要的是百亿级别的数据量支持；查询性能要求秒级返回；查询场景是聚合数据；数据不要求实时，离线聚合前一天的数据就可以；最好能够支持SQL查询。

目前主流的大数据查询引擎架构有两种：Mpp架构和预计算架构，Mpp架构的查询引擎有Impala、Presto、Spark，预计算架构的查询引擎有Druid和Kylin。我们看看这两种架构在数据量、性能和灵活性三方面的支持情况。

Mpp架构和预计算架构在数据量上都支持百亿级别的查询。

查询性能上，Mpp架构对查询请求的响应时间没有保证，当数据量和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至到小时级。而预计算架构是在数据入库的时候进行预计算，牺牲了一定的灵活性以换取性能，所以对超大数据集的查询请求响应时间能够稳定在秒级。

在灵活性方面，Mpp架构的灵活性是很强的，支持任意的SQL查询。而预计算架构的场景相对固定，只支持预计算后的数据查询。

从以上分析可以看出，针对流量分析平台的数据查询场景，我们应该选择预计算架构的查询引擎。

现在业界主流的预计算架构的查询引擎是Kylin和Druid，它们都是MOLAP查询引擎，都满足交互式的查询速度需求，都支持大数据量的查询。这两个查询引擎我们又是怎么选择呢？

下面我们将二者进行对比，看看他们之间的差异，哪个更适合流量分析平台的查询场景？

首先，Kylin的应用场景主要是非实时分析，1.5版本后后，通过对接Kafka支持实时分析。Druid则以实时分析场景为主，但也支持非实时分析，但不是主流场景。

在计算方式上，Kylin是利用MapReduce、Spark对数据进行聚合计算，而Druid的计算是在内存中进行的，速度会更快，但需要处理复杂的集群资源调度、容灾容错、数据扩容等问题。Kylin只是专注于预计算的优化、查询的优化等问题，将数据计算的问题交给MapReduce、Spark，存储的问题交给HBase、Hive。

Kylin是原生的支持SQL和JDBC接口的，而Druid需要引入第三方的SQL引擎。

Kylin1.5.3开始基于bitmap支持精确count distinct计算方式。Druid不支持精确的count distinct，使用HyperLogLog或datasketches实现近似count distinct，可以调节datasketches算法的参数使值越来越精确，但资源消耗非常严重。

Kylin回溯历史数据非常简单，只需要重新刷新立方体对应的Segment就行，Durid由于支持实时场景，回溯相对复杂一些，在index server出现后，解决了近期数据回溯的问题。

Kylin由于要预计算维度组合并存储，以空间换时间，维度膨胀比较严重，而Druid是通过建索引的方式将数据转化为Segment，所以进行无维度膨胀的问题。

从以上对比可以看出，Druid主要面向的是实时数据的场景，但流量分析平台主要是按天进行数据聚合，且使用更加方便，因此Kylin比Druid更适合作为流量分析平台的查询引擎。

下面给大家简单介绍一下Kylin。

Apache Kylin是一个开源的分布式分析引擎，在Hadoop之上提供超大规模数据的SQL查询接口及多维分析能力，最初由eBay开发并贡献到开源社区，能为巨大Hive表提供亚秒级别的查询响应。

Kylin的架构如图，核心思想是对Hive中的数据预计算，利用Hadoop的MapReduce对多维分析可能用到的维度和指标进行预计算，将计算的结果保存成Cube并存在Hbase中，提供查询时的直接访问。Kylin把高复杂度的聚合计算、多表连接等操作转换成对预计算结果的查询，使其能够拥有很好的快速查询和高并发能力。

此外，Kylin还提供标准SQL查询，友好的web页面进行Job管理和监控，数据压缩编码和方便的增量刷新和数据回溯功能。总的来说就是非常好用。

03

好，接下来，我们将看看具体的解决方案。本章节将介绍怎么用Kylin对流量分析平台的数据进行建模，并最终满足流量平台的数据需求。该章节分为降维、事实表生产、立方体配置、立方体构建这四个部分。

降维将介绍我们如何对路径维度进行维度聚合，并利用kylin提供的维度优化方案对维度进行优化。事实表生产将介绍用户浏览路径事实表fact_flow的每天例行生产过程。立方体配置将具体介绍流量分析平台的数据立方体是怎么配置的。立方体构建将介绍怎么进行立方体数据的增量更新、Segment合并和数据清理。

在我介绍具体的实践方案之前，我们先看一下利用Kylin进行流量分析平台数据生产的总体架构。

我们从下往上看，在集群上，存放的是流量分析平台依赖的明细数据，包括订单、sak日志、详情日志、商圈、城市信息等。我们每天利用Impala的计算能力，通过ETL例行生产用户浏览路径事实表的数据，并存放在Hive中。我们采用的是星型模型，有一个dim_path的维度表，用于存放路径信息。Kylin根据立方体配置的Schema，每天例行构建立方体数据，并存放在Hbase中。流量分析平台通过Kylin提供的JDBC接口，用SQL查询数据并进行展示。

根据之前的讲述，流量平台的维度有40多个，如果直接用这40多个维度进行建模，那维度组合的数目将有2的40多次方，数据膨胀会非常厉害。所以，用Kylin进行数据建模的第一步就是要进行降维。

流量分析的数据为什么有这么多维度呢？其实主要是路径维度太多，有36个路径维度。经过分析，可以将这36个路径维度可以聚合成一个路径ID，一个路径ID表示一种路径，路径的具体信息存放在路径维度表中，事实表通过路径ID和维度表关联。我们经常关注的路径只有几百个，所以这个维度的基数不会太大。通过路径维度聚合，流量分析平台的维度数量降为11个，这样维度组合就不会太多。

此外，我们还通过Kylin提供的立方体维度优化方案对立方体的维度进行优化，进一步减少维度组合的数目。

Kylin有5种立方体维度优化方案，维度聚合组、必选维度、层级维度、联合维度、派生维度。

维度聚合组：是对维度进行分组，以降低维度组合数目。如果有n+m个维度，如果将n个维度分为一组，m个维度分为另一组，则维度组合从2的n+m次方降为2的n次方加2的m次方。

必选维度：指所有的cuboid都包含的维度，每加一个必选维度，维度组合的数目就减少一半。

层级维度：指一系列具有层级关系的维度组成一个层级维度，设置了层级之后，对Cuboid增加了约束，低Level的维度一定要伴随高Level的维度出现，从而使维度组合大大减少。

联合维度：当有些维度始终在一起时，可以将这些维度设为联合维度。则任何有效的Cuboid要么不包含这些维度，要么包含所有维度，这些维度始终在一起，从而降低维度组合的数目。如果有n+m个维度，如果将m个维度配置成一个组合维度，则维度组合从2的n+m次方降为2的n+1次方。

派生维度：派生维度是针对维度表的，如果某张维度表有多个维度，如果该维度表一个或者多个列和维度表的主键是一一对应的，则可以将这些维度设置为派生维度。这样在Kylin内部会将其统一用维度表的主键来替换，以降低维度组合的数目。但查询效率会降低，因为Kylin在使用维度表主键进行聚合后，查询时需要再将主键转换为真正的维度列返回给用户。

在流量分析平台的立方体模型中，由于查询场景会涉及到所有维度，所以无法将维度分组，我们只建了一个维度聚合组。但采用了必选维度和层级维度这两种优化方案。INDEX_DAY（日期）和PATH_ID（路径ID）是必选维度，REGION_ID（大区ID）、CITY_ID（城市ID）、AOI_ID（商圈ID）是层级维度。同时维度表里的路径名称和路径编码采用的是派生维度。

确定流量平台数据的降维方案后，下一步就是进行流量平台基础数据的生产。流量平台采用的数据模式是星型模型，包括一个事实表fact_flow和一个维度表dim_path。维度表相对固定，不需要每天更新，手动生成一次就可以了。事实表fact_flow需要每天例行更新，该表是调度系统在每天凌晨从基础的订单、sak日志、日志详情表，通过ETL过程例行生产的，并将数据存放在Hive中。

该表包括的维度字段有：path_id、区域id、城市id、商圈id、来源、app版本、app渠道、小时、订单状态、日期。指标字段包括：用户的cuid、优惠前价格、百度补贴、商户补贴、代理商补贴、订单id。

下面我们看看流量分析平台的立方体是怎么配置的？这里我们只介绍几个关键步骤的配置，包括：模型配置、维度配置、指标配置。首先需要在Model里配置星型模型，通过path_id将事实表和维度表关联起来。

下一步进行维度配置，维度配置在立方体配置里进行，事实表里的维度的类型都是normal类型，维度表里的维度配置成derived类型，流量分析平台有10个normal维度、2个derived维度。

最后进行指标配置，我们这里配置的指标包括PV、UV、优化前流水、百度补贴、商户补贴、代理商补贴、订单量。PV通过count来计算。UV需要做去重，通过对cuid进行count distinct来计算。其他指标都是sum求和来计算。

立方体关键的配置步骤就完成了，后面就绪进行例行增量构建。

由于我们每天都会产出新的基础数据，立方体的数据也需要不断更新，这里我们通过增量构建的方式将每天新生成的数据加入到立方体中提供给流量分析平台查询。

Kylin会将Cube划分为多个Segment，每个Segment用起始时间和结束时间来标志。

Segment代表一段时间内数据的计算结果，一个Segment的起始时间等于之前一个Segment的结束时间。在同一个Cube下，不同Segment的结构定义、构建过程、优化方法、存储方式都是一样的。

从图中我们看到，每天早上7点多，会进行立方体构建，每次构建前一天产生的数据。通过百度外卖的调度系统，在依赖的fact_flow数据生产好后，自动调用Kylin的restfulAPI接口进行立方体的构建。

增量构建虽然好用，但也存在一个问题，就是增量构建会使Segment碎片太多，导致Kylin的查询性能下降，我们通过对Segment进行合并和清理来解决。Segment合并是将几个Segment合并到一起，清理是将无用的Segment删除，从而减少Segment的数量。合并和清理我们是通过配置立方体的自动合并门限和Segment保留门限来实现的。

如图所示，在立方体配置的Refresh Setting配置页中，我们将Segment自动合并门限配置成7，则每7天的Segment会合并在一起。Segment保留门限配置成100，则我们只保留100天左右的Segment。如果一个Segment的结束时间距离最晚一个Segment的结束时间大于这个门限，则这个Segment就会自动从立方体中删除。

至此，整个流量分析平台的数据建模的过程都介绍完了。

通过用Kylin进行数据建模，解决了流量分析平台数据的问题，那么下一步在流量平台上，我们还有哪些深入的应用呢？首先是全量路径，目前我们的路径维度里只有常用的几百个路径，后续我们会考虑将全量路径，分析流量的桑基图、用户也可以自定义路径进行分析。要做全量路径的话，另一个挑战就是路径维度的基数会很多，可能会有70+万种组合，需要进一步对路径维度进行优化。

另一个应用就是进行分布分析，目前的分析主要是对路径进行漏斗分析，后续会从城市、版本、渠道、商圈、入口等多个维度的流量分布进行分析，主要分析的指标包括：订单UV、进店率、完成单转化率、订单数、完成订单量、商户补贴等。

04

在第4部分，我们将介绍Kylin在百度外卖大数据部的其他应用。本章将主要介绍怎么将Kylin接入百度外卖的报表系统。

下面我们先来看看整个报表系统的架构。百度外卖大数据部有自己的一个基于Saiku+Mondrian+Impala的报表系统，我们计划增加一个Saiku+Mondrian+Kylin架构的报表系统。通过数据建模，用户可以在Saiku前端拖拽需要的指标和维度，产出自己想要的报表。Saiku将用户拖拽的指标、维度生成mdx语句，Mondrian将mdx转换成Sql提交给查询引擎进行查询，Saiku将查询的结果拼装成用户定义的表格返回给前端进行展示。

之前的报表系统的查询引擎对接的是Impala，优点是灵活，可以支持各种类型的sql查询，但问题是用户的查询多了就会给Impala造成非常大的压力，影响Impala每天例行的生产任务。且如果Sql比较复杂，Mpp架构的查询引擎返回的时间会比较长甚至出错，数据查询效率较低。所以可以接入Kylin作为查询引擎，为一些场景比较固定的查询提供服务，一方面减少了集群压力，另一方面能提高查询速度。

在对接Kylin的过程中，主要有三个技术难点需要解决：1、Saiku+Mondrian对接Kylin；2、数据建模；3、Saiku的改造。下面我们将主要介绍这三个问题我们是怎么解决的。

下面我们先看看Mondrian是怎么和Kylin对接的？我们对接的版本是Mondrian4.4和Kylin2.0，在对接过程中主要解决了以下几个问题。首先是在Mondrian源码中增加对Kylin方言的支持，在git上有一个整合Kylin、Mondrian和Saiku的开源项目，参考这个项目的指引，可以轻松搭建Mondrian+Kylin+Saiku的系统，这里要感谢项目的作者mustangore。

但git上的开源项目有一个bug，当我们需要进行count distinct查询的时候，会报错，Mondrian生成的Sql语法存在问题，在Kylin里查询的时候报错了。有赞技术团队给出了问题的解决方案，可以通过修改Mondrian的Kylin方言补丁和Mondrian的源码搞定。

在对接Mondrian过程中，还发现Kylin2.0存在一个数组越界的bug，该bug已经在kylin2.1版本中解决，如果未升级到2.1版本，可以参考我在kylin社区上提供的解决方案。

我们还对Mondrian4.4进行了一些改造，主要解决了Mondrian4.4的Schema对接Kylin兼容View的问题和Mondrian4对left join的支持。第一个问题是在获取表结构的时候有字段未获取到导致的报错，通过修改Mondrian获取表结构的流程来解决这个问题。第二个问题由于Mondrian只支持inner join，这样的话如果用inner join在Kylin中进行数据建模，当两个表有字段匹配不上时，会导致数据缺失，比如事实表存在空字段而维度表没用空字段。如果要解决这个问题，可以在基础数据中把空字段补上或者在Hive中建视图来补空字段，但由于涉及的表非常多，改造成本太高。如果Mondrian能支持left join，则可以一次性彻底解决这个问题。这可以参考git上的解决方案。

此外我们还进行Mondrian3对接Kylin的改造，主要问题当需要做表关联时，Mondrian3生成的Sql在语法上Kylin不支持，如果要支持的话，改造成本非常高，所以舍弃了这个方案。

下面继续看看数据建模和Saiku改造的问题。数据建模需要解决的3个问题。首先需要将我们之前的Mondrian3的Schema升级到Mondrian4的Schema。Mondrian3和Mondrian4的Schema配置差异是比较大的，其实Mondrian4在程序内部能自动将Mondrian3的Schema进行升级，但升级过程中容易出错，且升级后的Schema在和Kylin进行兼容的时候存在问题，比如我们在Mondrian3里面使用了很多View的配置，升级后生成的Sql在Kylin中查询就不了。所以我们只能自己开发工具将Mondrian3的Schema进行升级到Mondrian4的Schema。

第二个问题是兼容View的问题。由于我们之前用Impala作为查询引擎，可以支持非常灵活的查询Sql，所以在Schema里配置了很多View的查询场景。但用Kylin进行建模的话，由于Kylin不能支持那么灵活的Sql，查询的数据只能是已经建模好的数据，所以很多基于View的查询是不能支持的，虽然我们通过对Mondrian4的改造支持了View查询，但这些View在Kylin中还得进行建模，过程非常复杂，所以我们只能进一步降低灵活性，对规范底层的数据进行建模。将Schema中使用到的View先在Hive中创建相应的视图，用这些视图在Kylin中构建立方体。这样能较低成本解决通过View查询的问题。

第三个问题是维度分组。之前用Impala查询，无维度膨胀的问题，所以我们有一些立方体配置了一百多个维度，而这种场景如果在Kylin中建模，则维度膨胀会非常严重，此时需要根据业务场景对维度进行分组，拆分成小的立方体进行查询。

Saiku3.14改造，这里主要是解决用户访问权限和用户指标权限的问题。这两个问题都可以通过修改Saiku的源码来解决。第二个问题还需要改造Saiku3.14存放Schema文件的方式，Saiku3.14默认将Schema配置文件和Saiku文件存在本地的一个叫Jackrabbit的文件数据库中，我们需要将其改造成存放在Mysql中，并解析Mondrian4的Schema得到指标，和之前报表系统的权限控制系统打通来进行指标权限控制。

在解决了以上问题后，下面给大家展示一下接入Kylin的报表系统。这是Saiku3.14的前端，通过拖拽左边的指标和维度，能够在右边立刻生成我们需要的报表，这里查看的是两天分城市的月流水，和订单数据，在几秒之内就能够返回，且不会给集群造成压力。

最后，是问题与答疑时间。大家关于讲到的功能点和解决方案有什么不理解的地方或者更好的建议，欢迎畅谈。