Apache SeaTunnel 插件开发最新经验总结，手慢无！

在Apache SeaTunnel的最新插件开发中，Connector-v2 maxcompute 连接器实现了基于CatalogTable + SaveMode的新版本。

本文主要给大家分享了源端的关键改动包括弃用了过时的方法，改为通过CatalogTable实现数据传递。汇端则增加了对Multi-table sink和SaveMode接口的实现，并需手动管理auto service注解等经验方法！

此外，开发了特定的Catalog以处理公共参数和客户端操作。

Connector-v2 maxcompute 连接器

connector-v2 maxcompute 连接器
实现了基于CatalogTable + SaveMode
的新版本。

a) 源端的核心改动

• 新版本中SeaTunnelSource
  继承自SatunnelPluginLifeCycle
  接口，其中包含了一个prepare
  方法。该方法原本用于初始化源端中的config
  参数，以及一些预处理工作，如删除数据、执行SQL等。
• SeaTunnelSource
  中的getProducedType
  方法用于存储SeatunnelRowType
  ，即列映射转换信息的覆写。

改动如下：

• 不再使用两个已过时的方法。
• 在构造函数中创建CatalogTable
  ，并在新方法List<CatalogTable> getProducedCatalogTables()
  中实现catalog
  的数据传递。在新版本中，catalogTable
  将从源端传递到汇端，作为后续saveMode
  里批量同步建表的SQL拼接来源。
• SeatunnelRowType
  可以从catalogTable
  中获取，以适配现有连接器，也可以自己封装公共参数进行传递。

关于Catalog：

• 我们通过getTable
  获取CatalogTable
  。如果配置了自定义列（column
  ），以适配DataX，我们需要基于column
  生成CatalogTable
  。

b) Sink端的核心改动

变动见此图

去除auto_service
注解的原因：

• 如果某个连接器汇端（例如maxcompute）已经实现了新模式接口，不再通过过时的prepare
  方法注入config
  ，而是通过构造函数从上下文传入的catalogtable
  获取内部seatunnelRowType
  的适配。这个连接器在排序上比较靠前，AbstractPluginDiscovery
  在服务加载时总是首先发现它。但是，如果其他插件（例如clickhouse）仍在使用旧模式（prepare
  ），则MultipleTableJobConfigParser
  解析汇端会将其视为过时插件，并回退到JobConfigParser
  进行适配。在parseSink
  方法中，AbstractPluginDiscovery
  仍会扫描所有通过autoService
  注解注入的SeaTunnelSink
  插件。此时，它遇到的第一个插件maxcompute的构造函数不能适配旧模式的实例初始化，导致失败。
• 这导致了Maxcompute到Clickhouse数据同步时，报出MaxcomputeSink无法初始化的问题。

  

• MaxcomputeSinkWriter
  需要额外实现SupportMutiTableSinkWriter
  ，否则无法进行适当的转换。

如果要指定部分列回流：

• 必须比较catalogTable
  中的列数量与指定的自定义列数量，两者相等才可以进行回流。
• truncate -> data_save_mode / schema_save_mode
  
• 支持列数据的隐式转换（seatunnel row
  数据是一个Object[]
  数组，需要结合CatalogTable TableSchema + Opds TableSchema
  ）

c) 开发特定的catalog

catalog
需要通过catalog factory
进行实例化，并通过auto service
进行装配加载。