总体思路与架构定位
在 CentOS 上，HDFS 本身并非实时存储，通常与 Kafka 作为高吞吐消息队列、Spark Streaming 或 Flink 作为流处理引擎组合，形成“实时采集 → 实时处理 → 准实时落盘到 HDFS”的链路；如需对单条记录进行实时更新，可在实时层对接 HBase。这一分工既能满足低延迟处理，又能利用 HDFS 的海量存储与批处理能力。
方案一 基于 Spark Streaming 的 Kafka 到 HDFS
- 组件与版本建议：Hadoop 3.x、Kafka 2.8+、Spark 2.4+（示例依赖：spark-streaming-kafka-0-10_2.12 与 hadoop-client）。
- 关键配置与步骤：
- 创建高可用 Kafka 主题（示例：12 分区、3 副本）：
kafka-topics.sh --create --topic order-events-topic --partitions 12 --replication-factor 3 --bootstrap-server kafka-broker1:9092,kafka-broker2:9092
- 生产者可靠性：acks=all、retries=3、compression.type=snappy，提升吞吐与可靠性。
- Spark Streaming 消费并写入 HDFS（按时间分区目录，示例按日分区）：
- 使用 Direct API 订阅 Kafka，关闭自动提交，采用幂等/事务或精准一次语义保障。
- 输出路径示例：/data/kafka_sink/orders/yyyyMMdd，结合滚动策略（按大小/时间）避免小文件过多。
该方案适合日志、埋点、业务事件等场景的“近实时”落盘与后续离线分析。
方案二 基于 Flink 的端到端实时湖仓
- 架构要点：以 Flink CDC 实时捕获变更（如 MySQL binlog），在 Flink 中写入 Iceberg 表（元数据存于 Hive），并通过 Doris 1.1+ 创建 Iceberg 外表进行联邦查询，实现低延迟入湖与统一查询。
- 环境与实践：在 CentOS 7 环境下，可使用 Flink 1.14.4、Iceberg 0.13.2、Hadoop 3.x 等组件组合，Flink 侧引入 iceberg-flink-runtime 与 hadoop 适配包，完成与 HDFS 的打通。
- 适用场景：需要“实时入湖 + 交互式查询 + 统一口径”的业务，如实时数仓分层与即席分析。
方案三 基于 Storm 的实时处理并落盘 HDFS
- 典型链路：Kafka → Storm Topology → HDFS（可在 Storm 中并行做实时计算与落盘）。
- 适用场景：对延迟极敏感、需复杂实时拓扑（如实时聚合、风控、CEP）的业务；Storm 负责实时计算，HDFS 承担持久化与离线分析底座。
- 实践要点：合理划分 Kafka 分区与 Storm 并发度，落盘采用按时间/大小滚动策略，避免 NameNode 与 YARN 压力峰值。
关键配置与优化建议
- 实时性与容错：Kafka 生产端建议 acks=all、retries=3、compression=snappy；流处理端启用 checkpointing、幂等/两阶段提交（2PC）或 exactly-once 语义，保障端到端一致性。
- 小文件治理：按时间（如 yyyyMMdd/HH）与大小滚动输出；在 Spark/Flink 侧做 coalesce/合并；定期运行 Hive/Spark 小文件合并任务。
- 分区与并发：Kafka 分区数与 HDFS DataNode 数成倍数关系；流处理并发度与分区数匹配，避免热点与资源闲置。
- 存储与压缩：列式格式（如 Parquet/ORC）+ Snappy/ZSTD 压缩，提升后续批处理与查询性能。
- 资源与网络：为 YARN 容器与 Kafka 网络预留带宽与内存；HDFS 开启短路读与本地读，降低读写延迟。
- 可观测性：打通 Kafka Lag、处理延迟、落盘速率 与 HDFS 可用性 指标，配置告警与回溯机制。
