为学习技术的朋友门开拓眼界、提供技术学习的方向参考、可以选择其中一项或者几项自己有兴趣爱好的方向;下面按快递公司的业务场景,给大家介绍表面看着很Low的快递物流企业,为什么需要上千的内部IT队伍,都需要哪些最基本的核心技术能力。
一、快递公司的海量数据
海量扫描数据:快递公司业务高峰期需要1天处理1亿个包裹,这些包裹在每个环节都需要进行一次扫描数据采集,一天至少会产生10亿条以上各种业务扫描数据,这些核心业务数据处理需要庞大的服务器集群,而且需要把这些数据分发到各大业务系统中。
海量图片数据:每个快递包裹,在各转运中心被中转操作时都需要有拍照图片,快件破损遗失时,到底哪个环节出错,到底谁丢的,到底需要谁来赔偿等等,都需要这些图片记录的证据。
海量车辆轨迹数据:上万辆卡车、到底哪个时间点开到了哪里、是否按时到达、是否绕路、是否有各种处罚、补贴、交通故事的分析原因等等,都需要车辆的轨迹数据的分析,几秒中一个轨迹点,甚至更多的轨迹点数据,这些数据需要高效率存储、快速读取提供业务系统数据展示与分析。
海量监控视频数据:操作场地的监控视频、车辆装卸货视频、司机的驾驶视频、自动分拣线的工作视频,全国各地各各厂区的安全视频监控数据,需要庞大的网络带宽、灵活的调取视频监控的技术控制。
二、每日业务处理的数据量
总部大几千人,每个分公司都有上千人,还有几万个各地的加盟公司需要协同作业,需要处理业务系统的中的数据,例如用户的订单数据,客户的投诉数据,各种业务审批数据,人员的入职,离职,晋升、各种财务结算数据,一般会有几十个业务系统到几百个业务系统,庞大的全国性公司的信息系统需要庞大的后台技术支持。
若是外购的,虽然好用但是,无法与内部的几十个系统有效集成,往往销售给大公司的信息系统也是很昂贵的,容易各种被绑架,而且后续修改优化也是遥遥无期;所以效益好的大公司都需要用自主开发,未必是最先进的但是最符合公司的发展需要。
三、每个快件的扫描记录飞速展示
当每个用户在自己的手机里、电脑上查询快件的动态时,可以快速展示轨迹数据,这需要非关系型数据库技术的海量大数据能力的优化展示,例如HBase数据库,单号反转进行分布式存储等等,否则按传统数据库是超级艰难实现高并发下快速展示扫描轨迹数据的。
1:分库分表虽然也能解决问题,但是会增加运维的工作量、运维的工作难度。
2:大型数据库集群,虽然性能卓越,但是对如此庞大的数据量、也是力不从心,也无法在毫秒时间内读取到响应的扫描数据。
3:对外查询、对内查询运算,需要有不同的策略,对外只要求展示速度,高性能;对内需要大数据技术,各种关系型查询业务诉求。
4:对外部查询,一般需要查半年以上的数据,30天*6个月*10亿数据/每日 = 至少1800亿条数据随时需要能被秒查才可以。
四、快递扫描数据推送合作伙伴
快递扫描轨迹需要推送给各大合作伙伴,例如各大电商合作伙伴,国家各监管部门,电商平台还考核信息的完整性、及时性等等,需要强大的数据推送能力,推送失败,推送状态的监控能力等等,各种合作伙伴的各种数据推送要求兼容等等。有的合作伙伴系统不够稳定也未必能理想状态下稳定运行。
各大电商又有自己的完整的信息系统,在统计分析各种数据,所以这些扫描数据需要及时推送给他们,而且还有各种考核;各监管机构、各种国家监管单位,邮政、公安、国安、地方政府机构,都有权限要各种扫描数据等等;这些也需要及时提供给监管单位,而且不能影响现有系统的稳定高效率运行。
五、消息队列异步推送数据
海量数据需要推送到各个独立运行的子系统,还需要推送到各重要战略合作伙伴,需要用消息队列技术进行多渠道互不干扰的模式开展工作,庞大的消息队列,需要各种监控、消息过期策略等等;消息队列能保证各系统互相不干扰,某个子系统的崩溃不会影响其他子系统的正常运转,而且某个子系统的优化改进也不会影响其他子系统的稳定运行,消息队列是多系统协同运作的核心中间件。
首选需要消息队列的稳定运行,有自己的部署、监控维护能力,同时还有积压数据的监控能力,在庞大快速业务发展的公司,甚至需要消息队列的专家级人物排查各种疑难杂症才可以。
六、信息数据安全
客户的订单数据、用户的手机号码、快件的图片数据、用户购买的商品数据这些信息都是公司的保密数据,不能被电信诈骗分子拿到,需要防止各种信息泄露,需要有各种信息安全保障手段,图片服务器,文件服务器,数据库服务器,应用服务器等等都需要有良好的信息安全保障。
七、系统稳定性保证、监控系统
上万台,虚拟机、各种服务器,各种应用程序,需要稳定运行,硬盘存储,网络设备,需要有强大的监控能力,甚至24小时不间断的现场人员值班监控,系统若是瘫痪半小时,那对全国性业务的公司来说打击是巨大的。基础组件的搭建运营也是需要有一定的基本功,没足够强大的技术人员,往往基础组件运行不稳定,系统各种崩溃,各种无法稳定运行。
八、大数据平台从各子系统抽取数据
业务系统经过历年优化建设,有的系统可能是勉强能用能跑,未必能经得起各种海量数据处理的需求,需要把增量业务数据抽取到大数据平台,在大数据平台进行大规模海量数据的运算,抽取策略不正确也容易把子系统给抽挂了,引起故障。
1:业务部门会有无穷无尽的各种查询条件、与时俱进的各种KPI考核等等,某个子业务系统是无法经得起各种折腾,也没这个响应速度与响应能力。
2:公司层面,往往会有各种跨子业务系统的全局性的查询统计,例如资产模块,核心业务模块,统计分析资产的使用效率,需要全局性的数据进行分析。
3:需要有一个强大的大型数据库仓库,这个大型数据仓库提供各种统计分析能力,各种大数据据计算能力,各种无各子系统运行无关的,互相不干扰的强大的SQ语句统计分析能力;公司的核心大脑、快递大脑。
九、各种海量数据的统计汇总
例如每天有10亿个扫描数据,3万个加盟网点公司,小几十万内部员工;上百个分布在全国各地的转运中心,这些人需要进行量本利分析、各种绩效数据分析,各种业务数据汇总,每天接近1个亿的订单数据。总部各业务部门需要各种统计汇总数据报表,各分公司需要各种统计汇总报表,各个口子的决策领导往往需要各种统计汇总数据,公司需要有强大的数据分析能力,快速的响应能力。
例如:
哪个中心业务量下滑最严重?数量?百分比?
哪个快递网点客户流失最多?单量下滑明显?
哪个快递员的投诉最多?
哪个分公司的派送效率最高?
哪个客户的投诉最多?
用户还没签收,5天没动静的快件有多少?这部分是否遗失了?
在某个转运中心,已经2天没动静的快件有多少?这部分是否留仓件?需要紧急调度运输?
哪个分公司利润好,哪个分公司利润不好,效率低,哪末尾20个中心的领导需要撤换?
这些都需要从上千亿的业务数据里各种计算,一个SQL语句下去可能需要等个几个小时,几十台服务器集群运算后,可以得出结论;普通小型数据库服务器根本没能力存储,更没能力计算。
十、购买云服务与自建系统
原创作者: jirigala 转载于: https://www.cnblogs.com/jirigala/p/18778511