关于数据库:从-Exadata-到-TiDB中通快递-HTAP-实践

作者介绍：朱志友，中通快递大数据架构师。

中通快递背景介绍

中通快递业务的规模目前是世界第一，是第一个达成年百亿业务量的快递企业，在 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 的硬件无奈从根本上解决问题，并且随着硬件的一直降级，老本也越来越高。咱们感觉应该从一个新的技术计划下来寻找冲破，对咱们的业务零碎进行一个从新的架构降级。

这次技术上的降级给咱们带来了以下几个益处：

1. 数据存储周期从 15 天反对到 45 天。
2. 反对在线横向扩大，随时高低线存储和计算节点，利用无感知。
3. 满足高性能的 OLTP 的业务需要，性能略低于 Oracle，这个无奈防止，因为 TiDB 是一个分布式的数据库。
4. 数据库单点压力没了，TP 和 AP 拆散。
5. 反对更多业务维度的剖析。
6. 整体架构清晰，可维护性加强，零碎扩展性加强。
7. 硬件老本升高。

上图是咱们整个零碎重构后的架构：

• 右边这部分还是很多音讯的接入，通过 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 拉挂的状况，针对这个问题咱们做了一些监控和管控，次要有以下几点：

1. 监控线上非凡账号的慢 SQL，咱们主动会杀掉，而后告诉到运维和利用的负责人；
2. 开发了 Query 的平台，让用户应用 Spask SQL 去查问 TiDB 的数据，并发和平安的管制；
3. 指标额定接入了小米监控，外围的告警会电话告诉到相干的值班人员，相当于做了自动化监控的值班。

遇到的问题

上面来说一下在应用 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 上的演讲。