2023年，我参与某省会城市的智慧交通项目时，遭遇了典型的“数据烟囱”困境。交警、公交、地铁、停车管理四大系统各自独立，数据源互不联通，导致整个城市的交通调度决策延迟高达15分钟以上。当时，我们面临的核心问题就是大数据平台架构的选择。
项目初期，团队采用了传统的Lambda架构。实时层处理卡口抓拍和车辆轨迹数据，批处理层则负责历史统计和路网模型训练。然而，随着数据规模从日均50TB飙升至200TB，Lambda架构的维护成本急剧上升。实时流处理与批处理代码维护两套逻辑，出现了严重的“数据漂移”现象，离线计算出的拥堵预测结果与实时路况经常相差30%以上。
转机出现在2024年初，我们决定向Kappa架构迁移。核心思路是将所有业务数据统一到Kafka消息总线，通过Flink进行全量流的实时计算。为此，我们重构了数据模型，将路网状态、车辆轨迹、信号灯配时等高频数据全部抽象为“事件流”，而非传统的“状态快照”。例如，原本需要每日凌晨批处理的OD（起讫点）分析，现在通过对实时事件流的滑动窗口计算即可完成，延迟从12小时降至10秒以内。
架构迁移后，数据的时效性瓶颈被彻底打破，但新的问题随之而来：计算资源消耗激增。为此，我们引入了数据湖的“冷热分层”策略。将超过72小时的历史轨迹数据从HBase迁移至OSS对象存储，并利用Spark的“查询下推”机制，使得存储成本降低70%，且查询效率仅下降5%。最终，这个基于Kappa架构的智慧交通平台，支撑起了全市8000个路口的实时信号优化，让平均通行速度提升了18%。