为什么 tmp 不能替代 Parquet 作为主流数据格式——这个问题这两天在技术群里又冒出来了。问的人大概率是被 .tmp 这个后缀迷惑了觉得它也是一种数据格式那凭什么 Parquet 能当主流它就不行。说实话这个问题问得特别好因为它逼着我们把主流数据格式的底层逻辑拆开看一个格式能成为主流靠的不是名字好不好听而是规范是否明确、性能是否可预期、生态是否足够大。我用大白话先给结论Parquet 是一套有严格规范、专门为分析场景设计的列式存储格式而 tmp 压根不算格式它只是操作系统和应用程序用来标记临时文件的通用后缀里面装什么完全取决于谁创建了它。所以tmp 替代 Parquet这个命题本身就不成立就像问塑料袋能不能替代集装箱一样。这篇文章我会从概念、原理、性能、实操几个角度把这个事彻底讲透最后附上我在真实项目里跟这两种东西打交道的踩坑记录新手看完至少不会再被 .tmp 后缀误导。1. 先把概念捋清楚tmp 到底是什么1.1 tmp 不是格式是一种临时状态标记很多人的误区是把文件后缀当成了格式本身。看到 .tmp 就以为它是一种数据格式就像看到 .doc 认为是 Word 格式一样。但 .tmp 和 .doc 有本质区别.doc 背后有 Microsoft Office 的二进制格式规范而 .tmp 背后什么规范都没有。.tmp也叫 .temp只是temporary file的缩写表示这是一个临时文件。它是程序在运行过程中产生的中间产物用途五花八门程序崩溃时的自动保存内容比如 Word、Excel 的恢复文件下载工具下载到一半的缓存块编辑器给正在编辑的文件创建的副本锁数据库写日志前的临时排序文件安装程序解压出来的安装包部件。你甚至可以自己写一个程序往 /tmp 目录里随便丢一个命名为 x.tmp 的文件内容写什么都不违反任何规范。因为 tmp 根本没有规范可违反。操作系统层面的临时目录Linux 的 /tmp、Windows 的 %TEMP%也是一样它只是一个约定俗成的放临时东西的地方不是一种数据格式。注意这里要区分两件事——/tmp是一个目录xxx.tmp是一个文件后缀。它们都带 tmp但一个是路径一个是文件扩展名。后面会讲到MySQL 报错里的/tmp和 Oracle 安装报错里的/tmp都是目录问题和数据格式无关但很多人把它们混在一起。1.2 为什么 tmp 看起来像是个格式既然 tmp 不是格式为什么总有人觉得它有资格跟 Parquet 比我分析下来有三个原因。第一它有后缀。任何带点后缀的文件都会给人这是一种类型的错觉比如 .log、.bak、.tmp。第二它确实被某些系统当作输出。比如一些 ETL 工具把中间结果默认落成带 .tmp 后缀的文件看起来好像真是一种业界格式。第三搜索引擎tmp 文件用什么打开这类问题很多问题多容易让人误以为它是个常见格式。但只要你较真去查就会发现没有任何一家机构给 .tmp 出过白皮书没有任何一个库叫 tmp format library也没有任何一个开源项目声称我用 tmp 格式存储数据。反观 Parquet有 Apache 基金会的规范文档、有官方实现的 Java/C 库、有专门的测试套件。这就是看起来像格式和真的是格式的差别。为了加深理解我建议新手做一个实验随便找一台 Linux 机器用echo hello /tmp/test.tmp生成一个临时文件然后用file /tmp/test.tmp看一下系统会告诉你这是 ASCII text而不是 tmp format data。file命令不认识 .tmp因为它根本不是一种可识别的类型。这是最直观的验证方式。2. Parquet 凭什么能成为主流数据格式2.1 Parquet 是有标准的列式存储格式Parquet 是 Apache 软件基金会旗下的开源列式存储格式最初由 Twitter 和 Cloudera 合作开发设计灵感来自 Google 的 Dremel 论文里那套嵌套数据模型。它解决的痛点是在大数据场景下传统行式存储比如 CSV、JSON Lines在分析查询时效率太低而列式存储可以大幅减少 IO、提升压缩率。它的文件结构分三层行组Row Group文件按行切成多个行组每个行组包含若干行行组是并行读取的基本单位列块Column Chunk每个行组内部按列存储数据每一列单独存放这就是列式的由来页Page列块进一步切成页页是编码和压缩的最小单位。每个文件末尾还有元数据区记录 schema 信息、各列块的统计信息min/max、null count 等。这些统计信息是后续查询优化的重要基础后面讲谓词下推时还会提到。另外Parquet 天生支持嵌套数据结构不需要把复杂对象拍平。它通过 repetition level 和 definition level 两个概念来还原嵌套关系存出来的文件依然是扁平的列但读出来能还原成原始的嵌套 JSON/对象结构。这一点对现在大量 JSON 数据的分析特别重要。2.2 列式存储赢在压缩率和查询 IO为什么列式存储对分析场景这么重要我拿一个生活化例子说明。假设你有一张全校学生的成绩表一万行、二十列。传统行式存储像一个打印好的成绩册每一页是一行完整的学生信息。你只想统计所有人的数学成绩也得翻完一整本册子把每一页都扫一遍。列式存储则像把册子拆成二十本小册子一本只装一列查数学成绩就只拿数学这本。对应的工程收益有两个列裁剪Column Pruning查询只读取需要的列。比如一张 100 列的大表分析 SQL 只用其中 3 列列式存储可以跳过其他 97 列的数据块IO 直接减少 90% 以上高压缩率同一列的数据类型一致、取值范围相近字典编码、RLE 编码在这种数据上压缩效果极好。我实测过一份 100GB 的 CSV 日志转成 Parquet 加 Snappy 压缩后大概 12GB压缩比接近 8:1如果换 ZSTD 还能再小一些。还有一个细节很多人容易忽略Parquet 的页级统计信息支持谓词下推。比如查询条件带WHERE dt 2024-01-01引擎会先看每个行组的 dt 列 min/max 统计如果发现某行组的日期范围不包含 2024-01-01整个行组直接跳过。这相当于给查询加了快速预览连数据都不用读。实操心得如果你给用户导出一份 50GB 的 CSV他们用 Excel 打开之前得先等半天还可能直接崩。同样是这份数据转成 Parquet配合 DuckDB 或 Trino 查询秒级出结果。这就是列式存储带来的体验差异。2.3 生态才是主流的真正门槛一个格式光性能好还不够要成为主流必须有生态。Parquet 在这点上享有几乎全宇宙的适配计算引擎Spark、Hive、Flink、Presto/Trino、Doris、ClickHouse、DuckDB 都原生支持数据集成DataX、Flink CDC、Airbyte、NiFi 都能直接读写存储服务AWS Athena、阿里云 MaxCompute、Snowflake 等云服务默认推荐 Parquet 作为交换格式编程语言Java/C/Pythonpyarrow、pandas/Go/Rust 都有官方或社区实现。这带来的结果是一份 Parquet 文件在任何一个环节都不会被卡住。你在 HDFS 上写的 Parquet拿到本地用 Python 能读传到云上 Athena 能查塞进 Doris 能导入。这种一次写成、处处可读的体验是 CSV 之外几乎没有其他格式能做到的。另外我还想提一句iq15数据格式这个热词。SAP IQSybase IQ很早就用列式存储做分析型数据库后来被并入 SAP 产品线。这说明列式存储的理念早在 90 年代就在商业数据库里验证过了Parquet 只是把这个理念变成了开放标准让整个生态都能用。所以当你看到iq15 数据格式时要意识到它和 Parquet 是一派的思路而不是说 iq15 是一种文件后缀。3. 正面回答为什么 tmp 替代不了 Parquet3.1 从格式定义看tmp 没有参赛资格这个问题最粗暴的回答是你得先定义清楚 tmp 的格式是什么它才有资格跟 Parquet 比。但正如前面说的tmp 没有规范。它没有文件头标识、没有字段类型系统、没有编码规则、没有压缩算法定义、没有任何版本兼容的约定。而 Parquet 的规范里连一段数据应该用什么编码写在哪个位置读取器该怎么解析都规定得明明白白。规范意味着可预期任何两个不相关的系统只要都遵循 Parquet 规范就能无损交换数据。你见过哪个系统宣称支持 tmp 格式交换数据吗没有因为它根本无从支持。这就像你问为什么便利贴不能替代合同一样——便利贴随手写几个字很方便但合同有法律要件、有签署流程、有格式规范。数据格式的本质就是机器之间的合同没有规范的 tmp 无法承担这个角色。3.2 从存储与查询性能看tmp 毫无胜算就算我们退一万步假设 tmp 是一种格式那它顶多算一种无结构的普通二进制/文本存储。拿它跟 Parquet 比性能等于拿手推车跟高铁比赛。无压缩机制tmp 文件通常就是原始字节磁盘占用是 Parquet 的 5~8 倍无列式布局查询任何字段都得全文件扫描列裁剪、谓词下推这种优化根本无从谈起无统计信息引擎无法知道哪个文件包含哪些数据范围只能老老实实读完整内容再过滤无并行切分能力合理设计的 Parquet 文件支持按行组拆分并行读而 tmp 文件往往是随机写入的字节流切不了片。我在生产环境做过对比同一份 30GB 的明细数据存成临时文件被 Spark 读取做聚合跑完要 40 分钟转成 Parquet 后同样的 SQL 只要 6 分钟。这个差距不是优化手段能弥补的是存储布局决定的。3.3 从数据治理与生态看tmp 一无所有现代数据平台讲究的是可治理、可追踪、可演进。Parquet 在这方面有完整能力Schema 携带文件里本身就带着字段名、类型、嵌套结构读的人不需要额外一份建表语句Schema 演进新增列、删除列不会破坏旧文件老文件依然能读元数据丰富文件级、行组级都有统计数据方便做数据分片、优化和审计生态联通从 Kafka 到数仓、从湖到仓Parquet 都能无缝流动。tmp 文件呢没有 schema、没有元数据、没有版本概念。一个离职同事留下的 .tmp 文件三个月后你根本不知道它是什么程序写的、里面装的是什么结构的数据。这种情况我见得太多了任务跑失败后留下一堆 .tmp 中间文件想排查问题都不知道从哪下手。临时文件之所以叫临时文件就是因为它不该被当作资产保存而主流数据格式的本质是数据资产的标准载体两者的定位天然冲突。3.4 真正该对比的是 Parquet vs ORC vs Avro把 tmp 和 Parquet 放在一起本身就是舆论上的错位。业界真正纠结的取舍是 Parquet、ORC、Avro 之间的选择Parquet列式、压缩高、生态最广适合分析型负载和湖上通用存储ORC也是列式Hive 生态里表现好事务支持和索引更激进但跨生态支持不如 Parquet 普及Avro行式、schema 以 JSON 定义、序列化快适合写密集的流式场景和消息队列持久化。我的选型经验是只要场景是以分析查询为主优先 Parquet如果是流式写入、逐条 appendAvro 更顺手如果深度绑定 Hive 并且吃 ORC 的索引红利那 ORC 也不差。但无论选哪个都不会有人把 tmp 放进这个选项池里因为它不是一个选项。4. 实操场景对比同一份数据走 tmp 和走 Parquet 的差距4.1 场景一离线数仓 ETL 中间结果数仓 ETL 里最常见的操作是从源表抽数 → 清洗转换 → 落结果 → 下游读取。很多新手会图省事把中间结果写成临时文件放到 /tmp或者干脆用自定义的 .tmp 后缀文件。这样做的代价很快会暴露第一下游读取不稳定。你写的是自定义文本格式下游 Spark 脚本得写自定义解析器字段顺序一变全挂。第二没有容错点。如果任务在第三步失败回看中间文件时因为格式不明几乎无法判断数据是否正确。第三性能差。下游要重新全量解析文件没有列裁剪、没有压缩IO 白花花的烧。我当时接手的一个老项目就是这种状态。任务链上有五个步骤中间文件全是一堆 .tmp 文本跑一次全量要三小时而且经常因为某一步的解析器跟写入格式对不上而失败。后来我把所有中间落盘统一换成 Parquet加上 ZSTD 压缩任务时间从三小时压到四十分钟并且任何一步失败都能从上一层的 Parquet 文件直接断点续跑。这就是把临时文件升级成可检查点数据资产的收益。4.2 场景二数据集成与 DataX 对 Parquet 的支持datax hdfsreader支持parquet这个热搜词我很熟悉因为 DataX 是很多公司做离线同步的标配工具。DataX 的 HDFS Reader/Writer 在较新版本里对 Parquet 的支持已经相当成熟配置里通过fileType: parquet和parquetSchema字段来声明。一个典型的 DataX 配置片段hdfsreader 读 Parquet 到 hdfswriter 写另一个 Parquet长这样{ job: { setting: { speed: { channel: 8 } }, content: [ { reader: { name: hdfsreader, parameter: { path: /user/hive/warehouse/ods/detail, defaultFS: hdfs://namenode:8020, fileType: parquet, column: [ { index: 0, type: string }, { index: 1, type: long }, { index: 2, type: date } ] } }, writer: { name: hdfswriter, parameter: { path: /user/hive/warehouse/dwd/detail, defaultFS: hdfs://namenode:8020, fileType: parquet, writeMode: append, compress: zstd, parquetSchema: id string, amount long, dt date } } } ] } }注意几个实操细节fileType必须写parquet否则 DataX 默认按文本处理读出来全是乱码parquetSchema要跟源文件字段顺序一一对应类型不一致时 DataX 会尽力做隐式转换但 date 和 string 之间的转换经常翻车建议提前用preSql处理好字段类型压缩参数compress建议用zstd或snappy不要图省事不压缩否则 HDFS 磁盘会很快报警。为什么 DataX 要支持 Parquet因为在湖仓一体的架构里HDFS 上的事实表几乎统一用 Parquet 存储同步工具不支持 Parquet 就意味着每次同步都要做一次全量文本解析代价巨大。Parquet 在这里扮演的是统一中间格式的角色而这恰恰是 tmp 最想当又当不了的岗位。4.3 场景三Java 里的 tmp 文件与统一返回数据格式tmp在java中的意思也是一个高频搜索词。在 Java 里File.createTempFile(prefix, suffix)会在系统临时目录生成文件默认后缀通常是 .tmp。很多人第一次见这个 API 时以为它在定义tmp 数据格式其实它只是创建了一个用完即走的磁盘临时空间。Path tmpFile Files.createTempFile(myapp, .tmp); Files.write(tmpFile, 一些临时内容.getBytes(StandardCharsets.UTF_8)); // 用完删除 Files.deleteIfExists(tmpFile);这个文件的格式是什么你写什么就是什么——可以是纯文本、序列化对象、JSON、甚至二进制快照。「tmp」在这里只是命名约定不参与任何格式定义。真正对 Java 程序有意义的是统一返回数据格式这个概念。我在后端项目里经常听到有人把统一返回数据格式挂在嘴边比如 Controller 层统一用ResultT { code, message, data }返回 JSON。这里的数据格式是 JSON不是 tmp。为什么没人会用 tmp 做统一返回格式道理跟前面一样返回格式要被人读、被前端解析、被网关校验它需要稳定契约而 tmp 恰恰最没有契约。顺带提一句Java 程序如果频繁往临时目录写大文件要注意两点一是用完必须删除createTempFile不会自动清理二是临时目录空间会被撑爆Linux 的 /tmp 满了之后很多依赖临时文件的功能会莫名失败。我们线上的报错里No space left on device 出现在 /tmp 下的次数比出现在数据盘下的还多。4.4 场景四本地分析与小规模报表最后聊一个很多人忽略的场景本地分析。过去分析师习惯把数据导成 CSV 发给别人但 CSV 既没有类型信息日期全成字符串也没有压缩大一点就卡。现在越来越多的个人分析师开始用 Parquet 做本地数据交换。我自己的习惯是从数仓导出数据时如果下游要的是明细数据我直接导出 Parquet如果对方非要 Excel再在本地用 DuckDB 或 pandas 转一下。DuckDB 读 Parquet 快到什么程度一个 2GB 的 Parquet 文件SELECT count(*) FROM read_parquet(data.parquet)基本一两秒出结果同等数据量的 CSV 要多好几倍时间。# 用 DuckDB 直接查 Parquet duckdb -c SELECT dt, sum(amount) FROM read_parquet(orders.parquet) GROUP BY dt ORDER BY dt; # 用 parquet-tools 看文件元数据 parquet-tools inspect orders.parquet这个场景再次说明只要是数据要被人反复读、被工具链处理Parquet 就是更稳的选择。tmp 在这类场景里只会制造困惑——别人收到一个 .tmp 文件第一反应就是这玩意儿用什么打开然后浪费半小时。5. 常见问题速查与避坑实录5.1 tmp 文件用什么打开这是搜索热度最高的衍生问题答案很简单要看是谁创建的这个 tmp 文件它不存在通用打开方式。三个排查技巧先用file xxx.tmp看文件真实类型。如果是 ASCII text直接用文本编辑器开如果是 gzip compressed data 或 Parquet 之类说明创建方其实写的是压缩流或特定格式只是套了 .tmp 后缀用十六进制查看器看文件头部。比如前四个字节如果是PAR1这其实是个 Parquet 文件被改名成了 .tmp直接用 Parquet 工具打开即可回忆/查证它的来源。如果是 Office 自动恢复文件改名成 .docx/.xlsx 再打开如果是下载工具残留多半是死文件删了就行。在 Java 项目里排查生产事故时我习惯对落盘文件统一加真实格式后缀比如xxx.csv.tmp、xxx.parquet.tmp。这样既保留了写入中的状态标识又不会丢失真实格式信息。永远不要只写 .tmp 三个字母那等于把信息丢进黑洞。5.2 Parquet 文件怎么打开这个问题其实非常简单工具很多我按使用频率排个序工具用途上手难度DuckDBSQL 查询 Parquet最推荐低parquet-tools查看 schema、元数据、转 CSV低pyarrow pandasPython 生态读写中Spark / Trino大规模集群查询中高IDE 插件如 Big Data Tools可视化预览低最快速的上手路径是装一个 DuckDBpip install duckdb duckdb -c DESCRIBE SELECT * FROM read_parquet(data.parquet);如果你只想临时看几行数据用 parquet-toolsparquet-tools head -n 5 data.parquet踩过的坑提醒一句不要用 Excel 直接开 ParquetExcel 不认识它会报二进制格式错误。正确的流程是用工具转成 CSV 再进 Excel。5.3 MySQL 报错里的 /tmp 是怎么回事热搜词里有一条error 2002 (hy000): cant connect to local mysql server through socket /tmp/mysql.sock。很多人看到/tmp又开始联想了觉得是不是数据格式问题。不是这是 socket 路径问题。MySQL 客户端连接本机时默认走 Unix socket路径通常在/tmp/mysql.sock。报这个错大概率是MySQL 服务没启动socket 文件路径配置不一致服务端socket/tmp/mysql.sock客户端却指定了别的路径socket 文件被系统清理或权限不对检查ls -l /tmp/mysql.sock。排查顺序建议先systemctl status mysql看服务状态再mysqladmin -uroot ping测连通最后看 my.cnf 里的 socket 配置。这里的 tmp 只是一个目录名跟数据格式半毛钱关系都没有但它和tmp文件用什么打开这类搜索词混在一起恰恰说明大家对 tmp 的认知确实模糊。5.4 Oracle Grid 安装时的 /tmp 目录报错再提一条热搜prvf-7546 : the work directory /tmp/gridsetupactions2026-09-24_04-14-35pm/...。这是 Oracle Grid Infrastructure 安装时被 /tmp 目录卡住。原因通常是/tmp 空间不足Oracle 解压安装包要大量临时空间/tmp 挂载选项不允许执行文件比如noexec导致安装程序无法运行目录权限不对。解决方向清理 /tmp 释放空间或者把临时目录改到别的位置设置TMP/u01/tmp、TMPDIR/u01/tmp再重跑安装脚本。我自己装 RAC 时遇到过一次 /tmp 只有 2GB 的情况后来统一把安装临时目录指向单独的大分区再也没被 PRVF-7546 折磨过。这个案例进一步说明tmp 是运行空间概念不是数据格式概念。把运行空间和数据格式混为一谈才会产生tmp 能不能替代 Parquet这种问题。5.5 格式选型决策参考最后给一张实用决策表是我这几年做数据架构时反复用的判断逻辑你的场景推荐格式原因长期存储的分析明细数据Parquet压缩高、查询快、生态全流式写入、消息队列持久化Avroschema 演进友好、序列化快Hive 深度绑定、重索引场景ORC事务和索引能力强单机小数据、给人看的交付物CSV / Excel工具兼容、人类可读进程内临时中转、用完即删直接内存或用系统临时文件不追求格式规范任何需要长期依赖的数据资产绝不选 tmp没有规范就没有未来判断标准就一句话这份数据要不要被其他程序、其他团队、其他时间点的人重复使用要的话就必须选择有规范、有生态的格式。临时文件可以随手扔进 /tmp但如果它有价值请尽快让它转正成 Parquet。我个人在实际项目里被 .tmp 文件坑过太多次最惨的一次是花了整整一天去猜一个离职同事留下的一堆 .tmp 文件到底是什么结构最后用十六进制工具一点一点还原出来才发现是带表头的自定义文本。自那以后我给自己定了一条铁律所有落盘文件命名必须带真实格式后缀所有超过 24 小时还需要保留的文件一律转成 Parquet 存到正式存储。希望你看完这篇别再对被 .tmp 后缀伪装的文件抱有不切实际的幻想——它当不了主流数据格式但这恰恰是好事因为真正的数据资产值得用更靠谱的格式来承载。