Apache Kylin 云原生架构的思考及规划

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: 在 1 月 4 号 ECUG 技术大会的分享中,Kyligence 的 CEO Luke Han 为大家带来了主题为《Apache Kylin 云原生架构的思考及规划》的精彩演讲,分享了 Kylin 如何拥抱云原生这一趋势。以下为演讲实录。

在 1 月 4 号 ECUG 技术大会的分享中,Kyligence 的 CEO Luke Han 为大家带来了主题为《Apache Kylin 云原生架构的思考及规划》的精彩演讲,分享了 Kylin 如何拥抱云原生这一趋势。以下为演讲实录。


各位同学,大家下午好!非常高兴今天来到这个场合,给大家介绍一下 Apache Kylin 在接下来云原生方面的变化和思考,以及我们在这方面最近的工作。

01关于 Apache Kylin

首先介绍一下 Apache Kylin 这个项目,Kylin 是我们五六年前在 eBay 中国研发中心孵化,完全由中国人设计、研发、贡献出来的第一个 Apache 顶级项目,我们在这方面的确踩了一条路出来。今天我们看到 Apache 软件基金会里有十几个来自中国的项目,包括华为、百度、阿里等等,我们看到在全球的开源社区里有越来越多中国人的声音和力量。
image.png

Apache Kylin 是做什么的?它是一个分布式引擎,为 Hadoop 等大型分布式数据平台之上的超大规模数据集通过标准 SQL 查询及多维分析(OLAP)功能,提供亚秒级的交互式分析能力。也就是数据集很大的情况下,业务人员需要快速分析的时候,需要这么一个数据集市的解决方案,把数据汇总好,能够让你的业务人员用起来很快很爽,而不是让他再跑一个脚本。

image.png

我们看一下 Kylin 的基础架构。Kylin 是基于 Hadoop的,使用 MapReduce/Spark 进行预计算,并且使用 HBase 保存预计算的中间结果。通过 Calcite 来将 SQL 解析为执行计划,并且将最复杂的现场计算工作省去,直接利用预计算准备好的中间结果,达到加速查询的目的。

image.png

在当年的时候其实做得还挺好,但是这几年遇到了巨大的挑战。

02 挑战来临

image.png

第一个挑战叫云原生, Hadoop 的架构在云原生上是非常大的痛苦,而且是反云原生的,需要去解决的还有很多。我们 Apache Kylin 项目最原始的一些人出来创业,我们的创业公司叫 Kyligence ,在上海。我们成立之后,自己做了一个项目叫“逃离动物园”,因为整个 Hadoop 都是动物,猪、蛇还有蚂蚁、蜜蜂等等。

image.png

今天云计算在吞噬所有的世界,所以你如果不去做,你就被人吃掉了,赶紧去做。这张图背后的故事今天就不讲了,这两年发生的故事太多了。

image.png

回过头,来分析下我们想干的这件事情好在哪里,不好在哪里。可以看到整个 Hadoop 的曲线,对于整体私有部署还不错,还很便宜。但是你会发现整个学习曲线、计算存储、版本管理之类的相当令人痛苦。和 Hadoop 相关的项目有两三百个,你要去把这个事情玩得溜,要把版本弄清楚,要把牌打清楚,非常复杂。让这个东西上云的时候,你会发现更痛苦。

如果你有 PB 以上的数据量放在 Hadoop 里,我相信你靠一个人是摆不平的。如果你上面老板还想要做复杂点的东西,你发现养 10 个人的团队是必然的,而且还要天天晚上起来,因为跑 batch 的时候往往在晚上。

image.png

当时,我们发现 Kylin 的存储 HBase 也有巨大的挑战。它的挑战在于不是一个真正的列存,它可以很好地写优化,但是整个索引等等都有很大的挑战,而且运维相当困难。当然现在已经很好了,我们最早用 v0.98,那时候整个挂掉都是很正常的。另外一个是它缺乏二级索引,HBase 今天的版本里面依然没有很好的二级索引。我如果做查询,只做一个维度上的高查询,是可以做到的,但是业务用户永远不是这么想的。包括无数据类型等等,都有很大的挑战。而且放在云上面的挑战更大,日积月累以后数据占用的资源就很大了。我不是说它不好,它还是相当不错的。

image.png

当时我们看到了这些问题,但当时我们严重依赖 Hadoop ,今天我们要做的是想要怎么样逃出去,又不能完全从头写一个,外面那么多用户在用。所以我们想的第一件事情是云上有哪些好的东西,云上的特点在哪里。讲到云上的时候对象存储,云上对象存储很便宜,可以放很多的数据,但它不是一个 native 的存储,也就是说它比 HBase 直接访问磁盘要慢不少,今天我们在云上一定要加速,一定要在这方面做很多工作。好处是放在云上很便宜。

另外一个是在整个资源管理上,一般来说云上现在更多的是用 Kubernetes ,你在 Hadoop 里还得去做选型,很复杂。还有其他一些问题,其中最重要的一点叫存储与计算分离,不能说老是往云上方放数据,如果老板已经让你买了几千台机器,放在机房里不用,是沉没成本,但是放在云上就不一样了。

03 Apache Kylin 如何适应这一趋势?

回过头来,我们希望在整个云上面做几样东西,第一个是希望能够做到从整个持续集成,从容器编排到微服务和敏捷开发,都可以在新一代架构里面做出来,来看看我们是怎么去做的。
image.png

我们第一步是做重构,这件事情大概发生在 2014、2015 年的样子,我们创业前后的样子。这是最早的麒麟架构,其实我们最早设计的时候比较好的一点,我们完全是面向接口编程的,所以每个模块做得非常好,从源数据到执行引擎到存储到访问到 Server ,全部都是放开的。但还不够,所以我们做了一件事情叫可插拔的架构,我在某一年的 ECUG 讲过这个概念。也就是说我们把每一块都抽象出来,把 Cube Builder 这块全部变掉,这个好处也就是我们有能力去随时随地换掉某一个引擎。理想是很好的,但是现实确实很骨感。比如你想换个存储引擎,换换挺快的,让它成熟我们至少花了两年,这是一个过程。这是第一步,好几年前就做完了。

image.png

我们干完这件事情之后,各个地方都可以变成一个所谓的 Adaptor 的结构,我们最早只能支持 Hive source ,也就是说我们只能从 Hive 读数据,今天我们已经可以从 Kafka 等等,甚至前段时间做了一个阿里的接口,都做出来了,很容易,因为可插拔的架构在这儿了。
image.png

第二件事情是非常重的改变。最早的时候我们完全用 MapReduce 去做整个底下的计算,那个时候 MapReduce 做得确实好,坦率讲今天我的大量客户还在用 MapReduce ,原因是稳定,慢是很慢,但是真的稳定。但有的时候 MapReduce 并不 work,尤其我们想要扔到云上去,尤其是我们想要逃出这个动物园的话。所以我们第一个决定是用 Spark。

Spark 有几个好处,我们之前的计算是一层一层算的,简单地说,每一层是一个 Mapreduce Job,我这个 Job 做完才能做下一个,下一个做完才能做下一个。但是这里最大的问题是两个:一个在于数据会落盘,每一层计算完了以后都会 flush 到 HDFS 之上,下一个层才能去读;第二个问题在于,每一层都是一个 MapReduce Job ,所以会带来一个巨大的 job 的 overhead,因为你起一个 job 和关一个 job 是有时间差的,整个构建有很多层,时间就很长很长。所以我们当时就整个换成了 Spark,用 RDD 的方式,好处在于整个过程,一个 Spark Job 就过去了。

坦率讲,在这个场景下我们碰到了若干的坑,尤其是内存相关的,因为数据量太大,所以那时候 Spark 经常会爆,现在比较稳定了,我们有比较好的方式。这是整个 Spark 当时的改变。这个版本大概是在 2015 、2016 年的时候出来的,我们花了很多力气去做稳定性。

image.png

这是整个实现,以前每个 MapReduce Job 都是一个 for 循环,计算复杂度是非常大的。你想想看去加载几百 TB 数据计算的时候,是几个小时甚至十几个小时的过程,十几个小时的 for 循环。现在一个 Spark Job 提交上去之后就结束了,所有的东西在一个 Job 处理。这里最重要的是内存配置,不要把数据爆掉,这块 Kylin 社区有相当多的经验和实践可以给大家看。

image.png

不仅是 build ,整个过程都用 Spark 去做,这个时候你完全不需要依赖于 Hadoop 的东西了。这是一个对比,在 2017 年的 Spark 会议上介绍了,当时对比了一些相应的 MapReduce 的性能对比,一个非常粗的结论是我们可以节省一半的时间,当然这跟数据有关,有些数据集上反而会慢,这是肯定的,需要调优。

image.png

干完这件事情之后,我们另外一个事情是要运维了,因为云原生的东西一定要想办法更好地去运维它,所以 Docker 化是我们的第一步。我们在 2016 年 Docker 很火的时候就做了一个版本出来,这个东西一直在,然后整个查询服务是完全可以无状态化的,完全可以容器化了,当时我们就全部解决掉了,一个 Docker 下载下来就好了。现在查询服务本身无状态,都可以做到,这个很简单。

image.png

Docker 有了后还缺一样东西——天下大火的东西 Kubernetes 。你有了 Docker 已经去多中心了,耦合性也没有了,怎么去编排它,这块社区在开发中,快结束了。

怎么用 Kubernetes 去管理所有跟 Kylin 相关的东西,这是非常重要的。尤其在云上的时候,我们自己的云版本已经做到自动伸缩了,也就是说我可以在数据量进来之后,通过规则对资源的使用去做伸缩。这个得益于整个 Docker 化和 Kubernetes 化,可以做自动化的编排。

第二点,Kubernetes 化之后,给我们带来一个最大的变化,就是我们之前要依赖云上的 Hadoop ,你要做一整套东西的时候,要先去弄一堆东西出来,然后再培育出我们的东西出来,前前后后加在一起最乐观的情况下,EMR 的资源足够的情况下都需要 30 分钟,这不是我们的问题,是 Hadoop 集群初始化太慢了。今天我们的云版本已经完全拿掉 Hadoop 的情况下,现在最快大概 2 到 3 分钟就可以把一个集群完全性地跑出来,几行命令出来就可以了,这才应该是云上应该有的方式。

image.png

这是怎么使用 Kubernetes,我们现在有很多开源用户,他们在生产,已经把这块东西注册到他们内部上去了,用得还蛮好的,看到很多不错的方式,可以做到无人值守、无人运维。

image.png

这还不够,我们现在准备改动最深的一块:存储。之前提到了 Kylin on HBase 方案的诸多局限性,所以我们在商业版里用 Parquet 代替了 HBase。这个方案正在贡献回开源社区,目标是在今年上半年做出来,在下一代Kylin里面就没有 HBase 了,这套东西很复杂,因为存储改变带来的各种调优,确实相当复杂。而且有太多的东西进来以后,你要去做各种妥协,甚至有些场景之间是互斥的,你怎么去做,我们花了蛮多的力气,无所不用其极,压榨最后一分能力。
社区已有 Kylin on Parquet 分支。我们 2018 年底做的简单测试,证明我们把同样的东西放在 Parquet 上和放在 HBase 上,性能上差不多,甚至有些东西 Parquet 好一点,有些东西 Parquet 差一点,但是那时候没有做调优。也就是存储换成 Parquet 能够跑通我所有的测试,可以全部接得住。所以现在我们在紧锣密鼓地做这个事情,这还是蛮有挑战的。

image.png

最后一块,前面的五步做完了之后,扔到云上去就可以了,还差一块,也就是查询引擎。其实做到这个地方,作为一个分析的工具,SQL 的查询引擎是最难的,SQL 的查询引擎我们最早用的是 Apache Calcite, Calcite 应该是现在业界用得最多的 SQL 引擎。

当时我们用起来挺好的,但我们发现在大数据场景下就不行了。SQL 进来,plan 出来,优化好,从存储层将数据拿出来就好了,很快的。但是返回结果集的数据量非常大的场景下,尤其在咱们中国人多,在我们这里,返回来几百万条太正常了。所有的场景,我要把数据取回来,你会发现没有任何办法去缩小最终的数据集。Calcite 是一个单线程的设计,所以这个时候麻烦就大了,底下的存储引擎的计算速度很快,可能十几二十个毫秒就把数据取回来了,结果到Calcite这里是单线程,就只能等 Query 节点的 CPU 资源了,所以还是不合适的。

我们现在花了巨大的力气把它改成了 Spark 的方式,完全变成分布式的。变成这个以后,你会发现以前 cube 是因为存在 HBase 上,它是分布式的,所以我能够在各个节点把数据拉回来。收集完各个节点数据进行 Filter 开始就慢了,因为是单线程的。所以我们改变了一个方式,现在完全是用分布式了,所以你可以看打在上面的 sort 都是分布式的,你不需要在一个进程进行大量数据的 sort。这个情况,今天很多客户说在 Kylin 的节点上会去做优化,但是有时候不能解决性能瓶颈,只有这种分布式方式去做才能根本上解决性问题。但是这块的坑更大,因为这里面太复杂了。我们现在花很多力气,现在也在开发和测试,我们在看是不是可以和社区一起去做,我们把大部分的东西已经做完了。
image.png

2019 年 12 月发布了Kylin 3.0,3.0 是纯实时的架构。我们今年的目标是去做 Apache Kylin 4.0,希望 4.0 能变成真云原生,真实时的一整套。而且我们希望做到更好的一点,叫批流一体化,也就是说一个数据模型不用管数据到底是历史进来还是流式进来,对于业务用户,不应该切换不同的平台,只要去查就好了,只要去用就好了,不需要维护两套。如果我们可以做到前面讲的计划,完全是在云的整个场景下,会大大地降低整个运维难度和使用门槛。

欢迎希望参与打造云原生 Kylin 的同学踊跃联系我们 shaofengshi@apache.org,邮箱主题请备注「参与 Kylin 云原生开发」,下一代 Kylin 等着你~

我们的整体目标,第一是轻量级的架构,在云上我们基本上只会依赖两三样东西:一个是 Spark,这是肯定要的;第二个是 Kubernetes;还有一个是云存储。第二个目标是在云上自动伸缩起停,根据负载来伸缩,而不是一直放在那里。最终就是 TCO ,整个成本要降低下去。

以上是我们对 Kylin 往云原生这个方向转型的思考以及做法,我们非常谨慎,原因在于数据是用户的核心资产,我们非常敬畏这件事情。在转换的过程中,还是需要巨大的工作要去把它做得更加好、更加完善。谢谢各位!


原文链接:https://mp.weixin.qq.com/s/mBLeSlU-IQlYTNe9cOkFVQ


阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区,定期推送精彩案例,技术专家直播,问答区近万人Spark技术同学在线提问答疑,只为营造纯粹的Spark氛围,欢迎钉钉扫码加入!image.png
对开源大数据和感兴趣的同学可以加小编微信(下图二维码,备注“进群”)进入技术交流微信群。
image.png

相关实践学习
基于EMR Serverless StarRocks一键玩转世界杯
基于StarRocks构建极速统一OLAP平台
快速掌握阿里云 E-MapReduce
E-MapReduce 是构建于阿里云 ECS 弹性虚拟机之上,利用开源大数据生态系统,包括 Hadoop、Spark、HBase,为用户提供集群、作业、数据等管理的一站式大数据处理分析服务。 本课程主要介绍阿里云 E-MapReduce 的使用方法。
相关文章
|
6天前
|
存储 SQL 缓存
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
快手 OLAP 系统为内外多个场景提供数据服务,每天承载近 10 亿的查询请求。原有湖仓分离架构,由离线数据湖和实时数仓组成,面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力,替换了 Clickhouse ,升级为湖仓一体架构,并结合 Doris 的物化视图改写能力和自动物化服务,实现高性能的数据查询以及灵活的数据治理。
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
|
13天前
|
运维 Cloud Native 安全
云原生技术:重塑现代IT架构的引擎
在当今数字化时代,企业正面临着前所未有的挑战与机遇。随着云计算技术的不断发展,云原生技术作为其核心驱动力之一,正在彻底改变企业的IT架构和运营模式。本文将深入探讨云原生技术的内涵、特点及其对企业数字化转型的影响,揭示其在现代IT架构中的核心地位和作用。同时,我们还将分析云原生技术面临的安全挑战,并展望未来的发展趋势,为企业在云原生领域的实践提供有益的参考。
|
8天前
|
Cloud Native Java 对象存储
面向未来的架构设计:Spring Cloud和Netflix OSS在云原生环境下的发展趋势
展望未来,随着5G、边缘计算等新技术的兴起,微服务架构的设计理念将会更加深入人心,Spring Cloud和Netflix OSS也将继续引领技术潮流,为企业带来更为高效、灵活且强大的解决方案。无论是对于初创公司还是大型企业而言,掌握这些前沿技术都将是在激烈市场竞争中脱颖而出的关键所在。
21 0
|
3天前
|
Kubernetes Cloud Native 持续交付
探索云原生架构:打造弹性可扩展的应用
【9月更文挑战第29天】在云计算的浪潮中,云原生架构成为企业追求高效、灵活和可靠服务的关键。本文将深入解析云原生的概念,探讨如何利用容器化、微服务和持续集成/持续部署(CI/CD)等技术构建现代化应用。我们将通过一个简易的代码示例,展示如何在Kubernetes集群上部署一个基于Node.js的应用,从而揭示云原生技术的强大能力和潜在价值。
13 6
|
4天前
|
监控 Cloud Native 持续交付
云原生架构:构建弹性与高效的现代应用##
随着云计算技术的不断成熟,云原生架构逐渐成为企业技术转型的重要方向。本文将深入探讨云原生的核心概念、主要技术和典型应用场景,以及如何通过云原生架构实现高可用性、弹性扩展和快速迭代,助力企业在数字化转型中保持竞争优势。 ##
21 6
|
2天前
|
Cloud Native 持续交付 微服务
云原生时代的微服务架构实践
【9月更文挑战第30天】随着云计算技术的不断进步,云原生已经成为现代软件开发的重要趋势。本文将通过深入浅出的方式,介绍如何在云原生环境下设计并实施微服务架构,以及如何利用容器化技术和自动化工具来提升服务的可维护性和可扩展性。我们将一起探讨微服务架构的核心原则、优势,以及在云平台中部署和管理微服务的最佳实践。无论你是初学者还是有经验的开发者,这篇文章都将成为你探索云原生和微服务世界的一盏明灯。
|
5天前
|
运维 Cloud Native 持续交付
云原生架构:构建未来应用的基石
本文将深入探讨云原生架构的核心概念、主要优势以及实际应用案例,揭示其在现代IT领域的重要性。通过详细解析云原生技术的各个方面,帮助读者更好地理解和应用这一前沿技术。
|
5天前
|
监控 Cloud Native 持续交付
云原生时代的微服务架构设计原则与实践
【9月更文挑战第27天】本文深入探讨了在云原生环境下,如何高效地实施微服务架构。通过分析微服务的基本概念、设计原则和关键技术,结合实际案例,指导读者理解并应用微服务架构于云计算项目之中。文章旨在为软件开发者和架构师提供一条清晰的路径,以实现更加灵活、可扩展且易于维护的系统。
|
9天前
|
设计模式 Cloud Native API
云原生时代的微服务架构实践
【9月更文挑战第23天】在这篇文章中,我们将深入探讨云原生环境下的微服务架构设计原则、优势以及实施策略。文章不仅涉及理论概念,还结合具体的代码示例,帮助读者理解如何在实际项目中应用微服务架构。通过阅读本文,你将获得构建、部署和管理微服务的实用知识,为你的云原生项目奠定坚实的基础。
|
4天前
|
运维 Cloud Native Devops
云原生架构下的企业数字化转型之路##
在当今数字化浪潮中,企业如何实现高效、灵活的转型,成为行业焦点。云原生技术以其独特的优势,如容器化、微服务、DevOps等,正引领一场变革。本文将深入探讨云原生技术的基本原理、核心组件及其在实际应用中的案例,为企业提供一条清晰的云原生转型路径。通过分析云原生如何助力企业提升业务敏捷性、降低运维成本、增强系统弹性和安全性,我们将揭示其背后的深刻内涵与广阔前景。 ##

推荐镜像

更多
下一篇
无影云桌面