Cloudera提供了企业数据云，使的公司能够为混合云构建端到端的数据管道，将边缘设备扩展到公有云或私有云，并以集成的安全性和治理作为基础来保护客户的数据。Cloudera发现，客户花了很多年时间在大数据资产上进行投资，并希望通过建立更现代化的架构来利用多种形态，继续在这一投资上继续发展。让我们看一下一位客户的升级过程。
背景
客户A是一家运行CDH5.14.2的金融服务公司。他们拥有运行关键工作负载的开发、测试和生产集群，并希望将其集群升级到CDP私有云基础版。客户升级有几个主要原因：
利用现有的硬件资源，避免通过添加新硬件来进行迁移的的昂贵资源、时间和成本。
使用CDP私有云基础版中提供的新的流传输功能，对他们的体系结构进行现代化升级，以实时获取数据，以便快速将数据提供给用户。此外，客户希望使用CDP私有云基础版7.1.2附带的新Hive功能。
客户还希望利用CDPPvCBase中的新功能，例如用于动态策略的ApacheRanger，用于血缘的ApacheAtlas，全面的Kafka流服务以及在旧CDH版本中不可用的Hive3功能。
客户的升级窗口较短，这表明需要通过在其现有环境上安装CDP进行就地升级，而不是所需时间较长的迁移升级路径：采购和设置新硬件、安装新的集群的操作开销、数据迁移。
客户利用CDP中的Cloudera多功能分析堆栈。数据生命周期模型使用Kafka提取数据，使用基于Spark的批处理流程丰富数据，使用Hive和Impala执行深度数据分析，最后使用ClouderaDataScienceWorkbench将数据用于数据科学以获取深刻的见解。
该客户的工作负载利用Syncsort来批量处理来自多个后端数据库源（如Oracle、SQLServer和传统大型机）的数据。使用CDSW的数据科学和机器学习工作负载。该客户是Kafka大量数据提取的用户。ClouderaCDP拥有行业领先的Kafka产品，为客户提供了采用该平台的强烈动力。
通过升级到CDP私有云基础版，客户现在还可以为CDP旅程的下一阶段做好准备，因为他们现在可以安装CDP私有云体验，以利用基于HiveLLAP的虚拟数据仓库的优势。
客户环境
客户具有三种环境：开发、测试和生产。为了最大程度地减少风险和停机时间，按该顺序执行升级，并将每次升级的经验应用于下一个升级的环境。总数据大小超过1PB。
升级团队
升级由一个包括客户、Cloudera客户团队和专业服务人员在内的工作组推动。Cloudera团队包括专业服务解决方案架构师和服务交付经理。客户团队包括数名Hadoop管理员、一名程序管理员、一名数据库管理员和一名企业架构师。此外，各个应用程序团队为测试和部署其工作做出了贡献。一些客户可能还需要包括平台/基础架构、网络和信息安全资源。
升级规划、过程和实施
客户使用Cloudera专业服务来执行深入分析和升级支持。一次重大升级通常会带来一些风险，ClouderaPS可以通过深入的计划和测试来缓解这些风险，包括功能更改、不兼容的数据格式、不赞成使用的较旧的组件或更改数据库架构。生产环境的重大升级可能需要数小时至数天的停机时间，因此，高效且有计划地进行升级以最小化风险至关重要。
该过程从创建基本需求以及每个升级以及测试步骤和过程的深入计划开始。
阶段1：规划
查看组件列表并确定迁移已弃用和已删除组件（例如Pig，Flume，YarnFairScheduler，Sentry和Navigator）的工作负载所需的任何工作。
查看升级文档主题以获取受支持的升级路径。
查看升级要求–CDP私有云基础版支持以下操作系统，数据库和JDK。
操作系统–RHEL/CentOS/OEL7.6/7.7/7.8或Ubuntu18.04
DB–Oracle12.2.0.1，Postgres10，MySQL5.7或MariaDB10.2
JDK–OpenJDK8/OracleJDK8/OpenJDK11
查看升级前的过渡步骤
收集有关当前部署的信息。记录开发/测试/生产集群的数量。记录操作系统版本，数据库版本和JDK版本。确定操作系统是否需要升级，请按照文档进行备份，并将操作系统升级到支持的版本。查看JDK版本，并确定是否需要更改JDK版本，如果需要，请按照此处的文档进行升级
计划如何以及何时开始升级。扫描所有文档并阅读所有升级步骤。
阶段2：升级前
使用此处的备份步骤列表备份现有集群
确认是否满足所有先决条件。确保满足所有未解决的依赖关系。
将Spark1.x作业转换为Spark2.4.5。测试并验证作业，以确保执行和测试所有必需的代码更改。
将YARN从FairScheduler转换为CapacityScheduler，并为新的默认计划程序配置队列。CDP不推荐使用FairScheduler，并且不支持它。提供了一个新的工具“fs2cs”CLI工具来进行基本的队列结构迁移（CS和FS之间的行为不同，fs2cs工具仅转换部分配置，请参阅doc），然后上载到新的CM。队列迁移所需的升级后步骤是重新配置队列的ACL，并使用新的QueueManagerUI调整调度程序队列。
为所有相关服务（例如Ranger，Atlas等）设置和配置新数据库。
阶段3：升级
使用此处记录的步骤将ClouderaManager升级到7.1.2。
使用ClouderaManager下载、分发和激活ClouderaRuntime7.1.x数据包。
将所有相关服务和组件（例如Kafka，CDSW）迁移或升级到适当的受支持版本。并对所有这些服务和组件进行验证
升级到最新版本的CDPPvCBase7.1.2。对集群中部署的组件执行过渡前步骤。
注意：fs2cs，nav2atlas和sentrytoranger是从CDH5旧式集群过渡到CDPPvCBase的迁移工具和过程。
执行所有与加密有关的步骤
通过使用FS2CS转换实用程序将YARN设置从FairScheduler迁移到CapacityScheduler，将YARN调度程序从FairScheduler过渡到CapacityScheduler，然后使用YARNQueueManagerUI手动配置调度程序配置，以确保生成的配置适合应用程序调度要求。需要重新配置队列优先级以获得最佳性能。
通过从sentry导出策略规则并继续进行升级步骤，以将Sentry策略转换为Ranger策略，从Sentry过渡到Ranger。转换将以下sentry实体转换为Ranger：
osentry角色-Ranger角色
oSentry给父对象的赋权也包括孩子对象-Ranger的粒度更细，因此翻译成可为父和子（父数据库，子表）启用创建策略
oSentry的Owner概念-RangerALL特权
oSentry的OWNERWITHGRANTOPTION-Rannger的带委托管理员的ALL权限，且不是过渡状态
oSentryHive/HDFSACL同步未包含在CDP-DC7.1中（路线图）
o不建议使用sentry风格的GRANT/DENY语句。而是使用RangerRESTAPI。
通过将业务元数据（标签、实体名称、自定义属性、描述和技术元数据（Hive、Spark、HDFS、Impala）迁移到Atlas从Navigator进行转换，过程如下所示：
完成HDFS升级并完成升级。
阶段4：实施
评估并执行Yarn的设置规则，以确保作业可以轻松迁移
手动将所有数据库/表路径的HDFSACL策略转换为基于Ranger的策略。Ranger当前不支持HDFSACL同步。此功能正在开发中，将很快发布。
使用CapacityScheduler监视和调整YARN队列配置，以匹配预期的运行时行为
阶段5：升级后测试和验证
测试并验证Hive、Spark、YARN和Policy的行为。
测试和验证第三方工具。
挑战和解决方案
遇到并解决了以下问题和挑战。
Hive-on-Tez性能与Hive-on-MapReduce相比。
o客户A想了解HiveonTez与HiveonMapreduce。这对HiveonTez具有很好的架构洞察力。
Ranger，RangerKMS和Atlas
由于复杂的血缘规则和配置，Navigator至Atlas的迁移速度很慢。Atlas随附此配置中指定的默认堆大小为2GB，更改以增加内存配置解决了该问题。
在升级RangerKMS时导入策略步骤中出现的问题。将“keyadmin”角色授予Ranger中的rangerkms用户有助于升级的RangerKMSACL导入步骤成功完成。
Atlas到Kafka的连接问题。该问题在测试中发现，升级到7.1.2后已解决，Atlas能够通过SASL_SSL连接到Kafka。CDP私有云基础7.1.2已修复。
结论
从CDH5.x升级到CDP私有云基地可能是一个复杂的过程，但是Cloudera团队拥有经过精心记录的过程，以减轻风险并实现平稳升级。客户A能够在10周内成功完成迁移并从其生产工作负荷中获取价值。通过利用ClouderaPS的专业知识，客户可以与Cloudera支持合作快速识别任何问题或风险，并迅速解决它们。随着应用团队的测试和新问题的出现，ClouderaPS和客户团队迅速投入调试，发现问题区域并通过建议缓解它们。这些建议包括配置更改或基于Cloudera与其他客户的持续学习而对客户实践的更新。
客户A在ClouderaPS团队的指导下成功地从CDH5.14.2升级到CDP私有云基础版。这使他们能够启用现代数据体系结构，增强其流传输功能并为CDP旅程的下一阶段做好准备。
如果您准备开始升级到CDP私有云，请联系您的客户团队，并访问my.cloudera.