除了拖拽式的數(shù)據(jù)集成，在部分場景下，我們或許還需要向?qū)降臄?shù)據(jù)集成。那么，向?qū)降臄?shù)據(jù)集成應(yīng)該怎么設(shè)計(jì)？這篇文章里，作者從幾個維度做了切入和拆解，不妨一起來看一下。

一、向?qū)降母Ｒ?/h2>

在拖拽式的數(shù)據(jù)集成中也提到，一個源端、一個目標(biāo)端就能夠?qū)崿F(xiàn)和數(shù)據(jù)同步一樣的效果。那為什么還需要向?qū)降臄?shù)據(jù)同步呢。從單個表的功能實(shí)現(xiàn)上來說好像確實(shí)沒有必要，但是既然不僅僅需要考慮功能，還需要考慮便捷、交互優(yōu)化、易于維護(hù)等等，那么就會有些場景是需要向?qū)降臄?shù)據(jù)集成的。

第一個就是批量：

拖拽式的數(shù)據(jù)集成很顯然是沒有特別好的方式實(shí)現(xiàn)批量處理的。而在數(shù)據(jù)集成過程中，當(dāng)需要同步的表數(shù)據(jù)量特別大的時候，又會有這種批量創(chuàng)建任務(wù)的需求，這個時候向?qū)降臄?shù)據(jù)同步就能很好的進(jìn)行批量創(chuàng)建這種場景了。

現(xiàn)在，市面上一般的數(shù)據(jù)集成因?yàn)槭窍驅(qū)降?，也沒有實(shí)現(xiàn)批量創(chuàng)建的交互，這一點(diǎn)在設(shè)計(jì)的時候，個人感覺是可以給優(yōu)化一下的。下面也會講解到單個向?qū)胶团肯驅(qū)?，兩種向?qū)綌?shù)據(jù)集成任務(wù)。

第二個是便于維護(hù)：

向?qū)降臄?shù)據(jù)集成不存在像拖拽式的那么多的組件，所以在任務(wù)查看的時候也不需要像拖拽式那個把各個組件都點(diǎn)擊打開，來看內(nèi)部不同設(shè)置。這樣在任務(wù)查看，任務(wù)修改的時候會方便些。

還有一個不算理由的理由，算是產(chǎn)品慣性吧。如果不是純粹的從零開始（這種機(jī)會很少很少，即使代碼工程是從零開始，也一定會有一些公司內(nèi)部其他相同產(chǎn)品參考）。一家公司的產(chǎn)品是什么樣子，其實(shí)不是一個甚至說一屆產(chǎn)品經(jīng)理的決定能夠確定的，大概率是在之前的基礎(chǔ)上進(jìn)行升級優(yōu)化，不會完全推倒重構(gòu)，倒不是說這樣不好，只是說這是一種現(xiàn)狀。

回到向?qū)降臄?shù)據(jù)集成，同樣的思路，因?yàn)橐呀?jīng)有向?qū)降臄?shù)據(jù)集成了，也就在之前基礎(chǔ)上接著做了。

二、向?qū)綌?shù)據(jù)集成

向?qū)降臄?shù)據(jù)集成，可以是單表的也可以是批量多表的。

1. 單表模式

單表模式的數(shù)據(jù)集成是大部分類似產(chǎn)品的選擇。像Dataworks的數(shù)據(jù)集成一樣，在同一個界面中，完成源端選擇、目標(biāo)端選擇、字段映射及任務(wù)一些設(shè)置，是在一個界面上從上到下即可完成一個任務(wù)的創(chuàng)建。這種模式確實(shí)能夠快速完成任務(wù)設(shè)置，但是當(dāng)需要批量的時候，就顯得擴(kuò)展空間不足了。

個人在第一次進(jìn)行向?qū)降臄?shù)據(jù)集成設(shè)計(jì)時候，也直接采用了類似的交互，后來再次進(jìn)行設(shè)計(jì)的時候，發(fā)現(xiàn)這種形式和批量的比較，在便捷性上多少不足。

2. 批量模式

第二種方式，在實(shí)踐中證明是更好的一種方式，即能滿足單表，也能實(shí)現(xiàn)批量。如果單表是是從上到下完成了任務(wù)的創(chuàng)建，那么批量模式，即是從左到右的，第一步、第二步、第三步、第四步、第五步來完成任務(wù)的創(chuàng)建。

第一步：新建任務(wù)

在第一步中進(jìn)行任務(wù)名稱、描述，并完成源端和目標(biāo)端的選擇，因?yàn)槭桥磕Ｊ?，只需要選擇數(shù)據(jù)源即可。

第二步：任務(wù)設(shè)置

設(shè)置任務(wù)使用的資源隊(duì)列，重試次數(shù)，失敗策略等等任務(wù)本身通用的設(shè)置。

如果是離線的話，最重要的是周期性調(diào)度的設(shè)置。

周期性調(diào)度到底是在任務(wù)創(chuàng)建過程中，還是在任務(wù)創(chuàng)建完成，發(fā)布上線之后再進(jìn)行設(shè)置。這也是兩種不同思路，在任務(wù)創(chuàng)建過程中，意味著后續(xù)的調(diào)度已經(jīng)確定，隨著任務(wù)創(chuàng)建就可以了，如果是在發(fā)布上線之后再設(shè)置，也就是說需要先把任務(wù)創(chuàng)建出來，之后再確定調(diào)度周期。

第三步：源庫設(shè)置

在源庫設(shè)置這一步，就能夠?qū)崿F(xiàn)批量設(shè)置的能力。在彈窗中選擇批量任務(wù)需要批量處理哪些表，表選中后，點(diǎn)擊不同的表進(jìn)行過濾處理等設(shè)置。如果要進(jìn)行批量表的增減再調(diào)出彈窗進(jìn)行表的增減。

這種交互，既能夠進(jìn)行表的批量選擇，又能夠針對單個表進(jìn)行設(shè)置。個人對這個交互還是比較滿意的。

這里提一點(diǎn)，因?yàn)閿?shù)據(jù)集成源端和目標(biāo)端是多種多樣的，所以在具體界面顯示上，可能會根據(jù)不同的數(shù)據(jù)源類型有特殊的區(qū)別。

第四步：目標(biāo)庫設(shè)置

在目標(biāo)庫設(shè)置中，會進(jìn)行比較復(fù)雜的表級別的映射關(guān)系，這個界面和單表模式下的字段映射是類似的，會為每一個源端表來選擇一個目標(biāo)端的表進(jìn)行映射。當(dāng)然和源端一樣在不同數(shù)據(jù)源類型下，界面也會有所不同，還會有些是否創(chuàng)建表，是否有沖突策略，寫入前、寫入后的執(zhí)行策略等等。

第五步：預(yù)檢查

最后一步是一步預(yù)檢查，是在創(chuàng)建任務(wù)這一刻來保證任務(wù)成功運(yùn)行所必須的一些條件是否都完全具備的。如源端、目標(biāo)端的聯(lián)通性，權(quán)限是否開啟，是否有一些必須的log權(quán)限等等。

三、運(yùn)維的過程

個人單表模式的數(shù)據(jù)集成和批量模式的數(shù)據(jù)集成都涉及過，最終個人比較喜歡批量模式，在運(yùn)維過程中也主要說下批量模式的運(yùn)維。這中模式下希望能夠創(chuàng)建的時候能夠批量創(chuàng)建，運(yùn)維的時候能夠單個運(yùn)維。達(dá)到這種效果就可以。

1. 子任務(wù)及實(shí)例是打開新頁面，還是在原有頁面上左右伸縮顯示

雖然創(chuàng)建是批量創(chuàng)建的，但是實(shí)際的日常運(yùn)維是需要到子任務(wù)級別的，查看子任務(wù)的實(shí)例日志、狀態(tài)，對子任務(wù)進(jìn)行操作。所以從主任務(wù)打開子任務(wù)是怎樣的交互。

最開始是打開一個新頁面，在新頁面中對子任務(wù)進(jìn)行交互操作。后來發(fā)現(xiàn)需要頻繁的切換主任務(wù)，就意味的需要打卡的新頁面就很多。后來進(jìn)行了調(diào)整，在同一個頁面中左右顯示主任務(wù)和子任務(wù)，也就是在點(diǎn)擊主任務(wù)的時候，子任務(wù)能夠在右側(cè)已抽屜的形式展示出來，這樣就即能夠?qū)崿F(xiàn)主任務(wù)的靈活切換，又能夠很方便的查看子任務(wù)，對子任務(wù)進(jìn)行操作。

通過這次調(diào)整，也是發(fā)現(xiàn)產(chǎn)品確實(shí)是在使用過程中打磨完善的。有時候經(jīng)?？吹教貏e復(fù)雜的交互的產(chǎn)品，可能在最初的時候，都是功能很單一，交互很簡單的。只不過在產(chǎn)品的不斷使用過程中完善的。不需要奢望產(chǎn)品在最初就特別的復(fù)雜，功能特別的多，只要是在一條正確的路上，等待產(chǎn)品自己生長就可以了。

2. 創(chuàng)建的批量，下線是單個

前面說了雖然創(chuàng)建是批量的，但是運(yùn)維顯示的子任務(wù)、子實(shí)例都是單獨(dú)的，同樣，這對子任務(wù)的上下線需要能夠進(jìn)行單獨(dú)調(diào)整的。這也是運(yùn)維靈活性的一個體現(xiàn)。

四、是離線還是實(shí)時任務(wù)

因?yàn)樵诠ぷ髦薪佑|離線相關(guān)偏多些，所以上面的視角也是離線視角進(jìn)行的交互，但是其實(shí)大部分也是和實(shí)時適用的。和不同數(shù)據(jù)源界面需要做相應(yīng)調(diào)整類似，在做實(shí)時的時候也需要針對具體實(shí)時的數(shù)據(jù)源做相應(yīng)調(diào)整。

總結(jié)

整體來說向?qū)降臄?shù)據(jù)集成設(shè)計(jì)過了三次了，第一次純參考競品，第二次單行了基于單表的升級，第三次基于批量模式的升級。

當(dāng)然，也會有些覺得還需要增強(qiáng)的，比如：同步的數(shù)據(jù)量的統(tǒng)一監(jiān)控、實(shí)時同步的數(shù)據(jù)源要不要管控起來。當(dāng)然，這也是需要需求來推動的。隨著需求場景的不斷擴(kuò)展，再增加產(chǎn)品功能，產(chǎn)品是生長出來的，不需要一口氣全部都增加上。