做过数据采集的人都知道真正磨人的往往不是采集本身而是采集完之后那堆乱七八糟的格式。上游接口吐的是嵌套JSON内部系统导出的是CSV数仓那边又非要Parquet数据在三种格式之间来回倒腾稍不注意就是字段对不上、精度丢了一截、文件大得离谱。今天就把我在大数据采集项目里做JSON、CSV、Parquet格式转换的经验完整梳理一遍从选型思路到实操细节再到踩过的坑一次说透。1. 三种格式的底层逻辑与选型思路1.1 JSON、CSV、Parquet的本质差异很多新人会把格式转换简单理解成“换一个后缀名”这是最大的误解。这三种格式不是同一个东西换层皮它们的存储哲学完全不同。JSON是半结构化文本格式本质上就是一个带类型的嵌套字符串。它最大的价值是自描述性每个字段叫什么、怎么嵌套、值是什么类型全都写在文件里了不需要外部元数据。所以JSON特别适合上游数据源对接因为API接口返回的数据天然就是JSON拿到就能用结构变化也不怕。但代价是冗余大一个字段名在每条记录里都重复一遍一亿条数据就重复一亿遍存储和解析开销都很惊人。CSV是纯文本表格格式它比JSON更简单就是一个二维表行是记录列是字段没有嵌套没有类型。CSV的优势是通用性极强Excel能开、SQL能导、机器学习库能读几乎所有工具都认它。但CSV没有类型信息你看到2026-01-15不知道它是字符串还是日期看到123不知道是整数还是文本全靠下游自己猜。这种隐性约定在跨团队协作时特别容易出问题。Parquet是列式二进制存储格式它是为分析场景而生的。同样的数据量Parquet的存储体积通常是CSV的十分之一到二十分之一查询时还可以只读需要的列跳过无关数据。代价是Parquet是二进制格式人眼没法直接看也不适合频繁的单行更新而且写入时需要攒一批数据才能高效落盘不适合流式逐条写入。举一个生活化的例子JSON就像旅行时往行李箱里塞衣服每件衣服都挂个标签你知道哪件是什么但空间浪费严重CSV就像一张分好格的衣柜清单整齐但只适合规整物品Parquet则是把所有同色系衣服叠好后按颜色分区存放找某件衣服时只翻一个格子就行。1.2 采集管道各阶段该怎么选格式我在设计采集管道时格式选择的逻辑遵循一个简单原则源端随源落地随用传输随简。数据源对接阶段上游给什么就用什么通常就是JSON。不要在上游做复杂转换因为数据源不可控你要保留原始语义后续才能溯源。采集落地到暂存区时如果管道吞吐量很大建议先转成Parquet落盘因为能大幅减少存储占用和后续重放成本。如果管道只是小批量、临时性采集直接落JSON也可以胜在直观。真正要像选型一样认真决策的是进入数仓或分析层之前的最终格式。这里我的经验是需要明细级查询、与Hive/Spark/DuckDB等分析引擎配合优先Parquet需要给业务方提供可下载的原始数据、或者对方要求用Excel打开提供CSV需要保留API原始响应、或者做事件归档用JSON。还有一个容易忽略的点格式转换在管道里不是一次性动作它会反复发生。比如日志采集回来是JSON清洗后转Parquet入库业务方要数据导出时又从Parquet转CSV。所以你至少要保证这几种转换在两个方向上都跑得通而不是只会单向转换。2. JSON处理灵活性的代价与应对方案2.1 解析嵌套结构时最常见的三类坑JSON最常见的问题出在嵌套结构上。一个订单数据里面有user对象、items数组、items里又有sku嵌套用普通方式解析很容易写出又长又脆弱的代码。我见过最夸张的情况是某上游接口返回的JSON嵌套了七层下游取数的同事不得不写一大串data[order][items][0][sku][spec][color]一旦某个字段缺失就抛空指针整天修管道。第一类坑是字段缺失。上游接口升级后可能加了新字段也可能把某个字段改成了null。对策是解析时永远用安全的取值方式比如Python里用.get()链式取数、Java里用Optional包装或者统一做一层schema校验字段缺失时给出明确报错而不是运行时崩溃。第二类坑是类型漂移。同一个字段这次返回字符串10086下次返回数字10086再下次可能返回浮点10086.0。这在上游是历史包袱在下游却是灾难。我的习惯是在转换层做显式类型归一把这类字段统一cast成目标类型并加上异常计数漂移率超过阈值就告警。第三类坑是超大JSON与深层嵌套导致的解析性能问题。一整个GB级别的JSON文件如果直接一次性load进内存机器立刻吃紧。正确做法是流式解析按记录逐条处理而不是整个文档塞进内存。2.2 高效解析和生成JSON的工程化方案在Python生态里我通常会根据数据量级分三档选方案数据量在几百MB以内用Python标准库的json就够了配合ijson做流式读取。注意json.load()会把整个文件读进内存对大文件必须先json.loads()再逐行处理是错的方向。正确做法是用ijson.parse()做流式解析或者按json.load(open(file))这种内存换简单的方式只适用于小文件。数据量在几GB级别建议上orjson。这是一个用Rust写的JSON库解析速度比标准库快好几倍而且orjson.option.OPT_NAIVE_UTC、OPT_SERIALIZE_NUMPY这些选项能直接处理numpy类型和datetime类型省掉自己写转换器的麻烦。数据量到了几十GB甚至更大就别自己做解析了。直接上Spark或Polars这类分布式/向量化计算引擎它们内置了高效的JSON读取器会自动做分区并行和列式剪枝。另外强烈建议统一封装一个to_json_record()函数所有上游JSON在进入管道时都过一遍这个函数做四件事字段名统一转snake_case、时间字段统一转ISO格式、金额字段统一转decimal字符串、删除无用的调试字段。这样下游拿到的是规整数据而不是原始乱象。2.3 JSON校验宁可前置报错不要后置脏数据JSON格式问题最大的麻烦是“看起来没问题一用就炸”。unexpected end of json input这类报错很多人应该都见过多半是文件被截断或者多个JSON被拼在一起了。我在管道里加了一道JSON Schema校验工序思路是先定义每个JSON文档的结构约束比如哪些字段必填、类型是什么、取值范围多少然后每条记录进入管道时先校验校验通过才进入后续流程失败则走死信队列。这样做的好处是把脏数据挡在最前面而不是让它们在数仓里爆炸。还有一个小技巧是正则预处理大JSON里的非法字符比如BOM头、NaN、Infinity这些非标准值。标准JSON解析器遇到这些会直接报错但在采集实时日志时经常会出现。用orjson解析时注意它默认不允许NaN需要特殊处理或者先做字符串替换。3. CSV处理最亲民也最容易翻车3.1 编码、分隔符和引号转义三座大山CSV看起来太简单了以至于很多人不屑于认真处理结果翻车翻得最狠的就它。第一座大山是编码。CSV文件从Windows传过来经常是GBK编码在Linux或Mac上直接读就是乱码。我有个惨痛教训有一次从业务方拿月度销售CSV几百MB的文件一打开全是我们看不懂的乱码后来才知道是GB18030编码。现在我的管道里有统一的编码探测逻辑用chardet或charset-normalizer检测编码并且强制转成UTF-8再入库。第二座大山是分隔符。很多“CSV”其实是用分号或制表符分隔的因为欧洲部分地区Excel打开CSV时默认用分号。如果下游程序写死了逗号所有字段都会错位。我的做法是读取前先分析头部几行的分隔符特征而不是假设一定是逗号。第三座大山是引号和转义。字段里如果包含逗号、换行符、引号就必须用引号包围并做转义。但很多业务系统导出的“CSV”根本不加引号或引号规则不一致导致字段内容被错误地拆成多列。这里不能硬解析要用专门的CSV库比如Python的csv模块和Pandas的read_csv它们对引号规则处理得相对完善。3.2 大CSV效率优化分块读取与并行处理CSV文件一大性能问题就来了。一个10GB的CSV用Pandas直接read_csv()大概率内存爆炸。我的方案是分块读取pd.read_csv(big.csv, chunksize500000)每次处理50万行处理完写出一批Parquet最后合并。这个方法能把内存占用从几十GB压到几个GB速度也不差。如果文件更大可以考虑用命令行工具csvkit或xsv做快速探查。具体来说xsv处理CSV特别快几GB的文件做字段统计、采样、切分都是秒级。可以先xsv sample抽几行看看结构再决定怎么处理。其实很多时候CSV只是“运输格式”最终还是要落到Parquet或数据库里。这时可以直接用Polars或DuckDB来读CSV并转换它们都是向量化执行引擎读CSV比Pandas快很多而且DuckDB可以直接对CSV文件跑SQL还能自动推断类型写起来很爽。3.3 实操从CSV到Parquet的完整转换我用一个实际场景走一遍完整流程。手里有一个大约6GB的订单明细CSV字段有30多个包含中文列名和GBK编码要转成Parquet用于后续分析。第一步先做文件探查。用xsv headers看看列名用xsv sample 1000抽1000行数据肉眼检查有没有明显异常。第二步写一个Python转换脚本用Polars读取。Polars的read_csv非常快可以直接指定编码为GBK也可以自动推断类型。如果个别列类型推断错误在read_csv时用schema_overrides手动指定。第三步数据清洗。把金额列从带千分位的字符串转成浮点把日期列统一成日期类型把状态列映射成标准枚举值。清洗逻辑专门做成一个函数避免在读取时做太多事。第四步把所有清洗后的数据写入Parquet。这里注意设置合理的行组大小和压缩算法一般行组大小128MB、压缩用snappy或zstd存储和分析性能比较均衡。第五步做校验。读回刚生成的Parquet对比总行数、关键字段sum值是否与源CSV一致。这一步很多人会跳过但我强烈建议做因为格式转换中最隐蔽的错误是静默丢失或类型变化。4. Parquet处理列式存储带来的性能革命4.1 列式存储为什么这么快Parquet的核心理念是“列式存储”把数据按列而不是按行存放。传统CSV是行式存储一行数据的所有字段物理上挨在一起要查某个字段的统计信息就必须读完整行。Parquet则把相同字段的值连续存放查sum(amount)时只需要读取amount这一列的数据块其他列完全跳过。直观对比一下一张订单表有30个字段其中有一个total_amount字段你要算一个月总销售额。CSV方式需要扫描整个文件把每一行的30个字段全读出来筛出total_amountParquet方式只读total_amount这一列对应的数据页扫描量可能是CSV的1/30。数据越多这个差距越恐怖。列式存储还有一个很大的好处是压缩率高。因为同一列的数据类型相同、分布相似压缩算法能发挥最大效用。比如一个“省份”字段可能值就几十种压缩后几乎不占空间金额字段数值接近差值编码后体积也大幅缩小。4.2 压缩算法选型Snappy、Gzip还是ZstdParquet的压缩算法选择直接决定存储体积和查询速度之间的平衡。这个选择没有绝对标准要看你的实际场景。Snappy是默认标配压缩和解压速度极快压缩率一般。在大数据生态里Hive、Spark默认都支持Snappy兼容性最好很多团队的ODS层直接用Snappy。Gzip压缩率最高体积最小但代价是CPU消耗大、解压慢。如果数据主要用于长期归档、很少热查询Gzip很划算但如果是一个每天几十亿条记录的宽表用Gzip会把下游查询拖慢。Zstd是近几年越来越流行的选项。它的压缩率接近Gzip但速度远快于Gzip甚至能和Snappy打一打。如果存储和查询都有压力Zstd是很好的折衷。我现在的ODS层默认用SnappyDWD层用Zstd归档层用Gzip三层策略分别对应热、温、冷数据。提示在选择压缩算法前先拿自己的真实数据做一轮小规模对比测试单看压缩率不看速度很容易选错。一个经验准则是查询频繁的层用解压快的存储空间紧张的层用压缩率高的。4.3 实操用PyArrow精细控制Parquet写入PyArrow是底层Parquet实现提供的控制粒度比上层DataFrame库更细。如果要对Parquet写出做精细调优直接用PyArrow的parquet.write_table接口。关键参数我建议重点关注三个row_group_size控制行组大小默认128MB左右比较合理。行组是Parquet的独立读取单元查询时按需扫描行组行组太小则元数据开销大太大则扫描粒度粗。compression控制压缩算法填zstd或snappy。data_page_size控制数据页大小默认1MB左右可以太小会膨胀元数据太大会浪费IO。这里要特别提一个我自己踩过的坑写入Parquet时schema的类型很重要。如果你在Pandas里某个字段是object类型Parquet会按照String推断但数字字符串最好先转成数值类型否则后续查询时会有隐式转换开销。日期类型也能写成Parquet的date64或timestamp类型但需要在写入前显式转换。5. 转换管线的类型映射与常见问题5.1 转换中最容易丢数据的类型映射规则我在做多格式转换时遇到过最危险的问题不是解析失败而是类型映射导致的静默数据损坏。JSON说一个字段是数字CSV里它可能是字符串Parquet里又要明确成int64还是float64每一层转换都可能丢失精度或改变语义。这里列一张我自己项目里沉淀下来的映射表数据类型JSON表现CSV表现Parquet类型备注整数number123int64超过2^53会丢精度必须用string小数number123.45decimal金额必须用decimal避免浮点误差布尔true/falseTRUE/FALSEbool需统一枚举避免是/否歧义日期2026-01-1501/15/2026date32必须统一格式并校验时间戳ISO8601字符串2026-01-15 10:30:00timestamp必须统一时区大整数90071992547409939007199254740993string不能转number会丢精度有一个经典案例是订单号。上游MySQL里的订单ID是bigintJSON接口返回时会把大整数变成字符串因为Java的Long到JavaScript的Number会丢精度。如果采集时又自作主张把这个字符串“还原”成数字超过Number.MAX_SAFE_INTEGER的部分就全被四舍五入了。这种问题排查特别隐蔽因为大部分订单看着都对只有超大ID的个别记录出错。我的建议是主键、ID、手机号、银行卡号这类语义上是标识符而非数值的字段一律按string处理无论在哪个格式层都不转成数值。这个原则写进团队的数据规范里能省掉无数个隐形bug。5.2 实操一个多源采集转换管线的完整设计这里分享一个我近期在做实时订单数据采集时设计的转换管线整体分五段第一段是接入层。多路上游通过Kafka推送JSON消息消息里是完整的订单事件嵌套两层并带时间戳。这里保留原始JSON原始串同时解析出关键字段用于路由比如把不同订单类型分流到不同topic。第二段是解析与标准化层。用Pandas或Polars把JSON转成DataFrame做类型归一、字段重命名和缺失值补充。重点是时间字段统一转为UTC毫秒时间戳。第三段是校验层。校验行数、核心字段合法性、金额分位对齐等。我曾在这个阶段发现过上游金额单位不统一的问题有的接口返回“元”有的返回“分”不校验的话下游报表全错。第四段是落盘层。把标准化后的数据转成Parquet按天分区写入对象存储或HDFS。分区键的选择很关键我通常按dt做天级分区因为绝大多数查询都带时间范围过滤天级分区能快速剪枝。第五段是导出层。当业务方要数据时从Parquet按需读取再转成CSV或JSON供下载。导出时不要直接全量导最好支持字段选择和条件过滤因为业务方通常只是要一个月的数据而不是几十TB全给。5.3 常见报错排查速查表我整理了一份格式转换过程中最常见的报错和排查技巧都是实际项目里的经验沉淀报错/现象大概率原因排查方法unexpected end of json inputJSON文件被截断或拼接了多个文档检查文件尾部用jq empty file.json验证中文乱码源文件是GBK/GB18030被按UTF-8读取用chardet探测真实编码后转换csv.reader报line too long有超长字段或换行符未被引号保护调大field_size_limit并检查引号规则数字变成科学计数法Excel打开CSV时自动格式化了长数字用CSV原始文本导出不要经过Excel时间字段整体偏移8小时源时区和目标时区未对齐统一转UTC后按需本地化Parquet文件读取时报schema不匹配同一表在不同批次写入了不同schema用PyArrow读取schema对比强制统一MD5校验不一致CSV导出时不可见字符BOM、回车符混入先把文本统一转UTF-8 with BOM或without BOM再做MD5还有一个容易被忽略的坑是Excel对CSV的处理。CSV文件在手机上打开和电脑上打开效果不一样经常造成误解。实际上CSV本质是纯文本没有格式信息Excel把长数字显示成科学计数法只是展示层问题数据本身没变。如果业务方非要“打开是正常的表格”推荐导出时用xlsx而不是CSV别跟CSV特性较劲。5.4 一个性能细节JSON转Parquet时的内存与调度在实际做几TB级数据转换时最常碰到的性能问题是内存暴涨和任务被OOM杀掉。我的经验是有几个关键点不要在一台机器上做全局转换而是要分片处理。可以按业务主键做哈希分片或者按时间窗口分片每个分片转换完成后合并。用Spark或Flink这类分布式引擎时要特别注意repartition的粒度太粗会有数据倾斜太细会有调度开销。另一个性能细节是避免在管道里重复序列化和反序列化。比如从JSON解析出来的DataFrame不要先to_csv再读csv然后再to_parquet中间的所有步骤都要浪费大量IO和CPU。正确做法是只做一次解析然后直接在内存里完成类型转换最后一次性写入目标格式。还有一点是压缩的地点和时机。Parquet的压缩是写到磁盘时才发生的所以不要在多轮转换之间反复解压压缩而是最后统一压缩一次。如果中间过程是Parquet到Parquet可以关闭压缩让中间文件大一些、读写快一些最后再压缩。5.5 数据校验不能省转换完成后必须做对比检查我每次完成一批格式转换后一定会做数据对比检查这个习惯帮我拦住了不少线上事故。对比检查通常做三层第一层是条数核对。源文件和目标文件的总行数必须一致。注意这里的“行数”在JSON场景下是记录数在CSV场景下要跳过表头和可能的空行。第二层是字段汇总核对。对金额、数量等数值字段做sum和avg对比允许浮点误差但不允许量级差异。对ID类字段做唯一值数量对比防止重复或丢失。第三层是抽样明细核对。随机抽取几百条记录逐字段对比源和目标的值是否一致。这个步骤最花时间但也能发现汇总核对发现不了的问题比如某个字段整体偏移一位、某个空值被填了默认值等。如果是CSV文件我还会做一个MD5校验但这个校验要小心换行符和BOM会直接影响MD5值所以必须在格式统一的条件下做校验否则会误报。写在最后的一点经验格式转换这件事表面上是个技术活本质上是个数据质量工程。我在实际项目里最深的体会是不要等到转换出错了才排查要在管道设计时就把格式选型、类型映射、编码规范这些“看不见的约定”定清楚。格式转换最昂贵的不是CPU和内存而是上下游之间对同一段数据的理解不一致所造成的返工。还有一个很实用的小建议不管用什么工具做转换都先把源数据抽样看一遍花两分钟扫一眼真实数据比写半天防御性代码都管用。手里有真实数据的样子你才知道该转成什么样、有什么坑要填。大数据采集中格式转换走到最后拼的不是魔法是耐心和对数据的敬畏。