TKE用戶故事 | 作業幫檢索服務基于Fluid的計算存盤分離實踐-有解無憂

作者

呂亞霖，2019年加入作業幫，作業幫基礎架構-架構研發團隊負責人，在作業幫期間主導了云原生架構演進、推動實施容器化改造、服務治理、GO微服務框架、DevOps的落地實踐，

張浩然，2019年加入作業幫，作業幫基礎架構-高級架構師，在作業幫期間，推動了作業幫云原生架構演進、負責多云k8s集群建設、k8s組件研發、linux內核優化調優、底層服務容器化相關作業，

背景

大規模檢索系統一直都是各個公司平臺業務的底層基石，往往是以千臺裸金屬服務器級別的超大規模集群的方式運行，資料量巨大，對于性能、吞吐、穩定性要求極為苛刻，故障容忍度很低，除了運行層面外，超大規模集群和海量資料場景下的資料迭代和服務治理也往往是一個巨大的挑戰：增量和全量的資料分發效率，短期和長期的熱點資料追蹤等都是需要深入研究的問題本文將介紹作業幫內部設計實作的基于 fluid 計算存盤分離架構，能夠顯著降低大規模檢索系統類服務的復雜度，使得大規模檢索系統可以像正常在線業務一樣平滑管理，

大規模檢索系統所面臨的問題

作業幫的眾多學習資料智能分析和搜索功能中都依賴于大規模資料檢索系統，我們的集群規模在千臺以上，總資料量在百 TB 級別以上，整個系統由若干分片組成，每個分片由若干服務器加載相同的資料集，運行層面上我們要求性能達到 P99 1.Xms，吞吐量高峰百 GB 級，穩定性要求 99.999% 以上，

以往環境中為了提高資料讀取效率和穩定性，更多的在考慮資料本地化存盤，我們的檢索系統每日產生索引項并需要進行 TB 級別的資料更新，這些資料通過離線建庫服務產出之后，需要分別更新到對應的分片中，這種模式下帶來了許多其他挑戰，比較關鍵的問題集中在資料迭代和擴展性上：

資料集合的離散：由于實際運行中，每個分片的每個節點都需要復制下來本分片所有資料，由此帶來了同步資料下發困難的問題，實際運行中如果要同步資料到單服務器節點，需要使用分級下發，先下發一級（十級）由一級分發給二級（百級）再分發給三級（千級），這個分發周期長且需要層層校驗來保證資料準確性，
業務資源彈性擴縮較弱：原先的系統架構采用的是計算和存盤緊耦合，資料存盤和算力資源緊密捆綁，資源靈活擴展能力不高，擴容往往需要以小時為單位進行，缺乏應對突發峰值流量擴容能力，
單分片資料擴展性不足：單分片資料上限受分片集群內的單機存盤上限限制，如果達到存盤上限，往往需要拆分資料集，而這種拆分不是由業務需求驅動的，

而資料迭代和擴展性的問題又不得不帶來了成本壓力和自動化流程上的薄弱，

通過對檢索系統運行和資料更新流程的分析，當前面臨的關鍵問題是由于計算和存盤的耦合所帶來的，因此我們考慮如何去解耦計算和存盤，只有引入計算存盤分離的架構才能夠從根本上解決復雜度的問題計算存盤分離最主要的就是將每個節點存盤本分片全量資料的方式拆分開，將分片內的資料存盤在邏輯上的遠程機器上但是計算存盤分離又帶來了其他的問題，比如穩定性問題，大資料量下的讀取方式和讀取速度，對業務的入侵程度等等問題，雖然存在這些問題，但是這些問題都是可解決以及易解決的基于此我們確認計算存盤分離一定是該場景下的良方，可以從根本上解決系統復雜度的問題，

計算存盤分離架構解決復雜度問題

為了解決上述計算存盤分離所需要考慮的問題，新的計算存盤分離架構必須能達到以下目標：

讀取的穩定性，計算存盤分離終究是通過各種組件配合替換掉了原始檔案讀取，資料加載方式可以替換，但是資料讀取的穩定性依然需要和原始保持同等水平，
每個分片千節點同時資料更新場景下，需要最大限度的提升讀取速度，同時對網路的壓力需要控制在一定程度內，
支持通過 POSIX 介面讀取資料，POSIX 是最具備對各種業務場景的適應性的方式，這樣無需侵入業務場景下，屏蔽了下游變動對上游的影響，
資料迭代的流程的可控性，對于在線業務來說，資料的迭代理應被視為和服務迭代等同的 cd 流程，那么資料迭代的可控性就及其重要，因為本身就是 cd 流程的一部分，
資料集合的可伸縮性，新的架構需要是一套可復制，易擴展的模式，這樣才能面對資料集合的伸縮、集群規模的伸縮具備良好的應對能力，

為了達成上述目標，我們最終選用了 Fluid 開源專案作為整個新架構的關鍵紐帶，

組件介紹

Fluid 是一個開源的 Kubernetes 原生的分布式資料集編排和加速引擎，主要服務于云原生場景下的資料密集型應用，例如大資料應用、AI應用等，通過 Kubernetes 服務提供的資料層抽象，可以讓資料像流體一樣在諸如 HDFS、OSS、Ceph 等存盤源和 Kubernetes 上層云原生應用計算之間靈活高效地移動、復制、驅逐、轉換和管理，而具體資料操作對用戶透明，用戶不必再擔心訪問遠端資料的效率、管理資料源的便捷性，以及如何幫助 Kuberntes 做出運維調度決策等問題，

用戶只需以最自然的 Kubernetes 原生資料卷方式直接訪問抽象出來的資料，剩余任務和底層細節全部交給 Fluid 處理，Fluid 專案當前主要關注資料集編排和應用編排這兩個重要場景，

資料集編排可以將指定資料集的資料快取到指定特性的 Kubernetes 節點，而應用編排將指定該應用調度到可以或已經存盤了指定資料集的節點上，這兩者還可以組合形成協同編排場景，即協同考慮資料集和應用需求進行節點資源調度，

我們選擇使用 fluid 的原因

檢索服務已經完成容器化改造，天然適合 fluid，
Fluid 作為資料編排系統，使得上層無需知道具體的資料分布就可以直接使用，同時基于資料的感知調度能力，可以實作業務的就近調度，加速資料訪問性能，
Fluid 實作了 pvc 介面，使得業務 pod 可以無感知的掛載進入 pod 內部，讓 pod 內可以像使用本地磁盤一樣無感知，
Fluid 提供元資料和資料分布式分層快取，以及高效檔案檢索功能，
Fluid+alluxio 內置了多種快取模式（回源模式，全快取模式），不同的快取策略（針對小檔案場景的優化等）和存盤方式（磁盤，記憶體），對于不同的場景具備良好的適應性，無需太多修改即可滿足多種業務場景，

落地實踐

快取節點和計算節點的分離: 雖然使用 fuse 和 worker 結合部署可以獲得更好的資料本地性能，但是在在線場景下，我們最終選用了快取和計算節點分離的方案，原因是通過延長一定的啟動時間換來更優的彈性是值得的，以及我們并不希望業務節點穩定性問題和快取節點的穩定性問題糾纏在一起，Fluid 支持 dataset 的可調度性，換言之就是快取節點的可調度性，我們通過指定 dataset 的 nodeAffinity 來進行資料集快取節點的調度，從而保證快取節點可高效，彈性化的提供快取服務，
在線場景的高要求: 對于在線業務場景，鑒于系統對于資料的訪問速度、完整性和一致性有較高的要求，因此不能出現資料的部分更新、非預期的回源請求等; 所以對資料快取和更新策略的選擇就會很關鍵，
- 合適的資料快取策略: 基于以上需求，我們選擇使用 Fluid 的全快取模式，在全快取模式下，所有請求只會走快取，而不在回源到資料源，這樣就避免了非預期的長耗時請求，同時 dataload 的程序則由資料更新流程來把控，更安全和標準化，
- 結合權限流的更新流程: 在線業務的資料更新也是屬于 cd 的一種，同樣也需要更新流程來管控，通過結合了權限流程的 dataload 模式，使得線上資料發版更安全和標準化，
- 資料更新的原子性: 由于模型是由許多檔案組成，只有所有的檔案全部快取起來之后，才是一份可以被使用的完整的模型；所以在全快取無回源的前提下，就需要保證 dataload 程序的原子性, 在資料加載的程序中過，新版本資料不能被訪問到，只有在資料加載完成之后，才可以讀取到新版本資料，