计算型存储：异构计算的下一个关键应用
AWS re:Invent2019显示AWS市场占用率达到45%，相比2018年营收增长29%。使用专用芯片构建用于加速特定场景的战略更加清晰，除去Intel和AMD的X86和Nvidia GPU，还有通过其Annapurna Labs部门推出的基于Arm的Graviton的定制芯片，并承诺基于Graviton2（7纳米）的新型EC2实例的性能是第一代Graviton的7倍。
早在摩尔定律失效之前，一个逐渐达成的共识就是通用处理器的算力应该专注于复杂的商业逻辑，而简单重复的工作则由专用芯片完成更加合适。
超算和智能网卡
早在20年以前，基于异构计算的智能网卡就已经应用于超算（HPC）领域。从1993年开始 TOP500 就以每年两次的频率，基于 Linpack benchmark 负载模型来统计地球上运行最快的超级计算集群。
- 2003年，弗吉尼亚理工学院暨州立大学创建一个InfiniBand集群，在当时的TOP500排名第三；
- 2009年，世界500强超级算机中，152个使用InfiniBand，并提供38.7%的算力；
- 2020年11月，根据最新的第56版，155个使用 InfiniBand，并提供40%的算力，排名前10的超算集群有8个由 InfiniBand 构建，更是占据了前5的4席位置。
在构建高速网路时，争论主要是把网络功能Onload到CPU上，还是把这些功能Offload到专用硬件：
- 常用Onloading，TCP/IP技术在数据包从网卡到应用程序的过程中，要经过OS，数据在主存、CPU缓存和网卡缓存之间来回复制，给服务器的CPU和主存造成负担，也加剧网络延迟。
- Offloading 基于RDMA实现远程内存直接访问，将数据从本地快速移动到远程主机应用程序的用户空间，通过Zero-copy和Kernel bypass来实现高性能的远程直接数据存取的目标。
下图可以直观的看到两者在访问路径的区别：
当然，Offloading 需要将RDMA协议固化于硬件上，所以依赖于网卡的算力是否可以满足运行RDMA协议的开销，这实际上就是专用芯片和网卡的结合。用更性感的说法是：
SmartNICs are an example of DPU (Data Processing Unit) technology
AWS和Nitro
云计算催生超大规模数据中心，也同时放大通用算力的不足和异构计算的优势。就好比研发团队规模变大的同时必然走向专业化。AWS EC2早期由纯软（也意味着需要消耗CPU）的Xen对CPU、存储和网络完成虚拟化。基于这种实现方式，一个EC2实例的虚拟化管理开销高达30%。
30%相当可观，最重要的是并没有为客户提供直接价值。按照 Werner Vogels（AWS CTO ）的说法：
想为客户显著提高性能、安全性和敏捷性，我们必须将大部分管理程序功能迁移到专用硬件上。
- 2012年，AWS开始构建Nitro系统，也正是这，登纳德缩放定律（严格说是预测）几乎消失：
- 2013年， Nitro 应用于C3实例，其网络进程卸载到硬件中；
- 2014年，推出了C4实例类型，将EBS存储卸载到硬件中，并开始和Annapurna Labs合作；
- 2015年，收购 Annapurna Labs；
- 2017年，C5实例卸载控制平面和剩余的I/O，实现完整的Nitro系统；
此时，Nitro系统已经包含三个主要部分：Nitro卡、Nitro安全芯片和Nitro管理程序。主要卸载和加速IO，虚拟私有云（VPC）、弹性块存储（EBS）和实例存储，从而让用户可以使用100%的通用算力。
对客户而言，意味更好的性能和价格，下图可以看到基于Nitro的C5和I3.metal的延时明显降低：
计算型存储和数据库
从AWS的营收看，网络、存储、计算和软件是收入的四驾马车，数据库毫无疑问是存储领域的关键场景。随着云计算带来基础环境的改变，也直接加速云原生技术的发展和成熟，程序员不会再写出单体（Monolithic）应用，也再也不会在应用中只使用一种数据库。还是借用Werner Vogels的话：
A one size fits all database doesn't fit anyone.
从AWS提供的数据库服务也应证了一点（国内的云计算巨头也类似）。
不同的数据库针对不同的场景，比如Airbnb使用 Aurora 替代 MySQL，Snapchat 使用DynamoDB 承载起最大的写负载，麦当劳将ElastiCache应用于低延时高吞吐的工作负载，旅游网站expedia.com使用ElasticSearch实时优化产品价格。当然，对于存储介质，更快速和更大容量的需求普遍存在。从下面数据库的工程实践看，压缩是实现这一目标的共识：
DB-Engines DBMS数据压缩特性
DBMS | ✔是否支持数据压缩 |
|---|---|
Oracle | ✔ |
MySQL | ✔ |
Microsoft SQL Server | ✔ |
PostgreSQL | |
MongoDB | ✔ |
IBM Db2 | ✔ |
Elasticsearch | ✔ |
Redis | ✔ |
SQLite | ✔ |
Cassandra | ✔ |
压缩率依赖于数据本身，1948年由美国数学家克劳德·香农（Claude Shannon）在经典论文《通信的数学理论》中首先提出信息熵，理想情况下，不管是什么样内容的数据，只要具有同样的概率分布，就会得到同样的压缩率。
在实现时，常常要在压缩吞吐，解压吞吐，和牺牲压缩率之间做取舍，这也是产生诸多压缩算法的原因。下图是基于Silesia compression corpus不同压缩算法之间的差异。
Compressor Name | Ratio | Compression | Decompress |
|---|---|---|---|
zstd 1.4.5 -1 | 2.884 | 500MB/S | 1660MB/S |
zlib 1.2.11 -1 | 2.743 | 90MB/S | 400MB/S |
brotli 1.0.7 -0 | 2.703 | 400MB/S | 450MB/S |
zstd 1.4.5--fast=1 | 2.434 | 570MB/S | 2200MB/S |
zstd 1.4.5--fast=3 | 2.312 | 640MB/S | 2300MB/S |
quicklz 1.5.0 -1 | 2.238 | 560MB/S | 710MB/S |
zstd 1.4.5 --fast=5 | 2.178 | 700MB/S | 2420MB/S |
lzo1x 2.10 -1 | 2.106 | 690MB/S | 820MB/S |
lz4 1.9.2 | 2.101 | 740MB/S | 4530MB/S |
lzf 3.6 -1 | 2.077 | 410MB/S | 860MB/S |
snappy 1.1.8 | 2.073 | 560MB/S | 1790MB/S |
从一个常见的场景出发，应用多次写入压缩率各不相同的数据，逻辑写入量为36KB，如下图所示：
按照前面所示的压缩率，最理想的情况是压缩后占用15.2KB。
但现有的空间管理实践会占用更多的物理空间，首先写入时需要按照文件系统页对齐写入（假设4KB），占用物理空间为48KB，数据存储分布如下图所示：
但因为压缩后数据依然需要按照文件系统页大小（4KB）对齐，数据存储分布如下图所示：
所以实际占用的物理空间是36KB离预期的压缩率相去甚远。
为进一步提升压缩效率，通常会进一步压实（compaction）空间，压实后数据存储分布如下：
这时占用的物理空间是 16KB，才接近15.2KB。
可见在工程实践时，要想在应用场景中获得可观的压缩收益，仅关注数据结构和压缩算法是不够的，还要考虑压实(Compaction)效率，如果还要兼顾算力消耗、IO延时和代码复杂度等指标，工程难度将指数级提升。
针对这个场景，支持透明压缩的计算型存储 CSD2000，将压缩解压缩算法offload到盘内FPGA，使计算更靠近数据存储的地方（“in-situ computing”），进一步缩短数据路径，从而提升数据处理的效率。
对比“软”压缩（基于CPU）和硬压缩（基于FPGA）两者的收益并不复杂，下面以MySQL为例，将MySQL页压缩，MySQL表压缩和CSD2000透明压缩三者进行对比，采用TPC-C和TPC-E数据集和负载模型，以压缩率和数据库性能（TPS和时延）为指标衡量压缩效率。
先看压缩率，计算型存储 CSD2000 提供更高的压缩率，几乎是MySQL自带压缩的2倍以上，如下所示：
再看性能，使用sysbench测试1/4/16/64/256/512并发下性能表现，可以观察到（如下图所示）：
- ≥ 64并发时，CSD2000 QPS/TPS平均提高~5倍，最高提高~12倍，99%平均时延降低68%以上；
- <64并发时，CSD2000 QPS/TPS普遍高于普通NVMe SSD 20%~50%，99%平均时延降低8%~45%；
说明：为了便于对比，以普通NVMe SSD指标为基线做归一化。
Mark Callaghan （Facebook Distinguished Engineer）曾经吐槽在数据库中实现透明页压缩并应用在生产环境，工程实现过于复杂，难怪Jens Axboe（Linux内核代码主要贡献者之一，FIO和IO_URING的作者）建议他把这些工作丢给计算型存储公司 ScaleFlux。而从计算型存储带来的压缩及性能（详见：可计算存储：数据压缩和数据库计算下推）收益来看已经超额完成任务。
计算型存储和文件系统
压缩同时减少数据写入量（Nand Written）和写放大（Write Amplification），但实际的情况会更复杂一些，大多数情况下数据库运行在文件系统之上。
以日志型文件系统ext4为例，设计以下测试验证日志写入量与数据库数据写入量的比例及透明压缩对于减少写入量的收益：
- 选用 MySQL 和 MariaDB；
- 200GB数据集；
- 3种负载模型：Insert/Update-Index/Update-Non-Index；
- 两种数据访问方式：热点集中（Non-uniform Key Distribution） 和全随机（Uniform Key Distribution）；
最终测试结果如下：
- 因为文件系统的 WAL（Write Ahead Log）机制，加上日志的稀疏结构，日志写入量占整体写入量20%~90%，可见文件系统日志写入量可能大于上层应用（数据库）的数据写入量；
- 透明压缩对于减少数据库数据量的写入效果明显，对于减少日志系统写入量的效果更加显著，全部测试场景减少日志写入量约4~5倍；
说明：以普通NVMe SSD指标为基线做归一化，直方图面积越小，数据写入量越少。
人类的智慧注定都要在山顶相遇
亚马逊经常谈论单向（one-way）和双向（two-way）门决策。双向门决策容易逆转，例如A/B test，这类决策可以快速采取行动，即使失败，成本也不高。单向门决策大多数时候不可撤销，必须”大胆假设，小心求证“。Nitro 显而易见是一个单向（one-way）门决策，即便是2012年开始，AWS也花了足足7年时间才完整落地。
在异构计算领域，头部云计算厂已经达成共识，相关产品也加速推出，包括支持计算下推的阿里云PolarDB（详见：可计算存储：数据压缩和数据库计算下推），以及 AWS re:Invent2020 再次提到的基于 AUQA（Advanced Query Accelerator） 节点加速的 Redshift。
风物长宜放眼量，人类的智慧注定都要在山顶相遇。
作者：熊中哲，金戈
引用
https://www.mellanox.com/solutions/high-performance-computing/top500
https://www.mellanox.com/related-docs/solutions/hpc/TOP500-NOV-2020.pdf
https://www.top500.org/statistics/list/
http://www.ruanyifeng.com/blog/2014/09/information-entropy.html
https://www.nextplatform.com/2020/07/20/the-growing-dependence-of-vmware-on-aws/
https://en.wikipedia.org/wiki/In-situ_processing
https://www.nextplatform.com/2020/10/20/blurring-the-lines-between-your-cloud-and-their-clouds/
https://www.gartner.com/en/newsroom/press-releases/2020-08-10-gartner-says-worldwide-iaas-public-cloud-services-market-grew-37-point-3-percent-in-2019
https://pages.awscloud.com/AQUA_Preview.html