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

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

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

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

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

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

第二種：應(yīng)用程序和Janus Graph處在兩個(gè)不同JVM中，應(yīng)用通過給JanusGraph提交Gremlin查詢給GremlinServer，來使用JanusGraph，因?yàn)镴anusGraph原生是支持Gremlin Server的。（Gremlin Server是Apache Tinkerpop中的一個(gè)組件）。

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

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

寫在最后

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

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

精選提問：

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

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

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

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

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

答：目前是通過sql解析器對(duì)sql腳本做解析，例如sqlparser，比如說解析存儲(chǔ)過程，perl腳本什么的。

問4：mongodb支持圖數(shù)據(jù)庫(kù)嗎？圖數(shù)據(jù)庫(kù)的應(yīng)用場(chǎng)景在哪里？

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

問5：生產(chǎn)者和消費(fèi)者解耦，有啥優(yōu)勢(shì)？

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

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

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

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

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

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

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