聊聊最近基于 S3 的項目

作者：董澤潤 2022-09-03 23:15:04

業務也有很多基于 S3 的創業項目，比如基于 Fuse 實現的 juicefs 分布式文件系統，目前大數據領域用的非常多，聽說前兩年實現了收支平衡，當然收入來自國外 ^^ 還有 olap 數據庫 databend 等等。

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

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

基礎設施

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

上面截圖來自 aws 官網，大數據分析、日志存儲、應用數據、視頻圖片、備份都圍繞 S3, 對于應用來講，屏蔽了底層細節，無容量限制。

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

也可以想象一下，如果我司自建 IDC, 現有的 infra 團隊人員至少翻倍，這里羨慕國外的 infra 創業，能買 saas 服務，絕不造輪子。從財務到辦公軟件，從監控系統到數據庫，都是買的服務。

剛畢業工作時，數據庫的備份只能寫到磁盤上，然后把磁盤存儲到保險柜，沒得選，當時國內公有云廠商接受度還不高。

成本與選型

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

標準的最貴，對于頻繁讀取的默認即可。如果數據讀很少，可以選擇 Intelligent-Tiering? 智能存儲：Frequent Access Tier?, Infrequent Access Tier?, Archive Instant Access Tier。

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

對于大量的歷史審記數據，選擇 Glacier 冰川類型，缺點是轉成冰川類型，后續無法讀取，需要手動恢復成正常類型。

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

至于技術實現細節，估計也是多副本離線轉 EC 糾刪碼, 但是 aws 擁有龐大的機器規模，海量的過保機器，閑著也是閑著。這里推薦美團對象存儲系統[1], 干活十足，技術點都講到了。

小對象合并

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

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

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

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

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

簡單來講，歷史數據合并成 ?parquet 格式大文件，上傳到 S3, 用戶訪問 encoded s3 url 時，access point 調用 lambda 解析 url, 定位到 parquet 文件位置，然后使用 S3 Select API 查詢圖片數據。

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

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

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 回調的偽代碼示例，像不像讀取數據庫？

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

目前 aws 應該沒實現算子下推，了解這塊的朋友可以說下 ^^ 再次感慨 aws 生態的強大，收費也是真貴。

?小結

推薦大家讀下 minio 或者 seaweedfs 源碼，本篇分享的優化 idea 啟發于 minio 源碼。多讀讀業界實現，沒壞處，說不定哪個帶來了靈感。

參考資料

[1]https://www.bilibili.com/video/BV1za4y1v7Tb: "美團對象存儲系統",

[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"??

責任編輯：武曉燕來源：董澤潤的技術筆記

S3 項目源碼