作为加盟制货运合作商平台模式的提出者,安能物流是快运行业数字化转型的先行者。与快递行业不同,快运行业面临着业务流程复杂、交易链路长等问题,对数据的准确度、线上交易数据的生命周期等有着较高要求。因此,安能物流 IT 系统演进路线、建设思考、数据库选型等对行业具备极强的参考价值。
嘉宾|李家林 安能物流数据库负责人
本文要点:
1. 快运行业的业务特点及安能物流的数字化转型过程;
2. 在数字化转型中,安能物流在人工智能层面做过哪些探索,结果如何;
3. 数据库选型从 Oracle 到 MySQL 再到 TiDB,安能物流做了哪些思考;
4. 数据库迁移前后,成本和体验发生了哪些变化;
5. 安能物流对于数据底座及大模型技术的未来思考;
InfoQ:快运行业和快递行业的数字化转型(信息化建设)存在哪些差异?
李家林:首先,二者的业务形态存在很大不同。快递更多是针对 C 端,规模达到一定程度后,整个业务流程比较规范化。快运更多是针对 B 端业务,业务处理的流程环节繁多,业务逻辑也更为复杂。其次,企业在信息化建设过程中可能会因为缺乏顶层设计而走一些弯路,甚至需要将原有系统推到重建,比如现有系统足以支撑当前的业务形态,但却无法解决未来业务灵活多变时所出现的问题,缺少对于未来建设的思考,但大多数情况下只有企业真的走到那一步才会发现问题。
InfoQ:您方便分享下安能物流的数字化转型分为哪几个阶段吗?
李家林:自 2010 年成立,安能物流至今已经发展了接近 13 年的时间。在这个过程中,安能物流自主研发了 52 套 IT 系统,开发了一系列专有的、部署于整个业务流程的数字化工具,通过全链路数字化运营和智能化决策实现了效率升级。从系统信息化建设的角度可以分为如下三个阶段:
第一个阶段是 2016 年以前,该阶段采取垂直大集中的模式,主要解决的问题是将所有操作、业务涉及的环节和节点全部线上化,该阶段最大的问题是灵活性不够,单一系统的功能更新会影响全网的所有流程操作。
第二个阶段是 2016 年到 2018 年,,开始对系统进行拆分,由于对微服务架构的理解不够彻底,导致最终拆分出来的系统过多,虽然解决了灵活性的问题,但忽略了业务流程节点数据环环相扣的问题,且该阶段为了解决特定应用场景的业务问题,使用了多种技术架构。
第三个阶段是 2018 年之后,团队意识到系统拆分过于复杂,且对用户而言操作负担过重,完成一个业务流程可能需要登录多个系统,因此该阶段开始做分布式集中,在保证系统灵活性的同时保证底层数据统一,降低数据交付的复杂度,并提高准确性。基于此,团队提出全链路数字化升级的新目标:构建新一代一栈式物流数据平台,实现货物全闭环实时状态追踪。
InfoQ:在数字化转型的过程中,安能物流有引入过人工智能技术吗?具体做哪些事情?结果如何?
李家林:第一个探索方向是辅助驾驶,快运行业很大一部分成本来源于车辆运输费用,安能物流也探索过通过辅助驾驶的能力接入节省人力和油耗成本,比如一些长线路要求双驾,通过接入辅助驾驶最终只保留一位驾驶员,并且通过其规划出最佳行驶路线和最优驾驶技巧从而节省燃油成本。经过几个月的测试,我们成功验证了该想法,只是要想达到要求需要对车进行改造,成本比较高,经过测算大概需要三年时间可以回本。据了解,目前已经有货运公司开始跟车厂合作生产这类型的汽车,未来是有可能实现规模化的。
第二个探索方向是场内货物极速定位。相比于快递行业,快运行业的物品形状更不规则、体积更大,这些因素导致场内货物往往分布在场内更大的区域范围内,随之而来的问题就是需要找到诸如拦截件的时候费时费力。目前,安能物流已经通过 RFID 射频技术实现了一定距离范围内的快件位置搜寻,整个实践下来确实提升了效率;其次通过 RFID 技术还能快速的完成场内货物盘点。当下,RFID 的成本还是比较高,但我相信未来成熟之后成本会有所降低。
InfoQ:最近两年,行业内对于“降本增效”非常关注,安能物流的 IT 部门转型过程是否有这方面的思考?
李家林:安能物流已经在该方向进行实践。具体来说,在组织架构层面,组织变得更加扁平化,IT 组织内部按照产品线的方式调整团队,缩减了部门分类;在业务层面,部门内人员的具体定位都做了重新梳理,明确定位了每一个业务角色应该具备的能力和承担的责任;在 IT 技术层面,团队的职能不仅仅是提供工具和系统给业务人员使用,需要通过已有业务数据挖掘业务潜在价值,寻找新的增长点。
InfoQ:在数字化转型的过程中,安能物流对底层数据库的需求是如何变化的?
李家林:在数字化化转型的第三阶段,我们意识到既要保证系统数据的灵活可扩展,又要保证底层数据交互统一,降低数据交互的复杂度。此时,安能核心业务系统—结算系统(涉及总部及下属 30000 多家加盟网点,主要包含充值、交易、算费、调账、扣款、代收、代付包括税差全费用结算业务流程处理)因面临系统数据动态扩展、高并发、数据生命周期等问题,需要对系统数据库进行重构,此时就面临数据库选型的需求。
当时,业内主流的选择就 MySQL 和 PostgreSQL 两种。经过比较,团队最终选择了当时常用的 MySQL 加数据库中间件代理的模式。在运行了不到三年的时间,这套系统就出现了比较大的问题,这种伪分布式集群的第一个问题是扩展性太差;第二个问题是库压力不均和性能问题。
为了避免同一个网点查询或处理数据时出现跨库问题,当时分库分表设计的思路是以网点编码作为分库表的路由规则,共分了八个库,除此以外,为了保证单库单表数据量尽量均衡,我们还将产粮区如华东华南和非产粮区如东北西北区域的网点进行相互组合后放在同一个库同一个表中,即便如此,由于业务的不断增长,地区产业布局的变化,网点货量的变化,最终不同库的表数据量还是出现较大差异,个别库的压力极大,这就面临需要对该伪分布式集群增加节点或对现有节点数据进行迁移再平衡,无论哪一种方案,都需要重新设计分库分表路由规则和对现有集群数据进行迁移再平衡的问题,且 MySQL 当时的性能已经到了瓶颈,在线交易数据最多保持六个月的生命周期。基于以上面临的诸多挑战,我们大概在 20 年开始考虑,要对这套结算系统 MySQL 数据库进行换代升级。
InfoQ:快运行业对数据生命周期有哪些具体要求?
李家林:严格意义上来讲,数据都是有生命周期的。相比于快递行业,快运的业务流程节点更多,业务逻辑也更复杂一些,而在每一个业务环节,不但会涉及到业务操作,还会涉及到一些管理的动作,因此每个业务节点都会产生大量数据,而这些数据又环环相扣,这对数据的实时性金和准确性要求非常高。数据生命周期可能会持续一至两年。在结算没有完成之前,数据是不能归档到历史数据的。从业务角度来讲,我们希望在线的结算数据周期生命更长,我们其实没有做严格意义上的冷热数据分离,主要也是考虑到对冷数据进行分析也是存在业务价值的。
InfoQ:基于以上因素,安能物流在数据库选型过程主要考虑哪些因素?
李家林:在选型阶段,我们调研了很多数据库,我们的目标是希望找到一款性能、稳定性、扩展性可以满足业务诉求的分布式数据库。在测试 TiDB 之前,我们先测试了 PostgreSQL,但 PostgreSQL 有自己的集群模式,整体测试效果不及预期。虽然 PostgreSQL 生态也有一些自动化的工具,但与 MySQL 加代理中间件的伪分布式集群没有本质区别。2020 年 3 月份,我们了解并开始测试 TiDB,从 3.0 版本一直测试到 5.4 版本。具体来说,3.0 版本并没有达到安能结算业务的要求,因为该业务对数据的准确性、大规模数据查询和处理能力及高可用性等方面有较高要求。经过测试发现,在 TiDB 5.4 版本可以满足我们的要求,且在此期间 PingCAP 团队也和我们团队进行了交流,到目前为止最新的 TiDB 版本已实现了我们对 TiDB 提出的所有要求。
在测试达到要求之后,团队用了接近 10 个月的时间开始进行迁移,包括迁移前的数据校验等筹备工作。最终,在 2023 年初完成了结算系统的数据库迁移,原有的 MySQL 数据库已经下线。由于快运行业的业务流程比较长,后期会分批进行迁移,目前正在进行快件装车扫描、卸车扫描、分拣扫描等运营操作节点的数据迁移,预计今年底全面完成。
InfoQ:切换前后,整个成本和体验发生了哪些变化?
李家林:一是 TiDB 高度兼容 MySQL,应用代码几乎无改动,系统平滑迁移至 TiDB 上,是一款真正的分布式关系型数据库;二是一键水平扩容或者缩容,可按需对计算、存储分别进行在线扩容或者缩容并对应用运维人员透明;三是金融级高可用,计算与存储分离的多副本存储,保证总部与网点费用结算准确性和高可用;四是大规模数据处理能力和实时 HTAP 特性,增加了在线数据的生命周期,降低系统低延迟;五是内置的图形化监控系统,提供完整闭环监控能力和故障分析能力,降低了运维成本和门槛;六是支持表结构在线变更(DDL),减少了系统变更停机时间,提高了业务的可用性。
InfoQ:为什么没有先从边缘业务开始试点迁移?
李家林:这与研发团队的技术积累和风格有关。此前已经完成了从 Oracle 到 MySQL 数据库的切换,当时是因为 Oracle 的性能确实无法达到要求,团队充分具备相应的技术积累和沉淀,所以本次就直接选择将核心系统从 MySQL 切换到 TiDB,如果从边缘业务开始试点,整个战线会非常长。
InfoQ:安能如何借助于 TiDB 实现数字化升级目标?
李家林:安能在系统建设过程中,经历了从垂直大集中模式到数据独立拆分,再到微服务架构下数据分布式集中存储这样一个过程。目前我们正将业务全链路环节运营操作系统切换到 TiDB 上,从而降低系统数据交互的复杂度。如何使用最简单、最灵活、最高效的技术体系和最少的成本构建新一代数据平台,实现货物从下单到签收及结算等全闭环实时状态追踪。
基于 TiDB 在安能的应用实践,接下来我们将借助 TiDB 分布式、高可用性、弹性伸缩、大规模数据处理和实时 HTAP 等特点来构建新一代一栈式物流数据平台,加速公司数字化升级。
我们将使用 TiDB 作为一栈式物流数据平台的底座,把我们源端业务系统所采集的所有数据,按照业务主题和数据域统一进行存储,降低不同系统之间数据交互的复杂度,解决数据统一的问题。而在一栈式物流数据平台的基础上,我们可以做相应的数据服务,统一对外提供数据服务平台和 API 接口,以及更高阶的数据应用产品。
InfoQ:面向 AI 时代,TiDB 提出了 Serverless 的模式,您怎么看待这一动作?
李家林:目前,Serverless 版本还是在云端,企业级的私有化部署可能需要两到三年的时间。对快运行业而言,一个企业内部可能不太需要建很多的 TiDB 集群,只需要做到用户或应用级别的资源隔离,并给不同的开发人员提供相应的代码开发服务就足够了。基于此,TiDB 的 Serverless 服务可能更多还是面向未来的中小型企业或个人,快运行业可能更多的还是使用其现有的企业级数据库产品。
InfoQ:未来在数据层面,安能物流还有哪些计划?
李家林:对我们而言,最重要的还是底层的数据。现在,我们选择将 TiDB 作为新一代物流平台的数据底座,未来希望基于此统一技术栈,用最简单的体系满足业务层面多样化的数据需求。在 TiDB 的演进过程中,我们需要的功能都正在被 PingCAP 一一实现,相信未来 TiDB 还会出现更多令人期待的功能和特性,这也是我们认为的分布式数据库最优选择。
InfoQ:对于大模型相关技术,安能物流未来是否会考虑接入业务?
李家林:目前,大家普遍想到的场景是智能客服,这需要给大模型输入一些快运行业的特定数据做训练,基本就可以应用了。此外,我们希望可以实现全链路的数据可视化,应用数据挖掘业务的潜在增长点,包括对我们的服务品质和时效性有所提升,通过模型和算法做事前预测,提前干预可能的风险点。
领取专属 10元无门槛券
私享最新 技术干货