如何實現CDH到雲原生大資料平臺的快速平滑遷移？

在大資料發展的初期，以Hadoop為中心的大資料生態技術框架，是能基本滿足企業和機構建設大資料平臺的需要的。

當時，以Cloudera為代表的Hadoop發行商，所提供的Hadoop發行版，以降低企業使用Hadoop難度，其中代表產品Cloudera Data Hub(簡稱CDH)。所以，從那時起，基於CDH執行的大資料平臺不在少數。

傳統大資料平臺困難重重，CDH落伍了?

隨著時代的發展，大資料技術使用逐步地深入，大資料開發需求變得越來越旺盛，企業對多租戶環境下大資料開發的效率、大資料叢集資源利用率、新的計算儲存引擎、人工智慧和機器學習技術的整合速度提出了越來越高的要求，而傳統大資料平臺在面對這些需求時則顯得有點束手無策，出現了無法依靠自身的發展來克服這些困難的困境。我們仔細分析一下，就可以看到傳統大資料平臺的技術架構決定了依靠它本身的發展是無法克服這些困難的：

困難一：傳統大資料平臺難以實現資源的隔離。多租戶環境下的資料開發效率提升，需要以資源隔離的方式來保證租戶之間的計算作業互相不影響，特別是不能出現某一個或幾個租戶獨佔叢集資源的情況。但Hadoop系統本身的出發點就不是為了多租戶環境而設計的，其目前的資源隔離實現也不完善。在最近的Hadoop版本中，在一定程度上實現了記憶體資源和檔案資源的隔離，但是不夠完整，而磁碟I/O和網路I/O的隔離還在社群討論的過程中，短期內看不到解決的希望。

困難二：傳統大資料平臺難以整合新的計算和儲存技術。Hadoop系統在部署其他元件的時候，對這些元件與HDFS和Yarn的版本適配是有嚴格要求的。很多新的大資料元件是不適配老版本的Hadoop的，而升級Hadoop又會造成其他元件的失效。另外，部署新的元件還要考慮到Linux不同作業系統的相容性所帶來的額外複雜度。所以引入一個新的計算和儲存元件的難度是非常高的，往往需要幾天甚至是幾周的時間。

困難三：Hadoop存算合一的緊耦合架構決定了它的資源利用率無法提高。在一個Hadoop叢集中，一個節點既是儲存節點(data node)， 也是計算節點。當儲存資源不夠的時候， 增加節點可以進行儲存擴容，但會造成計算資源的利用率下降;同樣，當計算資源不夠而進行擴容的時候，儲存資源利用率就會下降。同時，因為對於Yarn的依賴，不使用Yarn排程的其它元件很難整合到Hadoop的計算框架中。所以Hadoop的這種耦合架構決定了它的資源利用率不高。

困難四：Hadoop叢集資源無法做到快速的彈性擴容和縮容。彈性的擴容和縮容是提高叢集資源利用率的有效方法。很遺憾，Hadoop的節點擴容和縮容流程，導致這個動作無法在很快的時間內完成，尤其是縮容過程， 只有當一個data node的所有資料塊都在其他節點完成了備份以後， 該節點才能被移出叢集，而由於資料備份是以較小的傳輸率執行在後臺，往往要持續幾個小時以上。

傳統大資料平臺因為其結構性的缺陷導致了多租戶環境下資料開發效率低、叢集資源利用率不高、以及整合新技術很複雜等問題，依靠Hadoop生態技術框架本身的發展解決這些問題是比較困難的。

總而言之，很多企業基於CDH的大資料平臺已經執行很多年了，現在沒辦法很好地滿足企業的業務需求。這也就不難理解，為什麼CDH落伍了。

被困在CDH的客戶，必須要遷移了

很多被困在CDH的客戶，長期無法得到元件升級和技術更新，嚴重影響大資料平臺的使用。所以，不少企業必須做出這樣的決定，即將自己的大資料平臺遷移至雲原生大資料平臺上。那麼，如何能夠快速且平滑地將CDH遷移到雲原生大資料平臺，又遷移到什麼樣的雲原生大資料平臺上呢?

BDOS Kubernets Data Platform(以下簡稱：KDP)是智領雲研發團隊基於容器、K8s和大資料技術研發的大資料平臺產品。這一產品的誕生，是要利用雲原生的資源隔離、作業混排、存算分離、標準化部署運維等技術優勢，解決傳統大資料平臺因本身技術侷限性而無法解決的資源利用率低、部署運維複雜、難以彈性擴容等技術難題，幫助使用者花更少時間、用更少的資源去進行大資料平臺的部署、配置和運維，投入更多的時間和精力去進行大資料開發和分析，更高效、更穩定地從海量資料當中挖掘資料的價值並提升企業的數字化能力。

KDP支援主流的大資料計算和儲存引擎，強化了這些大資料元件在生產環境下的安全性、穩定性和執行效能。同時，平臺的大資料整合基座實現大資料元件的標準化部署和運維，統一了所有大資料元件與可觀測性服務的適配，並且支援了在K8s排程機制之上的更精細化的作業排程機制。平臺支援在公有云和私有云部署，支援社群版的K8s和主流的商業版K8s，適用於不同的企業環境。

以CDH為代表的傳統大資料平臺，遷移到KDP的案例實踐

智領云云原生大資料平臺KDP，能夠幫助企業快速平滑的進行遷移，這也是企業選擇我們的原因。

大資料元件及服務，與Kubernetes的版本適配

大資料元件(如Hadoop、Spark、Flink、Hive等)有自己的釋出版本。不同的版本對 Kubernetes 的特定版本有不同的支援程度，或者需要一些調整才能適應新的 Kubernetes 版本。Kubernetes 是一個不斷髮展的開源專案，每個版本都會引入新的功能、改進和修復。因此，大資料元件需要與特定版本的 Kubernetes 保持相容。大資料元件及服務，與Kuberentes的版本適配，需要考慮：

API相容性：API大資料元件和服務通常需要與 Kubernetes API 進行互動，不同版本的 Kubernetes 可能會引入 API 的變更，因此，確保大資料元件能夠與目標 Kubernetes 版本的 API 相容。

網路策略：Kubernetes 的網路模型和策略因版本升級而發生變化。大資料元件通常需要特定的網路配置，包括服務發現、通訊埠等。

Pod排程和親和性：大資料工作負載對節點資源和親和性有特殊要求，需要確保大資料元件能夠在 Kubernetes 版本中正確排程和執行。

儲存和持久卷：大資料元件通常需要持久化儲存，而 Kubernetes 的持久卷機制會因不同版本而有變更，需要確保大資料元件對於儲存的要求與目標 Kubernetes 版本的持久卷機制相相容。

安全機制：Kubernetes 引入了許多安全機制，如 RBAC(Role-Based Access Control)、Pod 安全策略等，需要確保大資料元件的安全配置與目標 Kubernetes 版本的實踐相符。

資源管理：大資料工作負載對資源的需求往往較大，需要確保 Kubernetes 版本的資源管理機制與大資料元件的需求相匹配。

Kubelet版本：大資料元件依賴於執行在每個節點上的 Kubelet 程式，需要確保目標 Kubernetes 版本中的 Kubelet 版本與大資料元件的版本相容。

排程器的變更：大資料元件需要特定的排程策略，而 Kubernetes 的排程器在版本之間會進行改進或調整，需要確保在大資料元件能夠被正確排程。

監控和日誌：大資料元件的監控和日誌整合通常依賴於 Kubernetes 的相關功能，需要確保監控和日誌系統的配置與目標 Kubernetes 版本相容。

Operator 或 Helm Chart 的更新：如果使用 Operator 或 Helm Chart 管理大資料元件，需要確保這些工具版本可以支援目標 Kubernetes 版本。

KDP 產品能力之一是可以對接社群最新版本大資料元件

快速響應社群創新：KDP 能快速響應社群中新版本的大資料元件釋出，具備足夠的靈活性和可擴充套件性，能夠在短時間內適配、整合並支援社群的創新。

支援多種大資料元件： KDP 支援多種不同型別的大資料元件，如分散式儲存系統(如HDFS)、計算框架(如Spark、Flink)、資料處理引擎(如Hive、Kylin)等，能夠滿足使用者多樣化的大資料處理需求。

版本相容性： 與社群最新版本的大資料元件具有良好的版本相容性，對元件的API、配置檔案和資料格式有深入瞭解，確保在升級時不會引入不穩定性或不一致性。

自動化整合和測試： 實施自動化的整合和測試流程，確保對接最新版本的大資料元件時不會引入嚴重的問題。包括構建自動化測試套件，模擬真實環境中的使用情景，並在對接前後執行全面的驗證。

版本管理和回滾機制： 實現版本管理和回滾機制，在對接新版本時，KDP 能夠方便地切換回之前的版本，以應對意外情況或相容性問題。

安全性和身份驗證系統對接

IAM對接關鍵考慮因素

對接客戶 IAM(身份和訪問管理)系統是一個涉及到安全性和合規性的重要任務，需要考慮關鍵因素：

協議和標準： 確保系統與客戶 IAM 系統使用相同的身份驗證和授權協議，如OAuth、SAML(Security Assertion Markup Language)、OpenID Connect等。

使用者身份對映： 確定客戶 IAM 系統中的使用者身份如何對映到系統中。涉及到使用者識別符號(如使用者名稱、電子郵件地址)、使用者組(Group)資訊等。

單點登入(SSO)：如果客戶 IAM 系統支援單點登入，考慮整合以提供無縫的使用者體驗。這樣使用者只需要一次登入，即可訪問多個系統。

許可權和角色對映： 確定客戶 IAM 系統中的許可權和角色如何對映到系統中，包括訪問資源的許可權和可執行的操作。

安全傳輸： 透過使用安全協議和加密手段，確保身份驗證資訊在傳輸過程中的安全性。

使用者同步和 Provisioning：確保使用者資訊在客戶 IAM 系統和你的系統之間的同步和 Provisioning 是關鍵的，涉及到使用者的建立、更新、刪除等操作的同步。

令牌管理： 確保客戶 IAM 系統生成的令牌可以被你的系統有效地驗證，並在適當的時候進行重新整理。

審計和監控： 在對接過程中整合審計和監控機制，以便能夠跟蹤使用者活動並檢測任何異常行為。

合規性和法規： 遵循適用的合規性標準和法規，確保身份驗證和訪問控制的實施符合相關要求。

IAM對接注意事項

確認使用者規模，考慮是否支援使用者增量變更查詢，輔助評估可行性;

同步原則上是單向，只會在IAM定義，修改;

溝通確定許可權變更之後的生效時間;

KDP 在對接客戶IAM系統的優勢。

透過 KDP 和客戶IAM 系統對接，可以滿足應用級別的訪問控制、選單級別的訪問控制、建立KDP使用者的同步。

統一身份管理： 透過對接客戶 IAM 系統，KDP 可以實現將目標使用者進行同步，並可訪問雲原生大資料系統中的各個元件和服務。

許可權精確控制： 支援使用者粒度的許可權控制和選單基本的訪問控制，使用者可以在自己的IAM系統中定義對 KDP 系統中的應用及功能選單的許可權控制，並透過配置許可權訪問和使用系統功能。

集中化訪問控制： 在整個雲原生大資料系統中，可以透過系統進行一致性的許可權管理，簡化了許可權配置和維護的複雜性。

單點登入(SSO)：使用者只需在系統中進行一次身份驗證，即可訪問多個雲原生大資料系統中的元件和服務，提高使用者體驗。

彈性適應多雲環境： 在多雲環境中執行的 KDP 雲原生大資料系統，對接客戶 IAM 系統可以使得跨雲的身份驗證和授權更加靈活，適應多雲戰略。

安全性提升： KDP 雲原生大資料系統可結合客戶 IAM 系統先進的安全性功能，如多因素身份驗證(MFA)等，提升整體安全性措施。

監控告警系統的對接

將CDH(Cloudera Distribution for Hadoop)大資料元件遷移到雲原生大資料系統時，涉及監控和告警的對接需要考慮以下內容：

監控體系的相容性：確保CDH中使用的監控體系和工具與目標雲原生大資料系統相容。不同的大資料元件可能使用不同的監控系統，而云原生環境可能有自己的監控和觀測解決方案(如Prometheus、Grafana等)。

指標和日誌的收集：確保CDH大資料元件的關鍵指標(Metrics)和日誌能夠被正確地收集和匯入到目標雲原生環境的監控系統中。

告警規則的轉換：將CDH中的告警規則對映到雲原生大資料系統的告警規則，需要重新配置告警閾值、觸發條件等資訊，以適應目標系統的告警體系。

許可權和認證：確保在監控和告警的對接過程中考慮到許可權和認證的問題，保障監控資料的安全性。

KDP在進行大資料元件的監控告警系統對接的優勢

KDP 可提供大資料元件以及其執行的workload的日誌，效能/穩定性的指標監控和報警，計費以及審計功能。除了提供介面和SDK方便大資料元件接入可觀測性服務，KDP可觀測性服務和通用PaaS平臺最大的區別在於可以支援：批處理任務，二級排程任務，各種資料層面的指標。

全面的監控和報警功能： KDP 提供了全面的監控和報警功能，覆蓋大資料元件的執行工作負載、日誌、效能/穩定性指標等多個方面。使用者能夠全面瞭解系統執行狀況，並在有異常情況時及時採取措施。

大資料元件日誌記錄： KDP 不僅提供了對大資料元件執行的工作負載的日誌記錄，還能夠深入到大資料元件本身的日誌，有助於使用者在問題發生時快速定位和排查。

效能/穩定性指標監控：KDP可觀測性服務提供了對大資料元件執行效能和穩定性的詳細指標監控。使用者可以實時瞭解任務的執行時間、資源利用率、資料處理速度等資訊，有助於最佳化系統效能。

靈活的告警規則配置： 使用者可以根據自身需求配置靈活的告警規則。一旦觸發告警條件，系統會及時通知使用者，使得使用者能夠快速響應和處理問題。

計費功能整合： KDP 整合了計費功能，透過監控大資料元件的使用情況，為使用者提供了精確的計費資訊。有助於使用者最佳化資源利用和控制成本。

審計功能： 透過KDP可觀測性服務，使用者可以進行審計，記錄大資料元件的執行歷史、配置變更、訪問控制等資訊。這有助於確保系統的安全性和合規性。

支援批處理和二級排程任務： 與通用PaaS平臺相比，KDP可觀測性服務專注於大資料領域，能夠深度支援批處理任務和二級排程任務，使用者能夠更靈活地管理和監控各類任務。

資料層面指標監控： KDP可觀測性服務提供了對資料層面的詳細指標監控，包括吞吐量、延遲等，有助於使用者全面瞭解資料處理過程的質量和效率。

介面和SDK支援：為方便大資料元件接入可觀測性服務，KDP提供了友好的介面和SDK，使大資料元件能夠輕鬆地整合到監控和告警系統中。

資料遷移

遷移CDH Hive資料到 KDP 系統時，需要考慮一系列因素，以確保順利遷移並最大程度地保留資料完整性和效能。

版本相容性： 確保雲原生大資料系統的元件和版本與CDH中使用的Hive版本相容。有時候，不同版本之間可能存在語法差異或特性變化，需要仔細檢查和調整。

資料格式和儲存： 驗證CDH Hive中使用的資料格式(如Parquet、ORC等)是否與雲原生大資料系統的Hive相容。如果存在不同的資料格式，可能需要進行格式轉換。

後設資料遷移： Hive表的後設資料包括表結構、分割槽資訊等，確保將這些後設資料遷移到雲原生大資料系統的Hive後設資料儲存中。這可以透過使用後設資料匯出工具、Hive後設資料複製工具等來實現。

儲存位置和許可權： CDH中的Hive表可能依賴於特定的HDFS路徑和許可權設定。在遷移過程中，確保目標雲原生大資料系統中有相應的儲存位置，並設定正確的訪問許可權。

UDFs和自定義函式：如果CDH Hive中使用了自定義的使用者定義函式(UDFs)或其他自定義函式，確保這些函式在雲原生大資料系統中也可用，或者進行相應的調整和遷移。

配置調整： 雲原生大資料系統和CDH的Hive可能有不同的配置引數和預設設定。審查和調整這些配置，以滿足目標系統的效能和需求。

效能調優： 遷移後，可能需要對錶和查詢進行效能調優。這可能包括重新分析表、最佳化資料分割槽、重新設計查詢等步驟。

資料遷移策略： 選擇合適的資料遷移策略，可以是全量遷移，也可以是增量遷移。全量遷移適用於資料規模較小的情況，而增量遷移則適用於大規模資料的情況。

透過 KDP 遷移 CDH Hive 資料原生大資料系統的優勢

可透過 KDP 建立一個與CDH上相同的Hive後設資料庫。透過執行Hive DDL語句或使用後設資料庫備份進行恢復來完成。

可靈活使用Hadoop DistCp工具，將Hive表的資料複製到新的KDP大資料平臺。確保資料完整性和一致性。

快速實現從CDH HDFS到KDP的HDFS複製。

遷移 CDH Hive 資料原生大資料系統的注意事項

【1】Hive Reader：

使用 hivereader 作為讀取外掛。

指定源 Hive 的連線資訊，包括使用者名稱、密碼、JDBC URL。

指定源表的名稱、欄位等資訊。

【2】Hive Writer：

使用 hivewriter 作為寫入外掛。

指定目標 Hive 的連線資訊，包括使用者名稱、密碼、JDBC URL。

指定目標表的名稱。

【3】其他配置：

可以配置速度等其他任務級別的引數。

Sentry到Ranger資料遷移

Sentry和Ranger都是用於許可權管理和訪問控制的工具，它們通常與大資料平臺(如Hadoop生態系統)一起使用。將Sentry的許可權資料遷移到Ranger，需要執行以下步驟：

備份資料： 在進行任何資料遷移之前，首先確保對Sentry的資料進行備份。這包括許可權、角色、策略等資訊。確保備份是完整的且可恢復。

理解Sentry和Ranger的模型差異：Sentry和Ranger有不同的許可權模型和概念。在遷移之前，確保瞭解兩者之間的差異，以便正確對映許可權。

建立Ranger Repository：在Ranger中，首先需要配置一個Repository來儲存許可權資訊。這可以是基於資料庫的，如MySQL或PostgreSQL。根據你的需求選擇並配置相應的Repository。

建立Ranger策略：在Ranger中，許可權透過策略(policy)來管理。你需要為每個Sentry的許可權建立相應的Ranger策略。確保正確對映使用者、組、資源和許可權。

編寫指令碼或工具進行資料遷移： 編寫指令碼或使用工具來從Sentry的備份資料中提取資訊，並將其轉換為Ranger Repository和策略。這可能涉及到對許可權和使用者對映進行適當的轉換。

測試遷移： 在生產環境之前，先在一個測試環境中進行資料遷移。確保許可權遷移正確，使用者能夠按預期訪問資源。

執行遷移： 一切準備就緒後，執行遷移過程，並確保在生產環境中保留備份。

驗證和監控： 驗證Ranger中的許可權和策略是否與Sentry中的一致。設定監控機制來追蹤許可權的使用和變更。

透過 KDP 將 Sentry 資料遷移到 Ranger 的優勢

版本相容性：KDP 會完成統一的版本適配，可確保目標版本支援CDH Sentry的資料遷移。

後設資料遷移：KDP 可將Sentry中後設資料準確地遷移到Ranger中，以確保許可權設定的一致性。

角色和許可權對映：在Sentry和Ranger之間存在不同的角色和許可權模型，透過KDP可快速實現將Sentry中的角色和許可權正確地對映到Ranger的對應概念上，並進行新的Ranger策略在大資料元件上的應用。

資源和策略對映：可透過 KDP 應用Ranger管理介面或API，建立新的資源，並進行快速驗證與應用。

將Sentry資料遷移到Ranger的注意事項

Sentry和Ranger的版本之間可能存在差異，因此確保參考正確版本的文件來執行遷移。此外，可能需要手動處理一些特定於環境和用例的問題。

在整個遷移過程中，建議謹慎操作，確保備份資料的完整性，並在遷移前進行足夠的測試。

從CDH到智領云云原生大資料平臺KDP的遷移，是一項非常有挑戰的工作，但透過遷移，資料平臺從原本老舊的CDH，是可以順利平滑過渡到了智領云云原生大資料平臺KDP上來。

智領雲相信雲原生技術是企業數字化轉型的必經之路，雲原生大資料平臺則是取代傳統大資料平臺的必然結果。智領雲研發團隊將會密切關注雲原生技術和大資料技術的發展路線，在大資料技術的雲原生化方向為企業提供更好的產品和技術服務，幫助企業打造面向未來的雲原生數字底座。