您的位置: 主页 > 动态 > 公司动态 >

从 Exadata 到 TiDB 中通快递 HTAP 实践

本文摘要:作者先容:朱志友,中通快递大数据架构师。中通快递配景先容中通快递业务的规模现在是世界第一,是第一个告竣年百亿业务量的快递企业,在 2019 年的双十一更是完成了订单量凌驾 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台,拥有一支千余人规模的研发团队,承袭着“互联网+物流”的理念,与公司的战略、业务精密的衔接,为中通生态圈的业务打造全场景全链路的数字化平台服务。

米乐m7平台登录

作者先容:朱志友,中通快递大数据架构师。中通快递配景先容中通快递业务的规模现在是世界第一,是第一个告竣年百亿业务量的快递企业,在 2019 年的双十一更是完成了订单量凌驾 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台,拥有一支千余人规模的研发团队,承袭着“互联网+物流”的理念,与公司的战略、业务精密的衔接,为中通生态圈的业务打造全场景全链路的数字化平台服务。

上图展示了快递物流的生命周期,简朴举个例子,大家如果在某宝上下了一个订单,从付款竣事开始,到商家勒索,大家的包裹基本上就开启了一个快递的旅程。简朴的先容可以分为五个字,收发到派签,整个物流的全链路中可以拆解成以下的关键节点,客户下单之后快递员的揽收,揽收网点的建包,建包之后会把快递交到中心,至此快递就开启了转运和运输的历程,最终卖力派件的末了网点会凭据三段码的剖析去末了的中心把快递拉到末了的快递网点举行分拣,分拣之后会指派到指定的快递员,举行派件,快递小哥会把快递送到客户的手里,客户完成签收,在我们看来这一票件就完成了快递的全链路的生命周期。在每个环节中会发生大量的数据,对每个环节的每一个数据我们都市举行相关的分析,包罗时效的监控。2017 年的时候,我们就已经开始关注 TiDB ,那时候的关注点主要在解决一些分库分表的问题上,从 2018 年底开始调研测试大数据,我们主要想去解决存储和盘算的问题,2019 年头上线服务生产应用。

现在生产上有近 58 个物理节点,同时服务 OLTP 和 OLAP 的业务,服务平稳。支撑了 2019 年双十一的大促,我们的 QPS 峰值在 12 万+,支持百亿级的插入和更新,TiSpark 支持业务在线的分钟级统计分析。实时 ETL 宽表建设,TiSpark 将实时和离线很好的串联起来,在分析上互为增补。Why TiDB中通为什么会选择 TiDB 呢?随着业务的快速生长,我们遇到了许多技术上面的痛点,主要有以下几个方面:业务生长快、数据量激增, 能存放在 Exadata 一体机数据周期越来越短, 业务方对数据周期需求上升。

分库分表设计满足不了业务方分析和时效需求,统计分析依赖存储历程,系统的扩展性和可维护性不高。业务岑岭单机性能瓶颈,单点故障风险高,数据同步 T+1,分析时效不够。

测试 HBase、Kudu 建设实时数仓,和现有技术栈难以兼容,而且不能很好支撑业务端多维度的 query。有了痛点,接下来谈一下我们的需求。我们的需求主要有以下几点:支持在线扩展,数据按 region 分片,像 HBase 一样能破裂和迁移,最好自己支持热点调理。

强一致的漫衍式事务、二级索引,这是支持原来 Oracle 业务必须要有的。能高并发写和更新,而且支持我们快速的根据业务方的需求查询效果。

技术生态与 Spark 要精密联合,支持我们用 Spark 快速的做分钟级统计分析。支持大宽表的建设,支持多维度的查询分析。Exadata To TiDB上图是我们线上一个比力焦点的系统以前的架构,大家可以看到在各个转运环节中我们有许多的数据,有许多的消息泉源。

左边是我们对接的消息中间件,从这里可以看到我们有许多的 topic。右边可以分为以下几块,第一个是应用消费法式,我们会把这些中间件的消息消费进来,然后存到 Oracle 内里;另外我们会提供 API 和应用的数据服务,对外提供服务能力。

在原来的体系架构内里,大量的数据统计分析依赖于在 Oracle 上建很多多少存储历程,但随着数据量越来越大,我们发现存储和盘算的问题越来越显着,单纯靠升级 Oracle 的硬件无法从基础上解决问题,而且随着硬件的不停升级,成本也越来越高。我们以为应该从一个新的技术方案上去寻找突破,对我们的业务系统举行一个重新的架构升级。这次技术上的升级给我们带来了以下几个利益:数据存储周期从 15 天支持到 45 天。

支持在线横向扩展,随时上下线存储和盘算节点,应用无感知。满足高性能的 OLTP 的业务需求,性能略低于 Oracle,这个无法制止,因为 TiDB 是一个漫衍式的数据库。数据库单点压力没了,TP 和 AP 分散。

m6米乐官网入口

支持更多业务维度的分析。整体架构清晰,可维护性增强,系统扩展性增强。

硬件成本降低。上图是我们整个系统重构后的架构:左边这部门还是许多消息的接入,通过 Spark 实时盘算把这些消息接进来,与 Hive 维表在漫衍式盘算内里做一些 Merge 和 JOIN。

同时会跟离线 T+1 的盘算分析出来的数据、存在 HBase 的数据做 Merge 的盘算。最终盘算的效果我们会把它存到 TiDB 内里。我们天天会定时的和 TiDB 做一次同步,把 TiDB 的数据同步到 Hive,做一个数据备份。我们依赖于 TiSpark 在 TiDB 上做数据的统计分析,通常称为汇总层,汇总层包罗公共数据和业务层数据,我们也会把这些数据放在 Oracle 内里一份,包罗轻度汇总和多维汇总我们还会基于 TiDB 去提供明细的服务,像 API 接口的服务、明细查询和一些标签。

重新的架构上看,每一个关键的节点都支持可横向扩展,基本上没有单点或者单关键路径上压力的问题。实时宽表建设其实在 2017 年的时候我们就一直在探索实时数仓的建设,我们测试过 HBase 和 Kudu。在海内,小米使用 Kudu 比力多,写入性能还是不错的,可是社区活跃度一般,使用的是 Impala 作为查询引擎,可是在我们的技。


本文关键词:从,Exadata,到,TiDB,中通,快递,m6米乐官网入口,HTAP,实践,作者

本文来源:m6米乐官网入口-www.becannt.com