超过70%的企业大数据项目在原型验证阶段就宣告失败，而存活下来的项目中又有近半数因数据质量问题导致模型失效。这不是技术不够强，而是从一开始就问错了问题。

存算分离架构到底值不值得用

某电商平台将日志分析集群从Hadoop迁移到存算分离架构，硬件成本下降了40%而查询速度反而提升。原因在于它们的数据访问模式是典型的“读多写少”，冷热数据分层明显。但另一家金融公司盲目跟风后，却因高频实时写入场景遭遇网络I/O瓶颈，性能反而不如原来的本地存储方案。存算分离的核心价值在于弹性与成本解耦——适合低频访问的历史数据、共享数据湖场景；不适合需要毫秒级响应的交易系统或负载剧烈的BI报表。判断标准很简单：检查你的业务中是否有超过30%的数据在30天内不会被访问。

实时流处理到底需要多“实时”

某外卖平台声称“实时订单分析”，实际是把秒级写入的数据批处理成5分钟窗口的聚合结果，因为超过90%的配送决策根本不需要亚秒级响应。真正需要毫秒级流处理的是反欺诈系统——银行信用卡交易监控中，200ms延迟就可能导致一笔欺诈交易成功。很多团队一上来就追求Flink的exactly-once语义和毫秒级延迟，却忽略了业务本身的容忍阈值。建议按“决策类型”划分：操作型决策（如风控、推荐）需要100-500ms实时，战术型决策（如运营看板）可接受5-30秒，战略型决策（如季度分析）甚至可以用T+1的批处理。

数据湖与数据仓库是敌是友

某零售企业花两年建了数据湖，结果业务部门抱怨“数据湖就是数据沼泽”——非结构化日志、半成品清洗数据、过期副本堆在一起，查询一条用户画像需要跨5个格式。反观另一家公司，在数据湖上直接构建了“湖仓一体”架构：用Delta Lake或Iceberg管理ACID事务，用物化视图缓存高频查询，将数据湖当作统一存储层，数仓只做建模和汇报。两者并不互斥，关键是要用“分层命名空间”强制约束——原始数据区只写不读，清洗区只读不写，集市区供BI工具直接对接。

最常踩的三个误区与具体补救方法：

• 堆硬件代替调参：集群慢就加节点、加内存，结果CPU利用率不到20%而GC占用了30%时间。先跑一次YARN的公平调度日志，检查是否存在数据倾斜或频繁的shuffle spill。
• 全量数据都要保留：认为“存着总有用”，结果冷数据占70%存储空间还拖慢元数据查询。对超过90天未访问的数据设置自动归档策略，或转存到廉价对象存储（S3/OSS）。
• 用单次跑通验证方案：Demo时数据量只有1万条，全表扫描都很快。上线后数据量暴增到1亿条，发现join键未索引导致查询超时。必须在测试环境使用生产级数据量的1/10，并强制加入慢查询告警。