面向未来的HTSAP一体化数据平台该是什么样子？

在大数据实时分析的应用趋势和技术高速发展的推动下，曾经在大数据带来的系统规模问题下分道扬镳的 OLTP 和 OLAP 技术栈，开始以新的形态发生融合。从在线交易数据的实时分析需求出发解决实时分析需求的 HTAP 技术已获得蓬勃发展。另外一方面，随着机器学习应用场景的爆发性增长，由在线推理需求催生的分析洞察实时服务能力开始以 HSAP 的形态获得高速发展。

TiDB 是一款开源 HTAP 数据库，Flink 则是大数据领域优秀的数据实时处理、分析和计算平台。TiDB 拥有灵活的架构设计，能够快速演化出完整 Serving 场景的支撑能力。Flink 不但在大数据领域提供了不错的实时计算能力，还凭借迅速追赶的批计算能力成为具备流批一体能力的下一代大数据处理框架。对这两个产品进行有机融合，能够让 Flink 为 TiDB 带来实时的数据交付能力和批计算级别的 AP 处理能力，让 TiDB 为 Flink 提供高性能的数据存储和查询底座，共同打造出面向未来的 HTSAP 一体化数据平台。

本文整理自 PingCAP 社区生态团队的张翔在DIVE全球基础软件创新大会 2022的演讲分享，主题为“TiDB x Flink：面向未来的 HTSAP 一体化数据平台”。

分享主要分为五个部分展开：第一部分，会来简单回顾一下 TP、AP 和 Serving 的技术要求，以及相应系统的典型应用场景。第二部分，我们也会一起回顾一下，近些年来开始出现了 HTAP 和 HSAP 两种混合型工作负载的技术要求。接下来第三部分以 Hologres 和 TiDB 两款产品为例，分别看下 HSAP 和 HTAP 领域目前的状态。第四部分和第五部分，既然已经有了能覆盖 TP、AP 领域的 HTAP 产品，也有了能够覆盖 Serving 和 AP 领域的 HSAP 产品，很自然我们就会思考，能否对现有的系统进行扩展，让它们同时满足 TP、AP 和 Serving 场景的需求，使用一个统一的技术栈，为开发者在这些应用场景下提供一致的用户体验。

以下是分享实录：

背景

首先，先介绍一下大家最熟悉的 OLTP 系统，应该说 OLTP 系统是每一个业务工程师最先接触到的数据库类型，它具备强事务能力。在 OLTP 系统上构建的业务，通常采用关系型的数据模型，以小的事务和小的查询为主，在高并发的情况下，为用户提供低延时的访问。

我们来看一个 OLTP 的典型应用场景，今天电商业务已经极度发达，大家每天都可能在线上提交订单，并完成支付，背后支撑订单支付的系统就是一个 OLTP 的典型应用场景。在整个订单的支付的流程中有许多的步骤，在用户和业务系统之间，业务系统和外部支付系统之间，业务系统和数据库之间，都会发生多次的交互。我们在这里可以看到列出的步骤，简要的步骤大概有十个左右，这当中的每一个交互都需要保证它的事务性，并且还需要在极短的时间内完成事务的处理，给每一个用户提供又快又好的体验。

接下来我们来看一下 OLAP 系统，对于 OLAP 系统来说，通常是基于大量的数据集，用复杂的表关联、分组、聚合、排序等操作对数据进行分析，查询一般需要覆盖大量的数据。而且大多数时候，大多数的访问不需要访问 Row 所有数据，只需要访问部分的列，并且聚合的需求会明显多于明细的需求。我们需要面对读密集去做个优化，在 OLAP 中数据通常以雪花或星型的形式进行建模，在 DWS 或者说 ADS 层使用宽表形式进行组织数据。OLAP 通常是为企业内部决策提供数据参考，所以说需要支持并发数相比 OLTP 系统来说要低许多，但是它需要支持非常复杂的聚合查询，通常提供的这个响应时间是秒级、分钟级，有的时候甚至是小时级的响应时间。

还是以刚才的订单系统为例，订单系统大家接触也比较多。电商平台的订单分析，就是一个典型的 OLAP 工作场景，企业内部不同角色的人员，他对于数据分析的诉求是不一样的。比如销售经理会在地区纬度进行分析，根据每个大区中不同产品的销售情况，制定每个地区的销售策略。而产品总监他总是需要在产品纬度上进行分析，根据产品分类，分析产品在不同地区的销售情况，来制定相应的销售策略，所以说他们的分析诉求是完全不一样的。

接下来是 Serving 系统，Serving 是一类随着互联网应用爆发，而得到广泛应用的数据库。在需要应对海量用户和高并发场景的互联网行业，以合理的成本在这样极端的场景下支撑起业务，催生了 Serving 系统的发展。过去我们通常使用 NoSQL 数据库来应对这种业务场景，NoSQL 系统通过非事务模型以及简化关系模型的方式，用合理的成本来提供高并发下的在线点读、点更新能力。有些系统还提供了灵活的二级索引支持，进一步提升了应用开发的效率。近些年来，随着机器学习的快速发展，特征存储成为了 Serving 方向的一个快速增长点。除了前面提到的这些技术要求之外，极低的延时，极高的并发，Feature Store 还对 Serving 系统提出了更多的要求。尤其是在对服务的并发能力和响应时延都有要求的前提下，还需要具备在不影响在线服务的情况下，能够周期性地快速加载大量数据的能力。

相信大家对个性化推荐并不陌生，为了给用户提供更好的个性化体验，许多 C 端产品都开始加大在推荐系统上的投入。推荐系统的工作模式通常是由周期性执行的计算任务，生产离线的这些特征加载到 Feature Store 中。而用户的行为日志和交易事件则会经过实时的加工，产生实时的特征，同样也会到 Feature Store 中。图的右侧是特征存储在线 Serving 的部分，当用户的请求到达推荐系统时，推荐系统会根据用户的请求，和召回的侯选物料去特征存储批量查询大量的特征向量。拿到所有的特征向量后，就可以由模型进行预测，在完成推荐过程后把结果返回给用户。

刚刚我们了解了三大类典型的工作负载，也了解了它们背后能够支撑什么样的业务场景。从业务系统开发者的角度上看，它们需要根据自己的业务需求选择不同特点的数据库来更好地服务自身的业务场景，都希望用统一的技术来支撑更多的场景。如果用户不需要为这三种场景去分别学习和管理不同的数据库系统，那么无疑对用户来说是非常有价值和吸引的。

基于这样的动力，我们现在有了 HTAP 系统，也就是面向 TP 和 AP 混合场景的负载而设计的系统。HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统的架构当中，在线与离线数据库之间要有大量的数据交互。HTAP 基于分布式架构支持弹性扩容，可按需扩展分布，或者说数据存储，轻松地应对高并发、海量数据的场景。在 HTAP 系统内部，数据按照行存和列存的形式进行混合存储，通过 TP/AP 负载隔离的方式，通过用户提供统一的查询入口，一站式地解决两类工作和负载的不同诉求。

与 HTAP 类似，HSAP 是面向 Serving 和 AP 场景混合设计的系统，就像前面讲的 Serving 场景，尤其是在特征存储这种场景下，数据的实时和批量摄入能力是一个刚性需求。HSAP 基于分布式架构支持弹性扩容，也能够按需扩展吞吐以及存储，来应对高并发和海量数据分析的一个场景。在 HSAP 系统内部，数据也是按照行存和列存的这种形态进行混合存储，通过 Serving AP 负载隔离的这种方式，为用户提供一个统一的查询入口，一站式地解决两类工作负载不同诉求。

现状

接下来让我们以 Hologres 和 TiDB 两款产品为例，分别看下 HSAP 和 HTAP 领域目前的状态。此后，我还会介绍，诞生于 TiDB 生态面向 Serving 场景优化的 Zetta 系统。

Hologres 是 HSAP 里面的创造者，很自然 Hologres 具备了 HSAP 系统的全部能力，适合解决 HSAP 的混合工作负载。

我们从架构层面看一下 Hologres 是如何实现 HSAP 的。Hologres 它拥有完全面向云设计的架构，底层是由盘古分布式文件系统为它提供了高性能的以及高弹性的数据存储能力，而 Hologres 自身作为计算层也可以非常容易地横向扩展，因此整个系统自底向上都具备着非常强的弹性。在这个架构上，Hologres 实现了行存和列存两种格式数据的存储，以及物理隔离。除此以外，还提供了租户间的任务调度隔离，为用户提供了一个统一的，同时满足极致的 Serving 响应时间要求，和高性能的 AP 分析能力的系统。

接下来让我们来看一下 TiDB，TiDB 作为 HTAP 早期的实践者，具备 Gartner 最初定义的 HTAP 系统的各种能力。而且 TiDB 甚至比许多的 HTAP 实践更近了一步，为 TP 和 AP 数据带来了强一致的实时同步能力。在这个能力的支撑下，TiDB 能够在维持事务一致性的前提下，为用户的查询选择全局最优的执行计划，将单一的查询的部分执行计划，分别交给行存和列存系统去执行，来获得一个最优的处理能力，这个是 TiDB 的一个创新点。

为了实现刚才所说的强一致的 HTAP 能力，TiDB 利用 Raft 一致性复制协议，将在线交易的行存数据副本，同步转变为了可更新的列存副本，并且以更适合分析系统的方式对数据切片进行了一个重新的组织。这种创新性的副本同步方式，在对数据和负载进行充分物理隔离的前提下，还能够让 AP 副本实现和 TP 副本一致的事务隔离级别。这种强一致的数据同步能力，为 TiDB 带来了灵活的行存、列存混合执行能力，充分利用到了行存和列存两种系统的优势。在单一查询中，同时使用两种系统，自动地为用户去提供最优的执行方案。用户他其实还是执行了 SQL，他不需要去指定这个 SQL 是运行在 TP 系统，还是在 AP 系统上。TiDB 会去判断这个 SQL 当中的哪些部分是在 TP 系统上更适合，还是在 AP 系统上更适合，选择最优的一个执行方案，最终将两个系统的执行结果汇总后返回。

TiDB 它拥有着灵活、开放的架构，在这个基础上可以有非常多的方式，对系统去做不同的设计取舍，从而更好地支撑多样化的 Workload。Zetta 就是这样一款由知乎在 TiDB 生态中构建，面向 Serving 场景性能和能力优化的数据库。

Zetta 项目立项于 19 年，当时 TiDB 还处于 3.0 的时代，在知乎内部有一个非常有挑战的 Serving 场景，而且当时 TiDB 集群的数据规模已经接近了 300 TB。在这个业务规模下，如果可以根据 Serving 场景的特点去做针对性的优化，毫无疑问，收益将会非常明显。除了这个业务，知乎还有许多同样数据体量巨大的 Serving 系统，由 HBase 来支撑，为了统一 Serving 场景的技术栈，完成 HBase 向 TiDB 生态技术栈迁移，平台团队开始了 Zetta 系统的设计和研发。基于替换 HBase 的考虑，Zetta 系统还提供了和 HBase 协议兼容的能力。后期为了降低业务的开发成本，还支持了 MySQL 协议，并且在这个基础上为用户提供了事务支持、二级索引和 SQL 接入，这些是过去在 HBase 生态当中缺乏的能力。

我们来看一下 Zetta 架构，从图上可以看出，Zetta 架构和 TiDB 的 DB 部分非常接近，它在面向 Serving 方向的取舍，主要体现在我们提出来的这些点。首先，可以通过可选事务和非事务表，给用户提供了性能和事务上的 Tradeoff 能力。通过聚簇索引的方式给用户提供了数据分布的手动控制能力，通过非关系的宽表模型降低了业务开发的这样一个使用门槛，甚至能够支持单行数十万列的一个极度稀疏的数据。而且 Zetta 它是仅面向点读和点更新进行性能的优化，所有的取舍都极大地简化了优化器和执行系统的实现，这些取舍让 Zetta 和同系的 TiDB 相比拥有着更低的时间表现，在同样的资源投入下能够支撑更高的并发。今天知乎的大量的线上的系统已经从 HBase 迁移到了 Zetta，平台方明确计划将全部的 HBase 业务迁移到 Zetta，并且完成 HBase 的一个下线。

HTSAP

如果我们站在开发者的角度上看，简化的系统架构和统一的技术栈具有非常大的成本优势，既然我们已经有了能够同时承载 TP、AP 负载的 HTAP 系统，也有了同时承载 Serving 和 AP 负载的 HSAP 系统，很自然的，我们会问为什么不能有同时支撑好 TP、AP 和 Serving 工作负载的 HTSAP 系统？如果有一款能够同时满足三种工作负载的 One Database，它能够为用户带来一致的用户体验，简化后的单一系统也能够极大地降低学习成本和管理成本。

One Database 听起来是一个非常诱人的目标，而且实现路径也非常直接，比如我们可以选择为 HSAP 数据库增加事务能力，也可以选择在 HTAP 数据库的基础上增强 Serving 能力，这两种方式都能够扩展现有的 Hybrid 产品，令其成为同时满足三种场景的更全面的 Hybrid 数据库产品。

首先，我们来看一下，如果我们选择在 HSAP 数据库的基础上进行改造，我们首先需要的是为它增加事务的能力。典型的实现方式可以和 TiDB 一样，采用两阶段提交的事务方式，来维护事务的 ACID 语义。而且只具备事务能力还不能够满足大家对 OLTP 数据库的全部期望，用户会期望它同时具备完整的关系查询能力。这会对系统的数据布局和优化器，乃至 RunTime 等许多方面都提出更复杂的要求。当这些要求都被满足后，这个 HSAP 的数据库就能够成为一款 HTSAP 全场景覆盖的数据库。

类似的，我们也可以在 HTAP 的基础上弱化对事务的一个保障，让用户根据自己的实际业务需求，在强一致和弱一致之间进行选择，在极端性能和成本方向，强化系统的 Serving 能力。具体的实现路径可以是这样的，首先可以为用户提供非事务表的选择，在放松一致性和事务隔离级别要求的前提下，非事务表它可以彻底避免锁机制带来的开销和锁冲突带来的等待，也可以降低 MVCC 管理为系统带来的复杂度，在读性能和写性能上都能获得非常显著的收益。

在 SQL 方面，我们可以对优化器的规则进行进一步的简化，对于 Serving 类的 Query，我们就不支持复杂的跨表 Join，只面向具备唯一索引的这种点查来进行优化。通过简化处理流程，降低 Serving 类 Query 处理的资源消耗，从而进一步降低查询的响应时间。在数据模型方面，我们可以增加 NoSQL 系统常见的一个宽列数据模型，就能够降低现有的 Serving 用户迁移的技术成本。最后在不影响在线服务的情况下，我们还需要提供批量数据快速加载的能力，更好地支持今天 Big Data 产生的数据为用户提供在线服务的诉求。通过这些简单的调整，HTAP 数据库能够以较低的成本来增强自己的 Serving 能力，演化成为一个 TP 和 AP 以及 Serving 场景全面覆盖的数据库。

如果我们选择在 HTAP 数据库上扩展 Serving 能力，我们可以以 TiDB 和 Zetta 来作为一个参考，这个问题可以转化为如何把 Zetta 的 Serving 能力带到 TiDB。由于 Zetta 它本身就诞生于 TiDB 社区，它和 TiDB 具有非常密切的技术关联，也共享着许多的基础能力，所以说将它们融合是非常自然，而且难度比较低的一个工作。尤其是在考虑到，Zetta 诞生于 TiDB 3.0 的时代，而目前 TiDB 已经迈过 5.0，马上要迈向 6.0。

Zetta 为提高性能做了许多取舍和努力，在今天的 TiDB 上已经具备了许多相似的能力。比如聚簇索引已经为 TiDB 带来了数据分布的精细控制能力，比如具备更好扩展性的 Cascade Planner 带来了执行计划灵活性定制的能力，比如 Plan Cache 能够复用从前的执行计划，从而进一步的来降低响应的时间。还有，TiDB 现在也支持了 JSON 列，也为我们带来了 Schema Free 的数据组织能力。除了这里讲到的这些功能以及特性，还有更多的细节的一些改进，都对系统的性能和功能起到了一个巨大的推动作用。可以说，今天的 TiDB 在 Serving 场景上，已经有了同 Zetta 非常接近的一个能力，在这样的基础上，如果我们把 HBase 或其他常见的 NoSQL 协议兼容，带到 TiDB，那么对于用户来讲，这样的 TiDB 就具备了 TP、AP 和 Serving 三大场景全面覆盖的能力。

除了上面所讲的实现路径的低成本的可操作性之外，以 TiDB 为基础来演进 HTSAP 数据库，还有一个非常重要的一个优势，就是 TiDB 的架构是不和云，或者说某一家具体的云厂商做绑定的。作为用户可以不受限制，根据自身的 IT 基础设施的特点，自由地在云下、云上或者说混合云的这种环境当中来架设 TiDB。从而获得一个具备 TP、AP 和 Serving 能力的 One Database，来灵活地应对自己多样的业务负载。

TiDB x Flink

当我们仔细观察 HSAP 的代表作 Hologres 的时候，我们会发现 Flink 是每个 Hologres 方案当中必不可少的一个部分，可以说正是 Flink 的支持数据处理能力，为 Hologres 解决了 Serving 数据的一个生产问题，让 HSAP 的理念成为了可能。对于 TiDB 来说，如果只是单纯自己具备 Serving 能力，同样无法为用户闭环解决全部问题。TiDB 成为一站式的数据平台，同样离不开 Flink 同步。

首先我们来看一下，Hologres 和 Flink 的一个典型的配合方式。这是一个典型的实时数据加工链路，在链路上对数据进行层层的加工，根据加工层次的不同，这些加工产出的数据可能会用作 AP 分析，也有可能会为下游提供在线的一个处理服务。在这个数据流上看，Flink 作为上游为 Hologres 提供数据，Hologres 它要提供服务，离不开 Flink 生产的数据。

同传统的不可更新或点更新能力较弱的大数据解决方案相比，Flink 实时数据加工也离不开 Hologres 提供的高性能写入的能力。对于那些更新要求不高的数仓场景，也可以用 Flink 的批处理能力，将数据首先加载到 MaxCompute 中，在分析阶段再交由 Hologres 进行处理。Hologres 它不但提供了高性能的更新能力，它同时也提供了非常强的 Serving 能力，可以帮助 Flink 在数据加工过程当中支撑高吞吐的数据大宽需求，Hologres 也是实时数据加工链路中维表的一个非常理想选择。不论从哪个方向上来看，两者都具有非常强的一个互补关系，只有将 Hologres 和 Flink 配合在一起，才能为用户去提供一套完整的实时数据服务能力，闭环用户的诉求。

前面看到的是一个数据处理链路内部的一些实现细节，如果我们从外部用户的视角来看 Hologres 和 Flink 的整合，我们可以发现，Flink 作为数据的一个驱动者，它从消息系统、在线交易数据库、日志文件系统等等数据源当中收集实时或者说静态的数据，完成这些数据的精加工之后，将结果统一加载到 Hologres 中。而各种数据的消费方，比如我们上面列举的实时大盘、BI 可视化工具、数据应用、各种在线的 API 服务，就都可以从 Hologres 的一个入口当中，一站式地获取全部的数据的 Serving 和 AP 处理能力。

接下来我们看一下 TiDB 和 Flink 配合。和 Hologres 同 Flink 的配合方式类似，在同样的实时加工链路上，Flink 负责对数据运行产生了一个加工，根据加工层次的不同，加工产出的数据可以用作 AP 分析，也可以为下游提供在线的数据服务。与 Hologres 不同的是，这其中还包括了有事务需求的数据服务。

由于目前 TiDB 列存还不能够脱离行存独立存在，所以对于更新能力要求不高，并且数据体量较大的一个 DWD，或者说 DWS 层这的数据需求，选择 Icerberg 或者说 Hudi 是目前性价比比较高的实时数仓的建设方案。和 Hologres 类似，TiDB 也拥有非常高的一个存储查询能力，这样 Flink 在这个实时数据链路当中也是维表的一个理想选择。和只有托管服务的 Hologres 不同，开放的 TiDB 配合 Flink 能够运行在云下，或者说多云这样多样的云厂商环境下。我们之前也提到，如果有以 TiDB 为基础去演进 One Database，它可以在各种基础设施环境下去进行部署，不与任何的云，或者说某个单独的云厂商去进行绑定。如果用户的基础设施没有在云上，或者说没有在阿里云上，那么 TiDB 和 Flink 在这种情况下，仍然能够为大家带来一流的在线交易、在线服务，来支持数仓的能力。

同样，如果我们从外部的视角来看 TiDB 和 Flink 的整合，Flink 同样作为数据的驱动者负责从消息系统、在线交易数据库、日志文件等等数据源中收集实时或静态的数据。在完成这些数据精加工之后，将结果统一加载到 TiDB 中，而各种数据的消费方，包括图上列出了实时大盘、BI 可视化工具、数据应用、各种在线服务，在线服务包括有事务要求的在线交易型服务，都可以从 TiDB 这个入口一站式地获得全部的数据的 TP、AP 和 Serving 的处理能力。

未来如何规划？

我们刚才提到 TiDB 的列存副本现在不能够脱离行存独立存在，这其实拉高了 BigData 体量的数据仓库在 TiDB 上实施的成本，限制了 TiDB 在更广泛的一个 AP 场景的适用性。但是 TiDB 社区在快速的演进和发展，未来的 TiDB 在 TP、AP 和 Serving 方向的能力还会持续增强。伴随着这些能力的增强，我们对 TiDB 和 Flink 的未来也有一个更高的期望。

我们来看一下，TiDB 永远可以在哪些方向上去做一个优化。未来的 TiDB 首先在 Serving 方向还要做一个继续的强化，尤其是前面提到非常适合 Serving 需求的一个非事务表，用户可以用类似 MySQL 的方式在同一实例中，以表为颗粒度选择不同的存储引擎实现。只不过在 MySQL 中选择非事务表，在高并发下性能比事务表还要差，但在 TiDB 中这个情况就不复存在。非事务表的点读、点更新能力会优于事务表。

除此以外，TiDB 还会在 AP 方向追加更大的投入，为 TiDB 引入存列存表的支持，在解除和行存和列存的一个强绑定关系之后，我们能够为列存表引入更低成本的 S3 作为列存表的一个存储方式，这会大大降低 TiDB 列存的存储成本。这让在 TiDB 上，去实施具备成本优势的 Dig Data 规模的数仓成为一个可能。FDW 是一项在 TiDB 社区呼声颇大的一个特性，它能够为 TiDB 带来整合外部计算引擎的一个能力，实现联邦查询的这样一个可能。

当 TiDB 具备了刚才提到的存列存表的能力之后，我们再来回顾 TiDB 和 Flink 的一个配合关系。我们发现挡在 DWD 和 DWS 层的成本问题将不复存在。整个实时数仓的一个生产链路都能够由 TIDB 和 Flink 闭环完成，不论是实时大盘、BI 可视化工具，还是各类的数据应用和在线的 API 服务，都可以在 TiDB 这一个入口一站式得到解决。TiDB 就能够真正的成为一个 HTSAP 这样子的 One Database 系统，并且还具有很高的成本优势。

然后，在 FDW 的帮助下，Flink 甚至能够成为 TiDB 背后的一个计算引擎，它将不仅仅是为 TiDB 作为生产数据的这样一个功能，Flink 如果能够成为 TiDB 背后的一个计算引擎，不但能够为 TiDB 带来数据湖上异构数据的联邦分析能力，还能够成为 TiDB 在自身的一个 MPP 引擎之外另一个选择。为 TiDB 带来解决更大计算规模，执行比如说有着数百，乃至上千计算节点这样一个需求的任务的可能。而且，对于用户来讲，最关键的是，他们可以只关注 TiDB 这样一个统一的数据平台，忽略整个系统背后的复杂性。

最后，前面提到的各种增强并不是终点，未来还会有更多的可能性，会随着时间的推移浮现出来。特别 TiDB 是一个开源的、开放的一个社区，它所有的项目的源码也都进行开源，任何人都可以参与进来贡献自己的 Idea，贡献自己的力量。相信，随着 TiDB 的高速演进，以及配合着同样快速进步的 Flink，我们最终能够得到一个能够良好支撑 TP、AP 和 Serving 业务的开放的 One Database 平台。这样一个平台能够为业务带来一致的开发体验，以单一的用户体验降低用户的学习成本和管理成本，为用户创造源源不断的价值。当然刚才提到，TiDB 是一个开放的社区，所有的项目的代码也都已经开源，我们欢迎任何对这个有兴趣的人参与进来，加入到 TiDB 社区当中来，为 TiDB 和 Flink 去组成一个 One Database 的解决方案贡献自己的力量。