58快递货运、滴滴快递网约车、司机端都是按照行驶公里数收费的，所以“里程”的准确度是这类业务的核心问题。“里程计算”方案的演进，以及优化的思路，是本文要讨论的问题。1.直接调用地图API。这是最容易想到的方法，也是最省事的。然而，司机经常不按照预定路线行驶。很有可能会因为堵车或者封路而改变路线。一个估计值，不太靠谱优化方案：根据实际路线计算里程2.司机APP实时计算增量里程，服务器存储总里程过程如下：(1)货车所在位置是不断变化的，司机APP每隔一段时间（比如1s）记录GPS，即点（2）实时计算相邻两点之间的距离，并上报给服务器（3）存储服务器上的总里程。潜在问题：GPS可能不准确，偶尔会有噪音。噪声，相邻两个点之间的距离会很远，导致最终总里程可能比实际里程更远。优化方案：不能实时计算增量，而是先计算点数，最后统一计算，这样才有机会去噪。终端和服务端的统一里程计算流程如下：(1)货车位置不断变化，司机APP每秒打一个点，上报给服务端(2)服务端会打到登陆并记录数据库(3)到达目的地后，服务器对所有点进行统一处理，一次性计算里程，可以去除噪音点的潜在问题：假设每个订单的平均货运时间为1小时，也就是每笔订单需要打印3600个点，58个快递每天100w个订单，也就是总共需要36亿个点，每个点对应一次对数据库的写请求。数据库写入压力在每秒4万次左右，无法支持优化方案：批量写入是降低数据库压力的常用方案。4.客户端实时管理，压缩后批量上传流程如下：(1)司机APP每秒进行一次本地管理，每隔一段时间压缩上报给服务器（例如，20s)，服务器压力从4w降低到2k(2)服务器解压，批量写入队列(3)队列中的点，每隔一段时间写入数据库（例如，2s)优化结果：大大降低了数据库的压力（由于存储容量大，在实际优化过程中，使用Hbase优化存储）其他问题：数据库的压力下降了，但是到达目的地后，所有一个订单的积分会计算里程，成本高。如何减少计算量？这样的点是无效点，需要去掉吗？(1)噪声点原理：连续的点，偏移量大的噪声点需要去除(2)同点原理：相同位置的点可以去除，因为移动路径是0(3)速度原理：在行驶速度超过合理范围时，(4)角度原则应去除：理论上，顺序轨迹是平滑有序的。如果角度反复向后转，可视为无效点潜在问题：如果司机APP断开或信号不好，可能会漏点，导致计算出的总距离小于实际距离，会给司机带来损失。优化方案：补点6，补点后补点，数据校正，如何补点计算里程，如何进行数据校正？(1)补点：车辆行驶过程中，如果有中断路线，采用“地图路径规划”的方法补点(2)修正：使用卡尔曼滤波算法对轨迹进行整形(3)里程计算：根据点到点的距离，进行累计汇总“里程计算”优化过程：直接调用地图API，司机APP实时计算增量里程，服务器存储总里程和上报给服务器，服务器实时计算里程。更正，并非所有公司都会参与里程计算“mileagecalculation”，但很多优化思路还是可以借鉴的：服务End-to-end实现，整合所有数据，去除噪音Singleandbatch：单次操作，压力大，不易压缩；批量操作可以大大减轻压力，压缩比高无效数据可以减少计算量，提高精度。补充修正：对于少量缺失数据，可进行预测补充，顺利修正【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此查看该作者的更多好文章
