司机轨迹上报流程

（22）dloc3 发送

（35）Uapi

（21）dloc3 接收 生产

写入

（41）kafka 消息队列

（36）用户端

（11）司机端采集

（43）HIVE 

1. 司机端采集（11）--->司机端上报（12），绿色箭头2. 司机端上报（12）---> dloc3准备发送Kafka（22），紫色箭头——【度量上传到上报网络延时】     * 按照之前的认知：统计时实际使用seq_id 和 create_time的时间差，即从（11）—> （22）的延时情况。     * 按照最新的认知：需要调整为record_time 和 create_time的时间差3. 用户端请求司机端位置--->Uapi接到运力中心返回，红色箭头（36）--（35）--（34）--（33）--（34）--（35）    * 通过request_time和 log_time的时间差，得到上述路径所花费时间。4. 用户请求司机轨迹延时情况（from 海沫）    * 按照之前的认知：统计时实际使用loc_time(GPS时间) 和 log_time的时间差（上图无法展现）。    * 按照最新的认知：需要调整为seq_id(位置采集时间) 和 log_time的时间差，即从（11）—> （35）的延时情况。    * 存在的问题：[用户请求司机位置] 日志中没有seq_id字段，建议增加loc_id字段，这样关联司机轨迹表之后，                               可以得到seq_id、create_time、record_time.5. 10 秒轨迹覆盖率（from 隽颖）    体现的是：在假设司机端每10S上传一个轨迹点的前提下，计算从（12）—>（43）之间的转化率

request_time用户端请求司机位置时间

log_time收到运力中心返回后打印日志的时间

（32）  keplerconsumer

（34）  keplerquery

record_time 上报时间

（31）kafka 消息队列

（42）Hbase consumer

create_time 准备发送Kafka时间

（12）司机端上报

（33）redis

seq_id  位置采集时间