共计 7081 个字符，预计需要花费 18 分钟才能阅读完成。
明天的分享蕴含以下几点：
背景 & 需要
为什么是 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
