大多数企业部署大数据项目时，超过60%的成本并不花在工具采购上，而是在数据清洗、存储策略和实时处理这三类看似简单却反复出错的问题上。以下是高频出现的大数据技术困惑与解法。

数据清洗时，为什么“去重”反而造成数据丢失？

某电商平台在做用户行为分析时，发现同一个用户在同一秒点击了两次“加入购物车”。他们用简单的ID+时间戳去重，结果删掉了真正需要保留的订单确认操作——因为后端请求处理存在500毫秒延迟，两次记录的服务器时间戳恰好不同。正确做法是：根据业务逻辑定义“重复”的粒度。对于订单类数据，应以“订单ID+状态变更时间”为唯一键；对于日志类，则用“会话ID+事件序列号”去重。更激进的方案是保留原始数据，在查询层用窗口函数做动态去重，避免源头数据被永久破坏。

数据湖存储，HDFS还是对象存储更省钱？

一家金融科技公司最初将所有原始数据存入HDFS集群，每月存储成本占IT预算的40%。后来他们把90%的冷数据迁移到阿里云OSS对象存储，只保留最近7天的热数据在HDFS上做计算。对比结果：对象存储的单价仅为HDFS的1/8，且无需支付副本维护和节点管理的人工费用。但需要注意两点：一是对象存储的读取延迟比本地HDFS高2-5倍，不适合秒级交互查询；二是如果数据湖需要频繁执行Spark SQL或MapReduce作业，数据从对象存储加载到计算节点的网络带宽可能成为瓶颈。建议做法是“冷热分层”，用HDFS处理计算密集型任务，用对象存储归档超过30天不访问的数据。

实时流处理，Kafka到底该设多少分区？

某物流公司的实时轨迹系统，最初将Kafka分区数设为10，结果发现某个分区堆积了50万条未消费数据，而其他分区空闲。原因是车辆轨迹按“车牌号”哈希分区，但一辆重型货车在高速上连续发送1000次位置更新，全部打入同一分区。正确经验是：分区数不是越高越好，而是要根据“消费者并行度”和“数据倾斜度”来定。一个通用公式是分区数 = 消费者线程数 × (2到3倍)。同时必须避免天然倾斜的Key（如设备ID、用户ID），改用“设备ID + 时间窗口”的复合Key做分区，或者用RocksDB存储状态，在Flink或Spark Streaming中做二级分区。如果业务允许，可以牺牲一点实时性，用批处理窗口（如每30秒触发一次）来平滑流量洪峰。

三个最常见误区

• 误区一：所有数据都必须实时入库——实时流处理不仅成本高，而且对网络抖动和乱序数据非常敏感。正确做法是：只对影响用户交互或系统告警的数据做实时处理（如支付欺诈检测），其余数据走T+1或小时级批量导入，可降低70%的基础设施压力。
• 误区二：数据规模越大，需要的节点越多——很多团队用200个节点跑每日几十GB的数据，结果70%的CPU浪费在节点间通信和任务调度上。更合理的做法是：先用4-8个高性能节点（大内存+SSD）做计算，当数据量达到TB级别时才考虑横向扩展。实际案例中，100GB以内的数据用单机ClickHouse或DuckDB即可秒级响应。
• 误区三：数据压缩一定会拖慢查询——这是对列式存储的误解。以Parquet格式为例，使用Snappy或ZSTD压缩后，I/O读取量减少70%，虽然解压消耗少量CPU，但整体查询速度反而提升2-3倍（尤其是扫描大量列的场景）。不要为了省事而直接使用无压缩的CSV或JSON格式存储数据湖文件。