CDP7迁移评估：从CDH到Cloudera Data Platform的核心变化与踩坑记录

2020年5月中旬我参加了一场Cloudera厂商组织的技术交流活动主题就是当时的明星产品CDP7。去之前说实话我并没有抱太大期望毕竟我们生产环境里还跑着CDH5.16CDH6也才刚稳定突然冒出来一个CDP7总觉得更像是商业层面的换名游戏。但一场会听下来很多东西超出了我的预期也让我把原本计划的升级路线重新翻出来审视了一遍。这篇记录就当作一次参后感把我认为真正值得关注的技术点、厂商没有明说的潜在问题以及我回来之后做过的验证测试一次性都写清楚给同样在评估CDP7的大数据平台团队一个参考。1. 那天的现场与CDP7的来龙去脉1.1 去之前的疑惑CDH、HDP、CDP这三个词到底什么关系先简单交代一下背景。Cloudera和Hortonworks这对老冤家在2019年完成了合并当时很多人都觉得奇怪两个做了十年競品的大数据发行版厂商走到一起产品线要怎么收场一个手里握着CDH一个手里握着HDP总不能让客户二选一或者两边继续内耗。所以合并之后官方一直在放风说会推出一个统一的新平台名字就叫Cloudera Data Platform简称CDP。而我那次活动之前对CDP的了解基本停留在官方博客和几篇新闻稿上只知道它会把CDH和HDP的组件揉在一起但具体怎么揉、版本号为什么不是CDH7或者HDP4而是直接跳到CDP7心里是有疑问的。加上我们团队之前跟厂商做过几轮沟通大家普遍的疑虑是CDP7是不是就是CDH6套了个新外壳Ranger和Sentry的权限体系到底怎么兼容如果从CDH5直接跨到CDP7Hive表和HDFS目录这些还认不认这些问题在邮件和微信里很难讨论清楚所以那个下午的交流活动更像是带着一堆清单去现场找答案。1.2 厂商正式给出一个明确说法CDP7是合并后的统一基线厂商那天的开场没有绕弯子直接给了一个比较确定的定义CDP7是Cloudera和Hortonworks合并之后基于CDH6和HDP3两条技术线整合出来的新平台基线后面不再分CDH或者HDP了所有版本演化和新特性都集中到CDP这个产品上。这句话听起来简单但对当时的用户来说信息量不小。首先这说明CDH6和HDP3都不是长期分支了官方未来的新组件、新功能主要会落到CDP的版本迭代里。其次版本号选7而不是延续6.x也有意打破了跟CDH的强绑定印象产品叙事从“发行版”转向“数据平台”。厂商还特意点了一个对我很关键的信息CDP7里的Hadoop生态组件会统一到同一套基线版本不再像以前CDH和HDP各自维护不同版本。这意味着你在CDP7里看到的Hive、Spark、Kafka选择是收敛的不会出现同一个发行版里组件版本五花八门的情况。对运维团队来说这算是实打实的好消息至少依赖冲突会少一些。1.3 听完以后我的三点判断整个交流活动持续了差不多两个小时听完全程我心里其实已经有了一个比较粗的结论。第一CDP7对企业数据平台的定位明显比CDH更高不只是把组件升级一遍而是强调统一数据平台、内置安全治理、以及多云和本地部署的灵活性。官方演示里的内容很大篇幅都放在数据目录、权限策略、审计这些以前容易忽略的地方。第二从CDH5或CDH6往CDP7迁移不是简单改个仓库地址再做次升级需要把Hive Metastore、Sentry或Ranger里的权限策略、以及Kerberos和Sentry相关的配置都重新梳理。厂商的架构师现场也承认最花时间的往往不是HDFS数据搬移而是安全模型和Hive元数据的兼容。第三CDP7对于已经在用CDH6.x的团队来说迁移成本相对可控但如果还在CDH5.16甚至更低版本那么中间最好先升到CDH6再走CDP7的路径直接跨版本跳跃风险比较大。这个判断后来在我自己做的测试里也得到了验证。2. CDP7核心能力拆解哪些地方动了真格2.1 存储与计算层的统一逻辑CDP7比较明显的一个变化是在存储和计算层面做了一层更清晰的收敛。以前CDH和HDP各自维护各自的开源组件版本用户比较头疼的是同一个开源项目在两个发行版里版本差很多比如HiveCDH6和HDP3用的版本就不一样。CDP7把底层Hadoop基线提升到了我们熟悉的Hadoop 3.x系列并且把Hive、HBase、Kafka、Spark这些核心组件都统一到同一条版本轨道上。用厂商的话说这是统一基线避免掉过去版本分裂带来的兼容问题。这个说法我举双手赞成因为我们在实际运维中见过太多因为Hive和Hadoop库文件冲突导致的奇葩报错根源就是发行版里外部依赖不统一。它里面还引入了一个全新的存储方向叫Ozone当时还是预览特性。官方意思是未来对象存储和HDFS可以在一个数据湖里共存不再需要两套集群。虽然当时我没有打算引入Ozone但这条信息对长期规划很有参考价值至少说明HDFS不会被轻易抛弃而是在向云原生方向演进。2.2 安全治理的整合Ranger取代Sentry不是换皮安全治理这块是CDP7和旧版CDH差异最大的部分。CDH6时代权限控制主要靠SentryHortonworks那边推的是Ranger。两者虽然都是行级权限、角色授权但策略模型、授权接口、审计日志是完全不同的两套东西。合并后CDP7统一选择了Ranger这是个很重要的决策。只从技术角度看Ranger的插件机制覆盖面更广。它对Hive、HDFS、HBase、Kafka都有独立插件还能管理数据目录级别的标签策略。Sentry在Hive和HDFS上做得不错但对Kafka这种消息系统基本没有话事权在大数据平台组件越来越多的情况下Sentry逐渐成了瓶颈。厂商现场也演示了Ranger的管理界面我印象比较深的是它有一个审计模块所有用户对Hive表和HDFS目录的访问动作都能汇总到一个界面里看这点对运维排查问题很有用。以前想查谁读了哪张表经常要到各个组件底层日志里去翻效率很低。但这里有个坑我要特别提醒如果你现在用的是CDH5或CDH6且已经把Sentry权限策略建得比较细那迁移到CDP7时Ranger不会自动把Sentry的策略平移过来。Sentry没有官方的自动迁移工具常见做法是先在Ranger里重建用户、角色和策略再逐步切换访问入口。这个过程最容易被低估尤其是权限策略多的大型集群光重配权限就能耗掉一个迭代周期的工时。2.3 集群升级路径从CDH6/HDP3到CDP7怎么切入厂商当天给了一个比较清晰的升级逻辑。如果是从CDH6.3这个小版本开始可以直接通过Cloudera Manager的升级向导走到CDP7步骤相对平滑。如果还在CDH5.16或者更老的版本那就不能直接跨代升级了得先升级到CDH6.x再做CDH到CDP的升级。如果是从HDP3过来也有对应的工具和流程但整体复杂程度会更高因为两个发行版的目录结构和服务管理体系本来就不一样。这个升级路径让我松了一口气因为我们当时已经计划从CDH5.16升到CDH6等于没有绕远路只要把原计划执行完后续再评估要不要升CDP7。不过厂商给的描述里有个前提得先保证Cloudera Manager本身升级到支持CDP7的版本。CM版本和集群版本之间的匹配关系这块特别容易踩坑。另一个我当时很关注的问题是滚动升级能力。老CDH版本做滚动升级虽然也支持但实际执行中经常因为HDFS DataNode的balance策略或者YARN上的长任务中断出问题。CDP7这次把滚动升级做得更平滑了一点HDFS存量和增量块迁移可以同时进行DataNode可以在线上下线对运行中的任务影响小很多。不过厂商也提醒如果Hive on MR任务还很多建议先在低峰期做一次演练别拿生产环境直接试。3. 现场Demo印象与回来后的验证实验3.1 演示中让我印象最深的三个镜头厂商的现场Demo主要集中在三个地方。第一个是安装部署。他们在几台虚拟机上一键拉起了一个小型CDP7集群全程都是通过Cloudera Manager界面点选从添加主机到各个服务启动完成前后也就十几分钟。这个对老运维来说确实眼前一亮因为以前手动部署一套CDH集群要花一下午时间全耗在装包、改配置、逐个启动服务上。CM把这件事压缩到一个向导里虽然生产环境不会这么天真但整体流程确实成熟了不少。第二个是Hive LLAP的交互式查询。厂商现场跑了几个SQL其中最复杂的一条我记得是TPC-DS里比较典型的查询扫描的数据量不大但查询计划很复杂用了不少Join和子查询。LLAP把热数据放在了分布式缓存里响应速度确实比传统的MapReduce执行快很多实际体验接近于跑在一个交互式数仓上。这个对业务侧有很大吸引力因为以前用Hive跑一条临时查询等十来分钟很正常。第三个是Ranger里的一条权限控制演示。厂商先在Ranger里给一个测试用户配了只允许访问某个库下的几张表的策略然后直接用Hive查询另一张表马上就被拦截了。重点是整个过程没有做任何HiveServer2层面的二次配置说明Ranger插件在服务端已经生效了。这个演示虽然简单但很能说明问题权限变更实时生效这在老集群里要改Sentry配置然后重启服务才能实现差距摆在那。3.2 回来后我单独复现的最小化安装过程活动结束后我没闲着在公司一套空闲的测试机上进行了一次最小化的CDP7安装验证。我没有按照生产集群的规模来只用了三台虚拟机各分配了8核16 GB内存和100 GB磁盘目标是搭一个可以跑HDFS、YARN、Hive on LLAP的小集群顺便把Ranger权限验证做一遍。我的具体步骤是这样的先在每台机器上装好操作系统基础环境关闭防火墙设置好主机名映射然后在一台节点上安装Cloudera Manager Server版本选择支持CDP7的那一版。这里要注意CDP7需要的CM版本和CDH6用的不是一个号段不要用老版本的CM去加载CDP7的仓库否则会出现无法识别parcel的报错。CM Server装好之后我通过Admin Console完成集群创建再从CDP7的parcel仓库里把对应版本的安装包下载到本地在CM里分发到所有节点。这个过程里比较耗时的是parcel分发三台机器还好生产环境几十个节点的话尽量提前把parcel放在本地仓库里不然部署时间很难看。服务选择上我按测试需要选了HDFS、YARN、Hive、HBase以及Kafka安全组件那边我启动了Ranger和Atlas。数据库方面我在其中一台机器上部署了MariaDBHive Metastore、Ranger Admin、Atlas这些服务都需要独立的数据库实例这一点在CDP7里也是老规矩每个组件一个库别有复用同一个库的偷懒想法不然后面升级和问题定位都会很难办。3.3 安装配置里最容易翻车的三个地方第一次完整跑下来我大概花了小半天。中间也遇到了几个问题这里列出来给大家做个参考。第一个坑是Hive Metastore的兼容性。CDP7自带的Hive版本是从CDH6和HDP3融合出来的如果你在用旧的CDH5环境导出的Metastore schema不能直接让它去连新版本的Hive Metastore。最稳妥的做法是先在CDH6的迁移路径里把Metastore schema升级到对应版本再让CDP7接手。官方官方迁移文档里其实有schema升级脚本但需要自己手动执行不是装上CM就自动帮你做。第二个很容易踩坑的地方是Kerberos配置。CDP7对Kerberos支持比旧版严格很多如果你环境里已有的KDC主体和keytab没有同步到新集群很多服务启动时会报“找不到principle”的错误。我建议在部署前把所有服务主体都先规划好包括HDFS、Hive、HBase、Kafka各自的作用域然后在CM里一次性导入不要先启动服务再补认证。第三个也是我单独验证Ranger时发现的Ranger和Hive的插件之间需要保证版本匹配而且要在HiveServer2主机上正确安装Ranger Hive Plugin并在CM里启用Ranger的Hive服务策略。我一开始没启用在Ranger里建了策略怎么都不生效后来排查到插件没被CM识别才反应过来。所以如果策略配了但不生效别急着怀疑Ranger本身先去看对应组件节点上的Ranger插件进程是不是真的启动了。4. 还没讲透的授权问题与选型思考4.1 订阅模式变化预算上要提前心理准备这场活动里厂商对授权收费的细节没有展开讲只在最后简单提了一句CDP7会逐步向订阅制迁移跟以前按节点数买License的模式不完全一样。这句话的含金量很高懂的都懂。CDH时代很多团队买的是按节点数计算的永久License付完钱之后只要不升版本可以一直用下去。CDP7如果走向订阅制就意味着费用不只是取决于集群规模也要考虑使用周期和增值组件数量。运维团队如果只是做技术评估不跟财务沟通很容易在续费或者新采购的时候被发现预算压根没留那个额度。我的建议是如果团队正在评估新技术平台尽早把授权模型问题列入评估维度。不要只看开源组件本身免费的部分还要看Cloudera Manager、Ranger、Atlas这些管理组件在订阅里的覆盖范围。平台运维不是只跑HDFS和YARN就完事了安全和元数据治理在CDP7里是核心能力这部分如果是订阅专属成本一定要算进去。4.2 不同处境下的团队该怎么选三类情况的建议结合我自己的评估经验我大致把团队分成了三类。第一类是仍在CDH5.16或者更低版本上运行业务平稳没有强烈的实时数仓或数据治理需求。我的建议是暂时不要碰CDP7先把CDH6的升级路径走完。CDH6本身已经比较成熟稳定性经过了验证即便未来要升CDP7从CDH6走也比从CDH5直接走平滑得多。第二类是已经在CDH6.3或HDP3上且对Ranger权限、Atlas数据血缘、以及云上扩展有明确诉求的团队。这类团队是CDP7的理想用户。因为他们已经站在同一个生态体系里升级路径相对清晰核心技术栈不需要推倒重来收益则比较明显。第三类是准备新搭建一套大数据平台的团队不管以前用的是CDH还是HDP新项目建议直接选择CDP7。理由是现在开源组件版本演进已经围绕CDP来做了与其部署一套刚出生就开始过时的旧基线不如直接用新平台至少后续版本路线图是明确的。4.3 这场会出来后的执行动作清单前面讲了很多分析最后放一个可以直接抄走的执行清单都是我实际评估时会做的事情按顺序分四步。第一步盘点现有环境。把所有CDH或HDP版本、组件清单、Hive表数量和权限策略数量都列出来尤其要统计Sentry里的角色和权限规则这块后面是要重建到Ranger里的数量直接决定迁移工时。第二步搭一套最小化CDP7验证环境。不用完全复刻生产规模先把HDFS、YARN、Hive、Ranger、Atlas跑通然后把一部分Hive表和测试用户权限手动迁移进去验证查询和权限控制是否符合预期。第三步做一次数据与元数据迁移演练。把Hive Metastore导出、HDFS distCp拷贝、Ranger策略导入这几个步骤完整走一遍。记录每个环节耗时这样后续算生产迁移窗口时才有依据不是凭感觉排计划。第四步走一次严格回滚演练。验证环境提前做好快照模拟迁移过程中Hive查询报错、权限策略丢失、HDFS块校验失败这几类情况看看回到旧集群需要多长时间。因为生产环境迁移最有价值的保障不是顺迁了多少而是失败之后多久能恢复。结尾的几点实在话那次活动结束到现在也有一段时间了我自己在测试环境里陆陆续续又跑了几次CDP7的流程最大的体会是这个平台在工程化程度上确实比老CDH时代前进了一大截尤其是Ranger的权限模型、LLAP的查询体验、以及CM对整个集群生命周期的控制力都是实打实能感受到的变化。但我还是要给那些准备跟着厂商节奏立刻上CDP7的团队泼一点冷水。新平台的能力再强你的数据规模、权限体系、团队维护水平是否跟得上才是决定成败的关键。尤其Ranger和Atlas这类治理组件它们需要长期有人维护策略和元数据规范如果只是装上就扔在那不管那它们能发挥的价值会大打折扣甚至成为新的运维负担。最后分享一个我在实际部署中觉得很顺手的小技巧把CDP7相关的parcel包、镜像仓库和数据库初始化脚本提前准备好放到内网的一个固定位置。这样不管以后是要扩展节点还是重建测试集群都不用再对外网下载依赖。测试环境多建几次之后你就会发现这个准备动作省下来的时间非常可观。