很多用户使用DLA对存储在OSS上的数据的进行分析。并且，由于OSS极低的存储成本，也有很多用户也会选择通过SLS日志投递、DLA一键建仓等功能把其他数据源的数据转储到OSS进行分析。然而，由于OSS按照调用次数收费，在分析OSS数据时，因OSS接口调用而产生的成本往往会成为成本中较为显著的一个部分。
为了帮助用户降低成本，我们对DLA中读取OSS数据过程中调用API的次数进行了大幅度的优化，经过测试，在不同场景下，优化后的OSS调用次数下降为优化前的1/3甚至更低，最大下降为优化前的1/10。这就意味着，在这个优化发布之后，用户的这部分成本会有60%~90%的下降。
优化思路
在此之前，DLA访问OSS数据是通过开源的AliyunOSSFileSystem来进行读写的。我们对AliyunOSSFileSystem内部机制进行了分析，发现AliyunOSSFileSystem在进行数据读取时，会以每次512KB为单位（可配置，为描述方便，这里以默认配置为例）调用OSS API进行读取，如果读取的数据范围超出了512KB，就会新发起一次请求，这样就会导致使用AliyunOSSFileSystem读取OSS文件时，调用次数非常多，产生了很多不必要的成本。
我们认为，理想情况下读取OSS文件的方式应该是这样的：
- 一次请求会尽量多的读取需要的内容。例如如果是从头到尾顺序读一个大文件，应该只会产生一次OSS调用。
- 如果读取过程中有大的跳转（seek）操作，需要重新进行一次OSS调用。这是由OSS的接口设计决定的，OSS使用HTTP接口，我们只能在发起请求的时候决定这次读取的开始位置，因此如果不重新进行调用，就只能把这次跳转中间的数据全部读一遍并忽略，这样虽然调用次数少了，但是seek的延时变大了。
- 反过来说，小的跳转则可以不用重新调用，因为读取少量字节并忽略显然比重新发起一次HTTP请求的延时要小。
这个思路可以用下图来示意：
当然，具体实现起来还有一些细节的点需要考虑，例如每次读取的范围应该设置多少；再例如，按需读取意味着HTTP连接的存活时间比较长，如何对连接的生命周期进行管理等。
最终，我们按照这个思路对AliyunOSSFileSystem做了优化，经过测试，优化达到了我们最初期望的效果。
测试结果
测试选择了Text/ORC/Parquet三种常用的文件格式，统计他们在TPCH查询场景下的调用次数，分别测试了1GB和10GB数据量下的优化效果。测试结果如下：
从这个测试结果可以看出，在Text文件格式上面，优化后的调用次数只有优化前的1/10，ORC/Parquet的优化效果没有这么夸张，但是也只有优化前的1/3左右。这就是说，调用次数带来的成本会有60%~90%的下降。
为什么Text格式的优化效果这么明显呢？结合前面的优化思路介绍，由于Text文件格式简单，以顺序读为主，所以理论上读一个Text文件需要的最小OSS调用次数就是任务的split个数。而在优化前，由于社区AliyunFileSystem的预读逻辑，调用次数不会小于 文件大小/512KB。实际上，我们从执行计划看到的split个数，以及文件的大小计算得到的调用次数和测试结果基本是吻合的。而对列存格式来说，由于文件格式决定了要读取数据除了顺序读之外还会有跳转，所以优化效果不如Text明显。
更进一步，我们未来可以再对列存的索引等内容加入一些缓存的逻辑，甚至把经常读取的数据块也放在缓存中，这样就能进一步降低OSS的调用次数，对查询性能也有一定帮助。
目前，这个优化已经在华东1发布，该区域的DLA用户可以关注一下您的OSS成本变化。其他Region也会在近期陆续发布。
关于我们
数据湖分析Data Lake Analytics简介
欢迎大家使用数据湖分析(DLA)，DLA不仅仅便宜，且快，且方便，专为阿里云数据湖分析方案而生
- 支持自建、托管RDS、NoSQL、OSS(JSON、CSV、Parquet等格式)多种数据源分析
- 支持按量 按照扫描量 的计费方式，准入门槛0元，提供的Serverless的弹性服务为按需收费，不需要购买固定的资源，完全契合业务潮汐带来的资源波动，满足弹性的分析需求，同时极大地降低了运维成本和使用成本
- 平台底层托管大集群且自动弹性，在一定数据量情况下，分析性能比自建小集群高出400%
-
支持一键 把 MySQL、PG、SqlServer、PolarDb数据库 拖到DLA，再分析，解决原MySQL不敢分析的问题。 DLA 分析性能TPC-H 10G情况 比原MySQL 8c16g 等高出10倍，数据量越大，MySQL性能越差，在1TB数据量下，原MySQL基本跑不出来