《开元维度：2024对云上分析SQL引擎进⾏IO优化的成本效益白皮书（18页）.pdf》由会员分享，可在线阅读，更多相关《开元维度：2024对云上分析SQL引擎进⾏IO优化的成本效益白皮书（18页）.pdf（18页珍藏版）》请在本站上搜索。 1、*本白皮书版权归属于北京开元维度科技有限公司，未经授权，不得进行任何形式转载和分发。对云上分析SQL引擎进I/O优化的成本效益书The Cost Effect on I/O Optimization for Analytical SQL on Cloud本文探讨了将数据密集型分析应用从本地迁移到云原生环境这一普遍的行业趋势。我们发现，与云存储相关的独特成本模型要求对性能优化有更细致的了解。具体而言，根据从Uber Presto 生产环境中收集的数据，我们认为在云中简单地应用常见的 I/O 优化，比如table scan 和 filter（表扫描和过滤），以及 broadcast join（广播2、连接）可能会产生意想不到的成本。这是因为传统的 I/O 优化主要侧重于改善本地环境中的吞吐量或延迟，而没有考虑到与存储API调用相关的财务成本。在云环境中，这些成本可能会非常高昂，仅在Uber实际的使用规模下，Presto工作负载每天就可能涉及数十亿次的API调用。本文将以案例研究的形式呈现 I/O 优化逻辑和思路，可作为读者进一步研究的起点，从而设计出专门针对云环境中数据密集型应用的高效 I/O 策略。摘要011 导言2 云成本模型3 I/O 优化对工业分析负载的影响 3.1 工业分析流量模式在云 I/O 成本方面的挑战3.2 Table scan 和 filter 优化带来的成本挑战3.33、 Broadcast Join 优化的成本挑战4 讨论4.1 提高存储资源效率4.2 创建带缓存的虚拟存储层4.3 具备成本意识，重新设计数据密集型应用5 结论参考文献35668911111212141502目录本文对数据密集型分析应用从本地迁移到云原生环境这一普遍的行业趋势进行了研究。通过分析 Uber 生产环境中的 Presto 查询记录，由于不同云厂商的成本模型显著不同，对这些分析应用的常见 I/O 优化可能会因为存储 API 调用而产生意想不到的成本（每年数千万美元）。此外还可能导致这些应用在迁移到云环境后产生高昂的额外成本且降低效率。要实现成功迁移上云和正常运行，系统研究人员和开发人4、员必须了解云存储服务的细微差别，并为这些环境中的应用量身定制高效的I/O 策略。数据密集型分析应用主要是 Apache Spark、Apache Hive、Presto 22,20,17等分析计算引擎。一直以来，这些应用都是在本地环境中构建和运行的，依赖于HDFS（Hadoop分布式文件系统）等存储系统，通过最大限度地减少存储和计算之间的数据传输来确保数据本地性。此外，分布式计算引擎中的离散节点或进程通常单独进行文件级请求，例如读取文件或列出目录（list directory)。这里不进行节点协作的前提条件是 I/O 请求的成本主要体现在瞬时资源消耗(网络带宽、内存或处理能力)上,而非直接的财5、务支出。十多年来，这些设计原则一直指导着计算引擎的发展，主导并推动着 I/O 优化，有效提高了 I/O 吞吐量并降低了延迟。然而，随着这些应用程序向云环境迁移，有关数据本地性和成本模型的假设都受到了考验。首先，云存储服务（如 AWS S3、Azure Blob Storage 和 GoogleCloud Storage(GCS)）在各自的云生态系统中迅速崛起，成为主要的数据湖解决方案。因此，数据不再局限于本地网络上的服务，而是由云基础设施提供，节点数据本地性的概念不再适用。其次，这些云存储服务采用了与传统本地存储解决方案完全不同的定价结构。具体来说，它们对分散的 API 调用收费，而这些费用不6、一定与传输的数据量成正比 2,14,9。如果没有认识到这一点可能会导致成本迅速增加。031 导言本文从成本角度研究以 I/O 为重点的云上数据密集型分析负载，包含以下内容：在第2节中，介绍了根据云存储的不同情况来调整认知和策略的重要性，以及其对应用设计和性能的影响。在第3节中，基于来自Uber的真实数据进行案例研究，介绍了广泛使用的 I/O优化技术（如 table scan 和 filter、broadcast join）在企业级云迁移中可能会带来的计划外成本。在第4节中，提供了有关云计算领域系统设计的全新视角，帮助相关方应对数据密集型应用的快速发展。04本节介绍了云厂商在存储资源方面采用的定7、价模型。与传统的本地存储相比，访问数据的可选成本非常高，而且用户往往不清楚这部分成本，这在很大程度上导致在现代云存储上运行传统数据密集型计算引擎存在不可预测性。表1（见下文）比较了不同云存储服务（如S3、GCS 和 Azure Blob Storage）访问数据的API调用定价模型。这些供应商的共同点是，存储API调用的成本取决于API调用的次数，而非访问的数据大小。在API调用成本方面，访问一个3KB的对象可能比单独访问同一对象的首个KB和最后一个KB数据便宜，即使前一请求总共只需下载2KB的数据，而前一请求下载了3KB的数据。此外，不同的云厂商对操作的分类不同，采用的服务层级也各不相同，这8、也会影响成本。例如，Amazon S3 根据请求次数收费，将请求分为两类：PUT、COPY、POST 和 LIST 请求；以及 GET、SELECT 和其他所有请求。相比之下，AzureBlob Storage 根据写入和读取操作收费。具体存储层的选择，无论是高级存储层、热存储层、冷存储层还是归档存储层，都会对总体成本产生重大影响。关于在云上运行类似 Hadoop、Spark 或 Presto 的数据密集型应用，有如下发现：云存储服务引入了一种基于存储API调用次数和数据传输量的特殊成本模型。这些数据密集型应用中的 API 调用通常包括读取、写入和访问元数据的操作，每次调用都会产生费用。这些系9、统的设计和优化历来是为了尽量减少数据传输量，而不一定是为了减少或整合存储 API 调用次数。此外，数据分析系统（如 Presto）中的传统 I/O 优化方法侧重于读取操作。本文在讨论这些优化方法在云迁移过程中带来的财务成本挑战和影响时，将重点关注读取操作。数据密集型应用通常涉及大量的 I/O 操作，如数据处理和传输，没有任何预设置的流量限速。对 I/O 操作不加限制会导致成本上升，影响在云上运行此类应用的财务可行性。2 云成本模型053.1 工业分析流量模式在云 I/O 成本方面的挑战为了理解分析应用在大规模企业级数据上的数据访问流量模式，并分析迁移到云原生环境后I/O 优化对云成本的影响，我10、们从 Uber 生产环境的 Presto 集群中收集了使用数据。考虑到负载平衡，该集群的工作负载模式代表了 Uber 的离线Presto 处理流量，而这正是 Presto 在 Uber 的主要用例。这些数据记录了大约五天的集群操作。结合 I/O 使用数据和在生产环境中的运行经验，得出以下结论：分析作业须每天处理大量的数据读取操作。Uber 13和 Twitter 19最近的研究表明，一个 Presto 集群每天可处理10到50 PB的数据。图1：Uber典型Presto节点上存储数据访问大小的累积分布函数（CDF）3 I/O 优化对工业分析负载的影响06 列式文件格式占主导地位。目前，数据分析11、的数据集主要以列式文件格式存储，例如Apache Parquet 和 ORC 21,6。列式文件之所以比传统的行式文件更受欢迎，主要在于其支持谓词下推（predicate pushdown）等优化，从而可提高数据读取性能。I/O操作大部分来自于小数据片段的访问。在 Uber，Presto 对存储的访问中有超过50%小于10KB，而超过90%的访问小于1 MB，如图1所示。这主要是因为数据集以列式文件格式存储。基于上述观察，Presto 负载中的每个读取请求通常只访问小数据片段，导致在Uber规模的工作负载下出现每天数十亿次的读取API调用。因此，将 Presto 负载迁移到云上可能会对分析负载12、产生巨大的成本影响。但是这类 I/O 流量在现代企业数据平台上所有数据密集型应用中仅占较小的比例。理解这类由于 API 调用产生的成本以及可采取的措施至关重要。普遍使用的分析引擎（如 Spark SQL 和 Presto）的优化根本上是为了提高查询吞吐量和降低延迟，这是由快速响应数据分析的需求驱动的。本地部署与云原生环境不同，其 API 调用不涉及财务成本。就优化方式而言，尤其是那些应用于列式文件格式的优化，可能会在减少数据读取量的同时增加数据请求量。在以下章节中，将基于 Uber 的实际数据分析负载进行案例研究，并分析各类 I/O 优化的影响。Uber 生产环境中的 Presto 应用了许多13、主流的优化方法，如索引（indexing)、表1：Amazon S3、Google Cloud Storage 和 Azure Blob Storage 的存储成本定价适用于AWS美国东部俄亥俄地区（US East Ohio）、GCP北美地区（NorthAmerica）和 Azure美国西部2地区（West US 2）。截至2023年8月28日。07Uber 在优化分析负载时对延迟的关注体现在 table scan 操作的实现和优化上。Table scan 是一种读取表中所有行的技术，对于大型数据集来说，计算成本可能很高。为了提高table scan 的性能，主要的优化方法之一是使用谓词下推，14、常用于扫描 Apache Parquet 和 Apache ORC 等列式文件格式。该方法允许数据库系统在访问磁盘数据前跳过不必要的行和列。示例见图 2。假设数据库系统需要处理一条 SQL 语句 SELECT B,C FROM t WHERE A 15 and B=10。在处理列 A并应用条件 A 15后，查询引擎将索引 1、3、4 和 6 传递到下一阶段，因为只有这些索引的值满足要求。接着，在处理列 B 时，查询引擎不需要扫描所有行，而只需读取已传递索引的行。其他行将被跳过，避免不必要的扫描。在应用条件 B=10后，计算引擎会选择索引 1、4 和 6，并将它们传递给下一阶段，以选择 C 列中15、的相应行。因此，谓词下推可以显著减少 CPU 和 I/O 的使用，从而加速查询执行并降低成本。3.2 Table scan 和 filter 优化带来的成本挑战延迟物化(late materialization)和 shuffle join。但由于篇幅限制，本文将重点关注Uber分析负载中使用的两种典型优化方法：第3.2节中的 table scan/filter和第3.3节中的 broadcast join。本文旨在分析无成本导向的优化对于计费成本的潜在负面影响。第4节将讨论应对这些挑战的策略。图2：在处理SQL语句SELECT B,C FROM t WHERE A 15and B=10时应用16、filter来跳过不必要的行。08不过，需注意的是，当 table scan 访问云存储时，谓词下推也会带来一些成本方面的弊端。虽然它能节省 CPU 和 I/O 的使用，但会产生更多的碎片化读取，反过来又会导致更多的对云存储的API调用。这样一来就增加了查询执行的总成本，使其在工业用例中的成本效益降低。在 Uber，Presto平均每次访问底层存储系统会读取约 10 KB 的数据。鉴于 Uber 的 Presto 系统每天要访问约 10 PB 至 50 PB的数据，因此 Presto 集群每天要向存储系统发送 1 万亿至 5 万亿个读取请求。相比之下，根据对 Meta 的 Presto 工作负17、载的分析16，在没有应用谓词下推优化的情况下，数据读取量约为优化后数据读取量的 5 倍。将这一数据应用于 Uber 的Presto 工作负载，如果不进行谓词下推优化，Uber 的 Presto 系统每天将访问约50 PB 至 250 PB 的数据，每次 Presto 数据访问将获取 1 MB 的 Parquet 页面（Uber 默认 Parquet 设置）。因此，如果不应用谓词下推优化，Uber 的 Presto每天只会向存储发送 500 亿至 2500 亿个读取请求，仅为启用优化后所需请求数的 5%。总之，如果没有其他的成本导向优化策略，云迁移将产生难以预测的高API 成本。因此，数据库系统18、在针对延迟和成本效益优化 table scan 时，需要仔细平衡谓词下推的收益和成本。3.3 Broadcast Join 优化的成本挑战Uber 对延迟的关注还体现在分析负载中 Broadcast Join 操作的实现和优化上。Broadcast Join 涉及复制小表（build table），并将其发送到存储部分大表（probe table）的所有节点。这可以大大减少完成 join 所需的时间和资源。图 3举例说明了这一概念，其中两个计算节点参与了查询处理。启用 Broadcast Join后，两个计算节点都负责将较小的 build table从数据源加载到内存中。相反，较大的 prob19、e table 则以流式模式从数据源加载。分布式处理模式允许两个 worker并行处理条目，从而加快了整体处理速度。09出于对延迟问题的重视，数据库系统已转向优化 broadcast join，以缩短处理的完成时间。例如，Apache Spark 可以自动优化 join 操作，并根据表的大小和可用资源决定何时使用 broadcast join。不过，需注意的是，broadcast join 不一定是最具成本效益的方法，由于每个计算节点都需要将广播表中的所有数据加载到内存或本地磁盘存储中，因此会增加系统的存储成本。Uber 的 Presto 平台每天处理约 50 万次查询，其中约 20%的查询使20、用了 broadcast join 优化。在 Presto 中，触发优化的 build table 大小默认阈值为 100 MB。根据观察，Uber 分析负载的 build table 通常很大，从 20 MB到 100 MB 不等。Uber 的每个 Presto 集群包含 200 个 worker 节点，由此计算出：200100MB500k 20%=2PB 这表明，在 Uber 的单个 Presto 集群中，仅构建跨 worker 节点的 build table就需要访问多达 2 PB 的数据。此外，访问的数据大小与 Presto 集群中的 worker节点数呈线性关系，这表明计算出的 2 21、PB 数据中，有（1-1/（节点数），即199/200=99.5%）由于重复读取广播表而被浪费。考虑到同时采用 tablescan/filter 和 broadcast join 两种优化策略，在没有成本导向优化的情况下，处理如此海量的数据可能会每天产生超过100亿次的 API 调用。图 3：broadcast join示例。每个worker将build table加载到内存中，同时并行处理probe table中的条目。104.1 提高存储资源效率提高有关公有云的成本意识和成本效益将是云厂商及其客户的制胜法宝。目前，主要的云厂商提供了各类存储服务，让组合使用实现性能优化和成本效益提升成为可能22、。例如，Amazon S3 Select 3 可帮助过滤存储层中的数据、减少 API 调用次数并减小访问的数据量，但仅限于 AWS。Mingyu Liu 等人12全面回顾了云存储用户成本优化策略的最新进展，将其分为提高存储效率和利用云存储服务功能两类。这些服务的灵活性使得量身定制的数据存储策略不仅能满足个性化的业务需求，而且在有效利用的情况下还能显著节约成本。Hojin Park 等人15探讨了如何利用可迁移上云存储，帮助具有不同数据寿命要求的 I/O 负载降低成本和/或提高性能。Kadekodi 等人10指出，由于API调用成本，在云对象存储中操作大量小对象（KB级别）的成本很高，并提出了一23、项客户侧的修改，即把多个小对象合并成一个大对象，但可能会牺牲一定的稳定性。不过，这些论文都没有关注数据密集型应用（如分析）或广泛使用的 I/O 优化对于系统设计的影响。114 讨论4.2 创建带缓存的虚拟存储层124.3 具备成本意识，重新设计数据密集型应用还有一种有效策略是以成本为导向，重新设计侧重 I/O 优化的数据密集型应用。这需要从根本上重新评估应用程序与数据和存储资源的交互方式。与其依赖传统的数据访问模式，不如在设计这些应用时充分利用所选存储资源的优势，扬长避短。例如，Junjay Tan 等人18 对云数据库的选择进行了开创性的研究并对性能和成本进行了评估，不过他们没有详细探讨本文24、讨论的存储 API 成本。另一种策略就是引入作为协调虚拟存储层的平台来应对这些挑战：它可以消除对后端存储的冗余请求，减少不必要的数据流量，优化存储利用率。它可以纳入流量速控机制，防止流量限制，从而确保数据操作的顺畅和不间断。此外，在工业数据分析负载中，热数据在一天内可能会被重 复访问数十万次。就 Uber 的数据分析负载而言，50%的已访问数据会在不到 2 小时内被再次访问；最热的前10,000个数据块获得了约 90%或更多的读取流量1。虚拟存储可以预加载热数据，并通过缓存服务来提供需频繁访问的数据。目前，在这一方向上有一些开创性的项目。例如，Haoyuan Li 等人11提出了名为 Allu25、xio 的虚拟分布式文件系统（VDFS），可应对数据存储和数据处理中日益复杂的问题和挑战。该系统具有全局数据可访问性、高效的内存数据共享、高 I/O性能以及灵活的计算和存储选项等优势。尽管如此，成本效益还是在很大程度上被忽视，我们对这类虚拟层的数据策略也不 甚了解。此外，由于计算引擎通常只读取一小部分数据，而缓存颗粒度通常是文件 或数据块级别的，缓存可能会导致读放大这一重大弊端。我们期待在这方面有更多 研究，从而能更好地了解其潜力和局限性。Michael Armbrust等人8提出了Lakehouse 架构，并认为业界正在使用该架构替代数据仓库。Delta Lake、Iceberg 和 Apa26、che hudi 7,5,4 推出了 ACID 表存储层，并支持行级追加（append）和插入（insert)操作。不过，这种设计可能会导致大量小文件和小文件读取操作，从而影响云迁移的财务成本。期待在这方面有更多的研究力量，以全面评估最新数据湖表布局对成本的影响。总之，这些系统演进和新兴的数据湖格式主要侧重于提高云原生环境中的性能或提供更强的数据稳定性，而不一定将云中的 I/O 成本作为主要的设计考量因素。我们认为，在成本和性能之间取得谨慎的平衡至关重要，在有效实现的情况下可带来实质性的优化。13总之，将数据密集型分析应用迁移至云基础设施时，需要重新评估那些主要聚焦吞吐量和延迟的标准化优化方法27、，原因在于云环境具有不同的成本模型。为了实现成功迁移和持续性发展，系统研究者和开发者需要深入理解不同云存储服务之间的细微差别，并制定出高效的 I/O 策略。5 结论141 Optimizing hdfs with datanode local cache for high-density hdd adoption,2023.2 Amazon.Amazon s3 pricing,2023.https:/ Amazon.Amazon s3 select,2023.https:/ Apache.Apache hudi,2023.https:/hudi.apache.org/.5 Apache.Apa28、che iceberg:The open table format for analytic datasets.,2023.https:/iceberg.apache.org/.6 Apache.Apache ORC,2023.https:/orc.apache.org/.7 Michael Armbrust,Tathagata Das,Liwen Sun,Bu rak Yavuz,Shixiong Zhu,MukulMurthy,Joseph Torres,Herman van Hovell,Adrian Ionescu,Alicja uszczak,et al.Delta lake:hig29、h-performance acid table storage over cloud object stores.Proceedings of the VLDB Endowment,13(12):34113424,2020.68 Michael Armbrust,Ali Ghodsi,Reynold Xin,and Matei Zaharia.Lakehouse:a newgeneration of open platforms that unify data warehousing and advanced analytics.InProceedings of CIDR,page 8,2030、21.9 Google.Gcs:Cloud storage pricing,2023.https:/ Saurabh Kadekodi,Bin Fan,Adit Madan,Garth A Gibson,and Gregory R Ganger.Acase for packing and indexing in cloud file systems.In 10th USENIX Workshop on HotTopics in Cloud Computing(HotCloud 18),2018.11 Haoyuan Li.Alluxio:A Virtual Distributed File S31、ystem.PhD thesis,EECSDepartment,University of California,Berkeley,May 2018.12 Mingyu Liu,Li Pan,and Shijun Liu.Cost optimization for cloud storage from userperspectives:Recent advances,taxonomy,and survey.ACM Computing Surveys,2023.13 Zhenxiao Luo,Lu Niu,Venki Korukanti,Yutian Sun,Masha Basmanova,Yi32、 He,Beinan Wang,De vesh Agrawal,Hao Luo,Chunxu Tang,et al.From batch processingto real time analytics:Running presto at scale.In 2022 IEEE 38th InternationalConference on Data Engineering(ICDE),pages 15981609.IEEE,2022.14 Microsoft.Azure blob storage pricing,2023.https:/ Hojin Park,Gregory R.Ganger,33、and George Amvrosiadis.More iops for less:Exploiting burstable storage in public clouds.In Proceedings of the 15th USENIXConference on Hot Cloud,pages 114.USENIX Association,2020.16 Raghav Sethi,Martin Traverso,Dain Sundstrom,David Phillips,Wenlei Xie,YutianSun,Nezih Yegitbasi,Haozhun Jin,Eric Hwang34、,Nileema Shingte,et al.Presto:Sql oneverything.In 2019 IEEE 35th International Conference on Data Engineering(ICDE),pages 18021813.IEEE,2019.17 Yutian Sun,Tim Meehan,Rebecca Schlussel,Wen lei Xie,Masha Basmanova,OrriErling,Andrii Rosa,Shixuan Fan,Rongrong Zhong,Arun Thiru pathi,et al.Presto:Adecade 35、of sql analytics at meta.Proceedings of the ACM on Management of Data,1(2):125,2023.18 Junjay Tan,Thanaa Ghanem,Matthew Perron,Xiangyao Yu,Michael Stonebraker,David De Witt,Marco Serafini,Ashraf Aboulnaga,and Tim Kraska.Choosing a clouddbms:architectures and tradeoffs.Proceedings of the VLDB Endowme36、nt,12(12):21702182,2019.19 Chunxu Tang,Beinan Wang,Huijun Wu,Zhenzhao Wang,Yao Li,VrushaliChannapattan,Zhenxiao Luo,Ruchin Kabra,Mainak Ghosh,Nikhil Kan tibhaiNavadiya,et al.Serving hybrid-cloud sql interactive queries at twitter.In SoftwareArchitecture:15th European Conference,ECSA 2021 Tracks and 37、Workshops;Vaxj o,Sweden,September 1317,2021,Revised Selected Papers,pages 321.Springer,2022.20 Ashish Thusoo,Joydeep Sen Sarma,Namit Jain,Zheng Shao,Prasad Chakka,Suresh Anthony,Hao Liu,Pete Wyckoff,and Raghotham Murthy.Hive:a warehousingsolution over a map-reduce framework.Proceedings of the VLDB E38、ndowment,2(2):16261629,2009.21 Deepak Vohra.Apache Parquet.In Practical Hadoop Ecosystem,pages 325335.Springer,2016.22 Matei Zaharia,Mosharaf Chowdhury,Michael J Franklin,Scott Shenker,Ion Stoica,et al.Spark:Cluster computing with working sets.HotCloud,10(10-10):95,2010.16书关于Alluxio（扫码添加小助手）（扫码关注All39、uxio）Alluxio是全球领先的高性能数据平台提供商，聚焦于大数据分析和AI场景，可加速企业AI产品价值变现，并最大化基础设施的投资回报率。Alluxio数据平台位于计算与存储系统之间，能够在数据工作流的各个阶段为数据平台上的工作负载提供统一视图。无论数据位于何处，该平台均可提供高性能的数据访问，简化数据工程，提高GPU利用率，并降低云计算和存储成本。企业无需使用专用存储，即可大幅加速模型训练和模型服务，并在现有数据湖上构建AI基础设施。Alluxio在头部投资者的支持下，为全球科技、互联网、金融和电信企业提供服务，目前全球排名前 10 的互联网公司中有 9 家在使用Alluxio。北京开元维度科技有限公司于2021年在北京海淀区中关村成立，在开源软件Alluxio的基础上进行封装，旨在向企业级客户提供持续丰富的应用场景和不断升级的软件服务。目前，Alluxio高性能数据平台为金融服务、高科技、零售和电信等诸多领域客户提供了长期业务支持。