多数企业采购大数据平台时，最常犯的错误是把“数据量大”等同于“技术强”——结果花了几百万搭建的集群，实际日活查询只有几十次，连一台中等配置服务器都能扛住。

数据采集阶段：日志丢失率超过5%才是真问题

某电商公司曾用Flume采集用户行为日志，上线第一周就发现凌晨3点到5点的数据总是少30%。排查后不是带宽问题，而是Flume的Kafka Channel在批量提交时，如果消费者处理太慢，内存中的批次数据会被直接丢弃。更隐蔽的是，这种丢数不会报错，只在监控指标中的“未确认消息数”里留下痕迹。后来换用File Channel加手动ACK机制，才把丢失率降到0.3%以下。真正的大数据采集，首要指标不是吞吐量，而是端到端的数据完整性——你可以在压测时故意让消费者停10秒，观察数据是否全量落盘。

存储计算分离：别把“存算分离”做成“存算分家”

一家金融科技公司把Hadoop集群升级到存算分离架构，结果跑批任务从2小时变成8小时。原因是他们把热数据全放对象存储，但对象存储的元数据访问延迟比HDFS高一个数量级，而他们的ETL任务里充斥着大量List操作（比如每天遍历全量分区表）。真正有效的做法是：热数据仍暂存本地SSD，冷数据放对象存储，并用Apache Alluxio做透明缓存层。比如某游戏公司用这个方案后，90%的查询命中本地缓存，冷数据访问只占10%，整体查询延迟仅增加12%。

实时计算选型：Kafka Streams比Flink更适合80%的场景

很多人一提到实时计算就选Flink，但忽略了运维成本。某在线教育公司用Flink做用户实时画像，团队只有3个人，结果每周要处理两次因Checkpoint超时导致的Task重启。后来换用Kafka Streams，代码量减少40%，且完全不用维护独立的流计算集群——因为Kafka Streams是嵌入业务应用中的库。适用场景很简单：如果你的实时逻辑不需要跨多个Topic做复杂Join，且数据量在每秒10万条以内，Kafka Streams的简洁性远胜Flink。只有需要精确一次语义的跨时段窗口聚合（比如统计过去1小时的UV），才值得上Flink。

• 误区1：盲目追求“实时”，结果把离线任务硬改成流处理——比如每日一次的报表统计，用Spark批处理2分钟跑完，非要用Flink实时计算，增加了10倍运维复杂度。正确做法是：先确认业务能否接受10分钟的延迟，能接受就继续用批处理。
• 误区2：把数据湖当成“万能存储”，忘了事务支持——数据湖（如Delta Lake）虽然提供ACID，但它的并发写入性能其实比传统数仓差很多。如果你的场景需要频繁的Update/Delete（比如用户标签实时更新），请优先考虑TiDB或ClickHouse，而不是往数据湖里写数据。
• 误区3：用副本数代替备份——HDFS的三副本只防硬盘坏，不防误删数据。某公司运维一个rm命令删了整个Hive分区，三副本全没了。必须至少配置一个定时备份到不同介质（比如每晚异地备份到S3），且备份策略要区分“可重新生成的数据”（比如日志）和“不可恢复的数据”（比如用户上传的图片）。