大数据开发正在变成一场军备竞赛：我们是不是该停下来想想存储与算力的错配
过去八年我一直在跟 Hive、Spark、Flink 打交道，从 Hadoop 1.x 时代的 NameNode 脑裂，到如今动不动就上百节点的 K8s 上的 Spark Operator，说实话，工具越来越强，但问题越来越像。大家天天在群里聊的，不是数据怎么算对，而是资源怎么不够、任务怎么又跑挂了。我越来越觉得，大数据开发的核心矛盾，早就不是技术本身，而是存储与算力的错配。我们把数据放在 HDFS 上，却用 Spark 去一遍遍全量扫描；我们为了实时性，把 Kafka 当数据库用，结果下游的消费 Lag 永远追不平。这不是某一家公司的问题，这是整个行业的一种惯性。
你可以去查一下大部分公司的集群监控，CPU 利用率通常不到 30%，但磁盘 IO 早就被打满了。我们的 Spark 任务，十个里有八个是 Shuffle 倾斜导致的慢任务；我们的 Hive 表，分区字段选得乱七八糟，小文件多到 NameNode 的 RPC 处理不过来。为什么？因为我们在设计之初，根本就没把数据访问模式算进去。HDFS 擅长顺序读，不擅长随机读；Parquet 列式存储是为了减少 IO，但如果你用 select * 把整行都拉出来，列存就失去了意义。一个很典型的例子：某电商公司线上订单表，每天增量两千万行，他们用 Hive 做全量关联，跑一次要两个小时。后来我把关联键换成 Bucket 表，再把时间过滤条件下推，直接降到十五分钟。这不是什么高深技巧，只是尊重了数据的物理分布。
再说说实时化。Flink 被捧成大数据开发的银弹，但很多人没意识到，实时计算本质上是在用算力换延迟。你每降低一秒钟的延迟，背后可能是数倍的 CPU 和内存开销。很多场景根本不需要秒级，分钟级甚至小时级就够了。我见过一个做风控的团队，他们因为老板要“实时大屏”，硬是把离线跑批改成 Flink 流式，结果状态后端 RocksDB 频繁做 checkpoint，反压不断，最后数据还是不准。后来我帮他们重新设计：离线 T+1 做深度模型，实时只做规则引擎，把特征拼接放到 Redis 里，反而效果更好，成本省了 40%。所以我的观点很明确：实时化应当是一个渐进的过程，不是每个业务都需要 Flink，更不是把 Hadoop 扔掉换成 K8s 就代表先进。
还有一个被忽视的点：数据开发与存储的治理，其实是同一条链路上的事。很多团队把数据建模交给数仓工程师，把资源调度交给平台组，把实时链路交给流计算组，各管一段，结果数据血缘一团糟，冷数据占着热存储，计算引擎为了迁就数据格式而不断升级版本。我认为未来的方向是：存储与计算应该彻底解耦，但是数据组织必须共享同一套治理逻辑。比如用 Iceberg 或 Hudi 管理表格式，让 Spark 和 Flink 能同时读写，然后根据数据温度自动迁移存储等级；再比如利用数据湖的 manifest 文件做分区裁剪，而不是靠 Spark 的 Catalyst 优化器去猜。这些不是新概念，但真正做到的团队非常少。
如果你只在网上看文章，会觉得大数据开发一切都好：Presto 查询多快，Flink 吞吐多高，StarRocks 性能多猛。但实际去一线看一眼，你会发现 Hive 依然活得好好的，SQL 依然是在拼接字符串，数据质量依然靠凌晨三点被电话叫醒的人来保障。我想说的是，我们不应该再盲目追逐新的框架，而是回到问题的本质：数据在哪，算力应该怎么分配，数据流动的代价能否小于计算本身。因此，我给出一个比较可落地的三层策略：第一层，对 70% 的批处理任务，坚持使用 Hive + Spark SQL + 列式压缩，但必须强制分区裁剪和 bucket 化；第二层，对 20% 的准实时任务，用 Flink 做窗口聚合，只处理增量数据，不做全量状态；第三层，仅对真正需要秒级响应的 10% 场景，引入 OLAP 引擎或实时数仓。这样下来，资源利用率至少提升一倍，开发成本也大幅度下降。
大数据开发不是比谁的工具更酷，而是比谁更懂数据的脾气。如果你连自己某张表的存储大小、访问频率、热键分布都答不上来，那你八成是在用战术上的勤奋掩盖战略上的懒惰。