数据多副本
概述
Alluxio 工作节点上文件数据和元数据的副本称为副本。文件副本功能允许通过在不同工作节点上创建和分发多个副本,从而让多个工作节点能够提供同一个文件。此功能主要用于提高 I/O 吞吐量和可用性,特别是在数据集被大量客户端并发缓存和访问时。
如果未启用文件副本(即副本级别设置为 1),一个文件在集群中一次只会有一个副本。这意味着所有客户端对该文件数据的访问都将由存储该副本的单个工作节点提供服务。在许多客户端需要并发访问此文件的情况下,该单个工作节点可能会成为性能瓶颈。
注意: 一个工作节点对于任何给定的文件最多只会有一个副本,它不会存储同一个文件的多个副本。
启用文件副本
文件副本由几个系统设置控制,这些设置决定了创建多少副本以及如何访问它们。
副本数量
默认情况下,副本级别为 1,表示每个文件只有一个副本。要增加副本数量,你有两个选择:
创建副本规则(推荐):此方法通过允许你为特定路径定义副本级别,从而提供精细的控制。例如,一个规则可以为给定路径下的所有文件将副本数设置为 3。
设置集群范围的默认值:使用已弃用的
alluxio.user.file.replication.min
属性为整个集群设置默认副本级别。此方法不如使用副本规则灵活。
副本选择策略
当读取具有多个副本的文件时,副本选择策略决定了客户端从哪个工作节点读取。这对于负载均衡和确保高可用性至关重要。如果所选工作节点不可用,客户端会自动故障转移到另一个副本。
该策略使用 alluxio.user.replica.selection.policy
属性进行配置,可用选项如下:
GLOBAL_FIXED
(默认): 所有客户端按相同的固定顺序从工作节点读取。CLIENT_FIXED
: 每个客户端都有自己固定的工作节点顺序,从而将负载分散到各个副本。RANDOM
: 每个客户端为每个读取请求选择一个随机副本。
要配置该策略,请设置以下属性:
alluxio.user.replica.selection.policy=GLOBAL_FIXED
优化副本读取性能
默认情况下,客户端遵循副本选择策略,而不考虑所选工作节点上是否已缓存数据,这可能导致不必要的冷读取。为了优化这一点,你可以启用两个关键功能:缓存副本优先和被动缓存。
缓存副本优先:客户端首先检查哪些可用副本工作节点已完全缓存了文件。它会优先从这些“热”工作节点之一读取,以避免从 UFS 进行缓慢的冷读取。
被动缓存:此功能补充了副本优先。如果客户端最偏好的工作节点没有缓存数据,但另一个工作节点有,客户端将从缓存源读取,同时触发一个异步后台作业将文件加载到偏好的工作节点上。这确保了数据在理想的工作节点上被缓存,以供将来读取。
要启用这两个功能,请设置以下属性:
alluxio.user.replica.prefer.cached.replicas=true
alluxio.user.file.passive.cache.enabled=true
注意:部分缓存文件的工作节点不会比完全没有缓存的工作节点更优先。
配置副本规则
文件的副本数量通过副本规则进行管理。这些规则通过协调器上的 REST API 端点进行配置。
API 端点: http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
创建副本规则
要添加新规则,请发送一个 POST
请求,其 JSON 正文指定 path
和 numReplicasPerCluster
。
以下命令为根路径 (/
) 下的所有文件将副本级别设置为 2:
$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/", "numReplicasPerCluster": 2}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
你可以为不同的路径创建多个规则。例如,为 /s3/vip_data
设置 3 个副本,为 /s3/temp_data
设置 1 个副本:
$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data", "numReplicasPerCluster": 3}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/temp_data", "numReplicasPerCluster": 1}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
嵌套路径限制: 目前,副本规则路径不能嵌套。例如,你不能同时为 /parent
和 /parent/child
设置规则。这也意味着根路径 (/
) 上的规则不能与任何其他规则共存。此限制将在未来版本中取消。
列出副本规则
要查看所有活动的副本规则,请向该端点发送 GET
请求:
$ curl -G http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
响应是一个包含所有规则的 JSON 对象。以下示例显示了根路径 (/
) 上的默认规则,副本级别为 1。
{
"/": {
"pathPrefix": "/",
"clusterReplicaMap": {
"DefaultAlluxioCluster": 1
},
"totalReplicas": 1,
"type":"UNIFORM"
}
}
更新副本规则
要更新现有规则,请发送一个具有相同路径但 numReplicasPerCluster
值不同的 POST
请求。以下示例将 /s3/vip_data
的规则更新为 1 个副本:
$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data", "numReplicasPerCluster": 1}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
删除副本规则
要删除规则,请发送一个 DELETE
请求,其 JSON 正文中包含要删除规则的路径:
$ curl -X DELETE -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data"}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
创建副本
副本可以通过两种方式创建:通过分布式加载作业主动创建,或在客户端读取数据时被动创建。
主动创建副本
创建特定数量副本的最可靠方法是使用 job load
命令。此命令会启动一个分布式作业,将文件加载到 Alluxio 中,并创建与匹配的副本规则指定的副本数量。
例如,如果为 /s3
设置的规则为 3 个副本,以下命令将加载 /s3/file
,并在 3 个不同的工作节点上创建 3 个副本:
bin/alluxio job load --path s3://bucket/file --submit
即使某些副本加载失败,加载作业也会报告为成功。失败的副本将在下一次客户端请求时被动创建。
被动创建副本
在两种情况下可以被动创建副本:冷读取时或通过被动缓存。
冷读取时 当客户端读取一个未在 Alluxio 中缓存的文件时,会触发“冷读取”,文件被加载到服务该请求的工作节点的缓存中,从而创建一个副本。如果后续对同一文件的客户端请求被定向到不同的工作节点(基于副本选择策略),则会随着时间的推移被动创建额外的副本。以这种方式创建的副本数量不作保证,并取决于客户端的访问模式。
通过被动缓存 当被动缓存启用时,读取文件可以触发异步副本创建。如果客户端偏好的工作节点没有数据,客户端会从另一个源读取,同时一个异步后台作业会将文件加载到偏好的工作节点。这会在偏好的工作节点上创建一个新副本,确保未来读取时有更好的数据局部性。
监控
Alluxio 提供指标来监控文件副本和被动缓存的行为。
读取流量指标
当 alluxio.user.replica.prefer.cached.replicas
启用时,alluxio_multi_replica_read_from_workers_bytes_total
指标会跟踪数据读取模式。
类型:
counter
组件:
client
描述:客户端从工作节点读取多副本文件的总字节数。它有助于分析读取分布和缓存效率。
标签:
cluster_name
:服务工作节点所在的集群。local_cluster
:如果工作节点与客户端在同一集群中,则为true
。hot_read
:如果工作节点有完全缓存的副本,则为true
。
被动缓存指标
当被动缓存启用时,alluxio_passive_cache_async_loaded_files
指标会跟踪异步加载的文件。
类型:
counter
组件:
worker
描述:由被动缓存触发的工作节点加载的文件总数。
标签:
result
:加载作业的结果(submitted
、success
或failure
)。
限制
可变数据的一致性
文件副本最适合不可变数据。如果底层 UFS 中的数据是可变的,则在不同时间加载的不同副本可能会变得不一致。
为了缓解这种情况,你可以:
手动刷新元数据:使用带有
--metadataOnly
标志的job load
命令检查 UFS 更新并使过时的副本失效。bin/alluxio job load --path s3://bucket/file --metadataOnly --submit
使用缓存过滤器策略:设置
maxAge
策略以在一定时间后自动使副本失效,强制从 UFS 重新加载它们。例如,10 分钟的maxAge
:{ "apiVersion": 1, "data": { "defaultType": "maxAge", "defaultMaxAge": "10min" }, "metadata": { "defaultType": "maxAge", "defaultMaxAge": "10min" } }
副本级别不会被主动维护
Alluxio 不会主动添加或删除副本以匹配规则中设置的目标副本级别。实际副本数量可能由于以下原因而低于或高于目标:
缓存驱逐:由于缓存容量不足,副本可能会从工作节点中被驱逐。
被动创建:如果文件总是从现有副本提供服务,则可能不会创建新副本。
工作节点成员资格变更:当工作节点加入或离开集群时,副本选择算法可能会改变,导致“孤立”的副本不再被选中但仍存在于缓存中。这些孤立的副本最终会被驱逐。
Last updated