2023年全球企业的大数据项目失败率超过65%，其中83%的团队卡在了同一个问题上：数据准备好了，却不知道业务部门到底想要什么。这不是技术不够，而是需求从源头就错了。

存储层：Hadoop已死还是被误读？

某头部电商在2018年花两千万自建Hadoop集群，三年后数据量翻倍，查询却慢了五倍。技术团队复盘发现，问题不在Hadoop本身，而是他们把所有数据都塞进了HDFS，包括每天产生百亿条的点击流日志。这些日志超过90%从未被访问过，却消耗着大量存储和计算资源。正确的做法是分层：历史冷数据用廉价对象存储，实时热数据用Kafka，只有需要频繁交互分析的数据才留在HDFS。那个电商团队后来把冷数据迁移到腾讯云COS，存储成本降了70%，查询速度反而提升了40%。

计算引擎：Spark和Flink到底该选谁？

一家金融科技公司用Spark做实时风控，每天凌晨两点跑批处理，结果发现部分用户交易已被拒绝半小时后才出风控结果。问题在于Spark的微批次架构天生有秒级延迟，而Flink的纯流处理可以在毫秒内响应。但这不是说Spark不行——同一家公司后来用Spark做离线用户画像，处理百亿级数据只需3小时，而Flink在这类场景下资源消耗反而高出两倍。核心判断标准很简单：如果业务需要秒内响应（如支付风控、实时推荐），选Flink；如果按小时或天跑批处理（如报表、离线特征工程），Spark更经济。

数据质量：为什么清洗后数据还是不准？

某连锁零售品牌花了半年时间清洗了所有门店销售数据，但月报出来发现上海区的营收波动异常。技术团队查了三天，最终找到原因：清洗脚本里写死了“门店编号=4位数字”，但上海新开的第100家店编号变成了5位。这种边界值问题在传统ETL中极其常见，且通常不会被常规测试覆盖。更隐蔽的是，他们用平均值填充了所有缺失的客单价字段，导致高端门店的排名被拉低。避免这类陷阱的方法是在清洗脚本中加入动态校验：每跑一次就自动统计字段长度分布、空值比例、极值偏离度，超过阈值直接报警而非自动处理。上述公司后来引入Great Expectations库做自动化数据测试，将数据异常发现时间从三天缩短到十分钟。

三个最容易踩的坑与解法

• 坑一：盲目追求实时性。某物流公司要求所有数据必须秒级更新，结果每单轨迹变动都触发全量重算，服务器成本暴涨300%。实际上，90%的业务决策只需要小时级数据。解法：先根据业务响应时间反推技术架构，而非反过来。
• 坑二：把数据湖当垃圾场。大量团队存了全量原始日志，却没人知道哪些字段有用。一年后数据膨胀到PB级，查询一条记录要扫描整个分区。解法：强制在写入时做一级分区设计（按时间+业务ID），并定期清理超过90天未访问的数据。
• 坑三：用机器学习解决能用SQL解决的问题。有团队用神经网络预测下月销量，结果准确率还不如简单的移动平均。因为数据量不足100万条时，复杂模型反而过拟合。解法：先用统计方法验证数据规律，再决定是否上模型。