在上一篇文章《HTAP 的下一步？SoTP 初探（上）：数据分析正在从“大”数据趋向“小”而“宽”数据》中，我们从 HTAP 的发展历史脉络出发，结合国际知名咨询机构Gartner 的调研报告，点出了 SoTP（Serving over TP）诞生的背景。今天这篇文章，我们着重来讲一讲，SoTP 的定义、解决的问题和典型应用场景。本文是在第七届中国开源年会上的演讲实录+编辑补充版，权当抛砖引玉，欢迎广大同行批评指正。
SoTP 的重要支撑
“小”数据和“宽”数据的崛起
开篇还是回顾一下，我们提出 SoTP 的重要背景：从“大”数据转向“小”数据和“宽”数据。
根据 Gartner 技术成熟度曲线的判断，小数据正处于“创新出发点”的阶段，可能还需要一段时间才可以进入成熟，不过，随着小数据市场渗透率不断提高，它对 AI 以及更广义的数据分析的影响是显而易见且非常深远的。小数据的优势在于，抛开了对大型单体数据的依赖，实现了对于大型、小型、结构化、非结构化数据源的分析与协同。
这个趋势不仅仅是被 Gartner 一家认可的， 国际权威学者吴恩达教授也在今年 2 月初提出了：AI 的下一个发展方向，是从大数据转向小数据。当然，我们提的 AI 也只是实时事务处理与数据分析的一个重要应用领域而已，并不是全部。不过，未来数据库、数据分析处理与 AI、ML 的结合却是必然的，就比如我们后续将在 StoneDB 架构中加入的 StoneDB Autopilot 功能。作为在人工智能和机器学习领域上有着全球级影响力的领军人物，吴恩达最近几年一直在倡导以数据为中心的人工智能。什么叫以数据为中心？那就是对数据的质要有更高的要求而不是一昧的追求量（优质的小数据集经过训练也能有很好的泛化能力，如果读者感兴趣，可以阅读吴恩达接受 IEEE Spectrum 的采访新闻），而“小”数据和“宽”数据恰恰就是高质量数据集的最佳载体，可以理解为，这是众多数据分析场景逐渐从依托“量”转向提升“质”的重大发展趋势。
大势所趋之下，作为实时数据分析场景的基础底座之一，HTAP 数据库扮演着的角色也越来越重要。如果说通过“小”数据和“宽”数据获得了更高质的数据，那么热数据则是对这个质的再一次提升。
热数据一般是指频繁被访问查询的在线数据，而在一个实时智能决策系统中，近期产生的热数据往往才会发挥最大的价值，但是，并非所有 HTAP 数据库都是专注于热数据场景下的“小”而“宽”数据的，对此，StoneDB 作为国内首个对标 Oracle MySQL HeatWave 的开源实时一体化 HTAP 数据库，率先提出了面向热数据、小数据和宽数据场景的 SoTP 型数据库理念。
SoTP 数据库的定义
2.1 Serving 的定义和分类
先说这个 Serving 场景，一些同学可能有些不熟悉，因为好像之前听到的都是 OLTP 场景（指在线事务处理，比如业务处理，交易系统等） 和 OLAP 场景（指在线分析处理，比如BI、Adhoc等），但其实还有一种场景，是指在线实时服务的，介于 OLTP 和 OLAP 之间，可能还偏向 OLTP 一些，那么这种场景我们就称之为 Serving（英语时态学得好的人，应该可以 Get 到，就是进行时的意思，也即可理解为“进行中的服务”）
Serving 可以和 OLTP 组合，也可以和 BigData 或者 Stream 组合，我们把 Serving 分成了三类：
Type1. Serving over TP（StoneDB）
特点：处理事务型热数据，提供实时分析、事务和分析处理一体化
典型代表：Oracle MySQL Heatwave，StoneDB
Type2. Serving for BigData
特点：处理非事务型冷、温数据；适用读多写少BI分析类
典型代表：ClickHouse
Type3. Serving for Stream
特点：处理非结构化数据，作业状态状态等数据管理
典型代表：RocksDB
为了方便大家理解，我们做了一张图，三种类型的 Serving 数据库如图所示：
2.2 SoTP 的定义和解决的问题
那么，SoTP （Serving over TP）的定义也就很清晰了，简单来说，我们把这种有能力对在 OLTP 数据库上的热数据、小数据、宽数据进行 Serving（在线实时服务） 操作的数据库，称之为 SoTP 数据库。具体来讲，比如以 SoTP 数据库 StoneDB 为例，一个 SoTP 产品至少要满足以下几点要求：
数据量：一个系统，数据量不超过 100 TB，通常介于 100GB~100TB 之间
数据类型：主要处理结构化数据，可处理 Text、JSON 等半结构化数据，不处理非结构化数据
NoETL：TP 到 Serving 的流转过程中，NOETL，直接基于 TP 数据完成实时分析
查询类型：复杂即时的查询，将事务型热数据，从行存变成可被快速读取的列存数据
高并发的混合负载：比 AP 查询的并发高 3 个数量级
成本控制：TCO 总成本下降 80%
简单举个例子。如下图，右边就 SoTP 据库 StoneDB，对外主要接受两个业务请求，分别是左边的 OLTP 和 Serving，其中，进行 Serving 请求的主要是是 OLTP 产生的热数据。那么这个 SoTP 处理数据的过程就是先把 OLTP 请求交给主引擎——TP 引擎承载（如 InnoDB），然后再把 Serving 请求交给次引擎——Serving 引擎承载（如 Tianmu）。
2.3 SoTP 的典型场景案例
2.3.1 场景一：Native Analytics Query
注意，我们这里重点提出了一个 Native，什么叫 Native，就是指数据源上的原生，我们如果对 OLTP 系统产生的数据进行查询分析，这里的数据应该是同源的热数据，而不是另外一份数据。
客户需要一个数据库，既能执行 OLTP，还能高效、实时地运行Analytics；否则还得需要另外一个数据库运行 Analytics，这引入了额外的复杂性和代价。
传统的 ETL 方案架构就是比较复杂的，比如 MySQL + ETL + Elastic：
这种方案就不能称为是 Native，体现在数据源的不一致、查询语句语法变更等等。但是，使用 SoTP 数据库 StoneDB，就有所不同了，我们是完全一体化架构，如下：
StoneDB 一体化架构
采用 StoneDB 这种一体化架构就可以达成降本增效的效果，下图就是我们在华东地区的一个 CRM 客户使用 StoneDB 的案例：
总结来说，这个厂商获得了以下成果：
高兼容：平行替代MySQL业务，零改动
低成本：节省了成本 52%
强性能：DTU 提升了 68%
易维护：技术难度降低 50%
2.3.2 场景二：Native Autopilot
Autopilot 自动化了实现大规模高查询性能的许多最重要和最具挑战性的方面，包括provisioning、数据加载、查询执行和故障处理。
如图，StoneDB 未来的 Autopilot 将有以下特性：
自动系统配置
自动资源占用监测，集群节点按需自动动态伸缩。
自动性能监控，对需要分析的表数据进行自适应采样来预测运行工作负载所需的节点数量。
数据加载
自动并行加载：自动调整数据表最佳并行度来优化加载时间和内存使用
自动数据放置：存储数据自动分区以实现最佳查询
自动编码：采用可变长度的字符串编码确保最佳查询性能
查询执行
根据历史查询计划执行情况和统计信息优化查询性能，提升查询效率。
故障处理
自动错误恢复：当数据库节点访问异常时，StoneDB将自动配置新的数据库节点并完成数据迁移，确保数据快速恢复。
这里也可以举个例子，比如现在我们的需求是减少用户使用成本：要提供自动化的集群配置、加载数据、查询处理和故障处理服务，使得用户可以更多关注业务开发，减少其繁重且易出错的运维操作。
在使用 Autopilot 之前：
1. 依据数据量和数据变化率，估算节点数量；
2. 与业务开发人员确定数据分布方案；
3. 业务运行中，不断优化SQL语句；调整数据分布策略；
4. 集群节点变化导致数据迁移，业务架构，中间件等相关策略需调整；
在使用 Autopilot 之后：
1. 搭建好StoneDB服务；
2. 系统依据运行情况，自动调整相关参数，使得StoneDB处于最佳运行状态；
3. 业务人员和DBA等得到解放，更加关注业务。
SoTP 与 OLTP、OLAP 的差异
我们总结了 SoTP 与 OLTP、OLAP 的差异，具体如下表：
SoTP 数据库——StoneDB
当然，可能有部分同学看到我们上述的定位，会想着说 SoTP 和 HTAP 有一些相同之处，这是当然，毕竟我们的说法是 HTAP 的下一步，SoTP 初探。实际上，SoTP 针对的是更加细分的 HTAP 赛道，我们的核心目标就是对最近产生的热数据、小数据和宽数据进行实时分析，更进一步的是，把数据分析能力与机器学习相结合，而且因为我们是基于 MySQL 生态做的一体化架构，也可以把我们称作是 MySQL 热数据分析加速器。总之，StoneDB 作为 SoTP 数据库的核心特性就是：能够将 Serving 需要的热数据实时分析做到极致。
我们努力的现在，就是为了让下一代热数据分析尽早走上国产数据库的历史舞台，让更多的用户体验到真正的商业智能，从而更好地利用数据协作共享、驱动运营和做出决策。以下便是我们的 StoneDB 2.0 架构图：
StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），HeatWave 有多强大？我们后面也会出一篇文章给大家分享一下。目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上：
https://github.com/stoneatom/stonedb/issues/436
如果您想了解更多，也可以关注我们的 Github 仓库：
https://github.com/stoneatom/stonedb
以上，就是本次的分享，欢迎大家批评指正。如果您还有其他疑问，欢迎添加StoneDB小助手，加入StoneDB开源社区技术交流群，在群里您可以随时提问，我们会认真为您解答。
扫码添加小助手
加入StoneDB开源社区用户群
讨论交流，共同进步
存算一体 VS 存算分离 ，IT发展下的技术迭代
面向场景，HTAP到底是刚需还是炒作？
StoneDB 团队成员与 MySQL 之父 Monty 会面，共话未来数据库形态
解读《Benchmarking Hybrid OLTP&OLAP Database Systems》| StoneDB学术分享会
深度干货！一篇Paper带您读懂HTAP | StoneDB学术分享会