Presto的缓存机制

2022-02-14 00:00:00 数据节点缓存读取机制

近在Presto与Alluxio社区的通力合作下给Presto引擎带来了新的数据缓存机制，今天我们来分析一下这一部分的实现机制。

为什么

为什么Presto社区会开发这个缓存机制呢？我的理解是这样的: 在这个云计算时代，越来越流行的计算存储分离架构方式使得我们对计算需要的资源和存储需要的资源进行单独扩展，从扩展的角度这是很好的，但是副作用也是有的，它使得原本很近的计算和存储变远了。计算引擎要获取与之前同等大小的数据比之前的代价大了。在计算和存储分离的情况下，用户的数据往往保存在阿里云OSS或者AWS S3这些Blob存储上，如果要想以足够快的速度从Blob存储服务获取数据，我们需要计算引擎和存储之间有足够大的带宽，如果带宽资源不够，整个查询的性能就不会很好。那么这时缓存机制就可以发挥作用了，只要用户的查询有一定的重复性，那么部分数据就可以直接从本地缓存获取，省去从远端存储获取的时间，提高查询的性能。

Presto缓存的整体架构

Presto为缓存添加了一个新的模块: presto-cache, presto-hive 与 presto-cache 之间的交互流程大概是这样的:

虽然presto-cache这个名字听起来好像可以作用于所有的connector，但是从实际实现来看，只有presto-hive connector会与presto-cache模块有交互。在Presto缓存被引入之前 BackgroundHiveSplitLoader 使用底层的文件系统(比如对于阿里云的OSS, 它是AliyunOssFileSystem)直接进行数据的读写；引入了Presto缓存机制之后，底层的文件系统被被CachingFileSystem 代理一层:

// HiveCachingHdfsConfiguration.java
Configuration config = new CachingJobConf((factoryConfig, factoryUri) -> {
    try {
        FileSystem fileSystem = (new Path(factoryUri)).getFileSystem(hiveHdfsConfiguration.getConfiguration(context, factoryUri));
        checkState(fileSystem instanceof ExtendedFileSystem);
        return cacheFactory.createCachingFileSystem(
                factoryConfig,
                factoryUri,
                (ExtendedFileSystem) fileSystem,
                cacheManager,
                cacheConfig.isCachingEnabled(),
                cacheConfig.getCacheType(),
                cacheConfig.isValidationEnabled());
    }
    catch (IOException e) {
        throw new PrestoException(GENERIC_INTERNAL_ERROR, "cannot create caching file system", e);
    }
});

相关文章