您的位置:  首页 > 技术杂谈 > 正文

论文分享:利用对象存储进行高性能数据分析

2024-02-04 15:00 https://my.oschina.net/u/6839317/blog/11029309 格睿科技Greptime 次阅读 条评论

本次分享的是慕尼黑工业大学(TUM) Dominik Durner,Viktor Leis,和 Thomas Neumann 于 2023 年 7 月发表在 PVLDB(Volume 16 No.11) 的论文: Exploiting Cloud Object Storage for High-Performance Analytics。

DB:https://umbra-db.com/ 论文地址:https://www.vldb.org/pvldb/vol16/p2769-durner.pdf

概述:

🌟 ...Our experiments show that even without caching, Umbra with integrated AnyBlob achieves similar performance to state-of-the-art cloud data warehouses that cache data on local SSDs while improving resource elasticity...

我们的云原生时序分析型数据库研发团队在这篇文章上受益匪浅,论文主要聚焦于如何在对象存储上进行高性能数据分析,其中一些结论为我们的工程实践提供了明确的指导方向。

AWS S3 背景介绍

  • AWS S3 每 TB 存储成本为 23 美元每月,同时可以实现 11 个 9 的可用性。需要注意的是,最终费用还取决于调用的 API 次数以及跨 Region 的流量费用;
  • 访问 S3 的带宽可达到 200 Gbps,这取决于实例的带宽。在原文的 Introduce section 中为 100 Gbps,但后文提到在 AWS C7 系列机型上,这一带宽可以跑满 200 Gbps。

论文中提到 AWS S3 面临以下挑战: 挑战 1:无法充分利用带宽; 挑战 2:存在网络 CPU 额外开销 (主要是 One-to-one thread mapping 带来的一些问题); 挑战 3:缺少多云支持。

🌟 这三个挑战重要程度刚好也是 1 > 2 > 3

云存储(对象存储)特征

云存储(对象存储)通常提供相对较低的延迟(根据负载大小在若干毫秒至数百毫秒之间)和较高的吞吐量(上限取决于 EC2 带宽,EC2 第 7 代机型上可高达 200 Gbps),适用于大规模数据的读取和写入。相比之下,Amazon Elastic Block Store(EBS)通常提供更低的延迟(个位毫秒级),但其吞吐量则低于云存储,通常相差一到两个数量级。

2.1 延迟

  • 小请求中,首字节延迟(First byte latency)是决定性的影响因素;
  • 对于大请求,从 8 MiB 到 32 MiB 的实验显示,延迟随着文件大小呈线性增长,最终达到了单个请求的带宽限制;
  • 热数据方面,我们使用第一次请求和第二十次请求分别代表请求冷热数据的场景。在请求热数据的情境中,延迟通常更低。

🌟 对应到我们读取文件的场景中: 1. 读取平均大小小于 1 KiB 的 Manifest Files 的操作,可能需要约 30 ms(p50, Cold)/约 60 ms(p99,Cold)。 2. 读取 8 MiB 的 Parquet 文件,则需要约 240 ms(p50,Cold)/约 370 ms(p99,Cold)。

2.1.1 吵闹的邻居(Noisy neighbors)

实验方法:单个请求 16 MiB 带宽(Bandwidth)的计算方式:总字节数/持续时间

  • 对象带宽存在较大的变化,范围从约 25 到 95 MiB/s 不等。
  • 有相当数量的数据点(15%)位于最大值(~95 MiB/s)
  • 中位数性能稳定在 55-60 MiB/s。
  • 周末性能较高

2.1.2 不同云厂家的延迟

实验方法:单个文件 16 MiB,每次请求间隔 12 小时(以降低缓存对测试的影响)

  1. S3 延迟最大;
  2. S3 有“最小延迟”,即所有数据都比该数值高;
  3. 与 AWS 相比,在低延迟范围内的异常值表明其他供应商不隐藏缓存效果。

我认为这和 S3 底层硬件和实现或许也有关系,整体硬件更老旧或者不同的缓存方案都会导致 2,3 两个情况。

2.2 吞吐量

  • 单个文件 16 MiB,256 个并行请求,达到最大吞吐量(100 Gbps)
  • 随地域(Region)波动
  • AWS 75 Gbps (以下均为中位数)
  • Cloud X 40Gbps
  • Cloud Y 50Gbps
  • 冷热数据差别不大

2.3 最佳请求大小

通过上图可以看出,最佳请求大小通常在 8-16 MiB。尽管 32 MiB 的价格更低一些,但在相同带宽下,其下载用时会比 16 MiB 高一倍,相比于 8-16 MiB 而言优势并不明显。

2.4 加密

作者到目前为止所有的实验都是基于非安全链接 HTTP 测得的。在这一节中,作者比较了开启 AES 和启用 HTTPS 后的吞吐量表现。

  • HTTPS 需要 HTTP 2 倍 CPU 资源
  • AES 只需要增加 30% CPU 资源

在 AWS,所有区域之间的流量,甚至在可用区之间的所有流量都由网络基础设施自动加密。在同一个位置(Location)内,由于 VPC 的隔离,没有其他用户能够拦截 EC2 实例和 S3 网关之间的流量,因此使用 HTTPS 是多余的

2.5 慢请求

在实验中,我们观察到一些请求具有相当大的尾部延迟,甚至有些请求在没有任何通知的情况下丢失。为了应对这种情况,云供应商建议采用重新请求无响应的请求(request hedging)策略。

作者得到了一些慢请求的经验值,对于 16 MiB 大小的文件:

  • 在经过 600 毫秒后,只有不到 5% 的对象尚未被成功下载;
  • 第一个字节的延迟超过 200 毫秒的对象也不到 5%。

基于上述经验值,可以考虑对那些超过一定延迟阈值的请求进行重新下载的尝试。

🌟 Amazon Performance Guidelines for Amazon S3. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-guidelines.html

2.6 云存储数据请求模型

在研究中,作者注意到单个请求的带宽类似于访问 HDD 上的数据。为了充分利用网络带宽,需要大量并发请求。对于分析型工作负载而言,8-16 MiB 范围内的请求是具有成本效益的。他们设计了一个模型,用于预测达到给定吞吐目标所需的请求数量。

实验使用的计算实例(Instance)总带宽:100 Gbps,图中 Model(Hot)为之前实验中 25 分位(p25)延迟。

  • baseLatency 的中位数约为 30 ms (Figure 2:1 KiB 试验得出);
  • dataLatency 的中位数约为 20 ms/MiB,Cloud X 和 Cloud Y 更低 (12–15 ms/MiB) (Figure 2:16 MiB 中位数 - 基本延迟);
  • S3 跑满 100 Gbps 需要 200-250 个并发请求;
  • 数十几毫秒的访问延迟和单个对象的带宽约为 50 MiB/s,对象存储应该是基于 HDD 的(意味着以 ∼80 Gbps 从 S3 读取相当于同时访问约 100 个 HDD)。

AnyBlob

AnyBlob 是作者自行设计的通用对象存储库,支持访问不同云服务商的对象存储服务。与现有的 C++ S3 库相比,AnyBlob 采用了 io_uring 接口,并去除了一对一线程映射的限制。最终结果显示 AnyBlob 有着更高的性能并且 CPU 使用有所降低。然而,我认为主要原因可能就是现有 C++ S3 库质量太差了,说不定是实习生糊的。

域名解析策略 除此之外,AnyBlob 中还有一些可圈可点的地方。作者观察到,系统为每个请求解析域名会带来相当大的延迟开销。

  1. 缓存多个 Endpoint 的 IPs:将多个 Endpoint 的 IP 地址缓存,并通过调度请求到这些 IPs,基于统计信息更换那些性能明显下降的端点。
  2. 基于 MTU:不同 S3 节点具有不同的最大传输单元(MTU)。其中,一些 S3 节点支持使用最大 9001 字节的巨型帧(Jumbo frames),这可以显著降低 CPU 开销。
  3. MTU 发现策略:通过对目标节点 IP 进行 ping,并设置 Payload 数据大于 1500 字节且 DNF(do not fragment),以确定是否支持更大的 MTU。

集成云存储

在这一部分,作者介绍了他们是如何集成云存储的。总体而言,这些想法实际上都是趋同的,具体的实现细节还是要看各家工程实践的。

自适应 如果处理请求数据速度较慢,则减少下载线程(及任务)数量并增加请求线程(及任务)数量。

性能评估

5.1 数据下载性能

作者将查询分为了两类,检索密集型(retrieval-heavy)和计算密集型:

  1. 检索密集型的代表:Q 1, 6, 19 ,其特点是 In-Memory 和 Remote 之间的性能差异是一个常数倍数。
  2. 计算密集型的代表:Q 9, 18,其特点是 In-Memory 和 Remote 之间的性能差异非常小。

5.2 不同存储的对比

EBS 性能最差(这里应该是买了 gp2/3 丐版,1 Gib 左右带宽)。

5.3 扩展性

  1. 检索密集型(Q1),瓶颈出现在网络带宽
  2. 计算密集型(Q9),性能随着核心数量的增加而提高,远程 Umbra 版本的吞吐量几乎与内存版本相同。

5.4 End-To-End Study with Compression & AES

实验参数:比例因子(SF)为 100(∼100 GiB)和 1,000(∼1 TiB 的数据) 实验中用到的 Snowflake 为 large size,而 Umbra 使用了 EC2 的 c5d.18xlarge 实例,并且没有启用缓存。

总的来说,这个对比可能存在一些不够严谨的地方,比如没有提供 Snowflake 组更多的信息:

  • 对于 L size Snowflake,可能存在超售限流的情况;
  • Snowflake 组购买的可能是 Standard 丐版,这也可能影响实验结果。

不过另一个侧面也说明了:Benchmark marketing 的核心技术可能是统计学魔法 🧙(把没有击中缓存的那次查询藏到 p99 之后)。换句话说,单个查询跑 10 遍和跑 100 遍的 Benchmarking 优化工作量或许不在一个数量级 🥹。

关于 Greptime 的小知识:

Greptime 格睿科技于 2022 年创立,目前正在完善和打造时序数据库 GreptimeDB,格睿云 GreptimeCloud 和可观测工具 GreptimeAI 这三款产品。

GreptimeDB 是一款用 Rust 语言编写的时序数据库,具有分布式、开源、云原生和兼容性强等特点,帮助企业实时读写、处理和分析时序数据的同时降低长期存储成本;GreptimeCloud 可以为用户提供全托管的 DBaaS 服务,能够与可观测性、物联网等领域高度结合;GreptimeAI 为 LLM 量身打造,提供成本、性能和生成过程的全链路监控。

GreptimeCloud 和 GreptimeAI 已正式公测,欢迎关注公众号或官网了解最新动态!

官网:https://greptime.cn/ GitHub: https://github.com/GreptimeTeam/greptimedb 文档:https://docs.greptime.cn/ Twitter: https://twitter.com/Greptime Slack: https://greptime.com/slack LinkedIn: https://www.linkedin.com/company/greptime/

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接