數(shù)據(jù)平臺產(chǎn)品-數(shù)據(jù)集成篇–拖拽式數(shù)據(jù)集成
在進行用戶跨系統(tǒng),或者數(shù)據(jù)搬運的情況下,一般使用拖拽式的開發(fā)形式。國外一般歸類于ETL產(chǎn)品中,對應的組件是源端組件、轉(zhuǎn)換組件、目標端組件,具體如何設計,請看這篇文章。
拖拽式的數(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ù)據(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)品象限的領導者地位。不過話說來也挺怪的在國內(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)品,我為什么設計過?
這是在一家公司做乙方的時候,一家公司曾經(jīng)使用過IBM DataStage,所以當他們想上云時,也需要同樣的類似功能,基于此設計、實現(xiàn)一套拖拽式的數(shù)據(jù)集成工具。
整體的設計還是不會擺脫數(shù)據(jù)集成的三部分—ETL,對應的組件就是:源端組件、轉(zhuǎn)換組件、目標端組件。各個組件里面的展示細節(jié),也在不斷打磨中,這個過程更像產(chǎn)品是生長出來的感覺。不需要在一開始就要求是最好,讓產(chǎn)品發(fā)生。
一、源端組件
源端插件是整個數(shù)據(jù)集成中的數(shù)據(jù)開始進入的地方,所以交互上第一步就是先選擇一個數(shù)據(jù)源類型,根據(jù)類型變化具體類型下面的數(shù)據(jù)源的選擇。選完數(shù)據(jù)源之后,選擇一個具體的表,就完成了源端設置了。
二、目標端組件
目標端插件和源端設計一樣,也需要先選擇一個數(shù)據(jù)源類型,再根據(jù)類型確定具體的數(shù)據(jù)源可以進行哪些不同設置,目標端是整個數(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)品升級及上云都沒有接觸過,上述僅做參考),可以設計很復雜的交互,直接讓字段和字段建立映射。
但是在B/S架構(gòu)中,如果也使用這種交互,當打開的組件過多時,整個瀏覽器會變得特別的卡。所以,需要針對B/S對這種有字段映射的拖拽式開發(fā),需要有一種不同的形式來完成字段映射。這部分將在后面的組件間的字段映射部分做詳細說明。
三、轉(zhuǎn)換組件
轉(zhuǎn)換組件,是數(shù)據(jù)集成的能力體現(xiàn),轉(zhuǎn)換組件強大,則拖拽式的數(shù)據(jù)集成能力就強大。轉(zhuǎn)換式組件的 設計思路基本上就和SQL中的一些關鍵字的抽象,同時參考powercenter的現(xiàn)有的一些組件,在初期的時候,設計了以下的轉(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ù)傳遞都是字段級別的,所以這個拉線是表級別的還是字段級別的。
在設計之初的時候想打開兩個插件,然后將兩個插件內(nèi)部的每個字段進行一個行級別的對應映射,但是這樣做的話一方面是交互特別復雜,而在瀏覽器中不能做到這么靈活的交互,一方面如果字段特別多,都開發(fā)的話,占用瀏覽器內(nèi)存過多,交互過程會比較卡(CS架構(gòu)的Informactica powercenter就是這種打開后字段級別的交互,但是也很好奇遷移到云上之后,他們是怎么交互的)。于是就選擇了另一個中交互,也就是只是表級別,在表之間連線,然后傳遞上游所有字段到下游。在下游中進行字段映射。映射過程中字段對應關系怎么體現(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)品的樂趣。
本文由 @數(shù)據(jù)小吏 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
Agile Query 已經(jīng)做不需要關心JOIN 和UNION