共计 8062 个字符，预计需要花费 21 分钟才能阅读完成。
随同着国家产业降级的推动和云原生技术成熟，多点 DMALL 大数据技术也经验了从存算一体到存算拆散的架构调整变迁。本文将从引入 Kyuubi 实现对立 SQL Proxy 的角度讲述这一摸索实际的历程。
多点 DMALL 成立于 2015 年，提供一站式全渠道数字批发解决方案 DMALL OS，目前已与 130+ 连锁批发企业、近 1000 家品牌达成单干，笼罩 5 个国家和地区。作为一站式全渠道数字批发解决方案服务商，多点 DMALL 通过数字化解构重构批发产业，提供端到端的商业 SaaS。计划整体涵盖了从商品抉择、供应商引入、仓储供应链治理、门店经营、用户精准营销的整个产业链，实现了人人、事事、物物在线。
Apache Kyuubi 是网易数帆发动开源的一个分布式和多租户网关，用于在 Lakehouse 上提供 Serverless SQL，社区目前已汇集海内外百余名贡献者。
作为 DMALL OS 数字化能力的技术底座，大数据平台历经屡次迭代安稳撑持了公司 To B 业务的发展。随同着国家产业降级的推动和云原生技术成熟，多点 DMALL 大数据技术也经验了从存算一体到存算拆散的架构调整变迁。本文将从引入 Kyuubi 实现对立 SQL Proxy 的角度讲述这一摸索实际的历程。
技术背景
行业技术发展趋势
第一代的大数据技术次要采纳传统 Hadoop 开源技术栈，简直所有的企业搭建大数据集群都是从 HDFS、Hive 和 YARN 开始的。除了 Apache 开源组件组合外，许多企业也会选用 CDH、HDP 等商业发行套件，不便运维和部署。随着技术的成熟，传统的 Hadoop 技术开始裸露一些毛病：
1. 部署运维老本高
Hadoop 生态组件所需根底硬件资源较多，组建集群时须要谨慎设计和调整，部署老本高，前期运维复杂度高。
2. 集群隔离，资源节约
大数据集群部署时经常须要独自申请机器，与业务服务集群资源隔离。总体来看，两个集群的潮汐景象都存在，大数据集群白天较为闲暇，业务服务集群夜间用户使用量低，隔离部署的形式会产生较大资源节约。
3. 存储老本继续升高
大数据集群的数据量是始终增长的。纵使企业做了冷热拆散的设计、定时归档的解决，也只是减缓了增长趋势，仍旧无奈解决存储老本始终升高的现状。当然，除了上述毛病，还有 NameNode 元数据压力过大、组件版本互相制约等问题。这些毛病对于企业外部应用尚且能够优化解决，然而作为一家须要为客户提供定制化服务的企业，尤其面对日益突出的“性能”、“老本”、“平安”、“稳定性”等外围问题，多点 DMALL 意识到必须做出扭转。
To B 的大数据平台建设趋势
To B 的企业商业逻辑和 To C 的差异很大，在大数据畛域的差异更大。
1. 精密的老本治理
To C 的大数据平台使用者多是企业外部员工。应用大数据平台产生的老本独自计算，个人用户不会为这些资源耗费间接买单。但在 To B 模式下，使用者根本都来自 B 端企业客户，客户要为其资源应用付费。这就意味着作为服务提供商须要精细化老本，尽最大可能降低成本能力取得客户的认可。
2. 更低的应用门槛
企业外部应用的大数据平台，员工背景可控。To B 的大数据平台面对的环境要简单很多。客户以后的信息化水平、员工技能等都不雷同，大数据平台须要提供更多形式、更低门槛来帮忙客户的应用。
3. 更快的交付效率
须要进一步简化技术架构和实现，采纳标准化的伎俩小时级交付新环境，节省时间同时进一步升高后续运维难度。这样当前逐步造成疾速规模化复制的能力，输入批发数据中台解决方案。
多点 DMALL 的大数据技术倒退
上述技术背景和商业背景的倒退，对多点 DMALL 的大数据技术基座继续提出更高的要求。在继续优化降级的过程中，多点 DMALL 的大数据集群架构经验了从传统 Hadoop 生态迈向云原生，从存算一体到存算拆散的架构变迁。
接下来，咱们将具体讲述这一变迁的背景及其设计，以及 Kyuubi 在其中承当的角色和优化实际。
存算一体架构下的即席查问优化
架构背景
与其余大部分企业一样，多点 DMALL 最开始采纳的是传统 Hadoop 技术栈构建数据中台 UniData，强依赖 CDH 发行版，采纳 IDC 物理机 / 云主机集群部署。在即席查问中，咱们采纳自研的对立平安网关 UniSQL 连贯用户和底层引擎。UniSQL 可为用户提供平安校验、血统采集、SQL 审计、限流、白名单、查问降级、查问后果限度等平台管控级性能，最后只反对对接 Impala 和 Hive 查问引擎。很显著基于查问速度的劣势，平台用户会优先选择 Impala 作为查问引擎。随着平台的推广和用户量的减少，咱们发现这样的架构存在不少问题。
1. Impala 资源缓和
Impala 的资源缓和景象越来越频繁，因其自身资源隔离较为简单，也没有 HiveServer2 提供的原生查问条件管制等，使得整体可用性升高。尽管咱们在优化中通过平台层面补救进行局部 SQL 的拦挡，然而仍然无奈齐全阻挡局部占用大量资源的 SQL 执行。
2. Hive 查问速度不佳
相比于 Impala，Hive 查问速度不佳，用户体验较差。一方面，MapReduce 工作会产生大量长期小文件，影响运维人员的判断；另一方面，MapReduce 工作报错经常很费解，用户从 Hive 执行日志中无奈间接获取，须要运维人员去 YARN 治理页面搜寻查问详细信息，带来较大的运维老本。
3. YARN 集群潮汐景象重大
如图所示，YARN 所在的集群是为大数据独立搭建的基于 IDC/ 云主机的集群。实际中发现，YARN 集群的潮汐景象非常明显，凌晨时分随同着大量离线工作的启动，集群资源十分缓和；白天任务量很少，Impala 的大量应用意味着 Hive 查问量少，集群总体使用量较为闲暇。基于上述的起因，咱们思考引入 SparkSQL 作为即席查问的另一个可选项，在 Impala 资源缓和时，将 Impala 的查问资源疏导入 YARN 集群中，同时缩小 Hive 的查问以晋升用户整体的查问速率。选型过程中 Kyuubi 进入了咱们的眼帘。
### 架构设计
事实上，这不是咱们第一次调研 Kyuubi。早在 Kyuubi 正式开源时，咱们便尝试引入 Kyuubi 作为多租户代理工具，刚巧赶上过后公司技术倒退方向的优先级调整，这一尝试临时搁置。起初在需要的驱动下，咱们开始从新引入 Kyuubi，这时 Kyuubi 曾经到了 1.5.2 版本。现行的架构曾经稳固在多个集群运行，为了尽可能减少架构调整，保障引入过程中集群其余工作及服务的稳定性，最终引入 Kyuubi 后即席查问波及的总体架构图如下：
### 优化摸索
线上环境中曾经有 UniSQL 作为对立平安网关，Kyuubi 所承当的角色仅聚焦于多租户的 Spark SQL 代理。为了适配其余底层组件等起因，咱们对 Kyuubi 进行了局部调整：
1. 在现有的 CDH 环境下，为了匹配 Sentry 的权限管控和 YARN 的资源调度，咱们批改了 Kyuubi 提交 Spark 的执行命令，不应用 proxy-user 和 -queue 的参数，间接切换用户提交；
2. 因为平安组件应用 Sentry 进行权限管控的，在网上也没有开源产品能够提供 SparkSQL 基于 Sentry 的校验，咱们只好独自适配实现了针对 Sentry 的 Spark Extension；
3. 基于 Kyuubi 提供的 kyuubi.engine.initialize.sql 参数，将咱们原来为 Hive 和 Impala 提供的 UDF 迁徙到 SparkSQL 服务中，Kyuubi 在初始化 Spark 时便主动加载对应的 jar 包和 Function，用户切换引擎时应用无感知；
4. 为了不便用户从 Impala 切换到 Spark SQL 查问，咱们定制化反对了局部 SQL 语法，例如 invalidate metadata 进行元数据被动刷新等；在用户的应用中，咱们也进行了一系列参数优化。例如设置 spark.files.overwrite=true不便局部用户反复提交 jar 包以及测试自定义 UDF 函数；设置 spark.sql.autoBroadcastJoinThreshold=-1 敞开主动 Broadcast 以进步稳定性等。
### 遗留问题
在原有架构中，咱们以最简略的形式引入 Kyuubi，为客户提供了另一种查问引擎的可能，然而这样的引入很显著存在其短板：
1. JDBC 链路太长
用户从发动的 JDBC 连贯到最终开始执行 SQL，两头须要别离通过 UniSQL 和 Kyuubi 服务。多个连接池的治理晋升了总体的连贯治理复杂度，在报错时更是不易剖析查找。有赖于 Kyuubi 和 UniSQL 的稳固，在理论应用中暂未发现因多个连接池连贯导致的重大影响，但危险和隐患仍旧存在。
2. SQL Proxy 角色重叠
同为 SQL Proxy，UniSQL 和 Kyuubi 的角色存在重叠，很显著这样冗余的设计并不利于将来架构的倒退。
3. Spark 版本不对立
基于历史起因，现有架构中咱们为用户提供的是 Spark 2.4.6 和 Spark 2.3.1 版本，然而 Kyuubi 是须要搭载 Spark 3.x 版本。引入 Spark SQL 查问，又不能贸然将之前的版本“一刀切”，咱们只好临时独自为 Kyuubi 部署 Spark3.x 版本。这就造成当初集群中存在不对立的 Spark 版本，减少运维的难度。
4. Zookeeper 版本不对立
咱们应用的 CDH 发行版版本为 5.16.2，搭载版本为 3.4.5 的 Zookeeper。Kyuubi 的 HA 同样须要依赖 ZooKeeper，然而通过咱们测试，应用 3.4.5 的 Zookeeper 会呈现删除节点失败的状况，从而导致 Kyuubi Server 主动敞开。通过剖析，这一 BUG 在更高版本中修复结束。最终，咱们只好独自部署 3.6.1 版本的 Zookeeper 供 Kyuubi 应用。
5. Sentry 权限与 Spark 的对接不易
CDH 限定了集群的权限治理服务为 Sentry。家喻户晓，Sentry 的设计架构简略，缺失更细粒度的权限管制，包含视图、行、列等。而且 Spark 没有原生反对 Sentry 的权限管控形式。尽管咱们开发了针对 Sentry 的 Spark Extension 进行权限管控，更细粒度的管控仍旧是咱们很头疼的中央。
存算拆散架构下的对立 SQL Proxy 实际
架构背景
随着多点 DMALL 全面 To B 转型，为越来越多的 B 端客户提供批发全渠道解决方案，须要具备在多云部署环境下提供更具性价比、可复用的大数据底层基座和平台工具链。咱们也终于等到了一个契机，彻底甩开历史包袱，设计搭建存算拆散、轻量级、可扩大、云中立大数据集群架构。
侥幸的是，Spark on K8s 的技术趋于成熟，咱们得以全面拥抱云原生。在 K8s 的基座上，咱们合并了大数据计算集群和业务服务集群，甩开 CDH 的版本限度，剥离 Hadoop 生态的强依赖，充分利用对象存储，简化运维和部署，升高用户应用老本。
思考到上一版架构中的局部遗留问题，在降级架构设计中，通过具体的调研、剖析和选型，Kyuubi 也正式替换 UniSQL 作为 SQL Proxy，负责多套查问引擎的对立代理服务。
降级架构设计
在降级架构中，咱们充分考虑到之前版本不统一的状况，合并并简化了技术选型，使整体架构更轻量级和可扩大：
实际计划
应用 Kyuubi 作为对立 SQL Proxy，那么 Kyuubi 就须要满足之前 UniSQL 为代表的代理服务的全副辅助性能，包含审计日志、实时监控、限流、动静参数批改、权限管控等。因而咱们深刻学习了社区的实践经验和最优举荐，依据场景和需要，欠缺了 Kyuubi 的服务。以下为咱们局部实际后果。
- SQL 审计
作为对立代理层，须要对所有 SQL 和连贯进行具体的记录，包含用户、SQL、执行工夫、执行后果等。这样的数据并非实时应用，而是用于后续回溯查找问题，或者进行用户操作习惯的统计分析。侥幸的是，Kyuubi 提供了 EventHandler 的形式，收集了十分残缺的信息。在 Kyuubi1.6.1 中，反对应用下列参数将相干记录落在本地日志中：
kyuubi.backend.server.event.json.log.path
kyuubi.backend.server.event.loggers本地日志并不不便统计分析，咱们须要更灵便的形式。最终咱们抉择仿照原生 JsonLoggingEventHandler 类，继承 EventHandler 自定义将所需日志写入 Kafka 中。后续再通过大数据平台的性能，落地到 Hive 或其余引擎中用于回溯剖析。
- 实时监控
以后即席查问的应用状况如何、连贯数量、失败起因等，都须要实时监控查看。Kyuubi 提供了十分残缺的指标监控能力，咱们也复用外部运维平台的监控体系，选用了 Prometheus + Grafana 作为实时监控的载体。
相干参数：
kyuubi.metrics.reporters- 限流
不同平台和用户的应用形式不同，容易导致连接数暴发，从而影响 Kyuubi 服务的稳定性。因而，限流是必须要纳入思考的。Kyuubi 提供了局部参数进行限流：
kyuubi.server.limit.connections.per.user
kyuubi.server.limit.connections.per.ipaddress尽管这些参数限度到了单用户的连接数，甚至单用户单 IP 的连接数，然而这些参数是对所有用户对立的，而且 Kyuubi 服务启动后不能动静批改。就咱们的应用教训来看，反对针对不同用户动静设置不同的连贯限度将是一种更灵便的形式。但以后的性能也能根本满足限流管控要求，最终决定针对这个场景咱们不做代码批改，期待社区将来可能提供更精密的管控性能。
- 参数动静传递
线上环境不足适合的形式进行参数传递，这个遗憾在新的架构中得以补救。通过 Kyuubi 提供的自定义动静参数传递形式，实现 SessionConfAdvisor 类后对接配置核心。参数将在每次启动 Session 的时候动静拉取，也能较好的满足不同用户不同资源分配的场景：
kyuubi.session.conf.advisor当然，为了缩小对不同环境参数的自定义 jarb 包治理，咱们调整了传入该类的参数，增加了KyuubiConf，这样不同环境部署的 Kyuubi 主动能够传入对应的配置核心门路等信息，自定义的 jar 包也能够环境无关，缩小代码运维的复杂度。
- 基于 Ranger 的权限校验
甩开了 CDH 对于 Sentry 的强制要求，新的架构选用 Ranger 进行权限管控。因而能够间接应用 Kyuubi 提供的 auth-extension 进行权限校验。不过为了晋升整体的鉴权效率，咱们从新设计了鉴权体系，将鉴权能力集中在新的鉴权服务 RAC 中，防止每一个 Spark 工作都在 Driver 本地落地一份 Ranger 权限策略。在这样的思路下，对于 Kyuubi 提供的 auth-extension 也做了适配性的批改。不过这不影响这个工具的便捷性：
spark.sql.extensions=org.apache.kyuubi.plugin.spark.authz.rangerRangerSparkExtension只不过，就社区的更新速度来看，auth-extension 更新频率很高，咱们在测试中发现了一些问题，包含视图权限、长期 Function 权限等问题，修复后都还没来及脱敏奉献给社区，社区就在 master 分支修复公布了。瞎话说，这也导致咱们的这个插件更新十分苦楚，咱们须要一直批改，一直适配。这也是咱们越来越拥抱社区的起因，只有社区提供了性能，通过测试后咱们便删除自定义代码，不便将来更新，也是尽可能跟着社区一起成长吧。
- 主动合并小文件
Kyuubi 提供的主动合并小文件工具是纯开箱即用的，Spark3.3 版本次要依附 rebalance 逻辑。通过咱们的测试，同样的起源表，同样写出 10 个分区，写出文件从近 2000 个放大到 10 个，落地工夫也从 7min 放大到 40s，不仅升高了集群元数据的压力，更无效晋升了整体工作效率。
spark.sql.extensions=org.apache.kyuubi.sql.KyuubiSparkSQLExtension- 查问条件限度和扫描分区数限度
即席查问中，绝大部分探索性的查问都不须要大量的数据，后果数据量过大会引起 Driver 的压力过大，从而影响查问的稳定性以及用户的体验。社区最新提供了 HTTP 的异步获取的形式，然而这样的形式波及到上下游改变，还在性能测试中。
依照线上环境的教训，咱们将后果条数限度为 1000 条，针对不同的场景，这个参数也能够动静批改，根本满足返回后果要求。
spark.sql.watchdog.forcedMaxOutputRowsHive 反对限度查问 SQL 中分区表必须带分区条件的严格模式，Kyuubi 也提供了相似的性能，可反对管制扫描分区数的限度。只是管制扫描分区数对于不同场景的须要不同，咱们还没有正式利用这个性能，须要在实践中动静增加参数应用。
spark.sql.watchdog.maxPartitions- 服务日志切分
之前运维教训发现，Kyuubi 服务在 logs 下写入的服务日志始终增量写入，发现的时候单文件日志曾经达到了 90G。新架构下咱们吸取教训，批改了 log4j2.properties，将日志按大小和日期拆分，仅保留最近 7 天的日志，彻底解决这个隐患。
- 自由选择资源组
在公司的理论应用中，一个 user 是能够在多个 group 中的，依照 Kyuubi 原生的提供的以 group 为引擎隔离 level 的状况下，会默认取该用户的第一个 group。咱们将其批改成了通过 JDBC 参数能够抉择 group 的能力，当然也包含了安全性校验，不容许歹意应用不属于本人的 group。
- Volcano 调度器的模板文件
Spark 官网文档中针对 Volcano 的调度器应用参数如下：
spark.kubernetes.scheduler.name=volcano
spark.kubernetes.driver.pod.featureSteps=org.apache.spark.deploy.k8s.features.VolcanoFeatureStep
spark.kubernetes.executor.pod.featureSteps=org.apache.spark.deploy.k8s.features.VolcanoFeatureStep
spark.kubernetes.scheduler.volcano.podGroupTemplateFile=podgroup-template.yaml其中，最初这个参数 spark.kubernetes.scheduler.volcano.podGroupTemplateFile 须要是本地的 yaml 文件。咱们针对这个批改了提交命令，反对动静生成模板文件进行提交。
下一步摸索方向
咱们也在依据原始架构中用户的应用反馈，继续优化升级版架构的设计，一直调整打造存算拆散、轻量级、可扩大、云中立的大数据集群。
依据应用反馈，咱们下一步将重点关注以下优化点：
1. 单点引擎稳定性不佳，当一个 SQL 将该引擎查挂后，下次再查问会先报错后启动新的引擎。这对于用户的应用不太敌对。通过钻研社区里其余企业的分享，下一步咱们将关注资源池模式和引擎高可用的设计，以晋升用户的应用友好度。
2. 精细化老本管控是降级架构的重中之重，然而原生的 Spark SQL 无奈将资源拆分到 SQL 粒度。这里也是咱们下一步须要重点冲破的内容，为用户提供清晰的老本数据。
3. 大数据基座上除了咱们提供的大数据平台产品外，常有其余业务零碎申请间接应用大数据相干资源，最典型的就是 JDBC 链接。白名单将是咱们须要重点实现的性能。除了用户登录校验外，还能验证起源平台，对应用起源做出限度。
总结来看，咱们从 Kyuubi 正式开源时开始关注，到现在的 1.6.1 版本，越来越欣慰地发现，每次降级都会有新的性能补充和思考。咱们也在降级中逐步缩小自定义代码，应用 Kyuubi 社区提供的新个性。咱们会继续跟踪社区动静，并将实践经验反哺社区，参加推动 Kyuubi 的倒退。
