TiDB 在特来电的实践

作者介绍：潘博存，特来电大数据技术研发部架构师，具有 10 多年平台软件设计开发经验，现专注于大数据领域快速读写方向。

背景介绍

特来电新能源有限公司是创业板第一股特锐德（300001）的全资子公司，主要从事新能源汽车充电网的建设、运营及互联网的增值服务。特来电颠覆了传统充电桩的模式，世界首创了电动汽车群智能充电系统，获得 336 项技术专利，以“无桩充电、无电插头、群管群控、模块结构、主动防护、柔性充电”的特点引领世界新能源汽车充电的发展，系统的鉴定结论为：“产品世界首创、技术水平国际领先。主动柔性充电对电池寿命可以延长 30% 左右，电池充电的安全性可以提升 100 倍以上。”

特来电采用互联网思维，依靠国际领先的汽车群智能充电技术和系统，创新电动汽车充电商业模式，建设全国最大的汽车充电网，通过大系统卖电、大平台卖车、大共享租车、大数据修车、大支付金融、大客户电商，打造让客户满意、政府放心的中国最大汽车充电网生态公司，引领充电网、车联网、互联网“三网融合”的新能源互联网。

为什么研究 TiDB

特来电大数据平台通过开源与自研相结合的方式，目前已经上线多套集群满足不同的业务需求。目前在大数据存储和计算方面主要使用了 HBase、Elasticsearch、Druid、Spark、Flink。大数据技术可谓是百花齐放、百家争鸣，不同的技术都有针对性的场景。结合实际情况，选择合适的技术不是一件容易的事情。

随着接入大数据平台的核心业务的增加，我们在 OLAP 上主要遇到以下痛点问题：

• 随着基于大数据分析计算的深入应用，使用 SQL 进行分析的需求越来越旺盛，但目前已经上线的大数据集群（HBase、Elasticsearch、Druid、Spark、Flink）对 SQL 的支持度都比较弱。

• 目前进入大数据集群的数据主要以宽表方式进行，导致在数据归集和后期基础数据放生变化时应用成本较高。

• 数据仓库业务有些还是基于复杂的 T+1 模式的 ETL 过程，延时较高，不能实时的反映业务变化。

• 由于每个大数据集群主要针对特定的场景，数据重复存储的情况较多，这就造成了存储成本的增加，同时也会导致数据的不一致性。

• 目前进入 HDFS / Druid / ES 的数据，在历史数据更新时，成本较高，灵活性降低。

大数据技术发展迅速，我们也一直希望采用新的技术可以解决我们以上问题，我们关注到目前 NewSQL 技术已经有落地产品，并且不少企业在使用，所以决定在我们平台内尝试引入 NewSQL 技术解决我们的痛点问题。

我们先了解一下 NewSQL。

如图 1 所示，数据库的发展经历了 RDBMS、NoSQL 以及现在的 NewSQL，每种不同的技术都有对应的产品，每种数据库的技术背后，都有典型的理论支撑。2003 年 Google GFS 开创了分布式文件系统、2006 年的 BigTable 论文催生了 Hadoop 生态，在 2012 年的 Spanner 和 2013 年的 F1 论文发表后，被业界认为指明了未来关系型数据库的发展。

随着大数据技术的发展，实际上 SQL 和 NoSQL 的界限逐渐模糊，比如现在 HBase  之上有 Phoenix，HiveSQL，SparkSQL 等，也有一些观点认为 NewSQL = SQL + NoSQL。不同的技术都有各自的最佳适应场景，Spanner 和 F1 被认为是第一个 NewSQL 在生产环境提供服务的分布式系统技术，基于该理念的开源产品主要为 CockroachDB、TiDB。结合社区活跃度以及相关案例、技术支持，我们决定 NewSQL  技术上引入 TiDB。

TiDB 介绍

TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。

TiDB 具有以下核心特性：

• 高度兼容 MySQL —— 无需修改代码即可从 MySQL 轻松迁移至 TiDB

• 水平弹性扩展 —— 轻松应对高并发、海量数据场景

• 分布式事务 —— TiDB 100% 支持标准的 ACID 事务

• 高可用 —— 基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证

• 一站式 HTAP 解决方案 —— 一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程

其中涉及到的分布式存储和分布式计算，大家可以参考 TiDB 的官方网站，在这里就不再进行论述。

在处理大型复杂的计算时，PingCAP 结合上图说的 TiKV 以及目前大数据生态的 Spark，提供了另外一个开源产品 TiSpark。不得不说这是一个巧妙的设计，充分利用了现在企业已有的 Spark 集群的资源，不需要另外再新建集群。TiSpark 架构以及核心原理简单描述如下：

TiSpark 深度整合了 Spark Catalyst 引擎，可以对计算提供精确的控制，使 Spark 能够高效的读取 TiKV 中的数据，提供索引支持以实现高速的点查。

通过多种计算下推减少 Spark SQL 需要处理的数据大小，以加速查询；利用 TiDB 的内建的统计信息选择更优的查询计划。

从数据集群的角度看，TiSpark + TiDB 可以让用户无需进行脆弱和难以维护的 ETL，直接在同一个平台进行事务和分析两种工作，简化了系统架构和运维。

除此之外，用户借助 TiSpark 项目可以在 TiDB 上使用 Spark 生态圈提供的多种工具进行数据处理。例如使用 TiSpark 进行数据分析和 ETL；使用 TiKV 作为机器学习的数据源；借助调度系统产生定时报表等等。

目前的应用情况

由于很多用户已经部署了生产系统，我们没有在测试上再次投入比较大的精力，经过了简单的性能测试以后，搭建了我们的第一个 TiDB 集群，尝试在我们的业务上进行使用。目前主要用于我们的离线计算，以及部分即系查询场景，后续根据使用情况，逐渐调整我们的集群规模以及增加我们的线上应用。

1. 目前的集群配置

2. 规划的应用架构

基于 TiDB 我们规划了完整的数据流处理逻辑，从数据接入到数据展现，由于 TiDB 高度兼容 MySQL，因此在数据源接入和 UI 展现就有很多成熟的工具可以使用，比如 Flume、Grafana、Saiku 等。

3. 应用简介

a. 充电功率的分时统计

每个用户使用特来电的充电桩进行充电时，车辆的 BMS 数据、充电桩数据、环境温度等数据是实时的保存到大数据库中。我们基于采集的用户充电数据，需要按照一定的时间展示全国的充电功率 比如展示过去一天，全国的充电功率变化曲线，每隔 15 分钟或者 30 分钟进行一次汇总。随着我们业务规模的增加，此场景的计算也逐步进行了更新换代。

目前我们单表数据量接近 20 亿，每天的增量接近 800 万左右。使用 TiDB 后，在进行离线计算分析时，我们的业务逻辑转成了直接在我们的离线计算平台通过 SQL 的方式进行定义和维护，极大的提高了维护效率，同时计算速度也得到了大幅提升。

b. 充电过程分析

上面我们讲了，我们已经有了充电过程中的宝贵的海量数据，如何让数据发挥价值，我们基于充电数据进行充电过程的分析就是其中的一个方式，比如分析不同的车型在不同的环境（环境温度、电池特性）下，充电的最大电压和电流的变化情况，以及我们充电桩的需求功率满足度等。

针对海量的历史数据计算我们使用了 TiSpark 进行计算，直接使用了我们现有的 Spark 集群，在使用 Spark 进行计算时，一开始由于不熟悉 TiSpark，分配的资源比较少，耗时多一些。后来和 TiDB 技术人员交流了解到最佳实践，提升配置和调整部分参数后，性能提升不少。这个场景中我们充分利用了 TiDB 和 TiSpark 进行协同工作，满足了我们的业务需求。

总结及问题

1. 最佳应用场景

结合我们的线上验证，我们认为使用 TiDB，主要有以下几个优势：

• SQL 支持度相对于现有的集群支持度较好，灵活性和功能性大大增强。

• 可以进行表之间的 join 运算，降低了构造宽边的复杂度以及因此带来的维护成本。

• 历史数据方便修改。

• 高度兼容 MySQL 生态下对应的成熟软件较多（开发工具、展现、数据接入）。

• 基于索引的 SQL 性能在离线计算上基本可以满足我们需求，在即席查询上最适合海量数据下进行多维度的精确查询，类似与“万里挑一”的场景。

• 使用 TiSpark 进行复杂的离线计算，充分利用了现有的集群，数据存储做到了一份，同时也降低了运维成本。

2. 目前的定位

结合我们的实际现状，现阶段我们主要用于进行离线计算和部分即席查询的场景，后期随着应用的深入，我们逐步考虑增加更多的应用以及部分 OLTP 场景。