3、技术选型与环境搭建：Hadoop生态选型（HDFS/YARN）、MPP数据库选型（ClickHouse/Doris）、资源规划与集群部署
好，咱们进入第三章。这一章说白了就是“选家伙事儿”和“搭台子”。
做储能数据仓库，最怕什么？最怕数据量一上来，查询慢得像蜗牛，或者集群动不动就崩。我见过不少团队，上来就搞一套特别重的技术栈，结果运维成本高得吓人，业务还没跑起来，先把自己累死了。
所以，技术选型一定要务实。咱们的目标是：够用、稳定、好维护。
3.1 Hadoop生态选型：HDFS与YARN
先聊聊Hadoop。很多人觉得Hadoop过时了，其实不然。在储能场景下，HDFS依然是存储海量历史数据（比如电芯全生命周期数据、秒级采样数据）最靠谱的选择之一。
3.1.1 HDFS：存储的基石
我个人习惯，把HDFS当作“冷热数据”的冷备层。热数据放ClickHouse，温数据放HDFS，冷数据归档到对象存储。
为什么选HDFS？
- 吞吐量高：适合大文件顺序读写。储能数据大多是时序的，写入模式很友好。
- 容错性强：默认三副本，不用担心磁盘坏道。我在项目里遇到过硬盘集体报警，HDFS自动恢复数据，愣是没丢一条记录。
- 生态成熟：Spark、Flink、Hive都能直接读HDFS，集成成本低。
避坑指南：我曾经犯过一个错，把大量小文件（比如几KB的日志）直接丢进HDFS。结果NameNode内存爆了，因为每个文件都要在内存里维护元数据。后来我养成了习惯，小文件先合并成大文件（比如按小时合并），再写入HDFS。
3.1.2 YARN：资源调度器
YARN的作用，说白了就是管好集群里的CPU和内存。你想想看，如果Spark任务和MapReduce任务抢资源，谁也别想跑好。
在储能场景下，我建议这样配置YARN：
- 内存分配：给操作系统预留20%内存，剩下的给YARN。比如物理机128G内存，YARN可用约100G。
- CPU虚拟核数（vcore）：一般按物理核数的1.5~2倍配置。比如16核物理机，配置24~32个vcore。
- 调度策略：用Fair Scheduler（公平调度器）。避免一个任务占着茅坑不拉屎，其他任务饿死。
spark.dynamicAllocation.enabled=true。这样任务会根据数据量自动调整executor数量，省资源。
3.2 MPP数据库选型：ClickHouse vs Doris
这是大家最纠结的地方。ClickHouse和Doris都是优秀的MPP数据库，但侧重点不同。我两个都用过，说说我的感受。
3.2.1 ClickHouse：极致查询速度
ClickHouse的强项是单表查询和聚合分析。如果你要查“过去24小时，某型号电芯的电压平均值”，ClickHouse能在毫秒级返回。
适用场景：
- 时序数据聚合（储能最典型的需求）
- 大宽表查询（比如把几百个传感器字段拼成一张表）
- 日志分析
需要注意的地方：
- ClickHouse的多表JOIN性能一般。我建议尽量用大宽表，或者把JOIN逻辑放到应用层。
- 它不支持事务。如果你需要严格的数据一致性（比如金融级），ClickHouse不太合适。但储能场景下，大部分是分析型查询，问题不大。
toYYYYMMDD(timestamp)），排序键用（device_id, timestamp）。这样查询时能快速跳过无关分区。
3.2.2 Doris：全能型选手
Doris的优势在于高并发和多表关联。如果你需要支持几百个用户同时跑报表，或者做复杂的OLAP分析，Doris更合适。
适用场景：
- 实时报表（比如储能电站的运营大屏）
- 多表JOIN查询（比如关联设备表、告警表、运维表）
- 数据更新频繁的场景（Doris支持部分列更新）
需要注意的地方：
- Doris的导入性能不如ClickHouse。大批量数据导入时，建议用Stream Load分批导入。
- 它的存储压缩率比ClickHouse略低，磁盘占用会多一些。
3.2.3 选型对比表
| 维度 | ClickHouse | Doris |
|---|---|---|
| 单表查询速度 | 极快（毫秒级） | 快（秒级） |
| 多表JOIN | 一般 | 优秀 |
| 高并发 | 一般（适合低并发） | 优秀（支持高并发） |
| 数据更新 | 不支持（需重建分区） | 支持（部分列更新） |
| 存储压缩率 | 高（约5-10倍） | 中（约3-5倍） |
| 运维复杂度 | 低 | 中 |
我的建议：如果团队小、场景简单，优先选ClickHouse。如果业务复杂、并发高，选Doris。当然，也可以两个都用——ClickHouse做实时聚合，Doris做报表查询。
3.3 资源规划与集群部署
选好技术栈，接下来就是搭集群。资源规划做不好，后面全是坑。
3.3.1 硬件选型
我一般按这个标准来：
- CPU：建议用Intel Xeon或AMD EPYC，核心数32核起步。ClickHouse和Doris都吃CPU。
- 内存：至少128GB。ClickHouse的MergeTree引擎很吃内存，尤其是做GROUP BY时。
- 磁盘：用NVMe SSD。别省这个钱，机械盘在大量数据写入时根本扛不住。容量按数据量的3倍预留（算上副本和冗余）。
- 网络：万兆网卡。数据shuffle和副本同步都靠网络，千兆网卡会成为瓶颈。
3.3.2 集群规模估算
假设每天新增100GB数据，保留90天，三副本：
- 总存储需求：100GB × 90天 × 3副本 = 27TB
- 单节点可用容量：假设每台机器4块2TB SSD，RAID10后可用4TB
- 节点数：27TB ÷ 4TB ≈ 7台
再加上20%的冗余，建议部署9台。嗯，这个规模对于中型储能项目来说，基本够用。
3.3.3 部署架构图
下面这张图，是我常用的部署架构。你看一眼就明白了：
这张图里，数据从BMS等系统流入Kafka，Flink做实时ETL后，分别写入ClickHouse（实时查询）和HDFS（冷备）。Doris则从HDFS或ClickHouse拉取数据，做复杂的报表分析。各层职责清晰，互不干扰。
3.3.4 部署步骤（简化版）
这里我给出一个最小化部署的步骤，适合测试环境：
# 1. 安装Hadoop（HDFS + YARN）
wget https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz
tar -xzf hadoop-3.3.6.tar.gz
# 配置 core-site.xml, hdfs-site.xml, yarn-site.xml
# 启动
./sbin/start-dfs.sh
./sbin/start-yarn.sh
# 2. 安装ClickHouse
sudo apt-get install clickhouse-server clickhouse-client
sudo systemctl start clickhouse-server
# 3. 安装Doris（FE + BE）
# 下载并解压 Doris 二进制包
# 启动 FE
./fe/bin/start_fe.sh --daemon
# 启动 BE
./be/bin/start_be.sh --daemon
嗯，生产环境建议用Ansible或SaltStack做自动化部署，别手动一台台配，容易出错。
3.4 本章小结
这一章内容不少，我帮你捋一下重点：
- HDFS：存冷数据，注意小文件问题。
- YARN：管资源，用Fair Scheduler避免任务饿死。
- ClickHouse：单表查询快，适合时序聚合。
- Doris：多表JOIN强，适合报表分析。
- 资源规划：CPU、内存、磁盘、网络，一个都不能少。
技术选型没有银弹。说白了，你得根据自己团队的能力和业务特点来选。别盲目追新，稳定压倒一切。