在進(jìn)行用戶跨系統(tǒng)，或者數(shù)據(jù)搬運(yùn)的情況下，一般使用拖拽式的開發(fā)形式。國(guó)外一般歸類于ETL產(chǎn)品中，對(duì)應(yīng)的組件是源端組件、轉(zhuǎn)換組件、目標(biāo)端組件，具體如何設(shè)計(jì)，請(qǐng)看這篇文章。

拖拽式的數(shù)據(jù)集成，到底屬于數(shù)據(jù)集成還是數(shù)據(jù)開發(fā)，一直會(huì)有這個(gè)疑問；在加工過程中的各個(gè)組件，又能進(jìn)行負(fù)責(zé)的轉(zhuǎn)換、計(jì)算等操作。屬于數(shù)據(jù)加工吧，這種拖拽式的加工，在國(guó)內(nèi)不普及，開發(fā)人員開發(fā)能力強(qiáng)，還不如直接使用SQL腳本進(jìn)行開發(fā)了。兩邊都靠，兩邊都不是，甚至?xí)霈F(xiàn)到底在國(guó)內(nèi)場(chǎng)景下是不是有必要的討論。

這里把這種拖拽式的開發(fā)形式，一般主要用戶跨系統(tǒng)，或者說數(shù)據(jù)搬運(yùn)的情況下使用，屬于歸類于數(shù)據(jù)集成產(chǎn)品。國(guó)外歸類也是把他歸屬到ETL產(chǎn)品中。

這里多說一句：如果在你的產(chǎn)品設(shè)計(jì)里面，既有拖拽式的數(shù)據(jù)集成又有向?qū)降臄?shù)據(jù)集成，在叫產(chǎn)品名稱的時(shí)候，又不想加特別長(zhǎng)的前綴，可以把拖拽式的數(shù)據(jù)集成叫數(shù)據(jù)集成，向?qū)降臄?shù)據(jù)集成叫數(shù)據(jù)同步。這里就用了數(shù)據(jù)集成和數(shù)據(jù)同步在解釋上的細(xì)微的區(qū)別，一個(gè)專注于數(shù)據(jù)的整合和數(shù)據(jù)處理，一個(gè)更注重?cái)?shù)據(jù)的傳輸和一致性。這也就是開始說的依據(jù)具體的上下文場(chǎng)景、團(tuán)隊(duì)內(nèi)的稱呼習(xí)慣等靈活決定。

在轉(zhuǎn)做產(chǎn)品經(jīng)理之前，用過很長(zhǎng)時(shí)間的拖拽類數(shù)據(jù)集成產(chǎn)品，就是Informatica powercenter。這款產(chǎn)品常年占據(jù)Genter數(shù)據(jù)集成產(chǎn)品象限的領(lǐng)導(dǎo)者地位。不過話說來(lái)也挺怪的在國(guó)內(nèi)卻缺少一款同類型的產(chǎn)品。也就是說在國(guó)內(nèi)很少見以轉(zhuǎn)換算子特別豐富的拖拽形式進(jìn)行數(shù)據(jù)集成的產(chǎn)品。想了想，可能時(shí)國(guó)內(nèi)開發(fā)人員普遍的代碼能力較強(qiáng)（但是也不對(duì)，難道國(guó)外的開發(fā)人員代碼能力就弱了？），這種拖拽的雖然貌似將門檻降低了，但是卻沒有直接寫SQL的效率、維護(hù)上方便，所以也就沒有這方面的需求，類似的產(chǎn)品也就沒有生長(zhǎng)出來(lái)（聽說拖拽式的AI平臺(tái)也面臨同樣的處境。真正會(huì)AI的人覺得拖拽式開發(fā)麻煩，不會(huì)AI的人對(duì)于各個(gè)算子的參數(shù)又不能很好理解，不知道是不是真的？）。

有需求才會(huì)有產(chǎn)品，既然國(guó)內(nèi)很少用這個(gè)產(chǎn)品，我為什么設(shè)計(jì)過？

這是在一家公司做乙方的時(shí)候，一家公司曾經(jīng)使用過IBM DataStage，所以當(dāng)他們想上云時(shí)，也需要同樣的類似功能，基于此設(shè)計(jì)、實(shí)現(xiàn)一套拖拽式的數(shù)據(jù)集成工具。

整體的設(shè)計(jì)還是不會(huì)擺脫數(shù)據(jù)集成的三部分—ETL，對(duì)應(yīng)的組件就是：源端組件、轉(zhuǎn)換組件、目標(biāo)端組件。各個(gè)組件里面的展示細(xì)節(jié)，也在不斷打磨中，這個(gè)過程更像產(chǎn)品是生長(zhǎng)出來(lái)的感覺。不需要在一開始就要求是最好，讓產(chǎn)品發(fā)生。

一、源端組件

源端插件是整個(gè)數(shù)據(jù)集成中的數(shù)據(jù)開始進(jìn)入的地方，所以交互上第一步就是先選擇一個(gè)數(shù)據(jù)源類型，根據(jù)類型變化具體類型下面的數(shù)據(jù)源的選擇。選完數(shù)據(jù)源之后，選擇一個(gè)具體的表，就完成了源端設(shè)置了。

二、目標(biāo)端組件

目標(biāo)端插件和源端設(shè)計(jì)一樣，也需要先選擇一個(gè)數(shù)據(jù)源類型，再根據(jù)類型確定具體的數(shù)據(jù)源可以進(jìn)行哪些不同設(shè)置，目標(biāo)端是整個(gè)數(shù)據(jù)集成的數(shù)據(jù)終點(diǎn)，從源端導(dǎo)入的數(shù)據(jù)，最終都將到達(dá)目標(biāo)端。

只有一個(gè)源端，連接上一個(gè)目標(biāo)端，其實(shí)就可以完成一個(gè)數(shù)據(jù)集成任務(wù)的開發(fā)了。只是中間沒有任務(wù)的數(shù)據(jù)轉(zhuǎn)換，僅僅是數(shù)據(jù)的同步。（這時(shí)候就細(xì)微的發(fā)現(xiàn)數(shù)據(jù)同步和數(shù)據(jù)集成兩個(gè)名詞之間的一點(diǎn)區(qū)別了）

目標(biāo)端組件和源端組件在交互上最大的不同點(diǎn)是，目標(biāo)端組件在數(shù)據(jù)寫入的過程中有一個(gè)字段映射的問題。Powercenter是一個(gè)C/S架構(gòu)產(chǎn)品（Informatica Powercenter 的使用是基于2013年的版本，當(dāng)時(shí)是B/S 架構(gòu)，后續(xù)的產(chǎn)品升級(jí)及上云都沒有接觸過，上述僅做參考），可以設(shè)計(jì)很復(fù)雜的交互，直接讓字段和字段建立映射。

但是在B/S架構(gòu)中，如果也使用這種交互，當(dāng)打開的組件過多時(shí)，整個(gè)瀏覽器會(huì)變得特別的卡。所以，需要針對(duì)B/S對(duì)這種有字段映射的拖拽式開發(fā)，需要有一種不同的形式來(lái)完成字段映射。這部分將在后面的組件間的字段映射部分做詳細(xì)說明。

三、轉(zhuǎn)換組件

轉(zhuǎn)換組件，是數(shù)據(jù)集成的能力體現(xiàn)，轉(zhuǎn)換組件強(qiáng)大，則拖拽式的數(shù)據(jù)集成能力就強(qiáng)大。轉(zhuǎn)換式組件的 設(shè)計(jì)思路基本上就和SQL中的一些關(guān)鍵字的抽象，同時(shí)參考powercenter的現(xiàn)有的一些組件，在初期的時(shí)候，設(shè)計(jì)了以下的轉(zhuǎn)換組件:

1. 表達(dá)式組件-Map

在表達(dá)式組件內(nèi)部，對(duì)行級(jí)別的處理，可以新增行，將原有行數(shù)據(jù)進(jìn)行拆解、進(jìn)行規(guī)范化、新增一行默認(rèn)值等等。

2. 過濾組件-Filter

過濾組件其實(shí)并不是必須的，大可以在源端組件中直接完成過濾即可。這樣進(jìn)入整個(gè)數(shù)據(jù)集成的數(shù)據(jù)就會(huì)少很多。

3. JOIN組件

實(shí)現(xiàn)的功能和SQL的join邏輯是一樣的，將兩張表連接在一起。也會(huì)分內(nèi)連接、外連接等的區(qū)別。在界面上輸入是兩個(gè)，輸出是一個(gè)。也僅僅支持兩個(gè)輸入，多余三個(gè)join的話，就將上兩個(gè)的結(jié)果，繼續(xù)join第三張表。

4. Union組件

實(shí)現(xiàn)兩張表的union，實(shí)現(xiàn)的功能和SQL中的Union也是一樣的。

5. 分組聚合組件-Aggregator

對(duì)輸入表進(jìn)行分組聚合的計(jì)算。

四、組件間的字段映射

兩個(gè)組件如何實(shí)現(xiàn)數(shù)據(jù)傳輸那，其實(shí)就是拉線，拉一條線，表示數(shù)據(jù)從上游傳遞到了下游。我們所有數(shù)據(jù)傳遞都是字段級(jí)別的，所以這個(gè)拉線是表級(jí)別的還是字段級(jí)別的。

在設(shè)計(jì)之初的時(shí)候想打開兩個(gè)插件，然后將兩個(gè)插件內(nèi)部的每個(gè)字段進(jìn)行一個(gè)行級(jí)別的對(duì)應(yīng)映射，但是這樣做的話一方面是交互特別復(fù)雜，而在瀏覽器中不能做到這么靈活的交互，一方面如果字段特別多，都開發(fā)的話，占用瀏覽器內(nèi)存過多，交互過程會(huì)比較卡（CS架構(gòu)的Informactica powercenter就是這種打開后字段級(jí)別的交互，但是也很好奇遷移到云上之后，他們是怎么交互的）。于是就選擇了另一個(gè)中交互，也就是只是表級(jí)別，在表之間連線，然后傳遞上游所有字段到下游。在下游中進(jìn)行字段映射。映射過程中字段對(duì)應(yīng)關(guān)系怎么體現(xiàn)那，最簡(jiǎn)單也是最不友好的形式就是默認(rèn)從上到下的一一映射。

友好一些的就是將上游的將字段傳遞到下游插件，在下游插件內(nèi)部展示上游字段，然后在下游插件內(nèi)部自己做字段對(duì)照。 如果上游的字段進(jìn)行字段變更了，那么下游什么時(shí)候獲取到這寫變更的字段，這個(gè)是增加了一個(gè)局部保存還是全局保存的能力來(lái)做的。

源端、目標(biāo)端、中間轉(zhuǎn)換插件（算子），通過插件間的映射鏈接連接到一起。就是一個(gè)完成的拖拽式的數(shù)據(jù)集成任務(wù)了。

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

在上面介紹的所有算子，其實(shí)都是從離線的視角來(lái)介紹的。但是對(duì)于實(shí)時(shí)的視角其實(shí)一樣適用。只是中間的轉(zhuǎn)換算子不一樣。

這個(gè)如果是離線的那個(gè)就可以當(dāng)做一個(gè)普通的離線任務(wù)，放在離線的DAG圖中，配置調(diào)度，如果是一個(gè)實(shí)時(shí)的，就可以直接啟動(dòng)運(yùn)行了。

六、總結(jié)

做產(chǎn)品的過程，就是實(shí)現(xiàn)自己想法的過程，在實(shí)現(xiàn)了拖拽式數(shù)據(jù)集成之后，算是實(shí)現(xiàn)了一個(gè)做產(chǎn)品的個(gè)人小目標(biāo)?？粗患挛镌谧约旱囊?guī)劃中實(shí)現(xiàn)，還是很欣喜的，這可能是創(chuàng)造的樂趣，也是做產(chǎn)品的樂趣。