什么是真正的 HTAP ？（二）挑战篇

​​上一篇文章​​中，我们从技术和商业角度分析了 HTAP 系统缘起的背景，本篇文章中，我们将从 HTAP 定义及其相关核心技术等方面来讨论：构建一个 HTAP 所面临的核心问题和挑战有哪些？

HTAP 涉及技术和对产品的影响

HTAP 是将 TP 和 AP 进行高度融合的产物， 而非简单的 TP 和 AP 相加：TP+AP ≠ HTAP。有的数据库让 TP 系统通过简单的数据同步方式（比如 Binlog等），将数据同步到 AP 系统，然后再由 AP 系统进行处理数据，虽然该种方式从用户的角度来看似乎是获得了同时处理 TP 和 AP 的能力，但是从本质上来看，这并不能称为真正的 HTAP 产品，国内有一些数据库厂商宣传 HTAP 概念很起劲，但是自身可能还真不满足 HTAP 的定义。下面我们就 HTAP 所涉及到的几个核心问题来探讨一下，一个真正的 HTAP 产品需要具备哪些能力。

我们将从以下维度进行探讨：

1. 架构选择（Architecture choice）
2. 数据导入及查询处理引擎 （Ingestion and query processing egnines）
3. 存储方案 （Storage options）
4. 数据组织方案 （Data organization）
5. 事务语义（Transaction semantics）
6. 数据的时效性（Recency of data being read by OLAP)
7. 索引支持（Indexing supports）
8. AP 负载和 TP 负载的相互干扰（Workload interference）

1. 架构的选择

Single system（即 One system） 还是 Seperate system 的选择当前更多是基于工程上的难度。目前不少产品均是在原有的 TP 系统之上，叠加了一个 AP 系统并使用某种数据同步工具将TP系统中的数据同步至AP系统中。Seperate system 虽然有其优点，但这种方案存在着许多不容忽视的问题，比如无法保证对事务的支持能力、数据的时效性，以及复杂的系统架构等（下文会有详细的解释）。相比之下，One system 不仅架构简洁，对于事务的支持能力和数据的时效性等方面都能提供更好的保证。但是，One system 架构的技术难度相对较大，工程上也具有一定的难度，同时还需要考虑 TP 和 AP 负载间的相互干扰等问题。StoneDB 目前就是采用 One System 的架构设计，我们深知此架构的优势和难度。

2. 查询处理及数据导入引擎

该维度对产品有两个方面的描述。由于 HTAP 所面临的业务场景通常存着需要对海量数据进行分析处理需求，而在分析场景下，为了加速分析，通常的做法是将需要进行分析的数据，以列存的方式进行组织，这样可以利用列存的优势加速分析。因此，需要将适用于 TP 场景的行存类型数据转为适用于 AP 场景的列存数据。对于一个 HTAP 数据库首先需要解决的问题是高速的数据载入。这里又包括两个方面：

- 全量数据的载入方案，保证海量数据快速准确导入。

- 增量数据的更新方案，保证数据的时效性。

在数据加载完成后，另外一个维度是查询处理。查询处理部分属于整个 HTAP 数据库的核心模块，其最重要的能力是能够同时完成 TP 负载和 AP 负载的处理。

当系统接收到一个查询负载的时候，查询处理模块需要识别出该查询负载中的 TP 负载和 AP 负载。并能够依据相应的策略（这里可以是基于规则或者是基于查询代价），将相应的负载转发至相应的处理引擎。

3. 存储方案

随着存储技术的进步，存储介质和方式以及单位价格都发生了翻天覆地的变化，一个清晰的事实是：高速存储介质正在广泛地应用到数据库领域。对于 HTAP 数据库来说，TP 部分和 AP 部分的存储方案选择涉及到架构、性能、成本和业务场景等多方因素的影响。

4. 数据组织方案

选择列存储加行存储（DSM + NSM），还是 PAX （Partition Attributes Across）方案或者是其它方案。数据组织方案的选择不仅会极大的影响系统性能，还会影响数据的存储成本。而系统的整体性价比也是我们挑选产品的重要指标之一。

5. 事务语义

需要具有支持完整的事务语义的能力，即无论是 TP 部分还是 AP 部分都需要对事务进行完整的支持。现有的很多 HTAP 解决方案，AP 系统中所处理的数据均是同步自 TP 系统中已提交的数据。这类解决方案存在以下几个问题：首先，对应长事务场景下，如何保证 AP 系统可以获得最新版本的数据值得我们仔细考虑。再者，通过以同步日志的方式，数据的时效性和一致性需要认真考虑。最后，为了解决上述问题，会影响到事务的执行效率，导致系统吞吐量的下降。

6. 数据的时效性

需要保证 AP 系统所处理的数据均为当前最新版本的数据。当前的很多系统是在 TP 数据提交完成后，通过同步日志的方式将 TP 部分的变更同步到 AP 部分，这种方式无法保证数据的时效性，因而不能称之为真正的 HTAP 系统。

7.索引的支持

索引已成为 TP 系统的标配，通过设置索引可以大大提高数据库的检索速度，改善数据库性能。而 AP 系统中的更新操作通常为批量更新，在更新时首先需要定位到待更新的数据，考虑到 AP 系统的数据组织和存储模型，如何能够通过设置索引快速定位到需要更新的数据（尤其是在以列存且数据多为压缩形式的情况下）也是需要解决的一个难题。

8. 不同类型负载间的相互干扰

系统需要能够保证 AP 负载对 TP 负载无影响或者使得两种类型负载间的影响最小化。

上述讨论了一个真正的 HTAP 系统应该具备的几点核心能力，当然这些只是我们认为的核心能力，其它的相关问题这里就不在展开，后续我们会陆续给出上述 HTAP 核心能力的详细解读。

从不同维度对现有 HTAP 产品/解决方案进行分类

现有的 HTAP 产品图谱分类的主要方法：

1. 架构方式；
2. 存储范式（Cloud/Shared Disk）；
3. 扩展方式（Scale out/Scale up）；
4. 查询语句标准；
5. 并发策略（MVCC）；
6. 数据/表的组织方式；
7. 索引（LSM, ART, B-tree, lock-free Bw-Tree）。

其它方面：多模能力等属于非必要，这里暂不考虑。

下表从功能/许可证/是否开源等各个维度，对当前 HTAP 市场中的标杆产品进行了综合分析。如需获取更多信息，请访问我们的官网：​​https://stonedb.io/​​

这里我们将 ClickHouse 放进来，主要是考虑其在 AP 处理方面的优异能力，可以作为我们 HTAP 产品在 AP 方面的一个标杆。

HTAP所面临的核心挑战

综上，我们可以总结出 HTAP 面临的挑战有：

1. 真正的 HTAP，而非 TP 与 AP 的叠加
2. 架构的选择
3. 数据组织方案选择，存储方案选择
4. 查询优化：如何依据负载类型和查询代价选择合适的执行引擎
5. 数据的时效性：如何能够减少 TP 和 AP 之间的数据移动，高效实时地将 TP 数据更新同步到 AP 数据中
6. 负载隔离：如何有效地消除或者最小化 TP 和 AP 负载之间的相互干扰
7. 资源管理：如何能够高效的管理 TP 和 AP 负载之间的资源使用
8. 实时分析的能力
9. 事务语义支持

以上是对HTAP数据库的部分挑战梳理，在下一篇文章中，我们将对这些核心问题和挑战展开更加深度的讨论并给出选择一款 HTAP 产品的建议。

StoneDB 是国内首款基于 MySQL 的一体化实时 HTAP 开源数据库，内核引擎完全自研。我们将在开源数据库领域持续耕耘，不断与各个开源数据库社区、企业合作共建，共创国产开源数据库良好生态。

StoneDB 在6月29日已宣布​​正式开源​​。如果您感兴趣，可以通过下方链接查看 StoneDB 源码、阅读文档，期待您的贡献！

StoneDB 开源仓库

​​https://github.com/stoneatom/stonedb​​

作者：李浩

StoneDB 首席架构师、StoneDB PMC

曾在华为、爱奇艺、北大方正从事数据库内核核心架构设计。超过10年数据库内核开发经验，擅长查询引擎，执行引擎，大规模并行处理等技术。拥有数十项数据库发明专利，著有《PostgreSQL查询引擎源码技术探析》。

编辑 &校对：李明康、王学姣、高日耀、