CN115905306B - 一种面向olap分析数据库的本地缓存方法、设备及介质 - Google Patents

Abstract

本申请公开了一种面向OLAP分析数据库的本地缓存方法、设备及介质，用以解决如下技术问题：在不增加整体架构复杂性的前提下，保证缓存数据的查询性能。方法包括：OLAP分析引擎trino确定待读取数据；判断所述待读取数据是否存在于本地缓存；若否，则通过底层文件系统从远端存储系统读取所述待读取数据，并将所述待读取数据缓存到本地缓存。本申请通过上述方法一方面提高了重复性的数据查询的性能，另一方面可以降低计算引擎对于带宽的要求。

Description

一种面向OLAP分析数据库的本地缓存方法、设备及介质

技术领域

本申请涉及IT数据库研发技术领域，尤其涉及一种面向OLAP分析数据库的本地缓存方法、设备及介质。

背景技术

在云计算时代，越来越流行的计算存储分离架构方式使得对计算需要的资源和存储需要的资源进行单独扩展，从扩展的角度这是很好的，但是副作用也是有的，它使得原本很近的计算和存储变远了。计算引擎要获取与之前同等大小的数据比之前的代价大了。

在计算和存储分离的情况下，用户的数据往往保存在第三方云存储上，如果要想以足够快的速度从云存储服务获取数据，就需要计算引擎和存储之间有足够大的带宽，如果带宽资源不够，整个查询的性能就不会理想，但如果采用类似Alluxio独立的缓存系统，这样又会使整体架构越来越复杂。

发明内容

本申请实施例提供了一种面向OLAP分析数据库的本地缓存方法、设备及介质，用以解决如下技术问题：在不增加整体架构复杂性的前提下，保证缓存数据的查询性能。

第一方面，本申请实施例提供了一种面向OLAP分析数据库的本地缓存方法，所述方法包括：OLAP分析引擎trino确定待读取数据；判断所述待读取数据是否存在于本地缓存；若否，则通过底层文件系统从远端存储系统读取所述待读取数据，并将所述待读取数据缓存到本地缓存。

在本申请说明书一个或多个实施例中，在OLAP分析引擎trino确定待读取数据之后，所述方法还包括：确定所述待读取数据存在于所述本地缓存；直接从所述本地缓存读取所述待读取数据。

在本申请说明书一个或多个实施例中，在确定所述待读取数据存在于所述本地缓存之后，所述方法还包括：打开OLAP分析引擎trino的高速缓冲存储器cache，以切换到使用缓存文件系统；通过所述缓存文件系统中的底层缓存引擎，从所述本地缓存中读取所述待读取数据。

在本申请说明书一个或多个实施例中，在通过底层文件系统从远端存储系统读取所述待读取数据之后，所述方法还包括：通过所述缓存文件系统中的底层缓存引擎，将所述待读取数据写入所述本地缓存；其中，所述底层缓存引擎采用AlluxioCachingFileSystem实现。

在本申请说明书一个或多个实施例中，在将所述待读取数据缓存到本地缓存之前，所述方法还包括：生成扩展文件接口，所述扩展文件接口用于兼容原始文件系统；在所述扩展文件接口中增加传递参数，所述传递参数用于指示所述待读取数据是否可以被缓存；通过所述底层缓存引擎读取所述传递参数，并根据所述传递参数的取值，确定是否将所述待读取数据进行缓存。

在本申请说明书一个或多个实施例中，所述传递参数采用HiveFileContext参数，所述HiveFileContext参数的取值为0或者1。

在本申请说明书一个或多个实施例中，将所述待读取数据缓存到本地缓存之后，所述方法还包括：确定新的待读取数据，并判断所述新的待读取数据与所述待读取数据是否属于同一文件；若是，则将所述新的待读取数据对应的读取请求，分配给执行所述待读取数据对应的读取请求的节点。

在本申请说明书一个或多个实施例中，在将所述新的待读取数据对应的读取请求，分配给执行所述待读取数据对应的读取请求的节点之前，所述方法还包括：确定所述节点拥有的Split数量；其中，所述Split用于指示所述节点读取和处理的数据段；在所述Split数量小于所述节点对应的上限值时，确定所述节点空闲。

第二方面，本申请实施例还提供了一种面向OLAP分析数据库的本地缓存设备，所述设备包括：处理器；以及存储器，其上存储有可执行指令，当所述可执行指令被执行时，使得所述处理器执行如上述的一种面向OLAP分析数据库的本地缓存方法。

第三方面，本申请实施例还提供了一种非易失性计算机存储介质，其上存储有计算机可执行指令，所述计算机可执行指令被配置为执行如上述的一种面向OLAP分析数据库的本地缓存方法。

本申请实施例提供的一种面向OLAP分析数据库的本地缓存方法、设备及介质，具有以下有益效果：OLAP分析引擎Trino第一次读取数据的时候按照文件需要读取的开端offset和长度length，以细粒度Page(通常1MB)为单位从分布式缓存系统HDFS缓存在本地磁盘，第二次访问的时候，直接从本地节点的缓存访问，而不需要再远程读取数据，在不增加系统架构复杂度的前提下，大大提升了重复性数据查询的性能，同时降低了资源消耗，也降低了计算引擎对于底层Blob Storage的带宽需求，能够更好的满足业务需求。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种面向OLAP分析数据库的本地缓存方法流程图；

图2为本申请实施例提供的一种应用场景下，读取数据流程图；

图3为本申请实施例提供的一种面向OLAP分析数据库的本地缓存设备结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在云计算时代，越来越流行的计算存储分离架构方式使得对计算需要的资源和存储需要的资源进行单独扩展，从扩展的角度这是很好的，但是副作用也是有的，它使得原本很近的计算和存储变远了。计算引擎要获取与之前同等大小的数据比之前的代价大了。

在计算和存储分离的情况下，用户的数据往往保存在阿里云OSS或者AWS S3这些廉价的云存储上，如果要想以足够快的速度从云存储服务获取数据，就需要计算引擎和存储之间有足够大的带宽，如果带宽资源不够，整个数据查询的性能就不会理想。那么这时缓存机制就可以发挥作用了，只要用户的查询有一定的重复性，那么部分数据就可以直接从本地缓存获取，省去从远端存储获取的时间，提高查询的性能，而性能能否提升取决于要访问的数据是否事先缓存到了本地，因此是否使用本地缓存成为了一项极为重要的OLAP分析引擎trino查询性能优化技术。

在做标准的tpcds-10T数据量性能测试时发现，其SQL脚本中出现了大量的子查询，通过收集trino的血缘信息，发现少数表会被反复读取，对这些被反复使用的表如果能Cache到缓存中，每次读取时直接从缓存里读取而不用每次读磁盘，则能大大提高查询性能，但由于如果单独布署一套独立于OLAP分析引擎之外的一套缓存系统，会大大增加系统的复杂度与性能开销，因此，本申请实施例将缓存系统作为一个插件或依赖整合到OLAP分析引擎Trino中去，在提升数据读取性能的同时又没有增加系统的复杂性。

下面通过附图对本申请实施例提出的技术方案进行详细的说明。

图1为本申请实施例提供的一种面向OLAP分析数据库的本地缓存方法流程图。如图1所示，本申请实施例中的本地缓存方法，至少包括以下执行步骤：

步骤101、确定待读取数据。

本申请实施例提供的本地缓存方法，是基于OLAP分析数据库提出的，在该方法开始执行时，首先要确定待读取的数据，也即需要读取的数据。这里的待读取数据可以由OLA片的分析引擎trino根据接收到的数据读取请求确定。

步骤102、判断待读取数据是否存在于本地缓存。

在确定待读取数据之后，需要判断该数据在本地缓存中是否存在，所谓本地缓存就是指OLAP分析数据库的本地磁盘中。此处的判断过程可以是数据查询过程，查询该待读取是否被缓存。

步骤103、若否，则通过底层文件系统从远端存储系统读取待读取数据。

如果在本地缓存中没有查询到该待读取数据，也即该待读取数据不存在于本地缓存中，则trino通过底层文件系统向远端存储系统请求数据，以获得待读取数据。

在本申请的一个示例中，前述远端存储系统可以是远端的存储云等，其区别于本地缓存，需要进行数据的传输才能使trino获取到待读取数据。

步骤104、将待读取数据缓存到本地缓存。

在读取到待读取数据之后，为了便于后续的数据查询，将该待读取数据存储到本地缓存中。

为了更加清楚详细的对本申请的方案进行解释，基于图1的方法，本说明书还提供了该方法的一些具体实施方案和扩展方案，下面继续进行说明。

在本申请实施例的一种或多种可能实现方式中，如果前述判断待读取数据是否存在于本地缓存的结果为是，则说明之前已经查询或者读取过该待读取数据了，此时，可以直接在本地缓存中读取该待读取数据，而不需要再向远端存储系统读取数据了，提升了数据重复性查询的性能。

本申请中的本地缓存方法，主要是通过在OLAP分析数据库中增加一个新的trino-cache模块，使其与现有的trino-iceberg模块进行交互，通过访问文件系统时使用扩展文件系统(ExtendedFileSystem)创建的代理层，根据高速缓冲存储器cache的开启和关闭在缓存文件系统和原始文件系统中进行切换。因此，本申请实施例中，在本地缓存中读取待读取数据，具体可通过如下方式实现：首先打开OLAP分析引擎trino的cache，将文件系统切换到使用缓存文件系统，由于缓存文件系统下包括如下两个底层缓存引擎：AlluxioCachingFileSystem以及FileMergeCachingFileSystem；因此，可通过底层缓存引擎AlluxioCachingFileSystem，使用Alluxio的本地缓存进行待读取数据的读取。

需要说明的是，前述底层缓存引擎FileMergeCachingFileSystem属于纯手工打造的缓存实现，使用率较低或基本不使用。

进一步地，由于本申请实施例中的缓存管理、数据写入、淘汰等维护管理任务均交给Alluxio-client去处理，因此，在将待读取数据写入本地缓存时，也是通过底层缓存引擎AlluxioCachingFileSystem，使用Alluxio的本地缓存进行待读取数据的写入。

在本申请实施例的一种或多种可能实现方式中，因为增加了缓存文件系统，就需要考虑原始文件系统的兼容性问题，也即，如何兼容原始文件系统的访问并实现缓存的目的。针对引入的这一问题，本申请实施例通过引入传递参数解决。具体地，在将待读取数据缓存到本地缓存之前，首先生成一个扩展文件的接口，并在这个扩展文件接口中增加传递参数，该传递参数用来传递当前读取的数据或文件是否可以被缓存的上下文信息。当通过底层缓存引擎读取到待读取数据时，获取该传递参数并确定此时传递参数的取值，如若此时的取值指示当前读取的数据或者文件可以被缓存，则走缓存文件系统，将该待读取数据进行缓存。

在本申请的一个示例中，前述传递参数可以采用HiveFileContext参数实现，该HiveFileContext参数的取值为0或者1，也即，在HiveFileContext参数的取值为0时，代表当前读取的数据或者文件不可以被缓存，而在HiveFileContext参数的取值为1时，则代表当前读取的数据或者文件可以被缓存。

例如，将OLAP分析数据库中Hadoop的FileSystem扩展成

ExtendedFileSystem，并统一使用生成的扩展文件接口。扩展最主要的目的是加

入了openFile的方法，跟普通的FileSystem#openFile不同的是，本申请实施5例中的openFile方法添加了一个HiveFileContext参数，该参数并不是Hadoop FileSystem标准API的一部分，添加这个参数是为了传递当前要读取的文件或数据是否可以被缓存的上下文信息。如果当前要读取的文件或数据是可以被缓存的，那么底层缓存引擎会走缓存的代码路径，否则的话就走普通的代码路径。

最后，在底层缓存引擎AlluxioCachingFileSystem里面，会使用通过0HiveFileContext传递过来的缓存与否的信息判断是否走缓存逻辑，如果可以被

缓存，则走缓存文件系统进行缓存，否则直接走底层文件系统。

在本申请实施例的一种或多种可能实现方式中，在完成一次数据读取之后，如果接收到新的数据读取请求，请求读取新的待读取数据，本申请实施例会首

先判断当前的新的待读取数据与之前的待读取数据是否属于同一个文件，若是，5则将读取新的待读取数据的请求处理任务分配给之前处理读取待读取数据任

务的节点。这种任务分配机制被称为亲和性任务分配机制，引入该机制是为了打造出一个性能良好的缓存，不断提高缓存的命中率。也即，本申请中，对于同一个文件的读取请求，尽量分配给相同的节点进行处理，这样才能保证第一次放入缓存的数据会被后续的读取请求利用上。

0进一步地，在前述读取请求分配过程之前，需要先确定想要分配的节点是

否空闲，以避免该节点被占用不能执行当前的数据读取任务，具体地，首先确定该节点目前拥有Split的数量，然后将该数量与该节点对应的上限值进行比较，若当前拥有的Split数量并未达到上限值，则说明该节点此时空闲，还可

以进行任务执行，此时，将读取新的待读取数据的任务分配给该节点。在本申5请的一个示例中，前述Split在trino中描述的是当前节点读取或者处理的数据

段，并且，该Split也是并行执行与任务分配的单元。

在本申请实施例的一种或多种可能实现方式中，对于想要分配数据读取任务的指定节点的计算，采用Hash+mod的调度方式实现算法，但在这种方式下，如果集群中的某个节点失联或者下线down掉，那么Split到该节点的映射就会全部失效，需要全部进行重新分配，这样就导致缓存的命中率大幅下降，同时，如果出现问题的节点在重新上线恢复正常之后，也需要再次重新进行Split到节点的映射分配，因此，为解决这个问题，本申请实施例中会引入一致性哈希算法，尽可能降低节点扩缩容时对现有节点缓存命中率的影响。需要说明的是，此处引入的一致性哈希算法实现的功能可以使用现有的哈希算法实现，故本申请实施例在此不做赘述。

还需要说明的是，本申请实施例中的Trino缓存的实现，并不会通过一个类似Alluxio的单独集群来对数据进行缓存，而是在Trino节点本地利用磁盘进行了数据的缓存，因此称为Trino本地缓存。

图2为本申请实施例提供的一种应用场景下，读取数据流程图。如图2所示，当OLAP分析引擎trino需要读取数据时，首先会读取请求数据的请求，然后基于这个请求去查看被请求的数据是否被缓存，如果被请求的数据被缓存，则直接在本地缓存，从cache中读取数据返回给trino进行处理，而如果被请求的数据没有被缓存，则向远端存储系统读取被请求的数据，并将读取后的数据写入本地缓存，之后，再从本地缓存的cache中读取数据返回给trino进行处理。

另外，如图2所示，前述远端存储系统可以是诸如minio、hdfs、obs、oss或者s3的存储系统。

在本申请实施例提供的一种面向OLAP分析数据库的本地缓存方法，得益于软亲和性的调度策略，第一次访问的时候按照文件需要读取的开端offset和长度length，以细粒度Page(通常1MB)为单位从分布式缓存HDFS缓存在本地磁盘，当第二次访问的时候，就可以直接从本地节点的缓存访问，而不需要再远程读取数据，避免了对传输数据带宽的要求，以此实现了在不增加系统架构复杂度的前提下，提升重复性数据查询的性能。另外，相较于传统的使用Alluxio需要部署一整套Alluxio集群，本申请实施例中使用trino本地缓存只需要一个jar包就可以实现，减少了资源的使用，并且轻量级仅本地节点访问的缓存，将数据缓存在计算Node的本地ssd中，还可以不用考虑集群节点之间的数据共享问题，同时，对于trino来说，在性能、易使用、易维护方面也都比Alluxio优秀。

以上为本申请实施例中的方法实施例，基于同样的发明构思，本申请实施例还提供了一种面向OLAP分析数据库的本地缓存设备，其结构如图3所示。

图3为本申请实施例提供的一种面向OLAP分析数据库的本地缓存设备结构图。如图3所示，设备包括：处理器，以及存储器，其上存储有可执行指令，当所述可执行指令被执行时，使得所述处理器执行如上述的一种面向OLAP分析数据库的本地缓存方法。

在本申请实施例的一种或多种可能实现方式中，处理器用于，OLAP分析引擎trino确定待读取数据；判断所述待读取数据是否存在于本地缓存；若否，则通过底层文件系统从远端存储系统读取所述待读取数据，并将所述待读取数据缓存到本地缓存。

除此之外，本申请实施例还提供了一种非易失性计算机存储介质，其上存储有计算机可执行指令，所述计算机可执行指令被配置为执行如上述的一种面向OLAP分析数据库的本地缓存方法。

在本申请实施例的一种或多种可能实现方式中，计算机可执行指令被配置为，OLAP分析引擎trino确定待读取数据；判断所述待读取数据是否存在于本地缓存；若否，则通过底层文件系统从远端存储系统读取所述待读取数据，并将所述待读取数据缓存到本地缓存。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (4)

1.一种面向OLAP分析数据库的本地缓存方法，其特征在于，所述方法包括：

OLAP分析引擎trino确定待读取数据；

判断所述待读取数据是否存在于本地缓存；

若否，则通过底层文件系统从远端存储系统读取所述待读取数据，并将所述待读取数据缓存到本地缓存；

若是，则打开OLAP分析引擎trino的高速缓冲存储器cache，以切换到使用缓存文件系统，通过所述缓存文件系统中的底层缓存引擎，从所述本地缓存中读取所述待读取数据；

此时，将所述待读取数据缓存到本地缓存，具体为，通过所述缓存文件系统中的底层缓存引擎，将所述待读取数据写入所述本地缓存，其中，所述底层缓存引擎采用AlluxioCachingFileSystem实现；

在将所述待读取数据缓存到本地缓存之前，所述方法还包括：生成扩展文件接口，所述扩展文件接口用于兼容原始文件系统，在所述扩展文件接口中增加传递参数，所述传递参数用于指示所述待读取数据是否可以被缓存，通过所述底层缓存引擎读取所述传递参数，并根据所述传递参数的取值，确定是否将所述待读取数据进行缓存，所述传递参数采用HiveFileContext参数，所述HiveFileContext参数的取值为0或者1；

在将所述待读取数据缓存到本地缓存之后，所述方法还包括：确定新的待读取数据，并判断所述新的待读取数据与所述待读取数据是否属于同一文件，若是，则确定执行所述待读取数据对应的读取请求的节点拥有的Split的数量，其中，所述Split用于指示所述节点读取和处理的数据段，在所述Split的数量小于所述节点对应的上限值时，确定所述节点空闲，并将所述新的待读取数据对应的读取请求，分配给所述节点。

2.根据权利要求1所述的一种面向OLAP分析数据库的本地缓存方法，其特征在于，在OLAP分析引擎trino确定待读取数据之后，所述方法还包括：

确定所述待读取数据存在于所述本地缓存；

直接从所述本地缓存读取所述待读取数据。

3.一种面向OLAP分析数据库的本地缓存设备，其特征在于，所述设备包括：

处理器；

以及存储器，其上存储有可执行指令，当所述可执行指令被执行时，使得所述处理器执行如权利要求1-2任一项所述的一种面向OLAP分析数据库的本地缓存方法。

4.一种非易失性计算机存储介质，其上存储有计算机可执行指令，其特征在于，所述计算机可执行指令被配置为执行如权利要求1-2任一项所述的一种面向OLAP分析数据库的本地缓存方法。