AWS re:Invent2019顯示AWS市場占用率達(dá)到45%，相比2018年?duì)I收增長29%。使用專用芯片構(gòu)建用于加速特定場景的戰(zhàn)略更加清晰，除去Intel和AMD的X86和Nvidia GPU，還有通過其Annapurna Labs部門推出的基于Arm的Graviton的定制芯片，并承諾基于Graviton2（7納米）的新型EC2實(shí)例的性能是第一代Graviton的7倍。

早在摩爾定律失效之前，一個(gè)逐漸達(dá)成的共識(shí)就是通用處理器的算力應(yīng)該專注于復(fù)雜的商業(yè)邏輯，而簡單重復(fù)的工作則由專用芯片完成更加合適。

超算和智能網(wǎng)卡

早在20年以前，基于異構(gòu)計(jì)算的智能網(wǎng)卡就已經(jīng)應(yīng)用于超算（HPC）領(lǐng)域。從1993年開始TOP500就以每年兩次的頻率，基于Linpack benchmark負(fù)載模型來統(tǒng)計(jì)地球上運(yùn)行最快的超級計(jì)算集群。

2003年，弗吉尼亞理工學(xué)院暨州立大學(xué)創(chuàng)建一個(gè)InfiniBand集群，在當(dāng)時(shí)的TOP500排名第三；

2009年，世界500強(qiáng)超級算機(jī)中，152個(gè)使用InfiniBand，并提供38.7%的算力；

2020年11月，根據(jù)最新的第56版，155個(gè)使用 InfiniBand，并提供40%的算力，排名前10的超算集群有8個(gè)由 InfiniBand 構(gòu)建，更是占據(jù)了前5的4席位置。

在構(gòu)建高速網(wǎng)路時(shí)，爭論主要是把網(wǎng)絡(luò)功能Onload到CPU上，還是把這些功能Offload到專用硬件：

常用Onloading，TCP/IP技術(shù)在數(shù)據(jù)包從網(wǎng)卡到應(yīng)用程序的過程中，要經(jīng)過OS，數(shù)據(jù)在主存、CPU緩存和網(wǎng)卡緩存之間來回復(fù)制，給服務(wù)器的CPU和主存造成負(fù)擔(dān)，也加劇網(wǎng)絡(luò)延遲。

Offloading 基于RDMA實(shí)現(xiàn)遠(yuǎn)程內(nèi)存直接訪問，將數(shù)據(jù)從本地快速移動(dòng)到遠(yuǎn)程主機(jī)應(yīng)用程序的用戶空間，通過Zero-copy和Kernel bypass來實(shí)現(xiàn)高性能的遠(yuǎn)程直接數(shù)據(jù)存取的目標(biāo)。

下圖可以直觀的看到兩者在訪問路徑的區(qū)別：

當(dāng)然，Offloading 需要將RDMA協(xié)議固化于硬件上，所以依賴于網(wǎng)卡的算力是否可以滿足運(yùn)行RDMA協(xié)議的開銷，這實(shí)際上就是專用芯片和網(wǎng)卡的結(jié)合。用更性感的說法是

SmartNICs are an example of DPU (Data Processing Unit) technology

AWS和Nitro

云計(jì)算催生超大規(guī)模數(shù)據(jù)中心，也同時(shí)放大通用算力的不足和異構(gòu)計(jì)算的優(yōu)勢。就好比研發(fā)團(tuán)隊(duì)規(guī)模變大的同時(shí)必然走向?qū)I(yè)化。AWS EC2早期由純軟（也意味著需要消耗CPU）的Xen對CPU、存儲(chǔ)和網(wǎng)絡(luò)完成虛擬化。基于這種實(shí)現(xiàn)方式，一個(gè)EC2實(shí)例的虛擬化管理開銷高達(dá)30%。

30%相當(dāng)可觀，最重要的是并沒有為客戶提供直接價(jià)值。按照 Werner Vogels（AWS CTO ）的說法

想為客戶顯著提高性能、安全性和敏捷性，我們必須將大部分管理程序功能遷移到專用硬件上。

2012年，AWS開始構(gòu)建Nitro系統(tǒng)，也正是這，登納德縮放定律（嚴(yán)格說是預(yù)測）幾乎消失：

2013年， Nitro 應(yīng)用于C3實(shí)例，其網(wǎng)絡(luò)進(jìn)程卸載到硬件中；

2014年，推出了C4實(shí)例類型，將EBS存儲(chǔ)卸載到硬件中，并開始和Annapurna Labs合作；

2015年，收購 Annapurna Labs；

2017年，C5實(shí)例卸載控制平面和剩余的I/O，實(shí)現(xiàn)完整的Nitro系統(tǒng)；

此時(shí)，Nitro系統(tǒng)已經(jīng)包含三個(gè)主要部分：Nitro卡、Nitro安全芯片和Nitro管理程序。主要卸載和加速IO，虛擬私有云（VPC）、彈性塊存儲(chǔ)（EBS）和實(shí)例存儲(chǔ)，從而讓用戶可以使用100%的通用算力。

對客戶而言，意味更好的性能和價(jià)格，下圖可以看到基于Nitro的C5和I3.metal的延時(shí)明顯降低：

計(jì)算型存儲(chǔ)和數(shù)據(jù)庫

從AWS的營收看，網(wǎng)絡(luò)、存儲(chǔ)、計(jì)算和軟件是收入的四駕馬車，數(shù)據(jù)庫毫無疑問是存儲(chǔ)領(lǐng)域的關(guān)鍵場景。隨著云計(jì)算帶來基礎(chǔ)環(huán)境的改變，也直接加速云原生技術(shù)的發(fā)展和成熟，程序員不會(huì)再寫出單體（Monolithic）應(yīng)用，也再也不會(huì)在應(yīng)用中只使用一種數(shù)據(jù)庫。還是借用Werner Vogels的話

A one size fits all database doesn't fit anyone.

從AWS提供的數(shù)據(jù)庫服務(wù)也應(yīng)證了一點(diǎn)（國內(nèi)的云計(jì)算巨頭也類似）。

不同的數(shù)據(jù)庫針對不同的場景，比如Airbnb使用 Aurora 替代 MySQL，Snapchat 使用DynamoDB 承載起最大的寫負(fù)載，麥當(dāng)勞將ElastiCache應(yīng)用于低延時(shí)高吞吐的工作負(fù)載，旅游網(wǎng)站expedia.com使用ElasticSearch實(shí)時(shí)優(yōu)化產(chǎn)品價(jià)格。當(dāng)然，對于存儲(chǔ)介質(zhì)，更快速和更大容量的需求普遍存在。從下面數(shù)據(jù)庫的工程實(shí)踐看，壓縮是實(shí)現(xiàn)這一目標(biāo)的共識(shí)：

DB-Engines DBMS數(shù)據(jù)壓縮特性

壓縮率依賴于數(shù)據(jù)本身，1948年由美國數(shù)學(xué)家克勞德·香農(nóng)（Claude Shannon）在經(jīng)典論文《通信的數(shù)學(xué)理論》中首先提出信息熵，理想情況下，不管是什么樣內(nèi)容的數(shù)據(jù)，只要具有同樣的概率分布，就會(huì)得到同樣的壓縮率。

在實(shí)現(xiàn)時(shí)，常常要在壓縮吞吐，解壓吞吐，和犧牲壓縮率之間做取舍，這也是產(chǎn)生諸多壓縮算法的原因。下圖是基于Silesia compression corpus不同壓縮算法之間的差異。

從一個(gè)常見的場景出發(fā)，應(yīng)用多次寫入壓縮率各不相同的數(shù)據(jù)，邏輯寫入量為36KB，如下圖所示：

按照前面所示的壓縮率，最理想的情況是壓縮后占用15.2KB。

但現(xiàn)有的空間管理實(shí)踐會(huì)占用更多的物理空間，首先寫入時(shí)需要按照文件系統(tǒng)頁對齊寫入（假設(shè)4KB），占用物理空間為48KB，數(shù)據(jù)存儲(chǔ)分布如下圖所示：

但因?yàn)閴嚎s后數(shù)據(jù)依然需要按照文件系統(tǒng)頁大小（4KB）對齊，數(shù)據(jù)存儲(chǔ)分布如下圖所示：

所以實(shí)際占用的物理空間是36KB離預(yù)期的壓縮率相去甚遠(yuǎn)。

為進(jìn)一步提升壓縮效率，通常會(huì)進(jìn)一步壓實(shí)（compaction）空間，壓實(shí)后數(shù)據(jù)存儲(chǔ)分布如下：

這時(shí)占用的物理空間是16KB，才接近15.2KB。

可見在工程實(shí)踐時(shí)，要想在應(yīng)用場景中獲得可觀的壓縮收益，僅關(guān)注數(shù)據(jù)結(jié)構(gòu)和壓縮算法是不夠的，還要考慮壓實(shí)(Compaction)效率，如果還要兼顧算力消耗、IO延時(shí)和代碼復(fù)雜度等指標(biāo)，工程難度將指數(shù)級提升。

針對這個(gè)場景，支持透明壓縮的計(jì)算型存儲(chǔ) CSD2000，將壓縮解壓縮算法offload到盤內(nèi)FPGA，使計(jì)算更靠近數(shù)據(jù)存儲(chǔ)的地方（“in-situ computing”），進(jìn)一步縮短數(shù)據(jù)路徑，從而提升數(shù)據(jù)處理的效率。

對比“軟”壓縮（基于CPU）和硬壓縮（基于FPGA）兩者的收益并不復(fù)雜，下面以MySQL為例，將MySQL頁壓縮，MySQL表壓縮和CSD2000透明壓縮三者進(jìn)行對比，采用TPC-C和TPC-E數(shù)據(jù)集和負(fù)載模型，以壓縮率和數(shù)據(jù)庫性能（TPS和時(shí)延）為指標(biāo)衡量壓縮效率。

先看壓縮率，計(jì)算型存儲(chǔ) CSD2000 提供更高的壓縮率，幾乎是MySQL自帶壓縮的2倍以上，如下所示：

再看性能，使用sysbench測試1/4/16/64/256/512并發(fā)下性能表現(xiàn)，可以觀察到（如下圖所示）：

≥ 64并發(fā)時(shí)，CSD2000 QPS/TPS平均提高~5倍，最高提高~12倍，99%平均時(shí)延降低68%以上；

<64并發(fā)時(shí)，CSD2000 QPS/TPS普遍高于普通NVMe SSD 20%~50%，99%平均時(shí)延降低8%~45%；

說明：為了便于對比，以普通NVMe SSD指標(biāo)為基線做歸一化。

Mark Callaghan （Facebook Distinguished Engineer）曾經(jīng)吐槽在數(shù)據(jù)庫中實(shí)現(xiàn)透明頁壓縮并應(yīng)用在生產(chǎn)環(huán)境，工程實(shí)現(xiàn)過于復(fù)雜，難怪Jens Axboe（Linux內(nèi)核代碼主要貢獻(xiàn)者之一，F(xiàn)IO和IO_URING的作者）建議他把這些工作丟給計(jì)算型存儲(chǔ)公司 ScaleFlux。而從計(jì)算型存儲(chǔ)帶來的壓縮及性能（詳見：可計(jì)算存儲(chǔ)：數(shù)據(jù)壓縮和數(shù)據(jù)庫計(jì)算下推）收益來看已經(jīng)超額完成任務(wù)。

計(jì)算型存儲(chǔ)和文件系統(tǒng)

壓縮同時(shí)減少數(shù)據(jù)寫入量（Nand Written）和寫放大（Write Amplification），但實(shí)際的情況會(huì)更復(fù)雜一些，大多數(shù)情況下數(shù)據(jù)庫運(yùn)行在文件系統(tǒng)之上。

以日志型文件系統(tǒng)ext4為例，設(shè)計(jì)以下測試驗(yàn)證日志寫入量與數(shù)據(jù)庫數(shù)據(jù)寫入量的比例及透明壓縮對于減少寫入量的收益：

選用 MySQL 和 MariaDB；

200GB數(shù)據(jù)集；

3種負(fù)載模型：Insert/Update-Index/Update-Non-Index；

兩種數(shù)據(jù)訪問方式：熱點(diǎn)集中（Non-uniform Key Distribution） 和全隨機(jī)（Uniform Key Distribution）；

最終測試結(jié)果如下：

因?yàn)槲募到y(tǒng)的 WAL（Write Ahead Log）機(jī)制，加上日志的稀疏結(jié)構(gòu)，日志寫入量占整體寫入量20%~90%，可見文件系統(tǒng)日志寫入量可能大于上層應(yīng)用（數(shù)據(jù)庫）的數(shù)據(jù)寫入量；

透明壓縮對于減少數(shù)據(jù)庫數(shù)據(jù)量的寫入效果明顯，對于減少日志系統(tǒng)寫入量的效果更加顯著，全部測試場景減少日志寫入量約4~5倍；

說明：以普通NVMe SSD指標(biāo)為基線做歸一化，直方圖面積越小，數(shù)據(jù)寫入量越少。

人類的智慧注定都要在山頂相遇

亞馬遜經(jīng)常談?wù)搯蜗颍╫ne-way）和雙向（two-way）門決策。雙向門決策容易逆轉(zhuǎn)，例如A/B test，這類決策可以快速采取行動(dòng)，即使失敗，成本也不高。單向門決策大多數(shù)時(shí)候不可撤銷，必須”大膽假設(shè)，小心求證“。Nitro 顯而易見是一個(gè)單向（one-way）門決策，即便是2012年開始，AWS也花了足足7年時(shí)間才完整落地。

在異構(gòu)計(jì)算領(lǐng)域，頭部云計(jì)算廠已經(jīng)達(dá)成共識(shí)，相關(guān)產(chǎn)品也加速推出，包括支持計(jì)算下推的阿里云PolarDB（詳見：可計(jì)算存儲(chǔ)：數(shù)據(jù)壓縮和數(shù)據(jù)庫計(jì)算下推），以及AWS re:Invent2020再次提到的基于 AUQA（Advanced Query Accelerator） 節(jié)點(diǎn)加速的 Redshift。

風(fēng)物長宜放眼量，人類的智慧注定都要在山頂相遇。

責(zé)任編輯：lq