CN117677943A - 用于混合数据处理的数据一致性机制 - Google Patents

Abstract

本公开描述了为混合事务和分析处理提供数据一致性的技术。逻辑日志和与逻辑日志相关联的日志序列号(LSN)可以基于由第一处理引擎捕获的数据来生成。逻辑日志和LSN可以被传播到被配置为与第一处理引擎和第二处理引擎通信的存储子系统。LSN和指示LSN模式版本的信息可以由元数据服务存储和分发。第一处理引擎、第二处理引擎、存储子系统和元数据服务被模块化，并且支持用于维护数据一致性的LSN机制。

Description

用于混合数据处理的数据一致性机制

相关申请的交叉引用

本申请要求于2021年8月31日提交的标题为“DATA CONSISTENCY MECHANISM FORHYBRID DATA PROCESSING”的美国申请号17/462,938的优先权，该申请的全部内容通过引用整体并入本文。

背景技术

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

附图说明

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

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

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

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

图4示出了用于确保读取和写入过程期间副本之间的数据一致的示例体系架构。

图5示出了增量存储库和基本存储库的示例快照。

图6A示出了增量存储库和基本存储库的示例快照。

图6B示出了图6A的增量存储库和基本存储库的另一个示例快照。

图7A示出了增量存储库和基本存储库的示例快照。

图7B示出了图7A的增量存储库和基本存储库的另一个示例快照。

图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系统提供的事务支持和强数据一致性。混合事务/分析处理(HTAP)系统最适合此类场景。

HTAP系统提供几个独特的优点。在HTAP系统中，OLAP和OLTP工作负载统一在单个系统中。通过将OLAP和OLTP工作负载合并到单个系统中，可以显著降低部署和维护的复杂性和成本。这种多功能系统可以显著减少查询结果的陈旧性(这种陈旧性通常是由从操作数据库到数据仓库的耗时且昂贵的ETL过程引入的)。这种系统还具有对实时数据进行复杂分析的能力，从而解决通常要求对必须被实时利用的瞬态机会的有效响应的现代商业模式。

但是，许多现有的HTAP系统都有缺点。许多现有产品仅通过将OLTP和OLAP系统粘合在一起来构建HTAP系统。例如，许多现有产品仅通过使用ETL技术将OLTP和OLAP系统粘合在一起以将数据从OLTP存储装置加载到OLAP存储装置来构建HTAP系统。通过仅将OLTP和OLAP系统粘合在一起，HTAP系统缺乏期望的特征，诸如跨HTAP系统的OLTP和OLAP部件的强数据一致性。跨HTAP系统的OLTP和OLAP部件的强数据一致性对于许多业务场景至关重要。因而，期望一种解决这些缺点的HTAP系统。

本文描述了一种跨HTAP系统的OLTP和OLAP部件具有强数据一致性的HTAP系统。与现有的HTAP系统不同，本文描述的HTAP系统被配置为提供跨OLTP和OLAP部件的全局快照隔离并且被配置为支持OLAP查询以读取当前系统中的最新更新—从而确保强数据一致性。例如，可以使用包括但不限于Quorum(仲裁)和Gossip(闲聊)协议以及日志序列号(LSN)的机制来提供跨OLTP和OLAP部件的全局快照隔离。利用这种机制，向HTAP系统中的所有查询提供对数据集的一致快照的访问。不会向用户提供脏的、损坏的和/或过时的数据。在一些实施例中，可以向本文描述的HTAP系统的用户提供灵活的接口以选择期望的数据一致性级别。

跨OLTP和OLAP部件具有强数据一致性的HTAP系统可以具有灵活的模块化设计。模块化HTAP系统可以由几个可解耦的主要部件组成：OLTP引擎、OLAP引擎、服务OLTP和OLAP引擎两者的解耦的存储装置、元数据服务，以及智能代理。解耦的存储部件可以包括OLTP行存储库和OLAP存储库，其具有两个部分：保持最新更新的存储器内增量存储库和保持大数据块的盘上基本存储库。来自增量存储库的数据可以作为新数据块周期性地刷新到基本存储库。HTAP系统用来确保数据强一致性的LSN机制可以是所有这些可解耦部件的共同努力，而不与任何特定部件耦合。每个部件都可以被拔出并用替换部件替换，只要该替换部件被配置为通过公共API扩展对LSN的支持即可。

诸如上述改进的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可以包括任何其它类型的服务。

在一个实施例中，可以经由网络120向客户端设备104提供服务112。如果服务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引擎、底层解耦的存储装置、元数据服务和/或智能代理中的一者或多者。下面参考图3a-图7更详细地讨论HTAP系统110的体系架构。下面还关于图3a-图7更详细地讨论关于每个子系统的附加细节。

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查询，包括联接、聚合等。有效且实时的处理是由于HTAP系统110的体系架构促进在OLTP侧和OLAP侧存储不同的数据副本，因此OLTP与OLAP工作负载之间的干扰被最小化这一事实所赋予的。OLTP和OLAP数据格式可以被单独优化以适应其工作负载。可以存在通过HTAP系统110(来自OLTP侧)的单个数据改变源，从而简化跨OLTP和OLAP部件的一致性模型和并发性处置。

HTAP系统110的体系架构可以为OLAP查询提供新鲜/实时的数据改变。DML的逻辑日志可以在提交后立即从OLTP部件传播到OLAP部件。这些日志可以被分派到分布式分区，并且可以经由存储器内操作连续应用于存储器内增量存储库，这通常非常快。由逻辑日志携带的数据改变在应用于存储器内增量存储库后可以立即可用于OLAP查询。HTAP系统110的体系架构利用了跨HTAP系统110的统一版本控制，从而保证了强数据一致性。HTAP系统110的OLTP部件可以像大多数事务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引擎304、OLAP引擎308、数据存储系统310、元数据服务306和/或代理302。

如上所述，OLTP引擎304可以接收用户数据，诸如从用户设备301a-n接收。OLTP引擎304可以利用将计算引擎与底层共享/云存储装置(类似AWS Aurora)分开的模型。OLTP引擎304可以提供诸如ACID事务支持、行存储、预写日志(WAL)和日志复制之类的功能性。例如，OLTP引擎304可以实时或近实时地捕获用户数据。

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

OLTP引擎304可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果OLTP引擎304从更大的HTAP系统300解耦，那么OLTP引擎304可以用替代OLTP引擎(例如，类似的已建立的OLTP引擎)替换。例如，OLTP引擎304可以用替代OLTP引擎替换，该替代OLTP引擎被配置为通过公共API扩展对LSN的支持。例如，OLTP引擎304可以是MySQL，但是它可以容易地交换到任何其它已建立的OLTP引擎，诸如PostgreSQL。

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

还如上所述，OLAP引擎308可以接收由OLTP引擎(诸如OLTP引擎304)捕获的数据。由OLAP引擎308接收的数据可以是OLAP引擎308可读的特定格式(例如，混合行+列格式)。OLAP引擎308可以响应于接收到OLAP查询而对特定格式的数据的至少一部分执行分析。

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

OLAP引擎308可以是能够有效处置复杂分析查询的任何OLAP引擎，诸如已建立的开源查询引擎(例如，FlinkSQL)。OLAP引擎308可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果OLAP引擎308从更大的HTAP系统300解耦，那么OLAP引擎308可以用替代OLAP引擎(例如，类似的已建立的OLAP引擎)来替换。例如，OLAP引擎308可以被替换为替代OLAP引擎，其被配置为通过公共API扩展对LSN的支持。例如，OLAP引擎308可以是FlinkSQL，但它可以容易地交换到任何其它已建立的OLAP引擎，诸如Presto或SparkSQL。

存储子系统310可以从OLTP引擎304和OLAP引擎308解耦。还如上所述，数据存储系统310可以以一种格式(例如，行格式)持久保存用户数据以供OLTP引擎(诸如OLTP引擎304)使用，同时以不同的格式(例如，混合行+列格式)持久保存相同的用户数据以供OLAP引擎(诸如OLAP引擎308)使用。这可以显著减少OLAP与OLTP工作负载之间的干扰。可以为两种格式的数据保留多个数据复制品(例如，三个数据复制品)以实现高可用性。

数据存储系统310可以用作统一存储层。但是，数据存储系统310的体系架构可以被划分为两部分：TP部分和AP部分。由OLTP引擎接收的事务DML和DDL可以在日志存储库312中呈现为物理/重做日志(具有底层存储装置的信息)和逻辑日志。这些日志可以持久保存在存储装置的TP部分中。然后物理日志可以由日志分发器314复制并分发到其它存储装置并被重放以构造数据页。页面中的数据可以以行格式组织并存储在行数据存储库316中。存储在行数据存储库316中的数据可以被OLTP引擎用于包括点查找查询的简单查询。逻辑日志也可以由日志分发器314复制并分发到存储装置的AP部分。

存储装置的AP部分中的每个用户表可以基于表创建时定义的分区方案来分区。每个分区317可以驻留在物理存储节点(例如，服务器)中并且可以维护数据的几个复制品以实现高可用性。每个分区317还可以被划分为存储器内增量存储库318和盘上基本存储库320。已提交的DML事务的逻辑日志(诸如MySQL二进制日志)可以从OLTP引擎连续分派到每个AP存储节点上的用户表分区。作为一个示例，更新可以通过删除然后插入来建模。因此，在逻辑日志中可以只有插入和删除，而没有更新。

到达每个AP存储节点的逻辑日志可以被排序、持久化，然后按次序应用到每个分区317的存储器内增量存储库318中。增量存储库318可以以按其日志序列号(LSN，指示数据操作的次序的序列号/版本)排序的行格式存储数据。例如，当增量存储库318内数据的大小增长超过某个预定义阈值时或者在某个固定时间间隔之后，增量存储库318内的数据可以定期刷新到基本存储库320。在刷新之后，被刷新的数据所占用的存储器可以被垃圾收集。

基本存储库320中的数据可以以列格式组织以实现分析工作负载的更好性能，并且持久保存在本地文件系统中(利用当前的实施方式)。但是，应当认识到的是，该体系架构与任何底层存储方法一起工作。基本存储库320中的数据可能无法就地更新，因此可以维护标记行已被删除的删除位图。随着越来越多的删除和重叠刷新的数据单元，压缩和重新布置内部数据可以有益于存储和潜在的查询性能，因此可以定期压缩AP数据单元和清理冗余数据。基本存储库320中的文件可以被版本化，这是文件被刷新时文件中的最大LSN。LSN可以不保留在基本存储库320中，这会导致基本存储库320中的所有文件具有相同的版本(即，前一次刷新的LSN)。这可以提供许多优点。例如，它可以节省存储空间，通过使用删除位图使删除更加高效，并使扫描更快而无需与LSN进行比较。

存储子系统310可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦，如图3中所示。如果存储子系统310从更大的HTAP系统300解耦，那么存储子系统310可以用替代存储子系统(例如，类似的已建立的存储子系统)来替换。例如，存储子系统310可以被替换为替代存储子系统，其被配置为通过公共API扩展对LSN的支持。

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

元数据服务306可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果元数据服务306从更大的HTAP系统300解耦，那么元数据服务306可以用替代元数据服务(例如，类似的已建立的元数据服务)来替换。例如，元数据服务306可以被替换为替代元数据服务，其被配置为通过公共API扩展对LSN的支持。

代理302可以被配置为通过公共代理层将用户设备301a-n连接到OLTP引擎304和/或OLAP引擎308。代理302可以是智能代理。代理302可以向用户/客户端提供单个统一的API(默认：ANSL SQL加上一些常见的OLAP扩展)，即，如果客户端通过代理连接，那么底层系统细节对于客户端来说是透明的。基于用户要求，可以使用各种API(例如，ANSI SQL、JDBC、ODBC等)。使用单个统一的API可以减少用户使用系统的工作量。代理302可以具有基于请求的性质自动将不同的客户端请求/查询分派到不同的引擎(例如，OLTP引擎304或OLAP引擎308)的能力。例如，复杂的OLAP查询将被导向到OLAP引擎308，而DML、DDL和点查找查询将被导向到OLTP引擎304。

代理302可以被配置为耦合到更大的HTAP系统300和/或从更大的HTAP系统300解耦。如果代理302从更大的HTAP系统300解耦，那么代理302可以用替代的公共代理(例如，类似的已建立的代理)来替换。例如，代理302可以被替换为替代代理，其被配置为通过公共API扩展对LSN的支持。

OLTP引擎304、OLAP引擎308、存储子系统310和元数据服务306中的每一者可以利用LSN来确保HTAP系统中的强数据一致性。OLTP引擎处置OLTP事务并生成LSN。用于每次数据更新的LSN是在事务提交过程期间使用预写日志(WAL)生成的。例如，OLAP引擎304可以通过从元数据服务306请求全局读取LSN并启动分布式扫描任务以使用这些读取LSN请求数据来协调OLAP查询。LSN与日志一起从TP传播到解耦的存储装置310存储装置的AP部件，并且可以应用于存储装置310的增量存储库。存储装置310可以使用多个LSN来指示各种操作的进度/状态。元数据服务306可以将持久化LSN的进度存储在存储服务器上，并将其用作用于OLAP查询的read_LSN。元数据服务306还可以存储模式LSN以支持DDL。默认情况下，智能代理302不知道任何LSN。在READ_YOUR_WRITE一致性模式下，代理302可能需要收集查询的返回的LSN并利用该LSN发出下一个查询。

如上面所讨论的，为了保证HTAP系统中的强数据一致性，可以使用Quorum协议和/或Gossip协议来提供跨OLTP和OLAP引擎的全局快照隔离。利用Quorum协议和Gossip框架可以将单分区一致性读取和写入扩展到全局分布式集群中。图4示出了用于确保读取和写入过程期间副本之间的数据一致的示例体系架构400。体系架构400利用Quorum协议和Gossip协议作为构建来确保HTAP系统中的强数据一致性。具有复制的分区的数据可以跨集群401中的多个数据节点402、404、406来存储和/或访问。对于给定分区，不同节点上可以有多个复制品，从而保留相同的数据以用于容错。

可以应用Quorum协议来确保在读取和写入过程期间这些复制品之间的数据是一致的。Quorum是一种类型的技术，其可以用于在“分布式系统”中执行恒定功能或操作。它使用分布式事务，从分布式系统中获得最少选票。利用基于Quorum的数据一致性，读取和写入请求可以总是由多个健康节点(例如，节点402、404、406中的两个或更多个节点)提供服务，并且跨集群401的数据可以保留在一致状态。任何失败、损坏或缓慢的复制品都不会向外部客户端暴露任何数据正确性问题，诸如过时、脏、损坏的数据。

例如，体系架构400利用2+2Quorum设置。每个分区由3个复制品/节点(节点402、404、406)提供服务。由框架400向所有3个复制品/节点402、404、406发送写入请求，并且在其中2个成功之后写入成功。如图4中所示，发送到节点402和404的写入请求成功，并且发送到节点406的写入请求失败。但是，因为对于其中两个节点写入成功，所以写入仍然成功。在读取期间，框架400可以查询至少2个节点以请求数据状态，并选择具有满足读取一致性要求的数据的节点。由于存在至少2个保持最新写入的节点，因此我们可以容忍一个节点故障，但仍能确保读取成功且一致。如图4中所示，节点406发生故障，但其它节点402和404成功。因而，尽管节点406发生故障，读取仍然成功且一致。

除了Quorum算法之外，还可以利用Gossip协议来补救复制品402、404、406之间的任何暂时不一致性。Gossip协议是基于流行病传播的方式进行的计算机对等通信的程序或过程。一些分布式系统使用对等Gossip来确保数据被散布到组的所有成员。例如，如果任何复制品402、404、406由于诸如盘或网络故障之类的意外故障而落后于其它复制品，那么利用Gossip协议，复制品将在节点间消息交换期间赶上其对等体。例如，由于Gossip协议，节点406可以自己赶上LSN 110。

可以充分利用Quorum和Gossip协议来跨集群中的分布式分区使数据保留在一致状态。此外，可以利用LSN机制来确保数据读取和写入在每个分区上本地一致。当在协调器中编译查询时，可以以全局LSN的形式计算查询的数据快照。全局LSN可以被分发到保持期望分区的每个节点，并且可以检索关于查询快照LSN的本地数据部分。因此，即使数据在协调器中的编译点之后被立即更新，也不会在每个节点上访问多于或少于必要的数据。

在单个分区上，可以利用日志序列号(LSN)。LSN是指示本地存储状态的整数型递增数。每个分区保留其自己的本地LSN，而LSN还可以表示跨所有分区的存储状态的全局和逻辑数据快照。例如，当存储装置具有LSN 100时，并且在数据的新插入到达之后，存储装置LSN将移动到101。可以由协调器首先为查询分配来自元数据服务的全局read_LSN。全局read_LSN可以是编译查询时所有存储分区一直保存的LSN。然后可以将这个全局read_LSN发送到每个存储服务器以确定应当在每个分区上本地读取多少数据。例如，全局读取LSN100将确切地检索每个分区上的数据，直至LSN 100。

下面更详细地描述OLAP存储装置中使用的LSN。但是，应当认识到的是，HTAP系统的OLTP存储装置可以以类似的方式被处置，并且我们的HTAP系统中的查询可以使用单个读取LSN以一致的方式访问OLAP和OLTP存储装置两者。

如上面关于图3所讨论的，存储系统的基础(表的每个分区的每个复制品)是存储器内增量存储库和盘上基本存储库。增量存储库以逻辑日志的形式接受新数据，然后将日志转换成两个列表：插入增量列表和删除增量列表。在经过预定量的时间之后和/或如果满足容量准则，当前增量列表可以被刷新到基本存储库。可以使用多个LSN，每个LSN同时指示多个存储状态。

存储系统中的数据可以由于多次操作而不断改变。这些操作可以包括例如追加/删除、扫描、刷新、压缩和/或垃圾收集(GC)。在追加/删除操作期间，数据可以被添加到存储器内增量存储库的插入列表和删除列表。在扫描操作期间，可以相对于读取LSN从增量存储库和基本存储库读取当前数据。在刷新操作期间，数据可以从存储器刷新到盘。例如，当前数据可以从增量存储库移动到基本存储库。在压缩操作期间，可以重新组织基本存储库数据块。在垃圾收集操作期间，旧的和未使用的数据可以从增量存储库和/或基本存储库中移除。

可以应用多个LSN来指示这些操作的不同状态。通过这些LSN，数据扫描、更新和维护操作可以以并发且一致的方式一起工作，而不会彼此干扰。多个LSN可以包括每个查询的读取LSN以指示数据快照。这个LSN可以确保扫描将跨所有分区检索数据，直到读取LSN，组装针对直到读取LSN的数据的最终全局结果。多个LSN可以附加地包括以下中的一者或多者：用于保留活动查询的最小读取LSN的LSN、用于保留前一次刷新的结束点的LSN以及用于指示下一次刷新的结束点的LSN。这些LSN保证每个分区上的扫描将与刷新操作并发地进行，并且仍然产生关于查询的读取LSN的一致的结果。多个LSN可以附加地包括以下中的一者或多者：用于计算增量存储库数据可以被安全截断的点的LSN和用于指示哪些基本存储库块可以被安全截断的LSN。这些LSN确保维护操作(诸如GC)将与扫描并发地进行。

例如，在增量存储库上，可以利用以下LSN：min_read_LSN、last_flush_LSN、next_flush_LSN和/或delta_truncate_LSN。min_read_LSN可以指示活动查询的最小读取LSN。来自每个查询的所有活跃(alive)读取LSN都受到监视/跟踪，从而可以检索所有read_LSN的最小值，以高效地确定可以刷新多少数据。为了确保刷新操作不影响当前的数据扫描，只有LSN小于min_read_LSN的数据才可以从增量存储库刷新到基本存储库。last_flush_LSN可以指示前一次刷新的最大LSN。在下一次刷新之后，可以将其重置为next_flush_LSN。扫描可以从last_flush_LSN开始到其读取LSN，加上基本存储库中所有刷新的数据。虽然增量存储库的last_flush_LSN随着刷新而变化，但每次扫描的last_flush_LSN的快照(扫描数据从该LSN开始)不会改变。next_flush_LSN可以指示下一次刷新的最大刷新的LSN。可以选择min_read_LSN与last_flush_LSN之间的LSN作为next_flush_LSN，指示[last_flush_LSN，next_flush_LSN]中的行将被刷新。delta_truncate_LSN可以指示LSN小于delta_truncate_LSN的数据可以在后台GC线程中被截断，其中delta_truncate_LSN＝MIN(所有实时查询的last_flush_LSN，增量存储库的last_flush_LSN)。

这些并发操作的一个示例在图5中示出。图5描绘了增量存储库和基本存储库的示例性快照500。快照500指示增量存储库的前一次刷新已将与LSN<100相关联的数据移至基本存储库。因此，last_flush_LSN是100。每个活跃查询都持有读取LSN，其将读取增量存储库上从last_flush_LSN到其read_LSN的数据，以及last_flush_LSN之前的基本存储库数据。例如，LSN 110的查询1将从基本存储库中读取[0,100)，并从增量存储库读取[100，110]。查询2还将从基本存储库读取[0,100)并将从增量存储库读取[100，111]。由于所有活动查询的最小读取LSN是min_read_LSN，因此110(来自查询1)是min_read_LSN。随着旧查询完成和新查询到达，这个min_read_LSN不断更新。如果查询1在查询2之前完成，那么min_read_LSN将被更新为111。

可以基于时间或增量存储库容量标准来触发下一次刷新。图6A-图B示出了增量存储库和基本存储库的示例快照600、601。快照600描绘了下一次刷新之前的增量存储库和基本存储库，并且快照601描绘了下一次刷新之后的增量存储库和基本存储库。为了确定下一次刷新要刷新多少数据，选择小于当前min_read_LSN的next_flush_LSN。例如，next_flush_LSN可以是110，其小于当前的min_read_LSN 111。然后，增量存储库将刷新[last_flush_LSN，next_flush_LSN)(即，[100，110))之间的数据。在刷新完成点，last_flush_LSN将被更新为next_flush_LSN。刷新不会移除增量存储库中的任何数据，并且从其自己的last_flush_LSN(每个查询的快照)读取数据的活动查询不会用刷新来更新这个LSN。在刷新完成之后，新到达的查询将开始使用新的last_flush_LSN(110)。例如，查询4将开始使用新的last_flush_LSN(110)。以这种方式，刷新可以和扫描并发地工作，而不影响查询结果。

在垃圾收集操作期间，旧的和未使用的数据可以从增量存储库和/或基本存储库中被移除。图7A-图B示出了垃圾收集(GC)操作期间增量存储库和基本存储库的示例快照700、701。快照700描绘了GC操作之前的增量存储库和基本存储库，并且快照701描绘了GC操作之后的增量存储库和基本存储库。增量存储库上的GC操作将选择delta_truncate_LSN作为MIN(所有实时查询的last_flush_LSN，增量存储库的last_flush_LSN)，在该示例中是110。这意味着所有实时查询和未来查询都不需要在LSN 110之前扫描增量存储库，并且可以与实时扫描并发地安全地从增量存储库中移除那些数据，而不会影响任何查询的扫描结果。

对于基本存储库，可能有两种备选实施方式。第一种实施方式是带有版本化的数据的基本存储库。基本存储库中的每一行都将保留LSN。对基本存储库的扫描可以使用读取LSN，并且有可能为扫描启用时间旅行。第二种备选实施方式是没有显式版本的基本存储库。扫描始终读取基本存储库中的所有数据。非版本化的基本存储库在扫描和删除方面可以更高效，并且可以节省存储空间。

与增量存储库类似，基本存储库也可以具有如压缩和GC之类的维护操作。这些操作在基本存储库数据块上工作，因此不会影响增量存储库。为了使扫描和维护操作并行工作，在扫描开始时，查询将拍摄来自该基本存储库的所有实时数据块的快照。旧块如果被移除，那么会在结束点处改变为不可见，并用base_truncate_LSN进行标记，这是结束点处实时查询的最大read_LSN。在read_LSN<＝base_truncate_LSN的所有活动查询完成之后，GC线程中的那些旧块可以被移除。总之，在我们的增量存储库和基本存储库上使用多个并发操作，诸如数据插入、查询扫描、刷新、压缩和GC，并利用LSN来确保这些操作可以并发工作，同时仍然向查询客户端传递一致的结果。

以上述方式确保读取、写入和维护操作期间的一致性。附加地，使用集中式元数据服务确保一致的元数据和数据定义语言(DDL)操作。本文描述的HTAP系统能够通过使用元数据服务以存储模式版本LSN并分发到所有存储节点来处置分布式DDL操作。元数据服务可以被用于存储模式版本LSN并分发到所有存储节点。例如，集中式元数据服务将保存在存储器中并持久保存HTAP表和分区模式，以及用于表示其元数据版本的每个表的最新DDL LSN。在每个HTAP存储服务器上，受管理的分区还将保持其自己的元数据版本。

DDL更新可以经由以下步骤完成。来自OLTP的DDL操作(诸如创建表或模式更新)可以向HTAP存储装置发出带有LSN的DDL更新日志。元数据服务可以周期性地从OLTP中拉取DDL信息(例如，最新的DDL LSN)。如果存在改变，那么元数据服务可以首先将最新的LSN持久保存为元数据版本，然后它可以使用该LSN从OLTP目录中拉取最新的目录信息，如模式。在更新目录信息之后，元数据服务可以更新存储器中和持久保存的HTAP分区信息和统计表的对应条目。后面，DDL日志可以广播到所有分区，并且可以在到达增量存储库时由日志应用器应用。对于具有DDL影响的(多个)表的分区，其模式可以被相应地修改。对于其它分区，它们可以仅更新其元数据版本(更新到该DDL LSN)。

在扫描查询的编译期间，集中式协调器中的查询能够获取与read_LSN一致的元数据信息。因此，每个分区上的实际扫描任务可以将其read_LSN与该分区的元数据版本LSN进行比较，以确定该分区的当前元数据版本与查询的读取LSN是否一致。

例如，如果查询的read_LSN是1000并且元数据LSN是900，那么这意味着该查询是使用最新模式编译的并且该查询信誉良好。另一方面，如果在编译查询之后元数据被更新并提升至1100，那么分区版本LSN在扫描到达之前被相应地更新。在这种情况下，read_LSN可以是1000，而元数据是1100，这指示分区的模式已更新。可以用更新后的read_LSN重新编译扫描，以确保扫描始终读取模式与编译扫描时的模式一致的数据。

本文描述的HTAP系统提供：扫描功能以生成全局一致的扫描结果，该扫描功能由集中式编译服务(协调器)启用以从元数据服务检索读取LSN；启动扫描任务以检索分区上与读取LSN相关的数据的分布式查询执行环境；以及能够支持并发的插入、更新、删除、刷新、压缩和GC操作，同时仍然提供与读取LSN一致的扫描结果的存储系统。

对表的扫描可以作为每个分区的一个扫描任务进行分发，跨所有任务使用相同的读取LSN。步骤可以如下所示，以确保扫描是来自子任务的聚合结果。每个任务可以检索分区的确切数据，直到查询特定的读取LSN。首先，在从元数据服务获取DDL信息和读取LSN之后，查询可以在协调器中被编译。然后，查询可以创建扫描分布式任务，每个任务读取一个或多个分区。

例如，如果读取LSN是1000，那么每个查询子任务可以启动读客户端。客户端可以发起从该分区的复制品收集LSN的往返过程，然后选择具有大于或等于读取LSN或者最大LSN之一的LSN的复制品。这可以遵循上面讨论的quorum协议。例如，如果3个复制品保持LSN1100、1100、900，那么可以选择前两个复制品中的任何一个复制品。如果3个复制品保持900、900、800，这意味着最新更新不在这个分区的复制品上，那么我们选择最大的一个复制品，即，900。如果一个节点发生故障并且只有两个复制品返回结果，那么我们将选择具有较大LSN的一个复制品。

客户端可以将扫描请求发送到管理期望复制品的服务器。服务器上的扫描可以开始，直到该分区中小于或等于Read_LSN(1000)的所有日志都已应用于存储器中的增量存储库，即使这要求一小段等待时间。可以调用Gossip协议来填补LSN中的“洞”。扫描可以检查其read_LSN与该分区的元数据版本LSN。如果元数据LSN大于read_LSN，那么查询可以失败并重试。如果元数据版本是1100，那么这可以指示查询是使用旧版本的元数据编译的并且查询可能需要重新编译。

扫描可以从last_flush_LSN快照到其读取LSN(1000)读取增量存储库。可能需要检查删除散列图以过滤掉随后删除的行，使得它们不应当出现在快照中。例如，如果某行的插入LSN是800，而其删除LSN是900，两者都<1000，因此该行可以不出现在结果中。

扫描可以读取基本存储库上的刷新的数据。可以应用谓词过滤器和投影列来减少从盘扫描所需的数据。此外，可以检查基本存储库内的删除位图以排除被删除的行。基本存储库扫描的结果还需要基于行的主键匹配以及扫描行的read_LSN大于或等于删除行的delete_LSN来排除增量存储库的删除图中已删除的行。例如，如果某行的删除LSN是900(其小于1000)，那么可以不包括来自基本存储库中的这一行。组合的扫描结果可以返回给客户端。如果返回数据量大，那么可以使用多次往返的连续扫描。

虽然如上所述的技术默认情况下为混合事务和分析数据处理提供强数据一致性，但是可以附加地或备选地向希望基于每个用例调整一致性级别的用户提供灵活性。如果选择QUERY_DEFAULT，那么读取LSN是来自日志调度器的checkpoint_LSN。这个LSN之前的任何LSN都保证被HTAP存储装置接收并持久保存。元数据服务器可以周期性地从日志调度器获取checkpoint_LSN并对其高速缓存。如果直到checkpoint_LSN的日志已被持久保存，但尚未应用于存储器内的增量存储库，那么扫描任务理论上会出现延迟。对于希望以最少的等待时间获得强一致性的用户来说，这可以是默认模式和最常见的用例。

如果选择QUERY_LATEST，那么读取LSN是OLTP日志存储库中最新提交的LSN。与QUERY_DEFAULT相比，这种模式具有强一致性和更好的数据新鲜度，但是它与附加的延迟相关联，因为OLAP查询协调器必须等待直到checkpoint_LSN变得大于或等于该LSN才能执行查询以确保HTAP存储库已经具有到该LSN的日志。QUERY_DEFAULT中的理论延迟也适用于这种模式。

如果选择QUERY_DIRTY_READ，那么用户可以选择放宽数据一致性要求并选择对每个分区上的最新可用数据执行读取。扫描期间将不使用读取LSN，因此扫描期间不需要等待时间。这种模式中的扫描会体验到尽力而为的数据新鲜度和延迟，但是，在这种模式中会读取到早或晚的数据，而没有一致性保证。

如果选择READ_YOUR_WRITE，那么每个事务的提交LSN可以被传播回到发出它们的客户端会话。客户端会话可以使用这些LSN作为其后续OLAP查询的read_LSN。这为单个客户端提供了比其它模式更强的数据一致性和新鲜度，但会引入附加的等待时间，因为OLAP查询协调器必须等到checkpoint_LSN变得大于或等于该LSN才能执行查询，以确保HTAP存储库已经具有持久保存到该LSN的日志。QUERY_DEFAULT中的理论延迟也适用于这种模式。

图8图示了可以由HTAP系统(例如，如图3中所示的HTAP系统300)执行的示例过程800。HTAP系统可以执行过程800以确保HTAP系统中的强数据一致性。虽然在图8中被描绘为操作序列，但是本领域普通技术人员将认识到的是，各种实施例可以添加、移除、重新排序或修改所描绘的操作。

数据可以由第一计算系统实时地(或近实时地)捕获。第一计算系统可以是例如OLTP引擎(例如，OLTP引擎304)。在802处，可以基于由第一处理引擎捕获的数据来生成逻辑日志和与逻辑日志相关联的日志序列号(LSN)。LSN是指示存储状态的整数型递增数。例如，与特定逻辑日志相关联的LSN可以指示该逻辑日志的存储状态。

在804处，逻辑日志和LSN可以被传播到存储子系统。存储子系统可以被配置为与第一处理引擎和第二处理引擎通信。第二处理引擎可以例如被配置为执行在线分析处理(OLAP)。本文描述的HTAP系统的体系架构可以为OLAP查询提供新鲜/实时的数据改变。DML的逻辑日志可以在提交后立即从OLTP部件传播到OLAP部件。这些日志可以被分派到分布式分区并且可以经由存储器内操作连续应用于存储器内增量存储库，这通常非常快。逻辑日志携带的数据改变在应用于存储器内增量存储库后可以立即可用于OLAP查询。HTAP系统的体系架构可以利用跨HTAP系统的统一版本控制，从而保证数据的强一致性。HTAP系统的OLTP部件可以附加地支持快照隔离和其它(较弱的)一致性模型。

在806处，LSN和指示LSN模式版本的信息可以由元数据服务存储和分发。元数据服务可以将持久保存的LSN的进度存储在存储服务器上，并将其用作用于OLAP查询的read_LSN。元数据服务还可以存储模式LSN以支持DDL。第一处理引擎、第二处理引擎、存储子系统和元数据服务可以各自被模块化，并且可以各自支持用于维护数据一致性的LSN机制。例如，第一处理引擎、第二处理引擎、存储子系统和元数据服务中的每一这可以被配置为与更大的HTAP系统解耦，并用被配置为通过公共API扩展对LSN的支持的替代部件来替换。

图9图示了可以由HTAP系统(例如，如图3中所示的HTAP系统300)执行的示例过程900。HTAP系统可以执行过程900以确保HTAP系统中的强数据一致性。虽然在图9中被描绘为操作序列，但是本领域普通技术人员将认识到的是，各种实施例可以添加、移除、重新排序或修改所描绘的操作。

如上面所讨论的，为了保证HTAP系统中的强数据一致性，可以使用Quorum协议和/或Gossip协议来提供跨OLTP和OLAP引擎的全局快照隔离。利用Quorum协议和Gossip框架可以将单分区一致性读取和写入扩展到全局分布式集群中。具有复制的分区的数据可以跨集群中的多个数据节点被存储和/或访问。对于给定的分区，不同节点上可以有多个复制品，从而保留相同的数据以用于容错。

在902处，可以将Quorum协议应用于存储子系统的每个分区中的逻辑日志的复制品。可以应用Quorum协议来确保在读取和写入过程期间这些复制品之间的数据是一致的。Quorum是一种类型的技术，其可以用于在“分布式系统”中执行恒定功能或操作。它使用分布式事务，从分布式系统中获得最少选票。利用基于Quorum的数据一致性，读取和写入请求可以总是由多个健康节点(例如，节点中的两个或更多个节点)提供服务，并且跨集群的数据可以保持在一致状态。任何失败、损坏或缓慢的复制品都不会向外部客户端暴露任何数据正确性问题，诸如过时、脏、损坏的数据。

例如，上面关于图4描述的体系架构400利用2+2Quorum设置。每个分区由3个复制品/节点(节点402、404、406)提供服务。由框架400向所有3个复制品/节点402、404、406发送写入请求，其中2个成功之后写入成功。如图4中所示，发送到节点402和404的写入请求成功，并且发送到节点406的写入请求失败。但是，因为对于其中两个节点写入成功，所以写入仍然成功。在读取期间，框架400可以查询至少2个节点以请求数据状态，并选择具有满足读取一致性要求的数据的节点。由于存在至少2个保持最新写入的节点，因此我们可以容忍一个节点故障，但仍能确保读取成功且一致。如图4中所示，节点406发生故障，但其它节点402和404成功。因而，尽管节点406发生故障，读取仍然成功且一致。

除了Quorum算法之外，还可以利用Gossip协议来补救复制品之间的任何暂时不一致性。在904处，可以对存储子系统的每个分区中的逻辑日志的复制品应用Gossip协议。Gossip协议是基于流行病传播的方式进行的计算机对等通信的程序或过程。一些分布式系统使用对等Gossip来确保数据被散布到组的所有成员。例如，如果任何复制品由于诸如盘或网络故障之类的意外故障而落后于其它复制品，那么利用Gossip协议，复制品将在节点间消息交换期间赶上其对等体。

可以利用Quorum和Gossip协议来使集群中的分布式分区之间的数据保留在一致状态。此外，可以利用LSN机制来确保数据读取和写入在每个分区上本地一致。当在协调器中编译查询时，可以以全局LSN的形式计算查询的数据快照。全局LSN可以被分发到保持期望分区的每个节点，并且可以检索关于查询快照LSN的本地数据部分。因此，即使数据在协调器中的编译点之后被立即更新，也不会在每个节点上访问多于或少于必要的数据。

在单个分区上，可以利用日志序列号(LSN)。LSN是指示本地存储状态的整数型递增数。在906，可以由集中式编译服务从元数据服务检索查询的读取LSN。每个分区保留其自己的本地LSN，而LSN还可以表示跨所有分区的存储状态的全局和逻辑数据快照。例如，当存储装置具有LSN 100时，并且在数据的新插入到达之后，存储装置LSN将移动到101。

可以由协调器首先为查询分配来自元数据服务的全局read_LSN。在908处，可以将读取LSN分配给查询。全局read_LSN可以是编译查询时所有存储分区一直保存的LSN。然后可以将这个全局read_LSN发送到每个存储服务器以确定应当在每个分区上本地读取多少数据。例如，全局读取LSN 100将确切地检索每个分区上的数据，直到LSN 100。

在910处，可以启动扫描任务以基于读取LSN从存储子系统的分区检索数据。例如，OLAP引擎可以通过从元数据服务请求全局读取LSN并启动分布式扫描任务以使用这些读取LSN请求数据来协调OLAP查询。读取LSN可以确保扫描将跨所有分区检索数据直至读取LSN，组装针对直到读取LSN的数据的最终全局结果。多个LSN可以附加地包括以下中的一项或多项：用于保留活动查询的最小读取LSN的LSN、用于保留前一次刷新的结束点的LSN、以及用于指示下一次刷新的结束点的LSN。这些LSN保证每个分区上的扫描将与刷新操作并发地进行，并且仍然产生关于查询的读取LSN一致的结果。多个LSN可以附加地包括以下中的一项或多项：用于计算增量存储库数据可以被安全截断的点的LSN和用于指示哪些基本存储库块可以被安全截断的LSN。这些LSN另外确保了维护操作(诸如GC)将与扫描并发地进行。

图10图示了可以由HTAP系统(例如，如图3中所示的HTAP系统300)执行的示例过程1000。HTAP系统可以执行过程1000以确保HTAP系统中的强数据一致性。虽然在图10中被描绘为操作序列，但是本领域普通技术人员将认识到的是，各种实施例可以添加、移除、重新排序或修改所描绘的操作。

数据可以由第一计算系统实时地(或近实时地)捕获。第一计算系统可以是例如OLTP引擎(例如，OLTP引擎304)。在1002处，可以基于由第一处理引擎捕获的数据来生成逻辑日志和与逻辑日志相关联的日志序列号(LSN)。

在1004处，逻辑日志和LSN可以被传播到存储子系统。LSN是指示存储状态的整数型递增数。例如，与特定逻辑日志相关联的LSN可以指示该逻辑日志的存储状态。存储子系统可以被配置为与第一处理引擎和第二处理引擎通信。第二处理引擎可以例如被配置为执行在线分析处理(OLAP)。

逻辑日志和LSN可以被传播到存储子系统。存储子系统可以被配置为与第一处理引擎和第二处理引擎通信。第二处理引擎可以例如被配置为执行在线分析处理(OLAP)。本文描述的HTAP系统的体系架构可以为OLAP查询提供新鲜/实时的数据改变。DML的逻辑日志可以在提交后立即从OLTP部件传播到OLAP部件。这些日志可以被分派到分布式分区，并且可以经由存储器内操作连续应用于存储器内增量存储库，这通常非常快。由逻辑日志携带的数据改变在应用于存储器内增量存储库后可以立即可用于OLAP查询。HTAP系统的体系架构可以利用跨HTAP系统的统一版本控制，从而保证强数据一致性。HTAP系统的OLTP部件可以附加地支持快照隔离和其它(较弱的)一致性模型。

在1006处，LSN和指示LSN模式版本的信息可以由元数据服务存储。元数据服务可以将持久保存的LSN的进度存储在存储服务器上，并将其用作用于OLAP查询的read_LSN。元数据服务还可以存储模式LSN以支持DDL。

可以利用LSN机制来确保数据读取和写入在每个分区上本地一致。当在协调器中编译查询时，可以以全局LSN的形式计算用于查询的数据快照。全局LSN可以被分发到保持期望分区的每个节点，并且可以检索关于查询快照LSN的本地数据部分。因此，即使数据在协调器中的编译点之后被立即更新，也不会在每个节点上访问多于或少于必要的数据。

在单个分区上，可以利用日志序列号(LSN)。LSN是指示本地存储状态的整数型递增数。用于查询的读取LSN可以由集中式编译服务从元数据服务中检索。每个分区保留其自己的本地LSN，而LSN还可以表示跨所有分区的存储状态的全局和逻辑数据快照。例如，当存储装置具有LSN 100时，并且在数据的新插入到达之后，存储装置LSN将移动到101。

可以由协调器首先为查询分配来自元数据服务的全局read_LSN。在1008处，可以将读取LSN分配给查询。全局read_LSN可以是编译查询时所有存储分区一直保存的LSN。然后可以将这个全局read_LSN发送到每个存储服务器以确定应当在每个分区上本地读取多少数据。例如，全局读取LSN 100将确切地检索每个分区上的数据，直到LSN 100。

存储系统中的数据可以由于多次操作而不断改变。这些操作可以包括例如追加/删除、扫描、刷新、压缩和/或垃圾收集(GC)。在追加/删除操作期间，数据可以被添加到存储器内增量存储库的插入列表和删除列表。在扫描操作期间，可以相对于读取LSN从增量存储库和基本存储库读取当前数据。在刷新操作期间，数据可以从存储器刷新到盘。例如，当前数据可以从增量存储库移动到基本存储库。在压缩操作期间，可以重新组织基本存储库数据块。在垃圾收集操作期间，旧的和未使用的数据可以从增量存储库和/或基本存储库中移除。

可以应用多个LSN来指示这些操作的不同状态。在1010处，可以应用指示多个操作的状态的多个LSN，其中多个操作包括数据扫描、数据插入、数据删除、数据刷新、压缩和垃圾收集。利用这些LSN，数据扫描、更新和维护操作可以以并发且一致的方式一起工作，而不会彼此干扰。多个LSN可以包括每个查询的读取LSN以指示数据快照。该LSN可以确保扫描将跨所有分区检索数据，直到读取LSN，组装针对直到读取LSN的数据的最终全局结果。多个LSN可以附加地包括以下中的一项或多项：用于保留活动查询的最小读取LSN的LSN、用于保留前一次刷新的结束点的LSN、以及用于指示下一次刷新的结束点的LSN。这些LSN保证每个分区上的扫描将与刷新操作并发地进行，并且仍然产生关于查询的读取LSN的一致的结果。多个LSN可以附加地包括以下中的一项或多项：用于计算增量存储库数据可以被安全截断的点的LSN和用于指示哪些基本存储库块可以被安全截断的LSN。这些LSN确保维护操作(诸如GC)将与扫描并发地进行。

可以附加地或备选地向希望基于每个用例调整一致性级别的用户提供灵活性。在1012处，可以提供多个模式。多个模式可以由用户可选择。模式可以包括例如QUERY_DEFAULT、QUERY_LATEST、QUERY_DIRTY_READ、READ_YOUR_WRITE、和/或用户可以通过其选择期望的一致性级别的任何其它模式。

如果选择QUERY_DEFAULT，那么读取LSN是来自日志调度器的checkpoint_LSN。该LSN之前的任何LSN被保证由HTAP存储装置接收并持久保存。元数据服务器可以周期性地从日志调度器获取checkpoint_LSN并对其高速缓存。如果直至checkpoint_LSN的日志已被持久保存，但尚未应用于存储器内的增量存储库，那么扫描任务理论上会出现延迟。对于希望以最少的等待时间获得强一致性的用户来说，这可以是默认模式和最常见的用例。

如果选择QUERY_LATEST，那么读取LSN是OLTP日志存储库中最新提交的LSN。与QUERY_DEFAULT相比，这种模式具有强一致性和更好的数据新鲜度，但是它与附加的延迟相关联，因为OLAP查询协调器必须等待直到checkpoint_LSN变得大于或等于该LSN才能执行查询以确保HTAP存储库已经具有直到该LSN的日志。QUERY_DEFAULT中的理论延迟也适用于这种模式。

如果选择QUERY_DIRTY_READ，那么用户可以选择放宽数据一致性要求并选择对每个分区上的最新可用数据执行读取。扫描期间将不使用读取LSN，因此扫描期间不需要等待时间。这种模式中的扫描会体验到尽力而为的数据新鲜度和延迟，然而，在这种模式中会读取到早期或晚期的数据，而没有一致性保证。

如果选择READ_YOUR_WRITE，那么每个事务的提交LSN可以被传播回到发出它们的客户端会话。客户端会话可以使用这些LSN作为其后续OLAP查询的read_LSN。这为单个客户端提供了比其它模式更强的数据一致性和新鲜度，但会引入附加的等待时间，因为OLAP查询协调器必须等待直到checkpoint_LSN变得大于或等于该LSN才能执行查询，以确保HTAP存储库已经具有持久保存到直该LSN的日志。QUERY_DEFAULT中的理论延迟也适用于该模式。

图11图示了可以在各个方面使用的计算设备，诸如图1中描绘的服务、网络、模块和/或设备。关于图1的示例体系架构，云网络102、网络120、客户端设备104a-d、服务112、HTAP系统110和/或节点118可以各自由图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连接到其它计算节点。应该认识到的是，多个NIC 1122可以存在于计算设备1100中，将计算设备连接到其它类型的网络和远程计算机系统。

计算设备1100可以连接到为计算机提供非易失性存储的大容量存储设备1128。大容量存储设备1128可以存储系统程序、应用程序、其它程序模块和数据，这些已经在本文中更详细地描述。大容量存储设备1128可以通过连接到芯片组1106的存储控制器1124连接到计算设备1100。大容量存储设备1128可以由一个或多个物理存储单元组成。大容量存储设备1128可以包括管理部件1010。存储控制器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操作系统的版本。操作系统可以包括来自MICROSOFT公司的WINDOWS SERVER操作系统的版本。根据另外的方面，操作系统可以包括UNIX操作系统的版本。还可以利用各种移动电话操作系统，诸如IOS和ANDROID。应该认识到的是，也可以利用其它操作系统。大容量存储设备1128可以存储由计算设备1100使用的其它系统或应用程序和数据。

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

诸如图11中描绘的计算设备1100之类的计算设备也可以包括输入/输出控制器1132，用于接收和处理来自诸如键盘、鼠标、触摸板、触摸屏、电子手写笔或其它类型的输入设备之类的多个输入设备的输入。类似地，输入/输出控制器1132可以向诸如计算机监视器、平板显示器、数字投影仪、打印机、绘图仪或其它类型的输出设备之类的显示器提供输出。将认识到的是，计算设备1100可以不包括图11中所示的所有部件、可以包括图11中未明确示出的其它部件、或者可以利用与图11中所示的体系架构完全不同的体系架构。

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

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

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

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

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

描述了可以用于执行所描述的方法和系统的部件。当描述这些部件的组合、子集、交互、分组等时，应该理解的是，虽然可能没有明确描述对这些的各种单独和集体组合和排列中的每一者的具体参考，但对于所有方法和系统，每一者都在本文被具体考虑和描述。这适用于本申请的所有方面，包括但不限于所描述的方法中的操作。因此，如果存在可以执行的多种附加操作，那么应该理解的是，这些附加操作中的每一者都可以使用所描述的方法的任何具体实施例或实施例的组合来执行。

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

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

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

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

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

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

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

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

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

Claims (20)

1.一种系统，包括：

至少一个处理器；以及

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

基于由第一处理引擎捕获的数据生成逻辑日志和与所述逻辑日志相关联的日志序列号LSN，所述第一处理引擎被配置为执行在线事务处理；

将所述逻辑日志和所述LSN传播到存储装置，所述存储装置被配置为与所述第一处理引擎和第二处理引擎通信，所述第二处理引擎被配置为执行在线分析处理；

由元数据服务存储和分发所述LSN和指示LSN模式版本的信息；以及

其中所述第一处理引擎、所述第二处理引擎、所述存储装置和所述元数据服务被模块化，并且支持用于维护跨所述系统的数据一致性的LSN机制。

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

对所述存储装置的每个分区中的逻辑日志的复制品应用quorum协议，其中所述quorum协议在读取和写入过程期间维护所述复制品之间的数据一致性。

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

对所述存储装置的每个分区中的逻辑日志的复制品应用gossip协议，其中所述gossip协议解决所述复制品之间的暂时数据不一致性。

4.根据权利要求1所述的系统，其中LSN是指示存储状态的整数型递增数。

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

将读取LSN分配给来自所述元数据服务的查询，其中所述读取LSN与所述存储装置的每个分区一直保存到编译所述查询时的LSN相对应。

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

启动扫描任务，以用于基于所述读取LSN从所述存储装置的分区检索数据。

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

应用指示多个操作的状态的多个LSN，其中所述多个LSN使得所述多个操作能够以并发且连贯的方式一起工作，并且其中所述多个操作包括数据扫描、数据插入、数据删除、数据刷新、压缩和垃圾收集。

8.根据权利要求7所述的系统，其中所述多个LSN包括：

最小读取LSN，用于在所述存储装置中并发地执行数据扫描和将数据从增量存储库刷新到基本存储库，其中只有LSN小于所述最小读取LSN的数据才从所述增量存储库刷新到所述基本存储库；

前一次刷新LSN，指示先前刷新的最大LSN；

下一次刷新LSN，指示下一次刷新的最大LSN，所述下一次刷新LSN是在所述最小读取LSN与所述前一次刷新LSN之间选择的；以及

与从所述存储装置中移除旧数据的操作相关联的截断LSN，其中只有LSN小于所述截断LSN的数据才从所述存储装置中被移除。

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

集中式编译服务，被配置为从所述元数据服务检索针对任何特定查询的读取LSN。

10.根据权利要求1所述的系统，其中所述系统提供用户可选择的多个模式，所述多个模式与不同级别的数据一致性相对应。

11.一种方法，包括：

基于由第一处理引擎捕获的数据生成逻辑日志和与所述逻辑日志相关联的日志序列号LSN，所述第一处理引擎被配置为执行在线事务处理；

将所述逻辑日志和所述LSN传播到存储装置，所述存储装置被配置为与所述第一处理引擎和第二处理引擎通信，所述第二处理引擎被配置为执行在线分析处理；

由元数据服务存储和分发所述LSN和指示LSN模式版本的信息；以及

其中所述第一处理引擎、所述第二处理引擎、所述存储装置和所述元数据服务被模块化，并且支持用于维护跨所述第一处理引擎和所述第二处理引擎的数据一致性的LSN机制。

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

对所述存储装置的每个分区中的逻辑日志的复制品应用quorum协议，其中所述quorum协议在读取和写入过程期间维护所述复制品之间的数据一致性。

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

对所述存储装置的每个分区中的逻辑日志的复制品应用gossip协议，其中所述gossip协议解决所述复制品之间的暂时数据不一致性问题。

14.根据权利要求11所述的方法，其中LSN是指示存储状态的整数型递增数。

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

将读取LSN分配给来自所述元数据服务的查询，其中所述读取LSN与所述存储装置的每个分区已经一直保存到编译所述查询时的LSN相对应。

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

启动扫描任务，以用于基于所述读取LSN从所述存储装置的分区检索数据。

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

应用指示多个操作的状态的多个LSN，其中所述多个LSN使得所述多个操作能够以并发且连贯的方式一起工作，并且其中所述多个操作包括数据扫描、数据插入、数据删除、数据刷新、压缩和垃圾收集。

18.根据权利要求17所述的方法，其中所述多个LSN包括：

最小读取LSN，用于在所述存储装置中并发地执行数据扫描和将数据从增量存储库刷新到基本存储库，其中只有LSN小于最小读取LSN的数据才从所述增量存储库刷新到所述基本存储库；

前一次刷新LSN，指示先前刷新的最大LSN；

下一次刷新LSN，指示下一次刷新的最大LSN，所述下一次刷新LSN是在所述最小读取LSN与所述前一次刷新LSN之间选择的；以及

与从所述存储装置中移除旧数据的操作相关联的截断LSN，其中只有LSN小于所述截断LSN的数据才从所述存储装置中被移除。

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

提供用户可选择的多个模式，所述多个模式与不同级别的数据一致性相对应。

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

基于由第一处理引擎捕获的数据生成逻辑日志和与所述逻辑日志相关联的日志序列号LSN，所述第一处理引擎被配置为执行在线事务处理；

将所述逻辑日志和所述LSN传播到存储装置，所述存储装置被配置为与所述第一处理引擎和第二处理引擎通信，所述第二处理引擎被配置为执行在线分析处理；

由元数据服务存储和分发所述LSN和指示LSN模式版本的信息；以及

其中所述第一处理引擎、所述第二处理引擎、所述存储装置和所述元数据服务被模块化，并且支持用于维护跨所述第一处理引擎和所述第二处理引擎的数据一致性的LSN机制。