关于transform:解读-EventBridge-Transform数据转换和处理的灵活能力

11次阅读

共计 4065 个字符,预计需要花费 11 分钟才能阅读完成。

阿里云 EventBridge 提供了弱小而灵便的事件总线服务,它能够连贯应用程序、阿里云云服务和阿里云 Serverless 服务来疾速构建 EDA(Event-driven Architectures)事件驱动架构,驱动利用与利用,利用与云的连贯。除此之外,它还能够作为流式的数据管道,在不同的数据仓库和数据处理或分析程序之间疾速构建 ETL 零碎。

本文将从以下几个方面开展对阿里云 EventBridge Transform 能力的介绍:

1)首先介绍 ETL 基本概念;

2)接着介绍 T(Transform)的能力;

3)最初探讨 EventBridge Transform 能力及落地场景。

1. 什么是 ETL?

ETL 示意的是数据提取(Extract)、转换(Transform)和加载(Load)的过程,是数据集成的外围工作。三个步骤的次要作用如下:

1.1 提取

从数据源中提取数据,数据源能够是各种数据存储系统,比方音讯队列、数据库等。

1.2 转换

对提取的数据进行转换操作,比方数据富化、数据荡涤、数据聚合、数据拆分、格局转换等。

1.3 加载

将通过转换后的数据加载到指标服务中,比方数据仓库、数据湖、BI 零碎等。ETL 利用宽泛,它能够帮忙企业治理和利用数据,实现数据驱动的决策和业务转型。

2.T(Transform) 的能力

2.1 Transform 利用场景

ETL 中的 T(Transform)能够对提取的数据进行转换操作,它具体的应用场景如下:

2.1.1 数据富化

调用内部服务获取额定信息丰盛原始数据,进步数据的残缺度和可应用性。

2.1.2 数据荡涤

对原始数据进行荡涤或验证,去除反复、缺失或者不精确的数据,确保数据的品质和准确性,或者对数据中的信息进行脱敏,确保 数据的安全性。

2.1.3 数据聚合

将多条原始数据进行合并,造成一个对立的数据视图,便于后续的疾速剖析和查问。

2.1.4 数据拆分

将单条原始数据依据业务需要拆分为多条数据。

2.1.5 数据格式转换

将上游数据转换为指标服务可承受的格局,比方将 Base64、Avro、PB 等格局的原始数据对立转换为 json 格局。

通过 Transform,能够将原始数据转化为一致性、准确性和安全性兼具的高质量数据,为后续的数据分析等操作提供牢靠的根底。

2.2 业界 Transform 架构概述

目前业界的 Transform 能力,常见的做法有以下几类:

2.2.1 内置开箱即用的简略且轻量的 Transform 能力

数据荡涤:去除数据中的敏感字段、解决乐音数据等。

数据格式转换:将数据中的指定字段转换为特定格局。

2.2.2 内置 Custom Transform 能力

用户可自定义 Transform 的逻辑。这种常见的做法是:用户依据 Custom Transform 的接口标准,实现接口并将实现的代码打成 jar 包,之后在零碎导入该 jar 包即可应用本人编写的 Transform 逻辑。

2.2.3 Remote Custom Transform 能力

通过 Remote 调用的形式调用内部系统对数据进行 Transform。

上述 1、2 两种做法,因为其 Transform 与零碎逻辑高度耦合,共享计算资源,并不太适宜在 Transform 中进行重量级计算,仅适宜利用在一些轻量、简略的业务场景。更优的做法是 Remote Custom Transform,它解耦了 Transform 业务逻辑与数据通路,更具灵活性。

2.3 阿里云 EventBridge Transform 设计

阿里云 EventBridge 通过集成阿里云函数计算实现了 Custom Transform 能力,通过 Remote 调用的形式将 Transform 业务逻辑与数据通路解耦。进步了 Transform 的灵活性,升高计算资源的挤兑危险。

2.3.1 链路架构

应用阿里云的函数计算进行 Transform 时,EventBridge 的整体链路如图所示。

  • EventBridge 从 Source 侧提取数据。
  • 提取的数据,先通过攒批(window)逻辑的解决,达到攒批条件后,数据将以批的形式交由下一步解决。过滤(Filter)会遍历每一条数据,判断是否要抛弃该条数据。过滤实现后,数据将仍以批的形式交由下一步解决。转换(Transform)阶段会调用函数计算,将数据交由用户编写的函数代码进行解决,Transform 阶段会期待函数执行实现并接管其返回的处理结果。
  • EventBridge 将 Transform 解决后的数据加载到 Sink 侧。

下文在此基础之上持续探讨链路中波及的几个关键问题:

2.3.2 攒批问题

攒批能够批量聚合多条数据,在达到攒批条件后再将数据批量推送给下一步进行解决。EventBridge 将攒批能力置于 Transform 之前,通过攒批能力晋升了数据的解决效率和吞吐量,并且显著升高 Transform 调用函数计算的次数。

EventBridge 从数量和工夫两个条件来管制攒批的行为,只有达到其中一个条件时就会触发批量推送。

批量推送条数:单次可聚合的最大数据条数。

批零推送距离:聚合的间隔时间,零碎每到间隔时间会将已聚合的数据批量推送给下一步。

2.3.3 高可用问题

Transform 解决数据时可能出现异常,为防止异样导致数据失落或影响链路的稳定性和可用性等。Transform 复用了 EventBridge 的重试、死信、容错等机制。

  • 重试机制因为网络异样、零碎 crash 等起因导致 Transform 解决异样时,EventBridge 会依照用户抉择的重试策略进行重试,目前反对退却重试、指数衰减重试两种形式。
  • 死信队列当数据超过重试次数后仍未 Transform 胜利时,会变成死信数据。如果不心愿死信数据被抛弃,用户能够配置死信队列,所有的死信数据会被 EventBridge 投递到死信队列中,目前 EventBridge 反对 Kafka、RocketMQ、MNS 作为死信队列的指标端。
  • 容错策略当 Transform 产生谬误时,EventBridge 提供了以下两种解决形式:

1. 容许异样容错:当 Transform 异样产生时不会阻塞执行,会持续解决后续的数据。然而,EventBridge 会重试产生异样的数据,在超出重试策略后依据配置将数据投递至死信队列或间接抛弃。
2. 禁止容错:不容许谬误,当 Transform 异样产生且超过重试策略配置时会阻塞执行。

2.3.4 费用问题

函数计算的调用和函数的执行会产生肯定费用,蕴含函数调用、资源应用(CPU、Mem 等)和公网出流量三局部的费用。为缩小函数计算产生的费用,函数计算定向减免了来自 EventBridge 的函数调用次数费用,即 EventBridge 触发函数计算产生的函数调用次数不再计入费用账单 [3,4]。

2.4 产品交互

目前可在 EventBridge 的事件流中体验 Transform 能力,如图所示。

对于阿里云函数计算来说,咱们提供了两种形式:

2.4.1 新建函数模板

可在提供的模板之上,间接创立函数。产品层面提供了繁难的 IDE,便于用户编写和调试代码。

2.4.2 绑定现有函数

反对绑定用户已有的函数。更具体的应用可参考 Transform 帮忙文档,见附录 [4]。

2.5 Transform 劣势

2.5.1 Serverless Transform 个性

EventBridge Transform 基于 Serverless 函数计算构建,可享受 Serverless 服务免运维、资源弹性伸缩、按量付费等个性,具体如下:

  • 弹性:百毫秒内级别的伸缩,可满足波峰波谷、Burst、继续稳固等多样化的负载场景。
  • 免运维:用户无需关怀和运维 Transform 运行环境及资源。
  • 按量付费:用户只需领取函数运行所产生的费用,更重要的是 EventBridge 调用函数所产生的调用次数费用将不计费。
  • 灵活性:UDF 的形式可满足理论业务中简单、个性化的需要。
  • 多语言反对反对:go、python、java、nodejs 等支流语言,可抉择相熟或适宜的语言实现 Custom Transform 逻辑。
  • 架构解耦:Remote Transform 的架构将 Transform 业务逻辑和零碎逻辑结解耦,资源隔离,防止产生资源争抢等问题。
  • 模版反对:产品层面提供了多种 Transform 函数模板,防止用户从零开始。
  • 攒批提效:通过攒批,函数的入参为批量的音讯,大幅晋升了音讯的解决效率和吞吐。

3. 客户场景案例介绍

3.1 数据格式转换 + 架构降级

音讯 (MNS)->Transform-> 音讯 (RocketMQ)

客户面临架构降级问题,心愿将零碎依赖的 MNS 降级为 RocketMQ,但零碎架构简单,依赖 MNS 逻辑较多,且关涉研发人员较多,预计全副降级架构需继续几个月工夫。为保障架构降级过程中产生的数据一致性问题,客户应用 EventBridge 将旧架构的 MNS 音讯实时同步到新架构的 RocketMQ 实例中,来保证数据在一致性。同时为了适配新架构中的音讯设计,客户应用 FC Transform 先将旧音讯转换为指标格局,再投递至 RocketMQ 中。

3.2 数据荡涤 + 数据转储

音讯 (RocketMQ)->Transform->OSS

客户会将用户产生的视频数据投递到 RocketMQ 中,这些数据用户是能够查看的。为此客户抉择 OSS 来进行文件存储,满足这种写多读少、低成本存储数据的场景。然而,视频数据中蕴含了若干敏感信息,为此客户应用 FC Transform 对视频中的敏感数据做革除后,再将视频投递到 OSS 中。

4. 总结与瞻望

EventBridge Transform 通过集成函数计算,满足了理论业务中简单、个性化的需要。其弹性伸缩、免运维、按量付费的个性深受客户青眼。将来 Transform 会通过集成更多的服务(阿里云工作流、HTTP Destination 等)解锁更多的业务场景,满足多样化需要。

相干链接:

[1] EventBridge- 事件流 - 事件内容转换

[2] EventBridge- 事件流产品首页

[3] 定向减免音讯类产品和云工作流的函数调用次数费用

[4] 函数计算计费项提价告诉

原文链接

本文为阿里云原创内容,未经容许不得转载。

正文完
 0