论文分享：利用对象存储进行高性能数据分析
本次分享的是慕尼黑工业大学（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 小时（以降低缓存对测试的影响）
- 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/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 中还有一些可圈可点的地方。作者观察到，系统为每个请求解析域名会带来相当大的延迟开销。
- 缓存多个 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/
