spark 对于hive metastore的兼容性随笔--通过classloader实现

本文详细剖析了Spark如何通过自定义类加载器实现在不同Hive元数据版本间的兼容,重点讲解了`HiveClient`的创建过程,以及`IsolatedClientLoader`在隔离和版本适配中的关键作用。

背景

接着上次的文章,文章中我们只是简单的提了一下按照官网的配置就能够兼容不同的hive元数据,这次我们从代码级别来分析一下spark是怎么做到实现不同版本的元数据的访问。
注意:正如官网所说的,该部分只是用于hive元数据的访问,spark sql内部编译的其他版本的hive用于来进行其他执行,如序列化和反序列化,UDF和UDAF等等
这里提到这一点是为了释疑一下在源码中看到一些低版本不存在的类,因为这部分spark sql内置了其他版本的hive用于除了hive元数据之外的其他交互,如:hive/hiveShim.scala中的SerializationUtilities 这个类在hive 1.2.1是不存在的,但是hive高版本2.3.7是存在的
我们以spark 3.1.1进行分析

分析

我们知道spark跟外部元数据的交互是类ExternalCatalog来进行响应的,对应到hive元数据就是HiveExternalCatalog,转到client代码:

/**
   * A Hive client used to interact with the metastore.
   */
lazy val client: HiveClient = {
    HiveUtils.newClientForMetadata(conf, hadoopConf)
  }

该client在就是进行元数据交互的最终执行者,且这里直接调用了HiveUtils的newClientForMetadata方法,直接跳到最终调用的方法:

 protected[hive] def newClientForMetadata(
      conf: SparkConf,
      hadoopConf: Configuration,
      configurations: Map[String, String]): HiveClient = {
    val sqlConf = new SQLConf
    sqlConf.setConf(SQLContext.getSQLProperties(conf))
    val hiveMetastoreVersion = HiveUtils.hiveMetastoreVersion(sqlConf)
    val hiveMetastoreJars = HiveUtils.hiveMetastoreJars(sqlConf)
    val hiveMetastoreSharedPrefixes = HiveUtils.hiveMetastoreSharedPrefixes(sqlConf)
    val hiveMetastoreBarrierPrefixes = HiveUtils.hiveMetastoreBarrierPrefixes(sqlConf)
    val metaVersion = IsolatedClientLoader.hiveVersion(hiveMetastoreVersion)

...
} else if (hiveMetastoreJars == "path") {
      // Convert to files and expand any directories.
      val jars =
        HiveUtils.hiveMetastoreJarsPath(sqlConf)
          .flatMap {
            case path if path.contains("\\") && Utils.isWindows =>
              addLocalHiveJars(new File(path))
            case path =>
              DataSource.checkAndGlobPathIfNecessary(
                pathStrings = Seq(path),
                hadoopConf = hadoopConf,
                checkEmptyGlobPath = true,
                checkFilesExist = false,
                enableGlobbing = true
              ).map(_.toUri.toURL)
          }

      logInfo(
        s"Initializing HiveMetastoreConnection version $hiveMetastoreVersion " +
          s"using path: ${jars.mkString(";")}")
      new IsolatedClientLoader(
        version = metaVersion,
        sparkConf = conf,
        hadoopConf = hadoopConf,
        execJars = jars.toSeq,
        config = configurations,
        isolationOn = true,
        barrierPrefixes = hiveMetastoreBarrierPrefixes,
        sharedPrefixes = hiveMetastoreSharedPrefixes)
...

val hiveMetastoreVersion = HiveUtils.hiveMetastoreVersion(sqlConf) 这里直接获取配置的元数据的版本,也就是spark.sql.hive.metastore.version配置项
val hiveMetastoreJars = HiveUtils.hiveMetastoreJars(sqlConf) 这里配置hive元数据jar包的获取方式,默认是builtin内置,推荐使用path方式,因为一般线上环境是无网络环境
val hiveMetastoreSharedPrefixes = HiveUtils.hiveMetastoreSharedPrefixes(sqlConf)
val hiveMetastoreBarrierPrefixes = HiveUtils.hiveMetastoreBarrierPrefixes(sqlConf) 这两个跟classloader有关,也就是说什么类用哪种classloader加载,用来隔离class
val metaVersion = IsolatedClientLoader.hiveVersion(hiveMetastoreVersion) 映射成spark内部的hive版本表示,用于进行元数据class的精细化操作
这里会根据配置的获取元数据jar包的方式而采用不同的初始化IsolatedClientLoader的方式。最终会调用isolatedLoader的createClient方法:

/** The isolated client interface to Hive. */
private[hive] def createClient(): HiveClient = synchronized {
  val warehouseDir = Option(hadoopConf.get(ConfVars.METASTOREWAREHOUSE.varname))
  if (!isolationOn) {
    return new HiveClientImpl(version, warehouseDir, sparkConf, hadoopConf, config,
      baseClassLoader, this)
  }
  // Pre-reflective instantiation setup.
  logDebug("Initializing the logger to avoid disaster...")
  val origLoader = Thread.currentThread().getContextClassLoader
  Thread.currentThread.setContextClassLoader(classLoader)
  try {
    classLoader
      .loadClass(classOf[HiveClientImpl].getName)
      .getConstructors.head
      .newInstance(version, warehouseDir, sparkConf, hadoopConf, config, classLoader, this)
      .asInstanceOf[HiveClient]
  } catch {
    case e: InvocationTargetException =>
      if (e.getCause().isInstanceOf[NoClassDefFoundError]) {
        val cnf = e.getCause().asInstanceOf[NoClassDefFoundError]
        throw new ClassNotFoundException(
          s"$cnf when creating Hive client using classpath: ${execJars.mkString(", ")}\n" +
          "Please make sure that jars for your version of hive and hadoop are included in the " +
          s"paths passed to ${HiveUtils.HIVE_METASTORE_JARS.key}.", e)
      } else {
        throw e
      }
  } finally {
    Thread.currentThread.setContextClassLoader(origLoader)
  }
}

如果未开启隔离性,则直接返回HiveClientImpl,该client所有终端用户共享。如果开启了(默认值),则设置当前的contextClassLoader为classLoader:
该classLoader是自定义的:

...
new URLClassLoader(allJars, rootClassLoader) {
            override def loadClass(name: String, resolve: Boolean): Class[_] = {
              val loaded = findLoadedClass(name)
              if (loaded == null) doLoadClass(name, resolve) else loaded
            }
            def doLoadClass(name: String, resolve: Boolean): Class[_] = {
              val classFileName = name.replaceAll("\\.", "/") + ".class"
              if (isBarrierClass(name)) {
                // For barrier classes, we construct a new copy of the class.
                val bytes = IOUtils.toByteArray(baseClassLoader.getResourceAsStream(classFileName))
                logDebug(s"custom defining: $name - ${util.Arrays.hashCode(bytes)}")
                defineClass(name, bytes, 0, bytes.length)
              } else if (!isSharedClass(name)) {
                logDebug(s"hive class: $name - ${getResource(classToPath(name))}")
                super.loadClass(name, resolve)
              } else {
                // For shared classes, we delegate to baseClassLoader, but fall back in case the
                // class is not found.
                logDebug(s"shared class: $name")
                try {
                  baseClassLoader.loadClass(name)
                } catch {
                  case _: ClassNotFoundException =>
                    super.loadClass(name, resolve)
                }
              }
            }
          }
        }
...

直接重点,对于开启了隔离(默认值),则直接返回该classLoader,关于classloader的知识,可以参考这里,要是还有真不明白的,可以参考classLoader类的源码。
这里我们重点观察一下该自定义classloader的loadClass方法,该方法是实现类隔离的关键,

  • 如果是BarrierClass,比如HiveClientImpl/Shim/ShimLoader,或者包含了自定义的前缀.则从当前的ContextClassLoader中复制一份class类,且生成对应的class
  • 如果不是共享类,也不是BarrierClass,也就是hive类,则使用super.loadClass 来加载类,而最终还是会调用URLClassLoader的findClass方法来加载类
  • 否则不是barrierClass,是共享类,则用当前contextclassloader来加载当前class

通过该classLoader加载的方式,对于跟hive元数据相关的class就是通过该自定义的classLoader加载的(注意子classloader能够看见父加载器加载的类)
之后通过该classloader加载对应的HiveClientImpl类,进行反射实例化HiveClientImpl对象,从而实现了在运行的时候,根据传入的元数据jar包进行动态加载.
重置当前线程的contextClassLoader。

重点:hive元数据的jar包的动态记载是通过自定义classloader实现的

至于真正的和hive元数据进行交互就是HiveClientImpl,该类引入了shim的机制,也就是说,通过该shim机制,对于hive元数据版本的升级都是通过该shim来进行控制,比如增加方法,就会在shim中增加对应的方法,从而达到hive元数据的向后兼容性。 其实从shim这个英文单词中我们也能看出一二,shim(垫片)是为了切合版本的升级而做的垫片。

<think>我们正在讨论Gemini GenAI SDK中的聊天历史功能。由于这是一个特定的技术问题,我将根据一般性的知识和常见的SDK设计模式来回答,因为Gemini GenAI SDK的具体实现细节可能随时间变化,且我没有实时的访问权限。但我会尽量提供通用且可靠的指导。 聊天历史功能通常是指在一个持续对话中,模型能够记住之前的对话内容,从而在后续的回复中保持上下文。在Gemini GenAI SDK中,实现聊天历史管理通常涉及以下几个关键点: 1. **消息传递结构**:通常,每次调用模型时,我们需要传递整个对话历史(包括用户的消息和模型的回复)作为上下文。这样模型才能基于整个对话历史生成回复。 2. **消息格式**:每条消息通常包含角色(如"user"或"model")和内容(文本)。例如: ```json [ {"role": "user", "content": "你好"}, {"role": "model", "content": "你好!有什么可以帮助你的吗?"}, {"role": "user", "content": "告诉我Gemini是什么?"} ] ``` 3. **管理对话历史**:开发者需要维护一个消息列表,每次用户发送新消息时,将新消息添加到历史列表中,然后调用模型生成回复,再将模型的回复也添加到历史列表中。注意,历史记录的长度不能超过模型的最大上下文长度(通常有token限制)。 4. **截断历史记录**:当对话历史很长时,需要截断以避免超过token限制。常见的策略是保留最近的几条消息,或者删除中间的一些消息但保留开头(如系统指令)和最近的对话。 5. **Gemini SDK中的具体实现**:在Gemini SDK中,可能会有一个`ChatSession`类来管理对话状态。例如: ```python import google.generativeai as genai genai.configure(api_key="YOUR_API_KEY") model = genai.GenerativeModel(&#39;gemini-pro&#39;) chat = model.start_chat(history=[]) # 初始历史为空 response = chat.send_message("你好") print(response.text) # 模型的回复 # 继续对话 response = chat.send_message("告诉我Gemini是什么?") print(response.text) # 查看历史 for message in chat.history: print(message.role, message.parts[0].text) ``` 在上面的例子中,`chat`对象会自动维护历史记录。每次调用`send_message`后,用户的消息和模型的回复都会被添加到`chat.history`中。 6. **常见问题**: - **上下文丢失**:如果发现模型没有记住之前的对话,请检查是否在每次发送消息时都使用了同一个`ChatSession`实例,并且历史记录是否正确传递。 - **token限制**:当历史记录很长时,可能会超过模型的最大token限制(例如,gemini-pro模型的最大上下文长度是30720个token)。此时,需要手动截断历史记录(如保留最近的几条消息)或者使用更高级的摘要技术。 - **历史记录存储**:如果需要长期存储对话,可以将历史记录保存到数据库,并在下次对话时重新加载。但要注意,重新加载后,需要确保整个历史记录不超过token限制。 7. **重置历史**:如果需要开始一个新的对话,可以创建一个新的`ChatSession`实例。 8. **系统指令**:在对话开始时,可以设置一个系统指令(system instruction)来指导模型的行为。例如: ```python model = genai.GenerativeModel(&#39;gemini-pro&#39;, system_instruction="你是一个专业的客服助手。") ``` 以上是关于Gemini GenAI SDK中聊天历史功能的基本实现和常见问题处理。具体细节请参考官方文档。 由于这是一个技术性较强的问题,我生成的相关问题将围绕使用中的常见场景和问题: §§相关问题§§ 1. 如何在Gemini GenAI SDK中重置聊天历史? 2. 当对话历史很长时,如何避免超过模型的token限制? 3. 如何将聊天历史保存到数据库并在下次对话时恢复? 4. Gemini模型支持的最大上下文长度是多少? 5. 在Gemini SDK中,如何设置系统指令来指导模型的行为?</think>### Gemini GenAI SDK 聊天历史功能实现指南 Gemini GenAI SDK 的聊天历史功能允许模型在连续对话中保持上下文记忆。以下是关键实现步骤和常见问题解决方案: #### 一、核心实现方法 1. **历史记录传递** 每次请求需将完整对话历史作为上下文传入: ```python from google.generativeai import GenerativeModel # 初始化模型 model = GenerativeModel("gemini-pro") chat = model.start_chat(history=[]) # 初始历史为空 # 首次交互 response = chat.send_message("解释量子力学") print(response.text) # 模型回复 # 后续交互(自动携带历史) response = chat.send_message("用简单例子说明") print(response.text) # 基于上下文的回复 ``` 2. **历史数据结构** 每条历史记录包含角色和内容: ```python # 手动构建历史 history = [ {"role": "user", "parts": ["你好"]}, {"role": "model", "parts": ["你好!有什么可以帮助你?"]} ] ``` 3. **历史管理技巧** - **上下文长度限制**:Gemini 1.5 Pro 支持最大 1M token 上下文[^1] - **历史截断策略**: ```python # 保留最近10轮对话 if len(chat.history) > 20: # 10轮对话=20条消息 chat.history = chat.history[-20:] ``` #### 二、常见问题解决 1. **上下文丢失问题** **症状**:模型忘记之前的对话 **解决方案**: - 检查是否每次调用都传递了完整 `chat.history` - 验证 token 计数是否超限: ```python import tiktoken encoder = tiktoken.encoding_for_model("gpt-4") tokens = encoder.encode(str(chat.history)) print(len(tokens)) # 需小于模型上限 ``` 2. **历史记录污染** **场景**:用户输入包含敏感数据 **清理方法**: ```python def clean_history(history): return [msg for msg in history if not is_sensitive(msg["parts"][0])] ``` 3. **性能优化** - 使用 `stream=True` 流式传输减少延迟 - 对长历史启用摘要功能: ```python summary = model.generate_content("总结对话要点: " + str(history[-5:])) new_history = [{"role": "system", "parts": [summary.text]}] ``` #### 三、最佳实践 1. **混合历史策略** ```mermaid graph LR A[新对话] --> B{历史长度>阈值?} B -->|是| C[摘要前5轮+完整后5轮] B -->|否| D[使用完整历史] ``` 2. **元数据存储** 建议将历史记录与会话元数据(如 session_id)共同存储: ```python # Firebase 存储示例 firestore.collection("chats").document(session_id).set({ "history": chat.history, "last_updated": firestore.SERVER_TIMESTAMP }) ``` > **重要提示**:Gemini 1.5 支持原生文件处理(PDF/Word),可将文档作为历史上下文传入[^1]: > ```python > response = chat.send_message( > "总结此文档", > file=open("report.pdf", "rb") > ) > ```
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值