SeaTunnel 在 oppo 的特征平台实践 | ETL 平台数据处理集成

今天的分享包含以下几点：

• 背景&需求

• 为什么是 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 任务也有脚本，开发人员为了维护多个同步任务，同时还需要熟悉打包、编译、上线流程，维护流程难以统一化。且数据同步任务和数据处理存在烟囱式开发的问题，难以通用化，消耗人力物力。

我们需要让数据处理和同步任务标准化、对处理和同步任务进行统一管理，希望能将数据处理和同步抽象成工具化的产品，让数据处理和同步的能力通用化，可被复用。同时让数据处理和同步工具可以有普适性，能够产出一些低学习成本、高开发效率的工具达到减少重复劳动、提升效率的效果。

流程统一

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

离线样本拼接首先经过 S