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，以评估集群的准备情况。