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

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

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

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

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

2009年，世界500強(qiáng)超級(jí)算機(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í)，爭(zhēng)論主要是把網(wǎng)絡(luò)功能Onload到CPU上，還是把這些功能Offload到專(zhuān)用硬件：

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

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

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

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

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

AWS和Nitro

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

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

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

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

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

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

2015年，收購(gòu) Annapurna Labs；

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

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

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

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

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

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

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

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

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

壓縮率依賴于數(shù)據(jù)本身，1948年由美國(guó)數(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è)常見(jiàn)的場(chǎng)景出發(fā)，應(yīng)用多次寫(xiě)入壓縮率各不相同的數(shù)據(jù)，邏輯寫(xiě)入量為36KB，如下圖所示：

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

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

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

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

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

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

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

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

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

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

再看性能，使用sysbench測(cè)試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%；

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

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

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

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

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

選用 MySQL 和 MariaDB；

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

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

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

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

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

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

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

人類(lèi)的智慧注定都要在山頂相遇

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

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

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

責(zé)任編輯：lq