计算型存储:异构计算的下一个关键应用
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
计算型存储:异构计算的下一个关键应用相关推荐
- 计算型存储: 异构计算的下一个关键应用
AWS re:Invent2019显示AWS市场占用率达到45%,相比2018年营收增长29%.使用专用芯片构建用于加速特定场景的战略更加清晰,除去Intel和AMD的X86和Nvidia GPU,还 ...
- 下一个五年,存储的生意在哪里?
企业级存储还是一门好生意么? 在很多人眼中,随着公有云最近十年的兴起,企业级存储早已过了它的黄金时代,如今沦为基础设施领域的配角,利润大幅下降不说,还费力不讨好,成为彻彻底底的鸡肋. 但事实真是如此么 ...
- 2020:下一个十年,存储发展的趋势是什么?(全集)
前 言 今天是五四青年节,祝朋友们永葆青春的心态,积极乐观.开放真实.审慎务实. " 青春不是年华,而是心境. 无论年届花甲,抑或二八芳龄,心中皆有生命之欢乐,奇迹之诱惑,孩童般天真 ...
- 云存储,下一个浪潮之巅,看云存储格局之变
<浪潮之巅>一度成为IT公司追捧而热销的书籍,讲诉的是近一百多年来,国内外知名科技公司的兴衰史,更重在揭示他们兴衰的必然规律.云存储也被誉为下一个浪潮之巅,那么,云存储行业(个人网盘&am ...
- 初探元宇宙存储,数据存储市场下一个爆点?
2021年,元宇宙一词火爆全球,成为全社会关注的焦点. 除了在游戏和娱乐领域大有前途之外,元宇宙还能干嘛?让我们来看看元宇宙在医疗领域如何小试牛刀. "把二维CT切片组合成三维立体的'全息数 ...
- 张亚勤、韦乐平等综述论文:通信人工智能的下一个十年
来源:专知 [摘 要]移动通信技术走过了37年的发展历程,人工智能技术也已走过了64年的发展历程.从早期的各自独立演进,到5G与人工智能开始深度融合发展,"5G与人工智能"已被业界 ...
- 新华三:存储下一个十年是智能和速度并举
"首创精简卷技术.融合存储的缔造者.第一个开辟软件定义存储市场.首创存储人工智能.第一家推出IDP智能存储平台.第一家实现并行多控制存储平台--"过去十年,论对于存储趋势的洞察.把 ...
- AI算力需求6年增长30万倍,「超异构计算」才能满足下一个10年
今年 3 月,「强化学习教父」Richard Sutton 在<苦涩的教训>一文中指出,「70 年的人工智能研究史告诉我们,利用计算能力的一般方法最终是最有效的方法.要在短期内有所提升,研 ...
- js cookie 存储checkbox_[cookie实战记录-1]种下一个cookie
[cookie实战记录-1]种下一个cookie 引子 cookie ~ 也是前端实际工作中一定会碰到的(哎?为什么要说也呢...) 而且由于前一阵 Chrome 的更新改了关于 cookie sam ...
最新文章
- python lambda匿名函数 用法
- sql必知必会(第四版) 学习笔记一
- selenium 使用js执行脚本儿链接整理
- wince导航_宁可用手机导航,也不用汽车导航?
- 排列、组合问题(递归)
- 自动将存储过程转成C#代码的过程[转]
- Leetcode PHP题解--D7 905. Sort Array By Parity
- 鸿蒙os编码_终于有人把鸿蒙OS讲明白了,大佬讲解!快收藏!
- debian stretch + kernel 4.4 固件发布(支持硬件加速),可安装kodi
- TensorFlow2.0项目实战:从模型搭建到工业化部署全链路!
- table添加一行且可编辑 vue_vue表格添加可编辑的一行后如何得到整个表格的数据...
- 博弈中的 SaaS 渠道
- 项目管理十大知识领域(二)--- 项目范围管理(过程、输入、工具和技术、输出)
- 修改了Excel默认打开方式后仍然使用WPS打开的解决办法
- 微信:一个必须研究的产品
- 【回顾】巨杉数据库中标东莞农商银行非结构化内容管理平台项目
- HUAWEI华为MateBook 13 2020款 锐龙版 R7 集显 触屏 16GB+512GB (HNL-WFP9Q)原装出厂系统恢复原厂系统
- 完美解决微信页面返回不刷新问题
- leaflet流入迁徙图(canvas技术)(leaflet篇.71)
- 【Java】保姆级“方法“教学
热门文章
- ansible 安不安全_如何向您的安全团队介绍Ansible
- 领导力十律_关于开放领导力的10个最受欢迎的故事
- (6)<a>标签如何实现点击既不刷新也不跳转的功能
- ROS笔记(25) 自主探索SLAM
- php公众号客服消息图文,微信公众号开发系列-发送客服消息(示例代码)
- java 执行 cd_java执行cd命令
- java filter过滤器_JavaWeb之 Filter(过滤器)
- Luogu P1407 [国家集训队]稳定婚姻 (二分图写法)
- 视频编码技术---压缩感知编码---匹配跟踪算法
- 页面上插入flash文件