共计 4481 个字符，预计需要花费 12 分钟才能阅读完成。
作者：周跃跃，苏丹
近年来，随着数据规模越来越大，以及由此衍生出数据实时化的诉求激增，产生了一系列大数据相干的业务场景，场景复杂性高以及业务多维度是显著的两个特点，因而呈现许多了实时数仓架构来满足业务需要。
本文不波及对大数据场景的介绍，适宜正在或者思考进行大数据架构摸索的对象，将依据不同的角色需要、老本以及技术选型方面做介绍，并 提供一种可供选择的 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 组件，对分库分表合并后的单表进行多种维度的全局以及明细的实时剖析，并且实现离线报销的在线统计，同时提供强一致性保障。
- 架构简化，数据链路缩短，保护老本升高。
更多应用详情参考 360 x TiDB|性能晋升 10 倍，360 如何轻松抗住双十一流量
中通快递 x TiDB
为什么选 TiDB
- 业务倒退快、数据量激增，寄存在 Exadata 一体机数据周期越来越短, 业务方对数据周期需要回升。
- 分库分表设计满足不了业务方剖析和时效需要，统计分析依赖存储过程，零碎的扩展性和可维护性不高。
- 业务顶峰单机性能瓶颈，单点故障危险高，数据同步 T+1，剖析时效不够。
- 测试 HBase、Kudu 建设实时数仓，和现有技术栈难以兼容，并且不能很好撑持业务端多维度的 query。
应用场景
快递物流业务：各个环节中会产生大量的数据，须要对每个环节的每一个数据咱们都会进行相干的剖析，包含时效的监控。
架构
收益
- 数据存储周期从 15 天反对到 45 天。
- 反对在线横向扩大，随时高低线存储和计算节点，利用无感知。
- 满足高性能的 OLTP 的业务需要，性能略低于 Oracle，这个无奈防止，因为 TiDB 是一个分布式的数据库。
- TP 和 AP 拆散，数据库单点压力隐没。
- 反对更多业务维度剖析。
- 整体架构清晰，可维护性加强，零碎扩展性加强，硬件老本升高。
更多应用详情参考从_Exadata 到 TiDB，中通快递 HTAP 实际_
总结
TiDB 作为一款 HTAP 类数据库，针对实时剖析和实时数仓场景领有独特的劣势。
它岂但能良好反对实时数据落地存储，也能够提供一体化的剖析能力。而行列混合的引擎设计也使得它的剖析能力不止于高并发的明细数据定位和剖析，也能够提供大规模的交互 BI 查问。用户能够独自应用 TiDB 构建实时剖析业务，也能够与大数据生态一起构建离线 + 实时的数仓体系。另外 TiDB 也在摸索 Flink + TiDB 架构来适配更多的应用场景，目前也曾经有多家用户在应用 Flink + TiDB 满足其本身的业务需要。
如果想理解更多对于 TiDB 在实时剖析场景下的摸索和解决方案，欢送点击【文末链接】填写表单，即可分割咱们的社区技术专家获取更多专有干货内容。
TiDB 在实时查问业务场景下的实际 – 社区交换forms.pingcap.com
