Kyuubi项目中Trino引擎会话配置错误问题分析

在Kyuubi项目的Trino引擎实现中发现了一个重要的配置处理错误，该错误会导致引擎级别的配置被错误地当作会话级别配置使用，可能引发严重的配置混淆问题。

问题背景

Kyuubi是一个分布式SQL查询引擎，支持多种后端执行引擎，其中包括Trino(原PrestoSQL)。在Kyuubi的架构设计中，配置分为多个层次，包括：

1. 系统级别配置
2. 引擎级别配置
3. 会话级别配置

这种分层设计允许不同层级的配置相互隔离，确保用户会话的独立性。

问题描述

在Trino引擎的会话实现类TrinoSessionImpl中，存在一个错误的配置获取逻辑。具体表现为：

// 错误的实现：使用sessionManager.getConf作为会话配置
val trinoConf: TrinoConf = new TrinoConf(sessionManager.getConf)

而实际上，TrinoSessionImpl在构造函数中已经接收了正确的会话级别配置参数：

class TrinoSessionImpl(
    handle: SessionHandle,
    user: String,
    password: String,
    conf: Map[String, String],  // 这是正确的会话级别配置
    sessionManager: TrinoSessionManager)

这个错误会导致：

1. 会话级别的自定义配置无法生效
2. 所有会话都会继承引擎级别的配置
3. 破坏了Kyuubi的多租户隔离设计

影响范围

该问题影响Kyuubi主分支(master)版本的Trino引擎功能，可能导致以下场景出现问题：

1. 不同用户会话无法使用独立的配置
2. 敏感配置可能在不同会话间泄露
3. 配置覆盖和优先级管理失效

解决方案

正确的实现应该是使用构造函数传入的conf参数作为会话级别配置，修正后的代码逻辑应为：

// 正确的实现：使用构造函数传入的conf作为会话配置
val trinoConf: TrinoConf = new TrinoConf(conf)

这种修改确保了：

1. 会话级别的配置隔离性
2. 用户自定义配置的正确应用
3. 符合Kyuubi的整体架构设计

技术启示

这个问题提醒我们在开发多层级配置系统时需要注意：

1. 明确区分不同层级的配置来源
2. 在代码中清晰地标注配置的获取路径
3. 对配置系统进行充分的单元测试
4. 在架构设计文档中明确说明各层配置的作用域和生命周期

对于使用Kyuubi Trino引擎的用户，建议关注该问题的修复版本，确保在升级后验证会话级别配置的正确性。