Tungsten项目的核心洞察：性能瓶颈已从I/O转向CPU和内存，优化重心要跟着实际瓶颈走

Spark社区在启动Tungsten项目之前，做了一次重要的重新校准：过去大数据系统的性能瓶颈普遍被认为在磁盘和网络I/O上，但社区实践中发现，很多大数据应用真正的瓶颈其实已经转移到了CPU上。这个转移背后有清晰的硬件和软件双重原因——一方面网络I/O链路速度这些年提升非常显著（可达10Gbps级别），SSD硬盘和条带化HDD阵列也已经比较普及，磁盘I/O效率有了明显改善；但CPU的主频这些年没有大幅提升，核数增长的速度也不如网络和存储那样迅猛，硬件层面的这种不均衡增长，天然让CPU相对于I/O变成了更容易成为瓶颈的那一环。另一方面，Spark本身已经对I/O做了大量优化（列存储、I/O剪枝、优化过的Shuffle），在I/O这个方向继续投入，边际收益已经不大；与此同时，序列化和反序列化这类和CPU强相关的开销，反而变成了新的性能瓶颈。基于这个重新校准的判断，Tungsten项目把优化重心明确转向了内存管理和二进制格式处理、缓存友好的计算、代码生成这三个方向——本质上都是围绕”如何更高效地利用CPU和内存”展开的，而不是继续在已经优化得差不多的I/O方向上打转。这个案例给出了一条性能优化领域极其重要的方法论：性能瓶颈不是一成不变的，它会随着硬件的演进和软件本身持续优化的进度而动态迁移——曾经的瓶颈（I/O）可能因为硬件进步和前期优化投入而不再是瓶颈，而曾经不被重视的环节（CPU、内存管理）可能悄悄变成了新的瓶颈；持续做性能优化的团队，需要定期重新审视”当前真正的瓶颈到底在哪”，而不能一直依赖过去的经验判断（”瓶颈总是在I/O”）去决定优化投入的方向，否则很容易把精力持续投在一个已经不再是主要矛盾的地方。