"肖赞@贝壳找房本文根据贝壳找房资深工程师肖赞老师在2020年'面向AI技术的工程架构实践'大会上的演讲速记整理而成。 1 贝壳OLAP平台架的构演化历程 [图片] 如上图所示，贝壳OLAP平台架构的演化历程大致可以分成三个阶段：第一个阶段是从 2015 年到 2016 年，Hive to MyS ...."

Fork me on GitHub

AI架构
本助手集算力、智能于一身，为您提供最精彩全面的人工智能技术资讯
olap 大数据 • 0 回帖 • 1.5K 浏览 • 4 年前

贝壳找房 | 面向 AI 技术的贝壳 OLAP 平台架构演进

肖赞@贝壳找房

本文根据贝壳找房资深工程师肖赞老师在2020年"面向AI技术的工程架构实践"大会上的演讲速记整理而成。

1 贝壳OLAP平台架的构演化历程

如上图所示，贝壳OLAP平台架构的演化历程大致可以分成三个阶段：

第一个阶段是从 2015 年到 2016 年，Hive to MySQL的初期阶段，这是一个无到有的阶段；
第二个阶段是从 2016 年到 2019 年初，基于Kylin的OLAP平台建设阶段，这个阶段围绕着 Apache Kylin引擎构建OLAP 平台；
第三个阶段是从 2019 年初到现在，灵活支持多种OLAP引擎的OLAP平台建设阶段，这个阶段解耦了OLAP平台与Kylin的强绑定，具备灵活支持Kylin之外多种不同OLAP引擎的能力；

首先是第0阶段 - Hive2MySQL初期阶段

在这个阶段，数据处理流程比较简单，数据包括日志、Dblog等，经过Sqoop批量或Kafka实时接入大数据平台HDFS里，在大数据平台完成ETL处理后，通过大数据调度系统Ooize每天定时写入到关系型数据库MySQL中，然后再以MySQL中的数据为基础产出各种报表。

这是一个从无到有的过程，很多公司初期也都是这么做的。这种方式的优点是简单，很快能够落地跑通，但是问题也很明显：

整个平台受限于MySQL的能力，MySQL无法支持大数据量的快速查询和分析，一般几百万上千万后，MySQL就难以支撑；
这种方式缺少共性能力的沉淀，Case by Case的处理用户需求，需求开发时间长；

这也是我们为什么称为第0阶段，因为这个阶段平台化工作比较少，严格说还称不上一个平台。

随着公司业务的迅速发展，数据应用需求的急剧增加，Hive2MySQL的问题逐步突显，对这种原始架构进行升级改造是一个必然的选择。改造的目标很直接，首先解决MySQL无法支持海量数据分析查询的问题；第二就是要平台化，沉淀共性能力。

对于第一个问题的话，很直接就是引入一个能够支持大数据量的OLAP引擎，这块经过一系列对比调研，选择了Kylin，对于Kylin后面会有介绍；另外，对平台化不够的问题，一方面规范化数仓建模，另一方面引入了一个指标和指标平台，通过指标来向公司各业务线提供数据分析服务。

引入指标，一方面有利于业务方更好地与数仓开发人员进行沟通，业务方给出业务层面的指标定义和口径，然后由数仓开发人员转化为底层数仓表和维度模型（星型或雪花），指标开发完成后业务方使用指标即可，而不是要了解数仓内部技术细节；另外也可以在指标的层面更好的实现复用。

指标是业务单元细分后量化的度量值，包括维度与度量：

维度：观察数据的角度，如时间、地点
度量：需要统计聚合的值，如GMV、带看量

本质上指标是对维度建模（星型或雪花模型）在业务层的抽象。

基于前面所述的思考，就有了第1阶段 - 基于Kylin的OLAP平台架构。

OLAP平台的架构如上图所示，从底向上分为3层：OLAP引擎层，这里就是Apche Kylin；在Kylin之上是指标平台层，它对外提供统一API、指标统一定义和口径管理，支持指标的查询；在最上面是应用层，就是奥丁（这是贝壳内部的一个数据可视化产品）和各种数据应用产品，它们通过统一的指标API来获得数据，不直接使用SQL访问Kylin。另外，Kylin下面的是数据仓库层，里面有ODS、DWD、DWS、OLAP各层数仓表，这里就不仔细介绍了。

下面先介绍一下指标平台层。

首先，先重点介绍一下指标的概念。在前面提到，指标是指是对维度建模（星型或雪花模型）的抽象，指标包括维度和度量，分别对应维度建模中的度量和维度。在这里给了一个指标平台上具体指标的示例，“带看量_集团”指标，可以看到它的度量是对show_num字段count distinct排重计数，支持分公司编码、运营管理大区编码、运营大区编码等将近20个维度。

指标的类型可以分为3类：

原子指标：指标口径管理
派生指标：基础指标 + 业务限定
复合指标：指标间四则运算

所有的指标的定义和口径都是在指标平台进行管理的。各个业务方都主要通过在OLAP平台上定义和使用指标，来实现多维数据分析的。

接下来看一下指标查询，前面有说过，指标平台对外提供统一的API来获取指标数据，上图就是一个指标调用参数示例，参数传到指标平台，指标平台会根据调用参数自动转换为Kylin查询SQL，对Kylin发起查询，获得数据，并根据需求做进一步处理，例如同环比计算、指标间运算等。上图中左边框架的示例调用参数，将转化成对应的Kylin SQL，如右框所示。

接下来看一下指标的应用，可以在奥丁可视化平台中利用指标配置各种报表，也可以自己开发数据应用产品，在产品里调用指标API获取数据。

了解了指标平台后，再看一下Apache Kylin。

首先，为什么选型Apache Kylin。其实很简单，就是因为当时Kylin对平台的几个诉求，如亚秒级响应、支持百亿数据量、支持较高的并发和支持SQL等都有较好的支持。

下面简单的介绍一下Kylin，它是由中国人主导比较成功的Apahce开源项目之一，由国内Kylingence公司提供商业服务。

Kylin的整体架构如上图所示，其核心思想是预计算，对多维分析可能用到的度量进行预计算，用空间换时间。要预算首先需要知道怎么去预计算，也就是需要知道有哪些维度和度量，Kylin 通过要求用户首先定义Cube来获得这些信息，Cube定义支持星型或雪花模型，由Kylin的Metadata模块管理；

定义完Cube后，就通过Kylin的Cube Build Engine模块来进行预计算构建Cube，具体可以通过MR任务，Spark或Flink来实现，完成预计算后结果就存储在HBase中。

最后，用户可以通过Restful接口或JDBC协议利用SQL来查询Cube数据，Kylin的Query Engine模块会把SQL查询自动转化为对HBase的查询。

预计算的一个最大的问题就是“维度爆炸”，也就维度组合太多，Kylin提供了很多优化技巧来缓解这个问题，例如强制维度、层次维度、联合维度等。
其实Cube预计算这种方法并不是Kylin发明的，只是Kylin基于大数据平台来实现了这一套，使得它可以支持海量的数据，而之前没有大数据平台的支持，基于这种预计算方式的OLAP引擎支持的数据量很有限。

这样，在OLAP平台就建立了标准的指标开发流程。整个流程如上图所示。从上面的流程上看：有在Kylin中操作的部分，也有在指标平台操作的部分。这也是为什么说是围绕Kylin来构建的OLAP平台。

经过2，3年的推广应用，指标在公司内部获得广泛的应用。支撑公司整个指标体系的建立，覆盖公司所有的业务线：

6600+指标
日均调用量2000w+
调用3s内返回99.5%

围绕Kylin我们也做了很多工作，主要包括3个方面：

Kylin监控管理平台建设：Kylin 承载着许多指标，其中很多是关键指标，一出问题会影响经纪人整个作业等，因此，需要把监控管理构建好，及时发现和解决各种线上问题；
Kylin优化与定制改造；
Kylin与公司内部大数据系统的整合：和公司大数据系统、元数据管理平台、调度系统等进行整合；

高峰期Kylin平台上有 800 多个 Cube，300 TB 以上的存储量、1600 亿行的数据，单个Cube 最大有 60 多亿，日均查询有2000+万。

这块工作公司其他同事进行过多次分享，此处就不再详述，感兴趣可以去了解一下。

那是不是这样就比较完美了？

在指标大量推广使用后，业务方也反馈了许多的问题。简单总结一下，主要包括以下几个方面。

Kylin支持维度数量有限，而业务方对指标维度数量要求较多，很多指标需要有三、四十个维度，例如上面的示例指标集团带看量就有20多个维度；
没法满足业务需求的快速变更，新开发一个指标、变更指标维度都需要比较长的时间；
全量预计算，构建Cube时间比较长，导致指标产出时间较晚；
灵活性不够，每次修改Cube需回刷Cube，耗时较长；
性能优化，需要熟悉HBase实现细节；
不支持实时指标（Kylin 3.0引入实时指标支持）

那么，该怎么去解决这些问题？经过仔细分析，可以发现这些很多问题都是Kylin本身的原理所决定的，如果只依赖Kylin是没法解决的。因此，单一Kylin引擎无法满足公司不同业务场景下的应用需求，需要针对不同的业务场景来使用不同的OLAP引擎。为了让OLAP平台能够支持不同的 OLAP 引擎，OLAP 平台的架构就要做出相应的升级优化。

这就到了第2阶段- 灵活支持多种OLAP引擎的OLAP平台

这个阶段OLAP平台的架构如上图所示，从底向上分为4层：OLAP层，这里包括Kylin等各种引擎，在OLAP层之上是查询引擎层，它负责为指标平台屏蔽底层OLAP引擎查询接口的差异；再上面是指标平台，它对外提供统一API、指标统一定义和口径管理，支持指标的查询；在最上面是应用层，就是奥丁（这是我们一个数据可视化产品）和各种数据应用产品，它们通过统一的指标API来获得数据，不直接使用SQL访问OLAP。

其中一个关键点就是，由于第2阶段中我们引入指标平台，通过指标API的方式对上层应用提供服务，这样我们可以在用户透明的情况下，扩展更多的OLAP引擎。

下面简单介绍下各层。

首先指标平台层，原来Cube管理这些功能是依赖Kylin的，现在把这部分抽象到指标平台里，也就将Cube定义和管理从Kylin解耦到指标平台里：

参考Kylin、Mondrian等Cube定义
相当于在指标平台和底层OLAP引擎之间引入一个抽象层
可将Cube动态绑定到不同的OLAP引擎

同时引入的查询引擎，它的功能主要包括：

提供统一的数据查询接口（结构化）
屏蔽底层OLAP引擎的差异
实现统一查询请求到对应OLAP引擎查询的转换

因此指标平台仅需要使用QueryEngine的查询接口，不需要关注底层OLAP引擎。除此外，QueryEngine还具备查询优化（把GroupBy转TopN)、缓存、路由、熔断等功能。

上面的例子，同一个调用参数，查询引擎分别生成的Kylin SQL和Druid native查询参数，如上图所示。

这样的在新的OLAP平台上，指标的开发流程如上图所示。所有的步骤都是在指标平台上完成，不再依赖于Kylin 。同时，构建Cube对不同的引擎有不同的含义。例如，对于Druid引擎来说，构建Cube并不会像Kylin一样去枚举维度组合进行预计算，而只是根据Cube中的Join关系生成临时宽表，并将宽表导入Druid。

同时，我们开发一个配套的工具来支持多OLAP引擎指标的开发，包括指标定义、Cube建模、指标加工等。

现在OLAP平台能够灵活地支持不同的OLAP引擎，那该选择哪些OLAP引擎？这就到了第2部分OLAP引擎选型与实践。

2 贝壳OLAP引擎选型与实践

OLAP 选型一般关注三个方面：

数据量：能支持多大量级的数据量，例如 TB 级甚至更大；
查询性能，一是响应时间快不快，是否支持亚秒级响应；二是支持的QPS，在高 QPS 的情况下整个查询的性能怎么样；
灵活性：灵活性没有具体的标准， OLAP 引擎是否支持SQL、是否支持实时导入、是否支持实时更新、是否支持实时动态变更等等，这些都是灵活性的体现，具体需要是根据自己的应用需求来确定；

一般认为，目前没有一种开源OLAP引擎能够同时满足这三个方面，在OLAP引擎选型时，需要在这三个方面之间进行折衷，三选二。

上图中给出了一些常见的开源OLAP引擎。目前开源OLAP引擎数量比较多，往好的说是百花齐放，但其实也说明了这块很混乱。我们对它们进行了一个大概的分类，分类原则第一是看它的架构原理，MPP或批处理等；第二看是否有自定义的存储格式，管理自己的数据，即是否存储与计算分离。

首先是SQL on Hadoop，它又可以分为两类：第一类是SQL on Hadoop – MPP，基于MPP原理实现的引擎，像Presto、Impala、Drill等，这类引擎的特点是通过MPP的方式去执行SQL，且不自己管理存储，一般是查HDFS，支持Parquet或ORC通用列式存储格式；它可以支持较大的数据量，具有较快的响应时间，但是支持的QPS不高，往往具有较好的灵活性，支持SQL、Join等；第二类是SQL on Hadoop – Batch，也就是Spark SQL 或Hive，其原理是把SQLl转换成MR或Spark任务执行，可以支持非常大的数据量，灵活性强，对SQL支持度高，但是响应时间较长，无法支持亚秒级响应；

另外一类是存储计算不分离，即引擎自己管理存储的，其架构可能基于MPP或Scatter-Gatter的或预计算的，这类OLAP引擎的特点是，可以支持较大的数据量，具有较快的响应时间和较高的QPS，灵活性方面各OLAP不同，各有特点，例如，有些对SQL支持较好，有些支持Join，有些SQL支持较差。

了解这些之后，再结合我们的业务需求进行权衡。公司业务方一般对响应时间和QPS要求均较高，所以基本只能在自带存储引擎里的类型中选择。Kylin是已经在用，其他的我们主要关注了Druid，Clickhouse和Doris，其比较如下图所示。