豆瓣成立于 2005 年，是中國最早的社交網站之一。在 2009 到 2019 的十年間，豆瓣數(shù)據平臺經歷了幾輪變遷，形成了 DPark + Mesos + MooseFS 的架構。

由機房全面上云的過程中，原有這套架構并不能很好的利用云的特性，豆瓣需要做一次全面的重新選型，既要考慮未來十年的發(fā)展趨勢，也需要找到與現(xiàn)有組件兼容且平滑過渡的解決方案。一番改造后， 豆瓣數(shù)據平臺目前形成了 Spark + Kubernetes + JuiceFS 的云上數(shù)據湖架構，本文將分享此次選型升級的整體歷程。

01 豆瓣早期數(shù)據平臺

在 2019 年，豆瓣所使用的數(shù)據平臺主要由以下組件構成：

Gentoo Linux，內部使用的 Linux 發(fā)行版；MooseFS ，分布式文件系統(tǒng)；Apache Mesos 負責整個集群的資源管理，以及 Dpark 作為分布式計算框架提供給開發(fā)者使用。

（豆瓣早期數(shù)據平臺架構）

從上圖可以看到在這個數(shù)據平臺中，計算和存儲是一體的，每個計算任務是由 Mesos 進行調度的。計算任務的 I/O 操作都是通過 MooseFS 的 Master 獲取元數(shù)據，并在本地獲取需要計算的數(shù)據。此外，GPU 計算集群也是通過 Mesos 進行管理，不同的是， GPU 會基于顯存進行共享。

平臺組件介紹

Gentoo Linux

Gentoo Linux 是一個較為小眾的 Linux 發(fā)行版，具有幾乎無限制的適應性特性，是一個原發(fā)行版。Gentoo Linux 采用滾動更新的方式，所有軟件包都直接從社區(qū)中獲取二進制包，我們則通過源代碼構建我們所需的軟件包。Gentoo Linux 有一個強大的包管理器，使用它也會帶來很多便利，也同時存在一些問題。比如，滾動更新的速度非?？?，但對于服務器來說，可能存在一定的不穩(wěn)定性。

使用源代碼構建軟件包的好處是當社區(qū)沒有預編譯好我們所需的軟件包時，我們可以非常簡單地構建出自己所需的軟件包，并且當已有的軟件包無法滿足我們的需求時，也可以很容易地進行定制調整。但這也會帶來較高的維護成本。

另外，如果所有軟件包都能按照規(guī)范進行編寫的話，依賴沖突問題幾乎是不存在的，因為在打包過程中就已經可以發(fā)現(xiàn)。但實際情況是并不是所有軟件包都能遵守一個好的依賴描述的約定，因此依賴沖突問題可能仍然存在。

Gentoo Linux 是較為小眾的選擇，盡管社區(qū)質量很高，但是用戶也比較少，一些新項目可能沒有用戶進行足夠的測試，我們在實際使用過程中會遇到各種各樣的問題。這些問題大部分需要我們自己解決，如果等待其他人回復的話，響應會比較慢。

MooseFS

MooseFS 是一個開源的、符合 POSIX 標準的分布式文件系統(tǒng)，它只使用 FUSE 作為 I/O 接口，并擁有分布式文件系統(tǒng)的標準特性，如容錯、高可用、高性能和可擴展性。

對于幾乎所有需要使用標準文件系統(tǒng)的場景，我們都使用 MooseFS 作為替代品，并在其基礎上開發(fā)了一些自己的小工具。例如，我們可以直接使用分布式文件系統(tǒng)來處理 CDN 的回源。在早期版本中，MooseFS 沒有主節(jié)點的備份功能，因此我們開發(fā)了一個 ShadowMaster 作為元數(shù)據的熱備節(jié)點，并編寫了一些分析 MooseFS 元數(shù)據的工具，以解決一些運維問題。作為一個存儲設施，MooseFS 整體比較穩(wěn)定，并且沒有出現(xiàn)重大的問題。

Apache Mesos

Mesos 是一個開源的集群管理器，與YARN 有所不同，它提供公平分配資源的框架，并支持資源隔離，例如 CPU 或內存。Mesos 早在 2010 年就被 Twitter 采用， IBM 在 2013 年開始使用。

Dpark

由于公司全員使用 Python，因此使用了 Python 版的 Spark，即 Dpark，它擴展了RDD API，并提供了 DStream。

公司內部還開發(fā)了一些小工具，例如 drun 和 mrun，可以通過 Dpark 將任意 Bash 腳本或數(shù)據任務提交到 Mesos 集群，并支持 MPI 相關的任務提交。Dgrep 是用于快速查詢日志的小工具，JuiceFS 也提供了類似的工具。雖然 Dpark 本身可以容器化，但公司主要的數(shù)據任務是在物理服務器上運行的。支持容器化可以讓場內任務更好地利用線上業(yè)務的模型代碼。

02 平臺演進的思考

在 2019 年，公司決定將基礎設施轉移到云端并實現(xiàn)計算和存儲分離，以提高平臺的靈活性。由于以前的計算任務在物理機上運行，隨著時間的推移，出現(xiàn)了越來越多的依賴沖突問題，維護難度不斷增加。

同時，公司希望內部平臺能夠與當前的大數(shù)據生態(tài)系統(tǒng)進行交互，而不僅僅是處理文本日志或無結構化、半結構化的數(shù)據。此外，公司還希望提高數(shù)據查詢效率，現(xiàn)有平臺上存儲的數(shù)據都是行存儲，查詢效率很低。最終，公司決定重新設計一個平臺來解決這些問題。

平臺演進時，我們沒有非常強的兼容性需求。只要成本收益合理，我們就可以考慮將整個平臺替換掉。這就像是環(huán)法自行車比賽中，如果車有問題就會考慮換車，而不是只換輪子。在更換平臺時，我們如果發(fā)現(xiàn)現(xiàn)有平臺的任務無法直接替換，可以先保留它們。在切換過程中，我們有以下主要需求：

? Python 是最優(yōu)先考慮的開發(fā)語言。

?必須保留 FUSE 接口，不能直接切換到 HDFS 或者 S3。

?盡可能統(tǒng)一基礎設施，已經選用了部分 Kubernetes，就放棄了 Mesos 或其他備選項。

?新平臺的學習成本應盡可能低，讓數(shù)據組和算法組的同事能夠以最低的成本切換到新的計算平臺上。

03 云上構建數(shù)據平臺

目前的云上數(shù)據平臺幾乎是全部替換了，Gentoo Linux 的開發(fā)環(huán)境變成了 Debian based container 的環(huán)境， MooseFS 是換用了現(xiàn)在的 JuiceFS，資源管理使用了 Kubernetrs，計算任務的開發(fā)框架使用了 Spark，整體進行了徹底替換的，其他的設施是在逐漸縮容的過程，還會共存一段時間。

（豆瓣數(shù)據平臺架構）

JuiceFS 作為統(tǒng)一存儲數(shù)據平臺

為了更好地滿足不同的 I/O 需求和安全性考慮，我們會為不同的使用場景創(chuàng)建不同的 JuiceFS 卷，并進行不同的配置。JuiceFS 相對于之前的 MooseFS，創(chuàng)建文件系統(tǒng)更加簡單，實現(xiàn)了按需創(chuàng)建。除了 SQL 數(shù)據平臺外，我們的使用場景基本上都是由 JuiceFS 提供的服務。

在 JuiceFS 中，數(shù)據有幾種類型：在線讀寫、在線讀取離線寫入、在線寫入離線讀取、離線讀寫。

所有的讀寫類型都在 JuiceFS 上進行，比如日志匯聚到卷中，Spark 可能會讀取并進行 ETL，然后將數(shù)據寫入數(shù)據湖。此外，從 Kafka 數(shù)據源讀取的數(shù)據也會通過 Spark 進行處理并寫入數(shù)據湖。

Spark 的 Check Point 直接存儲在另一個 JuiceFS 卷中，而數(shù)據湖的數(shù)據則直接提供給算法組的同學進行模型訓練，并將訓練結果通過 JuiceFS 寫回。我們的運維團隊則通過各種腳本或工具來管理 JuiceFS 上的文件生命周期，包括是否對其進行歸檔處理等。因此，整個數(shù)據在 JuiceFS 中的流轉過程大致如上圖所示。

新數(shù)據平臺組件介紹

Debian based container

首先，運維團隊選擇了 Debian based container 作為基礎鏡像，我們就直接使用了。我們的計算平臺的鏡像很大，為了解決任務啟動速度的問題，團隊在每個節(jié)點上預拉取了鏡像。

JuiceFS

切換到 JuiceFS 存儲系統(tǒng)時，用戶感受不到變化，JuiceFS 非常穩(wěn)定。JuiceFS 比 MooseFS 更好的一點是，它擁有 HDFS 的 SDK，方便了團隊將來切換到 Spark 等工具。團隊在 Kubernetes 上使用了 JuiceFS CSI，可以直接使用 JuiceFS 作為 Persist Volume，用起來十分方便。JuiceFS 團隊溝通高效，解決問題迅速。例如，當 stream 的 checkpoint 頻率太高時，JuiceFS 團隊早早通知并迅速解決。

Kubernentes

我們早在 1.10 版本的時候就開始試用 Kubernetes。后來豆瓣對外的服務集群在 1.12 版本開始逐步遷移到 Kubernetes，基本上是在現(xiàn)有機器上完成了原地的替換。計算集群則是在上云后開始搭建的，基于1.14 版本。我們在版本升級方面可能比其他公司更為激進，目前我們的 Kubernetes 版本已經升級到了1.26 版。

我們選擇 Kubernetes 作為計算平臺的原因之一是它有比較統(tǒng)一的組件。此外，通過 scheduling framework 或者 Volcano，我們可以影響它的調度，這是我們比較希望擁有的一個特性。

我們還可以利用社區(qū)的 Helm 非?？焖俚夭渴鹨恍┬枰臇|西，比如 Airflow、Datahub 和 Milvus 等服務，這些服務都是通過 Helm 部署到我們的離線 Kubernetes 集群中提供的。

Spark

在最開始測試 Spark 時，我們像使用 Dpark 一樣將任務運行在 Mesos 集群上。之后我們選定了 Kubernetes，使用 Google Cloud Platform 上的 spark-on-k8s-operator 將 Spark 任務部署到 Kubernetes 集群中，并部署了兩個 Streaming 任務，但并未進行大規(guī)模的部署。

隨后，我們確定了使用 Kubernetes 和 Airflow，計劃自己實現(xiàn)一個 Airflow Operator，在 Kubernetes 中直接提交 Spark 任務，并使用 Spark 的 Cluster Mode 將任務提交到 Kubernetes 集群中。

對于開發(fā)環(huán)境，我們使用 JupyterLab 進行開發(fā)。廠內有一個 Python 庫對 Spark Session 進行了一些小的預定義配置，以確保 Spark 任務能夠直接提交到 Kubernetes 集群上。

目前，我們使用 Kubernetes Deployment 直接部署 Streaming 任務，這是一個很簡單的狀態(tài)，未來可能會有一些改進的地方。另外，我們正在準備試用 Kyuubi & Spark Connect 項目，希望能夠為線上任務提供更好的讀寫離線數(shù)據的體驗。

我們的版本升級非常激進，但確實從社區(qū)中獲益匪淺。我們解決了日常計算任務中許多常見的優(yōu)化場景。我們激進升級的原因是希望能夠盡可能多地利用社區(qū)的資源，提供新特性給開發(fā)者。但我們也遇到了問題，例如 Spark 3.2 的 parquet zstd 壓縮存在內存泄漏。為了規(guī)避這個問題，我們提前引入了未發(fā)布的補丁。

現(xiàn)在，我們使用兩種方式來讀寫 JuiceFS 數(shù)據：FUSE 和 HDFS。FUSE 主要用于 ETL 任務，例如讀寫日志和 CSV 文件。我們也會將 Hive 表轉存為 CSV 文件下載供未切換到 Spark 的任務進行計算。其他的數(shù)據，則直接通過預先配置好的 HDFS（如 Hive Table 和 Iceberg Table）進行讀寫，這大大簡化了我們的工作。

在數(shù)據湖的選擇上，我們一開始考慮了 Delta Lake，但由于它不支持 Merge on Read，在目前的使用場景存在寫放大，我們放棄了它。取而代之，我們選擇了 Iceberg，并將其用于 MySQL CDC 處理。我們將數(shù)據直接存儲在 JuiceFS 上進行讀寫，并且目前沒有遇到任何性能上的問題。未來，如果我們需要擴大規(guī)模使用，可能需要與 JuiceFS 的團隊溝通一下，看看有哪些優(yōu)化措施。

04 收獲與展望

我們切換到新的計算平臺之后，獲得了很多原來沒有的功能。例如，我們現(xiàn)在可以使用基于 SQL 的大量任務，這些任務的性能比以前好得多，各種報表的實時性也更好了。

與 Mesos 的情況不同，Spark 聲明了多少資源就使用多少資源，這與以前的 Dpark 相比有很大的差異，因為以前大家都是公平分享，相互之間會有影響?，F(xiàn)在，每個任務的執(zhí)行時間都比較可預測，任務評估也比較容易預測，整個新平臺對于業(yè)務數(shù)據的讀取也有更好的時效性。

以前的歷史包袱是相當沉重的，現(xiàn)在我們已經趕上了社區(qū)的步伐。去年年末的各種統(tǒng)計和排名都已經遷移到了新的計算平臺上，并且運行非常穩(wěn)定。

我們正在優(yōu)先考慮采取一些成本下降措施，以實現(xiàn)整個計算集群的動態(tài)擴縮容。我們正積極努力實現(xiàn)此目標，并希望提供更加穩(wěn)定的 SQL 接口。為此，我們計劃采用支持 Multi-tenant 的 SQL 服務器，并嘗試引入 Spark 3.4 的最新特性。

長遠來看，我們希望通過 Spark Remote Shuffle Service 進一步實現(xiàn)存算分離，以便更有效地利用資源。也許未來我們會開發(fā)一個“Spark as a Service”，提供給開發(fā)者使用?？傊覀冋谧汾s社區(qū)的步伐，并不斷努力提升我們的技術水平。