Apache Kylin实践:链家数据分析引擎的演变史

  UCloud 对用户了一系列可自助服务的 API,自身服务与用户业务都同样依赖这些 API 的可用性,从介绍我们微服务体系的变迁和高可用方案开始,再说到灰度发布方面的实践。

  本次的《中国顶尖技术团队录》第十一季挑选的17个团队虽然都来自互联网企业,却是风格各异。希望通过这样的记录,能够让一家家品牌背后的技术人员形象更加鲜活,让更多人感受到他们的可爱与。

  链家网工程师,大数据架构团队,目前主要负责 OLAP 平台建设及大数据应用拓展。

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

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

  当前 Kylin 主要查询方为指标 API 平台,能根据查询 SQL 特征,做相应缓存。指标 API 作为数据统一出口,衍生出其他一些业务产品。使用统计,如下:Cube 数量 350+,覆盖公司 12 个业务线。Cube 存储总量 200+TB,数据行万亿级,单 Cube 最大 40+ 亿行。日查询量 27 万 +,缓存不命中情况下,时延500ms(70%), 1s(90%),少量复杂 SQL 查询耗时 10s 左右。

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

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

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

  当前,Kylin 在用版本为 1.6,最新版本为 2.3。自 2.0 版本之后,又新增了一些新的特性,配置文件和属性也做了一些调整。由于,Cube 数据量大,涉及业务方多,在当前无明显瓶颈的情况下,没有实时更新新版本。但是,引入了 2.0+ 新增的一些重要特性,如分布式构建和分布式锁。

  我们了自己的一套 Kylin 代码,使用过程中,针对特定场景的进行一些优化开发,包括:

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

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

  七、Kylin query 机器,查询或者聚合,会加载大量的数据到内存,内存占用大,甚至存在频繁 Full GC 的情况。这种情况下,CMS 垃圾回收表现不是很好,因此更换为 G1 收集器,尽量做到 STW 时间可控,并及时调优。除了上述对 Kylin 本身的修改外,我们开发了 Kylin 中间件实现了任务调度、状态、权限管理等功能。

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

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

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

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