一、HGraphDB概述
圖無處不在，社交和電商領域每天都會產生大量的實體連線資料，而描述圖的方式往往是使用包括頂點和邊以及豐富的屬性的屬性圖來展現。在如今的2018年，社交網路和電商資料往往能夠形成非常大的實體圖，包括數十億頂點和百億條邊這樣的資料量。而面對這樣巨大的資料量，傳統關係型資料庫往往難以處理。

談到為什麼會出現圖資料庫，這就要談到關係型資料表達能力遠遠不夠的問題了。SQL表達非常複雜，往往需要多張表進行級聯查詢，而使用圖資料結構則會更加貼近於真實世界。

HGraphDB底層基於HBase進行資料儲存，方便進行水平擴充套件。其次，HGraphDB基於Tinker pop3實現，因此支援整合Tinker pop3全套軟體棧以及Gremlin語言。此外，HGraphDB是一個OLTP相簿，支援schema以及頂點和邊的增刪改查還有圖的遍歷。

HGraphDB支援底層的資料接入，可以通過檔案以及實時的對外介面訪問到HGraphDB的資料層。其底層的持久化是在HBase上，通過Gremlin的圖片裡實現實時的推薦和K跳查詢。而還可以通過與Spark的整合直接分析HBase資料庫實現諸如PageRank、聯通子圖等常用的圖計算。

對於HGraphDB的全棧而言，因為偏向於OLTP，因此其核心在於Gremlin-server上，其內部包含HGraphDB的核心驅動層，其是底層的資料模型，主要負責底層對於HBase的資料訪問。而因為很多使用者往往攜帶資料使用HGraphDB產品，因此Graph-loader就可以做一些檔案格式的解析，進而將資料批量匯入到HBase資料庫裡面。Gremlin-server還能夠提供HTTP和Web Socket服務，因此在客戶端裡面可以通過SDK、HTTP以及Web Socket來訪問圖資料庫。同時，也可以通過命令列實現圖的遍歷以及計算等操作。

二、深入解析HGraphDB
資料模型-全域性有序索引表
因為HGraphDB提供的是屬性圖，因此包括頂點和邊以及屬性，而因為HBase是一個Key-Value的表格系統，因此很容易實現訂單和邊的屬性集的持久化儲存。但是在圖裡面，一跳二跳相對而言比較麻煩，對於此採用了全域性有序索引表來解決，通過二級索引進一步找到全部屬性集。

如下圖所示的是底層表格儲存的真實的Schema格式，可以看到能夠將頂點相關的In和Out這些邊緊密地放在一起，只需要進行一次運算就可以拿到所有的相關頂點和邊的資料。而對於Vertex表和Edge表而言，其RowKey分別是其ID，屬性則通過寬列或者寬表的方式表現出來。

Gremlin是一種類SQL的方言，如下圖所示的就是Gremlin的DSL，也就是領域特定語言，而在Tinker pop中包含了Gremlin的直譯器。

Gremlin執行引擎的執行計劃如下所示，三個步驟會形成一個Pipeline，採用懶迭代方式，而底層會對於HBase資料表進行訪問，並且其執行效率是非常高的。

三、HGraphDB圖分析
僅有了圖資料庫的OLTP能力是遠遠不夠的，還需要進行圖分析，這一點是通過Spark graphframes實現的。Spark graphframes可以實現常見的分析，比如filter/agg計算、以及count和sum等。這些計算在底層可以轉化成基於Graphx的圖計算，進而可以實現pagerank、最短路徑。實施推薦、最小生成樹、聯通分量以及kcore等計算。Spark graphframes既可以滿足進行常規彙總統計的需求，也滿足測試和機器學習相關的迭代計算需求。

HGraphDB支援圖計算的程式設計框架——GAS分解。GAS分解類似於MapReduce思想，其主要是面向頂點的程式設計思想，其包含了計算引擎在內，因此只需要編寫想要實現的內容即可。也就是將程式拆解成三部分：Gather、Apply和Scatter。HGraphDB裡面有很多分割槽，一個頂點會有多個不同的Partition，每個Partition裡面先去做計算，之後將計算的值彙總到Master中，因此第一步叫做Gather。第二步叫做Apply，也就是改變Master節點的值。當將值修改完之後，Scatter步驟會將當前值分發到映象頂點，將映象頂點的值也更新完畢，同時通知鄰接頂點重新進行計算。

如下圖所示的是使用Spark graphframes進行圖分析計算的示例。

目前，HGraphDB產品已經開放到了阿里雲上。而在實現HGraphDB的過程中也做了不同的技術選型，比如與比較熱門的janusgraph進行了對比和評測。之所以選擇基於HGraphDB，是因為其程式碼量比較小，功能比較明確，可以基於其進行重寫和二次開發，但是janusgraph在做資料匯入的時候可能無法匯入或者效率極低，在資料量大的時候，效能也會急劇下降。而HGraphDB支援使用者指定ID，而janusgraph無法實現。對於資料匯入而言，janusgraph匯入邊資料困難，效率極低，而由於janusgraph需要支援底層所有表格儲存系統，而HGraphDB直接基於HBase進行了優化。此外，janusgraph做了一層抽象，將HBase完全當成黑盒，因此效能表現不佳。

四、使用場景以及未來工作
使用場景主要包括以下三個方面：
使用者360：因為HGraphDB提供的是屬性圖，因此可以很容易地拿到使用者屬性的子圖。
個性化推薦：基於圖能夠很容易地實現個性化推薦。
欺詐檢測：可以人工標註一些黑產頂點，如果和這個頂點太近，就可能存在問題。

未來改進方向
HGraphDB是Gremlin的DSL的一種標準實現，而Gremlin提供了很多鉤子讓使用者自己實現執行器的優化，但是現在的HGraphDB目前傳輸的資料量比較大，並且自身的計算能力有限，因此做全表掃描比較吃力，所以在執行器上具有較大優化空間。此外，還可以將詞聚合等運算元下推，以及能夠增強圖分析能力，將Spark作為內嵌分析引擎，實現Tinker pop OLAP規範。

感想：在如今的2018年，社交網路和電商資料往往能夠形成非常大的實體圖，面對這樣巨大的資料量，傳統關係型資料庫往往難以很好地處理，因此就需要圖資料庫來幫助解決。而HGraphDB底層基於HBase實現，支援Tinker pop3的全套軟體棧以及Gremlin語言，並且支援OLTP等，是解決圖計算問題一個非常優秀的工具。