本文主要面向在火山引擎 EMR on ECS 中使用数据湖集群的架构师或平台运维团队。EMR 数据湖集群是支持开源&开放、Stateless 云原生湖仓、引擎企业级优化、云上便捷运维等核心能力的解决方案,可应用于云原生数据湖仓、实时数仓、离线 ETL 数据分析、交互式查询等场景,帮助用户解决数据存储与计算的资源规划问题,综合考虑业务需求、数据规模、成本约束等因素,确保集群资源合理分配和高效利用。
业务场景
业务场景 | 支持的组件 | 核心能力 | 应用场景 |
|---|
数据湖集群 | 计算引擎:Spark、Hive、Tez、Kyuubi、Trino、Presto 数据存储:HDFS/TOS、Proton、Celeborn 数据集成:Sqoop 数据湖格式:Hudi、Iceberg、Paimon 资源管理:Yarn 分布式协调服务:ZooKeeper 安全与权限:OpenLDAP、Ranger、MIT Kerberos | - 开源&开放
- Stateless 云原生湖仓
- 引擎企业级优化
- 云上便捷运维
| 云原生数据湖仓、实时数仓、离线 ETL 数据分析、交互式查询等 |
方案架构
EMR 支持存算分离和存算一体两种架构,在做资源规划前,用户需根据公司实际业务场景、运维、成本等维度选择相对应的架构。
对比维度 | 存算分离 | 存算一体 |
|---|
技术特点 | - 计算与存储资源独立扩展,数据持久化存储在 TOS 中,结合火山 EMR 团队自研的加速引擎 Proton 使用
- 完全兼容 HDFS 接口,便于无缝迁移和使用
| - 计算与存储混合部署,数据存储在集群内部的 HDFS 中
|
适用场景 | | |
数据可靠性 | - TOS 支持多 AZ 冗余存储,提供了跨可用区的高可靠性保障
- 由对象存储底层保障,数据丢失风险极低
| - 依赖副本机制,局限于集群内部,缺乏跨 AZ 容灾能力
- 存在一定的数据丢失风险,如磁盘硬件故障等
|
数据持久性 | - 提供 99.9999999999%(12 个 9)的数据持久性
- 集群被释放后数据仍可长期保留
| |
运维复杂度 | - 存储容量无限扩展,无需因数据增长手动调整集群规模。
| - DataNode 故障时需手动执行数据重平衡
- 存储容量变化时,Core 节点扩容和缩容时需人工调整集群规模
|
存储成本 | | 1 元/GiB/月(标准数据云盘) 关于云盘的计费项,请参见云盘计费。
|
存储资源规划
存储配置
在 EMR 集群中 ECS 实例节点上有系统盘和数据盘两种角色的磁盘。
磁盘角色 | 磁盘描述 | 支持的磁盘类型 |
|---|
系统盘 | 系统盘用于安装操作系统,不保存业务数据。 | - 云盘
- 极速型 SSD FlexPL
- 极速型 SSD PL0
- 吞吐型 SSD TL0
|
数据盘 | 数据盘用于存储数据、本地化日志、任务的 Shuffle 等,其容量需根据存储架构(存算一体/存算分离)差异化评估,详情参见下文存储容量评估。 说明 存储容量相同时,多盘配置比单盘更能提升组件可用性。部分组件在多盘环境下具备容错能力,即使个别磁盘故障,也不会影响整体功能。 | - 云盘
- 极速型 SSD FlexPL
- 极速型 SSD PL0
- 吞吐型 SSD TL0
- 本地盘(特定机型)
|
磁盘类型
磁盘类型的应用场景如下所示:
类别 | 类型 | 应用场景 |
|---|
云盘 | 极速型 SSD FlexPL | - 特点:高吞吐量、高 IOPS、低时延,支持配置额外性能,性能和容量可以分开购买,资源配置更灵活。
- 应用场景:适用于大型数据库、NewSQL 数据库等 I/O 密集型业务场景。
|
极速型 SSD PL0 | - 特点:均衡的 IOPS 和吞吐量、低时延,价格均衡。
- 应用场景:适用于对 IO 性能有一定要求的场景,例如中小型数据库等。
|
吞吐型 SSD TL0 | - 特点:高吞吐量,中等 IOPS,时延不敏感,支持配置额外吞吐量,最大支持 1000MB/s 的吞吐量。
- 应用场景:适用于对带宽要求高,时延不敏感的场景,例如大数据离线业务、AI 大模型训练、大量日志数据批量处理、传输高清视频或流媒体内容等。
|
本地盘 | NVME SSD 本地盘 | - 特点:高 IOPS、大吞吐、低访问延迟。
- 应用场景:I/O 密集型应用且同时具备应用层高可用架构的业务场景,如关系数据库、NoSQL、ElasticSearch 等。
|
SATA HDD 本地盘 | - 特点:大容量、高吞吐 HDD 本地盘,价格低廉;
- 应用场景:适用于海量数据存储和离线计算的大数据型业务,例如 EMR 等大数据处理业务,本身对延迟不敏感,且上层有数据冗余,可以容忍单点数据故障。
|
存储容量评估
说明
存算分离场景下 TOS 对象存储容量可无限扩展,无需提前特别规划集群存储容量。
提前收集和确认集群中数据保留策略信息,包括:
- 存量数据规模
- 每日数据增量
- 增量数据保留时长(天)
- 每日数据处理规模
架构 | 数据盘容量规则 |
|---|
存算分离 | - TOS 对象存储容量可无限扩展,只需规划临时存储的容量,临时存储主要包含:日志文件、任务运行临时文件、任务 shuffle 数据等;
- 临时存储预留容量通常为每日数据处理规模- 50% (根据业务需求调整,业务峰值并发越高预留越多)。
|
存算一体 | - 需要综合考虑存量数据、增量数据、增量数据保留天数、HDFS 副本数、临时存储占比、存储水位阈值等因素;
- 存储水位是存储最多占据总磁盘容量的比例,通常对数据盘设置 70% – 80% 的使用上限阈值,以保留增长与故障恢复空间;
- 磁盘总容量计算公式如下:
总磁盘容量 = (存量数据规模 + 每日数据增量 * 增量数据保留时长) * HDFS 副本数 * (1 + 临时存储占比)/存储水位阈值
|
计算资源规划
节点角色配置
集群节点分为 Master、Core、Task 三类角色,功能、可选机型与推荐规格不同,需按需配置:
节点角色 | 角色说明 | 可选机型 | 推荐机型/规格 |
|---|
Master | - 负责管理集群和协调任务运行;
- 部署服务如: Namenode、ResourceManager、HiveServer2、HiveMetastore、ZooKeeper、PrestoCoordinator 等。
| | - 根据需要选取适用的实例规格,不同机型区分详见云服务器实例规格介绍。
- 常规建议:
- 小型集群(≤ 8 台实例):16 核 64 GiB
- 中大型集群:≥ 32 核 128 GiB
- 在存算一体架构下,当 HDFS 文件数量超大(≥ 1000 万)时,需要满足 NameNode 的内存需求。NameNode 内存规划参考:HDFS 内存规划。
|
Core | - 负责集群数据存储,提供计算能力和存储资源。
- 部署服务: DataNode、NodeManager、PrestoWorker 等。
| - 计算型
- 通用型
- 内存型
- 大数据型
- 本地 SSD 型
- 网络增强型
- GPU 计算型
| - 根据需要选取适用的实例规格,不同机型区分详见云服务器实例规格介绍。
- 常规建议:
- 根据 Yarn 任务的 CPU 与内存需求比例选择机型:
- 默认场景:通用型实例。
- CPU 密集型任务(如 AI 推理训练):计算型实例。
- 内存密集型任务(如离线报表分析):内存型实例。
- 根据 HDFS 存储需求(> 10 TB/节点):大数据型实例。
说明 单节点 Yarn NodeManager 容器上限以节点内存的 75% - 85% 为宜,以便为堆外内存与 PageCache 保留空间。 |
Task | - 负责调整集群的算力、补充 Core 节点在 CPU 和内存需求的不足,不存储数据
- 部署服务:NodeManager、PrestoWorker 等。
| - 计算型
- 通用型
- 内存型
- 大数据型
- 本地 SSD 型
- 网络增强型
- GPU 计算型
| 计算资源峰谷场景建议: - 固定 Task 节点规格按资源低谷计算需求配置。
- 配置弹性 Task 节点规格来应对峰值需求,功能介绍参见弹性伸缩。
|
计算容量评估
核心是 “覆盖并发任务资源需求 + 预留系统资源”,步骤如下:
- 提前收集信息:
单个跑批任务资源量:平均单个跑批任务 CPU 和内存资源使用量,如:常规 Spark 任务为 1 个 Driver + 2 个 Executor 资源总量为 4C16G * 3 = 12C 48G ;
- 流式任务数:每天运行的流式任务数;
- 单个流式任务资源量:平均单个流式任务 CPU 和内存资源使用量,如:常规 Flink 任务为 1 个 JobManager + 2 个 TaskManager 资源总量为 4C16G * 3 = 12C 48G ;
- 资源预留水位:为操作系统、服务进程等预留 20% 左右的资源;
- 总计算资源容量计算,公式如下:
总计算资源容量 = (并发跑批任务数 * 单个跑批任务资源量 + 流式任务数 * 单个流式任务资源量 ) * (1 + 资源预留水位)
HDFS 内存规划
HDFS 核心组件的 JVM 内存直接影响集群稳定性,需按文件 / 块数量精准计算:
组件 | 内存计算规则 | 示例 |
|---|
NameNode JVM | 建议值 =(文件数(单位:百万) + 块数(单位:百万)) × 512MB | 有 1000 万个文件,都是中小文件且不超过 1 个 Block,Blocks 数量也为 1000 万,则内存建议值:
(10+10)×512MB=10240MB(10GiB) |
DataNode JVM | - 先算单 DataNode 平均副本数:Replicas = 块数 ×3 ÷ DataNode 节点数
- 建议值 = Replicas(单位:百万) × 2048MB
| 大数据机型为 3 副本,Core 节点数量为 6,如果您有 1000 万个文件且都是中小文件,Blocks 数量也为 1000 万,则单个 DataNode 副本数 Replicas=1000 万 ×3÷6=500 万;
建议值 = 5×2048MB=10240MB(10GiB)。 |
NameNode JVM 建议值
文件数量 | 建议值(MB) |
|---|
10,000,000 | 10240 |
20,000,000 | 20480 |
50,000,000 | 51200 |
100,000,000 | 102400 |
DataNode JVM 建议值
单个 DataNode 实例平均 Replicas 数量 | 建议值(MB) |
|---|
1,000,000 | 2048 |
2,000,000 | 4096 |
5,000,000 | 10240 |