CN117321583A

CN117321583A - 用于混合数据处理的存储引擎

Info

Publication number: CN117321583A
Application number: CN202280034911.9A
Authority: CN
Inventors: 陈建军; 丁永华; 刘晔; 李方实; 张力; 张明屹; 魏奎; 丁尉; 吴凯; 孙杨
Original assignee: Lemon Inc Cayman Island
Current assignee: Lemon Inc Cayman Island
Priority date: 2021-08-31
Filing date: 2022-08-02
Publication date: 2023-12-29
Also published as: EP4334824A2; US11789936B2; US20230063730A1; WO2023033721A3; WO2023033721A2

Abstract

本公开描述了用于混合事务性处理和分析处理的存储技术。可以接收由第一处理引擎捕获的数据。该第一处理引擎可以被配置为执行在线事务性处理。基于该数据生成的逻辑日志的多个副本可以通过在该多个副本上应用仲裁协议而被分布到增量存储库。该增量存储库中的数据以行格式被存储，并且对于由第二处理引擎执行的在线分析处理的查询是可见的。可以基于一个或多个预定规则将数据从该增量存储库冲刷到基本存储库。该基本存储库中的数据以列式格式被存储，并且可以由该第二处理引擎访问。

Description

用于混合数据处理的存储引擎

背景技术

数据处理是指对一组数据或数据库执行特定操作的过程。数据库是事实和信息的有组织的集合，诸如关于库存、客户等的记录。存在多种形式的数据处理并且在商业环境中服务于不同的应用程序。随着数据库越来越多地用于存储大量复杂的数据，数据处理和存储方面的改进可能是合乎需要的。

附图说明

当结合附图阅读时，可以更好地理解下面的详细描述。出于说明的目的，在附图中图示了本公开的各个方面的示例实施例；然而，本公开不限于所公开的具体方法和手段。

图1示出了包括云服务的示例系统。

图2示出了包括一个以上云服务的示例系统。

图3示出了用于混合事务性和分析处理的示例系统。

图4示出了用于混合事务性和分析处理的示例存储引擎。

图5示出了示例逻辑日志。

图6示出了增量存储库(Delta Store)的示例数据存储架构。

图7示出了基本存储库(Base Store)的示例数据存储架构。

图8示出了用于混合事务性和分析处理的存储引擎的示例过程。

图9示出了用于混合事务性和分析处理的存储引擎的示例过程。

图10示出了用于混合事务性和分析处理的存储引擎的示例过程。

图11示出了可以用于执行本文公开的任何技术的示例计算设备。

具体实施方式

在线分析处理(OLAP)系统使用户能够从多个角度交互式地分析多维数据。多维数据包括具有三个或更多维度的数据集。OLAP系统允许用户同时分析来自多个数据库系统的信息。OLAP系统使分析师能够从不同的角度提取和查看数据，诸如业务数据。分析师经常需要对数据进行分组、聚合和连接。数据挖掘中的这些OLAP操作是资源密集型的。通过OLAP，可以预先计算和预先聚合数据，从而使分析更快。然而，传统的OLAP系统通常会定期批量加载大量数据。这可能导致OLAP系统遭受陈旧数据的问题。

OLAP通常与OLTP(在线事务处理)系统形成对比。OLTP系统捕获、存储和处理来自事务的数据。OLTP系统的一般特征是较大数量的较不复杂的查询以用于处理事务而不是用于商业智能或报告的目的。传统的OLTP系统能够支持数据操作语言(DML)。DML是一种用于添加(插入)、删除和修改(更新)数据库中的数据的计算机编程语言。传统的OLTP系统也能够高效地支持点查找查询。

OLAP系统与OLTP系统之间存在明显的差异。例如，OLTP系统通常没有大规模并行查询引擎(诸如OLAP系统中存在的那些引擎)来支持对大量数据的高效复杂查询处理。作为另一个示例，OLAP系统主要针对只读进行优化，可能不支持其他类型的查询，而OLTP系统处理所有类型的查询(读取、插入、更新和删除)。作为又一个示例，OLTP系统与短原子事务相关联，而OLAP系统允许更灵活的分布模式和更高的可扩展性，但是具有增加的延迟并且没有保证处理时间的上限。

许多主流数据平台/系统仅关注这些工作负载中的一个(例如，OLAP或OLTP)。然而，许多场景(例如，业务场景)既需要对新导入的数据执行复杂的OLAP式分析，又需要由OLTP系统提供的事务支持和强大的数据一致性两者。传统上，在数据仓库中，数据是从OLTP系统中提取的，然后在提取-转换-加载(ETL)期间转换，并且加载到OLAP系统中。ETL过程在事务与数据对OLAP系统的可见性之间引入了长时间的延迟(例如，几十分钟到几小时)。

混合事务/分析处理(HTAP)系统最适合此类场景。HTAP系统适用于需要对新导入的数据执行复杂的OLAP式分析的业务场景。此外，HTAP系统对于在分析处理中想要事务支持和高数据新鲜度的客户来说是理想的。HTAP系统提供了若干独特的优势。在HTAP系统中，OLAP和OLTP工作负载统一在单个系统中。通过将OLAP和OLTP工作负载整合到单个系统内，部署和维护的复杂性和成本显著降低。此类多功能系统可以显著减少查询结果中的陈旧性(此类陈旧性通常是由从操作数据库到数据仓库的耗时且昂贵的ETL过程引入的)。此类系统还具有用于对实时数据进行复杂分析的能力，从而解决通常需要对必须实时利用的短暂机会做出有效响应的现代商业模式。

然而，许多现有的HTAP系统都有缺点。许多现有的HTAP系统应用离线ETL将数据摄取为列式文件格式。此离线ETL过程往往会遭受OLTP数据与OLAP副本之间的高滞后时间。其他一些HTAP系统在一个系统中维护用于OLTP系统的行格式数据和用于OLAP系统的列式格式数据。然而，此类HTAP系统可能不具有高数据新鲜度或可能不具有在HTAP存储引擎中进行高效分析处理的技术。因此，需要一种解决这些缺点的HTAP系统。

本文描述了一种能够处理具有事务性(OLTP)工作负载和复杂分析性(OLAP)工作负载两者的业务场景的HTAP系统。与现有的HTAP系统不同，本文所描述的HTAP系统利用大规模实时分析架构，该大规模实时分析架构便于新鲜数据改变和强数据一致性。改进的HTAP系统被配置为通过OLTP引擎中的行存储库进行快速DML(数据操作语言)查询处理。改进的HTAP系统进一步被配置为在OLAP引擎中高效地处理复杂OLAP查询的分布式查询处理，包含连接和聚合操作。来自OLTP引擎的数据改变被连续地应用到存储器内的分布式增量存储库，并且改进的HTAP系统允许OLAP引擎立即(或几乎立即)查询最新的OLTP数据改变。

本文所描述的HTAP系统包括存储引擎。存储引擎可以与OLAP引擎和/或OLTP引擎解耦。由于(一个或多个)分离的计算引擎和存储引擎的架构，HTAP存储引擎可以被配置为支持高效的分析处理和高数据新鲜度。高数据新鲜度可能指示来自OLTP数据库中的事务性数据对OLAP数据库立即或几乎立即可见。这里描述的HTAP系统的许多特征有助于高效的分析处理和高数据新鲜度，包含但不限于，并发日志应用于存储器内增量存储库、谓词/聚合下推到存储引擎、用于分析查询处理的高效列式基本存储库、删除过滤的基于成本的优化、使用场地向量的高效存储器管理和垃圾收集、后台冲刷/整理等。

改进的HTAP系统可以具有灵活的模块化设计。系统的主要部件(诸如OLTP查询引擎、OLAP查询引擎和/或底层存储)是模块化的和可解耦的。因此，可以轻松地改变部件，而无需修改整个架构。例如，HTAP存储引擎可以与系统的其他部件解耦并且用不同的存储引擎替换。模块化设计还使每个部件的向外扩展变得更加容易。

多种不同的系统或实体可以利用HTAP系统，诸如上面所描述的改进的HTAP系统。图1图示了包含HTAP系统的示例系统100。系统100可以包括云网络102和多个客户端设备104a-d。云网络102和多个客户端设备104a-d可以经由一个或多个网络120彼此通信。

云网络102可以位于数据中心，诸如单个场所，或分布在不同的地理位置(例如，在若干场所)。云网络102可以经由一个或多个网络120提供(一个或多个)服务。网络120包括多种网络设备，诸如路由器、交换机、多路复用器、集线器、调制解调器、网桥、中继器、防火墙、代理设备等。网络120可以包括物理链路，诸如同轴电缆链路、双绞线电缆链路、光纤链路、它们的组合等。网络120可以包括无线链路，诸如蜂窝链路、卫星链路、Wi-Fi链路等。

云网络102可以包括托管多种服务的多个计算节点118。在实施例中，节点118托管服务112。服务112可以包括内容流服务，诸如互联网协议视频流服务。服务112可以被配置为经由多种传输技术来分布内容。服务112被配置为提供内容，诸如视频、音频、文本数据、其组合等。内容可以包括内容流(例如，视频流、音频流、信息流)、内容文件(例如，视频文件、音频文件、文本文件)和/或其他数据。内容可以存储在数据库中。例如，服务112可以包括视频共享服务、视频托管平台、内容分布平台、协作游戏平台等。除了内容流服务之外，或代替内容流服务，服务112可以包括任何其他类型的服务。

在实施例中，服务112可以经由网络120提供到客户端设备104。如果服务112是内容流服务，则内容可以经由网络120输出到不同的客户端设备104。内容可以流式传输到客户端设备104。内容流可以是从服务112接收到的短视频流。多个客户端设备104可以被配置为访问来自服务112的内容。在实施例中，客户端设备104可以包括应用程序。应用向与客户端设备104相关联的用户输出(例如，显示、渲染、呈现)内容。内容可以包括视频、音频、评论、文本数据等。

在实施例中，用户可以使用客户端设备104上的应用来创建内容并且将短视频上传到云网络102。客户端设备104可以访问应用的接口。该接口可以包括输入元件。例如，输入元件可以被配置为允许用户创建内容。为了创建内容，用户可以给予应用用于访问图像捕获设备(诸如客户端设备104的相机或传声器)的许可。在用户已经创建了内容之后，用户可以使用该应用程序将内容上传到云网络102和/或将内容本地保存到用户设备104。服务112可以将上传的内容和与该内容相关联的任何元数据存储在一个或多个数据库中。

多个客户端设备104可以包括任何类型的计算设备，诸如移动设备、平板设备、膝上型计算机、台式计算机、智能电视或其他智能设备(例如，智能手表、智能扬声器、智能眼镜、智能头盔)、游戏设备、机顶盒、数字流设备、机器人等。多个客户端设备104可以与一个或多个用户相关联。单个用户可以使用多个客户端设备104中的一个或多个来访问云网络102。多个客户端设备104可以行进到多个位置并且使用不同的网络来访问云网络102。

多个计算节点118可以处理与服务112相关联的任务。多个计算节点118可以被实现为一个或多个计算设备、一个或多个处理器、一个或多个虚拟计算实例、其组合等。可以由一个或多个计算设备来实现多个计算节点118。一个或多个计算设备可以包括虚拟化计算实例。虚拟化计算实例可以包括虚拟机，诸如计算机系统、操作系统、服务器等的仿真。可以由计算设备基于虚拟映像和/或定义用于仿真的特定软件(例如，操作系统、专用应用、服务器)的其他数据来加载虚拟机。随着对不同类型的处理服务的需求改变，不同的虚拟机可以在一个或多个计算设备上被加载和/或终止。管理程序可以被实现为管理同一计算设备上不同虚拟机的使用。

在实施例中，服务112包括HTAP系统110。HTAP系统110可以包括多个不同的部件(例如，子系统)。例如，HTAP系统110可以包括事务性OLTP引擎、分析性OLAP引擎、底层解耦存储、元数据服务和/或智能代理中的一者或多者。

HTAP系统110可以具有支持异构查询引擎的架构。该架构可以具有处理事务性型OLTP工作负载和复杂分析(OLAP)工作负载两者的能力。该架构可以遵循模块化设计并且其主要部件可以完全解耦，从而提供灵活性并且易于向外扩展。例如，HTAP系统110的部件可以容易地改变成类似的已建立的子系统。该架构可以通过具有单独的查询处理引擎和不同的数据副本来消除OLTP与OLAP工作负载之间的干扰。

HTAP系统110可以针对OLTP引擎和OLAP引擎以不同的格式保存用户数据。例如，在存储子系统中，HTAP系统110可以针对OLTP引擎以行格式保存用户数据，并且针对OLAP引擎以列式格式保存用户数据，以进行高效的查询处理。该架构可以具有元数据的单点真实性，并且可以使用独立的元数据服务来向HTAP系统110的某些部件提供最新的元数据。HTAP系统110的架构可以包含智能代理，该智能代理基于查询的性质将查询分派到OLTP和OLAP子系统(因此可以向用户/客户端隐藏内部细节)。用户/客户端能够利用具有单个统一接口的HTAP系统110。例如，用户/客户端可能能够利用具有客户端设备104的接口的HTAP系统110。该架构可以基于用户需求支持各个API(例如，ANSI SQL、JDBC、ODBC等)。

HTAP系统110的架构能够处理大规模的数据。这是HTAP系统110中的计算和存储部件可以被解耦的事实的结果。因为不假设数据将能够适合存储器，所以利用能够持久保存大量数据的可解耦存储系统。HTAP系统110中的计算资源和存储资源也可以向外扩展并且因此能够灵活地处理大量数据和大规模(OLTP和OLAP)工作负载。

HTAP系统110的架构能够进行有效且实时的数据处理。DML查询可以由OLTP引擎有效地处理，并且以行格式被有效地写入底层存储。HTAP系统110的架构可以包含OLAP查询引擎，该OLAP查询引擎具有分布式查询处理的能力(高并行性、更好的资源利用)以有效地处理复杂的OLAP查询，包含连接、聚合等。由于HTAP系统110的架构便于在OLTP侧和OLAP侧两者存储不同的数据副本，因此OLTP工作负载与OLAP工作负载之间的干扰被最小化的事实使得有效且实时的处理成为可能。OLTP和OLAP数据格式可以单独优化以适应其工作负载。可以存在通过HTAP系统110(来自OLTP侧)的单个数据改变源，从而简化了跨OLTP和OLAP部件的一致性模型和并发处理。

HTAP系统110的架构可以为OLAP查询提供新鲜/实时的数据改变。DML的逻辑日志可以在提交时立即从OLTP部件传播到OLAP部件。这些日志可以被分派到分布式分区，并且可以经由通常非常快的存储器内操作被连续地应用到存储器内增量存储库。由逻辑日志携载的数据改变在被应用于存储器内增量存储库时可以立即用于OLAP查询。HTAP系统110的架构利用了跨HTAP系统110的统一版本控制，使得保证了强大的数据一致性。与大多数事务性OLTP数据库引擎一样，HTAP系统110的OLTP部件可以支持快照隔离和其他(较弱的)一致性模型。

尽管图1的系统100将HTAP系统110示为由单个云网络102提供，但是HTAP系统110的各个部件/子系统可以替代地由多个不同的云网络提供。图2图示了包含具有跨多个云网络的部件/子系统的HTAP系统的示例系统200。系统200可以包括云网络202a-b和多个客户端设备204a-d。云网络202a-b和多个客户端设备204a-d可以经由一个或多个网络220彼此通信。

云网络202a-b中的每一个可以类似于上面图1中描述的云网络102。云网络202a-b中的每一个可以位于数据中心处，诸如单个场所，或分布在不同的地理位置(例如，在若干场所处)。云网络202a-b可以经由一个或多个网络220提供(一个或多个)服务。云网络202a-b包括多种网络设备，诸如路由器、交换机、多路复用器、集线器、调制解调器、网桥、中继器、防火墙、代理设备等。云网络202a-b可以包括物理链路，诸如同轴电缆链路、双绞线电缆链路、光纤链路、其组合等。云网络202a-b可以包括无线链路，诸如蜂窝链路、卫星链路、Wi-Fi链路等。

云网络202a-b中的每一个可以包括托管多种服务的多个计算节点。在一个实施例中，与云网络202a相关联的节点托管服务212a，并且与云网络202b相关联的节点托管服务212b。服务212a-b可以包括任何类型的服务，诸如上面参考图1描述的内容流服务。

多个客户端设备204可以包括任何类型的计算设备，诸如移动设备、平板设备、膝上型计算机、台式计算机、智能电视或其他智能设备(例如，智能手表、智能扬声器、智能眼镜、智能头盔)、游戏设备、机顶盒、数字流设备、机器人等。多个客户端设备104可以与一个或多个用户相关联。单个用户可以使用多个客户端设备104中的一个或多个来访问云网络202a-b中的至少一个。多个客户端设备104可以行进到多个位置，并且使用不同的网络来访问云网络202a-b。

在实施例中，服务212a-b中的每个服务包括HTAP系统(例如，HTAP系统110)的一个或多个部件/子系统。HTAP系统110可以包括多个不同的部件(例如，子系统)。例如，HTAP系统可以包括事务性OLTP引擎、分析性OLAP引擎、底层解耦存储、元数据服务和/或智能代理中的一者或多者。服务212a可以包括HTAP系统的一个或多个(但不是全部)部件。服务212b可以包括HTAP系统的其余部件。尽管图2中示出了两个云网络及其相应的服务，但是应理解的是，可以利用任何数量的云网络/服务来实现本文所描述的HTAP系统。

图3示出了根据本公开的用于HTAP系统(例如，HTAP系统110)的示例性架构300。架构300包括多个不同的部件(例如，子系统)。子系统包含OLTP引擎303、OLAP引擎305、数据存储系统306、元数据服务304和/或代理302。

OLTP引擎303可以诸如从用户设备301a-n接收用户数据。OLTP引擎303可以利用将计算引擎与底层共享/云存储分离的模型。OLTP引擎303可以提供诸如ACID事务性支持、行存储、预写日志(WAL)和日志复制的功能。例如，OLTP引擎303可以实时或接近实时地捕获用户数据。OLTP引擎303可以包括数据仓库。数据仓库可以存储由OLTP引擎303捕获的数据。

OLTP引擎303可以被配置为以特定格式(例如，基于行的格式)处理至少一些接收到的用户数据。例如，在接收到OLTP查询时，OLTP引擎303可以被配置为响应于该查询来处理至少一些接收到的用户数据。作为示例而非限制，OLTP查询可以包含检索特定数据项的查询、过滤接收到的数据以寻找特定数据项/数据项描述的查询、和/或过滤接收到的数据以识别接收到的数据的特定子集的查询。例如，查询可以是DML查询和/或点查找查询。

OLTP引擎303可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果OLTP引擎303与较大的HTAP系统400解耦，则OLTP引擎303可以用替代的OLTP引擎(例如，类似的已建立的OLTP引擎)替换。例如，OLTP引擎303可以是MySQL，但是它可以容易地交换到任何其他已建立的OLTP引擎，诸如PostgreSQL。

用户设备301a-n可以包括任何类型的计算设备，诸如移动设备、平板设备、膝上型计算机、台式计算机、智能电视或其他智能设备(例如，智能手表、智能扬声器、智能眼镜、智能头盔)、游戏设备、机顶盒、数字流设备、机器人等。用户设备301a-n可以与一个或多个用户相关联。单个用户可以使用一个或多个用户设备401a-n来访问包括OLTP引擎303的云网络。用户设备301a-n可以行进到多个位置并且使用不同的网络来访问包括OLTP引擎303的云网络。

OLAP引擎305可以访问由OLTP引擎(诸如OLTP引擎303)捕获的数据。OLAP引擎405访问的数据可以是OLAP引擎305可读的特定格式(例如，混合行+列格式)。OLAP引擎305可以响应于接收OLAP查询而对特定格式的数据的至少一部分执行分析。

例如，OLAP引擎305可以对数据的至少一部分执行分析操作。OLAP由三个基本的分析操作组成：合并(上滚)、向下钻取以及切片和切块。合并涉及可以在一个或多个维度上累积和计算的数据的聚合。例如，所有销售办公室都汇总到销售部门或销售分部，以预测销售趋势。相比之下，向下钻取是一种允许用户浏览细节的技术。例如，用户可以按构成某一地区销售额的单个产品来查看销售额。切片和切块是由此用户可以从中取出(切片)OLAP立方体的特定数据集并且从不同的角度查看(切块)切片的特征。这些视点有时被称为维度(诸如按销售人员、按日期、按客户、按产品、按地区等查看相同的销售额)。处理的结果可以被发送或转发到客户端设备301a-n。

OLAP引擎305可以是能够有效地处理复杂分析查询的任何OLAP引擎，诸如已建立的开源查询引擎(例如，FlinkSQL)。OLAP引擎305可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果OLAP引擎305与较大的HTAP系统300解耦，则OLAP引擎305可以用替代的OLAP引擎(例如，类似的已建立的OLAP引擎)替换。例如，OLAP引擎305可以是FlinkSQL，但是它可以容易地交换到任何其他已建立的OLAP引擎，诸如Presto或SparkSQL。

存储子系统306可以与OLTP引擎303和OLAP引擎305解耦。数据存储系统306可以以一种格式(例如，行格式)持久保存用户数据以供OLTP引擎(诸如，OLTP引擎303)使用，同时以不同的格式(例如，混合行+列格式)持久保存相同的用户数据以供OLAP引擎(诸如，OLAP引擎305)使用。这可以显著减少OLAP与OLTP工作负载之间的干扰。如图3中示出的，存储子系统306可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果存储子系统306与较大的HTAP系统300解耦，则存储子系统306可以用替代存储子系统(例如，类似的已建立的存储子系统)替换。将在下面参考图4更详细地讨论存储子系统306的架构。

元数据服务304可以被配置为对准OLTP引擎303和OLAP引擎305的元数据。元数据服务404可以从由某些资源(例如，通过OLTP引擎303的用户输入)生成的事件(例如，DDL)中提取元数据，生成元数据版本并且将它们与DML的顺序对准，使它们全局可用并且持久保存它们。元数据服务304可以为高可用性生成元数据版本的副本。元数据服务304可以从OLTP引擎接收到的DDL中提取元数据(具有与用于DML的相同LSN系统一致的版本)，该元数据持久保存到专用数据库中，并且由FlinkSQL和AP存储服务器推送/拉取。

元数据服务304可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果元数据服务304与较大的HTAP系统300解耦，则元数据服务304可以用替代元数据服务(例如，类似的已建立的元数据服务)来替换。

代理302可以被配置为通过公共代理层将用户设备301a-n连接到OLTP引擎303和/或OLAP引擎305。代理302可以是智能代理。代理302可以向用户/客户端提供单个统一的API(默认：ANSLSQL加上一些通用的OLAP扩展)，即，如果客户端通过代理连接，则底层系统细节对客户端是透明的。基于用户需求，可以利用各种类型的API(例如，ANSI SQL、JDBC、ODBC等)。利用单个统一的API可以减少用户利用系统的工作量。因为OLTP引擎303和OLAP引擎305各自维护数据的完整副本，所以DML/批量装载和查询两者都针对整个HTAP系统300进行操作。代理302可以具有基于请求的性质自动地将不同的客户端请求/查询分派到不同的引擎(例如，OLTP引擎303或OLAP引擎305)的能力。例如，复杂的OLAP查询将被导向OLAP引擎305，而DML、DDL和点查找查询将被导向OLTP引擎303。

代理302可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果代理302与较大的HTAP系统300解耦，则代理302可以用替代的公共代理(例如，类似的已建立的代理)来替换。

HTAP系统(例如，HTAP系统110)可以包括数据存储部件。图4更详细地示出了图3的存储系统306。在数据存储系统306中，通过设计具有多个副本的分布式存储器内增量存储库和在多个副本上应用仲裁协议的高效日志分布器来实现高数据新鲜度。

数据存储系统306可以以一种格式(例如，行格式)持久保存用户数据以供OLTP引擎使用，同时以不同的格式(例如，混合的行+列格式)持久保存相同的用户数据以供OLAP引擎使用。这可以显著减少OLAP与OLTP工作负载之间的干扰。为了高可用性，可以为两种数据格式保存多个数据副本(例如，三个数据副本)。

数据存储系统306可以用作统一的存储层。然而，数据存储系统306的架构可以划分成两部分：TP部分和AP部分。OLTP引擎接收到的事务性DML和DDL可以被呈现为日志存储402中的物理/重做日志(具有底层存储的信息)和逻辑日志。这些日志可以持久保存在存储的TP部分中。下面参考图5更详细地讨论示例性逻辑日志。

然后，物理日志可以被日志分布器404复制和分布到其他存储设备，并且被重放以构建数据页面。例如，日志分布器404可以将预写日志(WAL)分布到共享存储中的行存储406。页面中的数据可以按行格式组织，并且被存储在行数据存储406中。OLTP引擎可以将存储在行数据存储406中的数据用于包含点查找查询的简单查询。

逻辑日志也可以由日志分布器404复制并且分布到存储的AP部分，诸如分布到每个分区407。存储的AP部分中的每个用户表可以基于在表创建时定义的分区方案来分区。每个分区407可以驻留在物理存储节点(例如，服务器)中，并且为了高可用性，可以在每个分区中维护数据的若干副本。每个分区407可以进一步划分成存储器内增量存储库408和盘上基本存储库410。用于提交的DML事务的逻辑日志(诸如MySQL二进制日志)可以从OLTP引擎连续地分派到每个AP存储节点上的用户表分区。作为示例，更新可以用插入之后的删除来建模。因此，在逻辑日志中，可能仅插入和删除，而没有更新。

到达每个AP存储节点的逻辑日志可以被分类、持久保存，然后按顺序应用到每个分区407的存储器内增量存储库408中。一旦逻辑日志到达，它们可以被按顺序应用到存储器内增量存储库408中。OLTP引擎内部数据改变的时间与数据改变出现在增量存储库内部的时间之间的延迟几乎不存在(例如，在大多数情况下小于几百毫秒)。增量存储库408可以按照日志序列号(LSN，指示数据操作顺序的序列号/版本)排序的行格式存储数据。增量存储库408内部的数据可以定期冲刷到基本存储库410，例如，当其大小增长超过某个预定义的阈值时或在某个固定的时间间隔之后。在冲刷之后，被冲刷的数据占用的存储器可以被垃圾箱收集。

基本存储库410中的数据可以以列式格式被组织，以获得更好的分析工作负载性能，并且持久保存/存储在本地文件系统中。每个分区407可以存储在单独的目录中，并且用于不同列的数据可以存储在不同的文件中。在每个数据文件中，数据按主键(一列或多列)分类。此外，数据块可以周期性地与后台任务中的整理程序合并。

基本存储库410中的数据可能无法就地更新，因此可以维护标记已删除的行的删除位图。因为数据块一旦生成就不被修改，所以键值(KV)系统可以用于存储删除位图，该删除位图包含关于在从增量存储库408冲刷之后从基本存储库410移除的行的信息。

随着越来越多的删除和重叠冲刷的数据单元，压缩和重新布置内部的数据可以有益于存储和潜在的查询性能，因此可以定期压缩AP数据单元和清理冗余数据。基本存储库410中的文件可以被版本化，这是文件被冲刷时文件中最大的LSN。LSN可以不保存在基本存储库410中，这可能导致基本存储库410中的所有文件具有相同的版本(即，最后冲刷的LSN)。这可以提供许多优点。例如，它可以节省存储空间，通过使用删除位图来使删除更高效，并且在不需要与LSN进行比较的情况下使扫描更快。然而，不将LSN保存在基本存储库410中可能意味着用户将不能从增量存储库408中查询比最近冲刷的版本更旧的版本。在一些实施例中，针对数据的LSN可以被保存在基本存储库410中，以便支持时间行进查询(在存储和扫描性能上有一些成本)。

图5图示了示例性逻辑日志500。为了保存自上次存储空间备份以来的事务和数据库服务器改变的历史记录，数据库服务器可以生成日志记录。数据库服务器可以将日志记录存储在逻辑日志中，逻辑日志是由三个或更多个逻辑日志文件组成的循环文件。日志之所以称为逻辑日志，是因为日志记录表示数据库服务器的逻辑操作，而不是物理操作。

如上所讨论的，OLTP引擎接收到的事务性DML和DDL可以在日志存储(例如，日志存储302)中呈现为物理/重做日志(具有底层存储的信息)和逻辑日志，诸如逻辑日志500。除了其他数据之外，逻辑日志500还包括指示分区键的数据、表、指示一个或多个操作的数据以及指示主键的数据。例如，在列502中，存储了指示分区键的数据。在列504中，存储指示表的数据。在列506中，存储了指示一个或多个操作的数据。在列506中，存储了指示主键的数据。一个或多个操作可以包含任何操作，包含但不限于删除、插入或DDL。

逻辑日志(诸如逻辑日志500)可以由日志分布器(例如，日志分布器404)复制并且分布到存储系统(例如，存储系统306)的AP部分，诸如分布到每个分区(例如，(一个或多个)分区407)。存储的AP部分中的每个用户表可以基于在表创建时定义的分区方案来分区。每个分区可以驻留在物理存储节点(例如，服务器)中，并且为了高可用性，可以在每个分区中维护数据的若干副本。每个分区可以被进一步分成存储器内增量存储库(例如，存储器内增量存储库408)和基于盘的存储(例如，基于盘的存储410)。用于提交的DML事务的逻辑日志(诸如MySQL二进制日志)可以从OLTP引擎连续地分派到每个AP存储节点上的用户表分区。作为示例，更新可以用插入之后的删除来建模。因此，在逻辑日志中，可能仅插入和删除，而没有更新。到达每个AP存储节点的逻辑日志(诸如逻辑日志500)可以被分类、持久保存，然后按顺序应用到每个分区的存储器内增量存储库中。

图6图示了增量存储库的示例性数据结构600。如上所讨论的，每个分区的每个表都存在一个存储器内增量存储库。每个数据结构600包含由LSN分类的两个单独的变量列表：插入变量列表602和删除变量列表604。为了加速对删除变量列表604的搜索(对插入变量列表602和基本存储库的扫描两者都需要检查删除变量列表604中的删除是否删除了行)，在删除变量列表604上使用散列映射606(主键，LSN列表)来快速查找删除(用于删除检查的O(1)的成本)。

更新操作可以由删除操作替换，然后是插入操作，即删除具有旧数据的行，并且插入具有新数据的行。这简化了HTAP存储引擎，使其只处理插入和删除。增量存储库数据仅由日志分布器生成。每个日志分布器将日志批量应用到增量存储库，以提高效率和数据新鲜度。为了处理逻辑日志条目(如果它是插入日志)，可以将日志解析为元组，并且可以将元组附加在插入列表的末尾。如果是删除日志，为了处理逻辑日志条目，可以将日志解析成元组，可以将主键元组附加在删除列表的末尾，然后可以将<主键，LSN列表>插入到删除映射中。

由于增量存储库完全在存储器中，因此后台冲刷任务将定期将行冲刷到盘以使存储器可用。当有足够的行可用时(例如，行数>60K或累积数据的大小超过32MB)和/或自上次冲刷后经过了足够长的时间时(例如，1小时或任何其他预定时间段)，可能发生此情况。为了不阻止查询执行，被冲刷的行可以在增量存储库中保存一段时间并且当所有现有的读取(包含查询和后台整理操作)已经超过冲刷点完成时，那些被冲刷的行将被截断。

因此，增量存储库上的查询扫描、整理和垃圾收集(GC)操作的并发冲刷是允许的。为了处理存储节点中的所有分区，我们可以在不同的分区上并行使用多个线程进行冲刷。长时间运行的查询可能会阻止冲刷。如果增量存储库变得太大，我们可以取消此类查询并且将查询重新调度到DML很少的时隙。对于增量存储库上的日志应用、冲刷、GC和扫描的并发执行，安全的解决方案可以是对增量存储库的数据结构应用读/写锁。无锁数据结构以及比较和交换(CAS)的原子指令也可以提高并发性。

为了高效地管理存储器中的增量存储库，场地的向量可以用于增量存储库的存储器管理。每个增量存储库最初有一个具有可配置起始大小(例如，4096字节)的场地。如果增量存储库用完了当前场地中的存储器，则可以分配双倍大小的新场地并且将该双倍大小的新场地添加到向量中。每个场地都与作为此场地中保存的最后一行的LSN的LSN相关联。在增量存储库GC期间，我们释放与比GCLSN更小的LSN相关联的那些场地。

增量存储库对于HTAP系统中的高数据新鲜度至关重要。删除时的散列映射606，将行格式数据冲刷为列格式，以及日志应用、冲刷和扫描操作的并发性便于高效的分析处理。使用场地进行存储器管理有助于提高数据新鲜度和高效分析处理两者。

图7图示了基本存储库中的表702的示例性数据布局700。当数据从增量存储库被冲刷到基本存储库时，数据以列式格式被存储，并且基于分区键被分区为多个分区704a-c以用于高效查询OLAP工作负载。每个HTAP存储节点可以包含多个分区，但每个分区只能属于一个存储节点。基本存储库数据与其关联的增量存储库位于同一位置，以实现高效的冲刷和扫描操作。数据以PAX格式被存储在每个存储节点的本地文件系统中。每个表由其分区键进行分区，并且每个分区可以具有多个数据块706a-c。在每个数据块中，每个列710a-b、714a-b被保存在文件中，并且存在包含此数据块的所有列的元数据的元数据文件708、712。元数据可以具有数据块中的行数、每列的最小/最大/总和值和空位图等。每个数据块内的数据按主键排序。

KV系统可以用于存储已删除的位图，该已删除的位图包含关于在从增量存储库中冲刷之后从基本存储库中移除的行的信息。这允许列存储数据文件一旦写入盘就不可改变。KV系统提供了一种快速、可靠且简单的方法来插入和查找特定键或一系列键上的删除，而无需使用太多存储器空间。在实施例中，一个KV条目可以用于存储用于每个数据块的位图。在其他实施例中，可以使用一个以上的KV条目来存储用于每个数据块的位图。对于每个条目，我们使用数据块的块ID(更特别地，编码的主键列文件的逻辑ID)作为键，并且位图(字节)作为值。

示例操作包含但不限于插入删除和带删除的扫描。插入删除操作可以搜索具有删除键的块，使用块ID来获取位图。可以在块中搜索删除键的序号偏移量并且可以相应地更新位图。带删除的扫描操作可以基于输入的键范围和基于结果数据在块中的偏移范围来对每个块执行正常扫描。位图段可以从整个删除位图中取出并且应用于结果。为了支持高效扫描和数据压缩以减少存储使用，每列中的数据可以被划分成数据块706a-c(压缩单元)。数据块中的数据可以被压缩并且保存在其列文件中。为了高效地搜索主键，可以使用用于主键的布隆过滤器。如果主键包括多个列，则可能有额外的列文件来保存复合主键以提高扫描效率。

具有高效数据编码和压缩的基本存储库的列式格式便于高效的分析处理。删除位图的设计对于高数据新鲜度和高效的分析处理两者也是至关重要的。

在实施例中，为了提高扫描性能并且减少存储使用，可以在后台任务中对基本存储库应用整理操作。由于分区内的数据块可能具有重叠的主键范围，因此查询可能需要检查许多块，这会显著降低查询处理速度。此外，在删除位图中标记的数据文件中已删除的行可能被永久删除。这不仅会减小基本存储库的大小，还会提高查询处理的效率。为了实现上述两个目标，基本存储库执行后台整理过程来合并分区内的块。基本存储库上的整理操作提高了扫描性能并且减少了存储使用。整理操作不会阻止诸如日志应用、冲刷、GC和扫描等的其他操作。

为了使扫描和整理过程并行工作，在扫描开始时(每个扫描用读取_LSN标记)，基本存储库可以生成/获取它读取的所有可见数据块的快照，该快照可以是这些块的块ID的列表。对于整理操作，旧块可以在整理完成点被改变为不可见并且还可以用允许_截断_LSN来标记，这是在整理完成点所有活动扫描的最大读取_LSN(最大_读取_LSN)。在读取_LSN<＝允许_截断_LSN完成的所有活动扫描之后，可以移除GC线程中的那些旧块。

用于整理过程的基本算法可以包括以下步骤。在整理开始点，可以基于策略(例如，删除位图、键重叠、数据块大小、IO预算等)来选择用于整理的数据块。可以合并选择的数据块并且可以生成新的数据块(一个或多个)。后台合并不会阻止并发扫描。

接下来，可能需要更新元数据以使新合并的块变得可见(诸如对于OLAP引擎)。此时间可以被称为整理完成点。对于此操作可能需要元数据锁定。在整理完成点之后开始的扫描可能能够从更新的元数据文件中看到新的块。由于主动扫描需要在整理完成点能够完成扫描旧数据块之前开始，所以可以防止在所有这些扫描完成之前删除旧数据块。因此，旧的数据块可以被组织/存储在具有在整理完成点处的当前最大_读取_LSN的标签(版本)的删除集中。如果与旧数据块相关联的(一个或多个)标签小于所有活动扫描的当前最小读取_LSN，则后台GC可以删除删除集中的旧数据块。

为了扫描存储引擎中的数据，HTAP系统(具有(一个或多个)分离的计算引擎和存储引擎)利用扫描操作。扫描操作对我们的HTAP存储引擎的扫描进行了多种优化，例如异步RPC调用、使用扫描线程池的并行扫描、谓词下推、聚合下推、基于成本的删除过滤优化、大数据量的连续扫描以及分区修剪等。这些技术可以各自，单独或组合地，有助于高效的分析处理。

扫描操作是通过来自计算引擎的远程程序调用(RPC)来扫描存储引擎中的数据。多个扫描操作可以由扫描线程池中的线程并行执行。表扫描可以被分割并且分布到HTAP存储引擎中的表的分区中的多个并行扫描。分区中扫描操作的执行可以是异步的，并且当扫描完成时可以调用回调函数来发回结果。下面可能是扫描操作的API：HTAP_扫描(扫描_id，表_id，分区_id，谓词列表，投影列表，读取_LSN，结果，回调_函数)；

在扫描HTAP存储中的数据块时，可以应用谓词过滤器和所需列的投影。如果查询具有聚合操作符，则它的部分聚合可以下推到HTAP存储的扫描。存储节点中的本地部分聚合可能会大大减少扫描的结果数据。谓词和聚合下推的设计对于具有分离的计算和存储引擎的HTAP系统的性能至关重要。

此外，可能需要检查删除位图以排除已删除的行。基本存储库扫描的结果可能还需要通过基于行的主键查找删除散列表来排除增量存储库中已删除的行。有几种合适的策略来过滤掉已删除的数据。一种此类策略是针对每一行扫描的数据搜索删除散列表。另一个此类策略是组合删除位图和增量存储库中的删除以用于扫描基本存储库数据。这两种解决方案对于不同的工作负载具有不同的成本(例如，增量存储库中的删除次数和基本存储库的数据大小可能会影响成本)。基于成本的优化可以用于选择何时过滤掉增量存储库中的删除(如果增量存储库中有删除)。

一次RPC调用可能无法完成扫描。例如，每个RPC可能有行限制，如果扫描量很大，则必须批量返回扫描结果。为了处理此连续扫描要求，连续扫描框架可以被配置为在计算和存储分离的HTAP系统中处理具有大数据大小的扫描操作。存储引擎可以用增量存储库和基本存储库的快照上的迭代器实例来保存扫描状态，并且调用nextBatch()函数来返回下一批数据。例如，存储引擎可以保存<扫描ID，迭代器实例>的映射。当计算引擎发起新的扫描请求时，存储引擎可以分配新的扫描ID，创建迭代器实例，并且返回扫描ID作为响应的一部分。对于连续扫描请求，存储引擎可以使用计算引擎给出的扫描ID来定位当前迭代器实例并且从那里继续。

我们的OLAP引擎的优化器可以支持分区修剪。基于此优化，我们的HTAP存储引擎可能只扫描那些没有被优化器修剪掉的分区。它可能不会提高单个查询的性能；但是，当多个查询同时运行时，它可能会提高吞吐量和QPS(每秒查询数)。

图8图示了可以由HTAP系统的存储引擎(例如图4中图示的存储子系统306)执行的示例过程800。存储引擎可以执行过程800，以便以能够被OLTP子系统和OLAP子系统利用的方式接收和/或组织用户数据。尽管在图8中被描绘为操作序列，但是本领域普通技术人员应理解的是，各种实施例可以添加、删除、重新排序或修改所描绘的操作。

在802处，可以接收由第一计算系统(诸如实时地或接近实时地)捕获的数据。第一计算系统可以是例如OLTP引擎(例如OLTP引擎303)。由于OLTP工作负载本质上使用基于行的数据格式性能更好，而OLAP工作负载更喜欢列式数据格式，因此对两种工作负载使用一种格式意味着HTAP系统的性能会受到影响。

为了防止此性能损失，对于OLTP引擎和OLAP引擎可能以不同的格式存储用户数据。例如，用户数据对于OLTP引擎可以以第一格式(例如，以行格式)被保存，并且对于OLAP引擎可以以第二格式(例如，列式格式)被保存，以进行高效的查询处理。存储子系统可以包括多个分区。每个分区可以包括增量存储库和对应的基本存储库。例如，每个分区可以进一步划分成存储器内的增量存储库和盘上基本存储库。

在804处，可以通过在基于数据生成的逻辑日志的多个副本上应用仲裁协议，将多个副本分布到增量存储库。增量存储库可以按照日志序列号(LSN，指示数据操作顺序的序列号/版本)排序的行格式存储数据。每个用户表可以基于表创建时定义的分区方案进行分区。每个分区可以驻留在物理存储节点(例如，服务器)中并且为了高可用性，可以维护数据的若干副本。用于提交的DML事务的逻辑日志(诸如MySQL二进制日志)可以从OLTP引擎连续地分派到每个AP存储节点上的用户表分区。作为示例，更新可以用插入之后的删除来建模。因此，在逻辑日志中，可能仅插入和删除，而没有更新。

到达每个AP存储节点的逻辑日志可以被分类、持久保存，然后按顺序应用到每个分区的存储器内增量存储库中。增量存储库中的数据对于由第二处理引擎执行的在线分析处理(OLAP)的查询可以是可见的。逻辑日志的多个副本可以例如由日志分布器(例如，日志分布器404)来分布。

增量存储库内部的数据可以被冲刷到对应的基本存储库。在806处，可以基于一个或多个预定规则将数据从增量存储库冲刷到对应的基本存储库。例如，当数据的大小(例如，行数)增长超过某个预定义的阈值和/或在某个固定的时间间隔之后，数据可以从增量存储库冲刷到基本存储库。基本存储库中的数据可以以列式格式被存储，并且可以由OLAP引擎访问。可以基于分区键将基本存储库中的数据划分成多个分区。基本存储库中的每一个分区可以包括多个数据块，并且多个数据块的中的每个数据块中的数据可以被压缩。在冲刷之后，被冲刷的数据占用的存储器可以被垃圾箱收集。

基本存储库中的数据可能无法就地更新，因此可以维护标记已删除的行的删除位图。随着越来越多的删除和重叠冲刷的数据单元，压缩和重新布置内部的数据可以有益于存储和潜在的查询性能，因此可以定期压缩AP数据单元和清理冗余数据。基本存储库中的文件可以被版本化，这是文件被冲刷时文件中最大的LSN。LSN可以不保存在基本存储库中，这可能导致基本存储库410中的所有文件具有相同的版本(即，最后冲刷的LSN)。这可以提供许多优点。例如，它可以节省存储空间，通过使用删除位图使删除更高效，并且在不需要与LSN进行比较的情况下使扫描更快。

图9图示了可以由HTAP系统的存储引擎(例如图4中图示的存储子系统306)执行的示例过程900。HTA系统的存储引擎可以执行过程900以便以能够被OLTP子系统和OLAP子系统利用的方式接收和/或组织用户数据。尽管在图9中被描绘为操作序列，但是本领域普通技术人员应理解的是，各个实施例可以添加、移除、重新排序或修改所描绘的操作。

在902处，可以接收由第一计算系统(诸如实时地或接近实时地)捕获的数据。第一计算系统可以是例如OLTP引擎(例如OLTP引擎303)。由于OLTP工作负载本质上使用基于行的数据格式性能更好，而OLAP工作负载更喜欢列式数据格式，因此对两种工作负载使用一种格式意味着HTAP系统的性能会受到影响。

为了防止此性能损失，对于OLTP引擎和OLAP引擎可能以不同的格式存储用户数据。例如，用户数据对于OLTP引擎可以以第一格式(例如，以行格式)保存，并且对于OLAP引擎可以以第二格式(例如，列式格式)保存，以进行高效的查询处理。存储子系统可以包括多个分区。每个分区可以包括增量存储库和对应的基本存储库。例如，每个分区可以进一步划分成存储器内的增量存储库和盘上基本存储库。

在904处，可以通过在基于数据生成的逻辑日志的多个副本上应用仲裁协议，将多个副本分布到增量存储库。增量存储库可以按照日志序列号(LSN，指示数据操作顺序的序列号/版本)排序的行格式存储数据。每个用户表可以基于表创建时定义的分区方案进行分区。每个分区可以驻留在物理存储节点(例如，服务器)中，并且为了高可用性，可以维护数据的若干副本。用于提交的DML事务的逻辑日志(诸如MySQL二进制日志)可以从OLTP引擎连续地分派到每个AP存储节点上的用户表分区。增量存储库中的数据对于由第二处理引擎执行的在线分析处理(OLAP)的查询可以是可见的。逻辑日志的多个副本可以例如由日志分布器(例如，日志分布器404)来分布。

在906处，可以通过执行删除操作和插入操作来更新增量存储库中的数据。例如，更新操作可以用插入操作之后的删除操作来建模。因此，在逻辑日志中，可能仅插入和删除，而没有更新。

为了高效地管理存储器中的增量存储库，可以利用场地向量。在908处，可以使用场地向量来管理增量存储库。向量可以包括具有可配置的起始大小的初始场地，并且当增量存储库用完初始场地中的存储器时，具有更大大小的新场地可以被添加到向量。例如，每个增量存储库最初有一个具有可配置起始大小(例如，4096字节)的场地。如果增量存储库用完了当前场地中的存储器，则可以分配双倍大小的新场地并且将该双倍大小的新场地添加到向量中。每个场地都与作为此场地中保存的最后一行的LSN的LSN相关联。在增量存储库GC期间，我们释放与比GCLSN更小的LSN相关联的那些场地。

图10图示了可以由HTAP系统的存储引擎(例如图4中图示的存储子系统306)执行的示例过程1000。HTAP系统的存储引擎可以执行过程1000以便以能够被OLTP子系统和OLAP子系统利用的方式接收和/或组织用户数据。尽管在图10中被描绘为操作序列，但是本领域普通技术人员应理解的是，各个实施例可以添加、移除、重新排序或修改所描绘的操作。

如上所讨论的，逻辑日志可以到达每个AP存储节点，并且可以被分类、持久保存，然后按顺序应用到每个分区的存储器内增量存储库中。逻辑日志一旦到达就可以按顺序应用到存储器内的增量存储库中。OLTP引擎内部数据改变的时间与数据改变出现在增量存储库内部的时间之间的延迟几乎不存在(例如，在大多数情况下小于几百毫秒)。增量存储库可以按照日志序列号(LSN，指示数据操作顺序的序列号/版本)排序的行格式存储数据。

在1002处，可以基于一个或多个预定规则将数据从增量存储库冲刷到基本存储库。增量存储库内部的数据可以定期冲刷到基本存储库，例如，当其大小增长超过某个预定义的阈值时或在某个固定的时间间隔后。在冲刷之后，被冲刷的数据占用的存储器可以被垃圾箱收集。基本存储库中的数据可以以列式格式被存储并且可以由OLAP引擎访问。基本存储库中的数据可以以列式格式被组织，以获得更好的分析工作负载性能并且持久保存/存储在本地文件系统中。可以基于分区键将基本存储库中的数据划分成多个分区。基本存储库中的每个分区可以包括多个数据块。

基本存储库中的数据可能无法就地更新，因此可以维护标记已删除的行的删除位图。在1004处，删除位图可以被应用于从增量存储库冲刷到基本存储库的至少一批数据。，因为数据块一旦生成就不被修改，所以KV系统可以用于存储删除位图，该删除位图包含关于在从增量存储库中冲刷之后从基本存储库中移除的行的信息。

每个分区可以存储在单独的目录中，并且用于不同列的数据可以存储在不同的文件中。在每个数据文件中，数据按主键(一列或多列)分类。此外，数据块可以周期性地与后台任务中的整理程序合并。在1006处，可以对基本存储库应用整理操作以合并多个分区中的一个分区中的数据块。由于分区内的数据块可能具有重叠的主键范围，因此查询可能需要检查许多块，这会显著降低查询处理速度。此外，在删除位图中标记的数据文件中已删除的行可能被永久删除。这不仅会减小基本存储库的大小，还会提高查询处理的效率。为了实现上述两个目标，基本存储库执行后台整理过程来合并分区内的块。基本存储库上的整理操作提高了扫描性能并且减少了存储使用。整理操作不会阻止诸如日志应用、冲刷、GC和扫描等的其他操作。

为了扫描存储引擎中的数据，HTAP系统(具有(一个或多个)分离的计算引擎和存储引擎)利用扫描操作。扫描操作对我们的HTAP存储引擎的扫描进行了多种优化，例如异步RPC调用、使用扫描线程池的并行扫描、谓词下推、聚合下推、基于成本的删除过滤优化、用于大数据量的连续扫描以及分区修剪等。这些技术可以各自，单独或组合地，有助于高效的分析处理。

扫描操作是通过来自计算引擎的远程程序调用(RPC)来扫描存储引擎中的数据。多个扫描操作可以由扫描线程池中的线程并行执行。表扫描可以被分割并且分布到HTAP存储引擎中的表的分区中的多个并行扫描。分区中扫描操作的执行可以是异步的并且当扫描完成时可以调用回调函数来发回结果。下面可能是扫描操作的API：HTAP_扫描(扫描_id，表_id，分区_id，谓词列表，投影列表，读取

在扫描HTAP存储中的数据块时，可以应用谓词过滤器和所需列的投影。如果查询具有聚合操作符，则它的部分聚合可以下推到HTAP存储的扫描。在1008处，响应于确定OLAP查询包括指示聚合的聚合操作符，聚合的至少一部分可以被下推到增量存储库和基本存储库的扫描。存储节点中的本地部分聚合可能会大大减少扫描的结果数据。谓词和聚合下推的设计对于具有分离的计算和存储引擎的HTAP系统的性能至关重要。在1010处，可以通过应用谓词过滤器和投影操作来扫描数据块。

此外，可能需要检查删除位图以排除已删除的行。基本存储库扫描的结果可能还需要通过基于行的主键查找删除散列表来排除增量存储库中已删除的行。有几种合适的策略来过滤掉已删除的数据。一种此类策略是为每一行扫描的数据搜索删除散列表。另一个此类策略是组合删除位图和增量存储库中的删除以用于扫描基本存储库数据。这两种解决方案对于不同的工作负载具有不同的成本(例如，增量存储库中的删除次数和基本存储库的数据大小可能会影响成本)。基于成本的优化可以用于选择何时过滤掉增量存储库中的删除(如果增量存储库中有删除)。

一次RPC调用可能无法完成扫描。例如，每个RPC可能有行限制，并且如果扫描量很大，则必须批量返回扫描结果。为了处理此连续扫描要求，连续扫描框架可以被配置为在计算和存储分离的HTAP系统中处理具有大数据大小的扫描操作。

在1012处，可以基于扫描识别和迭代器实例的映射对增量存储库和基本存储库执行连续扫描。存储引擎可以用增量存储库和基本存储库的快照上的迭代器实例来保存扫描状态，并且调用nextBatch()函数来返回下一批数据。例如，存储引擎可以保存<扫描ID，迭代器实例>的映射。当计算引擎发起新的扫描请求时，存储引擎可以分配新的扫描ID，创建迭代器实例，并且返回扫描ID作为响应的一部分。对于连续扫描请求，存储引擎可以使用计算引擎给出的扫描ID来定位当前迭代器实例并且从那里继续。

我们的OLAP引擎的优化器可以支持分区修剪。基于此优化，我们的HTAP存储引擎可能只扫描那些没有被优化器修剪掉的分区。它可能不会提高单个查询的性能；但是，当多个查询同时运行时，它可能会提高吞吐量和QPS(每秒查询数)。在1014处，可以一批或多批返回扫描结果。

图11图示了可以用于各个方面的计算设备，诸如图1中描绘的服务、网络、模块和/或设备。关于图1的示例架构，云网络102、网络120、客户端设备104a-d、服务102、HTAP系统100和/或节点108均可以由图11的计算设备1100的一个或多个实例来实现。图11中示出的计算机架构示出了常规的服务器计算机、工作站、台式计算机、膝上型计算机、平板计算机、网络设备、PDA、电子阅读器、数字蜂窝电话或其他计算节点，并且可以用于执行本文所描述的计算机的任何方面，诸如实现本文所描述的方法。

计算设备1100可以包含作为印刷电路板的基板或“主板”，多个部件或设备可以通过系统总线或其他电通信路径连接到该基板或“主板”。一个或多个中央处理单元(CPU)1104可以结合芯片组1106操作。(一个或多个)CPU 1104可以是执行计算设备1100的操作所需的算术和逻辑操作的标准可编程处理器。

(一个或多个)CPU 1104可以通过操纵区分并且改变这些状态的开关元件从一个离散物理状态转变到下一个离散物理状态来执行必要的操作。开关元件一般可以包含保持两个二进制状态中的一个的电子电路(诸如触发器)以及基于一个或多个其他开关元件(诸如逻辑门)的状态的逻辑组合来提供输出状态的电子电路。这些基本开关元件可以被组合以创建更复杂的逻辑电路，包含寄存器、加法器-减法器、算术逻辑单元、浮点单元等。

(一个或多个)CPU 1104可以用其他处理单元(诸如(一个或多个)GPU 1105)来扩充或替换。(一个或多个)GPU 1105可以包括专用于但不必限于高度并行计算的处理单元，诸如图形和其他可视化相关处理。

芯片组1106可以在(一个或多个)CPU 1104与基板上的其余部件和设备之间提供接口。芯片组1106可以提供到用作计算设备1100中的主存储器的随机存取存储器(RAM)1108的接口。芯片组1106可以进一步提供给计算机可读存储介质的接口，诸如只读存储器(ROM)1120或非易失性RAM(NVRAM)(未示出)，用于存储可以帮助启动计算设备1100以及在各种部件与设备之间传送信息的基本例程。ROM 1120或NVRAM也可以存储根据本文所描述的方面的计算设备1100的操作所必需的其他软件部件。

计算设备1100可以使用通过局域网(LAN)到远程计算节点和计算机系统的逻辑连接在网络化环境中操作。芯片组1106可以包含用于通过网络接口控制器(NIC)1122(诸如千兆以太网适配器)提供网络连接的功能。NIC 1122能够通过网络1116将计算设备1100连接到其他计算节点。应理解的是，计算设备1100中可以存在多个NIC 1122，将计算设备连接到其他类型的网络和远程计算机系统。

计算设备1100可以连接到为计算机提供非易失性存储的大容量存储设备1128。大容量存储设备1128可以存储系统程序、应用程序、其他程序模块和数据，这些已经在本文中更详细地描述。大容量存储设备1128可以通过连接到芯片组1106的存储控制器1124连接到计算设备1100。大容量存储设备1128可以由一个或多个物理存储单元组成。大容量存储设备1128可以包括管理部件1111。存储控制器1124可以通过串行附接SCSI(SAS)接口、串行高级技术附件(SATA)接口、光纤通道(FC)接口或用于在计算机与物理存储单元之间物理连接和传送数据的其他类型的接口与物理存储单元接口连接。

计算设备1100可以通过转换物理存储单元的物理状态来反映所存储的信息，从而将数据存储在大容量存储设备1128上。物理状态的具体变换可以取决于各个因素以及本描述的不同实现方式。此类因素的示例可以包含但不限于用于实现物理存储单元的技术以及大容量存储设备1128是否被表征为主存储器或辅助存储器等。

例如，计算设备1100可以由通过存储控制器1124发出指令来将信息存储到大容量存储设备1128，以改变磁盘驱动单元中特定位置的磁特性、光存储单元中特定位置的反射或折射特性、或固态存储单元中特定电容器、晶体管或其他分立部件的电特性。在不脱离本描述的范围和精神的情况下，物理介质的其他变换是可能的，提供前述示例只是为了便于本描述。计算设备1100可以进一步通过检测物理存储单元内的一个或多个特定位置的物理状态或特性来从大容量存储设备1128读取信息。

除了上面所描述的大容量存储设备1128之外，计算设备1100还可以访问其他计算机可读存储介质来存储和检索信息，诸如程序模块、数据结构或其他数据。本领域技术人员应理解的是，计算机可读存储介质可以是提供非暂态数据的存储并且可以由计算设备1100访问的任何可用介质。

作为示例而非限制，计算机可读存储介质可以包含以任何方法或技术实现的易失性和非易失性、瞬态计算机可读存储介质和非瞬态计算机可读存储介质，以及可移动和不可移动介质。计算机可读存储介质包含但不限于可以用于以非暂态方式存储期望信息的RAM、ROM、可擦除可编程ROM(“EPROM”)、电可擦除可编程ROM(“EEPROM”)、快闪存储器或其他固态存储技术、光盘ROM(“CD-ROM”)、数字多功能盘(“DVD”)、高清晰度DVD(“HD-DVD”)、BLU-RAY或其他光存储、磁带盒、磁带、磁盘存储、其他磁存储设备或任何其他介质。

大容量存储设备(诸如图11中描绘的大容量存储设备1128)可以存储用于控制计算设备1100的操作的操作系统。操作系统可以包括LINUX操作系统的版本。操作系统可以包括来自微软公司的WINDOWS SERVER操作系统的版本。根据进一步的方面，操作系统可以包括UNIX操作系统的版本。也可以利用各个移动电话操作系统，诸如IOS和ANDROID。应理解的是，也可以利用其他操作系统。大容量存储设备1128可以存储由计算设备1100利用的其他系统或应用程序和数据。

大容量存储设备1128或其他计算机可读存储介质也可以用计算机可执行指令进行编码，该计算机可执行指令在被加载到计算设备1100中时，将计算设备从通用计算系统转换成能够实现本文所描述的各方面的专用计算机。如上面所描述的，这些计算机可执行指令通过指定(一个或多个)CPU 1104如何在状态之间转变来转变计算设备1100。计算设备1100可以访问存储计算机可执行指令的计算机可读存储介质，该计算机可执行指令在由计算设备1100执行时，可以执行本文所描述的方法。

计算设备(诸如图11中描绘的计算设备1100)还可以包含输入/输出控制器1132以用于接收和处理来自多个输入设备(诸如键盘、鼠标、触摸板、触摸屏、电子指示笔或其他类型的输入设备)的输入。类似地，输入/输出控制器1132可以向显示器(诸如计算机监测器、平板显示器、数字投影仪、打印机、绘图仪或其他类型的输出设备)提供输出。应理解的是，计算设备1100可以不包含图11中示出的所有部件，可以包含图11中未明确示出的其他部件，或可以利用与图11中示出的架构完全不同的架构。

如本文所描述的，计算设备可以是物理计算设备，诸如图11的计算设备1100。计算节点还可以包含虚拟机主机进程和一个或多个虚拟机实例。计算机可执行指令可以由计算设备的物理硬件通过解译和/或执行在虚拟机的上下文中存储和执行的指令来间接执行。

应理解的是，这些方法和系统不限于特定的方法、特定的部件或特定的实现方式。还应理解的是，本文所用术语仅是为了描述特定实施例的目的，而不是旨在进行限制。

如说明书和所附权利要求中所用，单数形式“一”、“一个”和“该”包含复数指示物，除非上下文中另有明确规定。范围在本文中可以表示为从“约”一个特定值和/或到“约”另一个特定值。当表达此类范围时，另一个实施例包含从一个特定值和/或到另一个特定值。类似地，当通过使用先行词“约”将值表示为近似值时，应理解该特定值形成了另一个实施例。进一步应理解的是，范围中的每一个的端点相对于另一个端点和独立于另一个端点两者都是重要的。

“可选的”或“可选地”是指随后描述的事件或情况可能发生或可能不发生，并且该描述包含所述事件或情况发生的实例和所述事件或情况不发生的实例。

在本说明书的整个描述和权利要求中，词语“包括”和此词语的变体，诸如“包括(comprising)”和“包括(comprises)”，意味着“包含但不限于”并且不旨在排除例如其他部件、整体或步骤。“示例性的”意味着“的示例”并且不旨在传达优选或理想实施例的指示。“诸如”不是在限制性的意义上使用，而是用于解释的目的。

描述了可以用于执行所描述的方法和系统的部件。当描述这些部件的组合、子集、相互作用、组等时，应理解的是，尽管可能没有明确描述对这些部件的各种单独和集体组合和排列中的每一个的具体引用，但是对于所有方法和系统，每一个都在本文中被具体考虑和描述。这适用于本申请的所有方面，包含但不限于所描述的方法中的操作。因此，如果存在可以执行的多种另外的操作，则应理解的是可以用所描述的方法的任何特定实施例或实施例的组合来执行，这些另外的操作中的每一个。

通过参考以下对优选实施例的具体实施方式和其中包含的示例以及附图及其描述，可以更容易地理解本方法和系统。

如本领域技术人员应理解的，该方法和系统可以采取完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。此外，这些方法和系统可以采取具有在该存储介质中实施的计算机可读程序指令(例如，计算机软件)的计算机可读存储介质上的计算机程序产品的形式。更特别地，本方法和系统可以采取网络实现的计算机软件的形式。可以利用任何合适的计算机可读存储介质，包含硬盘、CD-ROM、光存储设备或磁存储设备。

下面参考方法、系统、装置和计算机程序产品的框图和流程图来描述方法和系统的实施例。应理解的是，可以相应地由计算机程序指令来实现框图和流程图中的每个框以及框图和流程图中的框的组合。这些计算机程序指令可以被加载到通用计算机、专用计算机或其他可编程数据处理装置上以产生机器，使得在计算机或其他可编程数据处理装置上执行的指令创建用于实现流程图的一个或多个框中指定的功能的器件。

这些计算机程序指令也可以存储在计算机可读存储器中，这些计算机程序指令可以指导计算机或其他可编程数据处理装置以特定方式运行，使得存储在计算机可读存储器中的指令产生包含用于实现流程图的一个或多个框中指定的功能的计算机可读指令的制品。计算机程序指令也可以被加载到计算机或其他可编程数据处理装置上，以使得在计算机或其他可编程装置上执行一系列操作步骤，使得产生计算机实现的过程，使得在计算机或其他可编程装置上执行的指令提供用于实现流程图的一个或多个框中指定的功能的步骤。

上面所描述的各种特征和过程可以彼此独立地使用，或可以以各种方式组合。所有可能的组合和子组合都旨在落入本公开的范围内。此外，在一些实现方式中可以省略一些方法或过程块。本文所描述的方法和过程也不限于任何特定的顺序，并且与其相关的框或状态可以以其他适当的顺序来执行。例如，可以以不同于具体描述的顺序来执行所描述的框或状态，或多个框或状态可以组合在单个框或状态中。示例块或状态可以串行、并行或以某种其他方式执行。可以向所描述的示例实施例添加或从所描述的示例实施例删除框或状态。本文所描述的示例系统和部件可以与所描述的不同地配置。例如，与所描述的示例实施例相比，可以添加、删除或重新布置元件。

还应理解的是，各种项目被示为在被使用时存储在存储器中或存储装置上，并且这些项目或其部分可以出于存储器管理和数据完整性的目的而在存储器和其他存储装置之间传送。替代地，在其他实施例中，软件模块和/或系统中的一些或全部可以在另一个设备上的存储器中执行并且经由计算机间通信与所示计算系统通信。此外，在一些实施例中，系统和/或模块中的一些或全部可以以其他方式实现或提供(诸如至少部分地以固件和/或硬件实现)，包含但不限于一个或多个专用集成电路(“ASIC”)、标准集成电路、控制器(例如，通过执行适当的指令，并且包含微控制器和/或嵌入式控制器)、现场可编程门阵列(“FPGA”)、复杂可编程逻辑器件(“CPLD”)等。模块、系统和数据结构中的一些或全部也可以存储(例如，作为软件指令或结构化数据)在计算机可读介质(诸如硬盘、存储器、网络或便携式媒体产品)上以由适当的设备或经由适当的连接读取。系统、模块和数据结构也可以作为生成的数据信号(例如，作为载波或其他模拟或数字传播信号的一部分)在多种计算机可读传输介质上传输，包含基于无线和基于有线/电缆的介质，并且可以采取多种形式(例如，作为单个或多路复用模拟信号的一部分，或作为多个离散的数字分组或帧)。在其他实施例中，此类计算机程序产品也可以采取其他形式。因此，可以用其他计算机系统配置来实践本发明。

尽管已经结合优选实施例和特定示例描述了方法和系统，但是这并不旨在范围限于所阐述的特定实施例，因为本文的实施例在所有方面都旨在是说明性的而非限制性的。

除非另有明确说明，否则决不旨在本文阐述的任何方法都被解释为要求其操作以特定顺序执行。因此，在方法权利要求实际上没有叙述其操作遵循的顺序的情况下，或在权利要求或说明书中没有以其他方式具体说明操作将限于特定顺序的情况下，决不旨在可以从任何方面推断顺序。这适用于任何可能的非明示的解译基础，包含：关于步骤布置或操作流程的逻辑问题；源自语法组织或标点符号的简单意思；以及说明书中描述的实施例的数量或类型。

对于本领域技术人员来说显而易见的是，在不脱离本公开的范围或精神的情况下可以进行各种修改和变化。通过考虑到本文所描述的说明书和实践，其他实施例对于本领域技术人员来说将是显而易见的。说明书和示例图仅被认为是示例性的，其中真正的范围和精神由所附权利要求指出。

Claims

1.一种方法，包括：

接收由第一处理引擎捕获的数据，其中所述第一处理引擎被配置为执行在线事务处理；

通过在基于所述数据生成的逻辑日志的多个副本上应用仲裁协议，将所述多个副本分布到增量存储库，其中所述增量存储库中的数据以行格式被存储，并且对于由第二处理引擎执行的在线分析处理的查询是可见的；以及

基于一个或多个预定规则，将数据从所述增量存储库冲刷到基本存储库，其中所述基本存储库中的数据以列式格式被存储，并且能够由所述第二处理引擎访问，所述基本存储库中的所述数据基于分区键被划分成多个分区，并且所述基本存储库中的每个分区包括多个数据块。

2.根据权利要求1所述的方法，还包括：

通过执行删除操作和插入操作，更新所述增量存储库中的所述数据。

3.根据权利要求1所述的方法，其中所述增量存储库包括插入变量列表和删除变量列表，并且所述插入变量列表和所述删除变量列表基于日志序列号来被分类。

4.根据权利要求1所述的方法，其中所述多个数据块中的每个数据块包括多个列文件和元数据文件，并且所述元数据文件包括与所述多个列文件相关联的元数据。

5.根据权利要求1所述的方法，还包括：

将删除位图应用于从所述增量存储库冲刷到所述基本存储库的至少一批数据，其中所述删除位图包括指示在从所述增量存储库冲刷之后被移除的行的信息。

6.根据权利要求1所述的方法，还包括：

对所述基本存储库应用整理操作，以合并所述多个分区中的一个分区中的数据块。

7.根据权利要求1所述的方法，还包括：

通过应用谓词过滤器和投影操作，扫描所述多个数据块。

8.根据权利要求1所述的方法，还包括：

响应于确定在线分析处理查询包括指示聚合的聚合操作符，将所述聚合的至少一部分下推到所述增量存储库和所述基本存储库的扫描。

9.根据权利要求1所述的方法，还包括：

基于扫描识别和迭代器实例的映射，对所述增量存储库和所述基本存储库执行连续扫描；以及

批量返回扫描结果。

10.一种系统，包括：

至少一个处理器；以及

至少一个存储器，通信地耦合到所述至少一个处理器并且包括指令，所述指令在由所述至少一个处理器执行时使所述系统执行操作，所述操作包括：

11.根据权利要求10所述的系统，所述操作还包括：

12.根据权利要求10所述的系统，其中所述增量存储库包括插入变量列表和删除变量列表，并且所述插入变量列表和所述删除变量列表基于日志序列号(LSN)来被分类。

13.根据权利要求10所述的系统，其中所述多个数据块中的每个数据块包括多个列文件和元数据文件，并且所述元数据文件包括与所述多个列文件相关联的元数据。

14.根据权利要求10所述的系统，所述操作还包括：

15.根据权利要求10所述的系统，所述操作还包括：

16.根据权利要求10所述的系统，所述操作还包括：

通过应用谓词过滤器和投影操作，扫描所述多个数据块。

17.根据权利要求10所述的系统，所述操作还包括：

18.根据权利要求10所述的系统，所述操作还包括：

批量返回扫描结果。

19.一种非暂态计算机可读存储介质，包括计算机可读指令，所述计算机可读指令在由系统执行时使得所述系统实现操作，所述操作包括：

通过在基于所述数据生成的逻辑日志的多个副本上应用仲裁协议，将所述多个副本分布到增量存储库，其中所述增量存储库中的数据以行格式来被存储，并且对于由第二处理引擎执行的在线分析处理的查询是可见的；以及

基于一个或多个预定规则，将数据从所述增量存储库冲刷到基本存储库，其中所述基本存储库中的数据以列式格式来被存储，并且能够由所述第二处理引擎访问，所述基本存储库中的所述数据基于分区键被划分成多个分区，并且所述基本存储库中的每个分区包括多个数据块。

20.根据权利要求19所述的非暂态计算机可读存储介质，

其中所述增量存储库包括插入变量列表和删除变量列表，并且所述插入变量列表和所述删除变量列表基于日志序列号来被分类；以及

其中所述多个数据块中的每个数据块包括多个列文件和元数据文件，并且所述元数据文件包括与所述多个列文件相关联的元数据。