2、环境搭建与配置：操作系统依赖、Python/Java环境、Docker化部署、资源规划
说实话，环境搭建这事儿，看着简单，但坑最多。我见过太多流水线跑着跑着挂了，最后发现是底层依赖版本不对。这一章，咱们就把这些基础打扎实。
2.1 操作系统依赖：选对系统，少走弯路
数据流水线对操作系统有硬性要求。我个人习惯用 CentOS 7.9+ 或 Ubuntu 20.04 LTS。为什么？因为生态成熟，踩过的坑网上都有答案。
核心依赖清单
- glibc：版本必须 ≥ 2.17，否则很多二进制包跑不起来。
- OpenSSL：1.1.1 以上，用于加密通信。
- libffi：Python 扩展编译需要它。
- zlib-devel / libbz2：数据压缩必备。
- curl / wget：下载工具，别用太老的版本。
我在项目中遇到过一个问题：某次部署 Spark 集群，所有节点都装好了，结果任务一提交就报 libc.so.6: version GLIBC_2.18 not found。查了半天，发现是某台机器的 CentOS 6 没升级。嗯，从那以后我养成了一个习惯——先跑一遍 ldd --version 检查 glibc。
避坑指南
我曾经因为系统时区没统一，导致流水线的时间戳全乱了。建议在每台机器上执行：
timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp yes别小看这一步，数据对不齐的时候你就知道痛了。
2.2 Python 环境：版本隔离是王道
Python 环境是流水线的核心。你想想看，一个项目用 Python 3.8，另一个用 3.10，混在一起就是灾难。
我的标准做法：
- 安装 pyenv 管理多版本 Python。
- 每个项目创建独立的 virtualenv 或 conda 环境。
- 锁定依赖版本，用
pip freeze > requirements.txt生成清单。
注意
千万别用系统自带的 Python 跑生产流水线。我曾经图省事，直接在 /usr/bin/python3 上装包，结果系统工具升级时把依赖搞坏了，流水线停了整整半天。
举个例子，一个典型的 requirements.txt 长这样：
pandas==1.5.3
numpy==1.24.3
apache-airflow==2.7.1
psycopg2-binary==2.9.6
redis==4.5.4版本号写死，别用 >=。为什么？因为上游库一更新，你的流水线可能就炸了。
2.3 Java 环境：版本兼容性要命
Java 环境主要伺候 Hadoop、Spark、Flink 这些大家伙。版本选不对，直接跑不起来。
| 框架 | 推荐 Java 版本 | 说明 |
|---|---|---|
| Hadoop 3.x | Java 8 或 11 | Java 8 最稳，Java 11 有性能提升 |
| Spark 3.x | Java 8 或 11 | Java 17 部分功能不兼容 |
| Flink 1.17+ | Java 11 | Java 8 已停止支持 |
| Kafka 3.x | Java 11 或 17 | Java 8 勉强能用，但不推荐 |
我个人习惯用 OpenJDK 11 作为默认版本。为什么？因为它在兼容性和性能之间平衡得最好。安装时记得设置 JAVA_HOME 环境变量：
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
export PATH=$JAVA_HOME/bin:$PATH然后检查一下：java -version 输出是不是你想要的版本。
小技巧
我建议用 alternatives 命令管理多版本 Java。这样切换版本只需要一条命令，不用改环境变量。
sudo alternatives --config java2.4 Docker 化部署：一次构建，到处跑
Docker 是解决环境不一致的终极方案。说白了，就是把你的流水线连同所有依赖打包成一个镜像，到哪都能跑。
我的 Dockerfile 模板：
FROM python:3.9-slim
WORKDIR /app
# 安装系统依赖
RUN apt-get update && apt-get install -y \
gcc \
libpq-dev \
&& rm -rf /var/lib/apt/lists/*
# 复制依赖文件
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 复制应用代码
COPY . .
CMD ["python", "main.py"]注意几点：
- 用 slim 版本基础镜像，体积小，攻击面少。
- 合并
RUN命令，减少镜像层数。 - 最后复制代码，利用 Docker 缓存加速构建。
重要提醒
我曾经在生产环境用 latest 标签，结果某次拉取镜像时版本变了，流水线直接挂了。从那以后，我强制要求所有镜像使用 具体版本号 标签，比如 my-pipeline:v1.2.3。
2.5 资源规划：别让流水线饿死
资源规划是门学问。给多了浪费钱，给少了流水线跑不动。我一般按以下原则来：
| 组件 | CPU 建议 | 内存建议 | 磁盘建议 |
|---|---|---|---|
| Airflow Scheduler | 2-4 核 | 4-8 GB | 50 GB SSD |
| Spark Executor | 4-8 核 | 8-32 GB | 100 GB SSD |
| Kafka Broker | 4-8 核 | 16-32 GB | 500 GB SSD |
| PostgreSQL | 2-4 核 | 4-16 GB | 200 GB SSD |
你想想看，如果给 Spark Executor 只配 2GB 内存，处理 100GB 数据时肯定 OOM。我建议先按这个基准配置，然后根据实际负载调整。
资源规划三步走
- 估算峰值负载：流水线同时跑多少个任务？每个任务吃多少资源？
- 预留 20% 余量：别把资源用满，留点缓冲应对突发流量。
- 监控并调整：用 Prometheus + Grafana 看实际使用率，按需扩缩容。
下面这张图展示了整个环境搭建的流程和依赖关系：
环境搭建这事儿，说白了就是打好地基。地基不稳，上面盖的楼再漂亮也得塌。我见过太多团队在环境上省事，结果后期花几倍的时间去排查问题。嗯，希望你能一次就把这些基础做扎实。