概念喧哗背后的真实问题

「你们还在用 Lambda？现在都流批一体的时代了。」——架构评审会上，这类话术常让技术负责人自我怀疑。但架构选型从来不是追新比赛：Lambda 架构服务了无数企业十数年，至今稳健；流批一体在部分场景确实简化了架构，却也在另一些场景带来了资源浪费与运维复杂度。决策的依据应当是业务需求，而不是供应商的白皮书。

决策框架：三个问题定架构

• 问题一：业务到底需要多快的数据？。把时效需求分档：T+1 能满足的（经营分析、财务报告）不需要实时链路；分钟级即可的（运营监控）用微批足够；只有秒级决策场景（风控拦截、实时营销、价格调整）才需要真正的流处理。多数企业的实时需求集中在分钟级，这意味着大量「实时数仓」项目可能只是把简单问题复杂化了。
• 问题二：数据规模与复杂度到了哪一档？。日增量在 TB 以下、以结构化为主的场景，传统数仓加微批完全胜任；PB 级、多格式、需要探索式分析时，湖仓一体的开放架构优势才真正显现。规模没到，先别为「未来」支付架构复杂度。
• 问题三：团队能养住哪套架构？。流处理的人才稀缺且昂贵，实时链路的运维复杂度是批处理的数倍。如果团队连离线任务的稳定性都尚未保障，引入实时架构大概率会制造新的故障源。

务实建议

采用「批为主、流为辅」的渐进路线：先保证离线数据体系的稳定与规范，再按业务优先级逐个场景引入实时能力；架构上优先选择同时支持批与流的统一平台，避免为每个场景单独引入一套技术栈。记住：架构的胜利不是概念最新，而是三年后你不需要为今天的决策后悔。