除了拖拽式的数据集成，在部分场景下，我们或许还需要向导式的数据集成。那么，向导式的数据集成应该怎么设计？这篇文章里，作者从几个维度做了切入和拆解，不妨一起来看一下。

一、向导式的更常见

在拖拽式的数据集成中也提到，一个源端、一个目标端就能够实现和数据同步一样的效果。那为什么还需要向导式的数据同步呢。从单个表的功能实现上来说好像确实没有必要，但是既然不仅仅需要考虑功能，还需要考虑便捷、交互优化、易于维护等等，那么就会有些场景是需要向导式的数据集成的。

第一个就是批量：

拖拽式的数据集成很显然是没有特别好的方式实现批量处理的。而在数据集成过程中，当需要同步的表数据量特别大的时候，又会有这种批量创建任务的需求，这个时候向导式的数据同步就能很好的进行批量创建这种场景了。

现在，市面上一般的数据集成因为是向导式的，也没有实现批量创建的交互，这一点在设计的时候，个人感觉是可以给优化一下的。下面也会讲解到单个向导式和批量向导式，两种向导式数据集成任务。

第二个是便于维护：

向导式的数据集成不存在像拖拽式的那么多的组件，所以在任务查看的时候也不需要像拖拽式那个把各个组件都点击打开，来看内部不同设置。这样在任务查看，任务修改的时候会方便些。

还有一个不算理由的理由，算是产品惯性吧。如果不是纯粹的从零开始（这种机会很少很少，即使代码工程是从零开始，也一定会有一些公司内部其他相同产品参考）。一家公司的产品是什么样子，其实不是一个甚至说一届产品经理的决定能够确定的，大概率是在之前的基础上进行升级优化，不会完全推倒重构，倒不是说这样不好，只是说这是一种现状。

回到向导式的数据集成，同样的思路，因为已经有向导式的数据集成了，也就在之前基础上接着做了。

二、向导式数据集成

向导式的数据集成，可以是单表的也可以是批量多表的。

1. 单表模式

单表模式的数据集成是大部分类似产品的选择。像Dataworks的数据集成一样，在同一个界面中，完成源端选择、目标端选择、字段映射及任务一些设置，是在一个界面上从上到下即可完成一个任务的创建。这种模式确实能够快速完成任务设置，但是当需要批量的时候，就显得扩展空间不足了。

个人在第一次进行向导式的数据集成设计时候，也直接采用了类似的交互，后来再次进行设计的时候，发现这种形式和批量的比较，在便捷性上多少不足。

2. 批量模式

第二种方式，在实践中证明是更好的一种方式，即能满足单表，也能实现批量。如果单表是是从上到下完成了任务的创建，那么批量模式，即是从左到右的，第一步、第二步、第三步、第四步、第五步来完成任务的创建。

第一步：新建任务

在第一步中进行任务名称、描述，并完成源端和目标端的选择，因为是批量模式，只需要选择数据源即可。

第二步：任务设置

设置任务使用的资源队列，重试次数，失败策略等等任务本身通用的设置。

如果是离线的话，最重要的是周期性调度的设置。

周期性调度到底是在任务创建过程中，还是在任务创建完成，发布上线之后再进行设置。这也是两种不同思路，在任务创建过程中，意味着后续的调度已经确定，随着任务创建就可以了，如果是在发布上线之后再设置，也就是说需要先把任务创建出来，之后再确定调度周期。

第三步：源库设置

在源库设置这一步，就能够实现批量设置的能力。在弹窗中选择批量任务需要批量处理哪些表，表选中后，点击不同的表进行过滤处理等设置。如果要进行批量表的增减再调出弹窗进行表的增减。

这种交互，既能够进行表的批量选择，又能够针对单个表进行设置。个人对这个交互还是比较满意的。

这里提一点，因为数据集成源端和目标端是多种多样的，所以在具体界面显示上，可能会根据不同的数据源类型有特殊的区别。

第四步：目标库设置

在目标库设置中，会进行比较复杂的表级别的映射关系，这个界面和单表模式下的字段映射是类似的，会为每一个源端表来选择一个目标端的表进行映射。当然和源端一样在不同数据源类型下，界面也会有所不同，还会有些是否创建表，是否有冲突策略，写入前、写入后的执行策略等等。

第五步：预检查

最后一步是一步预检查，是在创建任务这一刻来保证任务成功运行所必须的一些条件是否都完全具备的。如源端、目标端的联通性，权限是否开启，是否有一些必须的log权限等等。

三、运维的过程

个人单表模式的数据集成和批量模式的数据集成都涉及过，最终个人比较喜欢批量模式，在运维过程中也主要说下批量模式的运维。这中模式下希望能够创建的时候能够批量创建，运维的时候能够单个运维。达到这种效果就可以。

1. 子任务及实例是打开新页面，还是在原有页面上左右伸缩显示

虽然创建是批量创建的，但是实际的日常运维是需要到子任务级别的，查看子任务的实例日志、状态，对子任务进行操作。所以从主任务打开子任务是怎样的交互。

最开始是打开一个新页面，在新页面中对子任务进行交互操作。后来发现需要频繁的切换主任务，就意味的需要打卡的新页面就很多。后来进行了调整，在同一个页面中左右显示主任务和子任务，也就是在点击主任务的时候，子任务能够在右侧已抽屉的形式展示出来，这样就即能够实现主任务的灵活切换，又能够很方便的查看子任务，对子任务进行操作。

通过这次调整，也是发现产品确实是在使用过程中打磨完善的。有时候经常看到特别复杂的交互的产品，可能在最初的时候，都是功能很单一，交互很简单的。只不过在产品的不断使用过程中完善的。不需要奢望产品在最初就特别的复杂，功能特别的多，只要是在一条正确的路上，等待产品自己生长就可以了。

2. 创建的批量，下线是单个

前面说了虽然创建是批量的，但是运维显示的子任务、子实例都是单独的，同样，这对子任务的上下线需要能够进行单独调整的。这也是运维灵活性的一个体现。

四、是离线还是实时任务

因为在工作中接触离线相关偏多些，所以上面的视角也是离线视角进行的交互，但是其实大部分也是和实时适用的。和不同数据源界面需要做相应调整类似，在做实时的时候也需要针对具体实时的数据源做相应调整。

总结

整体来说向导式的数据集成设计过了三次了，第一次纯参考竞品，第二次单行了基于单表的升级，第三次基于批量模式的升级。

当然，也会有些觉得还需要增强的，比如：同步的数据量的统一监控、实时同步的数据源要不要管控起来。当然，这也是需要需求来推动的。随着需求场景的不断扩展，再增加产品功能，产品是生长出来的，不需要一口气全部都增加上。