黄东旭解析 TiDB 的核心优势
535
2018-06-29
内容来源:http://mp.weixin.qq.com/s?__biz=MzI3NDIxNTQyOQ==&mid=2247486332&idx=1&sn=145ca8d250ec379a9ddaaafa56bf216c&chksm=eb162c16dc61a500005aa05ac843e18a47adc91d0f975055765c2a46bb6056e796c282264abd#rd
背景介绍
特来电新能源有限公司是创业板第一股特锐德(300001)的全资子公司,主要从事新能源汽车充电网的建设、运营及互联网的增值服务。特来电颠覆了传统充电桩的模式,世界首创了电动汽车群智能充电系统,获得 336 项技术专利,以“无桩充电、无电插头、群管群控、模块结构、主动防护、柔性充电”的特点引领世界新能源汽车充电的发展,系统的鉴定结论为:“产品世界首创、技术水平国际领先。主动柔性充电对电池寿命可以延长 30% 左右,电池充电的安全性可以提升 100 倍以上。”
特来电采用互联网思维,依靠国际领先的汽车群智能充电技术和系统,创新电动汽车充电商业模式,建设全国最大的汽车充电网,通过大系统卖电、大平台卖车、大共享租车、大数据修车、大支付金融、大客户电商,打造让客户满意、政府放心的中国最大汽车充电网生态公司,引领充电网、车联网、互联网“三网融合”的新能源互联网。
为什么研究 TiDB
随着接入大数据平台的核心业务的增加,我们在 OLAP 上主要遇到以下痛点问题:
随着基于大数据分析计算的深入应用,使用 SQL 进行分析的需求越来越旺盛,但目前已经上线的大数据集群( ***、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 的界限逐渐模糊,比如现在 *** 之上有 Phoenix,HiveSQL,SparkSQL 等,也有一些观点认为 NewSQL = SQL + NoSQL。不同的技术都有各自的最佳适应场景,Spanner 和 F1 被认为是第一个 NewSQL 在生产环境提供服务的分布式系统技术,基于该理念的开源产品主要为 CockroachDB、TiDB。结合社区活跃度以及相关案例、技术支持,我们决定 NewSQL 技术上引入 TiDB。
TiDB 介绍
图 2 TiDB 架构图
TiDB 具有以下核心特性:
高度兼容 MySQL —— 无需修改代码即可从 MySQL 轻松迁移至 TiDB
水平弹性扩展 —— 轻松应对高并发、海量数据场景
高可用 —— 基于 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 作为机器学习的数据源;借助调度系统产生定时报表等等。
目前的应用情况
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 多年平台软件设计开发经验,现专注于大数据领域快速读写方向。
更多案例
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。