TiDB 在实时分析应用场景下的探索

作者：周跃跃，苏丹

近年来，随着数据规模越来越大，以及由此衍生出数据实时化的诉求激增，产生了一系列大数据相关的业务场景，场景复杂性高以及业务多维度是明显的两个特点，因此出现许多了实时数仓架构来满足业务需求。

本文不涉及对大数据场景的介绍，适合正在或者考虑进行大数据架构探索的对象，将根据不同的角色需求、成本以及技术选型方面做介绍，并提供一种可供选择的 HTAP 技术产品——TiDB ，在进行 TP 业务的同时，满足大数据场景下实时、快速响应的需求。

为什么需要

不同的角色有不同的关注点，因此可以引申抽象出不同的业务场景：

• 对于业务决策者，需要关注公司当前的发展情况以及决定未来几年发展方向。比如需要通过查询五年之内的实时报表、损益报表等来分析当下公司的发展情况，同时根据已有的数据建模来预测分析未来几年营收情况来决定公司未来发展方向。在这个分析过程中，查询的时间粒度可以是时、日、周、月、年任意一个。
• 对于公司内某一个业务线负责人来说，需要关注的是当前该业务的基本情况，如营收、健康度、热点等问题，因此需要通过查询三年之内任意时刻的业务实时大屏、业务实时报表、营收预测以及商业化等数据信息。
• 对于安全团队的负责人，需要时刻关注信息安全问题，一般情况下需要查询最近一个星期到一个月内任意时刻的风控平台的数据信息。

综合以上三种常见的角色对应的需求，会发现在分析和判断的时候，需要借助实时查询，同时由于时间范围大部分跨度比较大，因此数据规模也需要考虑。数据规模大的同时，满足实时查询是一个具有挑战性的工作。

大数据方案怎么选

不同角色需要快速获取不同的维度信息，在数据实时性方面又有一定的要求，用户（无论内部还是外部）已经无法满足针对离线数据进行分析，他们需要更新鲜的数据，甚至可能对正在发生的交易数据直接进行分析，因此需要一套专业的架构来支持。同时只能由专业的团队来完成，一般情况下需要组建专业的数据团队来支撑各个负责人的需求，并需考虑成本的问题，包括人力成本、时间成本以及引入各种技术栈的成本。也就是说，在已有的 TP 业务场景下，需要考虑或者构建偏 AP 的数仓架构来满足实时查询的需求。

已有解决方案

传统以 Hadoop 分析型数据库为基础的数据分析 / 数据仓库方案都存在着无法良好支持实时分析的障碍；类似 HBase 等 NoSQL 方案虽然可以支持很好的扩展性和实时性，但无法提供所需的分析能力；而传统单机数据库则无法提供数据分析所需的扩展性。传统的交易型数据库提供了完整的数据库事务特性支持，但是缺少可扩展性，同时使用的行存储，对分析型场景来说，性能不够理想。除此之外，传统大数据技术平台本身也存在一些问题，如下图：

从图中可以看到，已有的解决方案存在以下问题：

• 数据经过 ETL 逻辑复杂，同时存储、时间成本过高
• 数据链路长
• 技术栈复杂

成本支出

完整数据团队的组建包括数据开发组和数据产品运营组。其中数据开发组又可以细分为：

• 数据开发工程师：包括 ETL、后端开发、前端开发，主要负责负责搭建、运营和维护大数据平台和数据仓库；当前市场上该类人才数量还是比较充裕的。
• 数据分析工程师：负责汇总公司业务数据，完成数据分析。当前市场上该类人才数量也还是比较充裕的。
• 数据算法工程师：负责通过建立数学模型、算法模型满足业务需求，这类人才很稀缺，需要高薪。

数据产品运营组细分为：

• 数据产品经理：主要职责包括：评估利用数据驱动解决业务痛点的可行性，准确识别和评估各类需求，抽象出共性的数据驱动需求，形成标准化产品，减少工作量；在当前市场上是属于稀缺人才。
• 数据运营：负责帮助业务团队解决数据产品使用问题；当前市场上该类人才数量还是比较充裕的。

根据以上信息，仅人力成本粗略计算下来，团队账面成本将是一笔不小的开支，核心人才难获取。除了人力成本之外，因核心人才难获取，导致团队组建时间成本在 0.5-1 年；产品设计迭代到产出需要 1-2 年左右时间；同时引入多种技术栈，维护复杂。因此人力成本高、时间成本高，维护复杂。

为什么选 TiDB

TiDB 特性

TiDB 是一款 HTAP 为特点的数据库，定位于在线事务处理/在线分析处理 HTAP（Hybrid Transactional / Analytical Processing）的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 HTAP 等重要特性，同时高度兼容 MySQL 协议和生态，迁移便捷，运维成本极低。

• 基于行存和列存的 HTAP 架构
  • 提供完整的索引以及针对明细数据精确定位的高并发访问，满足高 QPS 的点查。
  • 高性能的 MPP 框架以及可更新的列存引擎，在数据进行更新之后，可以实时的同步修改到列存引擎，使得系统可以用分析型数据库的读取性能访问最新数据，满足用户的实时查询需求。
  • 一套入口同时满足 AP 和 TP 需求，优化器会自动根据请求的类型决定是进行TP 类访问，索引选择，还是列存或者 MPP 计算模式，简化架构的复杂度。
• **弹性扩缩容：**对线上环境的 TiDB、PD、TiKV 组件进行灵活便捷的扩缩容而不会对生产环境产生影响，操作透明。在 TiDB 组件的写入和 TP 查询能力成为瓶颈时，通过增加节点来线性扩展该能力；同时存储节点即 TiKV 同样可以根据存储需求不断进行扩容增加存储。相反，在进行节点缩容时，对线上服务的影响几乎无感知。
• SQL 标准与兼容 MySQL 协议：支持标准的 SQL 语法，包括聚合，JOIN，排序，窗口函数， DML，online DDL 等功能，用户可以通过标准的 SQL 对数据进行灵活的分析运算。此外，兼容 MySQL 协议语法，这使得兼容 MySQL 生态工具链以及分析工具可以直接沿用，在已经使用 MySQL 比较广泛的情况下，业务迁移至 TiDB 之后，无需在业务层大量改动代码，就可以实现无缝对接。
• **管理简单：**使用 TiUP 工具可以快速的完成集群环境的搭建部署；正常运行时不需要依赖其他系统，运维上手简单；提供自带的监控系统，方便进行性能瓶颈分析和问题排查。

周边生态

• **丰富的周边工具：**TiDB 提供了丰富的数据流入、流出工具和备份恢复工具。数据流入方面，DM 可以实现数据由 MySQL 全量和增量同步到 TiDB，在同步过程中不影响业务侧和 TiDB 侧进行数据的读写请求，Lightning 工具可以将外部离线数据批量导入 TiDB；数据流出则可以通过 TiCDC 和 Binlog 来实现 TiDB 数据流入到下游 TiDB、kafka 等环境，满足对数据进行二次处理。BR 工具可以实现按照用户的全量和增量需求进行数据备份和恢复，特别是对大数据量备份，效果好同时部署操作简单易上手。
• **良好的社区生态：**对于想学习 TiDB 产品的同学来说，TiDB 提供给大家多种渠道学习和掌握。官方网站提供的官方文档包含了所有的 TiDB 版本对应的文档信息，通过查阅文档可以详细了解某一个版本的使用信息；博客部分展示了每个标签对应知识点深入讲解的文章；用户案例部分介绍当前各行各业在核心和典型场景使用 TiDB 的情况。如果准备想用或者想知道其他人是怎么使用 TiDB，TiDB 提供了供大家随时交流的平台，即 TUG（TiDB user group），会不定时的更新用户教程、使用经验和原理解读等文章，同时遇到任何使用问题时，可以在 AskTUG 论坛发帖求助，会有社区同学来帮助解答支持。人才培养方面，TiDB 有专门的 PU（PingCAP University）课程进行产品介绍，帮助有需要的同学学习和掌握最新的产品使用。经过 3 个月左右的学习，就可以熟悉和掌握 TiDB 的使用。

综合以上介绍，在使用 TiDB 之后，基本上可以替换到由各种技术栈构成的大数据架构，解决传统大数据平台的诸多问题，比如 ETL 逻辑复杂、数据链路长，技术栈多样，数据分析与 TP 场景分离问题。同时通过学习培训之后，可以快速有效的掌握 TiDB 使用，运维成本低，性能满足要求，性价比极高。

TiDB 应用成效

基于 TiDB 的 HTAP 架构，目前已有多家用户在 AP 场景使用。

360 x TiDB

为什么选 TiDB

• 单实例写压力大，使用分库分表缓解。使用单实例 MySQL 应对业务需求时，测试发现单实例 MySQL 压力较大，为了分散写压力，必须进行 MySQL 分库、分表。
• 数据搬迁复杂同时维护路由规则代价大。大数据量下的分库分表，经常需要变动拆分规则，每次规则变动都可能涉及到数据的重新搬迁，并且业务端还需要投入大量的人力去维护路由规则。
• 多种数据库产品，维护成本高。满足广告主的报表需求需要引入其他的数据库，离线 ETL 每天凌晨对 MySQL 的抽取造成网卡满载，也会影响了凌晨的其他业务操作。

使用场景

**广告主实时 & 离线报表业务：**广告投放过程中实时/离线报表业务以及广告物料投放对广告主来说是最重要、最核心的业务。

架构

收益

• 良好的扩展性以及性能：解决分库分表问题，同时性能满足要求，两小时 1.5 亿数据写入。
• 实时分析与强一致性保证：搭配 TiFlash 组件，对分库分表合并后的单表进行多种维度的全局以及明细的实时分析，并且实现离线报销的在线统计，同时提供强一致性保证。
• 架构简化，数据链路缩短，维护成本降低。

中通快递 x TiDB

为什么选 TiDB

• 业务发展快、数据量激增， 存放在 Exadata 一体机数据周期越来越短, 业务方对数据周期需求上升。
• 分库分表设计满足不了业务方分析和时效需求，统计分析依赖存储过程，系统的扩展性和可维护性不高。
• 业务高峰单机性能瓶颈，单点故障风险高，数据同步 T+1，分析时效不够。
• 测试 HBase、Kudu 建设实时数仓，和现有技术栈难以兼容，并且不能很好支撑业务端多维度的 query。

使用场景

**快递物流业务：**各个环节中会产生大量的数据，需要对每个环节的每一个数据我们都会进行相关的分析，包括时效的监控。

架构

收益

• 数据存储周期从 15 天支持到 45 天。
• 支持在线横向扩展，随时上下线存储和计算节点，应用无感知。
• 满足高性能的 OLTP 的业务需求，性能略低于 Oracle，这个无法避免，因为 TiDB 是一个分布式的数据库。
• TP 和 AP 分离，数据库单点压力消失。
• 支持更多业务维度分析。
• 整体架构清晰，可维护性增强，系统扩展性增强，硬件成本降低。

总结

TiDB 作为一款 HTAP 类数据库，针对实时分析和实时数仓场景拥有独特的优势。

它不但能良好支持实时数据落地存储，也可以提供一体化的分析能力。而行列混合的引擎设计也使得它的分析能力不止于高并发的明细数据定位和分析，也可以提供大规模的交互 BI 查询。用户可以单独使用 TiDB 构建实时分析业务，也可以与大数据生态一起构建离线 + 实时的数仓体系。另外 TiDB 也在探索 Flink + TiDB 架构来适配更多的使用场景，目前也已经有多家用户在使用 Flink + TiDB 满足其自身的业务需求。