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

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

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

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

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

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

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

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

一、源端組件

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

二、目標端組件

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

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

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

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

三、轉(zhuǎn)換組件

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

1. 表達式組件-Map

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

2. 過濾組件-Filter

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

3. JOIN組件

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

4. Union組件

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

5. 分組聚合組件-Aggregator

對輸入表進行分組聚合的計算。

四、組件間的字段映射

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

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

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

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

五、是離線還是實時任務

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

這個如果是離線的那個就可以當做一個普通的離線任務，放在離線的DAG圖中，配置調(diào)度，如果是一個實時的，就可以直接啟動運行了。

六、總結(jié)

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