关于大数据:Apache-Pulsar-在火山引擎-EMR-的集成与场景

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群

近年来，基于云原生架构的新一代音讯队列和流解决引擎 Apache Pulsar 在大数据畛域施展着愈发重要的作用，其利用场景和客户案例也在一直地丰盛与裁减。

火山引擎是字节跳动的企业服务品牌，次要面向 To B 业务场景。火山引擎中 Stateless 云原生开源大数据平台 E-MapReduce（简称 EMR）为用户提供了云上的端到端的大数据解决方案。与此同时，Apache Pulsar 的一个非常重要的个性也是云原生。

先进的存算拆散的架构使其非常适合在云化的环境中部署、运维，而 Topic 数据的存储形式也使其扩容操作大为简化，不须要数据的 rebalance 过程。于是，将 Pulsar 集成到火山引擎 EMR 的生态系统中便是一件瓜熟蒂落且极具价值的事件。

本文介绍火山引擎 EMR 中 Apache Pulsar 的集成状况和利用场景，依照如下构造来编排：

• 业务背景
• 详解 Apache Pulsar 在 EMR 的集成计划
• Apache Pulsar 典型利用场景、问题与解法
• 火山引擎 EMR 集成 Pulsar 的将来布局

一、业务背景

火山引擎是字节跳动旗下的云服务平台，将字节跳动疾速倒退过程中积攒的增长办法、技术能力和工具凋谢给内部企业，提供云根底、视频与内容散发、数智平台 VeDI、人工智能、开发与运维等服务，帮忙企业在数字化降级中实现持续增长。

火山引擎 EMR 是火山引擎数据中台产品体系的基座。数据中台是火山引擎中的一类重要产品，服务于用户的大数据体系，撑持用户构建端到端的数据链路。火山引擎数据中台产品体系如下图所示。

数据中台的大数据生产、服务体系，数据来源于交易系统、日志、IoT、音讯、文件等，通过数据集成进入到数据湖中，而后通过数据开发、治理过程，进入到专题集市，最初通过数据分析平台提供给数据的最终用户，包含 BI 报表、离线剖析、实时剖析、即席查问、数据挖掘等。以上是用户搭建大数据体系的一条残缺的数据链路。

在这条数据链路上的各个环节都有火山引擎数据中台的产品来对接。火山引擎 EMR 产品在数据中台整个的产品体系全景图中，处于基座的地位（如上图中黄色框所示），对于用户构建端到端的数据链路起着重要的撑持作用。火山引擎 EMR 基于火山引擎的 IaaS 能力，提供底层根底的大数据体系的计算引擎和存储引擎，并向上对接数据开发治理工具 DataLeap。

如果用一句话来定义火山引擎 EMR 这个云产品，那就是“Stateless 云原生开源大数据平台”。

用户能够在 EMR 产品中创立本人的集群，并应用 EMR 集群中配置好的服务，进行大数据的计算与存储。这里重点剖析一下火山引擎 EMR 产品定义中的几个关键词。云原生、开源、大数据平台这些概念置信都是读者们耳熟能详的。云原生是指云上资源的池化、用户的弹性按需应用、资源的老本摊薄和利用率晋升等。开源大数据平台则是 EMR 这类云产品的共有定义。

接下来重点讲一下 Stateless 这个概念。Stateless 指的是“无状态”。在 EMR 中创立的用户集群的“状态”指的是什么呢？以有状态场景下的 Hadoop 集群类型为例，集群的状态包含用户的 HDFS 中的数据（属于用户的外围数据资产）、Hive Metastore 中的元数据、Ranger 中的权限配置、各个服务的日志、历史作业执行统计信息、集群的配置信息等等。

这些状态信息都是存储在用户集群外部的，是用户集群的一部分。在这样的情景下，用户的集群是一个有状态的（Stateful）集群。在 EMR 的场景下，状态信息无处不在，集群外部蕴含大量状态信息并不稀奇，且这些状态信息的量级较重。然而，用户集群富含状态信息，会给用户带来额定的一些老本和困扰。

例如，如果用户想降级本人的集群版本，或者对本人的集群做一些其余的运维操作（例如服务的启停、执行定制化的运维脚本等），就会有一些顾虑：用户的数据、元数据、配置等信息都在集群外部，在执行集群降级或运维操作的时候，会不会对集群外部的状态信息造成影响。

事实上，如果状态信息内置在用户集群外部，用户在对集群进行运维操作的时候，是须要做认真的评估的，确保运维操作不会对集群外部的状态信息产生预期外的影响。这会给用户对集群的运维操作带来额定的顾虑和老本。

从下面的探讨不难看出有状态的集群会给客户带来一系列痛点问题，而火山引擎的 Stateless 的 EMR 集群则针对以上问题，为用户提供了解决方案。如果咱们把集群的数据、元数据、配置、历史作业信息等状态通过一些计划搁置在用户集群的内部，而在用户集群的外部不再持有状态信息，这样用户的集群就是一个无状态的集群，此时用户如果须要对集群执行降级或者其余运维操作，就不会有“集群状态数据受影响”相干的顾虑了，缩小了运维的危险与老本。

在 Stateless 集群的场景下，用户甚至能够抉择按需去持有集群，即：须要应用计算资源的时候，创立一个集群；不须要应用计算资源的时候，将集群开释。例如如果用户的数据生产 ETL 作业集中在凌晨执行，那么能够在当日的数据生产工作执行前将集群创立进去，而后用这个集群执行一系列的 ETL 作业，而在所有作业都胜利执行实现后，再把这个集群开释掉。

而到第二天凌晨，新一轮的数据生产作业执行之前，再创立出一个集群，待数据生产实现后再开释集群。如此周而复始。这样用户能够只为集群真正被应用的那段时间付费，而在不须要应用集群的时段，用户不须要持有集群，不存在用户持有的资源闲置的问题，用户也就不须要为闲置资源付费。这样能够给用户带来极大的老本优化，并晋升云上资源的利用率。Stateless 的 EMR 集群为这样的应用形式提供了可能。

下面介绍了火山引擎 EMR 的外围定义。针对火山引擎 EMR 的外围性能，进一步开展讲一下，就是提供了企业级的大数据生态组件，例如：Hadoop、Spark、Flink、Hive、Presto、Kafka、ClickHouse、Hudi、Iceberg 等，100% 开源兼容，疾速构建企业级大数据平台，升高运维⻔槛。

火山引擎 EMR 的外围个性包含以下几点：

• 开源兼容 & 凋谢环境： 大数据组件来自开源社区，与开源版本兼容。EMR 提供半托管的环境。EMR 托管在火山引擎的基础设施之上，通过管控面将用户在管制台上的操作传递到用户集群外部。然而这个意义上的托管并不是“全托管”，而是“半托管”——用户有足够的自主性、灵活性，能够登录到本人集群的节点的命令行环境中，执行灵便的运维操作，如脚本执行、软件装置与部署等，以满足用户的个性化需要。也就是说，“半托管”一方面能够通过云托管、白屏化来解决用户理论运维中的痛点问题，升高用户的运维老本，另一方面又不失灵活性，用户能够自主管制本人集群内的节点，有极大的自由度。
• Stateless 云原生湖仓：Stateless 的概念在上文已有详述。火山引擎 EMR 通过存算拆散把集群外部的数据外置到云存储中，如火山引擎对象存储 TOS，不再依赖用户集群外部的 HDFS。此外，通过外置 Hive Metastore、Public History Server、作业管理、配置核心等产品和技术计划，进一步把集群外部的状态信息外置。另外，通过弹性伸缩，反对用户在云上正当地调配资源，实现资源利用的最大化和老本的节约。Stateless 的架构也使得弹性伸缩的扩缩容过程更加轻量化，运维老本和危险得以升高。另外，火山引擎 EMR 也反对 Lakehouse（湖仓）这一近年来衰亡的数据开发理念。
• 引擎企业级优化： 能够分两方面来看。一方面是火山引擎 EMR 针对开源的大数据组件在性能和性能上做了一些加强，后续也会将一些加强回馈社区。另一方面是给引擎减少了一些企业级的个性，例如权限相干的性能。云上便捷运维：复用了云上 EMR 的通用的管控底座能力，各个类型的集群的创立等操作复用 EMR 的公共管控底座。反对按量付费和包年包月的计费模式。反对集群的按需创立和开释。反对集群内服务的操作、参数配置、监控、报警、日志等运维能力。用户在购买 EMR 后能够间接在控制台对接应用这些性能，开箱即用，非常不便。用户能够把大量的运维操作交给云，或者借助云上提供的能力大大降低用户的运维老本。很多本来须要通过命令行和运维流程操作的运维动作，在火山引擎 EMR 中能够通过控制台界面白屏操作。这样用户能够专一于本身的业务逻辑、增长逻辑，而把大数据平台的构建和运维交给云平台。这也是云上的 EMR 产品可能给用户提供的外围价值之一。

下图为火山引擎 EMR 的性能架构图。

火山引擎 EMR 建构在火山引擎的基础设施底座上，由火山引擎提供云服务器、公网 IP、云存储、VPC 等基础设施。在基础设施底座上，建构出数据存储引擎（如 HDFS、CloudFS、表格局等）、数据调度引擎（如 YARN 等）、各种面向不同场景的大数据计算、存储组件以及贯通整个 EMR 服务端到端的管控面。EMR 向上能够对接火山引擎的大数据研发治理套件 DataLeap，反对用户构建数据仓库，赋能百行百业，助力企业决策，帮忙业务成长，体现数据价值。

从 EMR-1.3.0 版本开始，火山引擎 EMR 反对 Pulsar 集群类型的创立。上面咱们来具体看一下火山引擎 EMR 集成 Apache Pulsar 的状况。

二、Apache Pulsar 在 EMR 的集成计划

本节内容重点探讨 Apache Pulsar 集成火山引擎 EMR 的起因和计划。

火山引擎 EMR 是一个云上的大数据平台，笼罩大数据开发畛域各个场景，包含离线计算、实时计算以及存储、数据调度、工具链等。

除此之外，还有一类组件不可或缺的，即音讯队列，至多有两类不同的场景依赖音讯队列：

• 第一个场景是数据摄入（Data Ingestion），即从业务零碎（也就是整个大数据体系的内部）把源头数据接入到大数据体系中，波及到一个数据从业务零碎向大数据体系传输的过程。
• 以客户端埋点日志为例，埋点日志被上报到音讯队列，该音讯队列为大数据链路的第一站。从该音讯队列开始，数据会持续向上游的离线 Hive 表或者实时数仓的上游音讯队列流动。在此场景下，作为整个大数据体系的源头，音讯队列连通业务零碎和数据仓库，将大数据体系里面的数据上报到音讯队列后，音讯队列作为一个沟通的纽带，音讯会流向上游的数据仓库的各层存储中，进入大数据体系外部。
• 不光是埋点日志信息，用户的业务数据库的信息，也能够通过把数据库 binlog 上报到音讯队列，由计算工作生产音讯队列中的 binlog 并把数据写入上游表，实现业务数据库的数据向数仓的同步，在数仓中重建出业务库的正本。
• 此外，像监控、日志类型的数据也能够上报到音讯队列，再通过音讯队列将对应的数据传导到大数据体系的外部。

第二个典型利用场景是实时数仓。

• 数据接入到数据仓库后，能够持续通过 ETL 过程构建离线表，也能够构建实时数据链路，应用实时处理逻辑将数据写到上游的音讯队列中，而这个音讯队列能够再进入下一级的实时处理逻辑，或做 mapping，或做聚合，进入到下一级的音讯队列中。
• 以上音讯队列相当于实时数仓的实时表，寄存 ODS、DWD、DWS、ADS 等层级的实时数仓数据。在这里，是应用音讯队列作为实时数仓各层数据的存储。
• 在最终数据利用的时候，依据利用场景的理论须要和查问特点，能够将实时数仓音讯队列中的数据导出到像 Redis 这样的 K-V 存储中，或者像 StarRocks、Doris、ClickHouse 这样的 OLAP 引擎中。
• 实时数仓的数据链路的中间层依赖音讯队列的，因为实时数据的解决次要是流解决，而音讯队列的存储与计算模式与流解决的模式是人造符合的。

从下面的探讨能够看出，音讯队列至多在数据接入和实时数仓中间层两个大数据体系的场景中扮演着不可或缺的作用，因而是大数据体系离不开的一类组件。所以火山引擎 EMR 将音讯队列集成进来也就成为了一件瓜熟蒂落的很天然的事件了。

而在音讯队列畛域中，近年来倒退迅速、体现优异、备受关注的一个佼佼者便是 Apache Pulsar。以上是咱们抉择将 Apache Pulsar 集成到火山引擎 EMR 的原动力之一。

当然除了这一点之外，还有以下的一些其余的起因。让咱们来看一下 Apache Pulsar 的根本状况，以及一些外围的个性和劣势。正是这些个性和劣势，促成了咱们将 Apache Pulsar 集成到火山引擎 EMR 中，并置信这样做会给用户带来很大的价值。

Apache Pulsar 是一个开源的基于公布 / 订阅模式的分布式、云原生、多租户的高性能音讯与流平台，提供音讯队列和计算服务，解决服务器间的音讯传输与队列问题。

Pulsar 具备很多令人瞩目的个性和劣势，上面选取了其中的一部分，次要是与把 Pulsar 集成到 EMR 最相干的一些要害因素。正是这些要害因素，使得咱们置信把 Pulsar 集成到火山引擎 EMR 中确定会给用户带来很大的价值。

这些要害因素列举如下：

• 弹性： 反对用户无感知的动静扩缩容，提供更好的弹性，为用户节俭硬件老本，更好地符合了云上产品的特色。这是云上产品的根底个性，也是一个产品想要上云所须要具备的个性，可能给客户带来上云的理论价值。
• 云原生： 采纳先进的云原生架构，将有状态的存储与无状态的计算拆散在不同的架构层级中，非常适合在云化的基础设施中部署、应用和运维。这个也是被大家经常提到的 Pulsar 的外围个性，无论是基于 Kubernetes 部署，还是通过 Bare metal / ECS 部署，都能够利用到存算拆散的架构特点，更好地利用云上资源池化、弹性的特点，实现更好的云原生。
• 易扩容： 存算拆散以及数据的扩散存储的架构特点极大缩小了用户对计算或存储能力进行扩容时的老本与危险，用户能够对计算或存储节点别离扩容，特地是在扩容的时候不须要做沉重的数据迁徙、rebalance，对系统的可用性、稳定性、可运维性和运维老本优化大有裨益。这也是大家津津有味的 Pulsar 的一个十分令人瞩目的优良特色。
• 与用户既有零碎（如 Kafka）兼容： 通过 KoP (Kafka on Pulsar)，提供与 Kafka 的在应用层面上的兼容性，便于用户间接复用已有的基于 Kafka 的代码体验 Pulsar 的个性。这一点也是十分重要的，可能带来很大的用户价值。Kafka 也是十分风行且在业内被宽泛应用的一个音讯队列组件，用户可能也会有很多基于 Kafka 开发的业务代码。如果用户心愿把这些业务代码在 Pulsar 下面进行试用与体验，那么如果 Pulsar 与用户既有的一些零碎（如 Kafka）兼容，就能够零老本或者低成本地把既有的业务代码放到 Pulsar 上来体验，更易于用户去体验 Pulsar 的各种令人瞩目的个性和性能。这一点对用户的价值很大。假如 Pulsar 没有提供与 Kafka 协定的兼容性，那么如果用户想体验 Pulsar，把既有的一些代码放到 Pulsar 下面试用、体验，可能须要对既有业务代码做一些批改、适配和迁徙，这些工作也是有老本的，且迁徙工作可能给用户在业务层面带来的价值无限，只是相当于在技术实现层面把代码进行了零碎之间的迁徙和适配，然而会给用户带来一些痛点和运维老本。所以如果可能做到和用户既有零碎的兼容，能够帮用户省去一些很沉重的迁徙工作，会带来很大的用户价值。

基于以上这几点，Pulsar 能够很好地为客户提供价值、增值，这也促成 Pulsar 集成到火山引擎 EMR 中。上面针对上文中提到的 Pulsar 的云原生架构和易扩容的个性，再开展讲一下技术细节。Pulsar 的云原生架构，如下图所示：

具体来讲，有以下几点因素：

• 计算和存储拆散，音讯数据存储在 BookKeeper 的 Bookie 中，由 Broker 提供服务。
• Broker 节点和 Bookie 节点可别离运维、扩缩容。
• 反对数据 offload 到云上的对象存储。

此外，Pulsar Client 与 Pulsar Broker 进行对接。ZooKeeper 节点与 Broker、Bookie 交互，解决元数据以及分布式系统中的协调。Pulsar 的另一个重要个性是易扩容。

Pulsar Topic 数据的存储模式使得节点扩容时不须要 rebalance。这个的起因是 Pulsar 采纳了 Topic – Ledger – Fragment – Entry 的多级构造来存储 Topic 的音讯数据。

如下图所示：

一个 Topic 下会有多个 Ledger，一个 Ledger 上面会有一个或多个 Fragment，每一个 Fragment 上面会有多条音讯（多个 Entry）。每个 Fragment 的理论数据的存储地位是在一组 Bookie 下面，不同的 Fragment 对应的 Bookie 的汇合都是不一样的。

这样的一个构造使得每一个 Topic 的音讯人造散布在不同的 Bookie 节点中，而不同的 Fragment 的数据存储在不同的 Bookie 汇合中。如果用户扩容一个新的 Bookie 节点，只须要把 Topic 的新的 Ledger / Fragment 的数据写入新 Bookie。

旧 Bookie 的数据不必 rebalance。Pulsar 中的 Topic 和具体的存储节点并没有耦合、绑定。假如一个 Topic 的数据绑定在某一个固定的存储节点上，那么如果单纯地扩容存储节点，且如果 Topic 的数量不变，那么新的存储节点是不会有 Topic 的数据写进去的。

为了让新扩容进去的存储节点可能被利用到，可能被写入 Topic 的数据，就须要更改一部分 Topic 与存储节点的绑定关系，这样就波及到了数据的搬迁，即 rebalance。

而 Pulsar 不存在这个问题，因为 Pulsar 人造就是一个 Topic 的数据扩散在不同的 Bookie 节点中存储，所以在新扩容出一个 Bookie 节点后，一个 Topic 中的新的数据是能够写入到新的 Bookie 节点中的，新的 Bookie 节点也不必放心没有数据写进去。

而 Topic 中的一些历史存量数据依然寄存在原来的中央，不必做存量数据的搬迁、rebalance。这样的话，对于用户来说，在扩容时的运维老本、危险和复杂性都大大降低了。这是 Pulsar 给客户提供的外围价值之一。

相比于其余音讯队列组件，Pulsar 也提供了一些差异化价值。上面这张表比照了 Pulsar 与 Kafka 的局部个性。

综上所述，基于以上的一些状况，促成了咱们把 Pulsar 集成到火山引擎 EMR 中。这样做能够给用户、Pulsar 和火山引擎 EMR 三方都带来收益，是一个“多赢”的场面。

给用户带来价值：

• 将 Pulsar 的泛滥令人瞩目的个性更便捷地提供给用户，在火山引擎 EMR 中一键创立 Pulsar 集群后“开箱即用”。
• 不便用户在云原生环境下扩容音讯队列，复用云上 EMR 的管控能力，升高大数据体系的应用和运维老本。
• 不便用户将 Pulsar 与火山引擎生态的其余的一些服务（例如 DataLeap 大数据开发、治理）交融起来，构建大数据端到端的全链路。

给 Pulsar 带来价值

• 将 Pulsar 融入到火山引擎 EMR 生态中，与大数据生态系统中的其余组件更不便地交互。
• Pulsar 集群与其余类型的 EMR 集群（如 Hadoop、Flink）位于同一个 VPC 内，网络互通，缩小网络买通的老本。
• 复用 EMR 通用的管控能力。
• 间接为 Pulsar 集群提供扩展性和弹性，按需付费。疾速、系统化对接服务的配置、启停、扩容等操作。
• 与火山引擎丰盛的产品线交融，例如大数据研发治理套件 DataLeap。

为火山引擎 EMR 带来价值

• 提供云原生、运维成本低的大数据根底组件。EMR 中须要集成音讯队列组件，而 Pulsar 是其中的佼佼者。
• 裁减火山引擎 EMR 的场景和整体生态的端到端能力，加强实时流数据处理能力，形成用户数据链路中的重要一环。

接下来的几张截图展现了火山引擎 EMR 中创立和应用 Pulsar 集群类型的场景。从 EMR-1.3.0 版本起，用户能够创立类型为 Pulsar 的集群：

蕴含 BookKeeper、Pulsar、ZooKeeper 服务，用户能够白屏化运维，例如服务的启停、服务的根本信息查看等：

用户能够在控制台对 Pulsar 的参数进行配置：

用户能够在控制台查看 Pulsar 运行时的监控数据、服务日志和操作日志：

在本节的最初，次要介绍 Pulsar 集成到火山引擎 EMR 的计划。次要步骤如下：

1. 镜像制作与手动拉起：将 Pulsar 安装包集成进 EMR 镜像，建设一个既有类型的 EMR 集群，手动部署 / 运行 ZooKeeper, BookKeeper, Pulsar (Broker)。
2. 自动化部署代码编写：将手动部署的逻辑转化为集群内的 Agent 调用的自动化部署代码，并思考异常情况解决。
3. 管控服务端：管控服务端配置元数据，以在控制台减少 Pulsar 集群类型相干内容，并驱动管控通用底座调用上一步编写好的自动化部署代码。
4. 参数：Pulsar 参数反对用户可配置 / 零碎动静生成。
5. 监控、告警、日志的对接。下图为零碎整体的控制流。管控服务端会和用户集群外部的 Agent 交互，把管控的操作命令下发到集群中去，在集群中执行具体的运维操作。如集群、服务的启停、参数的配置等。

在集成 Pulsar 的整个过程中，也遇到过一些问题。这些问题最终都通过排查以及查阅社区材料等做法得以解决。以上面这个问题为例：

Pulsar Broker 在自动化启动时报错：

ERROR org.apache.pulsar.broker.PulsarService - Failed to start Pulsar service:
org.apache.pulsar.metadata.api.MetadataStoreException$BadVersionException:
org.apache.zookeeper.KeeperException$BadVersionException: KeeperErrorCode = BadVersion for /counters/producer-name

问题排查：通过查阅社区材料，社区曾经遇到过并已解决该问题。在多个 Pulsar Broker 同时启动的时候会呈现这个问题。

• 短期解决方案：Pulsar Broker 启动时减少重试机制。
• 长期解决方案： 目前 Pulsar 社区针对此问题的修复已合入，后续思考降级 EMR 集成的 Pulsar 版本。

下面咱们对火山引擎 EMR 集成 Apache Pulsar 的状况进行了概要介绍。
上面咱们来看一下火山引擎 EMR 中的 Pulsar 的一些典型利用场景。

三、利用场景：实时数仓与批流一体

本节将简要介绍火山引擎 EMR 集成 Apache Pulsar 的两个典型利用场景：实时数仓与批流一体。Pulsar 和火山引擎 EMR 中的其余一些组件能够相互配合，共同完成场景问题的解决，施展价值、发挥作用。

实时数仓

首先看一个典型的、简化的实时数仓场景：给定业务库中全量商品的订单表，统计截止到以后的各个商品的订单总量。

这外面有两点须要留神：

• 订单表中有订单状态，在统计订单量的时候须要过滤掉有效订单。
• 订单状态随时可能发生变化。

下面两点给实时数仓的开发带来了很大的复杂性。源头的业务库中的数据可变，在实时流解决的时候须要思考到这种变动，并对实时计算结果进行调整。

输入输出样例如下图所示：

上图右边是业务库中订单粒度的原始表，咱们冀望聚合成左边的以商品为粒度的商品总订单数的统计表。另外，为了不影响线上业务，不容许间接查问线上业务库失去后果，须要以业务库为数据源建设数据仓库来反对数据分析需要。

当然，有很多成熟的计划能够解决这个问题。例如经典的 Lambda 架构，其核心思想是分为离线和实时两条链路：离线链路计算历史数据，实时链路计算当日数据。最初把历史数据和当日数据 merge 起来。如下图所示：

Lambda 架构是比拟成熟的计划，但也存在一些问题，如下：

• 同时保护离线、实时链路，链路简单，资源耗费大，保护老本高。
• 对于局部订单状态发生变化的状况，难以很好解决。例如历史订单在当日（今日）产生了生效，状态从无效变为了有效，这时解决起来会有一些复杂性，须要思考对离线历史数据的实时调整。
• 离线计算和实时计算结果须要 merge，须要准确把握工夫点，离线和实时的计算结果的工夫范畴须要做到不重、不漏。
• 对于须要从多个源表获取数据，且多个源表的字段值有可能发生变化的状况，则更为简单。这里限于篇幅，不开展讲了。感兴趣的读者能够结构一些状况来推演一下相干的解决逻辑，会发现外面的确会有许多简单的状况，波及到流 join、数据的生产程序等。能够梳理一下其中遇到的问题。

除了 Lambda 架构，还有另一个计划基于 upsert 离线表（如 Hudi 表）的计算。其核心思想是在 Hudi 表中近实时同步业务库中的数据（通过生产 binlog 数据），在 Hudi 表（相当于一个订单粒度的近实时表）的根底上，每隔一段时间（如 15 分钟）依照离线链路聚合数据的形式全量计算一次聚合后果，并将生成的后果同步到 OLAP 引擎中供查问。

聚合计算的源头 Hudi 表是近实时更新的，聚合计算过程是近实时触发的，因而 OLAP 引擎中的后果表的时效性也是近实时的。这个计划的数据处理链路如下图所示：

这个计划的一个益处是，复用离线数据开发的逻辑到 Hudi 表的近实时全量计算逻辑中，以较低的老本来实现近实时的统计分析，但也会有一些问题，列举如下：

• 须要较高频率的离线全量计算，耗费计算资源。
• 对离线存储资源仍有耗费。
• 不是纯实时（秒级）更新，而是一个近实时的过程。

针对以上实时数仓的场景，Pulsar 具备解决方案。具体来说，线上业务库的订单表输入 binlog 到 Pulsar 音讯队列中。这个音讯队列有全量的数据，其中冷数据能够 offload 到对象存储中。接下来能够应用 Pulsar SQL 每 15 分钟针对 Pulsar 中的全量数据计算一次聚合后果，并将计算结果写入 OLAP 引擎中供查问。

这个计划相似于下面提到的 Hudi 计划，不同之处在于利用了 Pulsar SQL，相当于能够间接去查问音讯队列中存储的数据。

整个计算链路如下图所示：

益处是：

• 能够利用 Pulsar 的分级存储个性，将冷数据写入对象存储。Pulsar 音讯队列的存储，既能够作为两头数据的存储，也能够作为离线 ODS 层数据的存储，节俭存储资源，链路简化。
• Pulsar 的分级存储和 Pulsar SQL 等个性使得间接在音讯队列存储中做计算成为可能，进而简化数据处理链路。

通过下面的探讨，咱们看到了在火山引擎 EMR 中，能够将其中的一些大数据组件和 Pulsar 联合起来应用，解决实时数仓开发中的一些问题。

批流一体

埋点日志数据存在实时处理和离线解决的需要：

• 离线链路：用于天级报表、离线训练数据等场景。
• 实时链路：用于实时剖析、举荐等场景。

一个经典计划，相似于上文提到的 Lambda 架构，须要保护离线和实时两套数据链路，如下图所示：

这样的计划在施行上比拟成熟，然而占用资源较多，保护老本较高。

而基于 Pulsar 也能够有一类计划，聚焦在实时链路。埋点日志数据上报到 Pulsar 中，用实时工作去写上游的 DWD 和 DWS 层（到 Pulsar 中）。整个 Pulsar 的实时链路也反对数据 offload 到对象存储。数据也能够间接写到 OLAP 层。

如果有离线数据计算的需要，能够用 Pulsar SQL 间接对接 Pulsar 中存储的数据。整个数据链路如下图所示：

• 基于 Pulsar 的分级存储和 Pulsar SQL 等个性，能够间接把 Pulsar 中的数据作为离线链路的 ODS 层。
• Pulsar 的上游能够间接对接实时处理逻辑。
• 若基于 Pulsar 中的原始日志数据，建设实时数仓，实时计算 ODS 层数据生成 DWD 层数据到 Pulsar topic 中，则 Pulsar topic 中的 DWD 层数据能够同时间接用于后续的离线计算和实时处理。
• DWS 层同理。

以上列举了实时数仓和批流一体中的一些典型场景和可能遇到的问题，以及应用火山引擎 EMR 中的 Pulsar 和其余组件的可能的解决思路。在本文的下一节，咱们将简要介绍一下火山引擎 EMR 集成 Apache Pulsar 的将来布局。

四、将来布局

目前火山引擎 EMR 已将 Apache Pulsar 集成进来，用户能够在火山引擎 EMR 中创立、应用、运维 Pulsar 集群。对于这部分工作将来的布局，次要分为以下几局部。

首先，咱们会进一步摸索云原生方向，在云原生的背景下把火山引擎 EMR 与 Pulsar 集成地更好，例如与 Kubernetes、火山引擎对象存储的联合等。

与此同时，咱们也心愿在以后的 Pulsar 的集成工作的根底上，对 Pulsar 引擎自身有更多的奉献，参加到社区开发中，为 Pulsar 奉献性能和代码。

当然，咱们也会继续把火山引擎 EMR 上的 Pulsar 做得更好用，包含但不限于以下几点：

• 减少高可用模式，3 个 Master 节点且独立部署 ZooKeeper。
• 更多周边组件的集成。
• 更加顺滑的端到端应用体验和最佳实际。
• 与火山引擎 EMR 的其余服务，以及火山引擎其余产品更好的集成，例如 EMR Flink 集群类型、大数据研发治理套件 DataLeap 等。
• 参数、性能调优等。

结语

本文介绍了火山引擎 EMR，以及咱们将 Apache Pulsar 集成到火山引擎 EMR 的起因和办法，同时介绍了 Pulsar 的一些令人瞩目的优良个性，并探讨了实时数仓和批流一体的一些典型场景、其中可能存在的痛点问题以及应用火山引擎 EMR 中的 Pulsar 联合其余组件的可能的解决方案。

最初咱们还瞻望了火山引擎 EMR 集成 Apache Pulsar 这部分工作的一些将来布局。咱们会继续致力，提供更好的云上大数据产品与服务，将火山引擎 EMR 的大数据生态与 Pulsar 的卓越能力更好地联合起来并互相赋能，发明更大的价值，笼罩更多的业务场景，更好地服务用户。

点击跳转 云原生开源大数据平台 EMR 理解更多