Hive 里的 `split` 函数本质上是一个字符串切分工具：它按照指定的分隔符将一段文字拆分成多个部分。在处理普通文本文件时，这个函数操作起来比较顺手；但一旦涉及压缩文件，情况就会变得复杂。许多用户曾在此处遇到问题，下面梳理几个关键要点。
自动解压机制
首先明确一点：Hive 在读取压缩文件时会自动进行解压。无论是 `.gz` 还是 `.zip` 格式，Hive 都会先将数据解压到内存中，然后才进行处理。因此，使用 `split` 函数时不需要额外编写解压逻辑，这一点相对友好。
分隔符选择
第一个容易出错的环节是分隔符的选择。压缩文件中的数据到底使用什么分隔符（逗号、制表符、竖线等）？必须与文件的实际格式保持一致。如果分隔符设置错误，`split` 切分出的结果会全部错位——数据字段混乱、内容张冠李戴，排查起来非常耗时。
字符编码
字符编码是另一个常见陷阱。Hive 默认以 UTF-8 编码处理数据。如果压缩文件中的实际数据使用 GBK 或其他编码，那么解析结果可能会出现乱码，甚至直接导致解析失败。此时可以通过手动设置参数 `hive.exec.compress.output.encoding` 来指定输出编码，不要依赖 Hive 自动猜测，而是由你明确告知系统。
行处理逻辑
行处理也是一个容易被忽略的细节。Hive 按行读取文件，压缩文件解压后同样逐行读取。因此，`split` 函数处理的是每一行的内容，而不是整个文件。如果某行数据被压缩成一大段文本，或者试图对整个文件做切分，就极有可能产生意料之外的 bug。
内存管理
最后是内存管理。压缩文件解压后的体积往往大幅膨胀——一个 200MB 的 `.gz` 文件解压后可能变成 2GB。如果 Hive 任务的内存配置不足（例如 `mapreduce.map.memory.mb` 或 `mapreduce.reduce.memory.mb` 设置过小），就会导致 OOM（内存溢出）。这不是危言耸听，在生产环境中，许多跑批任务正是因为这个问题而挂掉。
总结
使用 `split` 函数处理压缩文件时，关键在于对齐：分隔符要对、编码要对、行处理逻辑要对、内存分配也要对。只要这几个要点都盯住了，剩下的就是 Hive 自动解压，你只需等待结果即可。
