爆肝整理5000字！HTAP的关键技术有哪些？| StoneDB学术分享会#3-低调大师

爆肝整理5000字！HTAP的关键技术有哪些？| StoneDB学术分享会#3

2022-09-23 478

在最新一届国际数据库顶级会议 ACM SIGMOD 2022 上，来自清华大学的李国良和张超两位老师发表了一篇论文：《HTAP Database: What is New and What is Next》,并做了 《HTAP Database：A Tutorial》 的专项报告。这几期学术分享会的文章，StoneDB将系统地梳理一下两位老师的报告，带读者了解 HTAP 的发展现状和未来趋势。

在深度干货！一篇Paper带您读懂HTAP这期分享中我们已经把HTAP产生的背景和现有的HTAP数据库及其技术栈做了一个简单的介绍，这一期，我们将着重讲一讲报告中对HTAP关键技术的解读。

在正式开始前，先给上期简单收个尾，报告中提到 HTAP 数据库除了以下四种：

Primary Row Store + InMemory Column Store
Distributed Row Store + Column Store Replica
Disk Row Store + Distributed Column Store
Primary Column Store + Delta Row Store

还补充了3种，感兴趣的读者可以自行了解：

Row-based HTAP systems：如 Hyper（Row）、BatchDB等
Column-based HTAP systems：如 Caldera、RateupDB等
Spark-based HTAP systems：如 Splice Machine、Wildfire等

下面进入正文，本篇报告中主要介绍了HTAP的五大类关键技术，分别是：

Transaction Processing（事务处理技术）
Analytical Processing（查询分析技术）
Data Synchronization（数据同步技术）
Query Optimization（查询优化技术）
Resource Scheduling（资源调度技术）

Overview of HTAP Techniques

这些关键技术被最先进的HTAP数据库采用。然而，它们在各种指标上各有利弊，例如效率、可扩展性和数据新鲜度。

An Overview of HTAP Techniques

一、事务处理技术（OLTP）

HTAP数据库中的OLTP工作负载是通过行存储处理的，但不同的架构会导致不同的TP技术。它主要由两种类型组成。

1使用内存增量更新的单机事务处理

Standalone Transaction Processing with In-Memory Delta Update

关键技术点：

通过MVCC协议进行单机事务处理
通过内存增量更新进行insert/delete/update操作

相关数据库：Oracle、SQL Server、SAP HANA 和 StoneDB 等。

Standalone TP for insert/delete/update operations

上面这张图介绍了单机事务处理执行insert/delete/operations操作的一个逻辑过程，总体上是借助MVCC+logging，它依赖于MVCC协议和日志记录技术来处理事务。具体来说，每个插入首先写入日志和行存储，然后附加到内存中的增量存储。更新创建具有新生命周期的行的新版本，即开始时间戳和结束时间戳，即旧版本在删除位图中被标记为删除行。因此，事务处理是高效的，因为 DML 操作是在内存中执行的。请注意，某些方法可能会将数据写入行存储或增量行存储，并且它们可能仅在事务提交时写入日志。

一般有三种方式来实现内存增量存储，分别是：Heaptable(堆表)、Index organized table（索引组织表） 和 L1 cache（一级缓存），具体区别如下表：

Three implementations for an in-memory delta store

三者主要的区别在于插入（insertion）速度、查询（lookup）速度和容量（capacity）大小上。

2使用日志回放的分布式事务处理

Distributed Transaction Processing with Log Replay

关键技术点：

Two-Phase Commit(2PC)`+Paxos 用于分布式TP和数据复制
使用Log replay(日志回放)更新行存储和列存储

3对比

最后我们将提到事务处理技术做一个对比：

Comparisons of TP techniques in HTAP Databases

二、查询分析技术（OLAP）

对于HTAP数据库，OLAP负载使用面向列的技术执行，例如压缩数据上的聚合和单指令多数据 (SIMD) 指令。这里介绍两大类型和三种方式：

1内存增量遍历 + 单机列扫描

Standalone Columnar Scan with In-Memory Delta Traversing

关键技术点：

单指令多数据(SIMD)，向量化处理
内存增量遍历（In-Memory Delta Traversing）相关数据库：Oracle、SQL Server

举几个例子：

在（a）里，我们查询订单表中名称为JASON的花了多少钱，那么基于SIMD的查询方式，是可以通过CPU把数据Load到寄存器中，只需要一个CPU执行的周期，就可以同时去扫描查到满足条件的两个数据。

如果基于传统的火山模型，用的是一种迭代模型，就需要访问四行数据，而基于这种列存的方式，只要访问一次就可以得到结果。

同样的，还可以通过这种方式做基于Bloom Filter的向量化连接，也可以提高查询分析的效率。

在增量表中获取可见值，并跳过删除表中的陈旧数据

除此之外，我们在做列存扫描的同时要去扫描一些可见的增量数据来实现实时数据的分析，也去扫描删除表中是否有过期的数据，最终达到数据是新鲜的。

2日志文件扫描 + 分布式列扫描

Distributed Columnar Scan with Log File Scanning

关键技术点：

列段上的分布式查询处理
基于磁盘的日志文件归并与扫描相关数据库：F1 Lightning

Distributed Columnar Scan

Samwel, Bart, et al. "F1 query: Declarative querying at scale."PVLDB 11(12) , 2018: 1835-1848.

如上图所示的分布式列扫描，传统方法就是基于多个Worker来做并发的多节点下进行算子下推，扫描之后，在上层做一些聚集、HASH、排序等一些操作。

Log File Scanning

Yang, Jiacheng, et al. "F1 Lightning: HTAP as a Service." PVLDB 13(12), 2020: 3313-3325.

与分布式列扫描同时进行的还有日志文件扫描，我们还要基于列存储来做算子下推来查到当前增量存储中最新的数据，再进行数据合并。上图里的F1 Lighting就可以支持把10个小时的数据合并到Delta中。

3技术总结

内存中增量和列扫描

将内存中的增量和列数据一起扫描，因为增量存储可能包括尚未合并到列存储的更新记录。由于它已经扫描了最近可见的delta tuples in内存，因此OLAP的数据新鲜度很高。

基于日志的增量和列扫描

将基于日志的增量数据和列数据一起扫描以获取传入查询。与第一种类似，第二种使用列存储扫描最新的增量用于OLAP。但是，由于读取可能尚未合并的delta文件，这样的过程更加昂贵。因此，数据新鲜度较低，因为发送和合并delta文件的高延迟。

列扫描

只扫描列数据以获得高效率，因为没有读取任何增量数据的开销。但是，当数据在行存储中经常更新时，这种技术会导致新鲜度低。

4对比

Comparisons of AP techniques in HTAP Databases

对于第一种单机列扫描+内存增量遍历来说，优点是数据新鲜度较高，缺点是需要比较多的内存空间。对第二种分布式列扫描+日志文件扫描来说，优点是扩展性高，缺点是效率比较低。

三、数据同步技术（DS）

由于在查询时读取增量数据的成本很高，因此需要定期将增量数据合并到主列存储中。这个时候，数据同步（Data Synchronization）技术，就非常重要了，也是分为两大类型。

1类型一：内存增量合并

关键技术：

基于阈值的合并（Threshold-based merging）
两阶段数据迁移（Two-phase data migration）
基于字典的迁移（Dictionary-based migration）

相关数据库：Oracle、SQL Server、SAP HANA

Threshold-based merging

举个例子，如果阈值达到列存储90%的容量时，我们就把Delta Table中的数据合并到Column Store当中，当然这种方式有个缺点——如果阈值设置的太大可能会导致AP的性能发生抖动，所以看到图里我们加了一个Trick-based，最好是定小量按期地去合并，做一个权衡。

Two-phase data migration

两阶段数据的迁移，可以拿SQL Server举例，如图所示：

第一阶段：迁移准备
- 第（1）步先插入RID去把需要隐藏的数据写入到删除表当中；
- 第（2）步把这些数据分配RID后生成Delta Colunm Store；
第二阶段：迁移操作
- 第（3）步，把刚刚插入进去的RID删除；
- 第（4）步，最后真正把Delta中相关的数据删除，最后才把生成的增量列存合并到主列存中，达到了数据迁移的效果。

Dictionary-based migration

第三种基于字典的迁移，SAP HANA就是采用这种方式。如图所示，它第一阶段主要是针对每一列的数据做一个本地字典的方式映射过去增加对应的数据向量，第二阶段，才会把这个字典加入到全局的字典，做一个全局的排序，最后合并到数据向量当中。

2类型二：基于日志的增量合并

关键技术：LSM-tree 和 B-tree

3技术总结

可归类为有3种数据合并技术。分别是：

内存中增量合并；
基于磁盘的增量合并；
从主行存储重建。

第一个类别定期将新插入的内存中增量数据合并到主列存储。引入了几种技术来优化合并过程，包括两阶段基于事务的数据迁移、字典编码排序合并和基于阈值的变化传播。

第二类将基于磁盘的增量文件合并到主列存储。为了加快合并过程，增量数据可以通过B+树进行索引，因此可以通过键查找有效地定位增量项。

第三类从主行存储重建内存列存储。这对于增量更新超过某个阈值的情况很典型，因此重建列存储比合并这些具有大内存占用的更新更有效。

4对比

Comparisons of DS techniques in HTAP Databases

总体来看，基于内存的增量合并效率比较高，扩展性差点儿；基于日志的合并，扩展性好，但是多重合并的代价会比较高。

四、查询优化技术

HTAP中查询优化技术主要涉及三个维度，包括：

Query Optimization in HTAP databases

1In-Memory Column Selection

解决的问题：要从行存储区中选择哪些列进入内存呢？简单的做法是全部选择进去，但那样存储和更新的代价会很高，所以一般是基于历史的统计信息和现有内存的预算来做权衡选择。
解决方式：有两种，第一种是热力图（Heatmap），第二种是整数规划（Integer programming）

基于Heatmap，比如Oracle

通过访问频度来管理列存并进行热力图的制作。

Oracle 21c. Automating Management of In-Memory Objects., 2021.

如图所示，首先根据最下方持久化行存（Persistent Storage）来选定一些候选列集（Candidate Columns），通过记录候选集的访问频度。有些列就会变为Hot Columns，那么就可以把最新的数据Load进去（图中左下方的Populating）来达到加速查询的效果；慢慢地也有一些列会变为Cold Columns，那么就把这些冷列进行压缩（Compressed Columnar data），然后最后排除（图中右下方的Evicating）到内存当中，再选取其他被高频访问的列重复进行。

基于Integer programming，比如Hyrise

Integer programming for 0/1 Knapsack problem，第一种基于热力图的方式完全没有考虑选择列的代价，那么第二种就是把代价函数（cost-based optimization problem）考虑进去，再从二级存储中选择列。

Boissier, Martin, et al. "Hybrid data layouts for tiered HTAP databases with paretooptimal data placements." ICDE, 2018.

这个目标函数就是要去优化所有的查询代价函数，而每个查询代价函数要去衡量所选择列的代价。总目标是最小化这个代价，要小于这个最大的预算。（这里不展开讲了，感兴趣可以阅读这篇论文，也比较经典）

2Hybrid Row and Column Scan

解决的问题：内存中选择好列之后，如何利用混合行/列扫描加速查询呢？这个比较前沿了，像Google的AlloyDB也支持这个特性。
解决方式：基于规则的计划选择（Rule-based）或者基于代价（Cost-based）的计划选择。主要决定查询优化器要把哪些算子下推到列存引擎当中。

Rule-based Optimization(RBO)

先定义一些扫描的规则，比如先看列扫描，再看行扫描。相关数据库：Oracle、SQL server。

举个例子，上图中我们查找一些北京车子注册的证书和颜色，在这种规则下就可以生成一个逻辑计划树，在这个逻辑计划树里，我们先去查找底层表到底是行存还是列存，如果是列存，就做列存的方式处理，如果是行存就做一个B+树的扫描。最后合并做一个连接再返回最终结果。

Cost-based Optimization(CBO)

基于代价的方式，解决的方式是先去对比列存扫描和行存/索引扫描的代价分别是多少，然后再决定查询算子在哪里执行。

Compare the cost of row/index scan with the cost of columnar scan

3CPU/GPU Acceleration for HTAP

这个基于硬件去做HTAP的加速。比如，基于CPU/GPU异构处理器的方式进行HTAP的处理。相关数据库：RateupDB、Caldera。

CPU/GPU processors for HTAP

Task-parallel nature of CPUs for handling OLTP
- CPU任务并行的特性可以用来处理OLTP
Data-parallel nature of GPUs for handling OLAP
- GPU数据并行的特性可以用来处理OLAP

涉及到一些并行计算的知识，感兴趣可以了解了解~

4技术总结

主要涉及三大技术：

HTAP的列选择；
混合行/列扫描；
HTAP 的 CPU/GPU加速。

第一种类型依靠历史工作负载和统计数据来选择从主存储中提取的频繁访问的列到内存中。因此，可以将查询下推到内存中的列存储以进行加速。缺点是可能没有选择新查询的列，导致基于行的查询处理。现有方法依靠历史工作负载的访问模式来加载热数据并驱逐冷数据。

第二种类型利用混合行/列扫描来加速查询使用这些技术，可以分解复杂的查询以在行存储或列存储上执行，然后组合结果。这对于可以使用基于行的索引扫描和完整的基于列的扫描执行的 SPJ 查询来说是典型的。我们引入了基于成本的方法来选择混合行/列访问路径。

第三种技术利用异构CPU/GPU架构来加速HTAP工作负载。这些技术分别利用CPU的任务并行性和GPU的数据并行性来处理OLTP和OLAP。然而，这些技术有利于高OLAP吞吐量，同时具有低OLTP吞吐量。

5对比

Query Optimization in HTAP databases

五、资源调度技术

对于 HTAP 数据库，资源调度是指为 OLTP 和OLAP 工作负载分配资源。当前可以动态控制OLTP 和 OLAP 工作负载的执行模式，以更好地利用资源。

Resource Scheduling

1基于工作负载驱动的调度

Workload-driven Scheduling for HTAP，就是根据HTAP工作负载的执行性能进行动态的调度，线程和内存这些根据OLTP和OLAP的性能需求动态分配资源。相关数据库: SAP HANA。

Assign more threads to OLTP or OLAP

Psaroudakis, Iraklis, et al. "Task scheduling for highly concurrent analytical and transactional main-memory workloads." In ADMS, 2013.

举个栗子，第一种方式会分配更多的线程给OLTP或者OLAP，怎么分配呢？会在Scheduler里配置一个Watch-dog监测器，来监测当前的Worker，有一些被阻塞的Worker就分配多一些Thread，有一些比较活跃的的，就让它继续执行。

Isolate the workload execution and assign more cache for OLAP

Sirin, Utku, Sandhya Dwarkadas, and Anastasia Ailamaki. "Performance Characterization of HTAP Workloads." In ICDE, 2021.

如表所示，在第三层Cache当中进行一些调度，通过实验可以得知增加OLTP存储资源时，OLAP的颜色是会变深的，这意味着影响越严重，所以还是建议在第三层尽量给OLAP多分配一些资源。

2基于新鲜度驱动的调度

Freshness-driven Scheduling for HTAP

Switches the execution modes {S1, S2, S3}
Default S2; When freshness < threshold, jump to S1 or S3

Raza, Aunn, et al. "Adaptive HTAP through elastic resource scheduling." In SIGMOD, 2020.

3技术总结

调度技术有两种类型，工作负载驱动的方法和新鲜度驱动的方法。前者根据执行工作负载的性能调整OLTP和OLAP任务的并行度。例如，当CPU资源被OLAP线程饱和时，任务调度器可以在增大OLTP线程的同时降低OLAP的并行度。后一个切换了OLTP和OLAP的资源分配和数据交换的执行模式。例如，调度程序单独控制OLTP和OLAP的执行以实现高吞吐量，然后定期同步数据。一旦数据新鲜度变低，它就会切换到共享 CPU、内存和数据的执行模式。其他与 HTAP 相关的技术，还有新的 HTAP 索引技术和横向扩展技术。

4对比

Resource Scheduling in HTAP databases

第一种优点是比较容易实现，但是新鲜度较低；第二种方式优点是新鲜度高，但来回切换容易导致系统震荡。

六、其他相关的HTAP技术

这里不展开介绍了，感兴趣可以看看相关的Paper。

1Multi-Versioned Indexes for HTAP

Parallel Binary Tree (P-Tree)

Sun, Yihan, et al. "On supporting efficient snapshot isolation for hybrid workloads with multiversioned indexes." PVLDB 13(2), 2019.

Multi-Version Partitioned B-Tree (MV-PBT)

Riegger, Christian, et al. "MV-PBT: multi-version indexing for large datasets and HTAP workloads." In EDBT, 2020.

2Adaptive Data Organization for HTAP

H2O [Alagiannis et al, SIGMOD 2014], Casper [Athanassoulis et al, VLDB 2019]
Peloton [Arulraj et al, SIGMOD 2016], Proteus [Abebe et al, SIGMOD 2022]

Abebe, Michael, Horatiu Lazu, and Khuzaima Daudjee. Proteus: Autonomous Adaptive Storage for Mixed Workloads. In SIGMOD, 2022.

责编：宇亭

HTAP的基准测试

下一期我们将介绍针对HTAP基准测试的相关进展，在我们的第二期学术分享会里，也介绍过来自慕尼黑工业大学（TMU）数据库组的研究，感兴趣可以前往查看，这篇文章只是其中一种基准测试的方法，想了解还有哪些方法么？欢迎关注StoneDB公众号，我下期见~

StoneDB 已经正式开源，欢迎关注我们 https://github.com/stoneatom/stonedb

什么是真正的HTAP？（一）背景篇

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

官网：https://stonedb.io/

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

Slack: https://stonedb.slack.com/ssb/redirect#/shared-invite/email

微信关注我们

原文链接：https://my.oschina.net/StoneDB/blog/5579965

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

数据迁移工具chameleon的使用限制

这次介绍另一种也很常用的数据迁移工具chameleon。目录简介使用限制 1.一般性限制 2. 对象迁移限制 3. 在线迁移限制简介 chameleon是一个用Python 3编写的MySQL到openGauss的实时复制工具。工具使用mysql-replication库从MySQL中提取row images，这些row images将以jsonb格式被存储到openGauss中。在openGauss中会执行一个pl/pgsql函数，解码jsonb并将更改重演到openGauss。同时，工具通过一次初始化配置，使用只读模式，将MySQL的全量数据拉取到openGauss，使得该工具提供了初始全量数据的复制以及后续增量数据的实时在线复制功能。使用限制 1.一般性限制根据mysql-replication的要求，Python 3仅支持3.5~3.7。 MySQL列的AUTO_INCREMENT属性，在openGauss侧将通过序列(serial)实现。 detach复制副本进程将重置openGauss中的序列(serial)，以使数据库独立工作。外键约束也会在detach过...

2022-09-23

507

随通信行业不断的业务迭代，新的赛道为业务带来了新变化，生态合作和渠道的规模上量给系统带来了模式创新的同时，也带来了更大的压力。同时，国际站的地域环境和当地政策法规的因素，给全球化的建设也带来了全新的机遇和挑战。本文将探讨云原生时代下的网关技术，面向全球化、平台化、精细化的时代背景，如何在云原生时代挖掘自我蜕变的契机，又如何拖着沉重的技术负债实现涅槃重生，实现高性能、高可用、低成本的架构演进和技术突破，本文结合历年双11顶流下的网关技术实践经验落笔成文，希望对各位读者有所帮助。云通信网关发展新趋势与挑战阿里云通信短信网关是基于领先的通信架构和大规模分布式网关处理技术打造的云原生网关，提供稳定的通信服务能力，具备可冗灾、可恢复、可切换的高可用服务保障能力，实现客户的SLA保障要求，最终实现资源的最大利用和利润的最大化。高性能、高可用、低成本——是趋势，也是挑战。高性能，十万级并发、秒级触达阿里云通信起步于2017年，早期孵化于阿里通信，后与阿里云整合，经过短短几年的发展，目前已经是阿里云上最热门的云服务产品之一。在2019迎来规模化发展，这一年在天猫双11活动当天实现了历史峰...

2022-09-23

502

资源下载

更多资源

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。