项目内使用的MySQL2Hive任务失败，是由于数仓使用的TiDB新版组件BUG引起的，自此了解到了TiDB。恰逢美团技术团队公众号2018.11.22发了一篇文章新一代数据库TiDB在美团的实践，就花了点时间进一步了解了下TiDB。TiDB 是 PingCAP 公司（中国一家开源新型分布式数据库公司 ）设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，已在多家互联网公司使用：美团、今日头条、爱奇艺、饿了么等大规模使用。
1 数仓为何要用TiDB
目前公司线上业务库中的数据分析现有的架构会有如下问题：
- 现有的业务数据量比较大，多源DB压力大，不易优化，经常出现问题（如cpu满载等）
- Sqoop导入数据低效（1. Sqoop通过JDBC读取数据 2. Sqoop的Mapreduce虽然是分布式的，但是Mysql的数据库却只是单台，无法达到分布式的效果）
- 元数据信息不透明，用户通过调度系统添加调度任务的时候，对业务库的元数据不太了解，往往需要咨询DBA
- 数据导入过程中缺乏导入信息的统计，如导入的数据量等
- 数据的导入是T+1的模式，时效性不够
- 每次都全量导入到大数据集群中，造成存储，网络等资源的浪费
- 无法实现业务数据的OLTP分析，甚至跨多个库的联合分析
2 TiDB概述
2.1 简介
TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
TiDB 具备如下特性：
-
高度兼容 MySQL
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
-
水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
-
分布式事务
TiDB 100% 支持标准的 ACID 事务。
-
真正金融级高可用
相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
-
一站式 HTAP 解决方案
TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。
-
云原生 SQL 数据库
TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。
TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。
2.2 在互联网公司的应用
2.2.1 今日头条
TiDB 主要应用在今日头条核心 OLTP 系统 - 对象存储系统的部分元数据存储，支持头条图片和视频相关业务，比如抖音等。
TiDB 支撑着今日头条 OLTP 系统里数据流量最大、QPS 最高的场景：集群容量 几十T，数据量日增 5 亿，日常 QPS 均值在 12W，峰值 20W 左右。
用 TiDB 之前，元数据是存在 MySQL 里的一个 2.8TB 的SSD盘，因为增长的特别快，所以导致磁盘不够用，只能用分库分表的方案。
用的的分库分表的方案是 MyCAT。但用这个方案的过程中遇到了一些问题。比如丢数据；再就是连接的问题，目前头条做分片是大概固定分 100 个片。如果你的业务是需要分库分表，那好，你这边搞 101 个分片，这样有些业务，他用了一个分片键，用分片键来做查询，那可能中间件只用一个连接就可以找到相关数据。但有些业务，确实有不带分片键的请求。会导致 select 语句过来的时候，下面会建 101 个对后端的连接，也就是说，因为有连接的限制，有一个没有带分片键的这种请求过来之后， MyCAT 可以启 101 个连接到后面的每一个 MySQL 库。那这样的话，有时候我给它 5 万个连接，他一下子就把一百万用掉了。这样会导致，它在非分片键的 select 请求，它连接速度消耗非常快，经常在业务这边会抛出说，连接数不够。
目前平均值 QPS 在 12W，用了 3 个 TiDB，3 个 TiDB 总的连接数加起来大概 14K，然后 Latency 的 pct99 小于 60ms。这其实都属于挺高峰时期的数据了。做活动的时候 QPS 会达到 20W。
在使用 TiDB 过程中，比较一下 TiDB 和 MySQL 的延时：
2.2.2 美团点评
在美团，基于 MySQL 构建的传统关系型数据库服务已经难于支撑公司业务的爆发式增长，促使去探索更合理的数据存储方案和实践新的运维方式。随着近一两年来分布式数据库大放异彩，美团 DBA 团队联合架构存储团队，于 2018 年初启动了分布式数据库项目。
美团业务线众多，根据业务特点及重要程度逐步推进上线，到截稿为止，已经上线 10 个集群，近 200 个物理节点，大部分是 OLTP 类型的应用，除了上线初期遇到了一些小问题，目前均已稳定运行。初期上线的集群，已经分别服务于配送、出行、闪付、酒旅等业务。
除了分析查询量大的离线业务场景，美团还有很多分库分表的场景，虽然业界有很多分库分表的方案，解决了单机性能、存储瓶颈，但是对于业务还是有些不友好的地方：
- 业务无法友好的执行分布式事务。
- 跨库的查询，需要在中间层上组合，是比较重的方案。
- 单库如果容量不足，需要再次拆分，无论怎样做，都很痛苦。
- 业务需要关注数据分布的规则，即使用了中间层，业务心里还是没底。
2.2.3 爱奇艺
随着公司业务的快速发展，原来普遍使用的 MySQL 集群遇到了很多瓶颈，比如单机 MySQL 实例支撑的数据量有限，只能通过不停删除较旧的数据来维持数据库的运转。同时单表的数据行数不断增大导致查询速度变慢。急需一种可扩展、高可用同时又兼容 MySQL 访问方式的数据库来支撑业务的高速发展。
从 2017 年年中开始调研 TiDB，并且在数据库云部门内部系统中使用了 TiDB 集群。从今年 TiDB 推出 2.0 之后，TiDB 愈发成熟，稳定性与查询效率都有很大提升。
在实践过程中感受到 TiDB 解决的痛点主要是横向扩展和高可用。单机数据库支撑的数据量有限，如果采用分库分表 + proxy 的方式，无论 proxy 是在客户端还是服务端都增加了运维的成本。同时 proxy 的查询效率在很多场景下不能满足要求。另外，proxy 对事务的支持都比较弱，不能满足数据强一致性的要求。TiDB 可以直接替代 proxy+MySQL 的架构，服务高可用性、数据高可用性、横向扩展性都由 TiDB 集群完成，完美解决了数据量增量情况下出现的很多问题。而且，TiDB 在数据量越大的情况下性能表现得比 MySQL 越惊艳。
2.2.4 360
TiDB 中吸引我们的特点有很多，其中能帮助我们解决现有问题的主要集中于两点。其一是能够在近似无限的水平扩展的同时保证事务特性。这样不仅避免了分库，分表的繁琐，也让海量数据能够以关系模型进行存储变为可能。其次是能够高度兼容 MySQL 协议，不仅为开发人员及数据人员都提供了良好的应用接口。基于这些特性，我们发现线上 OLTP 和 OLAP 的界限已经非常模糊，在某些业务场景已经可以完全的融为一体。
TiDB 部署了 9 台服务器的集群。其中 3 台作为 PD 和 TiDB 的服务器，6 台作为 TiKV 的存储服务器。在运行一段时间后，除了一些业务逻辑上的 bug，表现一直很稳定，从未出过一次问题。而且随着业务量的增大，TPS 指标 也提升至 5000 左右，整个数据库平台的峰值计算能力提升了 10 倍左右，但是平台整体的吞吐量和响应时间都没有特别的抖动，一直稳定在可接受范围内。
对于风险分析人员，最大的提升就是就是可以用他们熟悉的 SQL 工具直接连接生产的 TiDB 库进行分析工作。不仅实时性大大增加，工作效率得到了质的提升，也省却了部分 ETL 的工作。
--------------------------文档信息--------------------------
学习笔记由博主整理编辑，供非商用学习交流用
如本文涉及侵权，请随时留言博主，必妥善处置
版权声明：非商用*转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls