提起對(duì)象存儲(chǔ)，業(yè)界唯一扛把子就是 AWS Simple Storage Service (S3), 國(guó)內(nèi)云廠商不需要做什么，要什么創(chuàng)新，直接抄就完事。協(xié)義都是現(xiàn)成的，哪家廠商敢不支持 s3 協(xié)義，都會(huì)被現(xiàn)實(shí)打臉，純純的開卷考試。

對(duì)于公司來(lái)講，無(wú)論是否多云架構(gòu)，還是自建 IDC, 對(duì)象存儲(chǔ)選型也只能是支持 S3 協(xié)義的，比如探探選型的 Minio?, 還有基于 SeaweedFS 改造的，必選項(xiàng)就是協(xié)義。

業(yè)務(wù)也有很多基于 S3 的創(chuàng)業(yè)項(xiàng)目，比如基于 Fuse 實(shí)現(xiàn)的 juicefs 分布式文件系統(tǒng)，目前大數(shù)據(jù)領(lǐng)域用的非常多，聽(tīng)說(shuō)前兩年實(shí)現(xiàn)了收支平衡，當(dāng)然收入來(lái)自國(guó)外 ^^ 還有 olap 數(shù)據(jù)庫(kù) databend 等等。

基礎(chǔ)設(shè)施

S3 己經(jīng)是 IT 的基礎(chǔ)設(shè)施，想象不到離開 S3, 自建成本有多離譜。做為程序員自建輪子飛起，技術(shù)實(shí)現(xiàn)上也沒(méi)什么秘密，都是公開的，鍛煉技術(shù)。就看誰(shuí)能把穩(wěn)定性做好，把成本降下來(lái)。

上面截圖來(lái)自 aws 官網(wǎng)，大數(shù)據(jù)分析、日志存儲(chǔ)、應(yīng)用數(shù)據(jù)、視頻圖片、備份都圍繞 S3, 對(duì)于應(yīng)用來(lái)講，屏蔽了底層細(xì)節(jié)，無(wú)容量限制。

而且 aws 大部分產(chǎn)品也都構(gòu)建在 s3 之上，圍繞對(duì)象存儲(chǔ)基礎(chǔ)設(shè)施，構(gòu)建龐大的生態(tài)。這也是為什么單獨(dú)做云存儲(chǔ)的廠商，無(wú)法存儲(chǔ)，無(wú)法盈利的原因 ... 比如七牛，如果用阿里云的大數(shù)據(jù)平臺(tái)，存取七牛對(duì)象存儲(chǔ)還要跨公網(wǎng)，誰(shuí)也接受不了這個(gè)成本，這家公司半死不活，己經(jīng)淪落為某云廠商 cdn 的二道販子。

也可以想象一下，如果我司自建 IDC, 現(xiàn)有的 infra 團(tuán)隊(duì)人員至少翻倍，這里羨慕國(guó)外的 infra 創(chuàng)業(yè)，能買 saas 服務(wù)，絕不造輪子。從財(cái)務(wù)到辦公軟件，從監(jiān)控系統(tǒng)到數(shù)據(jù)庫(kù)，都是買的服務(wù)。

剛畢業(yè)工作時(shí)，數(shù)據(jù)庫(kù)的備份只能寫到磁盤上，然后把磁盤存儲(chǔ)到保險(xiǎn)柜，沒(méi)得選，當(dāng)時(shí)國(guó)內(nèi)公有云廠商接受度還不高。

成本與選型

S3 好用，但代價(jià)也是真的貴，需要根據(jù)實(shí)用使用選擇不同的類型：Standard?, Intelligent-Tiering? 與 Glacier。

標(biāo)準(zhǔn)的最貴，對(duì)于頻繁讀取的默認(rèn)即可。如果數(shù)據(jù)讀很少，可以選擇 Intelligent-Tiering? 智能存儲(chǔ)：Frequent Access Tier?, Infrequent Access Tier?, Archive Instant Access Tier。

對(duì)于不追求多活的可以選擇 one-zone, 去掉 versioning 多版本存儲(chǔ)，進(jìn)一步降低成本。

對(duì)于大量的歷史審記數(shù)據(jù)，選擇 Glacier 冰川類型，缺點(diǎn)是轉(zhuǎn)成冰川類型，后續(xù)無(wú)法讀取，需要手動(dòng)恢復(fù)成正常類型。

AWS 當(dāng)然不是大善人，冰川類型存取都要花錢，一次性轉(zhuǎn)換成本非常高。對(duì)于大量小對(duì)象，無(wú)法利用 Intellint-Tiering 類型，最小對(duì)象大小要求 128KB， 同時(shí)每個(gè)對(duì)象還有額外 40KB 開銷，用于維護(hù)對(duì)象元數(shù)據(jù)信息。我們服務(wù)的 10% 成本來(lái)自這塊的開銷，驚不驚喜，意不意外 ...

至于技術(shù)實(shí)現(xiàn)細(xì)節(jié)，估計(jì)也是多副本離線轉(zhuǎn) EC 糾刪碼, 但是 aws 擁有龐大的機(jī)器規(guī)模，海量的過(guò)保機(jī)器，閑著也是閑著。這里推薦美團(tuán)對(duì)象存儲(chǔ)系統(tǒng)[1], 干活十足，技術(shù)點(diǎn)都講到了。

小對(duì)象合并

這里介紹下我們的場(chǎng)景，訂單完成或退貨，都要拍照生成 proof 憑據(jù)，供后續(xù)審計(jì)使用。訂單完成還要生成發(fā)票收據(jù)，這些都是圖片的形式存儲(chǔ)到 S3, 海量的小對(duì)象，成本非常高。

為了降低成本己經(jīng)選擇了智能存儲(chǔ)與冰川類型，但是這還遠(yuǎn)遠(yuǎn)不夠。這類場(chǎng)景有個(gè)前提：

• 歷史圖片訪問(wèn)的概率非常低，一周前的圖片基本不會(huì)讀取。
• 單獨(dú)使用圖片沒(méi)用，只有綁定到訂單才有意義。

經(jīng)過(guò)調(diào)研我們可以把圖片壓縮，并且合并成大文件按歷史時(shí)間存儲(chǔ)，好處是可以充分利用智能類型，使用便宜的 tier, 同時(shí)圖片經(jīng)過(guò)壓縮后大小只有原來(lái)的一半。

原有邏輯，后端服務(wù)生成臨時(shí) presigned s3 public URL, 客戶端公網(wǎng)訪問(wèn)即可，那么如何讀取歷史訂單數(shù)據(jù)呢？這里用到了 s3 的技術(shù) object accesspoint[2] 與 select api[3]。

簡(jiǎn)單來(lái)講，歷史數(shù)據(jù)合并成 ?parquet 格式大文件，上傳到 S3, 用戶訪問(wèn) encoded s3 url 時(shí)，access point 調(diào)用 lambda 解析 url, 定位到 parquet 文件位置，然后使用 S3 Select API 查詢圖片數(shù)據(jù)。

message Object {
 required int64 ID;
 required int64 DriverID;
 required int64 CityID;
 required int64 Index;
 required binary Payload;
}

可以把 parquet? 想象成數(shù)據(jù)庫(kù)的表，提前定義好 schema, 使用 SQL 來(lái)查詢數(shù)據(jù)。Object? 由 thrift 定義 IDL, Payload 是我們的歷史圖片 binary 數(shù)據(jù)。

select Payload from S3Object where ID=XXX limit 1

這是 select api 定義的查詢 SQL, 至于 AWS 底層如何存儲(chǔ) parquet? 文件仍然是黑盒，limit 1? 算子好像不能 condition push down 到底層存儲(chǔ)，無(wú)法提前返回，也就是說(shuō)加不加 limit 1 效果可能一樣。

func (impl *implDecoder) Decode(bucket, key string, filters map[string]string) ([]byte, error) {

 sql := fmt.Sprintf("select Payload from S3Object where  %s limit 1", strings.Join(clauses, " and "))
 logger.Info(logTag, "Decode bucket %s key %s filters %v sql: %s", bucket, key, filters, sql)

 // small objects default 50KB
 writer := bytes.NewBuffer(make([]byte, 0, 50*1024))

 if err := selectFromObjects(context.Background(), impl.selector, writer, bucket, key, sql); err != nil {
  return nil, err
 }
 return writer.Bytes(), nil
}

上面是 lambda 回調(diào)的偽代碼示例，像不像讀取數(shù)據(jù)庫(kù)？

理想情況下，aws 應(yīng)該將 parquet? 按照 Row Group 分開存儲(chǔ)數(shù)據(jù)，并且用 parquet index 加速查詢，或者是自建 Object 索引，類似于 mysql table. 或者添加 bloomfilter, 總之就是減少數(shù)據(jù)掃描，一個(gè)是減小 access point 查詢時(shí)間，一個(gè)是減少成本，aws 奸商是按照掃描數(shù)據(jù)大小收費(fèi)的?。。?/p>

目前 aws 應(yīng)該沒(méi)實(shí)現(xiàn)算子下推，了解這塊的朋友可以說(shuō)下 ^^ 再次感慨 aws 生態(tài)的強(qiáng)大，收費(fèi)也是真貴。

?小結(jié)

推薦大家讀下 minio 或者 seaweedfs 源碼，本篇分享的優(yōu)化 idea 啟發(fā)于 minio 源碼。多讀讀業(yè)界實(shí)現(xiàn)，沒(méi)壞處，說(shuō)不定哪個(gè)帶來(lái)了靈感。

參考資料

[1]https://www.bilibili.com/video/BV1za4y1v7Tb: "美團(tuán)對(duì)象存儲(chǔ)系統(tǒng)",

[2]AWS object accesspoint: "https://aws.amazon.com/blogs/aws/introducing-amazon-s3-object-lambda-use-your-code-to-process-data-as-it-is-being-retrieved-from-s3/",

[3]S3 Select API: "https://docs.aws.amazon.com/AmazonS3/latest/API/API_SelectObjectContent.html"??