日前，我司 CTO 黄东旭接受了即将开幕的 WOT2018 全球软件与运维技术峰会记者的采访，介绍了 TiDB 作为 HTAP 数据库的技术思考及应用情况，以及 PingCAP 自创立以来对开源的一些心得，以下是报道原文。Enjoy～
作者：查士加
创立 PingCAP 的理由异常简单
黄东旭提到，自己与朋友一同创业，理由很简单，源自一个需求。彼时，黄东旭与刘奇（现任 PingCAP CEO）同属豌豆荚的分布式存储团队，当时的他们开源了 Codis，解决了豌豆荚内部缓存的扩展性问题，数据库问题成了硬骨头。如何构建一个对业务端透明，兼具良好的扩展性和完整的分布式事务支持的数据库，是构建新一代微服务架构的核心问题之一。当时，团队在开源社区并没有找到比较好的方案，分库、分表、中间件，这些传统做法在涉及到业务大的改动时会带来很大的运维成本，如何彻底解决这个问题呢?
受当时 Google 发表的一系列在分布式数据库方面的论文（Spanner/F1）启发，PingCAP 的初创团队打算从头开始实现一个新一代的关系型数据库，来解决关系型数据库的扩展性问题。由此看来，PingCAP 创立的初衷很简单，就是几个工程师想要解决一个很困难的技术问题，同时想通过开源的方式帮到大家。
TiDB 研发早期经历的那些事儿
在 TiDB 研发早期，从 SQL 层开始，第一个开源的 TiDB 版本其实并没有存储引擎，后端存储是 HBase，为了加入存储层，也为了验证 SQL 的正确性，PingCAP 团队决定为 HBase 加入分布式事务的支持，直接对接在 TiDB SQL 层的后端，这种方法确实可行。但是考虑到性能和其他一些因素，PingCAP 很快决定用 Rust 重新实现一个全新的分布式存储层，也就是后来的 TiKV。彼时 Rust 还是一门比较新的语言，且以学习曲线陡峭著称，整个团队成员都没有相关经验，好在得到了 Rust 语言官方的诸多支持，PingCAP 和 Rust 语言共同成长了起来，如今，TiKV 已经是 Rust 社区的明星项目，同时 PingCAP 也是多个知名项目（如 gRPC 等）的 Rust 语言开源实现的主要维护者。黄东旭表示看到 Rust 语言越来越火，感到非常的高兴和欣慰。
PingCAP 是国内首家开源的新型分布式数据库公司，其独立研发的分布式数据库产品 TiDB 是一款定位于 HTAP（Hybrid Transactional/Analytical Processing）混合事务/分析处理数据库的融合、创新型数据库产品。为了实现这一目标，TiDB 在架构上将计算和存储层进行高度的抽象和分离，对混合负载的场景通过 IO 优先级队列，智能副本调度，行列混合存储等技术使其变为可能。另外，在 TiSpark 项目中，将 TiDB 的存储层和 Spark 的计算引擎高效地连接在一起，让用户也能够在 Spark 生态系统下实时的对数据库中的数据进行复杂分析。
黄东旭认为，HTAP 给开发者提供了一个实时数据分析方面的新思路，不需要再去维护另一个离线的数据仓库，既减轻了 ETL 的工作，又能节省很大一部分的建立数据仓库所用到的存储和计算成本，HTAP 将是未来的重要趋势。
HTAP 数据库的三类应用场景
一是大中台的场景。例如，前台的数据库已经分库分表或已水平拆分，TiDB 可以作为所有线上生产库的从库，实时将数据同步到一个大的 TiDB 集群上，在这一层将数据打通，可以直接进行复杂的跨库、跨表、跨业务的实时 SQL 查询，由于这是基于 MySQL 的协议和语法，对业务的侵入性很小，开发者无需再去学习新的查询语法。
二是为微服务提供强一致的持久化数据层（the source of truth）。其实微服务乃至后来的 Serverless 架构，一个核心的问题就是持久化数据层，要将无状态的业务逻辑容器化、服务化很方便，但是带状态的存储层在满足 SQL 和强一致甚至 ACID 的情况下实现弹性伸缩，在现有的方案下仍十分困难，而 TiDB 可以完美的在这类架构中填补这一空白。
三是 MySQL 分库分表的完美替代品。TiDB 与 MySQL 的语法、MySQL 社区的工具（如 Mydumper/PhpMyAdmin 等）完美兼容，可让 MySQL 应用无需修改便可直接运行。这让很多用了 MySQL 的业务在遇到大数据量的场景时，能够无缝的切换。
TiDB 解决 MySQL 可扩展性的实现原理
TiDB 产品的整体架构是分层的，由分布式 SQL 层（TiDB）、分布式 KV 存储引擎（TiKV）以及管理整个集群的 PD 模块组成。无限水平扩展是 TiDB 的一大特点，这里所说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以通过简单的添加 TiDB Server 节点，在提升整体处理能力的同时，提供更高的吞吐能力。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点，解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位进行调度，将部分数据迁移到新加的节点上。由此可见，企业在业务的早期可以只部署少量的服务实例，随着业务量的增长，能够便捷地按照需求添加 TiKV 或 TiDB 实例。
据介绍，目前，包括摩拜单车、同程旅游、饿了么、360 金融、游族网络、今日头条、盖娅互娱、猿辅导、易果集团、去哪儿网等 200 余家不同行业的领先企业已经将 TiDB 应用在实际的生产环境中，涉及互联网、游戏、金融、政府、电信、制造业等多个领域。
其中，今日头条和易果集团都是比较典型的案例。
今日头条：用 TiDB 替换原有的主从 MySQL 数据库
以今日头条为例，今日头条 APP 的自研 S3 存储系统，数据量级已近上百亿。在用 TiDB 前，今日头条的元数据存在 MySQL 2.8TB 的磁盘里，因为数据量增长迅速，导致磁盘不够用，只能用分库分表的方案，当时的方案是 MyCAT。但是分库分表带来一些问题，如：无法做 OLAP 分析;有丢数据的问题，数据虽然已经 commit，实际并没有保存下来;还有连接的问题，有些业务没有带分片键的查询，会消耗非常多的连接，造成没有连接的情况。
如今，今日头条使用 TiDB 替换了原有的主从 MySQL 数据库，上线后效果非常明显：
-
TiDB 支撑着今日头条 OLTP 系统里数据流量较大、QPS 较高的场景。例如今日头条、抖音;
-
QPS 一直在上升，目前均值十几万;
-
已经稳定运行近半年，做过一次扩容。
典型 OLTP+OLAP 混合场景案例
易果集团是一个典型的 OLTP+OLAP 混合场景的案例。在上线 TiDB 之前，易果集团的实时系统已经遇到了瓶颈：
-
SQL Server 当数据量到达一定阶段，性能出现拐点，弹性扩展很难实现;
-
HDFS+Hive+Spark+Presto+Kylin 方案在数据量增大的情况下，ETL 越来越慢，很难满足更复杂的 OLAP 需求，与此同时，业务对实时或者准实时的需求越来越强烈。
通过对 Greenplum、Kudu、TiDB 等多个方案的选型评估，最终易果集团选择了 TiDB 的方案：使用 Flume、Syncer 数据实时同步到 TiDB，并使用 TiSpark 替换 Hadoop 进行实时数仓业务。目前，在 TiDB 的支持下，易果集团 T+1 数仓已升级为实时数仓，TiDB 天然的满足了数据量线性扩展的问题，同时还节省了大量的运维成本。TiDB 作为一款 HTAP 数据库，为易果集团创建实时、统一的混合数据库提供了可能。
基础软件选择开源社区战略更加适宜
最后，黄东旭表示，开源是一种非常先进的软件开发模式和推广模式，对于基础软件来说，开源是一种很重要的手段。他引用了开源社区里流传甚广的一句话：只要眼睛足够多，Bug 无处藏。从这个逻辑的角度来看，对于基础软件来说，用户越多，使用场景越多，见过的 Workload 越多，得到相应的反馈越多，这些来自一线的反馈能够更好的让你看清方向和产品存在的缺陷，更快的迭代以达到更加完美的状态，避免闭门造车；另外一方面，社区和生态会成为你最大的护城河，从而构建真正的商业壁垒。黄东旭总结，PingCAP 这几年发展的如此之快，与他选择了开源的战略密不可分。