Apache Kylin在美团数十亿数据OLAP场景下的实践

共 8014字,需浏览 17分钟

 ·

2020-10-17 03:41

点击上方蓝色字体,选择“设为星标

回复”资源“获取更多资源

大数据技术与架构
点击右侧关注,大数据开发领域最强公众号!

大数据真好玩
点击右侧关注,大数据真好玩!




美团各业务线存在大量的 OLAP 分析场景,需要基于 Hadoop 数十亿级别的数据进行分析,直接响应分析师和城市 BD 等数千人的交互式访问请求,对 OLAP 服务的扩展性、稳定性、数据精确性和性能均有很高要求。本文主要介绍美团的具体 OLAP 需求,如何将 Kylin 应用到实际场景中,以及目前的使用方式和现状。同时也将 Kylin 和其它系统(如 Presto、Druid 等)进行了对比,阐述了 Kylin 的独特优势。


作为公司的平台部门,需要给各个业务线提供平台的服务,那么如何建设一个满足各种需求的公司平台级 OLAP 分析服务呢。首先,一个开源项目在公司真正落地会遇到很多障碍,这主要是由各个业务线不同的数据特点和业务特点决定的,所以本文会介绍一下美团的数据场景有什么特点;其次,针对这些数据特点,尤其是和 Kylin 设计初衷不太相符的部分,有什么样的解决方案;第三,目前 OLAP 领域还没有所谓事实上的标准,很多引擎都可以做类似事情,比如普通的 MPP,Kylin,或者 ES 等。这些系统之间的对比情况如何,应该如何选择,我们也有部分测试数据可以分享;最后,简单讨论一下未来准备在 Kylin 上做的工作。

1 美团的数据场景特点

第一个特点是数据规模和模型特点。一方面从数据规模上来讲,事实表一般在 1 亿到 10 亿量级,同时还有千万量级的维表,也就是超高基数的维表。另一方面,数据模型是一开始遇到的最大困难。因为 Kylin 最初的设计是基于一个星形模型的,但很不幸由于各种原因,很多数据都是雪花的模型,还有其它的模型,比如所谓“星座”模型,也就是中间是两张或者三张事实表,周围关联了其它很多维表。业务逻辑决定了这些数据的关联方式非常复杂,根本无法用经典标准的理论来解释。
第二个是维度。维度最理想的情况是固定的,每天变化的只是事实表。但实际上维度经常会变,这可能和行业特点有关,比如组织架构,相关的维度数据可能每天都会变化。除此之外还可能要用今天的维度去关联所有的历史数据,因此要重刷历史数据,相应的开销也比较大。
第三个是数据回溯的问题。比如发现数据生成有问题,或者上游出错了,此时就需要重跑数据。这也是和经典理论模型有区别的。
维度的角度来看,一般维度的个数在 5-20 个之间,相对来说还是比较适合用 Kylin 的。另一个特点是一般都会有一个日期维度,有可能是当天,也有可能是一个星期,一个月,或者任意一个时间段。另外也会有较多的层次维度,比如组织架构从最上面的大区一直到下面的蜂窝,就是一个典型的层次维度。
指标的角度来讲,一般情况下指标个数在 50 个以内,相对来说 Kylin 在指标上的限制并没有那么严格,都能满足需求。其中有比较多的表达式指标,在 Kylin 里面聚合函数的参数只能是单独的一列,像 sum(if…) 这种就不能支持,因此需要一些特别的解决方法。另外一个非常重要的问题是数据的精确性,目前在 OLAP 领域,各个系统都是用 hyperloglog 等近似算法做去重计数,这主要是出于开销上的考虑,但我们的业务场景要求数据必须是精确的。因此这也是要重点解决的问题。
查询上也有比较高的要求。因为平台的查询服务可能直接向城市 BD 开放,每次会有几十、上百万次的访问,所以稳定性是首先要保证的。第二要求有很高的性能。因为用 Kylin 主要是为了实现交互式的分析,让使用者能够很快拿到结果,所以需要秒级响应。
另外经常会有人问到,Kylin 有没有可视化的前端,在我们内部更多是由业务方来做,因为原来本身就有这样的系统,以前接的是 MySQL 等其它的数据源,现在可以直接使用 Kylin 的 JDBC driver 对接起来。
以上是美团在 OLAP 查询方面的一些特点。在用 Kylin 之前,实际上有一些方案,但效果并不理想。
比如用 Hive 直接去查,这种情况下,第一个是慢,第二会消耗计算集群的资源。尤其每个月第一天,大家都要出月报,跑的 SQL 非常多,全提到集群上去,并发度限制导致跑的比平时更慢。
我们原来也做过预聚合的尝试,这个思路跟 Kylin 很像,只不过是自己做这个事,用 Hive 先把所有的维度算出来,然后导入 MySQL 或者 HBase。但是这个方案并没有像 Kylin 这么好的模型定义抽象,也没有从配置到执行,预计算,查询这样整体的框架。现在通过使用 Kylin 实现了低成本的解决这些问题。

2 接入 Apache Kylin 的解决方案

针对上述的问题,经过大量的尝试和验证,目前主要的解决方案有以下几点。最重要的第一点,就是采用宽表。所有非标准星型的数据模型,都可以通过预处理先拉平,做成一个宽表来解决。只要能根据业务逻辑把这些表关联起来,生成一张宽表,然后再基于这张表在 Kylin 里做数据的聚合就可以了。宽表不只能解决数据模型的问题,还能解决维度变化、或者超高基数的维度等问题。
第二点是表达式指标的问题,也可以通过提前处理解决。把表达式单独转成一列,再基于这列做聚合就可以了。实际上宽表和表达式变换的处理可以用 hive 的 view,也可以生成物理表。
第三个是精确去重的问题,目前的方案是基于 Bitmap。由于数据类型的限制,目前只支持 int 类型,其它包括 long、string 等类型还不支持。因为需要把每个值都能映射到 Bitmap 里, 如果是 long 的话开销太大。如果用哈希的话就会冲突,造成结果不准确。另外 Bitmap 本身开销也是比较大的,尤其跑预计算的时候,如果算出来的基数很大,对应的数据结构就是几十兆,内存会有 OOM 的风险。这些问题后面我们也会想一些办法解决,也欢迎在社区里一起讨论。(补充说明:目前已在 1.5.3 版本中实现了全类型精确去重计数的支持。)
从整个系统的部署方式上来说,目前 Server 采用了分离部署的方式。Kylin Server 本质上就是一个客户端,并不需要太多资源,一般情况下使用虚拟机就能够满足需求。
实际的部署情况可以看这张图,左下角的是 hadoop 主集群,用于执行每天所有 hadoop 作业。中间最重要的是 Kylin01 和 02 这两个 server,是用于线上环境的 serve。其中 kylin01 是生产环境,这个环境一方面要负责从主机群上跑计算,把数据导到 HBase,另外也要响应前端的请求,从 HBase 里读数据。如果想新增一个 Cube 的话,需要在 kylin02 上操作,也就是预上线环境。所有业务方人员的 cube 数据模型定义都是在 kylin02 上做,没有问题后由管理员切到 kylin01 上。
这样做的一个好处是 kylin01 作为一个线上服务能保证稳定性,甚至权限控制能更严格一些;第二,预上线环境下开发完成后,管理员可以在投入生产前进行一次 review,保证 cube 的效率。

右上角是另外的调度系统。整个数据仓库的数据生产都是通过这个调度系统来调度的,其中的任务类型很多,Kylin 的 cube build 任务也是作为其中的一种类型。在上游的数据就绪以后,根据配置的依赖关系,自动触发 Cube 建立的过程。
左上角这边还有一个完全独立的线下测试集群,这个集群是完全开放的,主要是给用户做一些最开始的可行性调研或者评估的工作,但同时也不保证稳定性。
一个开源的系统从社区拿回来,到真正的落地,再到上生产,这个过程相对还是比较长的,这里并没有太多的技术问题,更多的是一些流程上的经验。就是如何在各个阶段给业务方提供更好的服务,使得接入 Kylin 的过程更顺畅,沟通成本更低。整个过程主要分为四个阶段。
第一个阶段是方案选型,业务方根据业务需求,选择一些方案进行调研。我们在这个阶段提供了需求的 Checklist,从数据模型,维度各个方面列出来比较详细的点,可以让业务方自己对照,确定需求是不是能够被满足。
在确定 Kylin 能满足需求的基础上,接下来是第二步,线下探查,也就是线下评估或者测试。我们提供了非常详细的接入文档,以及线下测试的环境。
第三步是线上开发,我们也有一些文档支持,基于抽象出来的场景,每个场景怎么配置 Cube,或者做哪些预处理,如何优化等,能够给业务方一个指导性的意见。
最后是开发完成后的切表上线。这个过程目前还是由管理员来操作,一方面是为了避免误操作或者滥操作,另一方面也会对 cube 进行 review,帮助进行优化。

3 主流 OLAP 系统对比分析

通过和其它同学交流,有一个感觉就是大家都觉得 Kylin 还不错,但并不是特别有信心,或者不知道非要用它的理由是什么,或者它和其它系统的对比是什么样的?这里也有部分测试结果可以和大家分享。
整个测试基于 SSB 的数据集,也是完全开源的,实际上是专门用于星型模型 OLAP 场景下的测试。整个测试数据集是非常标准的五张表,可以配置一些参数决定生成的数据集规模,然后在不同的规模下做不同查询场景的测试。现在已经完成的测试的系统包括:Presto,Kylin1.3,Kylin1.5 和 Druid。数据规模包含千万、亿、十亿三种规模;维度个数为 30 个;指标个数为 50 个。典型的测试场景包括:上卷、下钻,和常用的聚合函数。
这里挑选了典型的五个查询场景:一个事实表的过滤和聚合;五张表全关联之后的查询;两个 Count Dstinct 指标和两个 Sum 指标;后面两个查询包含 8~10 个的维度过滤。
这张图是千万规模下的一个测试结果,包括了四个系统。我们在用 Kylin 或者其它系统之前没有专门用于 OLAP 分析的引擎,只能用通用的。Presto 是其中表现非常好的引擎,但是在 OLAP 这种特定的场景下,可以看到不管跟 Kylin 还是 Druid 相比差的都比较多,所以前两个测试包含了 Presto 结果,后面就没有包含了
这里比较有趣的现象是在第三个查询,Kylin1.5 反而比 Kylin1.3 要慢一些。这个地方我们还没有搞清楚是什么原因,后面会详细的看一下。当然这个也可以证明数据没有修改过,是真实的测试数据。
从后面的两个查询上可以看到,在千万规模的级别,和 Druid 还是有比较大的差距。这主要和它们的实现模式相关,因为 Druid 会把所有的数据预处理完以后都加载到内存里,在做一些小数据量聚合的时候,可以达到非常快的速度;但是 Kylin 要到 HBase 上读,相对来说它的性能要差一些,但也完全能满足需求。

在亿级的规模上情况又有了变化,还是看后面两个查询,Kylin1.3 基本上是一个线性的增长,这个数据已经变得比较难看了,这是由于 Kylin1.3 在扫描 HBase 的时候是串行方式,但是 Kylin1.5 反而会有更好的表现,这是因为 Kylin1.5 引入了 HBase 并行 Scan,大大降低了扫描的时间。Kylin1.5 的数据会 shard 到不同的 region 上,在千万量级上数据量还比较小,没有明显的体现,但是上亿以后,随着数据量上升,region 也变多了,反而能把并发度提上去。所以在这里可以看到 Kylin1.5 表现会更好。这里也可以看出,在数据量成数量级上升后,Kylin 表现的更加稳定,在不同规模数据集上依然可以保持不错的查询性能。而 Druid 随着数据量的增长性能损失也成倍增长。

刚才是在性能方面做的一些分析,其实对于一个系统来说,性能只是一个方面,除此之外,我们也会去考量其它方面的情况,主要有以下四点。
第一,功能的完备性。刚才提到我们所有的数据必须是精确的,但是现在基本上没有哪个系统能完全覆盖我们这个需求。比如 Druid 性能表现确实更好,但是它去重计数没有办法做到精确。
第二,系统的易用性。作为一个平台服务,不仅要把系统用起来,还要维护它,因此要考虑部署和监控的成本。这方面 Kylin 相对来说也是比较好的。Druid 一个集群的角色是非常多的,如果要把这个系统用起来的话,可能光搭这个环境,起这些服务都要很长的时间。这个对于我们做平台来讲,实际上是一个比较痛的事。不管是在部署,还是加监控的时候,成本都是相对比较高的。另外一个查询接口方面,我们最熟悉或者最标准,最好用的当然是标准 SQL 的接口。ES、Druid 这些系统原来都不支持 SQL,当然现在也有一些插件,但是在功能的完备性和数据的效率上都不如原生的支持。
第三,数据成本。刚才提到了有些数据需要做一些预处理,比如表的拉平或者表达式列的变换,除此之外还有一些格式的转化,比如有的系统只能读 TEXT 格式,这样都会带来数据准备的成本。另一方面是数据导入的效率。从数据进入数据仓库到真正能够被查询,这个时间中间有多长。数据存储和服务的时候需要多少机器资源,这个都可以归为数据成本,就是使用这个数据需要付出的成本。
第四,查询灵活性。经常有业务方问到,如果 Cube 没定义的话怎么办?现在当然查询只能失败。这个说明有的查询模式不是那么固定的,可能突然要查一个数,但以后都不会再查了。实际上在需要预定义的 OLAP 引擎上,这种需求普遍来讲支持都不是太好。
这张图是各个系统全方位的一个对比。

从查询效率上看,这里表现最不好的就是 Presto,表现最好的应该是 Druid 和 Kylin1.5,两者不相上下。从功能完备性上来讲,确实 Presto 语法和 UDF 等等是很完备的,Kylin 会稍微差一些,但比 Druid 好一点。
系统易用性上区别不是太大,这里主要考虑有没有标准的 SQL 接口或者部署成本高不高,用户上手能不能更快,目前来看 Druid 接口上确实不够友好,需要去翻它的文档才知道怎么去写查询的语法。
在查询成本上,Presto 是最好的,因为几乎不需要做什么特殊的处理,基本上 Hive 能读的数据 Presto 也都能读,所以这个成本非常低。Druid 和 Kylin 的成本相对较高,因为都需要提前的预计算,尤其是 Kylin 如果维度数特别多,而且不做特别优化的话,数据量还是很可观的。
最后从灵活性上来讲, Presto 只要 SQL 写出来怎么查都可以,Druid 和 Kylin 都要做一些预先模型定义的工作。这方面也可以作为大家选型时候的参考。
刚才比较客观的对比了几个系统,接下来再总结一下 Kylin 的优势
第一,性能非常稳定。因为 Kylin 依赖的所有服务,比如 Hive、HBase 都是非常成熟的,Kylin 本身的逻辑并不复杂,所以稳定性有一个很好的保证。目前在我们的生产环境中,稳定性可以保证在 99.99% 以上。同时查询时延也比较理想。我们现在有一个业务线需求,每天查询量在两万次以上,95% 的时延低于 1 秒,99% 在 3 秒以内。基本上能满足我们交互式分析的需求。
第二,对我们特别重要的一点,就是数据的精确性要求。其实现在能做到的只有 Kylin,所以说我们也没有什么太多其他的选择。
第三,从易用性上来讲,Kylin 也有非常多的特点。首先是外围的服务,不管是 Hive 还是 HBase,只要大家用 Hadoop 系统的话基本都有了,不需要额外工作。在部署运维和使用成本上来讲,都是比较低的。其次,有一个公共的 Web 页面来做模型的配置。相比之下 Druid 现在还是基于配置文件来做。这里就有一个问题,配置文件一般都是平台方或者管理员来管理的,没办法把这个配置系统开放出去,这样在沟通成本和响应效率上都不够理想。Kylin 有一个通用的 Web Server 开放出来,所有用户都可以去测试和定义,只有上线的时候需要管理员再 review 一下,这样体验就会好很多。
第四,最后一点就是活跃开放的社区和热心的核心开发者团队,社区里讨论非常开放,大家可以提自己的意见及 patch,修复 bug 以及提交新的功能等,包括我们美团团队也贡献了很多特性,比如写入不同的 HBase 集群等。这里特别要指出的是核心团队都是中国人,这是 Apache 所有项目里唯一中国人为主的顶级项目,社区非常活跃和热心,有非常多的中国工程师。特别是当你贡献越来越多的时候,社区会邀请成为 committer 等,包括我自己及团队成员也已经是 Apache Kylin 的 committer。同时也非常高兴看到以韩卿为首的 Apache Kylin 核心团队在今年初成立的创业公司 Kyligence,相信可以为整个项目及社区的发展带来更大的空间和未来。

4 未来工作

在未来工作方面,我们认为 Kylin 还有一些不理想的方面,我们也会着力去做优化和改进。
第一,精确去重计数。刚才提到只支持 Int,接下来有一个方案会支持所有的数据类型,能够扩展大家使用精确去重的场景范围(补充说明:目前该功能已在 1.5.3 版本中实现)。
第二,在查询效率和 Build 效率上也看到了一些可以优化的部分。比如队列资源拆分,我们所有计算集群的资源都是按照业务线核算成本的,但是现在 Kylin 本身还不太支持,这个我们也会抓紧去做,相信在很多公司也有类似的需求。还有大结果集和分页。当结果到了上百万的量级时,查询时延会上升到几十秒。同时在查询的时候有可能需要排序并且分页,就是把结果全读出来之后,根据其中的一个指标再 order by,这个开销也是比较大的。我们也会想办法进行优化。
最后,Kylin1.5 之后有明细数据和 Streaming 特性出来,后面也会做这方面的尝试。

5 Q&A

Q1:之前在 Build 的时候一直提到成本的问题,能给出一个估计值吗,如果一百亿的数据,需要多少时间?
有一个简单数据,大概是两亿行数据,维度的话有十四五个,Build 时间不超过两个小时,Build 出来的数据是五六百 G。
Q2:原始值是多大?
把这个数据抽出来之后,就是只参与 Build 的数据压缩后只有几个 G。
Q3:Kerberos 认证失效的问题你们遇到过没有?
Kerberos 认证完之后,会在本地临时目录下有一个 ticket 问题,每天在外部定时刷新一下就可以了,服务是不用停的。
主持人:我补充一下我们为什么选择 SQL 接口?Kylin 解决的是真正的用户面是谁,其实是业务人员和分析人员,他只会 SQL,几乎那些人很少说再学个 JAVA,所以能给他一个标准的 SQL 这个是让他上船最快的事情。其实这就是易用性很重要。
刚才看到了 Kylin 在千万级规模和亿级规模的表现,如果数据规模上到十亿,百亿,千亿的时候,我相信 Kylin 应该会秒杀所有一切。因为我们现在有另一个案例,生产环境上千亿规模的一张表,可以做到 90% 查询在 1.8 秒以内。另外我觉得非常好的一点,像美团、京东这边贡献了很多 patch,其实就是把需求提出来,大家可以一起来做。

版权声明:

本文为大数据技术与架构整理,原作者独家授权。未经原作者允许转载追究侵权责任。
编辑|冷眼丶
微信公众号|import_bigdata
欢迎点赞+收藏+转发朋友圈素质三连


文章不错?点个【在看】吧! 

浏览 28
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报