IT效率提高3倍：使用横向扩展数据库进行近实时分析

ZTO Express是中国领先的快递公司，也是全球最大的快递公司之一。截至2016年12月31日，我们在中国提供快递服务以及其他增值物流服务，覆盖中国96％以上的城市和县。在一年一度的中国购物节的一天2019年11月11日，我们的促销活动获得了超过2亿张订单。

随着我们业务的迅速发展，大量数据涌入我们的数据库。 Oracle Exadata无法满足我们对数据存储的要求。在分片数据库后，我们无法实时执行数据分析，并且数据库无法扩展。另外两个选项Apache Kudu和HBase对于构建实时数据仓库并不理想。我们寻找的数据库支持水平可伸缩性，具有高度一致性的分布式事务，高度并发的写入以及分钟级的多维查询。

借助TiDB这个开源，分布式，混合事务处理/分析处理（HTAP）数据库，我们将IT效率提高了300％，并且在2020年第二季度，我们的每笔订单成本同比下降了17.1％ -年。

在这篇文章中，我将描述为什么我们从Oracle Exadata迁移到TiDB，以及TiDB如何帮助扩展我们的数据库并以几分钟的查询响应时间支持我们的多维分析。

随着Exadata数据库中数据量的增长，Exadata的存储容量面临着巨大的挑战。 Exadata中的数据存储时间越来越短，而应用程序团队则要求数据存储时间越来越长。

分片解决方案无法满足我们对实时数据分析的要求。数据分析依赖于存储过程，并且系统的可伸缩性和可维护性很差。

在高峰时段，我们存在独立的机器性能瓶颈和单点故障的高风险。数据以T + 1模式复制。我们无法实时执行数据分析。

为了构建实时数据仓库，我们测试了HBase和Kudu。但是Kudu与现有的技术堆栈不兼容，并且HBase对多维查询的支持非常有限。

它支持在线水平可伸缩性。数据被＆＃34;分割地区＆＃34;可以像在HBase中一样进行拆分和迁移。它最好支持热点自动调度。

为了支持原始的Oracle应用程序，它应该支持高度一致的分布式事务和二级索引。

它支持高并发写入和更新，并能够根据应用程序团队的需求快速查询结果。

其技术生态与Spark紧密集成在一起，因此我们可以使用Spark快速执行分钟级别的数据分析。

TiDB是由PingCAP及其开源社区构建的开源，云原生，分布式SQL数据库。它与MySQL兼容，并具有水平可伸缩性，强一致性和高可用性。它是用于在线事务处理（OLTP）和在线分析处理（OLAP）工作负载的一站式解决方案。您可以在此处了解有关TiDB架构的更多信息。

在2019年，我们部署了TiDB进行生产。当前，我们的生产环境拥有100多个物理节点，可同时为OLTP和OLAP应用程序提供服务。 TiSpark是TiDB的OLAP解决方案，它运行在TiDB的存储引擎之上，它支持我们的在线分析查询，查询响应时间在几分钟之内。当我们构建实时的提取，转换，加载（ETL）宽表时，TiSpark有效地连接了实时数据和脱机数据。

在采用TiDB之前，ZTO Express的核心系统架构如下所示：

每个数据传输点中都有大量数据和许多信息源。在上面的架构图中：

在右侧，应用程序使用者使用了这些中间件消息并将其存储在Oracle中。我们拥有API和应用程序数据服务来提供外部服务功能。

在这种体系结构中，对大量数据的数据分析依赖于在Oracle上构建许多存储过程。但是随着数据量的增加，存储和计算问题变得越来越严重。不幸的是，我们无法通过简单地升级我们的Oracle硬件来解决该问题，而且无论如何，这种选择都是昂贵的。因此，我们决定寻找一种新的解决方案。

左边是许多消息。 Spark将这些消息实时连接到系统，并对分布式计算框架中Hive维度表中的数据执行MERGE和JOIN操作。同时，Spark对通过离线T + 1计算模式分析的数据和存储在HBase中的数据执行MERGE操作。

我们将最终的计算结果保存在TiDB中。每天，我们将TiDB中的数据复制到Hive进行数据备份。

TiSpark是构建用于在TiDB或TiKV存储层之上运行Apache Spark来回答复杂的OLAP查询的薄层。我们使用TiSpark在TiDB上执行数据分析，这称为摘要层。摘要层包括公共数据和应用程序层数据。我们还将这些数据放在Oracle中，包括一个简单的摘要层和一个多维的摘要层。

我们还提供基于TiDB的详细服务，例如API接口服务，详细查询和一些标签。

在此体系结构中，每个关键节点都支持水平可伸缩性。通常，在单个节点或单个关键路径上没有压力。

2017年，我们探索了一种构建实时数据仓库的方法。我们测试了Apache HBase和Kudu，发现它们是不受欢迎的：

Kudu使用Impala作为查询引擎，但我们主要使用Presto作为查询引擎。可能存在兼容性问题。此外，Kudu社区并不活跃。

在我们的物流过程中，许多消息都连接到我们的系统。我们需要预测每个包裹的完整运输路径路由和等待时间，并为每个要转移的包裹捕获数据。我们需要以低延迟处理大量数据，因此我们决定使用TiDB和TiSpark来构建实时宽表。

我们建立了一个包含70多个字段的宽表。在我们的宽表中，OLTP数据被实时写入TiDB。 TiSpark使用分钟级的查询响应时间来处理OLAP查询。

在使用TiSpark之前，我们尝试使用DataX和Sqoop，但它们的ETL处理速度远低于TiSpark。我们的测试表明，TiSpark花了大约10分钟的时间将3亿行数据复制到Hive。此外，实时宽表中的数据来自10多个Kafka主题。当将多个消息写入系统时，很难保证消息的顺序。 TiSpark可以帮助我们在实时分析方案中集成脱机数据。

Spark将多个消息连接到集群以进行计算，并对Hive维度表中的数据执行JOIN操作。

加入JOIN之后，我们将详细数据存储在TiDB中，然后使用TiSpark在TiDB中计算数据并将其存储在Hive中。我们使用Presto集群为分析提供数据。

我们使用TiSpark将一些脱机数据刷新回TiDB以进行T + 1分析，并使用TiDB提供外部应用程序支持服务。

我们使用此表对整个快递路线进行实时分析，包括实时监控。通过这种机制，我们可以几乎实时地了解运输过程中每个包裹的状态。

TiDB使用Prometheus加Grafana作为其监视机制。监控指标可以满足我们的需求。我们使用DataX以T + 1模式将数据复制到Hive进行数据备份。但是，由于我们的集群同时支持在线应用程序和开发人员查询，因此SQL查询曾经使我们的数据库服务器不堪重负。为解决此问题，我们采取了以下措施：

我们会监控特殊帐户在线执行的缓慢SQL查询。系统会自动终止这些查询，然后通知操作和维护人员以及负责该应用程序的人员。

我们开发了查询平台，使用户可以使用Spark SQL语句从TiDB查询数据，并添加了并发控制和安全控制功能。

指标还连接到小米监控。如果发生严重警报，监视系统将致电相关人员。

2019年，我们完成订单121.2亿张，同比增长42.2％，超过行业平均增速16.9个百分点。在2019年11月11日，TiDB支持了我们的大规模促销活动，峰值流量达到了每秒超过120,000个查询（QPS）。它还支持数百亿行的插入和更新。 TiSpark支持我们的在线分钟级数据分析。这保证了我们的IT服务在促销日稳步运行。

此外，我们基于TiDB的新数据库基础架构还为我们带来了以下好处：

TiDB对OLTP工作负载具有高性能。性能可能会略低于Oracle，但这是因为TiDB是分布式数据库。

TiDB支持在线水平可伸缩性。要扩展或扩展，我们可以随时在存储或计算层中添加或删除节点。扩展过程对应用程序操作和维护人员是透明的。

OLTP和OLAP工作负载是分离的，并且单个节点上的压力消失了。

当前，我们在生产环境中有100多个TiDB物理节点和200多个TiDB实例。它们主要服务于票据，结算中心，订单中心，运单中心，消息中心以及与智能转运相关的应用程序。

以数据为依据的精细化管理措施继续有效。在2020年第二季度，我们的每笔订单成本同比下降了17.1％。

与Oracle相比，TiDB的灵活，高效和按需部署计划显着降低了我们的总拥有成本（TCO）。

当我们开始使用TiDB时，我们遇到了一些问题。与PingCAP团队一起，我们已经解决了其中的一些问题。

特殊应用在特定时间范围内有大量写入和更新。当前，我们主要关注的是索引热点。我们按时间查询许多应用程序，因此我们需要创建与时间相关的索引或复合索引。在连续的时间段内进行写入或更新可能会导致索引热点。这可能会影响写入性能。

PingCAP团队将在将来优化此问题，我们希望最终可以缓解我们的问题。

当某些SQL语句涉及大量协处理器请求，并且键值实例已完全加载时，群集写入性能会下降。在这种情况下，要查找昂贵的SQL语句，我们需要查看日志或运行SHOW PROCESSLIST命令进行故障排除。当有许多TiDB服务器时，故障排除非常耗时。为了解决此问题，我们将所有日志连接到Elastic Stack（以前是＆＃34; ELK堆栈＆＃34;）。

为了解决此问题，TiDB 4.0引入了TiDB Dashboard，它是带有各种内置小部件的图形界面，使用户可以轻松地诊断，监视和管理其集群。它显示每个查询的SQL语句，其执行结束时间，查询延迟和最大内存使用量。在一个地方，用户可以查看集群中所有慢速查询的详细信息。

此外，PingCAP团队还开发了时间线跟踪功能，该功能将为所有SQL语句自动启用。实施此功能后，用户将能够知道每个SQL语句在其生命周期的每个阶段的执行时间。此功能将在TiDB 5.0中推出。

我们有许多UPDATE，INSERT和DELETE语句。以前，我们使用TiDB 3.0.3。系统稳定运行一段时间后，我们在监视指标图中发现了一些问题。某些节点的度量标准（例如Raftstore CPU度量标准）间歇性丢失，而与群集性能相关的监视度量标准（例如SQL持续时间度量标准）则缓慢上升。

起初，我们认为问题在于监视本身。但是有了PingCAP工程师帮助，我们发现问题是由于内存碎片。然后，我们对集群进行了滚动重启，问题得到了暂时解决。 TiDB 3.0.14修复了此问题，并且由于我们已升级到该版本，因此不再是问题。

当前，我们有许多应用程序可以在TiDB 3.0.14中稳定运行。 2020年5月，发布了TiDB 4.0 GA。 TiDB 4.0的许多功能可以满足我们的紧急需求，例如大数据量，大事务的备份和TiFlash（TiDB的扩展分析引擎，用于执行实时HTAP分析）。

现在，我们的OLTP和OLAP应用程序并没有在键值节点上真正分离。当我们有大量的分析查询并且它们跨越很长的时间范围并且涉及大量数据时，索引过滤性能很差。这将导致全表扫描。在这种情况下，TiSpark需要大量资源，并且键值节点上的压力很大。在高峰时间，数据分析可能会影响写入性能。因此，我们密切关注TiFlash。接下来，我们将测试TiDB 4.0并建立一个实时数据仓库。

如果您想详细了解我们在TiDB方面的经验，可以在Slack上加入TiDB社区。

如果您想在云环境中尝试TiDB，请考虑TiDB Cloud，这是具有HTAP支持的完全托管的数据库服务。您可以在此处申请为期两周的免费试用。