过去两年，我们为制造、物流、政务等领域的客户交付了十余个大数据平台项目。一个反复出现的现象是：团队在选型阶段花大量时间对比组件参数，上线后却因架构设计与业务节奏脱节，导致查询延迟飙升、运维成本失控。问题往往不出在单个技术本身，而在于软件开发过程中缺少对数据链路整体性的判断。

存算分离，还是本地化部署？

以某汽车零部件企业的智慧系统为例，其日均新增数据约1.2TB，涉及MES、ERP、IoT传感器三类数据源。早期采用Hadoop本地化部署，存储与计算耦合，扩容时需整机迁移，单次停机超过6小时。后期切换至存算分离架构（对象存储+弹性计算池），资源利用率提升约40%，但跨网络调用的延迟增加了15%～20%。

关键权衡点

• 数据热度：冷数据占比超过60%时，存算分离的性价比更明显
• 查询模式：高频点查场景下，本地SSD缓存层不可省略
• 团队运维能力：缺乏K8s经验的团队，弹性计算池反而会放大故障面

在大数据服务的实际落地中，没有普适的最优解。我们通常建议客户先做两周的负载压测，用真实SQL回放来验证架构假设，而非依赖厂商提供的基准测试报告。

流批一体的实施节奏

Flink + Iceberg的组合近两年被频繁提及，但真正跑通流批一体的项目不足三成。核心障碍不在技术，而在数据治理的滞后——当ODS层缺乏统一的主键约束和时序对齐机制时，流批结果的一致性根本无法保证。这也是企业信息化从“有数据”走向“用好数据”的必经阶段。

我们的做法是：先冻结业务口径，再搭建轻量级元数据中心，最后才引入流批一体引擎。顺序颠倒，返工成本通常是初始投入的2～3倍。一套务实的技术解决方案，应当把治理成本算进架构预算里，而不是留到运维阶段被动填坑。

选型没有银弹。把业务SLA翻译成可量化的技术指标，再用小规模灰度验证，比任何架构图都可靠。