今天的案例分享來自社區用戶一面數據，這是一家通過解讀電商平臺和社交媒體渠道的海量數據，為全球快消巨頭（如寶潔、聯合利華和瑪氏等）提供實時、全面的數據洞察的公司。

在去年的案例中，一面分享了架構設計和實踐。本次案例，進一步補充了在后續數據遷移過程中一面遇到的具體挑戰以及分級存儲的實踐。如果你正在考慮將 Hadoop 遷移到云上，這篇文章從架構設計到實際操作都涵蓋了豐富的內容，是一篇不容錯過的案例。

一面數據原有的技術架構是在線下機房中使用 CDH 構建的大數據集群。自公司成立以來，每年都保持著高速增長，業務的增長帶來了數據量的劇增。

在過去幾年中，我們按照每 1 到 2 年的規劃擴容硬件，但往往在半年之后就不得不再次擴容。而每次擴容都需要花費大量精力。

為了解決包括擴容周期長、計算存儲資源不匹配以及高昂的運維成本等這些問題，我們決定對數據架構進行改造，并將數據遷移到云端，采用存算分離的結構。 在這個案例中，我們將為大家介紹 Hadoop 上云的架構設計、選型的思考、組件評估以及數據遷移的整個過程。

目前，基于 JuiceFS 我們實現了計算和存儲分離的架構，總存儲量增加了 2 倍；性能方面的變化無明顯感知，運維成本大幅降低。在案例的末尾還附上了針對阿里云 EMR 以及 JuiceFS 的一手運維經驗，希望這個案例能為其他面臨類似問題的同行提供有價值的參考。

舊架構及挑戰

為了滿足業務需求，一面數據抓取了國內外數百個大型網站的數據，目前數量已經超過 500 個，并積累了大量的原始數據、中間數據和結果數據。隨著我們不斷增加抓取的網站數量和服務的客戶群，數據量也在快速增長。因此，我們著手開始進行擴容以滿足需求的增長。

原有的架構是在一個線下機房使用 CDH 構建了一個大數據集群。如下圖所示，我們主要使用了 Hive、Spark 和 HDFS 等組件。在 CDH 的上游有多種數據生產系統，在這里只列出了 Kafka，因為與 JuiceFS 相關；除了 Kafka 之外，還有其他一些存儲方式，包括 TiDB、HBase、MySQL 等等。

一面數據原有數據架構

數據流向方面，我們有一個上游的業務系統和數據采集系統，數據會被采集下來后寫入 Kafka。然后我們使用一個 Kafka Connect 集群，將數據同步到 HDFS。

在這個架構上方，我們使用了一個自研的數據開發平臺，稱為 OneWork，用于開發和管理各種任務。這些任務會通過 Airflow 下發到任務隊列進行調度。

挑戰

業務 / 數據會增長比較快，業務擴容周期長。公司在 2016 年線下機房部署了 CDH 集群，到 2021 年已存儲和處理 PB 級的數據。公司自創立以來一直保持每年翻一番的高增長，而比業務量增長更快的是 Hadoop 集群的數據量。

在這幾年間，按 1 到 2 年規劃的硬件，往往因數據增長超出預期而在半年后不得不再次擴容。每次擴容周期可達到一個月，除了花費大量精力跟進行政和技術流程，業務端也不得不安排較多人日控制數據量。如果選擇購買硬盤和服務器來進行擴容，實施周期會相對較長。

存儲計算耦合，容量規劃難，容易錯配。 傳統的 Hadoop 架構中，存儲和計算是緊密耦合的，難以根據存儲或計算的需求獨立進行擴容和規劃。舉個例子，假設我們需要擴容存儲，于是首先需要購買一批新的硬盤，同時連帶著需要購買計算資源。在最初時，計算資源可能會變得過剩，因為可能實際不需要那么多的計算資源，從而一定程度上導致了超前投資。

CDH 版本比較老，不敢升級。 我們因為集群也建的比較早了，為了穩定，也就不敢升級了。

運維成本較高（全公司僅 1 個全職運維）公司當時有 200 多個人，只有一個運維，這意味著運維工作的工作量很大。因此，我們希望能夠采用更穩定、更簡單的架構來提供支持。

機房存在單點風險。考慮到長遠的因素，所有的數據都存儲在同一個機房中，這存在一定的風險。例如，如果光纜被挖斷，這種情況經常發生，那么我們僅有一個機房仍然會面臨單點故障的風險。

新架構與選型 選型考量

考慮到這些因素和挑戰，我們決定進行一些新的改變。以下是我們考慮架構升級的一些主要維度：

上云，彈性伸縮，靈活運維。利用云上的服務可以簡化運維工作。例如，在存儲方面，盡管 HDFS 本身是一個穩定且成熟的解決方案，但我們更愿意將時間投入到業務層面上，而不是底層的運維工作。因此，使用云服務可能更加簡單。此外，通過利用云上的資源，我們可以實現彈性伸縮，無需等待長時間的硬件部署和系統配置周期。

存儲計算分離。我們希望將存儲和計算解耦，以實現更好的靈活性和性能。

盡量使用開源組件，避免云廠商綁定。盡管我們選擇上云，但我們不希望過于依賴云服務本身。我們在為客戶提供服務時會使用云原生的解決方案，例如使用 AWS Redshift 等，但我們在自身業務方面更傾向于使用開源組件。

盡可能與現有方案兼容，控制改動成本和風險。我們希望新架構與現有解決方案兼容，以避免引入額外的開發成本，并對我們的業務產生影響。

新架構：阿里云 EMR + OSS + JuiceFS

最終選擇的方案是使用“阿里云 EMR + JuiceFS + 阿里云 OSS” 來搭建存算分離的大數據平臺，將云下數據中心的業務逐步遷移上云。

這個架構使用對象存儲來替代 HDFS，并選擇了 JuiceFS 作為協議層，因為 JuiceFS 兼容 POSIX 和 HDFS 協議。在頂部，我們使用了云上半托管的 Hadoop 解決方案 EMR。它包含了很多 Hadoop 相關的組件，例如 Hive、Impala、Spark、Presto/Trino 等等。

一面數據架構圖

阿里云 vs 其他公有云

首先是決定使用哪家云廠商。由于業務需求，AWS、Azure 和阿里云都有在用，綜合考慮后認為阿里云最適合，有這些因素：

物理距離：阿里云在我們線下機房同城有可用區，網絡專線的延遲小，成本低

開源組件齊全：阿里云 EMR 上包含的開源組件很多很全，除了我們重度使用的 Hive、Impala、Spark、Hue，也能方便集成 Presto、Hudi、Iceberg 等。我們在調研時發現只有阿里云 EMR 自帶了 Impala，AWS 和 Azure 要么版本低，要么要自己安裝部署。

JuiceFS vs JindoFS

阿里云的 EMR 本身也有使用 JindoFS 的存算分離方案，但基于以下考慮，我們最終選擇了 JuiceFS：

JuiceFS 使用 Redis 和對象存儲為底層存儲，客戶端完全是無狀態的，可以在不同環境訪問同一個文件系統，提高了方案的靈活性。而 JindoFS 元數據存儲在 EMR 集群的本地硬盤，不便于維護、升級和遷移。

JuiceFS 的存儲方案豐富，而且支持不同方案的在線遷移，提高了方案的可移植性。JindoFS 塊數據只支持 OSS.

JuiceFS 以開源社區為基礎，支持所有公有云環境，方便后期擴展到多云架構。

關于 JuiceFS

直接截取官方文檔[1] 的介紹：

JuiceFS 是一款面向云原生設計的高性能共享文件系統，在 Apache 2.0 開源協議下發布。提供完備的 POSIX[2] 兼容性，可將幾乎所有對象存儲接入本地作為海量本地磁盤使用，亦可同時在跨平臺、跨地區的不同主機上掛載讀寫。

JuiceFS 采用「數據」與「元數據」分離存儲的架構，從而實現文件系統的分布式設計。使用 JuiceFS 存儲數據，數據本身會被持久化在對象存儲[3]（例如，Amazon S3），相對應的元數據可以按需持久化在 Redis、MySQL、TiKV、SQLite 等多種數據庫[4] 中。

除了 POSIX 之外，JuiceFS 完整兼容 HDFS SDK，與對象存儲結合使用可以完美替換 HDFS，實現存儲和計算分離。

JuiceFS 架構圖

Hadoop 遷移云上 PoC 設計

PoC 的目的是快速驗證方案的可行性，有幾個具體目標：

驗證 EMR + JuiceFS + OSS 整體方案的可行性

檢查 Hive、Impala、Spark、Ranger 等組件版本的兼容性

評估對比性能表現，用了 TPC-DS 的測試用例和部分內部真實業務場景，沒有非常精確的對比，但能滿足業務需求

評估生產環境所需的節點實例類型和數量（算成本）

探索數據同步方案

探索驗證集群與自研 ETL 平臺、Kafka Connect 等的集成方案

期間做了大量測試、文檔調研、內外部（阿里云 + JuiceFS 團隊）討論、源碼理解、工具適配等工作，最終決定繼續推進。

實施

我們在 2021 年 10 月開始探索 Hadoop 的上云方案；11 月做了大量調研和討論，基本確定方案內容；12 月和 2022 年 1 月春節前做了 PoC 測試，在春節后 3 月份開始搭建正式環境并安排遷移。為了避免導致業務中斷，整個遷移過程以相對較慢的節奏分階段執行， 遷移完后，云上的 EMR 集群數據量預計會超過單副本 1 PB。

整體架構設計

做完技術選型之后，架構設計也能很快確定下來。考慮到除了 部分業務仍然會保留在數據中心的 Hadoop 集群，所以整體實際上是個混合云的架構。

整體架構大致如上圖所示：左側是的線下機房，使用了傳統的 CDH 架構和一些 Kafka 集群。右側是部署在阿里云上的 EMR 集群。這兩部分通過一條高速專線進行連接。頂部是 Airflow 和 OneWork，由于都支持支持分布式部署，因此可以輕松進行水平擴展。

數據遷移的挑戰 挑戰 1：Hadoop 2 升到 Hadoop 3

我們 CDH 版本比較老，也不敢升級，但我們既然做了遷移，肯定還是希望新集群能夠升級到新版本。在遷移過程中，需要注意 HDFS 2 和 3 之間的差異，接口協議和文件格式有可能會發生變化。JuiceFS 完美兼容 HDFS 2 & 3，很好地應對了這個挑戰。

挑戰 2：Spark 2 升級到 Spark 3

Spark 的一個升級對我們影響是比較大的，因為有不少不兼容的更新。這就意味著原來在 Spark 2 上面寫的代碼需要完成修改才能適配到新的版本里面去。

挑戰 3：Hive on Spark 不支持 Spark 3

在機房環境中，默認使用的是 CDH 自帶的 Hive on Spark，但當時 CDH 中的 Spark 版本只有 1.6。我們在云上使用的是 Spark 3，而 Hive on Spark 并不支持 Spark 3，這導致我們無法繼續使用 Hive on Spark 引擎。

經過調研和測試，我們將 Hive on Spark 改為了 Hive on Tez。這個改動相對來說還比較容易，因為 Hive 本身對于不同的計算引擎提供了抽象和適配，所以對于我們的上層代碼改動較小。Hive on Tez 在性能上可能略慢于 Spark。此外，我們也關注國內網易開源的一個新計算引擎 Kyuubi，它兼容 Hive，并提供了一些新特性。

挑戰 4：Hive 1 升級到 Hive 3，元數據結構有變化

對于 Hive 升級來說，最主要的影響之一是元數據結構的變化，因此在遷移過程中，我們需要進行數據結構的轉換。因為無法直接使用 Hive 來處理這種遷移，所以我們需要開發相應的程序來進行數據結構的轉換。

挑戰 5：權限管理由 Sentry 替換為 Ranger

這是一個比較小的問題，就是我們之前使用 Sentry 做權限管理，這個社區不怎么活躍了，EMR 也沒有集成，所以就替換為 Ranger。

除了技術挑戰外，更大的挑戰來自與業務端。

業務挑戰 1：涉及的業務多，不能影響交付

我們擁有多個業務，涉及不同的網站、客戶和項目。由于業務交付不能中斷，遷移過程必須進行分業務處理，采用漸進式遷移的方式。遷移過程中，數據的變動會對公司的多個環節產生影響，例如 ETL 數據倉庫、數據分析師、測試和產品開發等。因此，我們需要進行良好的溝通和協調，制定項目管理計劃和排期。

業務挑戰 2：數據表、元數據、文件、代碼多

除了數據，我們在上層還有許多業務代碼，包括數據倉庫的代碼、ETL 的代碼以及一些應用程序的代碼，如 BI 應用需要查詢這些數據。

數據遷移：存量文件 & 增量文件

要遷移的數據包括兩部分：Hive Metastore 元數據以及 HDFS 上的文件。由于不能中斷業務，采用存量同步 + 增量同步（雙寫）的方式進行遷移；數據同步完后需要進行一致性校驗。

存量同步

對于存量文件同步，可以使用 JuiceFS 提供的功能完整的數據同步工具 sync 子命令[5] 來實現高效遷移。JuiceFS sync 命令支持單節點和多機并發同步，實際使用時發現單節點開多線程即可打滿專線帶寬，CPU 和內存占用低，性能表現非常不錯。需要注意的是，同步過程中 sync 命令會在本地文件系統寫緩存，因此最好掛載到 SSD 盤來提升性能。

Hive Metastore 的數據同步則相對麻煩些：

兩個 Hive 版本不一致，Metastore 的表結構有差異，因此無法直接使用 MySQL 的導出導入功能

遷移后需要修改庫、表、分區存儲路徑（即 dbs 表的 DB_LOCATION_URI和 sds 表的 LOCATION）

因此我們開發了一套腳本工具，支持表和分區粒度的數據同步，使用起來很方便。

增量同步

增量數據主要來自兩個場景：Kafka Connect HDFS Sink 和 ETL 程序，我們采用了雙寫機制。

Kafka Connect 的 Sink 任務都復制一份即可，配置方式上文有介紹。ETL 任務統一在 OneWork 上開發，底層使用 Airflow 進行調度。通常只需要把相關的 DAG 復制一份，修改集群地址即可。實際遷移過程中，這一步遇到的問題最多，花了大量時間來解決。主要原因是 Spark、Impala、Hive 組件版本的差異導致任務出錯或數據不一致，需要修改業務代碼。這些問題在 PoC 和早期的遷移中沒有覆蓋到，算是個教訓。

數據校驗

為了能讓業務放心的使用新的架構，數據校驗必不可少。數據同步完后需要進行一致性校驗，分三層：

文件一致。在存量同步階段做校驗，通常的方式是用 checksum. 最初的 JuiceFS sync 命令不支持 checksum 機制，我們建議和討論后，JuiceFS 團隊很快就加上了該功能（issue，pull request[6]）。除了 checksum，也可考慮使用文件屬性對比的方式：確保兩個文件系統里所有文件的數量、修改時間、屬性一致。比 checksum 的可靠性稍弱，但更輕量快捷。

元數據一致。有兩種思路：對比 Metastore 數據庫的數據，或對比 Hive 的 DDL 命令的結果。

計算結果一致。即使用 Hive/Impala/Spark 跑一些查詢，對比兩邊的結果是否一致。一些可以參考的查詢：表 / 分區的行數、基于某個字段的排序結果、數值字段的最大 / 最小 / 平均值、業務中經常使用的統計聚合等。

數據校驗的功能也封裝到了腳本里，方便快速發現數據問題。

分級存儲

遷移完業務穩定運行后，我們開始考慮分級存儲。分級存儲在各種數據庫或存儲系統中都是一個常見問題，數據存在冷熱區別，而存儲介質的價格也存在差異，因此我們希望將冷數據存儲在更便宜的存儲介質上以控制成本。

在之前的 HDFS 中，我們已經實施了分級存儲策略，購買了兩種類型的硬盤，將熱數據存儲在高速硬盤中，將冷數據存儲在低速硬盤中。

然而，JuiceFS 為了優化性能采取的數據分塊模式，會對分級存儲帶來限制。按照 JuiceFS 的處理，當文件存儲在對象存儲上時，它被邏輯上拆分為許多 chunks、slices 和 blocks，最終以 block 的形式存儲在對象存儲中。

JuiceFS 數據分塊示意圖

因此，如果我們觀察對象存儲中的文件，實際上無法直接找到文件本身，而只能看到被分割成的小塊。即使 OSS 提供了聲明周期管理功能，但我們也無法基于表、分區或文件級別進行生命周期的配置。

后續我們通過以下這種方式來解決。

兩個 bucket：標準（ JuiceFS ） + 低頻（OSS）：創建兩個存儲桶，一個存儲桶用于 JuiceFS，并將所有數據存儲在標準存儲層中。另外，我們額外創建一個低頻的 OSS 存儲桶。

基于業務邏輯，對表 / 分區 / 文件，配置存儲策略表。我們可以根據表、分區或文件來設置存儲策略，并編寫定時任務來掃描并執行這些策略。

用 Juicesync 將低頻文件從 JuiceFS 導出到 OSS 并修改 Hive 元數據。文件從 JuiceFS 轉移到 OSS 之后會從 JuiceFS 刪除，并且在 OSS 上能看到完整的文件內容，我們就可以對其設置生命周期規則。轉移完文件后需要及時修改 Hive 元數據，，將 Hive 表或分區的位置更改為新的 OSS 地址。EMR 的 Hive/Impala/Spark 等組件原生支持 OSS，因此應用層基本無感（需注意訪問低頻文件會帶來額外開銷）。

完成這個操作后，除了實現分級存儲以降低成本外，還有一個額外的好處是我們可以減少 JuiceFS 元數據的數量。因為這些文件不再屬于 JuiceFS，而是由 OSS 直接管理，這意味著 JuiceFS 中的 inode 數量會減少，元數據的管理壓力就會減輕，Redis 請求的數量和容量也會降低。從穩定性的角度來看，這對系統會更有利。

架構升級的收益 & 后續計劃 存算分離的收益

總的存儲量增長了兩倍，計算資源不動，偶爾開啟臨時的任務節點。在我們的場景中，數據量增長非常快，但查詢需求相對穩定。從 2021 年至今，數據量已增長兩倍。計算資源在初始階段至今基本沒有做過太多的改動，除非出于某些業務需求需要更快的計算速度，我們會開啟彈性資源和臨時任務節點來加速。

性能變化

總體無明顯感知，PoC 期間做過簡單的 TPCDS 測試顯示差異不大，ad-hoc 的 Impala 查詢響應變快了

影響因素多：HDFS -> JuiceFS、組件版本升級、Hive 計算引擎變化、集群負載等

在我們的業務場景中，主要是進行大數據的批處理離線計算，總體而言對于性能的延遲并不敏感。

在 PoC 期間，我們進行了一些簡單的測試。然而，這些測試很難準確說明問題，因為測試過程受到了許多影響因素的影響。我們首先更換了存儲系統，從 HDFS 切換到了 JuiceFS，同時進行了組件版本升級，Hive 引擎也發生了變化。此外，集群負載也無法完全一致。在我們的場景中，與之前在物理服務器上部署的 CDH 相比，集群架構的性能差異并不明顯。

易用性 & 穩定性

JuiceFS 本身沒出過問題

EMR 的使用有遇到些小問題，總體上 CDH 更穩定易用

實施復雜度

我們的場景里， 增量雙寫 & 數據校驗過程花的時間最多（回過頭看校驗的投入過大，可以精簡） ；

影響因素多：跟業務場景（離線 / 實時、表 / 任務數量、上層應用）、組件版本、配套工具和儲備。

當評估類似架構或方案的復雜度時，有許多影響因素需要考慮。其中包括業務場景的差異，以及對延遲要求的敏感程度不同。此外，表數據量的規模也會產生影響。在我們的場景中，我們有大量的表和數據庫，文件數量相對較多。此外，上層應用程序的特性、使用業務的數量以及相關程序等也會對復雜度產生影響。另一個重要的影響因素是版本遷移的逐漸差異。如果只進行平移而保持版本不變，那么組件的影響基本上可以消除。

配套工具和儲備是一個重要的影響因素。在進行數倉或 ETL 任務時，有多種實現方式可供選擇，例如手動編寫 Hive SQL 文件、Python 或 Java 程序，或者使用常見的調度工具。但無論采用哪種方式，我們都需要復制和修改這些程序，因為雙寫是必要的。

我們使用自研的開發平臺 OneWork，在任務配置方面非常完善。通過 OneWork 平臺，用戶可以在 Web 界面上配置這些任務，從而實現統一管理。Spark 任務的部署也無需登錄到服務器上操作，OneWork 會自動提交到 Yarn 集群。這個平臺大大簡化了代碼配置和修改的過程。我們編寫了一個腳本將任務配置復制出來，進行一些修改，就可以實現高度的自動化程度，幾乎達到百分之八九十，從而順利運行這些任務。

后續計劃大致有幾個方向：

繼續完成剩余業務的上云遷移；

探索 JuiceFS + OSS 的冷熱分級存儲策略。JuiceFS 的文件在 OSS 上完全被打散，無法基于文件級別做分級。目前的思路是將冷數據從 JuiceFS 遷移到 OSS 上，設置為歸檔存儲，修改 Hive 表或分區的 LOCATION，不影響使用；

目前 JuiceFS 使用 Redis 作為元數據引擎，假如將來數據量增加，使用 Redis 有壓力的話可能考慮切換為 TiKV 或其他引擎；

探索 EMR 的彈性計算實例，爭取能在滿足業務 SLA 的前提下降低使用成本。

附錄 部署和配置 關于 IDC- 阿里云專線：

能提供專線服務的供應商很多，包括 IDC、阿里云、運營商等，選擇的時候主要考慮線路質量、成本、施工周期等因素，最終我們選擇了 IDC 的方案。IDC 跟阿里云有合作，很快就完成了專線的開通。這方面如果遇到問題，可以找 IDC 和阿里云的支持。除專線租用成本，阿里云也會收取下行（從阿里云到 IDC）方向傳輸費用。專線兩端的內網 IP 完全互通，阿里云和 IDC 兩側都需要一些路由配置。

關于 EMR Core/Task 節點類型的選擇：

JuiceFS 可以使用本地硬盤做緩存[7]，能進一步減少 OSS 帶寬需求并提高 EMR 性能。更大的本地存儲空間，可以提供更高的緩存命中率。

阿里云本地 SSD 實例是較高性價比的 SSD 存儲方案（相對于云盤），用作緩存正合適。JuiceFS 社區版未支持分布式緩存，意味著每一個節點都需要一個緩存池，所以應該選用盡量大的節點。

基于以上考慮和配置對比，我們決定選用 ecs.i2.16xlarge，每個節點 64 vCore、512GiB Memory、1.8T*8 SSD。

關于 EMR 版本：

軟件方面，主要包括確定組件版本、開啟集群、修改配置。我們機房使用的是 CDH 5.14，其中 Hadoop 版本是 2.6，阿里云上最接近的版本是 EMR 3.38. 但調研時發現該版本的 Impala 和 Ranger 不兼容（實際上我們機房使用的是 Sentry 做權限管理，但 EMR 上沒有），最終經過評估對比，決定直接使用 EMR 5 的最新版，幾乎所有組件的大版本都做了升級（包含 Hadoop 3、Spark 3 和 Impala 3.4）。此外，使用外部 MySQL 作為 Hive Metastore、Hue、Ranger 的數據庫。

關于 JuiceFS 配置：

基本參考 JuiceFS 官方文檔《在 Hadoop 中通過 Java 客戶端訪問 JuiceFS[8]》即可完成配置。另外我們也配置了這些參數：

緩存相關：其中最重要的是 juicefs.cache-dir 緩存目錄。這個參數支持通配符，對多個硬盤的實例環境很友好，如設置為/mnt/disk*/juicefs-cache（需要手動創建目錄，或在 EMR 節點初始腳本中創建），即用全部本地 SSD 作為緩存。另外也要關注 juicefs.cache-size、juicefs.free-space 兩個參數。

juicefs.push-gateway：設置一個 Prometheus Push Gateway，用于采集 JuiceFS Java 客戶端的指標。

juicefs.users、juicefs.groups：分別設置為 JuiceFS 中的一個文件（如 jfs://emr/etc/users、jfs://emr/etc/groups），解決多個節點 uid 和 gid 可能不統一的問題。

關于 Kafka Connect 使用 JuiceFS：

經過一些測試，確認 JuiceFS 可以完美應用于 Kafka Connect 的 HDFS Sink 插件（我們把配置方式也補充到了官方文檔[9]）。相比使用 HDFS Sink 寫入 HDFS，寫入 JuiceFS 需要增加或修改以下配置項：

將 JuiceFS Java SDK 的 JAR 包發布到 Kafka Connect 每一個節點的 HDFS Sink 插件目錄。Confluent 平臺的插件路徑是：/usr/share/java/confluentinc-kafka-connect-hdfs/lib

編寫包含 JuiceFS 配置的 core-site.xml，發布到 Kafka Connect 每一個節點的任意目錄。包括這些必須配置的項目：

fs.jfs.impl = io.juicefs.JuiceFileSystem

fs.AbstractFileSystem.jfs.impl = io.juicefs.JuiceFS

juicefs.meta = redis://:password@my.redis.com:6379/1

請參見 JuiceFS Java SDK 的配置文檔。

Kafka Connector 任務設置：

hadoop.conf.dir=

store.url=jfs:///<路徑>

在整個實施過程中陸陸續續踩了一些坑，積累了一些經驗，分享給大家做參考。

阿里云 EMR 和組件相關

兼容性

EMR 5 的 Hive 和 Spark 版本不兼容，無法使用 Hive on Spark，可以把默認的引擎改成 Hive on Tez.

Impala 的 stats 數據從舊版同步到新版后，可能因為 IMPALA-10230[10] 導致表無法查詢。解決方案是在同步元數據時，將 num_nulls=-1 的改成 num_nulls=0. 可能需要用到 CatalogObjects.thrift[11] 文件。

原集群有少量 Textfile 格式的文件用了 snappy 壓縮，新版 Impala 無法讀取，報錯 Snappy: RawUncompress failed，可能是 IMPALA-10005[12] 導致的。規避方案是不要對 Textfile 文件使用 snappy 壓縮。

Impala 3.4 相比 2.11 的 CONCAT_WS 函數行為有差異，老版本 CONCAT_WS('_', 'abc', NULL) 會返回 NULL，而新版本返回 'abc'.

Impala 3.4 對 SQL 中的保留關鍵字引用更嚴格，必須加上 “''”. 其實一個好習慣是業務代碼不要使用保留關鍵字。

PoC 或前期測試的覆蓋度盡可能完整，用真實的業務代碼去跑。我們在 PoC 和早期遷移的業務中用到的組件特性比較少，基本都是最常用、保持兼容的功能，因此比較順利。但在第二批遷移過程中就暴露出了很多問題，雖然最終都有解決，但花了很多額外的時間去做診斷和定位，打亂了節奏。

性能

EMR 5 的 Impala 3.4 打了 IMPALA-10695[13] 這個補丁，支持對 oss:// 和 jfs://（本意是支持 JindoFS，但 JuiceFS 也默認使用 jfs 這個 scheme）設置獨立的 IO 線程數。在 EMR 控制臺上增加或修改 Impala 的配置項 num_oss_io_threads.

阿里云 OSS 有賬號級別的帶寬限制，默認 10Gbps，隨著業務規模上升容易成為瓶頸。可以與阿里云溝通調整。

運維

EMR 可以關聯一個 Gateway 集群，通常用來部署業務程序。如果要在 Gateway 上用 client 模式提交 Spark 任務，需要先將 Gateway 機器的 IP 加到 EMR 節點的 hosts 文件。默認可以使用 cluster 模式。

EMR 5 會開啟一個 Spark ThriftServer，在 Hue 上可以直接寫 Spark SQL，用起來很方便。但默認配置有個坑，會寫大量日志（路徑大概是 /mnt/disk1/log/spark/spark-hadoop-org.apache.spark.sql.hive.thriftserver.HiveThriftServer2-1-emr-header-1.cluster-xxxxxx.out），導致硬盤寫滿。解決方案有兩個：配置 log rotate 或把 spark.driver.extraJavaOptions 配置清空（阿里云技術支持的建議）。

JuiceFS 相關

JuiceFS 需要每個節點上具有相同的 UID 和 GID，否則很容易出現權限問題。有兩種實現方式：修改操作系統的用戶[14]（比較適合新機器，沒有歷史包袱），或者在 JuiceFS 上維護一個用戶映射表[15]。我們之前也分享過一篇 JuiceFS + HDFS 權限問題定位[16]，有詳細討論。通常需要維護映射的用戶有 impala, hive, hadoop 等。如果使用 Confluent Platform 搭建 Kafka Connect，也需要配置 cp-kafka-connect 用戶。

使用默認的 JuiceFS IO 配置[17] 時，相同的寫查詢，Hive on Tez 和 Spark 都比 Impala 快很多（但在機房里 Impala 更快）。最終發現將 juicefs.memory-size 從默認的 300 (MiB) 改成 1024 之后 Impala 的寫入性能有成倍的提升。

在做 JuiceFS 的問題診斷和分析時，客戶端日志很有用，需要注意 POSIX 和 Java SDK 的日志是不一樣的，詳見 JuiceFS 故障診斷和分析 | JuiceFS Document Center[18]

注意監控 Redis 的空間用量，Redis 如果滿了，整個 JuiceFS 集群無法寫入。（這點需要特別注意） 使用 JuiceFS sync 把機房數據往云上同步時，選擇在有 SSD 的機器上跑，獲得更好的性能。

審核編輯：劉清