知乎 PB 级数据：超大规模 TiDB 集群管控实践

作者： 代晓磊 _Mars 原文来源：https://tidb.net/blog/9a2be83e

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

TIDB 规模总览

对于这种超大规模的 TiDB 集群，如何更好的让业务使用分布式数据库？以及 DBA 如何更好的管控 TiDB？接下来我将从 TiDB 生态架构入手展开说明管控 TiDB 都需要具备哪些工具和能力，然后结合 TiDB on K8S 或者 TiDB on 物理机这 2 种不同管控方式选择来展开知乎的具体实践，并且通过平台化能力，从业务研发和数据库管控 2 个方面来落地具体的管控措施，为知乎业务研发赋能。

一、运维管控架构图

首先业务要使用 TiDB 这个分布式数据库，就需要深入了解 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） Kubernetes 支持 TiDB on K8S 是通过 TiDB Operator 来部署和管理 TiDB 集群，支持 Kubernetes 上的自动化运维操作。

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

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

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

二、TiDB on Kubernetes OR 物理机？

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

• 灵活性与弹性：K8S 提供自动扩展、负载均衡和自愈能力，使数据库能更灵活地响应业务流量波动。相比之下，物理机部署固定资源，弹性扩展较难，需手动调整。

• 资源管理：K8S 提供资源隔离和调度优化，允许数据库与其他应用共享资源。物理机则专注于资源固定分配，难以实现动态调度。

• 运维复杂度：K8S 自动化运维工具（如 TiDB Operator）简化了数据库的部署、升级和故障恢复，而物理机通常需要手动维护和更复杂的操作。

• 性能：物理机通常能提供更高的性能，尤其是对高 I/O 需求的数据库，而 K8S 可能因虚拟化开销导致性能下降。

综合来看，K8S 适合动态、多租户场景，物理机则更适合对性能要求极高的关键任务。TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 Kubernetes 集群上。TiUP 是 TiDB 4.0 版本引入的集群运维工具，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。以下是我整理的 2 种部署管控工具的对比：

TiDB Operator VS TiUP

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

三、知乎的选择？

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

TiDB on K8S

四、知乎如何搞定数据库管控？

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

（1） 数据库日常运维

• 业务资源申请 / 删除需求

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

• 资源规划 & 部署

数据库基础服务独立 Kubernetes 集群，并且 Kubernetes 中预留 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） 数据库可观测能力

• 业务数据库监控

业务抖动大部分跟 DB 抖动相关，需要有监控系统如 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% 的服务器定期分析数据库资源利用率，避免不必要的资源过度配置，通过 Kubernetes 和 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 在 Kubernetes 环境中自动执行备份、升级、扩缩容等操作。

• 故障自动恢复：平台应具备自动化故障处理机制，当节点失效或集群不稳定时，能够自动触发恢复操作，并及时通知 DBA，减少人为干预。

• 统一管理与自动化运维

天穹平台 TiDB 集群列表

• 监控与预警系统：平台为 DBA 提供深度的数据库监控能力，能够跟踪 CPU 使用、内存消耗、磁盘 I/O、查询延迟、慢查询等指标。结合 Prometheus 和 Grafana，实时监控数据库健康状况，设置合理的告警阈值，提前发现潜在问题。

• 日志管理与分析：集中管理数据库日志，包括错误日志、慢查询日志、SQL 审计日志等。通过整合 ELK（Elasticsearch、Logstash、Kibana）等工具，支持 DBA 对日志进行深度分析，帮助排查问题。

• 数据库巡检：平台自动生成巡检报告，定期评估数据库集群的运行情况，生成包含性能、稳定性、安全性的报告，供 DBA 团队分析，并对潜在问题进行处理，保障数据库稳定性。

• 可观测性与预警

天穹平台统一监控中心

• SQL 审计功能：平台支持 SQL 审计功能，能够记录所有执行的 SQL 语句，帮助 DBA 追踪和分析 SQL 操作，防止潜在的安全风险和数据泄露。

• 访问控制与权限管理：DBA 团队需要通过平台集中管理数据库的用户权限，确保权限分配的最小化原则，防止数据被不当访问或篡改。

• 自动化备份：DBA 团队可以通过平台设置定时备份策略，自动备份数据库到 S3。

• 数据恢复工具：平台为 DBA 提供一键恢复功能，支持在灾难发生时快速恢复数据，保障数据安全。同时，应具备详细的恢复日志，帮助 DBA 分析和优化恢复流程。

• 数据库备份与恢复

• SQL 审计与安全管控

天穹平台 SQL 审计中心

• FinOps 成本管控

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

FinOPS 成本监控

总之，面向业务研发团队的数据库平台化重点在于提升自助服务能力，简化数据库操作，提高查询与开发效率，并为研发提供灵活的环境支持。面向 DBA 团队的数据库平台化则侧重于自动化运维、监控预警、数据备份与恢复、SQL 审计和成本管控，确保数据库的稳定运行和高效管理。通过分别满足研发和 DBA 团队的不同需求，数据库平台化可以为整个企业提供一个高效、稳定、可扩展的分布式数据库解决方案。

六、总结

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