Apache Kylin 在贝壳找房的发展历程

贝壳找房是以技术驱动的品质居住服务平台,聚合和赋能全行业的优质服务者,打造开放的品质居住服务生态,致力于为3亿家庭提供包括二手房、新房、租赁、装修和社区服务等全方位的居住服务,涉及到了居住服务的方方面面。
贝壳找房有 4+ 年的 Kylin 使用经验。从 2016 年下半年开始,当时有一个 Hive + MySQL 的平台,内部代号是地动仪,用来解决业务线的多维分析需求。

apache-kylin-usercase-beike

上图展现了平台数据的流转过程,负责数仓的同学会将数据进行初步的预聚合,再通过关系数据库来提供查询。但是随着数据量的快速增长,查询响应的时间变得越来越长,底层数据库的运维压力也越来越大。为了解决这些问题,同时为了支撑公司的指标体系建设,需要一个既能够支持大规模数据计算,也可以对查询作出快速响应的引擎。

经过调研,从可支持海量数据计算、亚秒级查询响应、支持标准SQL、以及可维护性,涉及的技术栈以及社区活跃度上,Kylin 都符合作为数据引擎来支撑企业指标体系建设的要求。

2017 年 3 月,Kylin 1.6 版本上线,随着指标平台的上线,Kylin 开始对外提供服务;
2017 年底,贝壳已经累计创建了 300 + Cube,每天有 20 多万的查询量;
2018年,升级到 Kylin 2.2 版本 ,支持 Spark 引擎做构建,同时对 HBase 集群做了 T+1 备份。在极端情况下,如果 HBase 集群发生故障,可以把用户的查询请求路由到备用集群里来保障业务正常运行;
2018 年底,贝壳一共有 2 套集群,累计创建了 600+ Cube,每天的查询量达到了 200 万;
2019 年初,我们 Kylin Team 定下了两个 KPI,在机制方面要保障重点数据在每天上午 9 点之前产出,在查询上要达成 3 秒钟内响应占比 99.7%,将 Kylin 升级到 3.1 版本,主要来做实时多维分析的应用。

为了达成这两个目标,在计算方面我们把集群从 1.6.0升级到 2.5.2,引入了 Spark 组件,将重点 Cube 构建的方式从 MR 改为了 Spark。

上图是调优前后的对比,重点 Cube 的平均构建时间从 70 分钟降到了 43 分钟,近 40% 左右的提升;在查询方面也通过一系列的优化,在 12 月就达成了 3 秒内占比 99.7% 的目标。

下图是当时每天的统计数据,到 19 年底贝壳还是两套集群,版本是 2.5.2,累计 700+ Cubes,每天的查询量超过了 1000 万。

apache-kylin-usercase

2020年初,Kylin 升级到 3.1.0,引入了 Flink 组件。

下图是公司的一级指标使用 Flink 组件前后花费时间的对比,可以看到提升比较明显,截止到 2020 年底,贝壳有两个3.1的集群,累计 800+ Cubes,每天的查询量最高超过了 2300 万。

apache-kylin-usercase

总的来说,这几年贝壳找房围绕 Kylin 主要在做平台化的建设。

下图右边最下面是 Kylin 集群,我们把集群的节点分成了 3 种角色,一台 Master 节点,负责接受提交的构建任务和提供元数据查询服务。Master 节点既不参与查询也不参与构建。有多台构建器(Job节点)和查询机器(Query节点)提供服务,这是在集群节点上的划分。集群本身是不对外开放的,通过上层平台提供服务。在平台侧主要是围绕 API、任务、查询、元数据做了一些工作。我们封装了 Kylin 的 API,对创建的 Cube 的流程进行了简化,同时对接了公司的权限体系来对模型进行权限控制。

apache-kylin-usercase

在任务管理上,由平台控制任务的提交,包括任务的优先级,任务的运行数,还有对任务状态的监控和异常数据的报警等。在查询上,包括对 Cube 所在集群的路由,以及对查询的实时监控和分析。在元数据管理上,我们对 Cube 进行了生命周期管理,当符合规则的时候,会启动 Cube 下线的流程。元数据管理还包括对 Cube 在不同集群之间的迁移和集群的版本控制、配置管理等等。

下图展示的是平台里非常有意思的一个功能,叫做 Cube 查询分析,每个小时都会分析一次Kylin的查询日志,统计出这些 Cube 被查询了多少次,有哪些产品使用 Cube 的数据,上面这个图就是一个 Cube 被不同产品查询次数的占比,可以看到这个 Cube 有 7 个产品在用,下面这个图是 Cube 的响应时间在不同范围内的查询次数和占比,可以看到这个 Cube 被查询了69万次,3秒内占比达到了99.99%。

apache-kylin-usercase

我们会解析 Cube 查询解析的每一条 SQL,拿到 SQL 用到的维度组合以及对应的响应时间,下图包括三个方面内容:
- Cube 被使用最多的维度组合排行
- Cube 查询慢的组合排行
- 最近 30 天都没有用到过的维度

apache-kylin-usercase

通过这些数据可以让 Kylin 的用户更好的了解数据的使用情况,也可以根据这些信息做一些针对性的优化,比如在构建和查询方面。
Kylin 在贝壳能高效的运用离不开内部同学的贡献。下图是这几年贝壳找房的同学贡献到社区的一些记录,先后有4位同学向 Kylin 贡献代码,涉及任务调度、Web页面、构建和查询的优化等等多个方面,覆盖了从1.6到3.1的各个版本。

二、Kylin 在贝壳找房指标体系建设过程中的作用

贝壳找房是在 2016 年下半年开始规划指标体系的建设,为了明确指标的定义,统计数据的口径,提高数据的共享性和安全性,同时规划了指标平台来承载指标体系的建设,并且使用 Kylin 来作为指标体系的数据引擎,来提供数据服务。

下图是以 Kylin 为基础的指标平台的架构,通过对数仓数据的建模计算,提供给指标平台使用,指标平台以 API 的方式对外提供服务,API 的基础是指标,业务方定义的 API 可以包含一个或多个指标。

apache-kylin-usercase

下面是基于 Kylin 的指标计算和使用的流程,首先数仓的同学会根据业务过程进行建模,从源数据有一个 ETL 的过程,最后会在 OLAP 层产生一张事实表,接着会在 Kylin 上关联维表创建模型和 Cube,创建完 Cube 后会自动在调度系统生成一个依赖事实表和维表的任务,接着会在指标平台定义指标,配置一下计算方式,支持的维度等信息,创建完指标之后就可以在 API 配置使用,调度系统会根据任务依赖来触发 Cube 的构建,数据构建完之后各种数据产品就可以通过 API 来使用这些数据,这是基于 Kylin 的指标创建和使用的流程。

apache-kylin-usercase

接下来为大家介绍两个指标的例子,两种不同的计算方式,一个是SUM类型,一个是COUNT DISTINCT类型的精确去重。
在贝壳找房指标体系里面,精确去重是非常强的需求,尤其是一些涉及到业绩类的指标,比如经纪人的带看量,精确去重也是 Kylin 的优势之一。

apache-kylin-usercase

上图左右两边是手机端的产品,中间是PC端的报表产品,这几款产品都是通过固定的维度组合来获取相应的指标数据,只需要筛选不同的过滤条件就可以快速获取报表。

另外一种场景就是可以随意进行维度组合的自助分析场景,做一些探索性的尝试,下图是我们公司自研的Odin可视化平台,图左侧两个红框分别是维度和指标,用户可以随意选择他想要的维度和需要的指标,配置筛选条件,右侧的图是根据用户的选择,实时查询Kylin生成的图表,当他确定要使用这些维度和指标之后,就可以把当前的配置保存成固定的报表。

apache-kylin-usercase

不管是固定报表还是自助分析,底层的查询流程是一样的,下图左侧框是业务方发起指标调用的形式,里面的字段是他需要的维度,同时要指定时间范围和过滤条件,发起一次API的调用,中间的框是指标平台,接受API的请求,将API的参数转化为标准SQL,然后提交给Kylin集群执行查询,查询完了之后会将查询结果返回给指标平台,指标平台将数据封装成固定的格式返回给业务方。这就是贝壳找房各种数据产品使用Kylin的底层查询流程。

apache-kylin-usercase

下图展示了目前 Kylin 在贝壳找房的一个使用情况,因为对接了公司的指标体系,所以 Kylin 的使用覆盖了所有的业务线,为超过 30 多个数据产品提供查询服务,支撑了10000+ 指标的计算需求,每天的查询量最高超过 2300万,我们承诺的查询响应时间是 3 秒内占比是99.7%,目前来说 Kylin 都能很好的完成这些目标。

apache-kylin-usercase

对 Kylin 未来发展的展望

对 Kylin 的展望主要是针对 Kylin 4.0,贝壳在 9 月份的时候也做了一次简单的测试,总体来说非常期待 4.0 GA 版本的发布。希望在建模的流程上能够更简化更灵活,比如支持 Schema 的动态更新。在当前的情况下,只要涉及到 Cube 的改动就比较繁琐,希望 Kylin 4.0 能改变这种情况。
关于 Local segment cache,4.0 里面生成的文件是存储在集群上,每次查询都需要实时去读取集群上的文件,同时对集群的资源和性能依赖比较大,可以考虑一下引入为 HDFS 提速的组件,比如 Alluxio,可以将 Segment 的文件缓存到本地来提升查询性能。
关于多租户,希望在查询层面做到对多租户的支持,来避免不同业务之间互相的影响,因为贝壳现在的业务方还是比较多,互相影响的情况也会发生。
关于 Kubernetes,现在的机器数和实例数也比较多,运维的成本比较高,后续会尝试把 Kylin 部署到 Kubernetes 来降低维护成本。

张如松
贝壳找房数据平台高级工程师,负责 OLAP 引擎的开发和维护以及运维指标体系的建设。
标签:
Apache Kylin
指标体系
数据引擎
数据计算
查询相应