明天的分享蕴含以下几点：

背景&需要

为什么是 SeaTunnel

ETL 平台集成实际

作者简介

01业务背景和需要痛点

业务背景

推搜广场景下存在大量的数据同步和特色解决需要。举荐搜寻广告业务波及图中几个模块，以特色为根底的特色服务，下层反对了机器学习、召回引擎和预估引擎。召回引擎和预估引擎撑持着更下层的举荐引擎业务的召回、粗排、精排、重排，最终产出后果。这是推搜广的次要业务流程，其中有些细小差异，但大体类似。

对于举荐零碎，物料数据是举荐零碎要举荐的内容，包含视频、文章或商品等。举荐零碎的次要数据包含用户行为日志、服务端日志、物料数据、实时特色快照等数据，咱们首先会接入 kafka 中，分两个流，一是同步到hdfs作为离线数据反对离线用户画像、物品画像、离线行为特色等离线特色数据的计算；二是 Kafka 中的数据通过实时的Flink或 Storm 解决，进行特色正负样本拼接、日志拼接和特色计算等，生成实时用户画像、物料动静画像、用户序列特色、实时快照特色等实时流特色数据。实时和离线特色通过特色注册存储到 redis、mongodb、parker、cassandra 等存储中通过特色服务对接到下层利用。

当用户向举荐零碎发动一个申请时，首先触发举荐零碎召回。召回有多种类型，协同类召回是基于物物类似 itemcf，人人类似 usercf，人物矩阵合成等；向量化是把一个内容或者物品通过向量化embedding 的形式表达出来，再计算类似度；池子召回，是热点池和精品池或者经营池等进行举荐；模型召回是基于一些模型算法开掘进去的、对用户举荐的候选集数据，进入召回阶段。

召回阶段可能存在 5000 篇视频或文章，这些数据进入粗排。粗排是对召回的数据通过预估引擎进行一次粗粒度的物料筛选，筛选出 5000 中可能的1000 篇。预估引擎利用了机器学习的一些模型，进行预估和打分。打分后会进行排序。进入精排后会输出更多特色数据，包含穿插特色等，进行更细粒度的筛选、排序和打分，后面的 1000 篇可能会剩下 50 篇或更少。这个后果会进一步进行重排，重排有多重伎俩，像将一些内容必须插入到某个地位的调整，还包含同类文章数据按规定打散缩小同质化内容、晋升用户体验，也会对举荐内容做去反复等操作。实现重排后输入后果。

能够看到机器学习、召回引擎以及预估引擎都是以数据和特色为根底的，这些业务场景下有大量数据处理。数据处理次要是特色计算，而计算过程中也须要将产生的数据模型同步到对应存储中，这就是咱们业务场景中数据同步需要的起源。整套零碎反对了 10-20 个业务，整体数据同步的需要较大。

痛点和指标

业务多，工作碎片化。一些工作部署在调度零碎中，一些工作是以 Crontab 模式配置的，开发人员保护同步工作艰难，且没有上线前后的串联关系。数据同步和数据处理需求量大，人力无限，同步工作开发和部署零散，有 Spark、Flink 工作也有脚本，开发人员为了保护多个同步工作，同时还须要相熟打包、编译、上线流程，保护流程难以统一化。且数据同步工作和数据处理存在烟囱式开发的问题，难以通用化，耗费人力物力。

咱们须要让数据处理和同步工作标准化、对解决和同步工作进行对立治理，心愿能将数据处理和同步形象成工具化的产品，让数据处理和同步的能力通用化，可被复用。同时让数据处理和同步工具能够有普适性，可能产出一些低学习老本、高开发效率的工具达到缩小重复劳动、晋升效率的成果。

流程对立

为了解决痛点、达到目标，咱们首先进行了数据处理和同步工作开发部署流程的对立。这里以样本拼接为例，样本拼接是咱们业务中重要的一环，分为离线和近线。样本拼接次要指获得用户过后的一些特色快照数据，给予用户对这个举荐后果的一个正负反馈，如是否点击、是否曝光、是否下载，把这些数据作为样本输出到训练模型的样本中。咱们的样本拼接次要做正负样本。

离线样本拼接首先通过 Spark 实现样本拼接和特色抽取后，后果存储到 HDFS，对接离线模型训练实现离线解决。近线样本拼接通过Flink对实时日志流数据进行解决，实现样本拼接和特色抽取后放入 Kafka，最终对接增量训练模型后实现近线解决。这里的实现是两套代码，接口和 API 不完全相同，由不同人保护，保护老本高。两套零碎，别离存储的数据容易出问题，离线近线两套零碎数据容易呈现不统一问题，对最终模型训练和试验成果有肯定影响。

在此基础上，咱们对立了解决流程，实时（近线）和离线均用Flink解决数据，保护同一套引擎代码。通过 Flink 进行实时流样本拼接、特色抽取，失去的样本数据存储到 Iceberg 数据湖。Iceberg 对接离线和增量模型训练，进行数据处理。这套计划对立存储、缩小数据冗余，防止了特色不统一问题产生。应用一套计算和存储引擎，函数复用，晋升了效率。

构造对立

首先咱们做了样本结构化。咱们把输出到模型的前置特色数据基于不同类型做了合成。

图中第一局部是业务单元，业务单元次要指用户ID、物料 ID、工夫戳，这些是用户申请后的快照数据。第二部实时特色，是用户申请的那一时刻的状态，比方那一时刻对某个趣味的上下文的那个实时特色。此外还有一些离线特色。

合成前，业务单元呀、实时特色呀、离线特色都是对立通过引擎去输出，dump 到 Kafka，而后再去做特色的样本拼接和数据处理的。但离线特色这一部分的特色很多是动态的，不会频繁变更。如果每次都走流式计算这些离线特色，数据量会特地大。而且数据反复传输，可能一些数据在模型外面基本不会用到。咱们做合成后，实时特色实时地申请，离线特色进行填补，缩小了数据冗余，整个样本的数据也更结构化。

除样本的结构化外，咱们对于样本内的特色也做了标准化，即存储格局的标准化，底层存储用pb格局序列化。数据中的 byte、string、Int64List、FeatureValueList 特色数据等。通过对立后，数据能够跨业务地复用、屏蔽底层细节。

性能模块化

在构造对立的根底上，咱们进一步做了特色的生产-存储-服务全流程标准化。并对立了API、对接上下游屏蔽底层细节，让跨业务特色数据共享开掘更大价值。

咱们的特色核心对接了实时和离线数据源，进行特色生产后，将特色注册到特色存储，而后由特色服务对立对接预估模型服务或用作召回数据。

咱们的特色服务反对在线计算，在线计算次要反对用户行为序列，近期特色和一些画像特色中须要统计一些根底数据的场景。如最近 20 条的某个类目标峰值、占比、CTR，能够通过在线的形式实时计算，这样可能减少业务的灵活性。

在这个构造上，咱们的特色生产是基于 SeaTunnel 做的。

02 为什么用 SeaTunnel

SeaTunnel 构建在 Spark 和 Flink 上，借助Flink、Spark 可能满足大数据量实时离线, 高性能的同步和解决能力。用户不须要关注细节，通过配置化、插件的形式，配合 SQL，就能够疾速部署数据同步利用到生产中。

SeaTunnel 解决流程高度形象，逻辑清晰。SeaTunnel 对接 Hadoop、Kafka、ES、Clickhouse 等数据源，通过 Source 输出，Source 对接 Transform，Transform 中进行数据逻辑解决，包含数据过滤等。数据处理实现后对接Sink 将数据输入到指标数据源中。

图中是一个 SeaTunne 工作的开发配置，env 局部配置可配置工作的并行度和工作的优化参数、checkpoint 门路和频率等。Source 局部能够配置 FakeSourceStream 数据源，做测试应用。FakeSourceStream 能够配置数据表和字段名称。Transform 局部从 source 读取数据，可配置多个数据处理的 SQL 和长期表名。这里配置的Sink 是 ConsoleSink，是输入到控制台，不便察看和调试。

SeaTunnel 基于 java SPI 技术,十分便于扩大。下图是整个顶层接口的设计，实线示意了继承关系，红色的虚线是依赖关系。顶层是基于 Plugin，在 Plugin 的根底上波及了BaseSource、BaseSink 和 BaseTransform。上面还有 BaseFlinkSource、BaseFlinkSink 和BaseFlinkTransform 三个高度形象的解决流程。继承这些接口，实现本人的逻辑即可。

除了 Source、Sink、Transform 外还有Runtime，Runtime 是封装了整个运行环境。Flink 封装了 BatchEnv、StreamEnv。除此之外还有 Execution，Execution 串联了整个 Job 的执行流程。

整体构造清晰明了，插件实现起来很容易。

SeaTunnel 曾经反对多种数据源，在此基础上缩小了造轮子的状况产生。SeaTunnel 社区曾经反对了 Doris、Redis、MongoDB、Hive、MySQL、TiDB、ElasticSearch、Clickhouse 等数据源。

03 ETL平台集成

ETL 特色生产解决平台是基于 SeaTunnel 进行的二次开发，构建在 flink 之上。

ETL 集成平台同 SeaTunnel 一样插件化，十分便于扩大与集成；

SeaTunnel 曾经反对了好多数据源，不须要从头开始造轮子；

ETL 平台提供了配置化的形式，便于上手，用户不须要编写代码和理解底层细节和 API，就能够实现一个流工作或批工作的开发；

借助 Flink 的状态机制和实时处理的个性，非常适合窗口统计类实时运算的操作，十分切合举荐业务场景；

图中是 ETL 特色生产解决平台的架构，有绝对独立的监控治理模块，Flink 引擎之上有数据输出层、数据处理层和数据输入层。

监控包含配置管理和工作治理，品质监控是负责配置质品质监控、告警。工作编排针对离线工作的依赖关系的治理。元数据是治理如Kafka输出的数据源的信息。此外还有血统依赖。数据输出层接入了Hdfs、MQ、Kafka、HBase 等数据源。数据处理层能够对数据进行标准化解决，反对 SQL、DataSet/DataStream、数据格式转换和数据压缩等解决。数据输入层反对了 Scylladb、Hdfs、Redis、Kafka 等。平台的利用场景蕴含数据同步、数据处理、特色计算、样本拼接，都是基于底层的模块零碎。

上面会具体介绍 ETL 的工作是怎么跑起来，又是怎么开发的。

组件单元分为三块：plugin、SQL 和 UDF。Plugin 是 Source、Transformer 插件，SQL 可做逻辑解决，咱们也封装了很多具备通用性的UDF，和依据业务场景定制化的 UDF。联合几个模块即可生成一个 Job 的配置文件。Job 既能够是批工作也能够是流解决。整个 Job 的配置文件生成后会进行工作的治理编排，调度零碎 oflow 负责编排批工作、ostream 负责编排流解决工作。oflow 会治理工作的上下游依赖关系，重试次数、报警等。ostream 是 Flink 运行的环境，治理工作参数配置等。对工作进行编排后会对工作进行提交，反对编排工作在 Yarn 和 k8s 平台进行运行。

ETL平台Job开发流程是怎么的？

首先咱们采纳了插件参数化治理的模式。以 Kafka Source为例，如下图所示，能够配置KafkaTableSchema 的实例名、schema、消费者信息和字段信息等。

建好 Source 后，对于不理解的老手，能够通过平台提供的托拉拽形式实现一个工作的编辑。同时借助 DAG 图的能力，可能非常容易地了解整个作业的流程。\

对整个流程比拟相熟的用户则能够间接编辑配置，或者通过复制编辑、批改局部配置，就能够疾速实现一个 job 构建。

配置与插件互通，用户能够依据状况灵便抉择和编辑。DAG 图能够辅助用户查看是否存在依赖谬误的问题。

如何确保一个工作正确并且稳固的开发和上线运行呢？咱们通过三个环节进行把控：配置测验，查看是否配置中已存在谬误；逻辑调试，判断是否存在逻辑谬误，如 SQL 中的字段谬误或命名问题，都能够在这一步被发现；线上监控是在工作上线后保障工作稳固运行。

如何将谬误管制在提交之前？首先咱们会对配置进行校验。保障组成配置是正当的，SQL 是没有语法的谬误的。如果肉眼察看能难发现错误，咱们会对简单 SQL 通过 SQL 解析疾速定位到具体的编写谬误。

第二是逻辑校验，对工作进行调试。工作调试须要数据，咱们提供了两种形式采集数据，一种是线上采样，另一种是样例数据上传。线上采样有时过于随机，不满足需要，这时用户能够上传样例数据造出须要的样本，察看上游数据产出是否通过测试。

逻辑校验对全流程进行模仿，打印日志，将逻辑谬误事后排除。启动调试流程后，通过样本上传或线上采样取得测试数据，进入模仿流程。最初输入后果。调试工作启动后，会对原有的工作配置做更改，在工作中插入埋点、将两头表数据处理进行输入。

图中是逻辑校验过程中打印的日志信息。能够直观地在工作上线前看到谬误，避免工作不通过测试就上线净化线上数据。

除了工作上线前校验，咱们还对工作进行了监控。工作监控包含 Flink metric 和自定义的指标上报，数据存储到时序数据库中，对接规定告警零碎。图中展现了 Grafana 的监控项。工作上线后，基于监控大盘能够十分不便疾速地定位和排查问题。

下图是工作监控中作业详情的 Grafana 大盘，能够看到工作运行状况、重启次数和提早等信息。

业务指标监控会对指标进行收集，服务裸露metrics 函数和 sink 插件上报到时序数据库。配合规定告警系统对数据报警。

ETL 平台反对了数据同步、样本拼接、时序特色、物料和用户画像、窗口统计等场景。这些根底上，咱们提供了模板，为数据同步、时序特色等较为固定和能够通用配置的场景提供了模板。咱们基于模板性能能够把通用的能力积淀下来。当用户须要新增数据同步工作时，能够基于模板对主要参数进行批改，疾速创立工作实现数据同步工作的开发。

咱们的 ETL 平台对 SeaTunne l也进行了优化与改良。咱们对所有插件都退出了并发管制，例如一个 Kafka 有 20 个 partition，但上游数据处理逻辑比较复杂，须要 40 并发解决数据。此时如果在代码中对立配置了 40 并发，这些并发可能产生很多大而无用的开销。还能够管制写入 HDFS 的文件数量和文件大小等参数。此外咱们对 Sink，Source 插件反对了更多扩大，反对了很多外部数据源。咱们的配置反对参数动静配置，这个性能在进行数据回溯时十分有用。咱们还开发了大量聚合函数和窗口函数，对状态保留和 Sum、Distinct 等聚合函数进行了优化。有一些函数是定制化的，有的业务有统计一些用户最近实时行为特色序列的需要，统计最近 APP 下载的一个窗口最新的 20条，且同时对 20 条信息去重，同时还要反对分类计数等。这样类场景，如果用 SQL 实现会非常复杂，还须要进行简单的优化和调优，此时咱们会开发比拟通用、在性能上通过优化的函数交给用户。

ETL平台规模方面，以后上线的任务量在1400多个，日均解决条目数在100亿以上，日均数据量40T以上。

咱们将来布局是引进Alink，Flink Ml等机器学习框架，反对回归以及分类算法、特色工程、窗口计算等与业务符合的能力。还有一个起因的话，就是咱们通过这个引进机器学习框架，能够把当初在Spark上运行的工作也迁徙到Flink上做对立管控。其次，咱们会在批流一体化落地方面继续摸索，解决Flink解决批工作的性能问题和起调机制问题。流批一体升高了保护老本，避免数据不统一问题呈现或数据失落，同时让数据回溯更加稳固便捷。此外，咱们还打算反对纯SQL模块，Spark SQL和其余SQL迁徙来的用户，面对平台中的配置文件的严格的模式会认为应用不够不便，因而咱们将对纯SQL进行更好的反对。

  • END

Apache SeaTunnel(Incubating) 是一个分布式、高性能、易扩大、用于海量数据（离线&实时）同步和转化的数据集成平台。

仓库地址：

https://github.com/apache/inc...

网址：

https://seatunnel.apache.org/

Proposal：

https://cwiki.apache.org/conf...

Apache SeaTunnel(Incubating) 2.1.0 下载地址：

https://seatunnel.apache.org/...

衷心欢送更多人退出！

可能进入 Apache 孵化器，SeaTunnel(原 Waterdrop) 新的途程才刚刚开始，但社区的发展壮大须要更多人的退出。咱们置信，在「Community Over Code」（社区大于代码）、「Open and Cooperation」（凋谢合作）、「Meritocracy」（精英治理）、以及「多样性与共识决策」等 The Apache Way 的指引下，咱们将迎来更加多元化和容纳的社区生态，共建开源精力带来的技术提高！

咱们诚邀各位有志于让外乡开源立足寰球的搭档退出 SeaTunnel 贡献者小家庭，一起共建开源!

提交问题和倡议：

https://github.com/apache/inc...

奉献代码：

https://github.com/apache/inc...

订阅社区开发邮件列表 :

dev-subscribe@seatunnel.apach...

开发邮件列表：

dev@seatunnel.apache.org

退出 Slack:

https://join.slack.com/t/apac...

关注 Twitter:

https://twitter.com/ASFSeaTunnel