剑指大数据：企业级数据仓库项目实战（金融租赁版）读书笔记__大数据测试集群的服务器节点服务分配规划表__解读（附：技术选型清单）

本文展示了一个由3台服务器（hadoop102/103/104）组成的大数据测试集群服务部署方案。

核心架构特点包括：

角色分工明确：hadoop102作为主控节点（部署NameNode、MySQL等16项服务），hadoop103专管资源调度（含ResourceManager），hadoop104承担辅助功能（如SecondaryNameNode）；

关键分布式服务（DataNode、ZooKeeper等）采用三节点部署确保基础功能；

采用非高可用模式（单NameNode/RM），适合测试环境；

服务总数显示hadoop102负载最重（16个），hadoop103最轻（10个）。该规划实现了从数据采集（Maxwell/Kafka）、处理（Spark/Hive）到可视化（FineBI）的完整测试链路。

关联阅读推荐

金融租赁行业数据的特点是不存在用户行为日志数据，即不会产生用户点击数据-CSDN博客

数仓系统的主要流程

测试服务器规划

|------------------|----------- | 测试服务器规划 | 服务名称 | HDFS | NameNode | | DataNode | | SecondaryNameNode | YARN | NodeManager | | ResourceManager | ZooKeeper | ZooKeeper Server | Maxwell | Maxwell | Kafaka | Kafaka | Flume | Flume | DataX | DataX | Hive | Hive | Spark | Spark | MySQL | MySQL | FineBI | FineBI | DolphinScheduler | MasterServer | | WorkerServer | | LoggerServer | | ApiApplicationServer | | AlertServer | 服务数总计 | -----------|---------------------|---------------------|---------------------|
|||||
| 子服务 | 节点服务器 hadoop102 | 节点服务器 hadoop103 | 节点服务器 hadoop104 |
| √ | | |
| √ | √ | √ |
| | | √ |
| √ | √ | √ |
| | √ | |
| √ | √ | √ |
| √ | | |
| √ | √ | √ |
| | | √ |
| √ | √ | √ |
| √ | √ | √ |
| √ | √ | √ |
| √ | | |
| √ | | |
| √ | | |
| √ | √ | √ |
| √ | √ | √ |
| √ | | |
| √ | | |
| 16 | 10 | 11 |

思考：

理解用户的请求：

用户提供了一个名为"测试服务器规划"的表格。

表格包含三列节点服务器：hadoop102、hadoop103、hadoop104。

行项列出各种大数据服务/组件（HDFS、YARN、ZooKeeper、Maxwell、Kafka、Flume、DataX、Hive、Spark、MySQL、FineBI、DolphinScheduler）。

每行中的"√"表示该服务安装/运行在该特定节点上。

底部有一个"服务数总计"行：hadoop102 为 16，hadoop103 为 10，hadoop104 为 11。

用户问："这是什么意思？"

分析数据：

这是大数据集群的典型硬件/软件部署架构图 或节点角色分配表。

共有3台机器（hadoop102、103、104），形成了一个小型大数据集群（通常是高可用性（HA）或分布式设置）。

HDFS：NameNode 在 102 上（单点，或非HA模式下的主节点）。DataNode 在所有节点上。SecondaryNameNode 在 104 上（辅助检查点，非备用节点，表明这是非HA的HDFS）。

YARN：ResourceManager 在 103 上（主节点）。NodeManager 在所有节点上。

ZooKeeper：在所有3个节点上（通常需要奇数个节点，3个正常，以实现HA协调）。

Kafka：在所有3个节点上（分布式消息队列）。

DataX/Hive/Spark：在所有节点上（通常是客户端安装或计算节点）。

MySQL：仅在 102 上（存储Hive元数据或FineBI后端数据库）。

FineBI：仅在 102 上（BI工具服务器）。

DolphinScheduler：分布在所有节点上，但Master/API/Alert服务集中在 102 上，Worker/Logger在 102、103、104 上。

总计：计数与标记匹配。102有16个服务，103有10个，104有11个。

确定用户想要什么：

他们不是问如何优化，也不是在修复错误。他们问的是"这是什么意思？"

这需要对表格进行解码，解释整体集群架构，阐明每个组件的作用，解释为什么某些服务放在特定的节点上（资源分配、HA考虑），并总结这对测试环境意味着什么。

起草回复结构：

直接回答 ：明确说明这是大数据测试集群的节点角色与组件部署规划表（即，哪个服务安装在哪台机器上）。

总体架构分析（解释"为什么"）：

102节点：重负载节点（主控节点）。包含大部分管理角色（NameNode、MasterServer、MySQL、FineBI）。资源消耗高。

103节点：资源管理器节点（YARN RM）。承担资源调度。

104节点：辅助节点（SecondaryNameNode、Flume）。

通用节点：DataNode、NodeManager、ZooKeeper、Kafka、Hive、Spark在各处，实现分布式存储/计算。

关键设计洞察（根据计数情况）：

非HA配置（注意：单NameNode，单RM，SecondaryNameNode不是备用节点）。适用于测试，不适用于生产高可用性。

分布式基础：Zookeeper和Kafka在3个节点上满足奇数仲裁要求。

计算分布：Spark/Hive/DataX在所有节点上，充分利用资源执行任务。

总结：以通俗语言总结此测试环境的用途（供开发人员调试、压力测试、验证ETL任务）。

起草过程中的自我修正/细化：

修正：SecondaryNameNode在104上。在非HA Hadoop中，SNN执行合并，但不提供故障转移。因此，如果102宕机，HDFS将关闭（除非手动恢复）。这在测试环境中没问题，但生产环境需要HA（通常有2个NN）。

102上的MySQL：很可能存储Hive元数据（Metastore）和FineBI的内部库。

DolphinScheduler分布：Master在102上，但Worker/Logger在所有节点上。这是典型的DS设置。

服务计数 ：统计一下：102有（HDFS NN, DN, NMs? 等等，我重新数一下）。

102：NameNode(1), DataNode(2), NodeManager(3), ZooKeeper(4), Maxwell(5), Kafka(6), DataX(7), Hive(8), Spark(9), MySQL(10), FineBI(11), Dolphin Master(12), Dolphin Worker(13), Dolphin Logger(14), Dolphin API(15), Dolphin Alert(16)。正确，16。

103：DataNode(1), NodeManager(2), ResourceManager(3), ZooKeeper(4), Kafka(5), DataX(6), Hive(7), Spark(8), Dolphin Worker(9), Dolphin Logger(10)。总计10。

104：DataNode(1), NodeManager(2), SecondaryNameNode(3), ZooKeeper(4), Kafka(5), Flume(6), DataX(7), Hive(8), Spark(9), Dolphin Worker(10), Dolphin Logger(11)。总计11。

全部匹配。

这是一张大数据测试集群的服务器节点服务分配规划表 。简单来说，就是告诉你在 hadoop102、hadoop103、hadoop104 这三台机器上，分别需要安装和启动哪些大数据组件。

通俗地讲，这三台机器组成了一个小型的大数据全家桶，用于开发测试、跑通流程。

我帮你从架构视角拆解一下这张表，你就明白为什么要这么分配了：

1. 节点角色定位（谁在干什么？）

hadoop102（重负载/主控节点） ：安装了最多的服务（16个）。它是集群的"总司令 "，承担了 HDFS 的 NameNode（目录管家） 、DolphinScheduler 的 Master（调度总管） 、MySQL（元数据数据库） 和 FineBI（报表展示）。所有的调度命令和元数据存储都压在这台机器上。
hadoop103（资源调度中心） ：主要承担了 YARN 的 ResourceManager（资源分配官），负责统一调度CPU和内存资源给任务跑。
hadoop104（辅助/日志收集） ：承担了 HDFS 的 SecondaryNameNode（辅助管家） 和 Flume（日志采集），主要负责协助主节点合并数据或收集日志。

2. 分布式服务的常规套路（为什么这么放？）

高可用与数据冗余（三台都有） ：DataNode（存储）、NodeManager（计算）、ZooKeeper（协调）、Kafka（消息） 这三项服务在 102、103、104 上都打了勾。这是因为大数据集群默认需要多台机器共同工作来存储数据块（HDFS）和计算任务（YARN），而 Zookeeper 和 Kafka 要求必须部署在奇数台（3台）机器上才能正常进行选举和主备切换。
计算引擎全覆盖 ：Hive（数仓工具） 和 Spark（计算引擎） 在3台机器上都部署了，这意味着你的 SQL 任务可以在任何一台机器上提交并执行。

3. 这张表告诉你的关键信息（测试环境的特点）

非高可用（非HA）模式 ：注意，NameNode 只在 102 上有一台，ResourceManager 只在 103 上有一台。这说明你们的测试环境没有配置主备切换。如果 102 或 103 宕机，整个集群的任务就会停摆（这在测试环境是允许的，节约资源）。
数据流转链路清晰 ：这张表还隐含了一条数据流向：外部数据 → Maxwell(102) → Kafka(三台) → Flume(104) → HDFS(三台) → Hive/Spark(三台) → DataX(三台导出) → MySQL(102) → FineBI(102展示)。

4. 什么叫"服务数总计"？

底部统计的是每台机器上打了多少个"√"。

hadoop102 承担了最多的管理角色，所以有 16 个。
hadoop104 负责辅助和日志，有 11 个。
hadoop103 相对轻量，有 10 个。

总结一句话 ：

你们有一组由3台Linux服务器搭建的测试大数据平台，其中 102是"大脑"（主控+存储），103是"管家"（资源调度），104是"助手"（辅助+日志），三者共同协作，用来跑通数据抽取、清洗、计算和报表展示的完整流程。

如果你要在这上面跑任务（比如刚才我们讨论的合同表 ETL），建议把 SQL 提交到 hadoop102 或 103 上执行，因为这两台装着关键的管理组件。需要我针对这张表，告诉你怎么登陆对应的机器执行命令吗？

大数据测试集群的"技术选型清单"

产品及其版本号（JDK 1.8.0, Hadoop 3.3.4, Flume 1.10.1, Maxwell 1.29.2, ZooKeeper 3.7.1, Kafka 3.3.1, MySQL 8.0.31, DataX 3.0, Hive 3.1.3, Spark 3.3.1, DolphinScheduler 2.0.5, FineBI 6.0）

兼容性检查

Hadoop 3.3.4 ↔ Hive 3.1.3（官方支持，但Hive 3.1.3是针对Hadoop 3.x编译的，没问题）。
Hadoop 3.3.4 ↔ Spark 3.3.1（Spark 3.3.1支持Hadoop 3.3.x，没问题）。
Kafka 3.3.1 ↔ ZooKeeper 3.7.1（注意！Kafka 3.3.1仍然需要ZooKeeper，但它也支持KRaft。这里他们使用ZooKeeper，可以兼容）。
Hive 3.1.3 ↔ Spark 3.3.1（Hive on Spark需要特定的Spark版本。Hive 3.1.3与Spark 3.3.x兼容，但默认需要重新编译或特定配置。这是一个关键点）。
MySQL 8.0.31 ↔ Hive 3.1.3（Hive需要MySQL JDBC驱动，需要支持MySQL 8的驱动）。
DolphinScheduler 2.0.5 ↔ JDK 1.8（DS 2.0.5支持JDK 8，没问题）。
FineBI 6.0（较新，支持JDK 8）。

一句话总结 ：这是上述测试集群的详细版本清单，整体选型是中度偏新、主流成熟、相互兼容的。

兼容性深度分析（重点）：

总体兼容性：和谐，没有大坑。

关键耦合点1：Spark与Hive（易踩坑点）。指出Hive 3.1.3与Spark 3.3.1集成需要额外依赖。

关键耦合点2：Kafka与ZooKeeper。注意他们用ZK模式（3.3.1仍支持），还没切换到KRaft。

关键耦合点3：MySQL 8.0与Hive。需要特定的JDBC驱动，不能使用旧版。

大数据测试集群的"技术选型清单"，列出了每一款组件具体使用的版本号。结合你之前提供的服务器规划表（hadoop102-104），这张清单意味着你们即将（或正在）搭建这套环境。

我对这张选型表做一个深度分析 ，包括兼容性评估 、版本特征 以及潜在的"坑"，方便你做技术评审或后续排错：

1. 整体评估：成熟稳定，生态兼容

评分：⭐⭐⭐⭐（推荐）
结论：这是一套2023-2024年主流的、中等偏新的开源大数据技术栈。所有组件版本都较为成熟，彼此之间有官方或社区验证的兼容性，非常适合企业级离线数仓和轻度实时计算。

2. 关键组件版本亮点（为什么选这些？）

JDK 1.8（Java 8） ：虽然较老，但这是大数据生态的"工业标准"。Hadoop/Spark 对 JDK 11/17 的支持尚在完善中，生产环境选 1.8 是最稳的，能避免 90% 的底层兼容报错。
Hadoop 3.3.4 ：相比旧的 2.x，它支持 EC（纠删码） ，能节省存储空间；且支持了 hdfs disk balancer。这是 3.x 系列里比较稳的版本。
Hive 3.1.3 + Spark 3.3.1 ：这是目前离线数仓的黄金组合 。Hive 3.1.3 支持 INSERT OVERWRITE 的动态分区优化，且默认支持 Spark 作为计算引擎（弃用了老旧的 MR），计算速度会比 MapReduce 快 10 倍以上。
DolphinScheduler 2.0.5：非常新的调度工具，界面美观，支持云原生。2.0 版本重构了架构，修复了 1.x 版本中任务频繁卡死的问题。
MySQL 8.0.31 ：用于存储 Hive 元数据（Metastore）和 DolphinScheduler 的业务数据。8.0 比 5.7 性能更强，但要注意时区和编码设置。

3. ⚠️ 需要特别留意的"兼容性雷区"（必看）

虽然选型版本都对，但有几个极易踩坑的配置点，部署前一定要检查：

组件组合	潜在风险	解决方案
Hive 3.1.3 + Spark 3.3.1	最大陷阱：Hive 3.1.3 自带的 `spark-assembly` 包与 Spark 3.3.1 不兼容。如果直接使用 Hive on Spark，会报 `NoSuchMethodError`。	需要下载 Spark 3.3.1 源码，重新编译 `spark-hive-thriftserver` 包，或者将 Hive 端的 `spark-submit` 路径软链指向你安装的 Spark 目录，并用 `spark.sql.hive.metastore.version` 指定版本。
Kafka 3.3.1 + ZK 3.7.1	注意：Kafka 3.3.1 依然强依赖 Zookeeper 管理 Broker 元数据。虽然 Kafka 3.x 已支持 KRaft（去ZK模式），但3.3.1 的 KRaft 还是预览版，绝不能在生产测试中关闭 ZK。你们在 hadoop102-104 部署 ZK 是完全正确的。
MySQL 8.0.31 + Hive	Hive 3.1.3 默认自带的 JDBC 驱动是 MySQL 5.x 的。直接连接 MySQL 8 会报 `Public Key Retrieval` 或 `SSL` 错误。	必须把 Hive 的 `lib` 目录下旧的 `mysql-connector-java-5.x.jar` 删除，换成 `mysql-connector-java-8.0.31.jar`，并在 JDBC 连接串后加 `?useSSL=false&serverTimezone=Asia/Shanghai`。

4. 硬件与性能的"隐忧"（结合你的服务器规划）

结合你上一张表（只有 3 台虚拟机 hadoop102-104），这套软件选型在 资源上其实是"紧巴巴" 的，有几个需要注意的地方：

内存开销极大 ：Hadoop 3.x 的 DataNode 默认堆内存、Spark 3.x 的 spark.driver.memory、DolphinScheduler 的 Master 服务，这三样加起来会消耗大量内存。
- 建议：部署时，将 Spark 的 spark.executor.memory 适当调低（如 1G-2G），不然你这 3 台机器跑任务时极易触发 OOM（内存溢出）导致 NodeManager 被 YARN 杀死。
NameNode（仅 hadoop102）单点 ：测试环境没问题。但注意，Hadoop 3.x 的 NameNode 默认会开启 NameNode Federation 特性，如果误开了，单节点负担会很重。

5. 版本选型的"权衡"：为什么没用更新的？

没选 Flink 1.17/1.18 ：你们用了 Spark 3.3.1 ，这表明你们的主要场景是微批处理（准实时）和 T+1 离线数仓，而不是纯粹的流计算。Spark 3.3.1 在结构化流（Structured Streaming）上已经很成熟。
没选 Hadoop 3.3.6：3.3.4 相比于 3.3.6 虽然旧，但业界对 3.3.4 的稳定性评价最好（3.3.5/3.3.6 修复了部分漏洞但也引入过小 bug）。

💡 给你的下一步行动建议

既然版本清单和服务器规划都有了，你在部署启动 DolphinScheduler 调度 Hive/Spark 任务前，先做一件事：

登录 hadoop102，检查 $HIVE_HOME/lib 下有没有 mysql-connector-java-8.0.31.jar。
测试 spark-submit --version 和 hive --service metastore 能否独立拉起。

如果部署时报错（大概率是上面提到的 MySQL 和 Spark 包问题），随时把报错日志发我，我教你改配置。另外，你们这套环境里没有列数据治理工具（如 Atlas） ，如果后续想在合同表（DWS层）做字段血缘追溯，这个版本选型是可以后期再加的。