3、数据湖基础设施搭建：Hadoop集群部署、HDFS高可用配置、YARN资源管理、Kerberos安全认证

说实话，数据湖这个概念这几年被炒得很热。但不管上层怎么包装，底层的根基始终是Hadoop。我做了这么多年金融大数据，见过太多「湖」建到一半就塌了的案例——说白了，都是基础设施没打牢。

这一章，我们就来聊聊怎么把地基夯实。我会把我在银行、证券项目中踩过的坑、总结的经验，都揉碎了讲给你听。

3.1 Hadoop集群部署：别小看这一步

很多人觉得部署Hadoop就是跑个脚本的事。嗯，确实有自动化工具，但金融环境不一样——网络隔离、端口管控、操作系统版本限制，每一样都能让你折腾半天。

我个人习惯，在金融生产环境里，坚决不用单点部署。哪怕只是测试环境，也至少三台机器起步。为什么？因为很多问题在单机模式下根本暴露不出来。

3.1.1 环境准备

先列一下我常用的配置清单：

组件 版本 备注
操作系统 CentOS 7.9 / Rocky Linux 8 金融客户普遍用CentOS，但RHEL系更稳
JDK JDK 8u202 别用太高版本，Hadoop兼容性你懂的
Hadoop 3.3.6 3.x系列，支持EC纠删码
SSH OpenSSH 7.4+ 必须配置免密登录

这里有个坑——时间同步。我在某券商项目里，就因为三台机器时间差了30秒，导致Kerberos认证疯狂报错。排查了两天才找到原因。所以，NTP服务一定要配好。

3.1.2 核心配置文件

部署时，我习惯把配置拆成三块：核心、HDFS、YARN。先看核心配置：

<!-- core-site.xml -->
<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://nameservice1</value>
        <!-- 注意：这里是逻辑名称，不是具体节点 -->
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/data/hadoop/tmp</value>
    </property>
    <property>
        <name>ha.zookeeper.quorum</name>
        <value>node1:2181,node2:2181,node3:2181</value>
    </property>
</configuration>

你想想看，fs.defaultFS 这个配置，如果写成了具体节点IP，那高可用就废了。一定要用逻辑名称，后面通过ZooKeeper去解析。

3.2 HDFS高可用配置：金融系统的命根子

金融数据，丢不得。HDFS的高可用，说白了就是解决NameNode单点故障。我参与过一个银行核心系统的迁移，就因为NameNode挂了，整个批处理停了4个小时——那场面，我这辈子不想经历第二次。

3.2.1 架构设计

HDFS HA的核心思路：Active-Standby模式。两个NameNode，一个干活，一个待命。通过JournalNode同步元数据。

关键组件：

  • Active NameNode：处理所有客户端请求
  • Standby NameNode：实时同步元数据，随时准备接管
  • JournalNode：负责edits日志的共享存储，至少3台
  • ZooKeeper：协调故障切换，监控NameNode状态

我曾经遇到过一个情况：Standby节点同步延迟了2分钟，结果Active挂了之后，Standby拿到的元数据不完整，导致部分文件丢失。后来我们加了个配置——dfs.ha.tail-edits.period 调成1秒，才解决。

3.2.2 配置示例

<!-- hdfs-site.xml -->
<configuration>
    <property>
        <name>dfs.nameservices</name>
        <value>nameservice1</value>
    </property>
    <property>
        <name>dfs.ha.namenodes.nameservice1</name>
        <value>nn1,nn2</value>
    </property>
    <property>
        <name>dfs.namenode.rpc-address.nameservice1.nn1</name>
        <value>node1:8020</value>
    </property>
    <property>
        <name>dfs.namenode.rpc-address.nameservice1.nn2</name>
        <value>node2:8020</value>
    </property>
    <property>
        <name>dfs.namenode.shared.edits.dir</name>
        <value>qjournal://node1:8485;node2:8485;node3:8485/nameservice1</value>
    </property>
    <property>
        <name>dfs.client.failover.proxy.provider.nameservice1</name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>
    <property>
        <name>dfs.ha.automatic-failover.enabled</name>
        <value>true</value>
    </property>
</configuration>

我的经验：JournalNode的磁盘一定要用SSD。edits日志是高频写入，机械盘扛不住。我在一个项目里用SATA盘，结果JournalNode成了整个集群的瓶颈。

3.3 YARN资源管理：别让资源打架

YARN是Hadoop的资源调度层。说白了，就是决定「谁先跑、跑多久、占多少资源」。金融场景下，白天跑实时查询，晚上跑批处理，资源分配不合理的话，两边都干不好。

3.3.1 调度器选择

YARN有三种调度器，我直接说结论：

  • FIFO Scheduler：简单粗暴，先来后到。适合单用户场景，金融环境基本不用。
  • Capacity Scheduler：按队列分配资源。我最常用的，适合多租户场景。
  • Fair Scheduler：按权重公平分配。适合资源动态调整的场景。

在金融项目里，我几乎都用Capacity Scheduler。举个例子：白天给实时查询队列分配60%资源，批处理队列40%；晚上反过来。这样既保证了交易系统的响应速度，又不浪费夜间的计算能力。

3.3.2 内存与CPU配置

这里有个常见的误区——内存配得越大越好。其实不是。YARN的Container有内存开销，配太大反而浪费。

<!-- yarn-site.xml -->
<configuration>
    <property>
        <name>yarn.nodemanager.resource.memory-mb</name>
        <value>65536</value>
        <!-- 每台节点可用内存，留20%给系统 -->
    </property>
    <property>
        <name>yarn.scheduler.minimum-allocation-mb</name>
        <value>1024</value>
    </property>
    <property>
        <name>yarn.scheduler.maximum-allocation-mb</name>
        <value>16384</value>
    </property>
    <property>
        <name>yarn.nodemanager.resource.cpu-vcores</name>
        <value>16</value>
    </property>
</configuration>

注意：CPU虚拟核数不要超过物理核数的2倍。我曾经图省事配了4倍，结果任务切换开销比计算本身还大，性能反而下降了30%。

3.4 Kerberos安全认证：金融合规的硬门槛

金融行业，安全是第一位的。没有Kerberos认证的Hadoop集群，在合规审计面前就是裸奔。我经历过一次银保监会的检查，对方直接问：「你们的Hadoop集群有没有开启Kerberos？」——没有？那不好意思，整改通知单上见。

3.4.1 Kerberos核心概念

Kerberos的原理，我用大白话解释一下：

  • KDC：认证中心，相当于「身份证发放处」
  • Principal：用户或服务的身份标识，类似「身份证号」
  • Ticket：临时通行证，有时效性
  • Keytab：加密的密钥文件，相当于「密码本」

为什么会这么设计？说白了，就是不想让密码在网络里裸奔。每次通信都用临时Ticket，过期就作废。

3.4.2 配置步骤

我总结了一套标准流程：

  1. 安装KDC服务：用yum install krb5-server krb5-libs krb5-workstation
  2. 创建管理员：kadmin.local -q "addprinc root/admin"
  3. 生成服务Principal：为每个Hadoop组件创建Principal
  4. 导出Keytab：kadmin.local -q "xst -k hdfs.keytab hdfs/node1@REALM.COM"
  5. 配置Hadoop：在core-site.xml和hdfs-site.xml中启用认证
# 创建HDFS服务的Principal示例
kadmin.local -q "addprinc -randkey hdfs/node1@EXAMPLE.COM"
kadmin.local -q "addprinc -randkey hdfs/node2@EXAMPLE.COM"
kadmin.local -q "xst -k /etc/security/keytabs/hdfs.keytab hdfs/node1@EXAMPLE.COM"
kadmin.local -q "xst -k /etc/security/keytabs/hdfs.keytab hdfs/node2@EXAMPLE.COM"

避坑指南：我曾经犯过一个低级错误——Keytab文件的权限没设对。HDFS进程用hdfs用户启动，但Keytab文件是root权限，结果认证一直失败。记住：chown hdfs:hdfs /etc/security/keytabs/hdfs.keytab，权限设为400。

3.4.3 日常运维要点

Kerberos上线后，最头疼的是Ticket过期问题。默认Ticket有效期24小时，但金融批处理经常跑超过24小时。我的做法是：

  • 把Ticket最大续期时间设为7天：max_renewable_life = 7d
  • 在crontab里加个定时任务，每天凌晨自动renew Ticket
  • 监控Keytab文件的修改时间，防止被意外覆盖

知识体系总览

下面这张图，是我自己梳理的数据湖基础设施搭建的核心逻辑。你看一眼，心里就有谱了：

数据湖基础设施搭建核心逻辑 Hadoop集群部署 环境准备 → 配置文件 → 启动服务 → 验证集群 HDFS高可用配置 Active NameNode ↔ JournalNode ↔ Standby NameNode YARN资源管理 Capacity Scheduler → 队列划分 → 内存/CPU配置 → 任务调度 Kerberos安全认证 KDC服务 → Principal管理 → Keytab配置 → 认证启用 基础层 高可用层 资源层 安全层

你看，整个体系是层层递进的。集群部署是基础，HDFS高可用保证数据不丢，YARN管好资源别打架，Kerberos守住安全底线。四层都做好了，数据湖才能稳稳地跑起来。

嗯，这一章的内容就到这里。记住：基础设施没有捷径，每一步都要扎实。我在金融行业摸爬滚打这么多年，最大的体会就是——慢就是快。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →