1. 背景

客戶A是一家運行CDH 5.14.2的金融服務公司。他們擁有運行關鍵工作負載的開發、測試和生產集群，並希望將其集群升級到CDP私有云基礎版。客戶升級有幾個主要原因：

利用現有的硬件資源，避免通過添加新硬件來進行遷移的的昂貴資源、時間和成本。
使用CDP私有云基礎版中提供的新的流傳輸功能，對他們的體系結構進行現代化升級，以實時獲取數據，以便快速將數據提供給用戶。此外，客戶希望使用CDP私有云基礎版7.1.2附帶的新Hive功能。
客戶還希望利用CDP PvC Base中的新功能，例如用於動態策略的Apache Ranger，用於血緣的Apache Atlas，全面的Kafka流服務以及在舊CDH版本中不可用的Hive 3功能。

CDH到CDP的新功能

確定客戶A感興趣的領域

Hive3

Hive-on-Tez提供更好的ETL性能

ACID事務，ANSI 2016 SQL支持主要性能改進

查詢結果緩存

物化視圖

改進的CBO，矢量化覆蓋率

安全

使用Knox的基於網關的SSO

支持Ranger KMS-Key Trustee集成

Ranger 2.0

動態行過濾和列掩碼

基於屬性的訪問控制和SparkSQL細粒度訪問控制

Sentry到Ranger遷移工具

Atlas2.0

血緣和監管鏈，高級數據發現和業務詞彙表

Navigator到Atlas的數據遷移，提高了性能和可伸縮性

流媒體

支持與HDFS，AWS S3和Kafka Streams的Kafka連接

對Kafka集群的集群管理和複製支持

使用Cruise Control在集群之間存儲和訪問架構以及重新平衡集群

客戶的升級窗口較短，這表明需要通過在其現有環境上安裝CDP進行就地升級，而不是所需時間較長的遷移升級路徑：採購和設置新硬件、安裝新的集群的操作開銷、數據遷移。

客戶利用CDP中的Cloudera多功能分析堆棧。數據生命週期模型使用Kafka提取數據，使用基於Spark的批處理流程豐富數據，使用Hive和Impala執行深度數據分析，最後使用Cloudera Data Science Workbench將數據用於數據科學以獲取深刻的見解。

該客戶的工作負載利用Syncsort來批量處理來自100多個後端數據庫源（如Oracle、SQL Server和傳統大型機）的數據。使用CDSW的數據科學和機器學習工作負載。該客戶是Kafka大量數據提取的用戶。Cloudera CDP擁有行業領先的Kafka產品，為客戶提供了採用該平臺的強烈動力。

通過升級到CDP私有云基礎版，客戶現在還可以為CDP旅程的下一階段做好準備，因為他們現在可以安裝CDP私有云體驗，以利用基於Hive LLAP的虛擬數據倉庫的優勢。

2. 客戶環境

客戶具有三種環境：開發、測試和生產。為了最大程度地減少風險和停機時間，按該順序執行升級，並將每次升級的經驗應用於下一個升級的環境。總數據大小超過1 PB。

服務	集群類型	數據大小	CDP版本
Kafka，SRM，SMM	測試和質量檢查		7.1.2
Hive, Ranger, Atlas, Spark. Ranger KMS, KTS, CM和CDSW	生產	1.5 PB（已複製）	7.1.2
Hive, Ranger, Atlas, Spark. Ranger KMS, KTS, CM和CDSW	測試和質量檢查		7.1.2
Kafka	開發	100TB	7.1.2
Kafka	生產		7.1.2
Hive, Ranger, Atlas, Spark. Ranger KMS, KTS, CM和CDSW	開發		7.1.2
Syncsort（合作伙伴產品）

3. 升級團隊

升級由一個包括客戶、Cloudera客戶團隊和專業服務人員在內的工作組推動。Cloudera團隊包括專業服務解決方案架構師和服務交付經理。客戶團隊包括數名Hadoop管理員、一名程序管理員、一名數據庫管理員和一名企業架構師。此外，各個應用程序團隊為測試和部署其工作做出了貢獻。一些客戶可能還需要包括平臺/基礎架構、網絡和信息安全資源。

4. 升級規劃、過程和實施：

客戶使用Cloudera 專業服務來執行深入分析和升級支持。一次重大升級通常會帶來一些風險，Cloudera PS可以通過深入的計劃和測試來緩解這些風險，包括功能更改、不兼容的數據格式、不贊成使用的較舊的組件或更改數據庫架構。生產環境的重大升級可能需要數小時至數天的停機時間，因此，高效且有計劃地進行升級以最小化風險至關重要。

該過程從創建基本需求以及每個升級以及測試步驟和過程的深入計劃開始。

4.1. 階段1：規劃

l 查看組件列表並確定遷移已棄用和已刪除組件（例如Pig，Flume，Yarn Fair Scheduler，Sentry和Navigator）的工作負載所需的任何工作。

l 查看升級文檔主題以獲取受支持的升級路徑。

n 查看升級要求– CDP私有云基礎版支持以下操作系統，數據庫和JDK。

u 操作系統– RHEL/ CentOS /OEL 7.6/7.7/7.8或Ubuntu 18.04

u DB – Oracle 12.2.0.1，Postgres 10，MySQL 5.7或Maria DB 10.2

u JDK – OpenJDK 8/Oracle JDK 8/OpenJDK 11

n 查看升級前的過渡步驟

l 收集有關當前部署的信息。記錄開發/測試/生產集群的數量。記錄操作系統版本，數據庫版本和JDK版本。確定操作系統是否需要升級，請按照文檔進行備份，並將操作系統升級到支持的版本。查看JDK版本，並確定是否需要更改JDK版本，如果需要，請按照此處的文檔進行升級

l 計劃如何以及何時開始升級。掃描所有文檔並閱讀所有升級步驟。

4.2. 階段2：升級前

l 使用此處的備份步驟列表備份現有集群

l 確認是否滿足所有先決條件。確保滿足所有未解決的依賴關係。

l 將Spark 1.x作業轉換為Spark 2.4.5。測試並驗證作業，以確保執行和測試所有必需的代碼更改。

l 將YARN從FairScheduler轉換為CapacityScheduler，併為新的默認計劃程序配置隊列。CDP不推薦使用FairScheduler，並且不支持它。提供了一個新的工具“ fs2cs” CLI工具來進行基本的隊列結構遷移（CS和FS之間的行為不同，fs2cs工具僅轉換部分配置，請參閱doc），然後上載到新的CM。隊列遷移所需的升級後步驟是重新配置隊列的ACL，並使用新的Queue Manager UI調整調度程序隊列。

l 為所有相關服務（例如Ranger，Atlas等）設置和配置新數據庫。

4.3. 階段3：升級

l 使用此處記錄的步驟將Cloudera Manager升級到7.1.2 。

l 使用Cloudera Manager下載、分發和激活Cloudera Runtime 7.1.x數據包。

l 將所有相關服務和組件（例如Kafka，CDSW）遷移或升級到適當的受支持版本。並對所有這些服務和組件進行驗證

l 升級到最新版本的CDP PvC Base 7.1.2。對集群中部署的組件執行過渡前步驟。

注意：fs2cs，nav2atlas和sentry to ranger是從CDH5舊式集群過渡到CDP PvC Base的遷移工具和過程。

· 執行所有與加密有關的步驟

· 通過使用FS2CS轉換實用程序將YARN設置從Fair Scheduler遷移到Capacity Scheduler，將YARN調度程序從FairScheduler過渡到Capacity Scheduler，然後使用YARN Queue Manager UI手動配置調度程序配置，以確保生成的配置適合應用程序調度要求。需要重新配置隊列優先級以獲得最佳性能。

· 通過從sentry導出策略規則並繼續進行升級步驟，以將Sentry策略轉換為Ranger策略，從Sentry過渡到Ranger。轉換將以下sentry實體轉換為Ranger：

o sentry角色->Ranger角色

o Sentry給父對象的賦權也包括孩子對象->Ranger的粒度更細，因此翻譯成可為父和子（父數據庫，子表）啟用創建策略

o Sentry的Owner概念->Ranger ALL特權

o Sentry 的 OWNER WITH GRANT OPTION->Rannger的帶委託管理員的ALL權限，且不是過渡狀態

o Sentry Hive / HDFS ACL同步未包含在CDP-DC 7.1中（路線圖）

o 不建議使用sentry風格的GRANT / DENY語句。而是使用Ranger REST API。

· 通過將業務元數據（標籤、實體名稱、自定義屬性、描述和技術元數據（Hive、Spark、HDFS、Impala）遷移到Atlas從Navigator進行轉換，過程如下所示：

· 完成HDFS升級並完成升級。

4.4. 階段4：實施

· 評估並執行Yarn的設置規則，以確保作業可以輕鬆遷移

· 手動將所有數據庫/表路徑的HDFS ACL策略轉換為基於Ranger的策略。Ranger當前不支持HDFS ACL同步。此功能正在開發中，將很快發佈。

· 使用CapacityScheduler監視和調整YARN隊列配置，以匹配預期的運行時行為

4.5. 階段5：升級後測試和驗證

· 測試並驗證Hive、Spark、YARN和Policy的行為。

· 測試和驗證第三方工具。

5. 挑戰與解決方案

遇到並解決了以下問題和挑戰。

· Hive-on-Tez性能與Hive-on-MapReduce相比。

o 客戶A想了解Hive on Tez與Hive on Mapreduce。這對Hive on Tez具有很好的架構洞察力。

· Ranger，Ranger KMS和Atlas

· 由於複雜的血緣規則和配置，Navigator至Atlas的遷移速度很慢。Atlas隨附此配置中指定的默認堆大小為2GB，更改以增加內存配置解決了該問題。

· 在升級Ranger KMS時導入策略步驟中出現的問題。將“ keyadmin”角色授予Ranger中的rangerkms用戶有助於升級的Ranger KMS ACL導入步驟成功完成。

· Atlas到Kafka的連接問題。該問題在測試中發現，升級到7.1.2後已解決，Atlas能夠通過SASL_SSL連接到Kafka。CDP私有云基礎7.1.2已修復。

6. 結論

從CDH 5.x升級到CDP私有云基地可能是一個複雜的過程，但是Cloudera團隊擁有經過精心記錄的過程，以減輕風險並實現平穩升級。客戶A能夠在10周內成功完成遷移並從其生產工作負荷中獲取價值。通過利用Cloudera PS的專業知識，客戶可以與Cloudera支持合作快速識別任何問題或風險，並迅速解決它們。隨著應用團隊的測試和新問題的出現，Cloudera PS和客戶團隊迅速投入調試，發現問題區域並通過建議緩解它們。這些建議包括配置更改或基於Cloudera與其他客戶的持續學習而對客戶實踐的更新。

客戶A在Cloudera PS團隊的指導下成功地從CDH 5.14.2升級到CDP私有云基礎版。這使他們能夠啟用現代數據體系結構，增強其流傳輸功能併為CDP旅程的下一階段做好準備。

如果您準備開始升級到CDP私有云，請聯繫您的客戶團隊，並訪問my.cloudera.com上的CDP Upgrade advisor，以評估集群的準備情況。