- 元宇宙：本站分享元宇宙相关资讯，资讯仅代表作者观点与平台立场无关,仅供参考.
朴朴数据平台基础技术架构简图
朴朴云上主体业务数据流转简图
EMR 在朴朴云上大数据平台担任计算单元角色，数据计算完毕后经由服务通道输出给业务平台 (平台架构图最顶层部分)，核心计算场景有：离线、实时、查询，三者比例约为 7:2:1。至于云上主体业务数据流转链路，我们使用 Apache Hudi 作为数据湖仓支撑基石，目前是以离线 + 实时双线同步链路方式支持数据入湖。湖仓架构是一种灵活的架构设计模式，本文篇幅有限，后续有机会笔者单开一篇进行论述。
我司近七成为离线计算，所支撑的业务场景繁杂多样：业务数据入湖仓 ETL、算法、数据报表、数据分析、仓储配送等，这些离线任务我们内部按照对业务影响程度制定了相关故障等级标准，达到核心故障级别的有：
业务库数据入湖仓主链路作为所有数据使用的保障基石，重要程度自然不言而喻
我司在算法域应用大体可分为：预测、推荐、规划三大类，部分算法任务的输出已嵌入业务流程中，典型如自动订补货、仓储商品调度配送等
对公司经营业务产生影响的数据报表，如：收益类、营销类、用户类、商品库存平衡等
目前我司实时计算平台，已上线实时计算任务有 200+，场景涵盖：业务数据实时入湖仓 ETL、算法、数据报表、门店大屏等，与离线计算所不同的是实时计算要求响应时效性更高，基本等同于朴朴主体业务 (A/C 端) 响应速度，随着业务场景不断深化，会逐步按需提升实时计算任务。
查询计算平台基于 presto 封装实现，目前在我司应用场景涉及：BI 平台、即席式交互、跨源融合查询，因云上虚拟机自建 Clickhouse，其存储瓶颈较明显且成本又高，因此引入 Presto 实现跨源融合查询以支持 BI 平台查询湖仓 Hudi 明细表，如此一来湖仓中的数据可无需再同步至 Clickhouse，降低明细表数据传输及落地存储至 Clickhouse 过程开销。
除此之外，数据平台团队已在规划、开发实现统一查询服务平台，该平台上线后会提供如下功能：
支持统一的 HiveSQL 语法 & 虚拟表查询。
支持异步查询和任务优先级调度。
支持 spark、presto、flink 等查询引擎。
支持查询路由及负载均衡。
多数据源融合查询。
开篇伊始，先简单了解下 EMR 集群单元架构。
AWS 官网介绍 EMR 部署模式有：EC2、EKS、Outposts、Serverless 这几种，后两者目前尚未在国内上线，而当前阶段 EMR On EKS 模式有使用场景限制 (仅支持 Spark 应用)，待之后具体调研使用后再作评论，本文着重于 EMR On EC2 模式进行说明。EMR 集群由三个组类构成：MASTER、CORE、TASK，典型的 EMR 集群实例组架构如下图所示：
在 EMR 集群中 master node 扮演着管理者角色，诸如：
master node| -- zookeeper server| -- hdfs namenode、hdfs journalnode、hdfs zkfc| -- yarn resourcemanager| -- presto coordinator
等服务进程在此节点运行，因此一个集群中至少有一个 master node，若需要 HA 架构，可在部署时选择 Multi master 模式 (3 实例)，然后静待 EMR 集群初始化完毕即可。
以 HDFS 和 YARN 为例，Multi master 架构下 EMR5 集群中两个 namenode 节点以 active/standby 状态工作，resourcemanager 三节点分别以 active/standby/standby 状态工作；而 EMR6 集群中有所不同的是全部 master node 会启动 namenode 进程，并分别以 active/standby/standby 状态工作，间接提高 HDFS 集群可用性。集群中可通过如下命令获取服务进程状态：
//