在进行用户跨系统，或者数据搬运的情况下，一般使用拖拽式的开发形式。国外一般归类于ETL产品中，对应的组件是源端组件、转换组件、目标端组件，具体如何设计，请看这篇文章。

拖拽式的数据集成，到底属于数据集成还是数据开发，一直会有这个疑问；在加工过程中的各个组件，又能进行负责的转换、计算等操作。属于数据加工吧，这种拖拽式的加工，在国内不普及，开发人员开发能力强，还不如直接使用SQL脚本进行开发了。两边都靠，两边都不是，甚至会出现到底在国内场景下是不是有必要的讨论。

这里把这种拖拽式的开发形式，一般主要用户跨系统，或者说数据搬运的情况下使用，属于归类于数据集成产品。国外归类也是把他归属到ETL产品中。

这里多说一句：如果在你的产品设计里面，既有拖拽式的数据集成又有向导式的数据集成，在叫产品名称的时候，又不想加特别长的前缀，可以把拖拽式的数据集成叫数据集成，向导式的数据集成叫数据同步。这里就用了数据集成和数据同步在解释上的细微的区别，一个专注于数据的整合和数据处理，一个更注重数据的传输和一致性。这也就是开始说的依据具体的上下文场景、团队内的称呼习惯等灵活决定。

在转做产品经理之前，用过很长时间的拖拽类数据集成产品，就是Informatica powercenter。这款产品常年占据Genter数据集成产品象限的领导者地位。不过话说来也挺怪的在国内却缺少一款同类型的产品。也就是说在国内很少见以转换算子特别丰富的拖拽形式进行数据集成的产品。想了想，可能时国内开发人员普遍的代码能力较强（但是也不对，难道国外的开发人员代码能力就弱了？），这种拖拽的虽然貌似将门槛降低了，但是却没有直接写SQL的效率、维护上方便，所以也就没有这方面的需求，类似的产品也就没有生长出来（听说拖拽式的AI平台也面临同样的处境。真正会AI的人觉得拖拽式开发麻烦，不会AI的人对于各个算子的参数又不能很好理解，不知道是不是真的？）。

有需求才会有产品，既然国内很少用这个产品，我为什么设计过？

这是在一家公司做乙方的时候，一家公司曾经使用过IBM DataStage，所以当他们想上云时，也需要同样的类似功能，基于此设计、实现一套拖拽式的数据集成工具。

整体的设计还是不会摆脱数据集成的三部分—ETL，对应的组件就是：源端组件、转换组件、目标端组件。各个组件里面的展示细节，也在不断打磨中，这个过程更像产品是生长出来的感觉。不需要在一开始就要求是最好，让产品发生。

一、源端组件

源端插件是整个数据集成中的数据开始进入的地方，所以交互上第一步就是先选择一个数据源类型，根据类型变化具体类型下面的数据源的选择。选完数据源之后，选择一个具体的表，就完成了源端设置了。

二、目标端组件

目标端插件和源端设计一样，也需要先选择一个数据源类型，再根据类型确定具体的数据源可以进行哪些不同设置，目标端是整个数据集成的数据终点，从源端导入的数据，最终都将到达目标端。

只有一个源端，连接上一个目标端，其实就可以完成一个数据集成任务的开发了。只是中间没有任务的数据转换，仅仅是数据的同步。（这时候就细微的发现数据同步和数据集成两个名词之间的一点区别了）

目标端组件和源端组件在交互上最大的不同点是，目标端组件在数据写入的过程中有一个字段映射的问题。Powercenter是一个C/S架构产品（Informatica Powercenter 的使用是基于2013年的版本，当时是B/S 架构，后续的产品升级及上云都没有接触过，上述仅做参考），可以设计很复杂的交互，直接让字段和字段建立映射。

但是在B/S架构中，如果也使用这种交互，当打开的组件过多时，整个浏览器会变得特别的卡。所以，需要针对B/S对这种有字段映射的拖拽式开发，需要有一种不同的形式来完成字段映射。这部分将在后面的组件间的字段映射部分做详细说明。

三、转换组件

转换组件，是数据集成的能力体现，转换组件强大，则拖拽式的数据集成能力就强大。转换式组件的 设计思路基本上就和SQL中的一些关键字的抽象，同时参考powercenter的现有的一些组件，在初期的时候，设计了以下的转换组件:

1. 表达式组件-Map

在表达式组件内部，对行级别的处理，可以新增行，将原有行数据进行拆解、进行规范化、新增一行默认值等等。

2. 过滤组件-Filter

过滤组件其实并不是必须的，大可以在源端组件中直接完成过滤即可。这样进入整个数据集成的数据就会少很多。

3. JOIN组件

实现的功能和SQL的join逻辑是一样的，将两张表连接在一起。也会分内连接、外连接等的区别。在界面上输入是两个，输出是一个。也仅仅支持两个输入，多余三个join的话，就将上两个的结果，继续join第三张表。

4. Union组件

实现两张表的union，实现的功能和SQL中的Union也是一样的。

5. 分组聚合组件-Aggregator

对输入表进行分组聚合的计算。

四、组件间的字段映射

两个组件如何实现数据传输那，其实就是拉线，拉一条线，表示数据从上游传递到了下游。我们所有数据传递都是字段级别的，所以这个拉线是表级别的还是字段级别的。

在设计之初的时候想打开两个插件，然后将两个插件内部的每个字段进行一个行级别的对应映射，但是这样做的话一方面是交互特别复杂，而在浏览器中不能做到这么灵活的交互，一方面如果字段特别多，都开发的话，占用浏览器内存过多，交互过程会比较卡（CS架构的Informactica powercenter就是这种打开后字段级别的交互，但是也很好奇迁移到云上之后，他们是怎么交互的）。于是就选择了另一个中交互，也就是只是表级别，在表之间连线，然后传递上游所有字段到下游。在下游中进行字段映射。映射过程中字段对应关系怎么体现那，最简单也是最不友好的形式就是默认从上到下的一一映射。

友好一些的就是将上游的将字段传递到下游插件，在下游插件内部展示上游字段，然后在下游插件内部自己做字段对照。 如果上游的字段进行字段变更了，那么下游什么时候获取到这写变更的字段，这个是增加了一个局部保存还是全局保存的能力来做的。

源端、目标端、中间转换插件（算子），通过插件间的映射链接连接到一起。就是一个完成的拖拽式的数据集成任务了。

五、是离线还是实时任务

在上面介绍的所有算子，其实都是从离线的视角来介绍的。但是对于实时的视角其实一样适用。只是中间的转换算子不一样。

这个如果是离线的那个就可以当做一个普通的离线任务，放在离线的DAG图中，配置调度，如果是一个实时的，就可以直接启动运行了。

六、总结

做产品的过程，就是实现自己想法的过程，在实现了拖拽式数据集成之后，算是实现了一个做产品的个人小目标。看着一件事物在自己的规划中实现，还是很欣喜的，这可能是创造的乐趣，也是做产品的乐趣。

本文由 @数据小吏 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。