訂閱
糾錯
加入自媒體

探索圖數(shù)據(jù)庫在數(shù)據(jù)資產(chǎn)可視化中的應(yīng)用

2020-07-09 10:04
EAWorld
關(guān)注

Apache Atlas為組織提供了開放的元數(shù)據(jù)管理和治理功能,以建立其數(shù)據(jù)資產(chǎn)的目錄,對這些資產(chǎn)進行分類和治理,并為數(shù)據(jù)科學家,分析師和數(shù)據(jù)治理團隊提供圍繞這些數(shù)據(jù)資產(chǎn)的協(xié)作功能。

此圖為Atlas的架構(gòu)圖,主要包含的組件如圖所示,我們主要關(guān)注于在Core組件中使用JanusGraph圖數(shù)據(jù)庫來存儲元數(shù)據(jù)對象。Atlas采用了分布式圖數(shù)據(jù)庫JanusGraph作為數(shù)據(jù)存儲,目的在于用有向圖靈活的存儲、查詢數(shù)據(jù)血緣關(guān)系。默認情況下元數(shù)據(jù)存儲配置為 HBase ,索引存儲配置為 Solr。也可以通過構(gòu)建相應(yīng)的配置文件使用BerkeleyDB存儲元數(shù)據(jù)存儲 和使用ElasticSearch存儲 Index。元數(shù)據(jù)存儲用于存儲元數(shù)據(jù)對象本身,索引存儲用于存儲元數(shù)據(jù)屬性的索引,其允許高效搜索。

Atlas定義了一套atlas-graphdb-api,允許采用不同的圖數(shù)據(jù)庫引擎來實現(xiàn)api,便于切換底層存儲。所以Atlas讀寫數(shù)據(jù)的過程可以看作就是將圖數(shù)據(jù)庫對象映射成Java類的過程,基本流程如下:

在Atlas中查詢某一個元數(shù)據(jù)對象時往往需要遍歷圖數(shù)據(jù)庫中的多個頂點與邊,相比關(guān)系型數(shù)據(jù)庫直接查詢一行數(shù)據(jù)要復(fù)雜的多,當然使用圖數(shù)據(jù)庫作為底層存儲也存在它的優(yōu)勢,比如可以支持復(fù)雜的數(shù)據(jù)類型和更好的支持血緣數(shù)據(jù)的讀寫。

JanusGraph與應(yīng)用的集成,有如下兩種方式:

第一種:可以把JanusGraph嵌入到應(yīng)用程序中去,JanusGraph和應(yīng)用程序處在同一個JVM中。應(yīng)用程序中的客戶代碼(相對JanusGraph來說是客戶)直接調(diào)用Gremlin去查詢JanusGraph中存儲的圖,這種情況下外部存儲系統(tǒng)可以是本地的,也可以處在遠程。

第二種:應(yīng)用程序和Janus Graph處在兩個不同JVM中,應(yīng)用通過給JanusGraph提交Gremlin查詢給GremlinServer,來使用JanusGraph,因為JanusGraph原生是支持Gremlin Server的。(Gremlin Server是Apache Tinkerpop中的一個組件)。

下面就展示實際基于JanusGraph圖數(shù)據(jù)庫的可視化展現(xiàn)情況:

基于以JanusGraph圖數(shù)據(jù)庫為例,結(jié)合Atlas獲取hadoop生態(tài)系統(tǒng)的元數(shù)據(jù)思路,未來數(shù)據(jù)資產(chǎn)可視化擴展對大數(shù)據(jù)的采集能力,以kafka作為消息系統(tǒng),解耦生產(chǎn)者和消費者,圖數(shù)據(jù)庫作為數(shù)據(jù)處理核心,以Hbase、solr,es,zookeper等技術(shù)作為輔助手段。為數(shù)據(jù)存儲,關(guān)系建立,數(shù)據(jù)血緣建立,數(shù)據(jù)快速查詢提供便利。

寫在最后

基于對圖數(shù)據(jù)庫知識的探索,圖數(shù)據(jù)庫在未來數(shù)據(jù)資產(chǎn)可視化中的應(yīng)用將會是促進數(shù)據(jù)價值提升,提高企業(yè)數(shù)據(jù)資產(chǎn)配置效率的有效手段,企業(yè)可以通過圖數(shù)據(jù)庫建立企業(yè)數(shù)據(jù)資產(chǎn)全景圖,快速搜索定位,形成有效的數(shù)據(jù)交匯,以個性化展現(xiàn)企業(yè)的數(shù)據(jù)資產(chǎn),方便使用者獲取關(guān)鍵信息,更好的了解數(shù)據(jù)資產(chǎn)的各個方面。

以上是我分享的內(nèi)容以及一些不成熟的思考,希望跟大家一起探討。

精選提問:

問1:圖數(shù)據(jù)庫增刪改查有特定語法嗎?

答:根據(jù)不同類型的圖數(shù)據(jù),所支持的語法也是不一樣的。

問2:看到上面列舉了四種圖數(shù)據(jù)庫的比較,在實際使用中,傾向于用哪個產(chǎn)品?為什么?

答:每個圖數(shù)據(jù)庫都有不同的優(yōu)點和缺點,需要看產(chǎn)品的需求,注重哪方面的,比如說更關(guān)注于性能,更專注于擴展性等。

問3:有些公司字段依賴是自己解析sql實現(xiàn)的,但是我還沒具體思路。。。老師能提示下嗎?

答:目前是通過sql解析器對sql腳本做解析,例如sqlparser,比如說解析存儲過程,perl腳本什么的。

問4:mongodb支持圖數(shù)據(jù)庫嗎?圖數(shù)據(jù)庫的應(yīng)用場景在哪里?

答:mongodb屬于nosql數(shù)據(jù)庫的一種,和圖數(shù)據(jù)是不一樣的。圖數(shù)據(jù)庫的應(yīng)用場景有很多,比如最典型的知識圖譜,在數(shù)據(jù)資產(chǎn)管理中,我認為更多的應(yīng)用數(shù)據(jù)資產(chǎn)可視化展現(xiàn),以及數(shù)據(jù)地圖,數(shù)據(jù)影響/血緣分析等。

問5:生產(chǎn)者和消費者解耦,有啥優(yōu)勢?

答:生產(chǎn)者和消費者更多的應(yīng)用在并發(fā)的過程中,可以并行的執(zhí)行。把生產(chǎn)者和消費者當做兩個獨立的并發(fā)主體,不互相依賴,也就是說生產(chǎn)者生產(chǎn)完直接把數(shù)據(jù)丟到緩存中,并不需要關(guān)系消費者是否使用,而消費者也并不需要等待生產(chǎn)者,可以加快處理速度。

問6:不過現(xiàn)在市面上,還有一個產(chǎn)品是百度Hugegraph,您覺得這個與Neo4j和JanusGraph有什么區(qū)別和優(yōu)缺點?

答:HugeGraph是基于TinkerPop,很大程度上借鑒了JanusGraph,只是再次基礎(chǔ)上做了二次開發(fā)和封裝,更加的易用。而JanusGraph可能更多的需要自己做配置。

問7:如何做傳統(tǒng)關(guān)系型數(shù)據(jù)庫數(shù)據(jù)和圖數(shù)據(jù)庫的數(shù)據(jù)遷移呢?

答:大部分的圖數(shù)據(jù)庫都會給出接口或者導(dǎo)出腳本,把數(shù)據(jù)庫從關(guān)系型數(shù)據(jù)庫遷移到圖數(shù)據(jù)庫上,但是導(dǎo)出的性能會有很大差異。現(xiàn)在并沒有統(tǒng)一的標準,更多的依賴開源。

問8:如果是中小型企業(yè)做基于工商數(shù)據(jù)的圖數(shù)據(jù)庫,在學習成本及硬件,軟件成本上。市面上這幾種圖數(shù)據(jù)庫有優(yōu)先級么?

答:個人認為,在關(guān)注于學習成本、軟件成本、易用性等方面考慮的話,推薦使用收費的軟件,不推薦使用開源的軟件,目前企業(yè)版收費的有Neo4j,ArangoDB等,項目成熟,社區(qū)活躍,文檔也很成熟。企業(yè)學習部署更方便。

<上一頁  1  2  3  4  
聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請聯(lián)系舉報。

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續(xù)

暫無評論

暫無評論

人工智能 獵頭職位 更多
掃碼關(guān)注公眾號
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯
x
*文字標題:
*糾錯內(nèi)容:
聯(lián)系郵箱:
*驗 證 碼:

粵公網(wǎng)安備 44030502002758號