【案例分享】Apache Kylin在链家的实践——链家数据分析引擎的演变史

作者：王龙帅、张如松
作者简介：链家网工程师，大数据架构团队成员，目前主要负责OLAP平台建设及大数据应用拓展。

前言

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

早期的ROLAP架构

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

具体处理流程：数据源接入HDFS，加载进HIVE。数据开发工程师根据业务需求，开发ETL脚本，配置OOZIE任务调度执行，根据数据仓库分层模型，逐层生成数据，最终推送到mySQL，根据维度筛选、聚合展示。
随着数据规模的增长和需求的增多，瓶颈逐渐显现。每个需求都要开发数据脚本，维度增加，开发周期拉长，同时需要耗费更多的人力，无法快速产出数据和响应需求变化。

链家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数量350+，覆盖公司12个业务线。Cube存储总量200+TB，数据行万亿级，单Cube最大40+亿行。日查询量27万+，缓存不命中情况下，时延<500ms(70%), <1s(90%)，少量复杂SQL查询耗时10s左右。

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的设计和存储，根据用户真正的需求，在存储、构建及查询性能间找到最佳的平衡点。

链家Kylin能力扩展

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

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

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

三、全局字典锁，在同一Cube所任务构建时，由于共享全局字典锁，当某执行任务异常时，会导致其他任务获取不到锁，此bug已修复并提交官方（https://issues.apache.org/jira/browse/KYLIN-3087）；

四、当有多台query情况下，元数据同步时，RestClient采用的BasicClientConnManager会遇到并发瓶颈，抛出异常，解决方案为替换成PoolingClientConnectionManager，并提交官方（https://issues.apache.org/jira/browse/KYLIN-2862）；

五、同一Cube构建多个segment时，假如第一次构建的segment时间段晚于第二个segment，会取第一次的last_build_time作为最后一次构建时间，取值错误，已修复提交官方（https://issues.apache.org/jira/browse/KYLIN-2789）；

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

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

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

Kylin中间件

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

可实现如下功能增强：

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

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

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

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

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

总结

Kylin引擎核心组件可扩展，支持超大规模数据，ANSI SQL易用性高，作为链家OLAP平台的关键组件，基本承载了全部的多维分析需求，提升了数据产出效率和查询性能。相比rOLAP架构，现在只需关注基础数据建设和数据探索，节省了大量人力，并提高了整体可维护性。

在OLAP平台建设期间，Kyligence给予我们很大帮助，并和其他公司保持技术交流。Kylin社区很活跃，核心开发团队也非常热心、高效，作为国人主持开源的apache顶级项目，希望Kylin和社区有更好的发展。

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

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