2020 年初，隨著網(wǎng)易互娛的海外業(yè)務(wù)增長與海外數(shù)據(jù)合規(guī)的需求，我們開始了網(wǎng)易互娛大數(shù)據(jù)離線計算平臺遷移出海的工作。前期，我們采取了云主機裸機加上高性能 EBS 塊存儲的方案。但是，這個方案存儲費用高昂，成本是國內(nèi)自建機房的數(shù)十倍。

于是，我們決定在公有云上構(gòu)建一個平臺，這個平臺不僅需要更加適應(yīng)當(dāng)前業(yè)務(wù)場景、與歷史業(yè)務(wù)更為兼容，還要比公有云的 EMR 托管方案更為經(jīng)濟。我們主要從存儲、計算和數(shù)據(jù)分層生命周期管理三方面進行了成本優(yōu)化，具體的優(yōu)化方案將在下文為大家詳細介紹。

最終，這個項目給下游數(shù)據(jù)業(yè)務(wù)和分析部門提供了完整 Hadoop 的兼容性，避免了所有業(yè)務(wù)邏輯推倒重來；給游戲數(shù)據(jù)業(yè)務(wù)出海節(jié)省了大量成本，存儲成本為優(yōu)化前的 50%，算力總成本為優(yōu)化前的 40%，冷數(shù)據(jù)成本為優(yōu)化后線上存儲成本的 33%。未來隨著業(yè)務(wù)量的增加，成本節(jié)約按 10 倍比例節(jié)約相應(yīng)的費用，為出海后的數(shù)據(jù)化運營等提供有力支持。

01. 大數(shù)據(jù)平臺海外上云方案設(shè)計

在 2020 年，我們開始了一項緊急的出海任務(wù)。在國內(nèi)，我們的業(yè)務(wù)一直以自建集群的方式進行部署和運行。為了在海外能夠快速上線，我們緊急上線了一個與國內(nèi)集群完全相同的解決方案，采用了物理節(jié)點構(gòu)建的一套存算一體的系統(tǒng)。我們選用了裸金屬服務(wù)器 M5.metal，并使用 EBS gp3 作為存儲。

這套方案的缺點是成本非常高昂，但是它的好處是解決了一個非常痛苦的問題，即我們需要兼容所有歷史業(yè)務(wù)，確保所有歷史業(yè)務(wù)能夠快速、立即地在海外運行。我們的上下游業(yè)務(wù)可以無縫遷移到海外，并支持每天接近30萬個作業(yè)的調(diào)度。

但是，成本一直是一個不能忽視的問題。因此，我們需要重新選擇方案，以獲得性能更優(yōu)、成本更低的解決方案，并確保兼容性。根據(jù)業(yè)務(wù)需求和大數(shù)據(jù)場景的特點，我們從以下幾個方向評估如何進行方案選擇：

• 以時間/空間換性能；
• 基于業(yè)務(wù)場景的實現(xiàn)部署優(yōu)化；
• 加入中間件實現(xiàn)兼容性的整合；
• 充分利用云資源的特性優(yōu)化成本。

Hadoop 上云

一般 Hadoop 上云有下面兩種方案，EMR+EMRFS、Dataproc+GCS。這兩種方案就是一個正常出海的姿勢?；蛘呤褂靡恍┰圃钠脚_，例如 BigQuery、Snowflake，Redshift 等做數(shù)據(jù)查詢方案，但是我們沒有去用這些方案。

為什么沒有使用 EMR

因為我們所有的業(yè)務(wù)都非常依賴 Hadoop，我們目前使用的 Hadoop 版本是根據(jù)業(yè)務(wù)需求定制的內(nèi)部版本，并實現(xiàn)了各種新版本功能向下兼容，有很多內(nèi)部的需求和優(yōu)化在 EMR 的 Hadoop 版本未能覆蓋。至于云原生的 BigQuery 等方案對業(yè)務(wù)來說，是一個改動更大更遙遠的方向。

為什么沒有直接使用 S3 存儲

1. 由于對數(shù)據(jù)業(yè)務(wù)安全的高需求導(dǎo)致我們有復(fù)雜的業(yè)務(wù)權(quán)限設(shè)計，遠超亞馬遜 IAM（Identity and Access Management）ROLE 能夠?qū)崿F(xiàn)的上限。

2. S3 的性能受限，需要分桶和隨機目錄等優(yōu)化措施，對業(yè)務(wù)使用不透明，調(diào)整目錄 prefix 去適配 S3 分區(qū)或使用更多的桶的方案都需要業(yè)務(wù)調(diào)整已有的使用方法，無法適配我們目前的目錄設(shè)計。另外，作為對象存儲實現(xiàn)的文件系統(tǒng)，直接對 S3 的目錄進行 list 和 du 等操作在超大文件數(shù)據(jù)情況下，基本上是不可用的，但是這又恰好是大數(shù)據(jù)場景下大量使用的操作。

存儲選型：HDFS vs 對象存儲 vs JuiceFS

我們主要從以下這些維度來評估存儲組件。

業(yè)務(wù)兼容性：對于我們這種擁有大量存量業(yè)務(wù)需要出海的情況，兼容性是一個非常關(guān)鍵的考慮因素。其次，降本增效不僅僅指降低存儲成本，還包括資源成本和人力成本的考慮。兼容性方面，JuiceFS 社區(qū)版兼容 Hadoop 生態(tài)，但需要在用戶端部署 JuiceFS Hadoop SDK。

一致性：在當(dāng)時，我們對 S3 進行了調(diào)研，但在 2020 年第一季度之前，并沒有實現(xiàn)強一致性，而目前也并非所有平臺都能做到強一致性。

容量管理：對于我們當(dāng)前自建的集群，有一個重要的問題是需要預(yù)留資源。也就是說，我們不可能使用到 100% 的資源，因此按需使用是一個非常節(jié)省成本的方向。

性能：基于 HDFS 可以達到我們國內(nèi)自建的 HDFS 的性能水平。我們國內(nèi)提供給業(yè)務(wù)的 SLA 是在單集群下 4 萬 QPS 的情況下，能夠?qū)崿F(xiàn) p90 在 10 毫秒以內(nèi)的 RPC 性能。但是對于類似 S3 的情況，實現(xiàn)這樣的性能非常困難。

權(quán)限認證：在自建集群中，使用 Kerberos 和 Ranger 做認證和權(quán)限管理。但 S3 當(dāng)時并不支持。JuiceFS 社區(qū)版本同樣也不支持。

數(shù)據(jù)可靠性：HDFS 使用三副本來確保數(shù)據(jù)可靠性。當(dāng)時我們測試時 JuiceFS 元數(shù)據(jù)引擎使用的是 Redis。我們發(fā)現(xiàn)，在高可用模式下，如果發(fā)生主節(jié)點切換，存儲會出現(xiàn)卡頓，這對我們來說是很難接受的。所以我們采用在每臺機器上獨立部署 Redis 元數(shù)據(jù)服務(wù)的方式，細節(jié)將在下文展開。

成本：塊設(shè)備這樣的方案成本很高。我們的目標(biāo)是要使用 S3，如果每個人都只使用 S3，成本當(dāng)然是最低的。如果使用 JuiceFS，后面的架構(gòu)會有一定的額外成本，因此我們后面會解釋為什么它的成本不是最低的。

02. Hadoop 海外多云遷移方案

存儲層存算分離: Hadoop+JuiceFS+S3

JuiceFS 與 Hadoop 的結(jié)合可以降低業(yè)務(wù)的兼容的成本，快速實現(xiàn)已有的業(yè)務(wù)出海。許多用戶在使用 JuiceFS 方案時，是通過 SDK 加上 Hadoop 開源版本來實現(xiàn)的。但這樣使用會有一個權(quán)限認證的問題，JuiceFS 社區(qū)版不支持 Ranger 和 Kerberos 的權(quán)限認證。因此，我們還是使用了 Hadoop 的整個框架。維護成本看上去很高，但在國內(nèi)我們有一套自建的組件在維護著，所以對我們來說差不多沒有成本。如下圖所示，我們使用 Fuse 將 JuiceFS 掛載到 Hadoop，再使用 S3 存儲。

先簡單對比我們與基于 EBS 自建單集群的性能。

• 在 4 萬 QPS 的情況下可以達到 p90 10ms；
• 單節(jié)點能夠承受 30000 IOPS。

一開始我們上云時采用了 HDD 模式，具體來說就是 st1 存儲類型。但很快我們發(fā)現(xiàn)，當(dāng)節(jié)點數(shù)量較少時，實際的 IOPS 遠遠不能滿足我們的要求。因此，我們決定將所有的st1存儲類型全部升級到 gp3。

每塊 gp3 默認提供大約 3000 個 IOPS。為了提升性能，我們掛載了 10 塊 gp3 存儲卷，總共實現(xiàn)了 30000 IOPS 的性能。這個改進讓我們的系統(tǒng)可以更好地滿足 IOPS 的需求，不再受限于節(jié)點數(shù)量較少時的性能瓶頸。gp3 的高性能和靈活性使得它成為我們解決 IOPS 問題的理想選擇。

每個節(jié)點目前的默認帶寬是 10Gb。但是不同的機型帶寬也有所不同。我們?nèi)×艘粋€基準(zhǔn)，即 30000 個 IOPS 單節(jié)點，帶寬為 10Gb。我們的目標(biāo)是要能夠整合我們的 S3 存儲，即在高性能的同時也要考慮存儲的成本，數(shù)據(jù)最終會落在 S3 上面。

而最重要的是要兼容 Hadoop 訪問，也就是所有的業(yè)務(wù)其實都不需要做任何修改，可以直接上云解決兼容性問題。對于一些歷史業(yè)務(wù)來說，它可能有一定的業(yè)務(wù)價值，但是我們要評估業(yè)務(wù)的改造成本和平臺兼容的成本，在我們場景業(yè)務(wù)中重構(gòu)所有歷史業(yè)務(wù)的人力成本當(dāng)前是大于平臺兼容成本，而且不可能短時間完成。

我們對 JuiceFS 的掛載方式與官網(wǎng)可能有所不同。我們在每臺機器上都部署了本地的 JuiceFS 和 Redis（如下圖所示）。這樣做是為了最大化 JuiceFS 的性能，并將本地元數(shù)據(jù)的損耗降到最低。我們曾嘗試過使用 Redis 集群和 TiDB 集群，但發(fā)現(xiàn)元數(shù)據(jù)性能差了好幾個數(shù)量級。因此，我們一開始就決定采用本地的部署方式。

另一個好處是我們的系統(tǒng)與 DNO（Data Node Object）綁定。我們可以控制每個 DNO 的文件數(shù)量，即單個節(jié)點的文件數(shù)量，使其穩(wěn)定在一個合理的水平范圍內(nèi)。例如，我們一個 DNO 大約有 3 百萬到 8 百萬個元數(shù)據(jù)文件的上限，所以元數(shù)據(jù)單節(jié)點大約為 20GB。這樣，我們不需要過于關(guān)注其膨脹情況，將一個大規(guī)模的分布式 Redis 需求轉(zhuǎn)化為單節(jié)點元數(shù)據(jù)可控的 Redis 需求。但穩(wěn)定性也是一個問題，如果單節(jié)點出現(xiàn)穩(wěn)定性問題，我們就會面臨丟失的風(fēng)險。

為了解決單節(jié)點的宕機問題，我們與 DNO 進行了綁定，并利用了 HDFS 多副本機制，在我們集群有兩種副本模式，一種是三副本，一種是 EC（Erasure Coding）副本。不同模式下，都通過副本的機制實現(xiàn)數(shù)據(jù)的高可靠性：在多副本的部署方案下，即使某個節(jié)點完全掛掉，我們也可以直接剔除它，而不影響整體運行和數(shù)據(jù)的可靠性。

在實踐中，將單節(jié)點部署在本地，同時使用 JuiceFS 和單節(jié)點 Redis，是能夠獲得最佳性能的方式。因為我們需要與 HDFS 和 EBS 方案的性能進行對標(biāo)。

我們通過基于 HDFS 的分布式水平擴展和 JuiceFS 的緩存與讀寫策略優(yōu)化，實現(xiàn)了高性能的 HDFS。優(yōu)化部分如下：

1. 使用 JuiceFS 替換 gp3 的目錄，以一塊小的 gp3 存儲作為 JuiceFS 的緩存目錄，實現(xiàn)了 IOPS 對齊 gp3 的水平；
2. 通過優(yōu)化 JuiceFS 緩存機制，定制的異步刪除，異步合并上傳，S3 目錄 TPS 預(yù)置等優(yōu)化減少落到 S3 的情況，低成本存儲的 S3 替換 gp3；
3. 基于 HDFS 集群的分布式實現(xiàn)節(jié)點水平擴展；
4. 利用 Hadoop 異構(gòu)存儲的特性，根據(jù)業(yè)務(wù)特性拆解 IO，以優(yōu)化性能和成本。我們將 HDFS 存儲拆分為兩個部分，“DISK” 和 “SSD”?！癝SD” 存儲類型對應(yīng)的是使用 JuiceFS 的 EBS 緩存與 S3 整合的混合存儲。“DISK” 存儲類型被配置為寫入 DN 的 EBS 存儲的目錄。在那些會頻繁覆寫的目錄，例如 Stage 目錄，我們會將這些目錄設(shè)置成使用 DISK 進行存儲。EBS 存儲更適合頻繁擦寫，對比 S3 的少了額外 OP 費用，而且這些目錄對存儲的總量要求是可控的，因此這個場景我們保留了一小部分 EBS 存儲。

計算層：Spot 節(jié)點與按需節(jié)點混合部署方案

首先，當(dāng)我們將國內(nèi)自建的 YARN 集群遷移到云上時，它無法適應(yīng)云上的資源特性以實現(xiàn)成本優(yōu)化。因此，我們基于 YARN 的智能動態(tài)伸縮方案與標(biāo)簽調(diào)度相結(jié)合，同時采用 Spot 節(jié)點與按需節(jié)點混合部署方案，來優(yōu)化計算資源的使用。

1. 調(diào)整調(diào)度器策略為容量調(diào)度 (CapacityScheduler)；
2. 劃分按需節(jié)點分區(qū)和 Spot 節(jié)點分區(qū)；
3. 調(diào)整有狀態(tài)的節(jié)點到按需節(jié)點的分區(qū) ，讓不同狀態(tài)的任務(wù)跑在不同的區(qū)域；
4. 使用按需節(jié)點兜底；
5. 回收通知與 GracefulStop，當(dāng)搶占節(jié)點在回收之前會提前收到回收的通知，調(diào)用與 6. GracefulStop 停止業(yè)務(wù)，避免與用戶作業(yè)直接失敗；

Spark+RSS，減少當(dāng)節(jié)點回收的時候，數(shù)據(jù)本來在動態(tài)節(jié)點上面從而去導(dǎo)致要重算作業(yè)的概率。

1. 基于我們的業(yè)務(wù)需求去做了一些動態(tài)智能伸縮的方案。和原生方案對比，我們更關(guān)注的方向是：基于業(yè)務(wù)的狀態(tài)去做動態(tài)伸縮，因為云廠商不可能知道業(yè)務(wù)的熱點時間。

2. 基于內(nèi)部運維工具 Smarttool 的周期性預(yù)測，實現(xiàn)智能伸縮。我們?nèi)∏叭艿囊粋€歷史數(shù)據(jù)，去做一次簡單的擬合，然后通過 Smarttool 預(yù)置的算法得到擬合殘差序列 resid，以及預(yù)測值 ymean。通過這個工具預(yù)測某一天某個時間點它的資源使用應(yīng)該是什么樣子，然后去實現(xiàn)動態(tài)伸縮容。

3. 基于時間規(guī)則的定時伸縮，例如針對特定時間做預(yù)伸縮：每月 1 號的月報表生成時間、大促等特定的時間做提前的容量預(yù)置。

4. 基于使用率的動態(tài)伸縮，使用容量在一定時間內(nèi)大于閾值上限，或小于閾值的下限，會觸發(fā)自動擴容和縮容，實現(xiàn)非預(yù)期的用量需求兜底。盡量保障我們的業(yè)務(wù)在云上面是能夠得到一個穩(wěn)定的，但是成本相對比較低的，計算資源的方案。

生命周期管理：數(shù)據(jù)分層，實現(xiàn)存儲成本優(yōu)化

我們實際上是基于副本機制將 JuiceFS 和 S3 整合的數(shù)據(jù)可靠性。不論是三副本還是 1.5 副本的 EC，都會有額外的存儲支出成本，但是我們考慮到一些數(shù)據(jù)熱度的情況，一旦數(shù)據(jù)過了一定的生命周期，其對 IO 的需求可能不再那么高。因此，我們引入了一層 Alluxio+S3 的單副本層，來處理這些數(shù)據(jù)。但是需要注意，如果不改變目錄架構(gòu)，這一層的性能其實比使用 JuiceFS 要差很多。盡管如此，在冷數(shù)據(jù)的場景下我們?nèi)匀豢梢越邮苓@樣的性能。

因此，我們自主開發(fā)了一個數(shù)據(jù)治理和組織分層的服務(wù)，通過對數(shù)據(jù)進行異步處理，實現(xiàn)了對不同生命周期數(shù)據(jù)的管理和成本優(yōu)化。我們稱這個服務(wù)為數(shù)據(jù)生命周期管理工具 BTS。

BTS 的設(shè)計基于我們的文件數(shù)據(jù)庫、元數(shù)據(jù)以及審計日志數(shù)據(jù)，通過對表格及其熱度的管理，來實現(xiàn)數(shù)據(jù)生命周期管理。用戶可以使用上層的 DAYU Rulemanager 自定義規(guī)則以及使用數(shù)據(jù)的熱度來生成規(guī)則。這些規(guī)則指定哪些數(shù)據(jù)被視為冷數(shù)據(jù)，哪些數(shù)據(jù)被視為熱數(shù)據(jù)。

根據(jù)這些規(guī)則，我們會對數(shù)據(jù)執(zhí)行壓縮、合并、轉(zhuǎn)換、歸檔、或刪除等不同的生命周期管理操作，并將它們分發(fā)到調(diào)度器去執(zhí)行。數(shù)據(jù)生命周期管理工具 BTS 提供了以下能力:

• 數(shù)據(jù)重組織，將小文件合并為大文件，優(yōu)化 EC 存儲的效率和 namenode 壓力；
• 表存儲和壓縮方式的轉(zhuǎn)換：異步將表從 Text 存儲格式轉(zhuǎn)換為 ORC 或 Parquet 存儲格式，并將壓縮方式從 None 或 Snappy 轉(zhuǎn)換為 ZSTD，可以提高存儲和性能效率。BTS 支持按分區(qū)進行異步表轉(zhuǎn)換；
• 異構(gòu)數(shù)據(jù)遷移，將數(shù)據(jù)異步在不同架構(gòu)的存儲之間遷移，為數(shù)據(jù)分層提供組織能力。

存儲分層架構(gòu)我們簡單地分為三層：

• 性能最好的是 HDFS on JuiceFS（熱)，3 副本；
• 其次是 HDFS on JuiceFS EC 的模式（溫?zé)幔?.5 副本；
• 再次是 Alluxio on S3（低頻冷數(shù)據(jù)）1 副本；
• 在所有數(shù)據(jù)消亡之前，它們都會被歸檔到 Alluxio on S3 并變?yōu)閱胃北尽?/li>

目前，數(shù)據(jù)生命周期治理效果如下：

• 60%冷, 30%溫?zé)幔?10%熱；
• 平均的副本數(shù) (70% * 1 + 20% * 1.5 + 10% * 3) = 1.3 在歸檔這樣對性能要求不高的場景，我們能夠?qū)崿F(xiàn)約 70%的數(shù)據(jù)。使用 EC 副本時，大約 20% 的數(shù)據(jù)，而使用三副本時約為 10%的。我們整體上控制了副本的數(shù)量，平均副本數(shù)維持在約 1.3 個。

03. 出海新架構(gòu)的上線效果：性能與成本

在測試中，JuiceFS 在大文件的讀寫方面能夠達到相當(dāng)高的帶寬。特別是在多線程模型下，大文件讀取的帶寬接近客戶端的網(wǎng)卡帶寬上限。

在小文件場景下，隨機寫入的 IOPS 性能較好（得益于 gp3 磁盤作為緩存），而隨機讀的 IOPS 性能相比之下較低，大約差了 5 倍。

EBS 方案與 JuiceFS+S3 方案在業(yè)務(wù)實測的對比，測試用例為我們生產(chǎn)環(huán)境下的業(yè)務(wù) SQL， 可以看出 JuiceFS + S3 基本與 EBS 差別不大，部分 SQL 甚至更優(yōu)。所以 JuiceFS + S3 能夠替換掉全量 EBS 。

使用基于JuiceFS 的 S3+EBS 混合分層的存算分離方案替換原來的 EBS 方案，通過數(shù)據(jù)治理和數(shù)據(jù)分層，從原來的 Hadoop 三副本的機制下降到平均 1.3 個副本，節(jié)省 55% 的多副本成本，整體存儲成本下降 72.5%。

通過智能動態(tài)伸縮實現(xiàn)了 85% 集群使用率和使用 95% 的 Spot 實例替換了按需節(jié)點，總體計算成本對比優(yōu)化前優(yōu)化超過 80%

04. 總結(jié)與展望：邁向云原生

相比原生的 JuiceFS 方案，Hadoop+JuiceFS 使用額外的副本實現(xiàn)了儲性能優(yōu)化和實現(xiàn)兼容性與高可用的支持。DN 只寫一個副本的方案， 依賴 JuiceFS 在可靠性上的迭代優(yōu)化。

雖然已經(jīng)在不同云上實現(xiàn)一套多云兼容、對比 EMR 更好的方案，但是對于混合多云和云原生的方案還需要更多的迭代。

對于未來大數(shù)據(jù)云原生場景的展望，目前我們采取的解決方案并非終極版本，而是一個過渡性方案，旨在解決兼容性和成本問題。未來，我們計劃采取以下措施：

1. 推進業(yè)務(wù)向更云原生的方案遷移，實現(xiàn) Hadoop 環(huán)境的解耦，并將數(shù)據(jù)湖和云上計算緊密結(jié)合在一體。
2. 推動更高層次的混合多云計算和混合存儲方案，實現(xiàn)真正的整合，而不僅僅是現(xiàn)在的兼容性。這將為上層業(yè)務(wù)部門帶來更多的價值和靈活性。

希望這篇內(nèi)容能夠?qū)δ阌幸恍椭?，如果有其他疑問歡迎加入 JuiceFS 社區(qū)與大家共同交流。文章來源地址http://www.zghlxwxcb.cn/news/detail-642369.html

到了這里，關(guān)于網(wǎng)易互娛出海之旅：大數(shù)據(jù)平臺上云架構(gòu)設(shè)計與實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！