JuiceFS 在大搜車資料平臺的實踐

JuiceFS發表於2021-11-16
UI

大搜車已經搭建起比較完整的汽車產業網際網路協同生態。在這一生態中，不僅涵蓋了大搜車已經數字化的全國 90% 中大型二手車商、9000+ 家 4S 店和 70000+ 家新車二網，還包括大搜車旗下車易拍、車行168、運車管家、布雷克索等具備較強產業鏈服務能力的公司， 與大搜車在新零售解決方案上達成深度戰略合作的長城汽車、長安汽車、英菲尼迪等主機廠商，以及與中石油崑崙好客等產業鏈上下游的合作伙伴。基於這樣的生態佈局，大搜車數字化了汽車流通鏈條上的每個環節，進而為整個行業賦能。

說到大資料，對於每個公司都不陌生。儲存元件 HDFS，計算資源管理 YARN，離線計算 Hive、Spark、Spark SQL，列儲存資料庫 HBase，實時計算Spark Streaming、Flink等。這些元件在叢集穩定情況下維護還算比較輕鬆，但是在公司快速發展過程中，叢集容量的高速增長是不可避免的，作為大資料的設計者不得不從叢集的成本和效益上思考兩者的權衡。

大資料叢集現狀

大搜車目前大資料叢集分為離線計算叢集和實時計算叢集，離線計算基於 Hive 和 Spark，實時計算基於 Flink，這兩類叢集分別基於 HDP 和 CDH 兩套管理方式。早期離線計算選用了 HDP，實時計算後來選用 CDH 的初衷是多叢集管理比較方便。由於離線計算引擎兩者是有區別的，遷移會有相容性問題，兩套叢集一直並存，叢集間資源完全隔離。

叢集維護痛點

資料量持續增長，成本一定的情況下做叢集擴容耗時耗力

從 18 年初到 19 年 6 月份，離線叢集從最初的數十個節點持續增長到上百個節點，資料量也從數十 TiB 增長了 10 多倍，並且保持每天數 TiB 的速度增加。在節省開支的情況下，每月做一次叢集擴容，形成了與資料增長速度賽跑的情況。每月固定工作差不多變成了接受磁碟告警狂炸、擴容、均衡資料、再均衡資料的情況。遇到一些極端情況，比如阿里雲在某個可用區沒有資料型別裝置資源而要新在另一個可用區建立，還會涉及到資料網段變更，就更復雜了。

  1. 儲存所需資源跟計算資源不同步

在對離線叢集資料做分析過程中發現，熱點資料僅佔大約 20%。在叢集不斷擴容的情況下，計算資源會有較大冗餘，產生了不必要的成本，另外每次均衡會佔用節點網路頻寬，影響任務讀寫資料的速度。

  1. 跨叢集資料同步

為了減少了實時任務和離線任務的相互影響，方便資源控制和雲資源選型價值最大化，實時計算和離線計算叢集在物理上做了資源隔離，難點也隨之出現，實時和離線叢集的資料無法實時同步，造成一些需求無法實現。

  1. NameNode記憶體持續增長，重啟時間過久

在檔案儲存中，檔案數量過多導致 NameNode 管理記憶體持續增加，重啟一次時間過長，勢必影響資料同步；並且在數倉層面不嚴加控制資料生命週期，資源佔用也會越來越大，在對叢集中整個資源做分析時也會受到影響。

選擇 JuiceFS

針對以上這些問題，選取一款產品做底層儲存勢在必行。儲存選擇上作為大資料的基石，需要遵從如下特點：

  • 相容Hadoop框架協議
  • 多版本叢集相容
  • 高吞吐、低延時
  • 支援深度壓縮減少資源使用

在一開始，我們嘗試使用阿里雲的 OSS 作為冷備儲存。在測試過程中，由於沒有元資訊管理，在資料維護上很受限制。後來接觸到了 JuiceFS 這款產品，在選擇上很是滿足上述要求。對此我們做了一些效能測試（均基於實際場景提取業務邏輯）。

實際場景效能測試

以下測試均選取實際業務資料，資料大小是 where 查詢條件不同選取的，僅做兩個檔案系統效能對比：

  • SELECT + INSERT 操作

從 3000 萬左右表中分別選取不同量級資料插入另一張表結構一樣的表中，橫向對比 HDFS 和 JuiceFS 耗時。

  • SELECT + COUNT 操作

從3000萬左右表中分別選取不同量級資料做 COUNT，橫向對比 HDFS 和 JuiceFS 耗時。

  • SELECT + ORDERBY

對 3000 萬左右表中資料做排序，橫向比較 HDFS 和 JuiceFS 的耗時。

綜上，JuiceFS 在查詢、插入資料時多數耗時比較穩定且整體比HDFS耗時要少，在 SELECT 資料情況，多數效能相差不多極個別情況要優於 HDFS，單行做排序操作效能差不多。

成本控制

我們對比了採用 JuiceFS 和 HDFS 兩種方案的費用（HDFS 叢集保證儲存冗餘 20%）。在同等資料量（JuiceFS 會再次做深度壓縮，壓縮比大約為 3:1）和對等計算資源的情況下采用 JuiceFS 每月會比使用雲主機部署 HDFS 節省至少 18%。

綜合看 JuiceFS 的效能和成本都非常滿足公司對成本和產品效能的要求。

未來展望

儲存計算分離

大資料叢集引入 JuiceFS，儲存和計算實際上已經分離。大資料叢集靈活彈性擴充套件計算資源已經成為可能，在凌晨業務低谷期可以將業務機器的計算資源排程給大資料叢集。

以下是目前整個大資料叢集架構：

後續可以結合計算儲存分離和動態伸縮設計為如下目標架構：

與 Kubernetes 做結合，按需申請資源，節省成本和減少維護成本。

推薦閱讀：
JuiceFS CSI Driver 的最佳實踐

專案地址： Github （https://github.com/juicedata/juicefs）如有幫助的話歡迎關注我們喲！ (0ᴗ0✿)

相關文章