TiDB 在小米的落地及云原生探索丨PingCAP DevCon 2021 回顾
Posted PingCAP
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了TiDB 在小米的落地及云原生探索丨PingCAP DevCon 2021 回顾相关的知识，希望对你有一定的参考价值。
本文根据 PingCAP DevCon 2021 上来自小米的数据库研发工程师刘子东的分享整理而成，介绍了 TiDB 在小米的落地以及小米在云原生领域的探索。
小米从创立到今天已经过去了 10 年，2020 年 8 月 16 日雷总在线上直播，宣布小米正式开启新十年的创业者计划。第二个月，云平台部门的数据库与存储团队启动了 TiDB 项目，作为团队在小米新十年中的第一个三年规划。2021 年 1 月，TiDB 产品正式在小米的内部私有云上线，落地各项业务。
先介绍一下小米与 TiDB 的现状。经过近一年的发展，TiDB 在小米已经部署了 20 多个集群，TiKV 节点也达到了三位数，覆盖的业务场景包括电商、供应链、大数据等等。右边这个米字 logo 的词云是由我们的一部分业务线组成的，包括了零售中台、小米有品、智能制造、代工厂、还有门店等。
小米经过十年的发展，在传统数据库上的使用中，确实遇到了相当多的痛点。因为时间有限，这只列举其中四个。
第一，容量瓶颈。我们内部的单机只有 2.6 T，经过十年的发展，很多业务线单机的存储都已经达到了 2 T 以上，甚至只有几百 G 的空间剩余，马上就要满了。为了解决容量问题，之前一般采用传统的分库分表解决方案，如果你对业务逻辑没有很深的了解，是成本非常高的事情，然而业务线的建设时间往往已经过去很久，以至于代码都不知道从何下手去重构。通过引入 TiDB 就能够比较轻松地解决这个问题。
第二，高可用。mysql 的主从架构下，我们尝试使用很多方法来做高可用实现，比如通过 LB + Orchestrator + 中间件的方案来解决。但是，如果半夜主库挂了，可能仍然睡不好觉。
第三，高写入。TiDB 作为一个分布式数据库，很好地解决了多点写入的问题。传统的 MySQL 主从架构，只能写到主库上，很容易达到瓶颈，达到瓶颈之后就会带来非常强的主从延迟。主从延迟就会带来一致性问题，一致性问题对很多业务来说是一个灾难。
最后，我们还有一些历史包袱。小米十年发展以来，我们内部有各种各样的解决方案去适应业务规模的增长,但都各有优劣。小米曾开源过一个叫 Gaea 的中间件，也是支持分库分表的，我们内部还有其他的中间件，方案非常多，而且都分散在各个业务线。一旦相关人员有一些变动，就会变得非常难以维护。但是 TiDB 实现了这些方案的打包，我不再需要考虑是用这个中间件还是那个中间件，他们分别适应什么样的场景。
我们发展的非常快，从我们刚刚了解 TiDB，到去年 9 月份接入了第一个业务，然后我们开始正式立项，建立团队。在今年 1 月份，我们就完成了包括部署、监控、告警、工单等基础能力的建设，开始类似于一个 DBaaS 平台，去对业务提供服务。
到今年 4 月，我们开始做质量提升工程，完成了小时级的备份恢复，还有巡检系统、两地三中心等方案的落地，大大提升了业务质量。到今年 7 月份，业务规模开始快速增长，TiKV 节点很快就过百了。我们现在看到的节点数过百，完成业务规模翻倍，其实仅仅就两三个月的时间。因为很多业务确实看到了 TiDB 很大的一个可扩展性，在遇到存储瓶颈时，他们也很愿意去做这个迁移接入。后面，我们也会持续的去做 TiDB、TiKV 的稳定性、性能还有成本等方面的工作，并且会重仓云原生的方向。
我们正式成立 TiDB 团队投入到 TiDB 产品的落地中还不到一年，和很多厂商相比算是后辈，我们也充分利用了后发优势，直接引入了大量生态产品如 BR、TiCDC、TiUP、DM 等等这些生态产品极大地减小了我们的运维成本，方便我们构建 TiDB 服务平台，促进了产品的快速发展。
第一是从分库分表到 TiDB 的迁移过程。历史问题造成的上游数据质量堪忧（如业务自行分库分表的设计，主键ID重复，甚至触发器、存储过程等），需要业务端做改造，从而导致迁移周期漫长。
第二是复杂的业务 SQL 导致查询计划不准。我们的老业务迁到 TiDB 之后，某一个 SQL 突然比以前执行时间大大增长。SPM 无法完全解决，一是 SQL 变化多、数量大。二是根据 cost，执行计划也会变化。而很多老业务的复杂 SQL 非常多，我们需要一一去调整查询计划，去帮业务做调优。
第三是部分内部工具对接，比如为了对接内部消息队列，我们建了一个 TiCDC 的内部分支版本、Drainer 的内部分支版本，当然后续比较根源的解决办法是内部工具去迎合外部开源工具，支持相应开源工具的接口。
最后，硬件、软件多方面的性能调教。比如一些反直觉的情况：我们之前使用的一款NVMe 硬盘表面上磁盘性能比 SSD 要高，但实测 sysbench 的 workload 和业务的 workload 都有不小性能差距，有的情况下甚至 NVMe 的并发性能比 SSD 还要差一倍。硬件的适配和兼容也是后期我们调优的一个方向。
第一个是社区支持非常友好，文档非常完善，因此我们的接入非常快速。我之前也讲了，其实仅仅一个季度的时间，我们就把整个以前看来各种高大上的平台做好，可以对业务提供服务了。
第二个是完善的数据库周边生态，降低了运维的成本。我们知道一个数据库产品的落地需要有自动化部署、监控告警、运维管理平台等一系列基建，得益于 TiDB 社区良好的可观测性和丰富的生态组件如 TiUP / BR / Dashboard 等等，我们很轻松的完成了相关建设，极大降低了运维成本，减轻了运维压力。
第三个，跨机房，多机房容灾，异地多活这个话题也是一个很深的话题。我们真正实践起来发现 TiDB 在跨机房上表现得非常优秀，很容易落地三中心的计划。对于一些需要异地容灾的业务来说，TiDB是一个很好的选择。
第四个，加密存储及传输的功能。透明数据加密 (Transparent Data Encryption)，简称 TDE，是 TiDB 推出的一个新特性，应用在风控隐私集群上，极大简化了业务逻辑。
最后是说下 HTAP 的内容。我们内部也有一些 HTAP 的实践，右边这个指标是我们的一个核心业务做的 HTAP 的实践，我们之前通过 TiSpark 打在 TiKV 上的任务时间是在左边，我们换了 TiFlash 之后，我们可以看到，无论是从任务执行时间，还是 P99 延时、负载上，我们都提高了不只三倍。如果我们自己去优化这三倍的性能，需要投入的精力有多少，大家做过性能优化的应该都知道。TiFlash 的引入大大简化了我们的工作。
前面我们提到，TiDB 丰富的生态，极大降低了我们的运维成本。取之社区，回馈社区。包括 TiDB 产品在内，很多生态产品我们都有提 patch。现在，小米团队是多个产品的 contributor，包括 dumpling、br、ticdc、tiup 等，TiDB 产品目前是 active contributor。
画虚线的产品 TiKV、TiDB Operator，虽然目前还不是 contributor，但是我们和 PingCAP 已经达成合作，后续将持续贡献 TiDB、TiKV、TiDB Operator 产品，同时也是符合我们持续性优化稳定性、性能及成本目标。
我们不仅仅是 DBA，还是研发工程师，都有代码层面了解产品的执拗，当然对生态产品的代码了解也有助于我们落地到业务中，同时反哺社区，帮助完善生态，也是开源社区所倡导的良性循环。
玩过云的，大家可能都知道，云发展历程中经历过很多基础设施的不同潮流，包括选择私有云还是公有云，以及底层的一些框架如何使用。
因为小米的国际化业务现在越来越发达，我们对海外的公有云的需求也会越来越大。所以我们制订了一个全球混合多云的战略。我们同时使用 IDC 机房和多种公有云，并且对外封装，把他变成一个屏蔽细节的、全球化的混合多云。
首先是
安全性
。在国际化业务中，我们可以根据需求把数据存储在不同的位置。这个是可以通过我们的存储来做，业务无需关心。第二个
灵活性
。我们可以对业务屏蔽掉底层这个复杂的多云环境，从而提供一个通用的环境。这样我们在切换供应商，或者是做一些底层操作的时候，业务就不会有感知。第三个
成本
。云原生的好处之一，就是优化调度，资源共享。第四个
质量
。
云的另一个好处就是高弹， 我们可以快速完成扩缩容。而我们如何在混合云下做高弹，又是一个非常大的挑战。
用户层我们不展开讲。服务是我们给用户提供的服务，包括运维管控、用户平台、数据流以及一些调优服务。然后是管理：由于 TiDB Operator 部署在单个 K8s 集群中，控制范围仅能在单个 K8s 集群，而我们的需求可能包含跨机房，跨云，甚至 IDC 和 K8s 混合（比如 TiCDC 部署在云中，而 TiDB 集群在 IDC 物理机上），所以我们需要在 TiDB Operator 上另外增加一些自定义调度。所以我们可以看到除了 TiDB Operator、传统的 CMDB，我们增加了一个自定义的 Operator。
底层的资源刚刚已经介绍了大部分，需要提的一项是底层的存储资源。从本地磁盘到云盘到 Ceph，再到其他分布式存储。开发者嘉年华的吐槽大会环节，美团的黄潇老师对 TiDB 对演进方向有一个灵魂拷问：我们未来 TiKV 到底是继续提高调度呢，还是说去往 PolarDB 这边靠，做一些共享存储的方案？东旭的回答是：我们为什么不都做呢？
其实我们也在研究这个问题。在支持本地磁盘和云盘的过程中，我们也在调研云原生的分布存储。StarFS 是我们数据库与存储团队目前正在自研的分布式云原生文件系统，与普通分布式存储如 HDFS、Ceph 等有区别，主打高性能、低延迟。分布式存储有一个天然弱势就是 latency 不稳定，所以很难作为线上数据库的存储后端，目前没有能满足数据库需求的开源分布式存储。StarFS计划采用基于高性能存储介质 SSD、NVMe，采用 SPDK、RDMA 等技术实现适合数据库的分布式存储后端。
当然，这只是初步规划，并在有条不紊推进过程中，也期待引进越来越多的新技术，来迭代优化混合云的架构设计。
云原生探索踩过一些小坑，这里技术细节比较多了。可以简单介绍一下，假如 PD-pod 假死，Operator 的控制逻辑就会失效。表面上是在 Running 的状态，但其实这个 pod 已经无法提供服务了，这个坑也很难受。还有一些分布式存储的调度问题、故障切换问题造成服务不可用的问题等。另外 Controller 的串行化设计也需要注意。我们知道 Controller 是把你的集群控制在一个期望的状态，但是这个串行化的控制逻辑会让你在扩容 TiDB 的时候，假如 TiDB 扩容不成功，TiKV 也无法扩容成功，这样的话就导致阻塞，导致你整个运维操作的失败。
最后表达一下期望，我们已经和 TiDB 社区建立了深度的合作，我们会共同推进混合多云战略，推进核心业务的 MySQL 迁移，以及做一些 Committer 的培养。在内部也会继续推进 TiDB 落地到小米金融、小米 AI、小米 IoT 等多个业务场景。
