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

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

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

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

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

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

舊架構及挑戰(zhàn)

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

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

一面數(shù)據(jù)原有數(shù)據(jù)架構

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

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

挑戰(zhàn)

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

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

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

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

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

機房存在單點風險?？紤]到長遠的因素，所有的數(shù)據(jù)都存儲在同一個機房中，這存在一定的風險。例如，如果光纜被挖斷，這種情況經(jīng)常發(fā)生，那么我們僅有一個機房仍然會面臨單點故障的風險。

新架構與選型 選型考量

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

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

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

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

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

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

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

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

一面數(shù)據(jù)架構圖

阿里云 vs 其他公有云

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

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

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

JuiceFS vs JindoFS

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

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

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

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

關于 JuiceFS

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

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

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

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

JuiceFS 架構圖

Hadoop 遷移云上 PoC 設計

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

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

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

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

評估生產(chǎn)環(huán)境所需的節(jié)點實例類型和數(shù)量（算成本）

探索數(shù)據(jù)同步方案

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

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

實施

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

整體架構設計

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

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

數(shù)據(jù)遷移的挑戰(zhàn) 挑戰(zhàn) 1：Hadoop 2 升到 Hadoop 3

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

挑戰(zhàn) 2：Spark 2 升級到 Spark 3

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

挑戰(zhàn) 3：Hive on Spark 不支持 Spark 3

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

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

挑戰(zhàn) 4：Hive 1 升級到 Hive 3，元數(shù)據(jù)結構有變化

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

挑戰(zhàn) 5：權限管理由 Sentry 替換為 Ranger

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

除了技術挑戰(zhàn)外，更大的挑戰(zhàn)來自與業(yè)務端。

業(yè)務挑戰(zhàn) 1：涉及的業(yè)務多，不能影響交付

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

業(yè)務挑戰(zhàn) 2：數(shù)據(jù)表、元數(shù)據(jù)、文件、代碼多

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

數(shù)據(jù)遷移：存量文件 & 增量文件

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

存量同步

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

Hive Metastore 的數(shù)據(jù)同步則相對麻煩些：

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

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

因此我們開發(fā)了一套腳本工具，支持表和分區(qū)粒度的數(shù)據(jù)同步，使用起來很方便。

增量同步

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

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

數(shù)據(jù)校驗

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

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

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

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

數(shù)據(jù)校驗的功能也封裝到了腳本里，方便快速發(fā)現(xiàn)數(shù)據(jù)問題。

分級存儲

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

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

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

JuiceFS 數(shù)據(jù)分塊示意圖

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

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

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

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

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

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

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

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

性能變化

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

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

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

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

易用性 & 穩(wěn)定性

JuiceFS 本身沒出過問題

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

實施復雜度

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

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

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

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

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

后續(xù)計劃大致有幾個方向：

繼續(xù)完成剩余業(yè)務的上云遷移；

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

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

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

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

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

關于 EMR Core/Task 節(jié)點類型的選擇：

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

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

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

關于 EMR 版本：

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

關于 JuiceFS 配置：

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

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

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

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

關于 Kafka Connect 使用 JuiceFS：

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

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

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

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:///<路徑>

一手運維經(jīng)驗

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

阿里云 EMR 和組件相關

兼容性

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

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

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

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

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

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

性能

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

阿里云 OSS 有賬號級別的帶寬限制，默認 10Gbps，隨著業(yè)務規(guī)模上升容易成為瓶頸?？梢耘c阿里云溝通調(diào)整。

運維

EMR 可以關聯(lián)一個 Gateway 集群，通常用來部署業(yè)務程序。如果要在 Gateway 上用 client 模式提交 Spark 任務，需要先將 Gateway 機器的 IP 加到 EMR 節(jié)點的 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 需要每個節(jié)點上具有相同的 UID 和 GID，否則很容易出現(xiàn)權限問題。有兩種實現(xiàn)方式：修改操作系統(tǒng)的用戶[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 更快）。最終發(fā)現(xiàn)將 juicefs.memory-size 從默認的 300 (MiB) 改成 1024 之后 Impala 的寫入性能有成倍的提升。

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

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

審核編輯：劉清