分享嘉宾：姚琴网易数帆技术专家
洪冬冬中国移动云能力中心软件开发工程师
编辑整理：牛红艳
出品平台：DataFunTalk
导读：在云原生+大数据的时代，随着业务数据量的爆炸式增长以及对高时效性的要求，云原生大数据分析技术，经历了从传统数仓到数据湖，再到湖仓一体的演进。本文主要介绍ApacheKyuubi技术架构，及Kyuubi在移动云的应用场景。
今天的介绍会围绕下面五点展开：
Kyuubi系统简介
Kyuubi架构解析
Kyuubi使用场景
Kyuubi开放社区
Kyuubi在移动云的实践
01Kyuubi系统简介首先，让我们来认识一下Kyuubi。
Kyuubi的中文译名是“九尾狐”，狐会喷火，用来致敬ApacheSpark，九代表多租户能力，最后的BI揭示我们最初面向的是大数据的BI场景。所以我们的图标是一只狐狸。
Kyuubi是一个ThriftJDBC/ODBC服务，目前对接了ApacheSpark计算框架，支持多租户和分布式等特性，可以满足企业内诸如ETL、BI报表等多种大数据场景的应用。
Kyuubi的服务层提供JDBC等标准化的接口，隐藏底层计算框架、存储系统，开箱即用，用户无需编写和配置Spark程序，大大降低用户使用门槛。
我们通过Kyuubi的引擎层封装完整的SparkSQL能力，提供高性能的大数据分析处理能力。首先，它可以Runanywhere，既可以支持跑在传统的YARN集群上，也支持K8s集群；其次，通过SparkSQLDataSourceAPI的强大能力，可以让我们轻松的将传统大数据数仓和数据湖框架串联起来，构建湖仓一体。最后，通过服务化，SQL化的方式提供大数据处理能力，也可以大大提升底层开发运维同学的工作效率。一方面可以更加方便的去诊断和调优，另一方面可以做充分的鉴权认证，保证数据安全，也可以简化部署、升级等日常运维工作。
所以，从现阶段的核心能力来说，Kyuubi提供了一个兼容HiveServer2协议的接口，加上在SparkSQL之上构建多租户、多应用服务的能力，可以让用户以“服务化”的方式运行Spark的各种数据计算任务。
从社区当前阶段的发展目标来看，它的主要方向是依托本身的架构设计，围绕各类主流计算框架，打造一个面向ServerlessSQLonLakehouse的服务，支持更加丰富的大数据场景应用。在接入侧，社区除了完整的对接了传统Hive数仓生态，也在尝试提供RESTAPI和MySQL协议的支持。在计算侧，也在尝试对Flink、Presto等计算框架的支持。在存储侧，我们也对所有的数据湖框架完成了支持。大家可以前往我们的Github地址进一步了解社区的动态。
02Kyuubi架构解析接下来，介绍Kyuubi的实现架构。
在这之前，我们先来看看SparkThriftServer的实现和存在的问题。从狭义的角度来讲，我们可以认为Kyuubi是SparkThriftServer的增强版本。在易用性上，Spark社区一路用RDD替换MapReduce，简化了大数据编程逻辑，接着又上了DataFrame来屏蔽了RDD的底层细节，进一步降低编程难度，而ThriftServer的出现则进一步让它变得“开箱即用”，用户无需Spark编程基础，直接用SQL就可以进行交互式数据分析。
但是，它在带来便利的同时，不足之处也是比较明显的。
首先，它是“服务”于“计算引擎”完全耦合的“单”应用。它响应客户端Session和Operation等请求，完成对SparkSession实例的新建及SQLAPI的调用，然后所有的计算调度交给一个SparkContext单例来完成。单应用导致了它只能在使用单条队列的资源，无法通过YARN、K8s这类资源管理器做资源隔离。这与我们线上普遍为不同的产品线或者团队划分不同队列是大相径庭的。同时它只有一个SparkDriver，负责所有的SQL编译，DAG调度，容易过载，任务之间很容易相互影响。
一个Spark应用只有一个全局的用户，所以它本质上是一个单租户系统，对于一些数据安全级别比较高的场景，它并不适配。
此外，作为一个“常驻”的服务，没有“高可用”的支持导致了它客户端并发能力受限，且容易造成单点故障，不适用于大规模的生产落地。
为了突破SparkThriftServer架构上的限制，实现“服务”与“计算引擎”的解耦，并引入多租户及高可用等能力，我们引入了常驻的KyuubiServer进程，可定义生命周期的Kyuubi引擎，及两层的服务发现模块。Kyuubi引擎的实现逻辑和SparkThriftServer如出一辙，不同的是它可以通过client/cluster模式提交，IP和端口都是随机的，所以额外加上了做服务发现的客户端，用于将自己暴露给Server和对应的租户。KyuubiServer本质上也共用了引擎的设计和抽象。在具体的实现上，针对连接请求，我们在Server端裂变成了两类操作，一个是引擎类型的操作，包括发现逻辑和新建逻辑，这为多应用提供了基础。另一个Session本身的连接逻辑，我们将它重定向至被发现的引擎上。服务发现模块目前也支持外置的Zookeeper，Server就可以负载均衡的方式实现高可用。
前面讲到了对服务端Session请求的特殊处理让Kyuubi架构获得了多应用多引擎的能力。而Kyuubi多租户的设计则是为了在保证租户隔离的大前提下，合理的隔离和共享这些引擎。数据结构EngineSpace，是一个简单KV，其中value是引擎的随机地址，key则包含多个部分，ServerSpace用于隔离不同的Kyuubi集群，Version用于版本隔离，防止兼容性问题，ShareLevel是共享策略，应对不同工作负载，EngineType用于隔离不同计算框架，EngineUser用于隔离租户，Subdomain是用户自定义的隔离字段。KyuubiServer拿着客户端连接请求中的认证信息、配置信息生成对应的Key，当我们能通过key获取到对应的引擎实例，就可以实现对该引擎实现共享，否则，就会进入引擎启动的逻辑，这个过程中，服务端会把Key传递给引擎端，引擎完成初始化后，会在EngineSpace中插入自己的信息，这时服务端就可以拿到这个信息完成对应的连接了。
Kyuubi通过服务注册发现实现负载均衡，来获得高可用能力和高客户端并发能力。作为一个常驻的服务，不可避免的会遇到各种计划内或者计划外的停服事件，比如服务端的各类硬件或者软件故障，升级操作等。通过服务注册发现机制，我们对计划内的维护升级操作，可以实现“平滑下线”。对计划外的单点故障，可以提供客户端重试的机制，保证任务的容错能力。同时，在高可用模式下，引擎依然遵循Kyuubi多租户的对应关系来实现隔离和共享。
综合引擎启动耗时、单引擎的负载能力，集群整体资源利用率等因素，并为了满足不同大数据工作负载对资源隔离共享，稳定性性能、响应时间的不同诉求，我们引入了不同粒度的引擎隔离共享策略。分别是基于连接、用户、用户组和Server四个粒度。举例来说，基于连接的共享模式，连接和引擎是一对一的关系，每个连接都有一个自己的独立引擎，其他任何人或连接都无法访问。这种模式可以提供良好的隔离性使得它也可以胜任一些大型的批处理作业。在这种模式下，连接关闭时，引擎会及时关闭，释放所有计算资源。再比如，基于用户的共享模式，默认情况下，用户和引擎是一对一的关系，每个用户都有一个自己的独立引擎，其他任何人都无法访问，而来自同一用户的连接则可以复用这个引擎。对于一个分析师来讲，他所有的连接只有一次包含比较耗时的引擎启动，其他的都可以快速响应，可以比较愉快的进行交互式分析。
对于一个多租户集群而言，为了较好的提升集群整体的资源利用率，除了可以充分利用YARN和K8s等资源调度管理服务的能力之外，对于单个引擎而言，我们也实现了二级的资源弹性能力。在引擎之上，我们合理设置引擎的空闲TTL时间，来实现它的资源复用和回收。在引擎之内，我们可以开启Spark提供的动态资源分配功能，合理设置最大可分配Executor个数及Executor空闲TTL，来实现Executor的资源复用和回收。
从服务化的角度，弹性资源的能力让我们可以根据作业实际的负载去申请和使用资源，而Spark3.0之后引入的自适应查询引擎则可以让这个过程更加的“智能”。它可以利用中间计算结果的统计信息，进一步优化后续的执行计划，实现动态合并Shuffle分区、动态选择Join策略、动态的处理Join中的数据倾斜问题等。我们内部在实践和落地这个特性的时候，也发现了不少的问题，很多优化根据“上游优先”的开源玩法，我们都推到了Spark社区中。而一些更加符合Kyuubi场景的特性或者暂时合不进去的，都以可扩展插件的方式在Kyuubi社区中维护。比如对于合并分区规则，一个静态的推荐合并大小参数，一方面很难在各种复杂算子间取得平衡，另一方面对于写场景，通常我们期望一个较大的参数值来规避小文件的产生，在这种情况下，中间过程的并行度也会收到影响，影响整个作业的性能。对于这个问题，Kyuubi引入了Stage级别的配置隔离策略，单独对最后Stage的参数进行配置，同时保证中间并发和最终文件的输出大小。其他，我们还引入增加数据倾斜命中的规则、Z-Order索引等拓展。此外，Kyuubi也支持用户在Spark所提供的可扩展点上的任意自定义扩展。
03Kyuubi使用场景在第三部分，我们简单介绍下Kyuubi的使用场景
我们在社区的Github讨论区有一个编号为的的单独讨论帖，来收集用户的使用场景。总的来说，大部分的用户都采用Kyuubi来替换HiveServer2来提升性能，弥补SparkThriftServer在场景和拓展能力上的不足。其次，是基于Kyuubi加SparkonK8s的能力提供大数据上云的能力，实现离线在线业务混部，降低IT设施的总拥有成本。最后，是整合Hudi、Iceberg等数据湖框架，搭建数据湖分析平台。从目前的讨论帖登记情况来看，Kyuubi在不同行业的很多公司都有成功的落地实践，比如视频领域的B站和爱奇艺，提供云上大数据服务的腾讯云和中国移动移动云，T3出行的ApacheHudiPMC杨华老师团队也整合Kyuubi和Hudi打造了T3的数据湖平台。这些社区用户中，也涌现了不少社区贡献者，同时，我们在这些案例分享中，也吸收了不少灵感。欢迎大家来使用Kyuubi项目并与社区分享你们的实践案例。
04Kyuubi开放社区最后，我们来简单回顾下Kyuubi开放社区的建设和发展。
Kyuubi最早在年从网易魔改的内部Spark分支中独立出来并开源，一直遵循ApacheLicence2.0版本开源协议。最初的目的是为了引入多租户能力，满足Spark权限控制的需求。年低，完成了新架构的设计和对Spark3.0的支持，应用场景也更加丰富，这些变化带来了不少新用户和贡献者。Apache软件基金会是全球最大的开源组织之一，很多知名的大数据项目如Hadoop/Spark/Hive等都在其指导下孵化成为顶级项目，Kyuubi和这些项目的生态关系，也为了社区的进一步，让我们社区有了进入Apache社区孵化的想法。年6月，这个想法成为现实，我们顺利进入Apache软件基金会孵。Kyuubi进入Apache基金会的目的是希望在Apache基金会的帮助下，构建一个厂商中立的多元化社区，推动Kyuubi项目的发展。在年的上半年，在社区小伙伴的共同努力下，我们成功发布了1.3.0、1.3.1和的1.4.0一共3个Apacherelease版本。
“CommunityOverCode”/“社区大于代码”是Apache不变的宗旨，它是一种鼓励长期协作和保持项目稳定的方式。ApacheKyuubi社区希望有兴趣的小伙伴可以加入我们，你可以分享你的实践案例，订阅邮件列表
联系电话：