大数据项目失败率超过 60%，多数问题并非出在技术选型上，而是卡在了数据治理、实时架构与成本控制这三个看似简单的环节。以下三个高频疑问，直接来自一线运维与架构团队的真实场景，或许能帮你避开同样的坑。

数据治理投入大却不出数，根源在哪？

某电商平台在建设用户画像系统时，IT 团队花了 3 个月清洗用户行为日志，但算法工程师拿到数据后仍发现 30% 的字段缺失或格式错误。问题出在治理流程只盯着“数据质量”，却没定义“业务可消费性”。比如，日志里“用户点击商品”这个事件，后端埋点记录的是商品 ID，前端埋点记录的却是商品 SKU 编码，两个字段在数据仓库里被当成独立维度存储，导致画像分析时需人工二次关联。正确做法是：在数据入湖阶段就要求业务方提供“字段映射字典”，并强制在元数据中标注每个字段的计算口径、数据来源与更新频率，这样即便数据源从 MySQL 切换到 Kafka，字段含义也不会跑偏。

实时计算架构选型，批流一体到底香不香？

某金融风控团队曾用 Flink 做实时交易反欺诈，每天处理 2000 万条事件流，查询延迟控制在 50 毫秒以内。后来他们为了“统一架构”，把所有批处理任务也迁移到 Flink 上跑，结果发现历史数据回溯（比如计算过去 30 天用户逾期率）时，Flink 的状态管理机制导致内存溢出，任务重启后恢复时间长达 20 分钟。对比之下，Spark Streaming 在处理这种“一次读取、多次计算”的场景时，反而因为弹性分布式数据集（RDD）的容错设计，表现得更加稳定。核心结论是：批流一体适合数据量在 TB 级以下、业务逻辑简单的场景；一旦涉及大量历史聚合计算或跨小时窗口的复杂事件关联，建议保留两套引擎——用 Flink 处理秒级实时链路，用 Spark 做批处理与模型训练，中间通过 Kafka 或 Pulsar 做数据解耦。

大数据集群成本失控，如何精准降本？

某在线教育公司上个月 Hadoop 集群账单涨了 40%，查后发现是 30% 的存储空间被“僵尸数据”占据——这些数据是两年前投放的广告日志，既无下游消费任务引用，也未设置生命周期。更隐蔽的浪费来自计算资源：他们给所有 ETL 任务统一分配 100GB 内存，但实际 70% 的任务峰值内存消耗不超过 30GB。建议分三步止血：第一，用存储治理工具扫描出 90 天无访问的数据，按“业务负责人确认-归档至冷存储-自动删除”三步清理；第二，对 Spark/Flink 任务按“高峰-低谷”时段动态调整资源配额，比如凌晨批量任务降低 50% 的 executor 数量；第三，引入资源标签（如 cost center），让每个部门按季度认领计算成本，超支部门需提交优化方案才能扩集群。

• 误区一：数据治理等于清洗数据。实际上，治理的核心是定义“数据怎么变成业务指标”的规则，而非事后纠错。
• 误区二：实时架构越统一越好。批流一体需评估数据规模与查询复杂度，高并发、长窗口场景建议分拆引擎。
• 误区三：降本只盯着硬件采购。无主数据、资源闲置、任务配置冗余才是最大浪费，成本控制应从数据生命周期和资源利用率出发。