全部标签
写点什么
OpenHarmony算法元宇宙MySQL移动开发学习方法学习方法Web3.0高效工作数据库Python音视频前端AI大数据团队管理程序员运维深度思考低代码redisgolang微服务架构flutter 查看更多

360 智慧商业 x TiDB 丨数据架构革新驱动广告业务高效运作

作者：TiDB 社区干货传送门
  • 2024-06-07
    北京

  • 本文字数：3727 字

    阅读完需：约 12 分钟

作者： GreenGuan 原文来源：https://tidb.net/blog/d0e63dcd


   广告行业正迅速转型，对数据处理和分析的需求日益增长。360 智慧商业作为行业的领航者，一直在探索如何利用先进的数据库技术优化其商业化业务线。TiDB，作为一款分布式 HTAP 数据库，为我们提供了强大的数据管理和实时分析能力，使其能够应对广告行业中的多样化业务场景。
复制代码

商业化业务线的总体概览


   我们商业化业务线主要有广告创意与策划、媒体请求、竞价排名、广告计费、广告主报表和持续优化等关键环节。在这些环节中，TiDB 在处理大规模数据和海量高并发请求场景承担重要的角色。
复制代码


1.1 广告创意与策划阶段


   在广告创意与策划阶段，我们商业化业务线需要存储和管理大量的广告物料，这个阶段的数据规模达到了百亿级别。最初，我们使用的是 MySQL 数据库，但随着业务的发展，MySQL 的分库分表方式逐渐暴露出性能不稳定和可扩展性复杂的问题。因此，我们决定迁移到高度兼容 MySQL 的分布式 HTAP 数据库 TiDB，以期获得更好的性能和水平扩展能力。
复制代码


1.2 媒体请求与竞价排名


   在媒体请求和竞价排名阶段，系统需要在 200 毫秒内完成特征匹配和竞价排名，这对数据库的响应速度提出了极高的要求。这部分我们采用的是分布式缓存数据库 Aerospike 满足这一需求，保证了广告投放的实时性和准确性。
复制代码


1.3 广告计费与报表


   对于广告计费和报表阶段，TiDB 不仅需要处理账单数据的高并发写入，还需要提供实时的分析报表服务。TiDB 的 HTAP（混合事务/分析处理）能力在这里发挥了重要作用，它能够同时支持 OLTP（在线事务处理）和 OLAP（在线分析处理）需求，为广告主提供了全面的数据处理和分析决策支持。
复制代码

TiDB 在多种不同需求下的架构演进及价值

   我们在早期数据库架构采用 MySQL 分库分表方案设计，解决业务发展在亿以上级别数据规模阶段 OLTP 事务处理能力，但随着业务增长下，分库分表方案中逐步暴露诸多问题亟须解决。
复制代码



   为了更好地适应我们商业化业务的需求，在设计实施 TiDB 架构也经历了一系列的优化和调整。例如，通过引入 DM （TiDB Data Migration）数据迁移同步组件将大规模的各个分片 MySQL 集群中的数据汇总到一套 TiDB 集群中，这样可以使我们能够更高效地处理大规模数据导入和实时计算场景，TiDB 方案显著提升了业务响应时间。
复制代码



2.1 存储引擎的选择


   在某些特殊场景下，TiDB 存储引擎的选择对性能有显著影响。我们通过监控表的健康状态，并在必要时使用表绑定策略（Placement Rules in SQL），确保了 TiDB 能够选择最合适的存储引擎，从而优化性能。
复制代码


2.2 硬件升级与资源隔离


   随着业务量的持续增长，我们智慧商业采取了一系列创新措施来实现成本效益和系统性能的双重提升。我们通过引入高配置的主机，替换了原有的多台低配置主机，这一策略不仅大幅度降低了运营成本，还显著增强了整个系统的性能。高配主机的引入，使得我们能够更高效地处理大量数据，同时保持系统的流畅运行。
复制代码



   进一步地，为了确保不同业务场景之间的稳定性和互不干扰，我们在接入层实施了资源隔离策略。在计算层根据不同业务维度实现物理隔离，另外在存储层采用 TiDB 产品的资源管理功能实现逻辑隔离。这种设计确保了即使面对 AP（分析处理）类业务的故障，也不会对 TP（事务处理）类业务的查询造成任何影响，从而极大提升了整个架构的稳定性和可靠性。
复制代码



   此外，我们还专注于提升用户密度和主机密度，通过优化资源分配和提升硬件使用效率，我们成功实现了硬件成本降低 40% 左右，整体运营成本的大幅度降低。这不仅体现了我们对成本控制的严格管理，也展现了我们对系统性能优化的不懈追求。
   通过这些综合性的策略和措施，我们智慧商业在保持业务快速发展的同时，有效降低了运营成本，提高了系统性能和稳定性，为广告行业的数据管理和分析树立了新的标杆。
复制代码


2.3 实时计算与 TiFlash 运维问题


   在实时计算场景下，我们智慧商业的业务线需要分析大量的数据，并要求快速响应以支持实时决策和广告投放。TiFlash 作为 TiKV 的列存扩展，也应用我们 TiDB 数据库架构。TiFlash 在提供了良好的隔离性的同时，也兼顾了强一致性，很好地解决了 HTAP 实时计算场景要求。
复制代码



然而，在使用初期版本的 TiFlash 时，我们遇到了一些性能瓶颈，主要表现在两个方面：


  1. TiFlash 版本低：早期 v5.4 版本的 TiFlash 可能在性能和功能上存在限制，尤其是在处理大规模数据集和复杂查询时。这可能导致查询响应时间延长，无法满足实时计算场景对速度的严苛要求。

  2. 优化器选择不当：数据库优化器负责决定执行查询的最佳计划，如果优化器选择的执行计划不是最优的，将会导致查询效率低下，影响整体性能。


为了解决这些问题，我们智慧商业采取了以下策略：


  • SQL binding：在 TiDB 执行计划管理（SPM (SQL Plan Management)）功能中其中之一数据库优化技术，通过预先定义查询的执行计划，强制数据库按照这个计划执行特定的 SQL 语句。这样，即使优化器可能会选择一个效率较低的执行计划，SQL binding 也能够确保查询按照预期的高效方式执行。这有助于提升查询性能，尤其是在面对复杂查询和大量数据时。

  • 升级 TiFlash：为了充分利用 TiFlash 的最新性能改进和新功能，我们对 TiFlash 进行了版本升级。采用新版本的 TiFlash 通常会包含性能优化、查询优化、以及对新硬件和新特性的支持。升级至 v7.5 版本后，系统能够更高效地处理数据，提供更快的查询响应时间，从而满足实时计算场景的需求。



   通过实施 SQL binding 和升级 TiFlash 的策略，我们智慧商业不仅解决了实时计算场景下的性能问题，还提升了整个系统的稳定性和可靠性。这些改进使我们能够更好地服务于广告业务，确保广告投放的实时性和精准性，同时也为未来的业务扩展和技术创新打下了坚实的基础。
复制代码


2.4 容灾方案


   在构建商业化业务线的容灾策略时，360 智慧商业深知数据的高可用性和灾难恢复能力的重要性。为此，我们采用了 TiCDC（TiDB 增量数据同步工具）的方式建立了多个 raft group，这是贴合 360 的业务场景进行评估后的取舍方案。
复制代码



   TiCDC 的模式和传统的主从复制模式类似，既源端通过感知 region 的变化，把变化的数据转换为 SQL 语句传输到目标端，因为采用了 TiCDC 的模式，所以目标端为单独的一套 raft group ，这点非常重要，选择 TiCDC 的方案有如下两点原因。
复制代码


1. 我们考虑到如果真的发生了 zoneA 机房的故障，那不仅仅是数据库服务出了问题，而是整个 zone 上的服务无法对外提供服务，那么不可避免的是要修改 DNS 下的 vip 指向，对于这种场景，我们力求减少不可控因素，region 的切换以及 pd 角色的变更都有不确定性，所以我们采用了 TiCDC 的模式。


2. 360 的网络环境非常复杂，每周都会有网络割接，有些时候我们不太担心 zoneA 彻底挂，而是比较担心 zoneA 挂的不彻底，在搭建了容灾集群后，我们不希望网络层的抖动造成业务侧的抖动，这样有些得不偿失。


不过这种方案也有两个值得分享的地方：


  1. TiCDC 构建从库可能会很漫长，由于我们的 TiDB 集群的规模很大用 BR 恢复至少需要十多个小时乃至二十多个小时，日常的增量数据非常大，在构建从库时需要根据表的大小单独拆分成过个通道，有时还需要 BR 和 Lighting 并用的方式同步数据。

  2. 成本问题，虽然我们的 PD 组件和 TiKV 组件所用资源可控，但是我们是否要部署相同规模的计算节点在 zoneB 需要权衡，360 智慧商业团队在尝试结合中台部门的能力，在故障发生时用采用虚拟迅速部署一批虚拟机，同时通过 tiup 的方式进行快速部署。


TiDB 在商业化业务线的使用规模


   目前，我们智慧商业已将三套核心业务和 16 套非核心业务接入到了 TiDB 集群中，物理机数量超过 200 台。核心集群在业务高峰时的 TPS 达到 10 万+，QPS 达到 13 万+，数据总量超过 100 TB。
复制代码

TiDB 为业务线带来的收益


TiDB 的引入为我们商业化业务线带来了显著的收益：


  1. 提高交付能力：TiDB 能够同时满足 TP 和 AP 的需求，使得业务查询模型更加灵活。

  2. 水平扩展能力：根据业务规模及特点，可以水平扩缩容存储或者计算节点。

  3. 降低运维成本：通过提升主机密度，降低了硬件成本约 40%，同时让开发的精力更集中在业务上。

  4. 完整的生态链：TiDB 提供了从 MySQL 迁移到 TiDB 的完整工具链，如逻辑数据导入导出工具 Dumpling/Lighting、 备份恢复工具 BR、数据迁移同步工具 DM、增量数据同步工具 TiCDC 等。

  5. 可观测性强：通过 Prometheus + Grafana 的监控方案和 Dashboard（TiDB 图形化界面），可以实时监控集群状态，及时发现并解决问题，提升故障处理效率。


对 TiDB 新版本的展望和期待


我们对 TiDB 新版本充满期待，特别是以下几个方面：


  1. 分区表和全局索引：新版本支持的分区表全局索引将进一步提升查询性能，特别是在处理大规模数据时。

  2. TiProxy 功能添加：期待 TiProxy 能够提供更多的功能，如 SQL 语句的回放和限流，以提高系统的稳定性和可扩展性。

  3. 向量支持：期待 TiDB 能够提供向量化查询的支持，这将大幅提升查询性能，尤其是在处理复杂计算和分析时。

  4. 通过 TiDB 的实践与探索，我们智慧商业在广告行业中成功应对了多种业务场景的挑战。TiDB 的高性能、可扩展性和易用性为我们提供了强大的数据库支持，帮助其在激烈的市场竞争中保持领先地位。随着 TiDB 技术的不断进步，我们有理由相信，我们智慧商业将能够继续引领广告行业的创新和发展。


#


划线
评论
复制
发布于: 刚刚阅读数: 4

版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。

原文链接:【http://xie.infoq.cn/article/088b0168dfa13040b38165694】。文章转载请联系作者。

实践案例社区活动数据库架构设计
用户头像

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
Copyright © 2024, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5京公网安备京公网安备 11010502039052号 | 产品资质
360 智慧商业 x TiDB丨数据架构革新驱动广告业务高效运作_实践案例_TiDB 社区干货传送门_InfoQ写作社区