知乎 PB 级别 TiDB 数据库集群管控实践

以下文章来源于知乎技术专栏，作者代晓磊

导读

在现代企业中，数据库的运维管理至关重要，特别是面对分布式数据库的复杂性和大规模集群的挑战。作为一款兼容 MySQL 协议的分布式关系型数据库，TiDB 在高可用、高扩展性和强一致性方面表现卓越。知乎自 2019 年开始应用 TiDB，并通过云原生 Kubernetes（以下简称 K8s）环境和 TiDB Operator 来实现高效的集群管控，支撑业务的快速发展。本文由知乎数据库架构团队负责人代晓磊撰写，深入探讨知乎如何利用 TiDB 的生态架构和平台化运维工具，结合 TiDB Operator 和自研的天穹平台，构建出灵活、稳定且高效的数据库管控体系。通过自动化部署、数据迁移、监控预警等一系列手段，知乎为业务研发和 DBA 团队提供了强有力的支持，确保数据库服务能够在高并发、大数据场景下持续稳定运行。

相关推荐：知乎 PB 级别 TiDB 数据库在线迁移实践

TiDB 是一款开源的分布式关系型数据库，兼容 MySQL 协议，支持水平扩展，具有强一致性和高可用性。它融合了传统关系型数据库与 NoSQL 的优势，支持大规模数据处理，适合处理高并发、复杂查询和大数据存储的场景，广泛应用于金融、互联网等行业。知乎从 2019 年就开始应用落地 TiDB，截止现在知乎的 TiDB 规模：

TiDB 规模总览

对于这种超大规模的 TiDB 集群，如何让业务更好地使用分布式数据库、DBA 更好地管控 TiDB？

接下来本文将从 TiDB 生态架构入手展开说明管控 TiDB 都需要具备哪些工具和能力，然后结合 TiDB on K8s 或者 TiDB on 物理机这 2 种不同管控方式选择来展开知乎的具体实践，并且通过平台化能力，从业务研发和数据库管控两个方面来落地具体的管控措施，为知乎业务研发赋能。

运维管控架构图

首先业务要使用 TiDB 分布式数据库，就需要深入了解 TiDB 的生态架构，它包含了各种工具和能力集合体，如下图所示：

TiDB 生态架构图

这张图展示了 TiDB 的整体系统架构和它在不同子系统之间的交互。以下是主要模块和功能的总结：

(1) TiDB Cluster（核心组件) : 业务程序通过 LVS 或 H5 进行负载均衡组建访问 TiDB Cluster 这个无状态的 SQL 处理层，解析 SQL 请求、生成执行计划、调用下层 TiKV 存储来执行查询。TiKV 作为分布式的存储引擎来存储数据，它是一个分布式的、可水平扩展的 Key-Value 存储。PD（Placement Driver）这个"大脑"管理集群的元数据，负责数据的调度、负载均衡等操作，保障了集群的稳定。

(2) 数据迁移与同步 : 要想使用 TiDB，需要将数据进行流转，包括使用 DM（Data Migration）将数据库表从 MySQL 等其他数据库中迁移数据到 TiDB，保证数据的可靠迁移和一致性。另外 TiCDC 可以将数据变更从 TiDB 集群导出，并且支持与 Kafka、MySQL 等系统对接，提供实时数据同步。

(3) 运维与监控平台 : DBDAS 平台是 TiDB 集群管控不可缺少的一环，TiDB dashboard 和 TiEM 等平台提供了含元信息、热力图、巡检报告、SQL 审计、自动化管理、扩展缩容等功能，简化运维操作。监控是通过 Prometheus、Grafana 对集群进行监控，提供指标数据采集与展示，K8s 里面通过 TiDB Monitor 组件实现监控功能。

(4) 备份与恢复 : 数据库稳定性必不可少的就是备份/恢复，TiDB 采用 BR（Backup & Restore）进行物理备份和恢复工具，确保在发生故障时能够快速恢复数据。另外 Lightning & Dumpling 用于快速导入和导出数据，适合数据逻辑备份/恢复场景。

(5) 生态集成 Spark 集成 : TiDB 与 Spark 集群集成，允许通过 Spark SQL 直连 TiKV 执行复杂的分布式计算任务。ELK（日志分析）通过 Filebeat 收集日志，经过 Kafka、Logstash 传递到 Elasticsearch，最终在 Kibana 上进行可视化展示。

(6) K8s 支持 : TiDB on K8s 是通过 TiDB Operator 来部署和管理 TiDB 集群，支持 K8s 上的自动化运维操作。

(7) 工具集 TiUP : TiDB 的集群管理工具，负责集群的安装、升级、扩展等操作。TiBigData、TiFlink、TiRedis 等工具帮助用户在大数据和分布式场景下更好地集成和使用 TiDB。

(8) 安全与审计 : SQL 变更和 SQL 审计功能，需要支撑业务日常的在线数据查询以及 SQL 变更操作，并且进行检测和审计，确保系统中所有操作都有迹可循，保障数据库稳定和数据安全。

总结来说，TiDB 的生态架构具备了从数据库迁移、存储、查询、备份恢复、实时同步、监控运维到大数据计算和日志分析的全方位功能。这种架构充分展示了使用好 TiDB 需要具备丰富的工具和能力。

那么如何更好地管控 TiDB？我们先从 TiDB on 云上 or 云下来看。

TiDB on Kubernetes OR 物理机

数据库运行在 K8s 和物理机上的区别主要体现在灵活性、资源管理、运维复杂度和性能等方面。

灵活性与弹性 : K8s 提供自动扩展、负载均衡和自愈能力，使数据库能更灵活地响应业务流量波动。相比之下，物理机部署固定资源，弹性扩展较难，需手动调整。
资源管理 : K8s 提供资源隔离和调度优化，允许数据库与其他应用共享资源。物理机则专注于资源固定分配，难以实现动态调度。
运维复杂度 : K8s 自动化运维工具（如 TiDB Operator）简化了数据库的部署、升级和故障恢复，而物理机通常需要手动维护和更复杂的操作。
性能 : 物理机通常能提供更高的性能，尤其是对高 I/O 需求的数据库，而 K8s 可能因虚拟化开销导致性能下降。

综合来看，K8s 适合动态、多租户场景，物理机则更适合对性能要求极高的关键任务。TiDB Operator 是 K8s 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 K8s 集群上。

TiUP 是 TiDB 4.0 版本引入的集群运维工具，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。以下是我整理的 2 种部署管控工具的对比：

TiDB Operator VS TiUP

总的来说， TiDB Operator 更适合 K8s/云原生场景，具有强大的自动化和扩展能力。而 TiUP 则适合对 K8s 不熟悉或没有云原生需求的团队，适用于相对简单的部署和运维场景。

知乎的选择

知乎是业内较早研究应用 K8s 的互联网公司，在容器化方面有较深的积累，基于 TiDB 集群管控的便利性，知乎选择了 TiDB Operator 这个云上的管控工具来较为便利的管控 TiDB 集群。

TiDB on K8s

知乎如何搞定数据库管控

为了为公司业务研发团队提供分布式数据库（如 TiDB）的选型，数据库架构团队需要从多个方面进行深入的准备和规划。以下是每个方面的详细说明：

1. 数据库日常运维

业务资源申请/删除需求

需求评估与资源分配：团队需要与研发团队紧密协作，评估业务系统对数据库资源的需求，包括存储、计算能力和网络带宽等。应设计标准化的资源申请流程，并确保资源分配合理且具有扩展性。自动化流程：使用工具 TiDB Operator 来支持资源的自动申请、分配和删除，确保资源生命周期的高效管理。

资源规划&部署

数据库基础服务独立 K8s 集群，预留 5% 以内的计算和存储资源。业务申请经过业务 owner+DBA 审批通过后，调用 TiDB Operator+TiDB-cluster.yaml 实现快速部署。

扩缩容

根据业务增长、降本需求，修改 TiDB-cluster.yaml 的 replica 数量并且应用实现集群的自动扩缩容。扩容一定要提前规划好资源池，以便快速响应业务的高峰期需求，避免因为资源不足影响服务可用性。定期监控数据库容量和性能指标，预警扩容需求。

2. 数据迁入/迁出

根据不同的业务类型和需求来定制化的执行 MySQL 迁移 TiDB 的方式，比如大部分都是通过 DM 工具（支持全量和增量同步，保证数据一致性）来迁移切换，对于一些凌晨从 Hive 写回的结果表（白天数据不变化），业务双写或者 Dumpling 导出 +Lightning 导入即可。当然知乎的业务有需要把 TiDB 的(T-1)数据当天凌晨导入到 Hive 的需求，这时 TiBigDATA 这个工具就派上用场了，知乎 70% 左右的在线表每天凌晨的全量 ETL 都是采用这个工具。还有一些业务需求是需要将 TiDB 的实时数据变更，我们使用 TiCDC，支持将 TiDB 中的数据流式同步到 Kafka 消息供业务消费。

3. 数据库稳定性建设

数据库备份/恢复

根据业务的核心程度不同，定制实例级别的备份策略，比如 S 级别业务每天凌晨都用 BR（Backup & Restore）工具定期备份到 S3，并且每天抽样 S3 备份文件验证数据恢复，保障数据库的稳定性。

多云多活

对于核心业务，建议数据库具备多数据中心的多活能力，知乎基于 TiDB 的 Placement-rule 策略实现了跨云跨 K8s 的副本投放，并且通过 label+role 来控制 region leader 分布，并且基于这一套架构实现了在线机房的迁移，提高数据库的稳定性。

数据库巡检

数据库巡检是数据库稳定性建设必不可少的模块，包括且不限于：库表巡检、SQL 巡检、资源巡检、数据库核心指标巡检等等，自动化巡检能力通过定期进行数据库健康检查，未雨绸膜，提前发现数据库稳定性风险。

4. 数据库可观测能力

业务数据库监控

业务抖动大部分跟数据库性能抖动相关，需要有监控系统如 TiDB 的 Prometheus 和 Grafana，实时查看数据库的性能指标，包括 CPU 使用率、内存消耗、磁盘 I/O、查询延迟等，来及时定位问题。业务延迟升高大部分跟慢查询相关，可以通过 TiDB 的 Slow Query 日志和 SQL 审计功能捕捉慢查询，分析业务查询的执行效率，优化数据库性能；另外 DBA 还利用 ELK（Elasticsearch + Logstash + Kibana）系统，结合日志采集工具 Filebeat，对数据库日志进行集中管理和分析。在业务抖动问题定位时，日志往往是定位问题的关键。

报警

报警如何做到故障时能及时报出警而且又不至于报警轰炸？这时需要定制化的报警策略，根据数据库的性能指标设定报警阈值（如磁盘使用率、节点响应时间等），一旦超出阈值通过电话或企业微信及时通知。并且制定报警的报表，每周周会进行分析查看，并且制定合适的报警策略或者降低非必要报警。

5. 数据库降本增效

FinOps 成本管控

知乎通过 FinOps 成本管控平台来实现业务和资源方的成本使用。

首先要考虑的是数据库的成本是否需要完全分摊给业务方、应该如何分摊。目前通过给每种资源定价(按套餐、按 xx 元 GB/天)，制定合理的定价策略来管控业务数据库资源使用，建立数据库资源的成本监控机制，追踪每个业务模块对数据库资源的使用情况，帮助团队实现数据库成本的透明化管理。

资源方需要严格管控服务器利用率，比如对于 cpu+mem+disk 平均都 <20% 的服务器定期分析数据库资源利用率，避免不必要的资源过度配置；通过 K8s 和 TiDB Operator 的弹性扩缩容功能，动态调整数据库资源，避免资源闲置和浪费。

数据库架构团队在为公司业务研发团队提供 TiDB 分布式数据库选型时，需要全方位考虑数据库的基本运维（包括资源管理、自动化部署和扩缩容）、数据迁移、稳定性（如备份与巡检）、可观测性（监控和日志分析）以及成本管控（通过 FinOps 实现降本增效），这些管控工具其实都需要一个平台来承接。

知乎数据库平台化建设

知乎通过自研的天穹平台来承接，面向业务研发团队和面向 DBA 团队的需求和侧重点有所不同。以下是天穹平台对这 2 个纬度的支撑情况：

1. 面向业务研发团队

业务研发团队主要关注数据库平台的易用性、灵活性和自助服务能力，确保能够快速响应业务需求，提升开发效率。以下是平台化的几个关键点：

自助服务能力

自助资源申请/下线： 研发人员可以通过天穹平台自助申请数据库实例、存储资源、读写分离等服务，而不需要依赖运维团队或 DBA 手动分配。这种自助服务应具有标准化和自动化流程，确保快速响应需求。
数据库扩容和缩容： 当业务流量波动或业务扩展时，研发团队应能够在平台发起扩缩容变更，平台自动完成资源分配，且能够在不影响服务的情况下进行扩展。
工单中心： 天穹平台为研发人员提供数据库变更工单中心模块，能够根据不同的业务变更需求自助审批和执行。

天穹平台业务申请 TiDB 集群

天穹平台 TiDB 集群详情

天穹平台工单中心

数据库操作简化

SQL 变更支持： 提供 SQL 审核工具，研发人员可以通过平台提交 SQL 变更，自动完成语法检查、SQL 审批和执行全流程，并结合业务的数据库规范自动进行审核，避免低效或有风险的 SQL 语句。
查询历史与可视化工具： 研发人员可以通过平台查看自己提交的 SQL 查询历史、执行计划等信息，帮助优化查询语句，同时应提供可视化工具（如数据表结构、索引等），简化数据库操作。
慢查询分析与优化： 平台应自动记录慢查询，并为研发团队提供优化建议或提示，帮助他们提高 SQL 语句的执行效率，提升业务系统性能。

天穹平台慢 SQL 处置中心

监控与日志查询

自助监控面板： 为研发团队提供可视化的监控面板，能够实时查看与他们业务相关的数据库性能指标，如查询延迟、CPU 和内存使用情况等。
日志查询： 支持研发人员查询数据库操作日志，分析执行过的 SQL 查询、报错信息等，帮助诊断问题，提高调试和排查的效率。

天穹平台监控中心

天穹平台日志中心

2. 面向 DBA 团队

DBA 团队主要关注数据库平台的稳定性、可观测性和自动化运维能力。平台化应提供便捷的工具来简化日常运维工作，提升数据库的管理和运维效率。以下是面向 DBA 团队的几个关键点：

统一管理与自动化运维

统一集群管理： 平台能够集中管理多个数据库集群，包括 TiDB、MySQL、Redis 等，提供统一的操作界面，便于 DBA 快速查看集群状态、健康状况和节点信息。
自动化任务调度： 对于日常的运维任务（如备份、巡检、扩缩容等），平台支持自动化调度，降低 DBA 的重复性工作负担。例如，使用 TiDB Operator 在 K8s 环境中自动执行备份、升级、扩缩容等操作。
故障自动恢复： 平台应具备自动化故障处理机制，当节点失效或集群不稳定时，能够自动触发恢复操作，并及时通知 DBA，减少人为干预。

天穹平台 TiDB 集群列表

可观测性与预警

监控与预警系统： 平台为 DBA 提供深度的数据库监控能力，能够跟踪 CPU 使用、内存消耗、磁盘 I/O、查询延迟、慢查询等指标。结合 Prometheus 和 Grafana，实时监控数据库健康状况，设置合理的告警阈值，提前发现潜在问题。
日志管理与分析： 集中管理数据库日志，包括错误日志、慢查询日志、SQL 审计日志等。通过整合 ELK（Elasticsearch、Logstash、Kibana）等工具，支持 DBA 对日志进行深度分析，帮助排查问题。
数据库巡检： 平台自动生成巡检报告，定期评估数据库集群的运行情况，生成包含性能、稳定性、安全性的报告，供 DBA 团队分析，并对潜在问题进行处理，保障数据库稳定性。

天穹平台统一监控中心

SQL 审计与安全管控

SQL 审计功能： 平台支持 SQL 审计功能，能够记录所有执行的 SQL 语句，帮助 DBA 追踪和分析 SQL 操作，防止潜在的安全风险和数据泄露。
访问控制与权限管理： DBA 团队需要通过平台集中管理数据库的用户权限，确保权限分配的最小化原则，防止数据被不当访问或篡改。

数据库备份与恢复

自动化备份： DBA 团队可以通过平台设置定时备份策略，自动备份数据库到 S3。
数据恢复工具： 平台为 DBA 提供一键恢复功能，支持在灾难发生时快速恢复数据，保障数据安全。同时，应具备详细的恢复日志，帮助 DBA 分析和优化恢复流程。

天穹平台 SQL 审计中心

FinOps 成本管控

资源优化与成本监控：平台帮助 DBA 监控各数据库实例的资源使用情况，评估资源利用率，避免过度配置，提升成本效益。

FinOPS 成本监控

总之，面向业务研发团队的数据库平台化重点在于提升自助服务能力，简化数据库操作，提高查询与开发效率，并为研发提供灵活的环境支持。

面向 DBA 团队的数据库平台化则侧重于自动化运维、监控预警、数据备份与恢复、SQL 审计和成本管控，确保数据库的稳定运行和高效管理。通过分别满足研发和 DBA 团队的不同需求，数据库平台化可以为整个企业提供一个高效、稳定、可扩展的分布式数据库解决方案。

总结

知乎的数据库团队以"致力于提供稳定、高效和易用的数据库服务"为目标，为公司业务团队提供更好的 TiDB 存储服务来应对高并发、复杂查询和大数据存储的需求。本文详细介绍了 TiDB 的生态架构，包括核心组件、数据迁移与同步、运维与监控平台、备份与恢复、生态集成、K8s 支持、工具集和安全与审计等方面。同时探讨了知乎如何在云上和云下环境中管控 TiDB 集群，以及如何通过自研的天穹平台实现数据库平台化建设，提升业务研发团队数据库变更和 DBA 团队的资源管控效率。