写点什么

Kylin 在携程的实践(上)

2020 年 11 月 26 日

Kylin 在携程的实践(上)

携程在 2016 年左右开始应用 Kylin 的解决方案。在 2018 年的 5、6 月份,我作为小白接手了 Kylin,逐渐琢磨、踩坑,折腾折腾就过来了。我将介绍 Kylin 在携程这一年的发展历程,碰到的挑战,以及解决的问题。


背景


1 早期架构


下图是携程早期的 OLAP 结构,比较简单。有两个应用,一个是 BI 分析报表工具,另一个是自助分析的 Adhoc 平台,下层主要是 Hive,技术比较单一。Hive 是比较慢的运行引擎,但是很稳定。期间我们也使用过 Shark,但 Shark 维护成本比较高,所以后面也被替换掉了。文件存储用的是 HDFS。整个架构是比较简单的,搭建过程中成本也比较低。



早期架构的特点:一个字 慢! 两字 很慢! 三个字 非常慢!!!


2 技术选型


随着业务需求的多样化发展,我们团队引入了许多 OLAP 引擎,其中也包括了 Kylin。这里我们重点介绍下选择 Kylin 所考虑的几个方面:



百亿数据集支持


首先对我们来说,海量数据的支持必不可少的。因为很多的用户向我们抱怨,由于携程早期都是采用微软的解决方案,几乎没办法支撑百亿级的数据分析,即便使用 Hive,也需要等待很长时间才能得到结果。


SQL 支持


很多的分析人员之前使用的 SQL Server, 所以即使迁移到新的技术也希望能保留使用 SQL 的习惯。


亚秒级响应


还有很多的用户反馈,他们需要更快的响应速度,Hive、Spark SQL 响应只能达到分钟级别,MPP 数据库像 Presto、ClickHouse 也只能做到秒级,毫秒级是很困难的。


高并发


在一定的用户规模下,并发查询的场景非常普遍。仅仅通过扩容是非常消耗机器资源的,一定规模下维护成本也很高。而且,传统的 MPP 会随着并发度升高,性能出现急剧的下降。就拿 Presto 来说,一般单个查询消耗 10 s,如果同时压 100 个并发,就出不了结果。Kylin 在这一方面的表现好很多。


HBase 的技术储备


携程有大量使用 HBase 的场景,在我们大数据团队中有精通 HBase 的开发人员,而 Kylin 的存储采用 HBase,所以运维起来我们会更得心应手。


离线多


携程目前离线分析的场景比较多,Kylin 在离线分析场景下属于比较成熟的解决方案,所以我们选择了 Kylin。


当前架构


首先我们先看一下目前 Kylin 在携程的使用规模。



Cube 的数量现在稳定在 300 多个,覆盖 7 个业务线,其中最大的业务线是度假玩乐。 目前单份数据存储总量是 56 T,考虑到 HDFS 三份拷贝,所以总存储量大约 182 T,数据规模达到 300 亿条左右。最大的 Cube 来自于火车票业务,一天最大的数据是 28 亿,一天次构建最大的结果集在 13 T 左右。 查询次数比较固定,基本上是 20 万查询/天,通过 Kylin 的查询日志分析下来,90% 的查询可以达到 300 ms 左右。


下图是 OLAP 的架构图,在携程主打的 OLAP 采用 Spark、Presto 和 Kylin,Hive 慢慢被 Spark 给替代。Kylin 服务两个业务产品,一块是 Artnova BI 分析工具,还有其他的业务部门报表产品,也会接入 Kylin。存储层是 HBase、HDFS 等等。



这里顺便提到元数据的管理,目前正在做这块的开发,其中包含字段的血缘分析、表的特征分析,后期 Kylin 会根据分析的结果自动替用户构建 Cube。 打个比方:某些表,用户频繁的访问,或者在维度很固定的情况下,Kylin 就会自动配置一个对应的 Cube。前端的报表自动就匹配了 Kylin 作为查询引擎,对用户来说,之前每次要 20 s 才能展示的报表,突然有一天只需要 500 ms 就可以展示了。


另外,我们计划将 Kylin 接入规则引擎,从而给数据产品提供统一的入口。并且提供查询自动降级等对用户友好的功能。


我们再看下 Kylin 部署图:



1 两套集群


主要考虑到 MR 构建的性能。目前在大集群上跑 MR, 由于 Hadoop 在高峰时期持续到中午都非常繁忙,计算资源基本上是满负荷。一次 MR 任务的调度需要等待 20 秒左右才跑起来,对于准实时的构建性能影响非常大,很难满足用户的准实时数据落地的需求。虽然目前暂时把任务优先级别调高,但提升也是比较有限的。


2 负载均衡


负载均衡是为了防止单机宕机对用户产生的影响,是出于稳定性的考虑。


3 独立的 HBase + HDFS 查询集群


脱离线上大集群,单独构建 HBase + HDFS 集群, 可以大大减少其他因素对于查询性能的影响。


4 共享的计算集群


在我们接收 Kylin 之前,整个 Kylin 的部署是 7 个业务线,7 个 Kylin 的 Instance,比方说火车票这个 Instance 只有 2 个 Cube,每天的查询量几百次。单个节点放在那里很多时间都是空闲的,浪费资源不说,维护成本也高。


为什么要读写分离? 因为 Kylin 是典型的适用于一次写、多次查询的场景,对于查询,最好是其他不相关的干扰因素越少越好。在之前的构建和查询混杂在一起的情况下,查询性能受制于构建任务,互相制约,难以保证服务的稳定性。


监控


我们自己开发了一套 Kylin 集群的监控系统。


1 Kylin HBase 集群的监控,把握 HBase 的负载



这里我们说个故事。几个月前,Kylin 出现了一个很大的与 Kylin HBase 相关的问题。因为 HBase Master 进程和 ZooKeeper 失联了,然后 HMaster 两个都失联,全部挂了之后,整个 HBase Master 出现宕机状态。我们最后是通过上图的页面发现当时 HMaster 系统的 CPU 特别高,然后顺藤摸瓜,找出问题的根源。


2 查询性能监控



可以更加实时地看到各个时段平均查询的响应速度,我们每次优化之后都能通过这个页面看到优化的效果是否明显。


3 清理合并任务的运行状态监控告警


通过这套监控系统,我们可以实时把握 Kylin 的垃圾清理状态。Kylin 中数据垃圾的堆积是灾难性的, 如果不监控,积少成多的失败会导致灾难性的后果。



这里说个故事。之前由于合并清理任务没有及时地被监控,导致长时间的失败,我们都没有在意,后果是什么呢?HBase 的 Region 数量暴增到 5 万以上,导致 HBase 的压力特别大,最后无法支撑,从而挂机,这是个惨痛的代价。


经验分享


1 维度组合优化


像度假部门,他们很多的场景需要 20、30 个维度。在这种场景下,我们需要确定强制维度。为什么使用强制维度?比方说:用户门票分析,有些维度是必需的,比如性别、姓名、身份证。通过优化其实可以将原先 30 个维度的场景减少到 14 个以内。


2 高基字典


如果在 Kylin 上面配高基 dict,fact distinct 这个步骤就会对于高基的字典生成一个很大的如下 Sequence File,如果这个文件达到 700 MB,Hadoop 初始化 StreamBuffer 时就会抛出异常。


1.4G hdfs://ns/kylin/kylin_metadata/kylin-a2696e1c-1516-4ff1-800e-5f7b940d203a/C_PaymentCR_Flat_clone/fact_distinct_columns/V_OLAPPAY_CONVERTRATE_FLAT.SITE


异常详情与解决方法见:https://plumbr.io/outofmemoryerror/requested-array-size-exceeds-vm-limit


3 MR 内存分配


精确去重时,Kylin 会做全局字典,在 MR 构建过程中,全局字典在 Kylin 里会被切分成很多 Slice,构建过程中这些 Slice 存放在缓存中。由于缓存需要控制大小,所以通过不停地换入换出,保证缓存的大小可控。由于每个数据其实都需要访问其中一个 Slice,我们遇到的问题是:因为内存太少,整个全局字典 Slice 换入换出太频繁,一条数据过来之后,找不到 Slice,会从 HDFS 中加载。整个过程非常缓慢,当我们把内存调高了一倍之后,构建速度明显改善。


4 构建调度缓慢


Kylin 依赖 Scheduler 的实现去调度 Job 构建任务,在 Streaming 的构建场景下,会积累大量的历史 Job 信息。Scheduler 在每个步骤调度的间隔会去扫描 Job 历史,从而获取哪些 Job 需要继续被构建下去。在这个过程中,Scheduler 会一个一个 RPC 请求访问 HBase。如果 Job 历史超过 1 万个,1 万次 RPC 的请求耗时大概有 1 分钟左右,这样大大影响 Scheduler 的调度性能。我们这里通过缓存需要被调度的 Job 信息,减少了 99% 的无用的 HBase RPC 调用,从而提高了整体调度间隔消耗的时间。


5 Merge 上传无效字典


用过 Kylin 的人都知道,在 Kylin 构建过程中,有很多的 Segments 之后,要把它们 merge。Streaming 产生新 Segments 的频率很高,因此,可能 5 分钟就出现一个 Segment。一天里,一个 Cube 就可以产生 1440 个 Segments。在 merge 的过程中,即使 merge 两个 Segments,Kylin 也会上传 1440 个 Segments 的元信息。这块我们已经进行优化,并且成功合并到了 Kylin 2.6.0 之后的版本:https://issues.apache.org/jira/browse/KYLIN-3826


6 数据安全


当我们迁移到统一的公用集群之后,我们要考虑数据安全,每一个用户仅仅对自己的 Cube 可见,所以我们在 Kylin 2.3.1 版本上,加了用户隔离的逻辑。对于用户来说,这样可以直接看到自己业务相关的 Cube。


7 节点自动探知


去年,我们出现了一个事故。当时,凌晨一个查询节点出现岩机器宕机故障。由于 Kylin 配置中 kylin.rest.servers 指明了所有同步节点的 Host,导致即使出现一个节点宕机,同步请求依然会不停地发向这个节点,最后所有同步的线程被阻塞。读写分离的集群出现了灾难性的数据不同步情况。



我们的方案:引进了服务发现组建 ZooKeeper。详见:


https://issues.apache.org/jira/browse/KYLIN-3810



8 独立 HBase 的 HA 模式


去年,我们 HBase NameNode 主备切换导致 Kylin 无法正常工作的问题。我们实现了通过 namespace 的方式来访问 HDFS,并将相关的改进提交到社区:


https://issues.apache.org/jira/browse/KYLIN-3811


9 设置 kylin.storage.hbase.max-region-count


控制 hbase.max-region-count 其实可以有效地控制生成 HFile 过程中对于 DataNode 的写压力。比如说:在 HDFS 集群比较有限的情况下,大量的 MR 写操作,会给 HDFS 系统带来很大的压力,减少这个值可以有效地控制 MR 写 HFile 的并发度,但也会影响构建性能,这个需要权衡。


本文转载自公众号 apachekylin(ID:ApacheKylin)。


原文链接


Kylin 在携程的实践(上)


2020 年 11 月 26 日 10:101087

评论

发布
暂无评论
  • Apache Kylin 在百度地图的实践

    对于Apache Kylin在实际生产环境中的应用,在国内,百度地图数据智能组是最早的一批实践者之一。大数据OLAP多维分析平台承载百度地图内部多个基于Apache Kylin引擎的亿级多维分析查询项目,共计约80个cube,平均半年时间的历史数据,共计约50亿行的源数据规模。

  • Kylin 在贝壳的性能挑战和 HBase 优化实践

    本文从性能调优上向大家介绍如何通过对 HBase 的优化来保障重点业务的查询性能,实现 Kylin 千万级/天的查询量下,3s 内查询占比达到99.7%。

  • Kylin 5 年的成长与未来规划

    本文分享 Kylin 在过去 5 年中的成长和 Kylin 4.0 版本开发的状况,也面向社区分享了 Kylin 未来的发展规划。

  • Apache Kylin 在携程的实践

    在近期的 Apache Kylin Meetup 上,携程大数据资深研发工程师张巍分享了 Kylin 在携程的应用。本文为大家介绍携程当前的架构以及使用 Kylin 过程中的挑战与心得。

  • 美团点评常态、异地、多机房、单集群 Hadoop 架构实践

    演讲嘉宾美团点评离线存储团队技术专家,2013 年毕业于哈尔滨工程大学,2015 年加入美团,负责美团点评 HDFS、HBase 服务,先后深度参与了 HDFS Federation 兼容性改造和落地,美团点评数据平台融合,常态、异地、单集群、多机房 Hadoop 架构改造,HDFS NameNode 锁粒度拆分,增量数据生产架构演进等重点项目。在 HDFS、HBase 方面有大量的源码和架构实践经验,致力于为美团点评提供稳定、高效、易用的大数据存储服务。内容介绍随着美团点评以吃为核心的多场景业务的飞速发展, 美团点评的 Hadoop 集群规模持续每年翻番, 2017 年 Hadoop 集群规模突破万台,超出单机房容量上限, 势必要提供多机房的 Hadoop 服务。现有 Hadoop 架构没有机房概念,在多机房部署 Hadoop 服务时,会导致大量的跨机房流量和请求严重降低集群吞吐。业内在解决 Hadoop 多机房部署问题时,往往采用一个机房一套集群的运维方式,但这会使机房概念最大程度的暴露到数据生产层面,提高了数据开发成本。在此背景下, 美团点评离线团队秉持以业务为中心的价值导向, 通过技术换运营,自主研发了对业务提供透明的、数据强一致性保障的、常态、异地域、多机房、单集群 Hadoop 服务。目前, 美团点评 Hadoop 集群规模数万台,是业界唯一一家提供常态、异地域、多机房、单集群 Hadoop 服务的科技企业。此次分享整个方案设计和落地,给业界同行在面临同样场景时以参考。

    2019 年 7 月 24 日

  • 阿里巴巴的大数据故事:数据分析平台发展史

    国内大数据平台做得最好的公司当属阿里巴巴。今天我们介绍一下阿里巴巴数据分析平台的发展情况。

    2018 年 4 月 11 日

  • 字节跳动 EB 级 HDFS 实践

    本文从 HDFS 发展历程入手,介绍发展路径上的重大挑战及解决方案。

  • 高可用存储架构:集群和分区

    今天我们一起来看看另外两种常见的高可用存储架构:数据集群和数据分区。

    2018 年 6 月 26 日

  • 效率提升 4 倍,Apache Kylin 在银联的实践

    10年前,中国银联建成了统一的企业级数据仓库,确立了以 IBM Cognos 为核心的多维分析应用。经过10年的积累,IBM Cognos 在各个方面都迎来了巨大的挑战。经过选型验证,中国银联把以 Apache Kylin 为核心的 Kyligence 作为大数据多维分析的核心技术组件,并在 Kyligence 的基础之上进行了定制化的开发。

  • Kylin 在滴滴 OLAP 引擎中的应用

    滴滴 OLAP 引擎细分多种场景,如灵活分析、固化分析、热点数据等,针对不同场景的特性,使用不同的场景引擎。Apache Kylin 作为滴滴 OLAP 引擎内部的固化分析场景引擎,间接服务了滴滴下游多个重要的数据产品,覆盖了十多条业务线,为用户提供了稳定、可靠、高效的数据分析性能。

  • Apache Kylin 的快速数据立方体算法——概述

    Apache Kylin(麒麟)是由eBay贡献给开源社区的大数据分析引擎,支持在超大数据集上进行秒级别的SQL及OLAP查询,目前是Apache基金会的孵化项目。本文是一系列介绍快速数据立方体计算(Fast Cubing)的第一篇,将从概念上介绍新算法与旧算法的区别以及分析它的优劣。该算法目前正在内部进行测试和改进,将在Apache Kylin 后续版本中发布。源代码已经公开在Kylin的Git代码库中,感兴趣的读者可以克隆并切换到0.8分支查看。

  • 分片机制:为什么说 Range 是更好的分片策略?

    分片是解决性能和存储这两个问题的关键设计,甚至不仅是分布式数据库,在所有分布式存储系统中,分片这种设计都是广泛存在的。

    2020 年 8 月 21 日

  • 卷皮 OLAP 平台进化史:Apache Kylin 在卷皮网大数据平台的运用

    随着卷皮网的快速发展,数据规模快速增长,集群数据存储量成指数倍增大,服务器规模达到 100+ 台,与此同时公司的运营成员急剧增加,数据需求也随着业务的发展落地不断增长。为了节省取数工作的时间和人员开支,及时响应运营等部门同学数据需求的快速响应,于是开发了以自助数据分析为目标的 OLAP 平台。本文将详解 Apache Kylin 在卷皮网大数据平台的运用。

  • Druid 在有赞的使用场景及应用实践

    Druid 是 MetaMarket 公司研发,专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统,已在 Apache 基金会下孵化。

  • 爱奇艺如何处理千亿级数据

    爱奇艺使用 Kylin 代替传统的 Hive + MySQL 模式,在爱奇艺 BI、推荐等 20+ 个业务场景的应用、具体落地效果,遇到的坑和一些优化经验,以及未来的计划,比如简化 Cube 调整难度等。

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

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

  • Apache Kylin v1.5 版本中的快速数据立方算法揭秘

    Apache Kylin是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据。它能在亚秒内查询巨大的Hive表。本文将详细介绍Apache Kylin 1.5中的Fast-Cubing算法。

  • 微博技术解密(上) | 微博信息流是如何实现的?

    接下来的微博技术解密系列,我将分享微博在信息流架构、存储中间件等方面的经验,希望能给你带来启发和帮助。

    2019 年 1 月 29 日

  • 切片集群:数据增多了,是该加内存还是加实例?

    随着用户或业务规模的扩展,不可避免地要遇到保存大量数据的情况。而切片集群,就是一个非常好的解决方案。

    2020 年 8 月 24 日

  • Kylin 在携程的实践(下)

    本文将继续携程的案例,您将看到 Kylin 在携程离线、实时分析场景中的实际应用,及携程对 Kylin 未来的展望。

发现更多内容

让Go“恐慌”的十种方法

博文视点Broadview

go

你可能还不知道自己无知

小天同学

读书 智能时代 信息噪声 高考

一次非常有意思的 SQL 优化经历: 从 30248.271s 到 0.001s

Java小咖秀

MySQL 面试 经验分享 优化逻辑 后端开发

【Python】__name__ 是什么?

Leetao

Python Python基础

一口气说出 OAuth2.0 的四种授权方式

程序员内点事

Java oauth2.0

Spring核心原理解析

Chank

Java spring

很多人毕业多年以后,还是改不掉学生思维

小智

职场 思维方式 高考

啃碎并发(三):Java线程上下文切换

猿灯塔

计算机中短期学习路线

zack

「深度解析」AI训练之数据缓存

焱融科技

人工智能 AI 存储 焱融科技 数据缓存

计算机操作系统基础(十四)---线程同步之条件变量

书旅

php laravel 操作系统 进程 线程’

干货 | 如何评估Kubernetes持久化存储方案

焱融科技

Kubernetes 容器 云原生 k8s 容器存储

SpringBoot 中使用 Filter 的正确姿势

Java课代表

话题讨论|作为一名程序员,你下班之后都会做些什么?

InfoQ写作平台官方

写作平台 话题讨论 话题

架构师训练营第五周作业

talen

Ceph数据恢复初探

焱融科技

焱融科技 文件存储 分布式存储 数据恢复 Ceph

第五周作业

Linuxer

极客大学架构师训练营

数据分析师成长体系漫谈--数据埋点

analysis-lion

数据分析 数据采集 埋点

游戏夜读 | 关卡设计的难点

game1night

架构师训练营第五周作业

一剑

国内首本CTF赛事技术解析书籍,五年之约,兑现了!

华章IT

网络安全 Web CTF Reverse PWN

kafka监听mysql实时数据变更

爱java爱自己

MySQL mysql事务

女同事问哪吒什么是 Spring 循环依赖?我...

通天哪吒

第5周结构师训练营——作业

jiangnanage

Redis-进阶篇一

多选参数

数据库 redis redis高可用 redis6.0.0 Redis项目

架构师训练营 W5 作业

Kun

极客大学架构师训练营

第 5 周作业:一致性 Hash 算法

姜 某某

week05 学习总结 分布式缓存&消息队列&负载

Z冰红茶

一致性hash的理解与实现

dongge

这份高考卷,只有程序员能得满分...

程序员生活志

程序员 高考

架构师训练营第5周

大丁💸💵💴💶🚀🐟

飞猪Flutter技术演进及业务改造的实践与思考

飞猪Flutter技术演进及业务改造的实践与思考

Kylin 在携程的实践(上)-InfoQ