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

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

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

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

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

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

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

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

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

成本與選型

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

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

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

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

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

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

小對象合并

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

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

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

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

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

簡單來講，歷史數(shù)據(jù)合并成 ?parquet 格式大文件，上傳到 S3, 用戶訪問 encoded s3 url 時，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ù)庫的表，提前定義好 schema, 使用 SQL 來查詢數(shù)據(jù)。Object? 由 thrift 定義 IDL, Payload 是我們的歷史圖片 binary 數(shù)據(jù)。

select Payload from S3Object where ID=XXX limit 1

這是 select api 定義的查詢 SQL, 至于 AWS 底層如何存儲 parquet? 文件仍然是黑盒，limit 1? 算子好像不能 condition push down 到底層存儲，無法提前返回，也就是說加不加 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ù)庫？

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

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

?小結(jié)

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

參考資料

[1]https://www.bilibili.com/video/BV1za4y1v7Tb: "美團(tuán)對象存儲系統(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"??