文档首页/ 数据仓库服务 DWS/ 最佳实践/ 存算分离/ DWS磁盘缓存最佳实践

更新时间：2025-12-22 GMT+08:00

查看PDF

DWS磁盘缓存最佳实践

场景介绍

在云计算时代，随着存算分离架构技术日趋成熟，越来越多的企业选择将大量用户数据存放在云端存储中，这导致了频繁的OBS云端存储读写需求。在这种架构下，数据访问速度逐渐成为了性能瓶颈，如何在这样的背景下，提升云上数据处理速度，成为了一个亟待解决的问题。

DWS通过利用本地硬盘上的缓存来加速数据访问，并采用了一种先进的多队列 LRU（Least Recently Used，最近最少使用）策略来高效管理缓存空间。针对跨VW（Virtual Warehouse，弹性计算组）的应用场景，DWS 还提供了缓存预热功能，以便在弹性VW建立时，能够迅速加载特定数据（如表或分区）到缓存中，从而提升查询性能。

本功能仅9.1.0.x及以上集群版本支持，其中TTL队列仅9.1.1.x及以上集群版本支持。

了解多队列LRU

LRU
LRU（Least Recently Used，最近最少使用）通过维护一个数据访问队列来管理缓存。当数据被访问时，该数据会被移动到队列的前端。新加入缓存的数据同样会被置于队列前端，以防止其过早被淘汰。当缓存空间达到上限时，队列尾部的数据将优先被移除，即最近最少使用的数据优先被淘汰。

DWS通过引入LRU-2Q算法，优化了LRU的缓存污染问题，确保了不会因为访问大量历史数据而导致核心业务的热数据被冲刷出缓存。

LRU2Q共包含3个队列，分别是A1in/A1out/Am，其中数据首次命中时会进入到A1in队列中，后续如果A1in队列满了（可调整GUC参数，通常默认值为整个队列大小的0.25倍），会淘汰到A1out（实际并不存储数据到缓存，只是A1in队列淘汰的延长记忆），等A1out队列中的block被命中时，才会插入到Am队列。在Am队列中的数据，是最热的数据。
TTL (Time-To-Live)
TTL策略确保新导入的数据在缓存中保留一段时间不被淘汰。在这段时间内，数据具有最高优先级，且所有TTL数据之间地位平等，不会因为某些数据即将过期而被提前淘汰。当TTL缓存空间不足时，会尝试抢占LRU队列的空间，以确保TTL数据能够被写入，TTL队列最大可使用的空间由GUC参数disk_cache_ttl_max_ratio控制，默认值是0.5，即整个缓存空间的一半。当TTL队列的缓存空间到达上限后，如果仍然有新的数据要进入TTL队列，此时会触发TTL队列自身的LRU淘汰，被淘汰的数据将进入到LRU空间中。

应用场景：TTL策略特别适用于希望在本地持久化的小规模数据表。对于常驻表，可以设置较长的TTL值来保护其数据；对于实时表，可以根据热数据的活跃时间设定相应的TTL值。

多队列

海量大数据场景下，随着业务和数据量的不断增长，数据存储与消耗的资源也日益增长。根据业务系统中用户对不同时期数据的不同使用需求，对膨胀的数据本身进行“冷热”分级管理，可以有效提升本地缓存的使用效率。

例如，在网络流量分析系统中，用户可能对最近一个月内安全事件和网络访问情况感兴趣，而很少关注几个月前的数据。针对这样的一些场景，可以将数据按照时间分为：热数据、冷数据。

冷热数据主要从数据访问频率、更新频率进行划分。

Hot（热数据）：访问、更新频率较高，未来被调用的概率较高的数据，对访问的响应时间要求很高的数据。
Cold（冷数据）：不允许更新或更新频率比较低，访问频率比较低，对访问的响应时间要求不高的数据。

对于热数据，应该尽可能地将其留在本地缓存中；对于冷数据，既应该享受到本地缓存带来的空间局部性优势（即将当前访问数据及相邻数据都缓存下来，减少后续OBS读的次数），又应该具备比热数据更容易被淘汰的性质。最终决定给冷数据单独提供一个简化的、固定 1GB 的磁盘空间，这部分数据由A0队列进行管理，该部分缓存也遵循LRU策略。

DWS采用基于LRU的多队列策略，根据TTL属性及冷热属性将数据分为三类，分别置于TTL队列、LRU - 2Q队列、A0 队列中。设置了TTL属性的热数据被放置到TTL队列，没有设置TTL属性的热数据被放置到LRU - 2Q队列，冷数据都放置到A0队列中。

在数据读取和写入过程中，DWS会选择填充和读取的队列，以最大化缓存利用率。具体机制如下：

表1 DWS数据读取和写入机制
操作	未命中时填充的队列	写入数据时填充的队列
导入(开启缓存双写)	TTL / LRU - 2Q / A0	TTL / LRU - 2Q / A0
查询	TTL / LRU - 2Q / A0	N/A
预热	N/A	TTL / LRU - 2Q / A0

以查询操作为例，在读取数据时如果未命中，先判断数据是否是冷数据，如果是冷数据会直接进入 A0 缓存，如果是热数据则需要再判断当前表是否设置了 TTL 参数，如果设置了参数并且当前数据还没有过期，则数据会进入到 TTL 缓存，否则会进入 LRU - 2Q 缓存。

淘汰
A0队列可使用的缓存空间固定为1GB， TTL 队列和LRU - 2Q队列共同使用由GUC参数disk_cache_max_size设置的缓存空间，初始状态时缓存空间都给LRU - 2Q使用，在后续访问到设置TTL属性的数据或者TTL中有大量数据过期时，会动态调整TTL队列与LRU - 2Q队列的比例关系，以充分利用缓存空间，TTL所使用缓存空间的最大比例不超过disk_cache_ttl_max_ratio。
- TTL队列的淘汰
  当有新的数据进入TTL队列时，会将部分已经过期的数据淘汰至LRU - 2Q队列。
  
  后台线程会定期清理TTL中已过期的数据，并淘汰至LRU - 2Q队列。
  
  当TTL空间使用达到上限，且没有过期的数据时，会触发自身的LRU淘汰策略，被淘汰出去的数据会进入LRU - 2Q队列。
  
  当用户删除设置了过期时间的表数据时，后台线程会定期清理TTL中无效的数据。
- LRU - 2Q队列的淘汰
  当有新的数据插入且当前LRU空间使用达到上限，会触发自身的LRU淘汰策略，被淘汰出去的数据会被清除缓存。
  
  当TTL队列空间不足，但未到达上限，会抢占LRU - 2Q队列的空间。如果LRU - 2Q的空间已满，也会触发自身的LRU淘汰。
  
  当用户删除设置了过期时间的表数据时，后台线程会定期清理LRU - 2Q中无效的数据。

多盘缓存

云上环境，对不同云盘的访问，其流量会走不同的网卡，因此不同云盘的带宽是可以叠加的。在有多块云盘（EVS）的情况下，DWS支持设置多块盘作为缓存的路径，尽可能将cache文件分散在不同云盘上以提升缓存访问的性能。为了提升集群正常时主DN的性能并充分利用节点上的磁盘空间，目前会默认使用主备两块硬盘作为当前节点上主DN缓存介质，通过查询以下参数查看相关信息：

通过disk_cache_base_paths（该参数不支持用户自行配置，默认即可，如需设置请联系技术支持）参数查看和增减缓存硬盘路径，举例某个节点上的目录配置，实例名为h10dn1：

主DN多盘缓存路径默认如下：

路径1：/DWS/data1/h10dn1/primary0/disk_cache
路径2：/DWS/data2/h9dn1/primary0_disk_cache

备DN多盘缓存路径默认如下：

路径：/DWS/data2/h9dn1/secondry/disk_cache

备机的多盘缓存路径与当前节点上主DN的缓存路径2在同一块盘上，因此限制备机升主后的磁盘缓存空间最大为1GB，性能对比切换前会有较大劣化，需要尽快修复集群至均衡状态。

缓存预热

在存算分离模式下，DWS支持搭建跨VW集群，各VW间共享数据但不共享缓存。新的VW创建时，其缓存为空，可能影响查询性能。为此，DWS提供缓存预热功能，允许用户从远端存储主动拉取数据至本地缓存。该功能支持以下两种模式：

表数据预热：预热指定表 A 的数据。

       
            /* 将表A的数据预热至A1in队列中 */
EXPLAIN warmup SELECT * FROM A;
 /* 将表A的数据预热至Am队列中 */
EXPLAIN warmup hot SELECT * FROM A;

分区数据预热：预热指定表 A 的分区 p1 的数据。

       
            /* 将表A p1分区的数据预热至A1in队列中 */
EXPLAIN warmup SELECT * FROM A partition(p1); 
/* 将表A p1分区的数据预热至Am队列中 */
EXPLAIN warmup hot SELECT * FROM A partition(p1);

使用示例：

点击放大

warmup信息解读：

Read Cache Size : 从磁盘缓存中读取的数据大小。
Write Cache Size : 从OBS读到本地缓存的数据大小。
Avg Write Cache time : OBS请求的平均执行时间。

查看缓存数据

查看磁盘空间及命中率：

用户可通过查看disk cache视图pgxc_disk_cache_all_stats查看disk cache当前缓存状态，使用方式为：

     
          SELECT * FROM pgxc_disk_cache_all_stats;

图1 pgxc_disk_cache_all_stats
点击放大

其中各个字段含义如下：

表2 PGXC_DISK_CACHE_ALL_STATS字段
名称	类型	描述
node_name	text	节点名称。
total_read	bigint	访问disk cache的总次数。
local_read	bigint	disk cache访问本地磁盘的总次数。
remote_read	bigint	disk cache访问远端存储的总次数。
hit_rate	numeric(5,2)	disk cache的命中率。
cache_size	bigint	disk cache保存的数据总大小，单位kbytes。
fill_rate	numeric(5,2)	disk cache的填充率。
ttl_rate	numeric(5,2)	TTL空间占整个disk cache空间的比率。该字段仅9.1.1.100及以上集群版本支持。
temp_file_size	bigint	临时/冷缓存文件的总大小(kbytes)。
a1in_size	bigint	disk cache中a1in队列保存的数据的总大小，单位kbytes。
a1out_size	bigint	disk cache中a1out队列保存的数据的总大小，单位kbytes。
am_size	bigint	disk cache中am队列保存的数据的总大小，单位kbytes。
ttl_size	bigint	disk cache中ttl队列保存的数据的总大小，单位kbytes。该字段仅9.1.1.100及以上集群版本支持。
a1in_fill_rate	numeric(5,2)	disk cache中a1in队列的填充率。
a1out_fill_rate	numeric(5,2)	disk cache中a1out队列的填充率。
am_fill_rate	numeric(5,2)	disk cache中am队列的填充率。
ttl_fill_rate	numeric(5,2)	disk cache中ttl队列的填充率。该字段仅9.1.1.100及以上集群版本支持。
fd	integer	disk cache正在使用的文件描述符数量。
pin_block_count	bigint	disk cache中被pin住block的数量。该字段仅9.1.0.100及以上集群版本支持。

查看特定语句的OBS读写统计信息：

对于3.0表，由于数据的实际存储位置位于OBS，DWS增强了对OBS读写请求统计信息的监控能力，用于辅助定位特定SQL慢问题。

可以通过TopSQL视图以及EXPLAIN PERFORMANCE语句查看特定语句的OBS读写统计信息。

    
         /* TopSQL视图 */
SELECT * FROM pgxc_wlm_session_info;    ---注意在连接postgres数据库下执行
 /* EXPLAIN PERFORMANCE */
 EXPLAIN PERFORMANCE + SQL语句

图2 OBS读写信息
点击放大

其中新增字段含义如下：

表3 OBS读写信息
新增字段名称	字段含义
vfs_scan_bytes	OBS虚拟文件系统接收到上层请求的扫描的字节数(bytes)。
vfs_remote_read_bytes	OBS虚拟文件系统实际从OBS读取的字节数(bytes)。
preload_submit_time	预读流程提交IO请求的总时间(microseconds)。
preload_wait_time	预读流程等待IO请求的总时间(microseconds)。
preload_wait_count	预读流程等待IO请求的总次数(count)。
disk_cache_load_time	读取diskcache的总时间(microseconds)。
disk_cache_conflict_count	读取diskcache中block产生哈希冲突的次数(count)。
disk_cache_error_count	读取diskcache失败的次数(count)。
disk_cache_error_code	读取diskcache失败的错误码(count)。
obs_io_req_avg_rtt	OBS IO请求的平均RRT(microseconds)。
obs_io_req_avg_latency	OBS IO请求的平均延迟(microseconds)。
obs_io_req_latency_gt_1s	OBS IO请求延迟超过1s的数量(count)。
obs_io_req_latency_gt_10s	OBS IO请求延迟超过10s的数量(count)。
obs_io_req_count	OBS IO请求的总数量(count)。
obs_io_req_retry_count	OBS IO请求重试的总次数(count)。
obs_io_req_rate_limit_count	OBS IO请求被流控的总次数(count)。

打开磁盘缓存功能

当前云上集群的磁盘缓存默认是打开的，即对所有v3表的访问都会使用到磁盘缓存。可以通过以下方式检查当前集群的磁盘缓存是否打开？以下内容仅供参考，无需用户单独配置，如需配置请联系技术支持。

在DN上执行以下查询命令：
```
SHOW enable_aio_scheduler; 
SHOW obs_worker_pool_size;
```
确保enable_aio_scheduler=on，obs_worker_pool_size >=4。
CN上执行以下查询命令：
1

SHOW enable_disk_cache
确保enable_disk_cache=on。

上述两点必须同时满足。

指定表级缓存策略

当前disk cache支持的缓存策略有以下四种：

HPN(HOT PARTITION NUMBER)

cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成HPN : N，⽤户需要提供⼀个数字N(N >= -1600 && N <= 1600)，之后获取表中的数据，更晚创建的N个分区中的数据会被热缓存，其余分区会被冷缓存。当N等于0时，所有分区中的数据都会被冷缓存。HPN只对V3表中的range分区表和list分区表⽣效。

       
        
          
          
            CREATE TABLE IF NOT EXISTS lineitem
(
 L_ORDERKEY BIGINT NOT NULL
 , L_PARTKEY BIGINT NOT NULL
 , L_SUPPKEY BIGINT NOT NULL
 , L_LINENUMBER BIGINT NOT NULL
 , L_QUANTITY DECIMAL(15,2) NOT NULL
 , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL
 , L_DISCOUNT DECIMAL(15,2) NOT NULL
 , L_TAX DECIMAL(15,2) NOT NULL
 , L_RETURNFLAG CHAR(1) NOT NULL
 , L_LINESTATUS CHAR(1) NOT NULL
 , L_SHIPDATE DATE NOT NULL
 , L_COMMITDATE DATE NOT NULL
 , L_RECEIPTDATE DATE NOT NULL
 , L_SHIPINSTRUCT CHAR(25) NOT NULL
 , L_SHIPMODE CHAR(10) NOT NULL
 , L_COMMENT VARCHAR(44) NOT NULL
) with (
 orientation = column,
 colversion = 3.0,
 cache_policy = 'HPN : 3'
)
TABLESPACE cu_obs_tbs
DISTRIBUTE BY HASH(L_ORDERKEY)
PARTITION BY RANGE(L_SHIPDATE)
(
PARTITION L_SHIPDATE_4 VALUES LESS THAN('1993-01-01 00:00:00'), -- 冷缓存
PARTITION L_SHIPDATE_5 VALUES LESS THAN('1994-01-01 00:00:00'), -- 冷缓存
PARTITION L_SHIPDATE_3 VALUES LESS THAN('1995-01-01 00:00:00'), -- 冷缓存
PARTITION L_SHIPDATE_1 VALUES LESS THAN('1996-01-01 00:00:00'), -- 冷缓存
PARTITION L_SHIPDATE_2 VALUES LESS THAN('1997-01-01 00:00:00'), -- 热缓存
PARTITION L_SHIPDATE_7 VALUES LESS THAN('1998-01-01 00:00:00'), -- 热缓存
PARTITION L_SHIPDATE_6 VALUES LESS THAN('1999-01-01 00:00:00')  -- 热缓存
);

           

         

       
      

HPL(HOT PARTITION LIST)

cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成HPL : , , ...，⽤户需要提供意图指定成热分区的分区名，之后获取表中的数据，热分区中的数据会被热缓存，⽽其余分区中的数据则会被冷缓存。HPL只对V3表中的range分区表和list分区表⽣效。HPL只对V3表中的range分区表和list分区表⽣效。

       
        
          
          
            CREATE TABLE IF NOT EXISTS nation
(
 N_NATIONKEY INT NOT NULL,
 N_NAME CHAR(25) NOT NULL,
 N_REGIONKEY INT NOT NULL,
 N_COMMENT VARCHAR(152)
) WITH (
 orientation = column,
 colversion = 3.0,
 cache_policy = 'HPL : ASIA, AMERICA, REST'
)
TABLESPACE cu_obs_tbs
DISTRIBUTE BY ROUNDROBIN
PARTITION BY LIST(N_NAME)
(
PARTITION ASIA VALUES ('INDIA', 'INDONESIA', 'JAPAN'), -- 热缓存
PARTITION EUROPE VALUES ('FRANCE', 'GERMANY', 'UNITED KINGDOM'), -- 冷缓存
PARTITION AFRICA VALUES ('ALGERIA', 'ETHIOPIA', 'KENYA'), -- 冷缓存
PARTITION AMERICA VALUES ('ARGENTINA', 'BRAZIL', 'CANADA'), -- 热缓存
PARTITION REST VALUES (DEFAULT) -- 热缓存
);

           

         

       
      

NONE

cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成NONE，之后获取表中的数据，所有数据都会被冷缓存。

       
            CREATE TABLE IF NOT EXISTS partsupp
(
 PS_PARTKEY BIGINT NOT NULL,
 PS_SUPPKEY BIGINT NOT NULL,
 PS_AVAILQTY BIGINT NOT NULL,
 PS_SUPPLYCOST DECIMAL(15,2) NOT NULL,
 PS_COMMENT VARCHAR(199) NOT NULL
)
WITH (
 orientation = column,
 colversion = 3.0,
 cache_policy = 'NONE'
)
TABLESPACE cu_obs_tbs
DISTRIBUTE BY HASH(PS_PARTKEY);  -- 冷缓存

ALL

cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成ALL，之后获取表中的数据，所有数据都会被热缓存。

       
        
          
          
            CREATE TABLE IF NOT EXISTS orders
(
 O_ORDERKEY BIGINT NOT NULL,
 O_CUSTKEY BIGINT NOT NULL,
 O_ORDERSTATUS CHAR(1) NOT NULL,
 O_TOTALPRICE DECIMAL(15,2) NOT NULL,
 O_ORDERDATE DATE NOT NULL,
 O_ORDERPRIORITY CHAR(15) NOT NULL,
 O_CLERK CHAR(15) NOT NULL,
 O_SHIPPRIORITY BIGINT NOT NULL,
 O_COMMENT VARCHAR(79) NOT NULL
)
WITH (
 orientation = column,
 colversion = 3.0,
 cache_policy = 'ALL'
)
DISTRIBUTE BY ROUNDROBIN;  -- 热缓存

           

         

       
      

设置TTL策略

在建表时，设置相应的表级参数disk_cache_ttl，即可将该表的数据使用TTL策略进行缓存。disk_cache_ttl表示，新导入的数据期望在缓存中保留的时间，参数的类型为interval，最小值为"1 second"、最大值为 "100 years"。

     
          CREATE TABLE IF NOT EXISTS ProductDimension
(
    ProductID INT,
    ProductName VARCHAR(100),
    Category VARCHAR(50),
    Price DECIMAL(10, 2),
    Description TEXT
)
WITH (
 orientation = column,
 colversion = 3.0,
 disk_cache_ttl = '1 day'
)
DISTRIBUTE BY ROUNDROBIN;  -- 热缓存

上表中，所有新导入的数据将在缓存中被保留 1天。系统当前支持修改表的 TTL 时间，用户可以根据实际需求将 TTL 的时间延长或减短。

    
         ALTER TABLE ProductDimension SET (disk_cache_ttl = '1000 seconds');

修改后的 TTL 值不会对已经在缓存中的数据生效，仅对后续进入缓存的数据有效。
如果在建表时没有设置 TTL，用户同样可以通过执行ALTER语句来修改表的TTL属性。

TTL设置典型场景

维度表，数据量较小、变动不大，但是访问频繁，可以设置较长的TTL时间，例如1年，避免查询大表数据时被替换出缓存，以确保其数据在一年内都能被快速访问。

客户新建维度表设置disk_cache_ttl为1年：

       
            CREATE TABLE dimension_table(a int, b text) with (orientation = column, COLVERSION = 3.0, disk_cache_ttl = '1 year');

已有维度表通过alter设置disk_cache_ttl：

如果不确定表数据导入的时间，可以把disk_cache_ttl设置为10年

       
            ALTER TABLE dimension_table SET (disk_cache_ttl = '10 years');

也可以设置为1年后，对维度表做VACUUM FULL，更新数据的导入时间。

       
            ALTER TABLE dimension_table set (disk_cache_ttl = '1 years'); 
VACUUM FULL dimension_table;

非频繁更新实时表，主要做数据导入与查询业务，可以根据客户业务设置合理的TTL时间。比如客户业务会频繁访问最近半天的数据，则可以设置TTL时间为0.5天。

       
            ALTER TABLE dimension_table set (disk_cache_ttl = '0.5 day');

频繁更新实时表，UPSERT业务比较频繁，可以根据需要做UPSERT的时间范围给表增加TTL时间，提升UPSERT操作的性能。设置过期时间时也根据客户具体的业务确定，如果主要对近两天导入的数据进行UPSERT，可将过期时间设置为2天。

       
            ALTER TABLE dimension_table set (disk_cache_ttl = '2 days');

常见问题

为什么我通过du、ls命令看到的disk cache目录占用的空间远大于我实际的数据量？（用户无法执行du、ls命令，仅技术支持人员可操作）
disk cache的磁盘占用空间代表的是历史上的最高水位，和当前实际缓存的数据量并没有关系，假设导入了100G的数据，之后进行了UPSERT等业务，数据量变成了200G，然后之后进行了VACUUM，数据量变成了100G，那么disk cache的磁盘占用空间仍然会保持在最高水位200G，但是disk cache内部的实际缓存数据量会是100G。失效数据需要将整个disk cache用满后触发LRU淘汰策略后才能清理。
disk cache是否会自动淘汰？为什么我的磁盘水位一直维持在配置的最高点，不下降？
会。目前策略是达到磁盘使用上限（参数可控制，默认主备盘总空间的50%）、或当前磁盘使用率达到80%才会开始淘汰。但淘汰不会实际删除数据，只是将缓存的磁盘位置标记为空，后面的新缓存写入时会覆盖老缓存。所以即使发生淘汰，磁盘占用空间也不会下降，不会影响实际使用。
为什么我执行DROP表操作后，OBS也显示表文件已删除，但是我的disk cache实际存储的数据量没有下降？
DROP 表数据不会进行disk cache缓存的删除，已经不存在的表的缓存会随着时间的推移，通过disk cache的内部LRU逻辑淘汰（删除），不影响实际使用。
为什么我各个节点之间的缓存占用差异很大？
各个节点之间的节点缓存占用是无法保证在相邻水位的，这是单机缓存天然的限制，只要对查询延迟没有影响就行。占用差异受很多因素影响：
- 不同实例加入集群的时间先后。
- 不同vw的表数量差异。
- 表数据的分布方式，以及业务实际访问的数据，可能某个业务访问的数据都在一个节点上。
- 不同节点vacuum full的时间差异，vacuum full会导致该表在缓存中占用的空间double，需要随着时间的推移，通过 disk cache 的内部 LRU 逻辑淘汰无需缓存。

父主题：存算分离

上一篇：DWS 3.0 存算分离使用建议及性能优化

下一篇：数据开发

意见反馈

文档内容是否对您有帮助？

有帮助没帮助

提供反馈

提交成功！非常感谢您的反馈，我们会继续努力做到更好！您可在我的云声建议查看反馈及问题处理状态。

系统繁忙，请稍后重试

在使用文档中是否遇到以下问题

内容与产品页面不一致

内容不易理解

缺失示例代码

步骤不可操作

搜不到想要的内容

缺少最佳实践

意见反馈（选填）

0/500

请至少选择一项反馈信息并填写问题反馈

字符长度不能超过500

直接提交取消

如您有其它疑问，您也可以通过华为云社区问答频道来与我们联系探讨

盘古Doer提问云社区提问