上一篇文章中，我们从技术和商业角度分析了 HTAP 系统缘起的背景，本篇文章中，我们将从 HTAP 定义及其相关核心技术等方面来讨论：构建一个 HTAP 所面临的核心问题和挑战有哪些？
HTAP 涉及技术和对产品的影响
HTAP 是将 TP 和 AP 进行高度融合的产物， 而非简单的 TP 和 AP 相加：TP+AP ≠ HTAP。有的数据库让 TP 系统通过简单的数据同步方式（比如 Binlog等），将数据同步到 AP 系统，然后再由 AP 系统进行处理数据，虽然该种方式从用户的角度来看似乎是获得了同时处理 TP 和 AP 的能力，但是从本质上来看，这并不能称为真正的 HTAP 产品，国内有一些数据库厂商宣传 HTAP 概念很起劲，但是自身可能还真不满足 HTAP 的定义。下面我们就 HTAP 所涉及到的几个核心问题来探讨一下，一个真正的 HTAP 产品需要具备哪些能力。
我们将从以下维度进行探讨：
- 架构选择（Architecture choice）
- 数据导入及查询处理引擎 （Ingestion and query processing egnines）
- 存储方案 （Storage options）
- 数据组织方案 （Data organization）
- 事务语义（Transaction semantics）
- 数据的时效性（Recency of data being read by OLAP)
- 索引支持（Indexing supports）
- AP 负载和 TP 负载的相互干扰（Workload interference）
当系统接收到一个查询负载的时候，查询处理模块需要识别出该查询负载中的 TP 负载和 AP 负载。并能够依据相应的策略（这里可以是基于规则或者是基于查询代价），将相应的负载转发至相应的处理引擎。
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 系统中的更新操作通常为批量更新，在更新时首先需要定位到待更新的数据，考虑到 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 产品图谱分类的主要方法：
- 架构方式；
- 存储范式（Cloud/Shared Disk）；
- 扩展方式（Scale out/Scale up）；
- 查询语句标准；
- 并发策略（MVCC）；
- 数据/表的组织方式；
- 索引（LSM, ART, B-tree, lock-free Bw-Tree）。
下表从功能/许可证/是否开源等各个维度，对当前 HTAP 市场中的标杆产品进行了综合分析。如需获取更多信息，请访问我们的官网：https://stonedb.io/
其它方面：多模能力等属于非必要，这里暂不考虑。
这里我们将 ClickHouse 放进来，主要是考虑其在 AP 处理方面的优异能力，可以作为我们 HTAP 产品在 AP 方面的一个标杆。
HTAP所面临的核心挑战
综上，我们可以总结出 HTAP 面临的挑战有：
- 真正的 HTAP，而非 TP 与 AP 的叠加
- 架构的选择
- 数据组织方案选择，存储方案选择
- 查询优化：如何依据负载类型和查询代价选择合适的执行引擎
- 数据的时效性：如何能够减少 TP 和 AP 之间的数据移动，高效实时地将 TP 数据更新同步到 AP 数据中
- 负载隔离：如何有效地消除或者最小化 TP 和 AP 负载之间的相互干扰
- 资源管理：如何能够高效的管理 TP 和 AP 负载之间的资源使用
- 实时分析的能力
- 事务语义支持
以上是对HTAP数据库的部分挑战梳理，在下一篇文章中，我们将对这些核心问题和挑战展开更加深度的讨论并给出选择一款 HTAP 产品的建议。
StoneDB 是国内首款基于 MySQL 的一体化实时 HTAP 开源数据库，内核引擎完全自研。我们将在开源数据库领域持续耕耘，不断与各个开源数据库社区、企业合作共建，共创国产开源数据库良好生态。
StoneDB 在6月29日已宣布正式开源。如果您感兴趣，可以通过下方链接查看 StoneDB 源码、阅读文档，期待您的贡献！
StoneDB 开源仓库
https://github.com/stoneatom/stonedb
作者李浩
StoneDB 首席架构师、StoneDB PMC
曾在华为、爱奇艺、北大方正从事数据库内核核心架构设计。超过10年数据库内核开发经验，擅长查询引擎，执行引擎，大规模并行处理等技术。拥有数十项数据库发明专利，著有《PostgreSQL查询引擎源码技术探析》。
编辑 &校对：李明康、王学姣、高日耀、
