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

本次分享的是慕尼黑工业大学（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/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 中还有一些可圈可点的中央。作者察看到，零碎为每个申请解析域名会带来相当大的提早开销。

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 优化工作量或者不在一个数量级 🥹。

• 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/