一、货运司机业务全景

货运司机业务涵盖从司机招募到车辆生命周期管理的闭环。其复杂性体现在以下五大维度：

司机招募与留存
- 业务场景：渠道效果分析、流失预警、培训需求预测。
- 数据痛点：需实时监控新司机注册转化率、3 日 / 7 日留存率，识别高流失风险群体（如年龄 < 25 岁、周接单量 < 10 单的司机）。
在线运营与调度
- 业务场景：实时热力图、智能派单、疲劳驾驶预警。
- 数据痛点：需实时监控接单状态（空闲 / 忙碌）、车辆故障报警。
完单质量与客户体验
- 业务场景：订单完成率、客户评分分析、异常订单处理。
- 数据痛点：需实时关联司机行为（如绕路、超时）与客户投诉，定位服务短板。
会员体系与增值服务
- 业务场景：会员权益、积分兑换、精准营销。
- 数据痛点：需构建司机价值分层模型，实时推送个性化优惠（如订单券、收费折扣）。
车辆资产与金融服务
- 业务场景：车辆租赁 / 销售、保险理赔、残值评估。
- 数据痛点：需整合车辆行驶里程、维修记录、事故数据，实现动态定价与风险控制。

二、货运司机实时指标框架一览

我们可以通过构建3大板块的指标，以实时、量化的方式描述上述业务活动

数据接入与预处理
- 数据源：以 MQ 作为数据输入源头，承载原始数据。
- 初步处理：通过 Scala/Flink SQL 对 MQ 数据进行代码或 SQL 形式的清洗、转换等预处理，为后续流程做准备。
数据缓冲与流式处理
- 消息队列缓冲：预处理后的数据写入 Kafka，利用消息队列特性实现数据的异步缓冲、流量削峰，保障数据传输稳定性。
- 流式计算处理：再次通过 Flink SQL 对 Kafka 中的数据进行实时计算（如聚合、关联），完成数据的深度加工。
数据存储与分层
- 基础存储：处理后的数据输出至 StarRocks，进行基础存储。
- 接口封装：对于通用逻辑，使用SR的视图作为标准接口，统一输出口径，实现数据的分层管理，便于后续不同场景调用。
数据服务化与应用
- 平台处理：
  - 服务化/数据集：基于 SR视图构建标准的业务数据集或模型，支持业务的可视化指标配置。
  - 平台保障：强调平台对数据稳定性的维护，确保指标口径一致，并通过强制校验避免数据不一致问题。
- 最终应用：服务化模型与数据集共同支撑报表生成，为业务提供可视化分析结果，辅助决策。

当前的实时链路单日flink成本在千元级别，共计370+个节点，其中：

核心流量主要来自心跳数据，每秒数据千级别，峰值接近万级；延迟控制在百毫秒级，极端场景下达秒级。

货运司机实时链路大致可划分为5个板块，分别对应了上述业务的划分：司机招募、在线调度、完单监控、会员运营和车辆资产管理

数据源同步策略存在标准化不足问题。当前同步机制同时支持表级同步与整库同步两种模式，其中一些轻量级表级同步采用 Scala 代码实现导致运维复杂度增加，而整库同步因缺乏统一管理规范，造成存储资源浪费及运维成本上升；
kafka / SR 节点存在冗余配置。部分通用数据处理逻辑被独立封装为共享服务后，下游消费场景发生变更，导致部分 Kafka/SR 节点仅通向另一个Kafka/SR 节点，或未被任何下游消费，造成集群存储资源闲置；
SR 视图存在冗余建设问题。视图创建缺乏统一管理规范，导致视图治理复杂度显著提升；部分视图包含复杂关联逻辑，引发下游查询性能下降；相同业务逻辑分散在多个视图中，未有效收敛，增加问题追溯难度；
实时维度写入 HBase ，导致数据处理链路层级增加。下游计算节点需额外增加 HBase 数据读取逻辑，原相对独立的数据处理链路与其他链路形成强耦合，增加了潜在延迟、破线了风险。
前置流关联操作前置引发架构层面问题。流关联的前置导致实时宽表的提前生成，由此与大量下游节点耦合，链路延迟增加，链路断裂风险提升，单节点故障扩散范围增大。

针对现存问题，给出以下重构方案：

该方案实施历时半年，结果如下：