TiDB 在特来电的实践

背景介绍

特来电新能源有限公司是创业板第一股特锐德（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 数据库发展史

如图 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，支持无限的水平扩展，具有强一致性和高可用性。

图 2 TiDB 架构图

TiDB 具备如下核心特性：

• 高度兼容 MySQL —— 无需修改代码便可从 MySQL 轻松迁移至 TiDB
• 水平弹性扩展 —— 轻松应对高并发、海量数据场景
• 分布式事务 —— TiDB 100% 支持标准的 ACID 事务
• 高可用 —— 基于 Raft 的多数派选举协议能够提供金融级的 100% 数据强一致性保证
• 一站式 HTAP 解决方案 —— 一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程

其中涉及到的分布式存储和分布式计算，你们能够参考 TiDB 的官方网站，在这里就再也不进行论述。

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

图 3 TiSpark 架构图

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

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

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

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

目前的应用状况

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

1. 目前的集群配置

图 4 集群配置清单

2. 规划的应用架构

图 5 引入 TiDB 之后的应用架构图

基于 TiDB 咱们规划了完整的数据流处理逻辑，从数据接入到数据展示，因为 TiDB 高度兼容 MySQL，所以在数据源接入和 UI 展示就有不少成熟的工具可使用，好比 Flume、Grafana、Saiku 等。

3. 应用简介

a. 充电功率的分时统计

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

图 6 充电功率的分时统计

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

b. 充电过程分析

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

图 7 充电过程分析

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

总结及问题

1. 最佳应用场景

结合咱们的线上验证，咱们认为使用 TiDB，主要有如下几个优点：

• SQL 支持度相对于现有的集群支持度较好，灵活性和功能性大大加强。
• 能够进行表之间的 join 运算，下降了构造宽边的复杂度以及所以带来的维护成本。
• 历史数据方便修改。
• 高度兼容 MySQL 生态下对应的成熟软件较多（开发工具、展示、数据接入）。
• 基于索引的 SQL 性能在离线计算上基本能够知足咱们需求，在即席查询上最适合海量数据下进行多维度的精确查询，相似与 “万里挑一” 的场景。
• 使用 TiSpark 进行复杂的离线计算，充分利用了现有的集群，数据存储作到了一份，同时也下降了运维成本。

2. 目前的定位

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

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