OSS/OSS-HDFS的性能优化最佳实践

背景信息

越来越多的用户构建数据湖，并借助OSS来存储数据。OSS可提供99.9999999999%（12个9）的数据持久性，99.995%的数据可用性。多种存储类型供选择，全面优化存储成本。

从OSS上传和下载数据时，您的应用程序可以轻松实现每秒数千个事务的请求性能。您的应用程序可以实现存储空间（Bucket）中每个分区（OSS按对象名的字母序排列对象，并按照数据量和请求QPS来拆分分区）每秒至少3500个PUT、COPY、POST或DELETE请求和5500个GET或HEAD请求，而存储空间中的前缀数量是没有限制的，因此您可以通过并行读取来提高读取或写入性能。也就是说，如果您的请求的文件前缀设计合理，在某个OSS Bucket中创建了10个前缀来并行上传，则可以将数据写入性能扩展到每秒35000个PUT请求。

阿里云OSS-HDFS服务（JindoFS服务）是JindoFS存储系统在阿里云上的服务化部署形态，与阿里云OSS深度融合，开箱即用，无须在EMR集群中部署维护JindoFS，免运维。OSS-HDFS服务详情请参见OSS-HDFS服务概述。

管理HTTP速度缓慢响应的最佳实践

将OSS/OSS-HDFS和ECS实例配置在同一地域

OSS存储空间名称是全局唯一的，您在创建存储空间时必须指定地域，且创建以后不能更改名称和地域。为了优化性能，建议您尽可能从同一阿里云地域中的ECS实例访问OSS存储空间，从而降低网络延迟和数据传输成本。详情请参见ECS实例通过OSS内网地址访问OSS资源。

通过水平扩展和并发或并行请求实现高吞吐量

OSS是一个超大的分布式系统。为了帮助您利用其规模，建议您将并行请求水平扩展到OSS服务终端节点，这种扩展方式有助于通过网络将负载分布在多个路径上。

OSS-HDFS使用了上述最佳实践，通过元数据服务支持，以文件块的方式将文件水平扩展到多个OSS服务终端上，以获取最佳的读写性能。

对于高吞吐量传输，您可以根据您的ECS规格和应用程序，调整特定参数，在多个线程或多个实例中控制上传和下载数据的并发或并行度来优化吞吐量。

• 测量性能指标

  根据CPU、网络吞吐量的要求来评估不同的ECS实例规格。有关实例规格的更多信息，请参见实例概述。此外，建议您在测量性能时使用HTTP分析工具查看DNS查询时间、时延和数据传输速度。

  当您要调整并发的请求数时，性能测量非常重要。建议从单个请求开始，测量当前的网络带宽以及其他资源的使用情况，从而识别瓶颈资源（即使用率最高的资源），以及可能的并发请求数。例如，如果一次处理一个请求导致CPU使用率为10%，则表明最多可以支持10个并发请求。

• 调整并发与并行的参数

  您可以通过修改fs.oss.download.thread.concurrency和fs.oss.upload.thread.concurrency调整单个进程内上传和下载的并发数。

  如果您在运行MapReduce或Spark任务，还有以下选择：

  • 对于提交MapReduce任务，可以通过Hadoop参数mapreduce.job.maps和mapreduce.job.reduces控制并行的执行程序数量。

  • 对于提交Spark执行程序，可以通过选项--num-executors或者Spark参数spark.executor.instance控制并行的执行程序数量。

对时延敏感的应用程序进行超时重试

OSS针对管控类API，如GetService（ListBuckets）、PutBucket、GetBucketLifecycle等进行QPS限制。如果应用程序产生高请求速率，可能会收到HTTP 503减速响应。如果发生这类错误，建议您延迟几秒后进行重试。

您可以通过调整fs.oss.retry.count控制访问OSS或OSS-HDFS的重试次数，fs.oss.retry.interval.millisecond控制访问OSS或OSS-HDFS的重试间隔（间隔会随重试次数的增加而倍增）。也可以根据网络情况来调整fs.oss.timeout.millisecond超时时间，进行合理的超时重试。

对频繁访问的内容使用缓存加速

如果您的应用程序需要支持同一地区大量访问同一静态文件的场景，可以使用JindoData缓存服务进行加速。JindoData缓存服务将文件以块的形式分散存储在分布式缓存服务中，从而避免重复从OSS或OSS-HDFS反复拉取数据，有效减少访问时延，增加计算资源的利用率。详情请参见阿里云OSS/OSS-HDFS服务透明缓存加速。

使用最新版本JindoSDK