XML在大数据场景下的实际表现
公司最近接了个项目，需要从第三方系统导入一批用户数据。对方给的格式是XML，文件大小有800多MB。刚拿到文件的时候，开发小李还挺轻松：‘不就是解析个XML嘛，DOM解析器走起。’结果一跑程序，内存直接爆了。
这其实挺常见的。XML本身设计初衷并不是为了处理海量数据。它用标签嵌套来表达结构，看着清晰，但数据量一大，问题就来了。比如一个简单的用户记录：
<user>
<id>1001</id>
<name>张三</name>
<email>zhangsan@example.com</email>
</user>解析方式决定性能上限
继续说那个800MB的文件。小李一开始用DOM解析，把整个XML树加载进内存，结果程序占了将近2GB内存。后来改用SAX或StAX这类流式解析方式，边读边处理，内存压到了200MB以内。差别这么大，是因为DOM会把整个文档构造成节点树，而流式解析只关心当前读到的部分。
举个生活里的例子：你要查一本厚词典里的某个词，DOM就像把整本词典背下来再开始找，SAX则是一页页翻过去，看到目标就停下。数据越大，后者的优势越明显。
真实项目中的取舍
去年做物流系统时，我们和一家老国企对接。他们坚持用XML传运单数据，每小时几万条。我们试过压缩、分片、用高性能解析库，最终方案是接收后立刻转换成JSON存进Kafka，后续流程全用二进制协议处理。XML只作为入口格式存在，不参与核心流转。
这说明一个问题：不是XML不能用于大数据，而是你得清楚它的角色。如果两端系统都老旧，XML可能是唯一选择；但如果追求效率，Protocol Buffers、Avro这类二进制格式在序列化速度和体积上甩开XML好几条街。
什么时候还能用XML
也不是全盘否定。配置文件、小批量数据交换、需要人类可读的场景，XML依然合适。比如Spring框架的bean定义，写成XML虽然啰嗦点，但运维人员打开就能看懂，出了问题不用专门工具解析。
关键是别把它当成万能药。就像你不会用Excel处理十亿行数据一样，面对大数据量，优先考虑更轻量的方案。真躲不开XML，至少记得用流式解析，别让程序死在第一步。