雁栖学堂--湖存储直播第三期原创

各位云家社区的朋友们好，很高兴在这里向大家介绍goods f table管理和缓存预热能力。首先呢，我做一个个人介绍，呃，我2020年加入腾讯云对象存储团队，并且一直致力于数据库存储方向的技术研发工作，曾就职于百度应从事分布式文件存储研发工作，目前作为故SFS的核心研发工程师，主导设计和研发了gus FS的新特性，同时也活跃于Lou社区，并作为contribute。嗯，接下来呢，我主要是围绕故SFS的业务场景介绍，故SFS大数据table管理的介绍，以及故SFS的缓存预热能力介绍三部分来进行呃讲解。首先呢，故FS的业务场景，呃的一个架构图是这个样子的，那我们cos团队呢，就是腾讯云cos，呃也推出了三级加速，用于呃适配于用户的大数据AI等呃用户的一些场景，首先故SFS是存在于计算端的，用于计算端的缓存加速。

它可以通过将远程的存储数呃，远程的呃数据呃呃预存到计算端，从而带来像访问本地的磁盘一样的读写性能。嗯，同时呢，呃，Cos也推出了cos的加速器，那它是AC，它是在AC端的。他通过高性能的介质为用户的数据带来很高的一个数据访问能力。那其次呢，呃，为了解决对象存储，呃本身的一个rename跟list的这种呃嗯性能问题，那我我我们也推出了原数据的一个加速的一个能力，那这个是存在于存储端，那它可以提供进文件系统语义的这种，呃，Rename跟list的原数据访问的一个性能，那通过三个三层加速的一个配合呢，我们可以在原来的基础上提升两到十倍的性能。

那从这个架构图中可以看出，我们公司FS是存在于计算端的，直接对接于用户的大数据场景跟AI场景。那它呢？呃，是有智能缓存对，同时也支持高可用架构以及集群化的一个部署，同时我们也会具备监控告警，健全认证，如acl或ranger健全以及云日志管理等能力。接下来我们主要围绕智能呃缓存来进行介绍。首先呢，我们介绍一下故事，FS的table管理。

那推步管理的一个适用场景呢？首先是说它主要是针对于SQL查询类的一个场景。那用户可以通过goods table的一个预热能力呢，就是数据的预热能力呢，可以对用户本身的一个。Table表的一个信息或者是数据。进行呃，性能这样的一个加速。那我们可以看一下下面的这个架构。首先呢，呃，用户的还还达store中呢，是有多个DB的。那每个DB中呢，也是有多个table的。那每个table是存在于，就是每个table的数据是存在于cos上的，并且与并且以table name，呃为命名的一个目录中存储的。那这个table下的呃子目录呢，也有可能存呃存储有呃这个table所对应的呃一些partition。

的一些数据。那呃，那我们呢，可以通过将cos，呃，通过创建name space的方式，将cos的这个嗯，Table的一个副目录呢，挂载到我们故事FS中。然后呢，我们故SFS也可以去挂载have ma store，就是用户的have ma store，从而获得这个have ma中的原数据信息。通过将原数据以及数据都挂载到故事FS呢，我们就可以做很多table相关管理的事情。那所以这个功能呢，也会支持说通过goods FS查询一些表的信息，就是用户的还mad的DB信息以及表信息以及partition信息都是可以支持的，同时呢，它也可以支持按照table，就是这个table以及partition的这个力度，将呃对应的数据预热到我们的故事FS中，从而给用户提供嗯。高性能的一个数据访问能力。

那我们接下来来看一下table功能的一个使用流程，那我这边呢，去mark了一个呃表。那这个表的location呢，是在可以看到，是在cosn的1DEMO目录下面的。那首先我们需要去呃将这个呃location，就是表的这个存储路径呢，挂载到我们SFS上，我们通过呃上一期介绍的这个呃name space特性呢，我们将它。去挂载到我们的故事FS中，并且挂载的目录是靠test。接下来呢，我们需要将远程的，就是用户的这个have。嗯。Have DB去挂载到我们的故事FS中。我们通过attach database。这边也会有相应的一些命令的用法，嗯，对，我们可以通过good FS的table touch TV去进行，呃，将去进行挂载，将用户的have，呃的DB去挂载到我们的故SFS中。啊，具体的命令就是这。

那这个goods FS DB呢，就代表嗯，在goods FS中这个table，这个DB的名字，呃，这个后面我们会呃详细的用DEMO的方式向大家更更直观的去去展示出来。那同时呢，我们挂载好了之后呢，我们就可以对这个DB以及用户的这个数据进行一个调度或者是一些操作，比如说我可以通过故事FS去查询用户的这个log test这个表的一个详细的呃信息表信息，然后我们也可以通过呃，Table load呢去缓存用户的表信息到我们的库SFS中，同时呢，也可以支持释放。最后用户用完了之后呢，那我们也可以支持将这个DB，就是have的这个DB从我们公司FS中呃，Detach掉。那接下来我们可以看一下这个DEMO，更形象的去感受一下它。

首先呢，我们可以通过一个namespace命令呢，去创建一个呃，Namespa，那这个namespace的呃。路径呢，就是我们刚刚提到的这个。Table的副目录的路径，嗯，叫做呃，DEMO的这个路径，那挂载到我们ofs中呢，路径呢是cost test，可以看到挂载成功之后呢，它会有这样一个提示。嗯，然后呢，F挂载用户的have DB的命令呢，就是f table，它是DB，按照这样的形式去填充自己的DB信息就可以，那可以看到这个弹幕中呢，我是以，嗯呃，我我我是以。呃，Gus FS DEMO的形式去挂载到我们的gus FS中，那挂载的呃用户的这个DB名字呢，就是default，可以看到default，然后have的server的一个呃，IP以及port。

进行挂载，那可以看到。提示信息中呢，是有一个table已经更新成功了，原因是说我这个DB中，呃，因为只是DEMO嘛，所以我创建了一个table叫做log test。它也提示可以挂载成功了，接下来呢，我就可以通过故事FS对这个表进行查询了，嗯，它具体的命令就是故FS table is加，就是刚刚创建的这个。在过FS中，这个DB的名字叫做过SFSDEMO啊，可以看到呢，这个DB中呢，只有一个table表，就是刚刚我创建的。接下来呢，我们也可以通过呃呃，Table ls加上DB的名字，以及呃以及table的名字呢，我们可以查询这个table的一个详细信息，从图中可以看出这个table就是叫做log test。并且它有两个字段，以及它通过log进行partition划分的。

同时location呢，是存在于我们的cost test log test这个呃，目录下的。同时呢，它也标志出呃，标记出了这个part partition name的都有哪些，以及partition所对应的的一些信息。那接下来呢，我们会介绍故事，FS的一个预热能力。那故事FS的一个加速形态呢，主要是以下几种方式，首先是动态缓存，那它的嗯，工作原则呢，就是边读边缓存以及编写边缓存，那边读边缓存呢，它主要适用于加速数据重复读的一个场景，就是我通过第一次，呃。有一些延迟的读，将数据读到。开始中之后呢，嗯，我们接下来的重复读就会直接从我们的缓存中直接读取。

从而带来性能的提升。那边写边缓存呢，是适用于加速，呃，写后读取的场景，就是我从通过故事FS写入，那写入的时候呢，也会写入到我们的缓存中，那接下来去读取我刚刚写入的数据的时候呢，也会直接通过命中缓存的方式去读取，从而提供很高的一个访问性能。但是呢，在实际的应用场景中呢，我们发现以上的这个策略呢，在以下的两种场景中表现的并不是很好，第一种是非重复读的SQL类作业。对，因为数据只数据集呢，它只读一次，所以无法为后续的这个读取呢带来命中。那第二种场景呢，就是基于容器的AI训练场景，它的这个模型呢，是属于延迟很敏感，所以它无法接受，就是我们首次读取的时候，缓存的时候的一个高延迟的一个读。

为此呢，我们针对于以上的两种场景呢，也推出了这种预热的方式。首先呢，呃，我们介绍一下table跟partition力度的数据预热。那刚刚呢，我们其实也介绍了table的一个呃，一个挂载以及管理的一个呃能力，那我们通过呃，刚刚的那个操作呢，其实我们已经把这个table挂载到了我们F中。嗯，接下来呢，我们就可以对这个table呢，进行缓存的一个预热。那它这个应用场景呢，就是呃，针对于这种。按照table跟partition力度，就是访问的这种circle类作业，嗯，进行加速。那我们可以看一下下面的这个某个用户的一个circle类作业的一个呃，方案架构。那首先呢，就是我们可以介绍一下这个它的一个大概的一个访问模型，就是呃，这个是离线日志分析的一个作业，那它通常呢，是将同一天的数据划分到一个table中。

呃，一个table的一个同一个分区中，比方说这个DATA1的这个分区，那呃，对应的这个文件存储呢，就是存储在cos上的这个table name杠，呃，DATA1这个目录中。那用户的一个，呃，作业的一个访问规律呢，就是他会访访问近一天或者是几天的一个离线日志。呃，离线日志的一个数据，那我们拿到了这个规律呢，就可以对呃，用户即将要访问的partition。进行一个智能化的缓存调度，就是在呃用户作业运行之前呢，我们先把这个将要访问的这些partition的数据呢，呃，通过智能调度呢，去缓存到我们故事FS中。那当用户的作业真实的，呃，真正的去运行的时候呢，他就通过很高命中率的访问去访问到我们故事FS中，这样的话会给他的作业带来很高的一个访问性能。

那呃，Table的跟partition的这个预热功能呢，我们是支持table力度，或者是table的某一个partition力度的一个数据的缓存预热和释放，同时呢，我们也支持这个预热任务的一个查询以及取消等管控操作。那它具体的一个用法呢，就是通过gus FS的table命令。那呃，通过漏的方式去，呃，对这个某个DB的某个table。呃呃，某个partition，当然了，这个当然是可选的，你也可以通过呃直接对整个table进行预热，然后同时呢，也可以支持。多副本的一个预预热。啊，那free free的这个命令呢，就是我也可以通过，呃，我我我也可以通过free命令去对我预热上来的数据呢，呃，进行按照table力度或者partition力度，呃，进行数据的一个释放。

那job state job ID呢？就是在我们发起命令之后，我们可以通过。查询，通过这个job ID查询这个job运行的一个进度以及状态，那通过呃，Cancel呢，就是job cancel呢，我们也可以取消这个预热的任务。那接下来我们可以看一下这个真实的一个预热的功能的一个DEMO。首先呢，呃，我们第一步是预热整个table的一个数据，那预热的操作呢，就是通过s FS table load，然后可以看到这里我是呃，Load了gus fste。的某一个table的表，就是叫log test，这个也是刚刚我们Mo出来的一个table。对，那可以看到下面的一个日，呃，一个返回信息呢，就是说这个任务已经提交，异步落的任务已经提交成功了，并且它的招牌ID是这个。

那这个时候呢，我们就可以通过boos FS job state加上这个job ID呢，去查询这个job的一个运行状态，那我们可以看到它已经完成了complete。对的。嗯，接下来呢，我们可以通过goods f table state去查看一下，呃，整个table的一个呃，数据缓存。的一个占用，就是空间占用的一个信息，我们可以看到这个返回的信息，是说这个table呢，一共在我们中有两个文件。那两个文件的呃，总大小就是这么多，并且呃，在FS中呢，它。呃，它呃，并且缓存在gus FS中，数据呢，百分比呢是100%，也就是说通过load命令呢，我们把这个数据全部缓存到我们的gus FS中了。那呃，预热某个table的某个partition呢，可以通过goods f table load，就是加上DB的名字，Table的名字，并且用杠P加上这个partition name，那这个partition name呢，就是可以通过那个刚刚的那个table。

我们可以回去看一下。可以通过呃，Table ls，呃，加一个DB名字，加一个table的名字，我们可以看到，呃，这个有一个table name，对。那我们呢，就是通过这个命令加一个杠P加这个table的name呢，我们就可以发起一个某个呃，某个table的某个partition的一个预热，预热任务啊，可以看到这个job ID就是这个东西，那我们也可以通过这个job ID去查询呃，这个job的一个情况。那释放table和提式数据缓存呢？那我们可以通过s f table free，可以看到这个DEMO里面啊，就是table free，嗯，S f DEMO test，那就是我这个就是去释放了这个整个table的一个数据，可以看到它有一个信息告诉我们是说已经成功的从gus FS的空间中把这个数据释放掉了。

以上就是table的一个呃管理以及呃数据预热的一个能力的介绍。那接下来呢，我们来介绍一下目录，Atomic是原子的一个预热的一个能力。它的一个应用场景呢，就是避免用户在预热新数据的期间读取到中间的数据，从而发生呃，低命中率的这种情况，从而降低这种访问性能。呃，那这个目录Tom的这个预热能力呢，呃，预热功能呢，就是呃，当目录下的文件及就是它的。呃，所有的文件100%预热到我们FS中后呢，用户才对这个目录下的文件可见。

那我们可以看如下的一个场景。首先呢，呃，这个是一个某个用户的一个AI训练作业的一个场景，那用户的模型数据呢，会定时的去产生，呃，产出。新的那个model的就是模型数据到我们的cos中。那呃，那这个时候呢，它会触发呃，新增数据缓存调度，去将它新产生的这个MODEL2的这个数据呢，缓存到我们库SFS中。但是当这个MODEL2缓存到12%的时候呢？如果训练任务这个时候去读取，那会发生，呃，Catch missing，因为它没有。把所有的数据缓存到我们的ofs中，这个时候呢，会触发呃，穿透读到我们的cos上，从而带来性能的降低。那我们的atom预热呢，其实也是针对这种场景，就是呃，避免在预热。

过程中。给用户的作业性能带来性能的降低。OK，呃，那那我这边再补充一点哈，就是那如果我们应用了这个atomic预热呢，就是我们通过atomic的形式将这个MODEL2进行预热进来呢，就是那用户的任务就不会发生开始密行，因为这个MODEL2的数据未达到100%的时候呢，呃，训练任务是看不到这个数据的。也看不到它的目录的，所以无法访问，当只有达到真正的100%的时候，它才会呃去访问，所以这个时候呢，就能达到100%的一个缓存命中率。那这个目录do预热方法，呃，预热的一个用法呢，就是通过goods FS，嗯的呃，Distributed load这个命令去进行。

触发，其中呢，杠A是表示。呃，我们本次预热呢，是启用了atomic预热。那这个呢，是指我可以对这个。嗯，路径就是路径下的，呃，数据呢，进行多部分的预热，当然了，默认是一，你也可以设置为三等等。那这个呃，Expre time呢，是用于呃，清理失败的任务数据残留的一个时间窗口。他的考虑是说呢，就是假如说有一个预热任务，用户已经触发了，那运行到50%的时候呢，它失败掉了，那这个时候呢，用户可以再次去触发这个预热任务，从50%这个断点继续去做，就是只需要呃做嗯，还没还没有预热的这个，嗯文件的这个任务，这样的话会大大减少呃用户的这个失败情况下的一个预热的一个。嗯。嗯，预热的一个时间消耗。

那这个是这个time呢，呃，就是在，呃说我这个前期失败的这个任务已经预热上来的这些数据呢，我可以在故FS中，呃保留多久，那默认呢，就是24小时，就是在24小时之后呢，我会把这个失败任务的这个数据残留呢，我就会清理掉。OK，那我们也可以看一下这个atomic预热的一个DEMO。嗯，首先呢，我是呃呃。嗯，接着就是table的时候，已经挂载了一个呃，Namespace，就是这个DEMO，把这个con的某个的某个目录挂载到了我们的S中，嗯，对，然后呢，嗯，我同时呢，呃查询了一下这个cost test。嗯，我们可以看到，呃，这里面是不存在这个atomic test。然后呢，我在这个里面去新增了一个atomic t，就是在呃，它的一个挂载点路径下。

可以看到，就是cos的这个DEMO目录下，我新增了一个atomic test来模仿用户的一个模型的一个新增。那这个时候呢，呃，它的状态是说在故事FS中呢，是不存在这个目录的，但是在底层呢是存在的。那接下来呢，我们就可以对这个目录呢，进行atomic的一个预热。那它的一个命令的，呃，命令的形式呢，就是故FS distributed load加个杠A，然后加一个目录，就是你想要去预热的这个目录。嗯，那我们可以看到看到这个里面的一个信息，呃，告诉我们是说这个目录下的一个数据已经开始预热了。那我们着重关注一下这个时间窗口，就是我们来看一下在这个时间窗口内，这个这个目录是不是在库SFS中。是不可见的。

那我们呃来查看一下，就是这个目录是是否在gus FS中可见，那我们可以通过SFSLS这个目录的副目录来看它是不是已经可见了，那我这边也标志标记出来了，就是刚刚的一个预热的时间段。是。14:58:15~20秒。是从预热开始到预热结束的一个时间段，那我们可以从图中看到，那我这个执行查询的一个操作是在17秒到19秒执行完成的，也就是说在这个区间内，那我们可以看到这个atomic的这个test，这个目录呢是不可见的。那当这个预热完成后呢，我们再次进行查询。那可以看到。它已经是可见的了，并且呃，这个时候它已经在gus中的呃比例是缓存在GUFS中的比例是100%了。

那从从这个可以看出来，这个他米预热的这个呃，能力呢，是符合预期的。那针对于这个预热能力呢，我们也推出了一个预热白名单的一个功能，就是这个主要是为了支持用户定制化的去管控开始，那我那它的功能呢，就是说呃，在这个白名单内的目录，那才它才可以成功的进行呃预热。就是去缓存到我们SFS中，那它它的这这个功能的一个应用场景呢，就是呃，有一些用户呢，他仅仅希望呃对个别的一个核心的一个数据。做缓存，他不在乎其他数据的一个访问性能，所以他不想其他数据去占用他，故FS的一个嗯，存储的一个，呃，资源对。那这个预热白名单的一个用法呢，就是通过good ns。

呃的这两个命令去进行，呃生效，首先那这个apply命令呢，就是嗯去开启开启这个namespace，或者是关闭这个namespace的一个白名单，那这个configgu的这个模板呢，就是首先是namespa的，呃名字就是我们这边就是算是靠N啊，然后第二个是说是否开启这个namepace的一个白名单功能，那我这边设置的是触。然后以及这个namespace，这个白名单列表是什么。那呃，这个命令呢，是用于查询，就是查询我们namespace某个namepa的一个呃，白名单的一个信息。那接下来我们可以看一下这个功能的一个DEMO。首先呢，呃，我这个conflict信息呢，是space是用的constant test。然后并且开启这个白名单功能，同时呢，呃，白名单列表里面呢，我设置了一个，呃。

设置了某个路径。那我们可以通过这个apply命令呢？呃，就是NS的这个呃，开始呃，CT-apply去将这个com，呃，Con的这个name space信息呢去进行生效啊，可以看到这个enable已经是成功的了，并且呃，并且白名单也录入成功了。那接下来我们去，呃，对这个namespace呢，执行一个预热操作，来看看是不是符合预期。那我接下来是通过good FS的distributed的load去对这个name space，呃，整体进行一个预热，从这个信息中可以看到。啊，只有白名单，只有白名单里边的这个文，呃，目录下的文件被漏的上来了。被执行了这个预热，那其他的呢，都在报，他不在白名单中，所以他没有去，呃，执行这个预热。

那可以看到这个也成功预热了，呃，这个白名单下的某一个文件。那我们可以看一下这个，呃，缓存的占用，我们度一下这个，嗯嗯，度一下这个，看一下这个c test下面的文件的一个信息。可以看到呢。只有这个data白名单下面，就是这个白名单下面的一个文件已经被100%预热，其他的都是没有触发预热的。嗯，那它这个也是符合预期的。那我们以上介绍呢，都是，呃，都是通过异步任务呢去进行预热的。那呃，这个时候呢，我们就会考虑是说，呃，用户如果想要自定义，就是预热的任务。那应该怎么样？嗯，因为我们集群的一个预热的资源呢，是一定的，那呃怎么样去更合理的去调度用户的这个预热任务呢，我们就推出了这个预热优先级的一个功能。

我们通过。嗯，优先级队列呢，去让用户自定义这个他想要预热的这个任务的一个嗯，优先级，从而呃，更合理的去分配这个资源。那呃，传统的这个优先级队列呢，其实有一个很严重的问题就是呃，当呃有高优先级的任务不断进来的时候，那。他会不断的去执行这个高优先级的任务，嗯，而低优先级的任务永远得不到执行，从而带来饿死的风险。那我们呢，为了解决这样的问题。也也推出了自己的一个带有呃权重的。任务优先级队列，它呢，通过呃，某个优先级，然后嗯，设置某一个权重，来通过权重的这个值呢，来进行资源的分配，我们可以看一下左边这个规则，就是例如我们这个优先级呢，就是我们自己的这个fair queen呢，它有三个队列，就是三个优先级，那分别对应的权重是842。

那么我们每一轮呢，执执行的时候，保证保证至少执行八个最高优先级的这个预热任务。同时呢，至少执行四个中优先级的一个预热任务，以及至少执行两个低优先级的预热任务，所以通过这种方式呢，我们就可以呃保证用户的一个预热任务都是在嗯同时执行呢，不会出现饿死的情况，但是呢，也同时保证了呃高优先级的任务会呃调度到更多的资源。那在监控方面呢，我们也建立了这个，呃，缓存的一个命中率，因为gus FS也是一个缓存系统，那缓存的命中率的话，对他来说是一个很核心的指标了。

那我们可以看下面这个图。首先呢，呃嗯，这个命中率呢，分为gus is整体的一个命中率。以及短路读命中率，就是短路读，所谓短路读就是呃，你的计算节点跟你的存储节点就是跟库存储节点在一个节点的时候，它会触发直接从本地磁盘读，从而带来很高的一个性能啊。其次是非短路读命中率。那呃，第一个图呢，就是guci I整体命中率，我这个图是截取的，呃，线上的一个用户的一个监控图，可以看到它的命中率是相当高的，基本就是在100%。呃，所以故S的呃，这个在它的业务场景中的作用呢，也是非常的一个关键的。其次呢，我们可以通过监控呢，去看到嗯整个集群的一个吞吐能力，呃包括短路读的一个吞吐，就是刚刚介绍的直接读呃本地磁盘的一个吞吐，呃非短路读的吞吐，以及读远程的这个挂载点的这个存储系统的一个吞吐，那这样的话呢，我们也可以很清楚的去呃，嗯去看到这个用户的一个呃访问的一个嗯状态，以及SFS中呃，故SFS是不是起到了。

嗯，Catch的这个作用。嗯嗯，好的，那我本期的一个介绍就到此结束了啊，那在这里也给大家预告一下，下一期的一个介绍，就是cos原数据加速。的一个介绍。