1. 为什么是CDH平台选型的底层逻辑1.1 不是只有CDH一个选择先说说我个人的结论如果你的团队从零开始搭大数据平台CDHCloudera Distribution including Apache Hadoop依然是一条稳妥、省事、可控的路。很多第一次接触大数据的人会问一个问题明明Apache Hadoop官方网站就能直接下载为什么还要用一个商业发行版我也这么想过直到我真的在生产环境里自己把Apache Hadoop从源码编译、配置、纠缠PVP、调参、部署完整一套下来之后才发现开源社区版和发行版的差距远不止“多了几个组件”这么简单。Apache Hadoop的原生发布包做POC没有问题但生产环境要考虑的是组件之间的兼容性、升级路径、监控体系、权限管理、组件的配置一致性。这些工作不是不能做而是需要你自己从底层维护一旦集群到了几十台甚至上百台规模纯手工管理的成本会迅速失控。举个例子只是给集群里的每个节点同步一份hdfs-site.xml配置文件、重启某个服务听起来简单但在几十台机器的规模下漏一台就可能导致整个集群的读写路径不一致而这种故障排查起来往往非常痛苦。CDH的核心价值在这里就很明显它把Hadoop生态里几十个开源组件HDFS、YARN、Hive、HBase、Spark、Kafka等打包进一个统一的版本体系所有组件的版本之间都做了严格的兼容性验证。你在界面上看到的每一个组件都是经过反复测试的组合避免了那种“Hive 3.1.2配Spark 3.0.0出现诡异报错”的版本地狱问题。简单来说选择CDH本质上不是为了“花钱买省事”而是为了获得一个确定性你对整个平台的行为有完整的预期出现问题时知道从哪里排查版本升级时不用把整个集群推倒重来。1.2 CDH真正带来的三个好处第一统一的监控与运维入口。Cloudera Manager作为管理平面把HDFS的NameNode状态、YARN的ResourceManager状态、Hive的元数据库连通性、各节点的磁盘余量、内存使用率、服务进程存活状态全部聚合到一个Web界面上。这个界面的价值不是“好看”而是让你能在十分钟内判断整个集群的健康状况而不是逐个节点登录上去查日志。第二图形化的配置管理与配置漂移控制。CDH把所有组件的配置文件集中到后台管理你在界面上改一个参数点“应用到主机”它会自动推送到对应的节点并滚动重启相关服务。这样做最直接的好处是避免了配置漂移——也就是某台机器上残留着一段旧配置行为跟其他机器不一致。第三组件生命周期管理。安装、启动、停止、升级、退役这些操作都可以在界面上有序执行。Cloudera Manager会处理组件之间的依赖顺序比如依赖HDFS的服务一定是在HDFS正常起来之后才启动不会出现你先启动Hive、结果HDFS还没就绪导致一堆连接报错的情况。2. 部署前的思考硬件、网络与操作系统准备2.1 硬件规划与角色划分在做任何安装动作之前先想清楚你的集群规模和使用场景。我自己常用的一个划分方式是把节点分成三类管理节点、主角色节点、工作节点。管理节点用于运行Cloudera Manager Server和Agent。小规模集群比如10台以内可以把Manager Server和NameNode放在同一台机器上但更稳妥的做法是单独给Manager Server留一台机器内存不低于16GB磁盘建议用SSD因为Cloudera Manager的监控数据会持续写入活动管理的数据库默认是Embedded PostgreSQL。我见过有人把Manager Server挤在同一台机器上还开了HDFS DataNode结果集群一跑起来Cloudera Manager界面光加载监控趋势图就要半分钟点一次服务操作卡半天。这种情况不是Cloudera Manager本身的问题而是管理节点被其他服务抢占了资源。主角色节点放NameNode、ResourceManager、Hive Metastore这些角色。这个角色组合的内存规划要仔细一点NameNode的堆内存和集群的文件数规模强相关一个百万级文件数的集群NameNode的堆内存给到8GB都不嫌多。YARN的ResourceManager主要做调度内存压力相对小但它的吞吐量和集群的任务数相关建议至少4GB堆内存。工作节点统一作为DataNode和NodeManager。每台机器的内存和CPU是决定你后续能跑多大作业的直接瓶颈。我个人的经验公式是如果机器内存是64GB系统预留和基础服务占掉大约8GB剩余的56GB里DataNode的堆内存给1GBNodeManager可以用的内存规划在48GB左右剩下的留给操作系统页缓存和突发负载。磁盘方面DataNode的存储目录建议至少分成独立的磁盘或挂载点不要全部都丢在系统盘。原因是HDFS的DataNode在多目录写入时会自动做磁盘均衡但如果你所有目录都在同一条IO链路上均衡就失去了意义。网卡方面数据节点之间的数据复制会占用大量带宽万兆内网能显著提升性能千兆网在数据量大的时候会成为明显瓶颈。2.2 操作系统配置与网络规划操作系统我建议选择主流发行版的64位Linux系统。CentOS 7.x是我用下来最顺手的版本原因不是它性能最好而是它和CDH各个版本的兼容性验证最完整、踩坑案例也最多遇到问题往往能搜到现成的解决方案。安装完操作系统之后有几项配置必须提前做否则后面装Cloudera Manager和启动HDFS时会遇到各种莫名其妙的坑。首先关闭防火墙或者至少放通集群内部所有节点之间的通讯端口。大数据集群内部的组件之间通讯涉及大量端口从8020NameNode RPC到8088YARN Web UI再到各种组件的随机端口逐个放行几乎不可能维护。我的做法是直接关闭firewalld和iptables只在集群前端的边界防火墙上做管控。所有节点执行之后可以检查一下服务状态确保没有开机自启。之后是SELinux。这个是老生常谈了但确实非常关键。SELinux开启的状态下很多服务的端口绑定、文件访问权限会受到额外限制排查起来特别费时间。我记得有一次HDFS的DataNode总是报权限错误查了半天才发现是SELinux拦截了进程对挂载点的访问。在存储目录、NameNode的数据目录这些路径上直接用setenforce 0并且修改/etc/selinux/config永久关闭即可。还有一个容易被忽略的配置所有节点的时间同步。大数据组件对时间不一致非常敏感Kerberos认证环境下更是如此。如果没有NTP服务集群里各节点的时间会慢慢漂移到一定程度会出现认证失败、心跳超时这类问题。至少要配置一个统一的时间服务器并确保各节点开机启动ntpd时自动同步。2.3 JDK版本的坑与选择CDH对JDK版本有明确的验证范围。这时候不要去追求最新的JDK版本而是用CDH官方验证过的版本。我最早部署的时候图省事直接装了当时最新的JDK结果启动HDFS时NameNode直接报了一个UnsupportedClassVersionError折腾了半小时。后来换回CDH默认适配的JDK版本问题就消失了。建议直接使用Oracle JDK 8或对应版本并且最好在所有节点上安装完全相同的JDK版本和目录路径。因为后面很多配置项比如JAVA_HOME都是写在配置文件里的如果各节点路径不一致后续在Cloudera Manager里做任何涉及JVM的操作都很容易出错。3. 从零到一的部署流程Cloudera Manager安装全记录3.1 节点基础配置部署前要在每个节点上做统一的用户和目录准备。CDH的安装过程会用到cloudera-scm用户这个用户是安装包自动创建的但也有一些目录需要提前准备好并设置好属主。比如/data下的数据盘挂载点如果你计划把HDFS的数据目录放在这里就要提前创建目录并且把属主改成cloudera-scm或者后续在Cloudera Manager配置时手动指定。我习惯的步骤是先确认所有节点的hostname已经设置好然后统一写入/etc/hosts把所有节点的IP和主机名映射都加上。这一步的意义在于CDH的集群内部通讯大量依赖主机名而不是IP如果你不提前配置好后面一定会遇到“无法解析主机名”之类的报错。然后是为集群节点配置SSH免密登录。虽然Cloudera Manager的安装向导支持你通过输入密码来部署Agent但如果你打算在安装后经常通过命令行维护集群免密登录会大幅提升效率。我通常会用ssh-keygen生成密钥然后通过ssh-copy-id分发到每个节点。3.2 搭建Cloudera Manager运行环境CDH部署的第一步是安装Cloudera Manager Server和Agent。官方提供了两种方式一种是通过repository方式在线安装另一种是准备离线安装包。我建议在能确保网络稳定且内网有软件源的情况下用在线方式没有把握就准备离线包。安装Cloudera Manager核心包的顺序是先装Server包再在所有节点上装Agent包。Server和Agent之间的通讯走的是7180端口HTTP和7182端口Server和Agent的通讯端口我在前面关闭防火墙之后这里就不需要额外放行了。选好安装路径之后Cloudera Manager Server会要求初始化它自带的Embedded PostgreSQL数据库。这个数据库是Cloudera Manager的活动管理库用于存放集群的监控数据、配置数据、主机列表等。小规模集群用自带的Embedded PostgreSQL完全没问题但当集群规模超过几十台、监控数据量上来之后我更建议使用独立部署的PostgreSQL或MySQL。不过这是后话在刚开始搭建时自带数据库足够用了。数据库初始化之后就可以启动Cloudera Manager Server。启动完成后浏览器访问http://server-ip:7180第一次访问时向导会让你登录默认账号密码是admin/admin。进入到主界面之后就能看到“添加集群”的引导流程。3.3 通过Web向导完成集群搭建这个引导流程是整个部署过程中最繁琐、也最容易出问题的一段。向导会要求你指定需要加入集群的主机列表提供一个具有免密登录权限的SSH账号然后它会自动把Cloudera Manager Agent分发到各台主机上并启动。Agent分发完成后你需要选择CDH的版本。这里会有几个不同的CDH版本可选选你提前下载好的那个版本就好。然后向导会把CDH的parcel包分发到所有主机并解压激活。这一过程耗时跟网络带宽和机器数量强相关一台机器可能要等十几分钟几十台机器拉长到一两个小时都不奇怪耐心等待即可。激活之后是“为集群添加服务”的环节。这里最核心的一组操作是你需要在向导里指定哪些主机运行HDFS的NameNode哪些主机运行YARN的ResourceManager哪些主机做DataNode和NodeManager。Cloudera Manager会基于你选的角色分配自动生成默认配置包含各角色的内存分配、存储目录、端口绑定等。默认配置可以直接用但我强烈建议在每个服务添加完成后点进对应的服务配置页对照你的硬件资源把关键参数调一遍不要直接点“继续”。所有组件安装完成后Cloudera Manager会进入一个安装检查的环节比如检查各主机的权限、目录可用性、内核参数是否合适。这个检查报告要仔细看里面报出来的每一条问题后面都会成为集群运行的不稳定因素。4. 服务组件应该如何选HDFS、YARN、Hive与其它4.1 核心组件按需选择第一次搭建CDH集群的时候最容易犯的一个错误是把所有能选的组件全部装上去。Cloudera Manager的服务列表里有HDFS、YARN、Hive、HBase、Spark、Kafka、Flume、Sqoop、ZooKeeper、Oozie、Hue等等看起来每个都值得装但每多装一个组件就意味着你的集群里多了一批需要维护的进程、多了一套监控项、多了一组潜在故障类型。我的建议是第一步只装核心组件——ZooKeeper、HDFS、YARN、Hive。ZooKeeper是很多组件的基础协调服务HDFS是存储底座YARN是计算调度Hive让你能用SQL的方式做数据分析。这四个组件构成了一个大数
1. 为什么是CDH平台选型的底层逻辑1.1 不是只有CDH一个选择先说说我个人的结论如果你的团队从零开始搭大数据平台CDHCloudera Distribution including Apache Hadoop依然是一条稳妥、省事、可控的路。很多第一次接触大数据的人会问一个问题明明Apache Hadoop官方网站就能直接下载为什么还要用一个商业发行版我也这么想过直到我真的在生产环境里自己把Apache Hadoop从源码编译、配置、纠缠PVP、调参、部署完整一套下来之后才发现开源社区版和发行版的差距远不止“多了几个组件”这么简单。Apache Hadoop的原生发布包做POC没有问题但生产环境要考虑的是组件之间的兼容性、升级路径、监控体系、权限管理、组件的配置一致性。这些工作不是不能做而是需要你自己从底层维护一旦集群到了几十台甚至上百台规模纯手工管理的成本会迅速失控。举个例子只是给集群里的每个节点同步一份hdfs-site.xml配置文件、重启某个服务听起来简单但在几十台机器的规模下漏一台就可能导致整个集群的读写路径不一致而这种故障排查起来往往非常痛苦。CDH的核心价值在这里就很明显它把Hadoop生态里几十个开源组件HDFS、YARN、Hive、HBase、Spark、Kafka等打包进一个统一的版本体系所有组件的版本之间都做了严格的兼容性验证。你在界面上看到的每一个组件都是经过反复测试的组合避免了那种“Hive 3.1.2配Spark 3.0.0出现诡异报错”的版本地狱问题。简单来说选择CDH本质上不是为了“花钱买省事”而是为了获得一个确定性你对整个平台的行为有完整的预期出现问题时知道从哪里排查版本升级时不用把整个集群推倒重来。1.2 CDH真正带来的三个好处第一统一的监控与运维入口。Cloudera Manager作为管理平面把HDFS的NameNode状态、YARN的ResourceManager状态、Hive的元数据库连通性、各节点的磁盘余量、内存使用率、服务进程存活状态全部聚合到一个Web界面上。这个界面的价值不是“好看”而是让你能在十分钟内判断整个集群的健康状况而不是逐个节点登录上去查日志。第二图形化的配置管理与配置漂移控制。CDH把所有组件的配置文件集中到后台管理你在界面上改一个参数点“应用到主机”它会自动推送到对应的节点并滚动重启相关服务。这样做最直接的好处是避免了配置漂移——也就是某台机器上残留着一段旧配置行为跟其他机器不一致。第三组件生命周期管理。安装、启动、停止、升级、退役这些操作都可以在界面上有序执行。Cloudera Manager会处理组件之间的依赖顺序比如依赖HDFS的服务一定是在HDFS正常起来之后才启动不会出现你先启动Hive、结果HDFS还没就绪导致一堆连接报错的情况。2. 部署前的思考硬件、网络与操作系统准备2.1 硬件规划与角色划分在做任何安装动作之前先想清楚你的集群规模和使用场景。我自己常用的一个划分方式是把节点分成三类管理节点、主角色节点、工作节点。管理节点用于运行Cloudera Manager Server和Agent。小规模集群比如10台以内可以把Manager Server和NameNode放在同一台机器上但更稳妥的做法是单独给Manager Server留一台机器内存不低于16GB磁盘建议用SSD因为Cloudera Manager的监控数据会持续写入活动管理的数据库默认是Embedded PostgreSQL。我见过有人把Manager Server挤在同一台机器上还开了HDFS DataNode结果集群一跑起来Cloudera Manager界面光加载监控趋势图就要半分钟点一次服务操作卡半天。这种情况不是Cloudera Manager本身的问题而是管理节点被其他服务抢占了资源。主角色节点放NameNode、ResourceManager、Hive Metastore这些角色。这个角色组合的内存规划要仔细一点NameNode的堆内存和集群的文件数规模强相关一个百万级文件数的集群NameNode的堆内存给到8GB都不嫌多。YARN的ResourceManager主要做调度内存压力相对小但它的吞吐量和集群的任务数相关建议至少4GB堆内存。工作节点统一作为DataNode和NodeManager。每台机器的内存和CPU是决定你后续能跑多大作业的直接瓶颈。我个人的经验公式是如果机器内存是64GB系统预留和基础服务占掉大约8GB剩余的56GB里DataNode的堆内存给1GBNodeManager可以用的内存规划在48GB左右剩下的留给操作系统页缓存和突发负载。磁盘方面DataNode的存储目录建议至少分成独立的磁盘或挂载点不要全部都丢在系统盘。原因是HDFS的DataNode在多目录写入时会自动做磁盘均衡但如果你所有目录都在同一条IO链路上均衡就失去了意义。网卡方面数据节点之间的数据复制会占用大量带宽万兆内网能显著提升性能千兆网在数据量大的时候会成为明显瓶颈。2.2 操作系统配置与网络规划操作系统我建议选择主流发行版的64位Linux系统。CentOS 7.x是我用下来最顺手的版本原因不是它性能最好而是它和CDH各个版本的兼容性验证最完整、踩坑案例也最多遇到问题往往能搜到现成的解决方案。安装完操作系统之后有几项配置必须提前做否则后面装Cloudera Manager和启动HDFS时会遇到各种莫名其妙的坑。首先关闭防火墙或者至少放通集群内部所有节点之间的通讯端口。大数据集群内部的组件之间通讯涉及大量端口从8020NameNode RPC到8088YARN Web UI再到各种组件的随机端口逐个放行几乎不可能维护。我的做法是直接关闭firewalld和iptables只在集群前端的边界防火墙上做管控。所有节点执行之后可以检查一下服务状态确保没有开机自启。之后是SELinux。这个是老生常谈了但确实非常关键。SELinux开启的状态下很多服务的端口绑定、文件访问权限会受到额外限制排查起来特别费时间。我记得有一次HDFS的DataNode总是报权限错误查了半天才发现是SELinux拦截了进程对挂载点的访问。在存储目录、NameNode的数据目录这些路径上直接用setenforce 0并且修改/etc/selinux/config永久关闭即可。还有一个容易被忽略的配置所有节点的时间同步。大数据组件对时间不一致非常敏感Kerberos认证环境下更是如此。如果没有NTP服务集群里各节点的时间会慢慢漂移到一定程度会出现认证失败、心跳超时这类问题。至少要配置一个统一的时间服务器并确保各节点开机启动ntpd时自动同步。2.3 JDK版本的坑与选择CDH对JDK版本有明确的验证范围。这时候不要去追求最新的JDK版本而是用CDH官方验证过的版本。我最早部署的时候图省事直接装了当时最新的JDK结果启动HDFS时NameNode直接报了一个UnsupportedClassVersionError折腾了半小时。后来换回CDH默认适配的JDK版本问题就消失了。建议直接使用Oracle JDK 8或对应版本并且最好在所有节点上安装完全相同的JDK版本和目录路径。因为后面很多配置项比如JAVA_HOME都是写在配置文件里的如果各节点路径不一致后续在Cloudera Manager里做任何涉及JVM的操作都很容易出错。3. 从零到一的部署流程Cloudera Manager安装全记录3.1 节点基础配置部署前要在每个节点上做统一的用户和目录准备。CDH的安装过程会用到cloudera-scm用户这个用户是安装包自动创建的但也有一些目录需要提前准备好并设置好属主。比如/data下的数据盘挂载点如果你计划把HDFS的数据目录放在这里就要提前创建目录并且把属主改成cloudera-scm或者后续在Cloudera Manager配置时手动指定。我习惯的步骤是先确认所有节点的hostname已经设置好然后统一写入/etc/hosts把所有节点的IP和主机名映射都加上。这一步的意义在于CDH的集群内部通讯大量依赖主机名而不是IP如果你不提前配置好后面一定会遇到“无法解析主机名”之类的报错。然后是为集群节点配置SSH免密登录。虽然Cloudera Manager的安装向导支持你通过输入密码来部署Agent但如果你打算在安装后经常通过命令行维护集群免密登录会大幅提升效率。我通常会用ssh-keygen生成密钥然后通过ssh-copy-id分发到每个节点。3.2 搭建Cloudera Manager运行环境CDH部署的第一步是安装Cloudera Manager Server和Agent。官方提供了两种方式一种是通过repository方式在线安装另一种是准备离线安装包。我建议在能确保网络稳定且内网有软件源的情况下用在线方式没有把握就准备离线包。安装Cloudera Manager核心包的顺序是先装Server包再在所有节点上装Agent包。Server和Agent之间的通讯走的是7180端口HTTP和7182端口Server和Agent的通讯端口我在前面关闭防火墙之后这里就不需要额外放行了。选好安装路径之后Cloudera Manager Server会要求初始化它自带的Embedded PostgreSQL数据库。这个数据库是Cloudera Manager的活动管理库用于存放集群的监控数据、配置数据、主机列表等。小规模集群用自带的Embedded PostgreSQL完全没问题但当集群规模超过几十台、监控数据量上来之后我更建议使用独立部署的PostgreSQL或MySQL。不过这是后话在刚开始搭建时自带数据库足够用了。数据库初始化之后就可以启动Cloudera Manager Server。启动完成后浏览器访问http://server-ip:7180第一次访问时向导会让你登录默认账号密码是admin/admin。进入到主界面之后就能看到“添加集群”的引导流程。3.3 通过Web向导完成集群搭建这个引导流程是整个部署过程中最繁琐、也最容易出问题的一段。向导会要求你指定需要加入集群的主机列表提供一个具有免密登录权限的SSH账号然后它会自动把Cloudera Manager Agent分发到各台主机上并启动。Agent分发完成后你需要选择CDH的版本。这里会有几个不同的CDH版本可选选你提前下载好的那个版本就好。然后向导会把CDH的parcel包分发到所有主机并解压激活。这一过程耗时跟网络带宽和机器数量强相关一台机器可能要等十几分钟几十台机器拉长到一两个小时都不奇怪耐心等待即可。激活之后是“为集群添加服务”的环节。这里最核心的一组操作是你需要在向导里指定哪些主机运行HDFS的NameNode哪些主机运行YARN的ResourceManager哪些主机做DataNode和NodeManager。Cloudera Manager会基于你选的角色分配自动生成默认配置包含各角色的内存分配、存储目录、端口绑定等。默认配置可以直接用但我强烈建议在每个服务添加完成后点进对应的服务配置页对照你的硬件资源把关键参数调一遍不要直接点“继续”。所有组件安装完成后Cloudera Manager会进入一个安装检查的环节比如检查各主机的权限、目录可用性、内核参数是否合适。这个检查报告要仔细看里面报出来的每一条问题后面都会成为集群运行的不稳定因素。4. 服务组件应该如何选HDFS、YARN、Hive与其它4.1 核心组件按需选择第一次搭建CDH集群的时候最容易犯的一个错误是把所有能选的组件全部装上去。Cloudera Manager的服务列表里有HDFS、YARN、Hive、HBase、Spark、Kafka、Flume、Sqoop、ZooKeeper、Oozie、Hue等等看起来每个都值得装但每多装一个组件就意味着你的集群里多了一批需要维护的进程、多了一套监控项、多了一组潜在故障类型。我的建议是第一步只装核心组件——ZooKeeper、HDFS、YARN、Hive。ZooKeeper是很多组件的基础协调服务HDFS是存储底座YARN是计算调度Hive让你能用SQL的方式做数据分析。这四个组件构成了一个大数
