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

此圖為Atlas的架構圖，主要包含的組件如圖所示，我們主要關注于在Core組件中使用JanusGraph圖數(shù)據(jù)庫來存儲元數(shù)據(jù)對象。Atlas采用了分布式圖數(shù)據(jù)庫JanusGraph作為數(shù)據(jù)存儲，目的在于用有向圖靈活的存儲、查詢數(shù)據(jù)血緣關系。默認情況下元數(shù)據(jù)存儲配置為 HBase ，索引存儲配置為 Solr。也可以通過構建相應的配置文件使用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ù)庫中的多個頂點與邊，相比關系型數(shù)據(jù)庫直接查詢一行數(shù)據(jù)要復雜的多，當然使用圖數(shù)據(jù)庫作為底層存儲也存在它的優(yōu)勢，比如可以支持復雜的數(shù)據(jù)類型和更好的支持血緣數(shù)據(jù)的讀寫。

JanusGraph與應用的集成，有如下兩種方式：

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

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

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

基于以JanusGraph圖數(shù)據(jù)庫為例，結合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ù)據(jù)存儲，關系建立，數(shù)據(jù)血緣建立，數(shù)據(jù)快速查詢提供便利。

寫在最后

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

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

精選提問：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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