Apache Kylin 实践:链家数据分析引擎

Apache Kylin™ 是一个开源的分布式分析引擎,提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由 eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的 Hive 表。

Apache Kylin
Apache Kylin

其特征包括:

  • 可扩展超快 OLAP 引擎:Kylin 是为减少在 Hadoop/Spark 上百亿规模数据查询延迟而设计
  • Hadoop ANSI SQL 接口:Kylin 为 Hadoop 提供标准 SQL 支持大部分查询功能
  • 交互式查询能力:通过 Kylin,用户可以与 Hadoop 数据进行亚秒级交互,在同样的数据集上提供比Hive更好的性能
  • 多维立方体(MOLAP Cube):用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体
  • 与 BI 工具无缝整合:Kylin  提供与BI工具的整合能力,如 Tableau,PowerBI/Excel,MSTR,QlikSense,Hue 和 KXCY-BD-VIZ(跨象乘云™大数据可视化探索平台)

其他特性还包括:Job 管理与监控 / 压缩与编码 / 增量更新 / 利用 HBase Coprocessor / 基于 HyperLogLog 的 Dinstinc Count 近似算法 / 友好的 Web 界面以管理,监控和使用立方体 / 项目及表级别的访问控制安全 / 支持 LDAP、SSO 等。

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

链家 OLAP 平台及 Kylin 使用

链家 OLAP 平台结构(By 邓钫元),于 2016 年底搭建。Kylin 采用集群部署模式,共部署 6 台机器,3 台用于分布式构建 Cube,3 台用于负载均衡查询,query 单台可用内存限制在 80 G。同时,计算集群一旦运行大任务,内存压力大的时候,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 的设计和存储,根据用户真正的需求,在存储、构建及查询性能间找到最佳的平衡点。