本文主要是介绍【在路上3】大数据离线分析快递的派件时效,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
【在路上1】快递物流大数据的由来
【在路上2】快递的运单轨迹
几乎人人都用过快递,如果说用户最在意什么?那必然是谁家送得快!这也是整个快递物流行业被诟病最多的地方。
都知道顺丰送得快,但价格摆在那里,且它的市场份额不到十分之一。也有许多热心用户质疑,广州到上海开车就18个小时不到,快递怎么样都不可能要四五天(2016年以前),收货1天,运输1天,分拣派件1天,标准时长应该是3天才对,今发后至!这个分析很中肯,同时也是我们自己的疑问,只是无从查起!
很多人都干过一件事,网购以后,每天刷新多次物流轨迹,看看宝贝到哪了。如果上午就到了上海,而下午没有拿到手,大多数人都会发火!
2016年,有了初步的大数据(此时没有任何积累),在高层领导决策下,我们选择了末端派件这么一个环节来进行时效分析。
针对过去一个月进入上海的全部包裹进行数据分析,看看每个网点派件时长,横向对比其它网点,纵向对比该网点不同日期。
咱们用专业术语再来一次:
1,准备20160301至20160407全量签收数据,签收表独立,入库时间作为索引,考虑上传延迟多跑几天。
2,过滤签收网点位于上海,且签收时间位于3月份的数据。签收后可能过1~48小时才会上传入库,所以签收时间不等于入库时间。
3,按照中心发出日期加网点的维度,统计每个网点每天应派件量(中心发出),实际派件量(网点签收),平均时效(签收时间减去中心发出时间)
4,根据坐标计算网点到中心的驾驶时长,留出2小时作为回去后的分拣操作时间,就得到网点实际应该达到的派件时效
所有进入上海的件,在上海中心交给派件网点之前,都会做一次发件扫描,最终派件网点会做签收扫描。
按照这个逻辑,借助Oracle一体机的存储过程跑了一份数据。此时上海全天派件量10万票左右,整个3月份两三百万,跑起来难度不大。
很显然,这份数据根本就没法看!这是纯技术思维考虑的方案,尽管考虑到多跑一段,但是快递业务根本就不是这样的!!!
整个3月份的总量是差不多的,平均时效也偏差不大,问题就在于统计日期,完全错了!
要知道,每天14:30以后到达上海的件,会留到第二天早上6点,作为一派件由网点车拉回去,6:00到12:30作为二派,12:30到14:30作为三派,网点一共会来拉三次件。这里问题最大的就在于一派前半截,下午才到,网点即使拉回去也派不掉,傍晚还得去收件分拣打包。
因此,重新调整了统计日期计算规则,才得到了一份初步数据,以派件任务的视角来查看。这说明,光有技术不行,还得深入到业务之中去。
然而事情并不会那么顺利。拿这份数据去跟网点沟通的时候,才发现自己是多么的幼稚!前面说到,网点会派三次车去中心拉件,这是理想情况。实际上部分网点不会这么操作,比如,几个网点共用一辆车,又比如,二派的车在12:30故意不走,等到13:30,顺带拉走大部分三派的件,等等等!这都是为了节省成本啊,每个人都可以找出成千上万个理由,为派件不及时而辩解,实际上有没有派件不力,就掩盖在其中!
项目就此进入僵局!欲听如何破局,请听下回分解!
这一节进入实战,遇到了许多实实在在的意想不到的问题:
1,采集数据延迟上传,导致业余时间远小于入库时间。而为了能够单向分析以及数据准确性,就得用入库时间作为索引,在目标数据区间前后多跑一段数据。
2,结合快递业务,绝大部分包裹的生命周期在7天以内,因为多跑7天数据。
3,快递有一二三派,不同城市要求不同
---以上所述并非完全真实准确,为了便于书写,把不同时间点发生的事情略微调整。
作者认为,最有价值的应该是大数据落地这么一个过程,如果借助技术去攻城拔寨!
今天除夕,躲在山沟沟里用手机码字实属不易,如果喜欢,帮忙转发一下!
提前祝大家新年快乐!
这篇关于【在路上3】大数据离线分析快递的派件时效的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!