全国服务热线:0248-343826855 欢迎来到英雄联盟竞猜-lol比赛在哪里可以押注官网!
您的位置:主页 > 企业实力 > 资质认证 >

从 Exadata 到 TiDB,中通快递 HTAP 实践

发布时间:2021-11-22 00:55 人气: 来源:lol比赛在哪里可以押注

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

英雄联盟竞猜

作者先容:朱志友,中通快递大数据架构师。中通快递配景先容中通快递业务的规模现在是世界第一,是第一个告竣年百亿业务量的快递企业,在 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 分散。支持更多业务维度的分析。

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

同时会跟离线 T+1 的盘算分析出来的数据、存在 HBase 的数据做 Merge 的盘算。最终盘算的效果我们会把它存到 TiDB 内里。我们天天会定时的和 TiDB 做一次同步,把 TiDB 的数据同步到 Hive,做一个数据备份。

我们依赖于 TiSpark 在 TiDB 上做数据的统计分析,通常称为汇总层,汇总层包罗公共数据和业务层数据,我们也会把这些数据放在 Oracle 内里一份,包罗轻度汇总和多维汇总我们还会基于 TiDB 去提供明细的服务,像 API 接口的服务、明细查询和一些标签。重新的架构上看,每一个关键的节点都支持可横向扩展,基本上没有单点或者单关键路径上压力的问题。实时宽表建设其实在 2017 年的时候我们就一直在探索实时数仓的建设,我们测试过 HBase 和 Kudu。在海内,小米使用 Kudu 比力多,写入性能还是不错的,可是社区活跃度一般,使用的是 Impala 作为查询引擎,可是在我们的技术栈里主要使用的是 Presto,兼容性有待思量,而且 Hbase 很难满足我们全部业务 Query 的需求。

在我们整个物流链路的历程中,有许多消息的接入,我们需要针对每一票件举行全链路路由和时效的预测,定位到每一票件转运环节,不仅数据量大,而且对时效要求高。有了之前的项目履历,我们决议实验用 TiDB+TiSpark 构建我们实时宽表建设。实时数仓宽表建设,业务的 OLTP 数据通过 TiDB 实时写入,我们构建了一个 70+ 字段的宽表,后续 OLAP 的业务是通过 TiSpark 做分钟级的分析,有五分钟也有十分钟的。

之前我们接纳过 DataX 和 Sqoop,但数据同步的效率远远不如 TiSpark,而且还遇到过把 TiDB Server 拉挂的情况。经由我们的测试,TiSpark 同步 3 亿条数据到 Hive 或许需要 10 分钟,这为我们的实时数据建设与离线 T+1 的整合提供了保障。而且实时宽表的建设泉源于 10 多个 topic,多个消息的接入很难保障消息之间的有序性, TiSpark 可以资助我们在实时业务分析的场景中融合离线数据。上图是我们实时宽表建设一个或许的架构:通过 Spark 把多个消息接入到集群内里做盘算,而且和 Hive 维表做 JOIN。

JOIN 之后我们会把明细数据存到 TiDB,接下来通过 TiSpark 来盘算 TiDB 中的数据并存到 Hive,并通过 Presto 集群对外提供分析的数据支持。另外我们会把 T+1 的一些离线分析数据通过 TiSpark 回刷到 TiDB,并通过 TiDB 对外提供业务应用支持的服务。以上是我们现在实时宽表的建设,它支撑了我们全链路的时效分析,包罗时效的监控,基本上能到达准实时的相识到每一票件在每一个环节是否出了问题。

运维TiDB 有富厚的监控指标,他们使用的是比力盛行的 Prometheus + Grafana,监控指标已经可以满足我们的需求。关于数据同步,我们接纳了 DataX T+1 同步到 Hive 做数据备份,但因为我们集群既支持线上业务,也支持开发人员来做一些数据的查询,所以之前遇到过 SQL 把 DB server 拉挂的情况,针对这个问题我们做了一些监控和管控,主要有以下几点:监控线上特殊账号的慢 SQL,我们自动会杀掉,然后通知到运维和应用的卖力人;开发了 Query 的平台,让用户使用 Spask SQL 去查询 TiDB 的数据,并发和宁静的控制;指标分外接入了小米监控,焦点的告警会电话通知到相关的值班人员,相当于做了自动化监控的值班。遇到的问题下面来说一下在使用 TiDB 的历程我们遇到的一些问题。

首先是热点问题,因为我们业务的一些特殊性,在特定的时间规模内会有大量写入、更新的需求,索引热点在现在情况下比力突出,许多业务基于时间来查询,需要建立时间相关的索引或者组合索引,一连时间段的写入或更新会导致索引热点,影响部门写入性能。第二点是部门问题排查比力难题,我们在线上会发现当部门的 SQL 触发了大量的 Coprocessor 时,会导致 KV 示例负载 Load 打满后,集群写入性能下降,此时定位 expensive SQL 需要检察日志,或者通过 Show Processlist 去排查,当 DBserver 较多时,排查比力泯灭时间艰苦,我们想的解决措施是把这些日志的情况全都接入到 ELK。第三个问题是内存碎片化,因为我们有大量数据的更新、插入,也有大批量的数据删除。

我们其时用的版本是 TiDB 的 3.0.3 的版本,在系统稳定运行一段时间后,发现监控上的部门节点的监控数据触底了,像 Raftstore CPU,而且相关的监控指标,如 SQL Duration 有缓慢上升的趋势,一开始排查误以为是监控的问题,厥后在 TiDB 工程师的协助下,最终定位为内存碎片化的问题,其时通过转动重启集群暂时解决问题。在 TiDB 3.0.14 的版本中,这个问题已经获得相识决,我们升级后现在未发现异常。

总结和展望现在我们有多条业务线稳定的运行在 3.0.14 的版本上, TiDB 4.0 GA 在 5 月 28 号公布,从 2019 年我们就关注着这个版本的进度,其中许多新的特性都是我们迫切需要的,好比说像大数据量的备份、大事务、TiFlash 等。现在我们 TP 和 AP 的业务在 KV 节点上还不是真正的物理分散,当有大量的分析需求, 且分析的时间周期跨度大、数据量大的时候,数据过滤的性能并不高,TiSpark 的资源需求很大,KV 的节点压力也较大,在业务岑岭的时候我们发现分析会影响到部门写入的性能,所以在 4.0 的版本中我们特别关注 TiFlash,TiFlash 是为分析而生的,也是我们迫切需要的。接下来我们会专注 4.0 的测试,加大实时数仓的建设。本文整理自朱志友在 TiDB DevCon 2020 上的演讲。


本文关键词:从,Exadata,英雄联盟竞猜,到,TiDB,中通,快递,HTAP,实践,作者

本文来源:英雄联盟竞猜-www.sprnext.com

在线客服
联系方式

热线电话

13961794152

上班时间

周一到周五

公司电话

0248-343826855

二维码
线