1. 前言

伴随链家业务线的拓宽和发展，以及数据生态的建设，数据规模快速增长。从2015年大数据部门成立至今，集群数据存储量为9PB，服务器规模为200台+。与此同时，数据需求也随着业务的发展落地不断增长，如统计分析、指标API、运营报表等，不同业务需求差异较大，维度越来越多，需要定制化开发。面对数十亿行级别的数据，低延迟响应的特性，保障服务稳定、数据准确，链家的数据分析引擎经历了如下的发展历程。

2. 早期的ROLAP架构

起初，数据规模不大，增长不是很快。而且，数据需求比较零散，处于摸索阶段。采用如下ROLAP引擎，支撑数据分析：

具体处理流程：数据源接入hdfs，加载进hive。数据开发工程师根据业务需求，开发ETL脚本，配置OOZIE任务调度执行，根据数据仓库分层模型，逐层生成数据，最终推送到mysql，根据维度筛选、聚合展示。

随着数据规模的增长和需求的增多，瓶颈逐渐显现。每个需求都要开发数据脚本，维度增加，开发周期拉长，同时需要耗费更多的人力，无法快速产出数据和响应需求变化。

3. MOLAP多维引擎

由于，ROLAP无法实时响应、服务不稳定的问题愈加凸显，因此着手引入MOLAP引擎，搭建平台级的OLAP多维分析服务。
OLAP领域还没有事实上的标准，很多引擎都可做类似事情，如普通的MPP、Kylin、Druid等。技术选型过程中，重点关注了基于MapReduce预计算生成Cube并提供低延迟查询的Apache Kylin解决方案。Kylin最初由eBay开发，并于2014年10月贡献至开源社区，2015年11月正式毕业成为Apache顶级项目，是首个由国内开源的Apache顶级项目。
Kylin支持ANSI SQL大部分查询功能，标准SQL语法+JDBC/ODBC驱动可以很方便的和现有系统做集成；用户可以与Hadoop数据进行亚秒级交互，随着数据量和维度组合的增长，性能衰减也不会特别明显；Cube模型的合理设计，并支持增量更新；同时，具备良好的可伸缩性，核心组件可扩展，社区活跃。可以在数据准确度、存储空间、性能之间灵活调整，找到最适合需求场景的平衡点。

4. Kylin基本原理

通过上面章节的分析，我们对在线DDL的实现有了一定了解，在了解其优势的同时我们还应该了解一些问题和限制，以方便我们后续遇到此类问题时有更全面的考虑。

如下，为Kylin架构图：

Kylin数据源常采用Hive，使用MapReduce作为Cube构建的引擎,预计算结果存入HBase,对外暴露Rest API/JDBC/ODBC的查询接口。因为Kylin支持标准的ANSI SQL，所以可以和常用分析工具（如Tableau、Excel等）进行无缝对接。
Data Cube，代表数据立方体。包含维度和指标，由不同维度构建出的多维空间，包含了所有要分析的基础数据，所有的聚合数据操作都在立方体上进行。Kylin的核心思想是预计算，对多维分析可能用到的度量，基于维度组合做预计算，计算结果保存成Cube。把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询，通过空间换时间，获得快速查询和高并发能力。
Kylin有两种预计算方法：一、计算出最底层的cuboid，也就是包含全部维度的cuboid（相当于执行一个group by全部维度列的查询），然后在根据最底层的cuboid一层一层的向上计算，直到计算出最顶层的cuboid（相当于执行了一个不带group by的查询）；二、Fast Cubing，在采用逐层计算时，由于Mapper不做预聚合，即便经过Combinder，但是依然要通过Reducer做聚合，期间不断的写入和读取hdfs，耗费集群资源和耗时。fast cubing算法最大化利用Mapper端的CPU和内存，对分配的数据块，将需要的组合全部计算出，再由Reducer再做一次合并（merge），经过一轮Map-Reduce，便可计算出完整数据的所有组合。Fast Cubing原理，如下图：

5. 链家Olap平台及Kylin使用

如上，为链家Olap平台结构，于16年底搭建。Kylin采用集群部署模式，共部署6台机器，3台用于分布式构建Cube，3台用于负载均衡查询，query单台可用内存限制在80G。同时，计算集群一旦运行大任务，内存压力大的时候，HBase 就会性能非常差，为避免和计算集群互相影响，Kylin集群依赖独立的Hbase集群。同时，对Hbase集群做了相应的优化，包括：读写分离、SSD_FIRST 优先读取远程SSD、并对依赖的hdfs做了相应优化。

由于Kylin只专注预计算，不保存明细数据，对于即席查询和明细查询，通过自研QE引擎实现，底层依赖spark、presto、hive，通过特定规则，路由到相应查询引擎执行查询。多维分析查询，由Kylin集群提供查询服务，可实现简单的实时聚合计算。
当前Kylin主要查询方为指标API平台，能根据查询sql特征，做相应缓存。指标API作为数据统一出口，衍生出其他一些业务产品。使用统计，如下：Cube数量500+，覆盖公司12个业务线。Cube存储总量200+TB，数据行万亿级，单Cube最大40+亿行。日查询量27万+，缓存不命中情况下，时延<500ms(70%), <1s(90%)，少量复杂sql查询耗时10s左右。

6. Kylin应用场景及使用规范

适用场景：数据规模大，非实时，目前能支持小时级别；维度组合和查询条件组合在可预见的范围内；查询条件扫描范围不会太大；不适合需要大范围模糊搜索排序的场景（类似Search）。
如何能规范的使用Kylin很重要，在Kylin建设初期，踩过很多坑。并不是程序的错误，而是未能详细了解Kylin使用流程及规范，逐渐摸清积累了一些经验，沉淀到公司wiki，供相关人员参考。大致如下：

维度优化，预计算的结果需要存储到hbase，且支持实时查询，因此，在配置维度时，要考虑到存储和查询的优化。包括：维度的编码，根据维度的值类型，选择合适的存储类型，可节省空间，加快hbase scan效率；可根据业务需要，对维度进行分片存储，增加查询的并发度，缩短查询时间；基数允许范围内的维度，尽量采用字典编码；对于分区字段，一般格式为yy-MM-dd hh:mm:ss，若只需要细化到天级别，可保存为数字类型yyMMdd，极大降低维度基数。

根据hbase的查询特性，rowkeys是由维度组合拼接而成，因此要考虑到以后查询场景：对于查询频繁的维度，在设置rowkeys时，优先放在前面。

维度组合优化，由于维度的组合影响最终的数据量，因此如何能减少维度的组合，是Cube配置时所要考虑的。根据业务需要，及Kylin支持的特性，可进行的维度组合优化有：使用衍生维度，只物化维度表的主键，牺牲部分运行时性能进行实时join聚合；使用聚合组，将相关维度内聚成一组，并在聚合组内，根据维度的特征，配置强制维度、层级维度、联合维度。聚合组的设计可以非常灵活，例如，高基数的维度，可以单独一个group。

及时清理失效数据。由于构建过程出错或者集群故障，会导致一些垃圾文件，随着时间积累的一些无用segment，不但占用存储空间，增加namenode内存压力，以及占用hbase、hive及kylin元数据空间，因此需要定期清理掉，保持存储环境干净。

应该实时监控集群状态，重点关注Cube构建和查询的低延迟，不断优化数据模型及Cube的设计和存储，根据用户真正的需求，在存储、构建及查询性能间找到最佳的平衡点。

7. 链家Kylin能力扩展

当前，kylin在用版本为1.6，最新版本为2.3。自2.0版本之后，又新增了一些新的特性，配置文件和属性也做了一些调整。由于，Cube数据量大，涉及业务方多，在当前无明显瓶颈的情况下，没有实时更新新版本。但是，引入了2.0+新增的一些重要特性，如分布式构建和分布式锁。
我们维护了自己的一套Kylin代码，使用过程中，针对特定场景的进行一些优化开发，包括：

支持分布式构建。原生kylin是只能有一台机器进行构建。的当kylin上的cube越来越多，单台机器显然不能满足任务需求，除了任务数据有限制，任务多时也会互相影响数据构建的效率。通过修改kylin的任务调度策略，支持了多台机器同时构建数据。使kylin的构建能力可以横向扩展，来保证数据构建；

优化构建时字典下载策略。原生kylin在build cubiod data时用的字典，会将该字段的全部字典下载到节点上，当字段的字典数量很多或者字典文件很大时，会在文件传输上消耗很多不必要的时间。通过修改代码，使任务只下载需要的字典文件，从而减少文件传输时间消耗，加快构建；

全局字典锁，在同一Cube所任务构建时，由于共享全局字典锁，当某执行任务异常时，会导致其他任务获取不到锁，此bug已修复并提交官方；

支持设置Cube强制关联维表，过滤事实表中无效的维度数据。kylin创建的临时表作为数据源。当使用olap表和维表关联字段作为维度时，会默认不关联维表，直接使用olap中的字段做维度。而在Build Cube这一步又会使用维表的字典来转换维度的值。如果olap中的值维表中没有就会产生问题。我们通过增加配置项，可以使kylin强制关联维表，来过滤掉olap表中的脏数据；

Kylin query机器，查询或者聚合，会加载大量的数据到内存，内存占用大，甚至存在频繁Full GC的情况。这种情况下，CMS垃圾回收表现不是很好，因此更换为G1收集器，尽量做到STW时间可控，并及时调优。

除了上述对kylin本身的修改外，我们开发了kylin中间件实现了任务调度、状态监控、权限管理等功能。

8. Kylin中间件

中间件承接Cube管理及任务的调度，对外屏蔽了Kylin集群，架构图如下：

可实现如下功能增强：

理论上，可实现无限容量队列，现实中不会有这么大任务量，也不会一直堆积；

同时，针对特定的Cube，实现优先调度，保障重要数据的及时产出；

元数据管理平台，可通过中间件执行sql查询，而指标API平台，需要预先在元数据管理平台配置API查询接口，配置时可看到自身权限对应的数据，由此实现权限的管控；

当任务执行失败，可进行有限次数重试，重试不成功会报警；

同时，可实现并发控制，由于Kylin集群的承载能力有限，过多的任务同时执行，会造成大量任务失败，目前设置最多提交50个构建任务同时运行。

9. 总结

未来，我们会持续跟踪业务需求，不断优化集群性能，提升集群稳定性和易用性。并重点关注大结果集查询性能、Spark构建引擎、任务资源隔离等。

链家网大数据架构团队负责公司大数据存储平台、计算平台、实时数据流平台的架构、性能优化、研发等，提供高效的大数据OLAP引擎、以及大数据工具链组件研发，为公司提供稳定、高效、开放的大数据基础组件与基础平台。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/GHgJRVkU3hsrSLy-Rhviwg

创作场景

Apache Kylin 在链家的实践