本次分享的是慕尼黑工业大学(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 KiB 的 Manifest Files 的操作,可能须要约 30 ms(p50,Cold)/ 约 60 ms(p99,Cold)。
- 读取 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 小时(以升高缓存对测试的影响)
- S3 提早最大;
- S3 有“最小提早”,即所有数据都比该数值高;
- 与 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/optimiz…
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 中还有一些可圈可点的中央。作者察看到,零碎为每个申请解析域名会带来相当大的提早开销。
- 缓存多个 Endpoint 的 IPs:将多个 Endpoint 的 IP 地址缓存,并通过调度申请到这些 IPs,基于统计信息更换那些性能显著降落的端点。
- 基于 MTU:不同 S3 节点具备不同的最大传输单元(MTU)。其中,一些 S3 节点反对应用最大 9001 字节的巨型帧(Jumbo frames),这能够显著升高 CPU 开销。
- MTU 发现策略:通过对指标节点 IP 进行 ping,并设置 Payload 数据大于 1500 字节且 DNF(do not fragment),以确定是否反对更大的 MTU。
集成云存储
在这一部分,作者介绍了他们是如何集成云存储的。总体而言,这些想法实际上都是趋同的,具体的实现细节还是要看各家工程实际的。
自适应
如果解决申请数据速度较慢,则缩小下载线程(及工作)数量并减少申请线程(及工作)数量。
性能评估
5.1 数据下载性能
作者将查问分为了两类,检索密集型(retrieval-heavy)和计算密集型:
- 检索密集型的代表:Q 1, 6, 19,其特点是 In-Memory 和 Remote 之间的性能差别是一个常数倍数。
- 计算密集型的代表:Q 9, 18,其特点是 In-Memory 和 Remote 之间的性能差别十分小。
5.2 不同存储的比照
EBS 性能最差(这里应该是买了 gp2/3 丐版,1 Gib 左右带宽)。
5.3 扩展性
- 检索密集型(Q1),瓶颈呈现在网络带宽
- 计算密集型(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 优化工作量或者不在一个数量级 🥹。
- https://instances.vantage.sh/aws/ec2/c5d.18xlarge
- https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf
对于 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/