Amazon Neptune 圖資料庫 (Graph Database)學習和資料視覺化(Data Visualization)是我在公司這次的創新Idea Sprint的研究主題。

前言

我們公司每三個月都會有一個Sprint叫做創新Idea Sprint，在這個Sprint，工程師們可以去研究自己想要研究的技術，然後在Sprint結尾秀出自己的研究成果給大家看。

而這次的形式和以往有點不同，美國團隊那邊提出可以嘗試看看跨團隊合作，意思就是我們可以去找別的部門/團隊合作，然後一起研究技術，增進跨團隊的溝通能力，以及讓研究的技術更多樣化。

我覺得是很難得的機會，這次本來有在想要不要去問問美國團隊有沒有人要一起合作搞點什麼創新，但是我看他們的Idea版上沒什麼美國人的名字，所以我也不知道能找誰，在專案經理早了一週就開始詢問每個人的計畫，然後當時只是覺得

Neptune 這個名字看起來很Cool，然後看到 Visualization (視覺化) 就覺得是不是又有前端可以開搞XDD，我至從今年初開始學前端，就對一些視覺化的玩意兒有興趣。所以，就把我的名字填在那張Idea卡片下方。

然後就和另外一個台灣的團隊組員一起研究 AWS Neptune Service 和 Data Visualization，進而產生了這篇文章。

從第一家公司畢業後，我就很少寫後端技術相關的文章，我覺得我那時處於的技能層跟想寫的文章好像都太基礎了，會有很多後端大神寫的比我更好，所以近年來都沒有在撰寫後端技術的文章，不過這次有這個機會我也很高興，能在後端技術中分享些新技術的知識。

Objective

我們這次的主題叫做 Amazon Neptune 圖資料庫 (Graph Database)學習和資料視覺化(Data Visualization)。

我跟另外一個組員對Graph Database 完全是0經驗，我們有2~3週的時間，從0開始學習，然後到可以用AWS的Neptune服務作出一些初步的實作，所以這篇文章不會介紹到太困難的技術層面，然後所有的內容直接切重點。

文章內容大致如下:

• 學習圖資料庫(Graph Database)的基本概念
  • NoSQL
  • Graph DB 存資料的概念: Nodes, Edges, Label, Properties
  • 處理資料的語言 Query Language: Gremlin
  • 關聯式資料庫(RDB) VS 圖資料庫(Graph DB)
• 實作Part
  • 開啟 Amazon Neptune 資料庫 + Jupyter Notebook
  • 用 Gremlin 語言做簡單的塞資料跟搜尋資料
  • 實現資料視覺化 (Data Visualization)
    • aws/graph-notebook
    • G.V()
    • Gremlify

你準備好了嗎？

基本概念 Basic Knowledge

大概掌握下面幾個抽象概念就可以大致上了解 Graph DB。

• NoSQL
• Nodes, Edges, Label, Properties
• Query Language
• 關聯式資料庫(RDB) VS 圖資料庫(Graph DB)

NOSQL

首先，Graph DB 不是關聯式資料庫，他跟一般接觸到的關聯式資料庫像是 MySQL, PostgreSQL, SQLite 不是同一路的技術，就是說存取資料的方式會不同，畢竟資料庫就是存資料的地方，但並不是每個資料都適合像是關聯式資料庫那樣的表格式一筆一筆資料存取。

從上表來看就能知道Graph DB是一種 NoSQL 形式的資料庫，可以清楚知道他處在什麼位置什麼分類。

Nodes, Edges, Label and Property

再來介紹 GraphDB 存取資料的抽象概念，如果說關聯式資料庫的名詞是 Table, Column, Primery Key 跟 Foreign Key，那Graph DB 的名詞就會是Nodes, Edges, Label 和 Property。

來個表格整理一下

以上就是大致 Graph DB的資料抽象概念。

Query Langauge: Gremlin

再來是處理資料所使用的語言，可以和Graph DB溝通處理資料的語言有 Gremlin, Cypher, GQL, SPARQL, PGQL, GraphQL …，如果說SQL是處理關聯式資料庫的語言，那處理Graph DB就是上面列出來的這幾種。

舉例:

在這個為期2-3週的研究，我們使用Gremlin，可以在AWS Neptune上被支援，當初有想說用Python，但不知道為什麼Python在我測試的Jupyter Notebook 裡完全不work，後來參考AWS的範例，決定使用Gremlin。

來一點 Gremlin Cheat Sheet

%%Gremlin

// 列出所有的 Nodes
g.V()

// 列出限制幾筆 Nodes (25筆)
g.V().limit(25)

// 列出所有的Edges
g.E()

// 列出所有的 Nodes跟他的值
g.V().valueMap()

// 列出所有的 Nodes他本身的Id + 他的值
g.V().valueMap(true)

// 列出所有的 Edges跟他的值
g.E().valueMap(true)

// 刪除所有Nodes <-- 這麼危險的指令當然也要教你們辣
g.V().drop().iterate()

// 刪除所有的Edges
g.E().drop().iterate()

// 加一個 Node
g.V().add("Company")

// 加一個 Node 跟 Property
g.V().add("Company").property(id, "COM-0001").property("name", "Innova").as("COM-0001")
g.V().add("Employee").property(id, "EMP-0001").property("name", "Mina").as("EMP-0001")

// 加一個 Edge 跟 Property (填id)/然後addE是關係的名字: 連接 員工 -> 公司
g.V("EMP-0001").addE("belong").to(__.V("COM-0001")).property("checkIn", "2022-02-14")

// 連續加好多個資料: 尾巴都加 next(), 但最後一筆不要加
g.V().add("Company").property(id, "COM-0001").property("name", "Innova").as("COM-0001").next()
g.V().add("Company").property(id, "COM-0002").property("name", "Google").as("COM-0002").next()
g.V().add("Company").property(id, "COM-0003").property("name", "Tesla").as("COM-0003")

// 撈出同Label的資料，就是你看到上面是Company，會撈出 Innova (Node), Google(Node), Tesla(Node)
g.V().hasLabel("Company")

// 撈出指定id的 Node/Edge
g.V("COM-0001")
g.E("<id>")

大概就以上這些。

關聯式資料庫(RDB) VS 圖資料庫(Graph DB)

	Graph DB	關聯式資料庫(RDBMS)
形式	Nodes, Edges	Tables 有 Rows(幾筆資料) 和 Columns(欄位)
關係	會是使用Edges連結Nodes	關聯跨Table，用 Foreign Keys 去關聯不同的Table
複雜的查詢	搜尋的很快，不需要用Joins語法	需要使用Joins語法才能撈出在不同Table的資料
使用案例	當需要一堆關聯跟關係時，像是社群網站或搜尋引擎。 高連接度的場合，比方說家庭樹/族譜(族譜用在這應該很輕鬆) 資料的Schema/欄位需求需要一直變動(畢竟不用先定義欄位名稱)	存取很多或很複雜的資料, 比方說Json，如果需要做複雜的運算，或者像IoT那樣大量的資料(應該是吧xd?)
長相
優點	如果有額外的屬性可以直接加，不用多新增一個欄位跟定義. 並非所有的資料都有相同的屬性，可以依據不同的資料加不同的屬性 (在關聯式資料庫，就算某筆資料沒有該屬性，但存在同個Table，那筆資料就是要填空). 屬性沒有規定格式，想存數字就數字，想存文字就文字。	比較適合處理大量的資料，比起GraphDB需要用走訪(Tree資料結構)一直去查找下一個節點，關聯式資料庫已經知道所有有多少筆資料了。
缺點	需要特定的Label去撈同個類別的資料(Nodes). 對於你有特定的id想撈一筆資料，其實沒什麼意義。如果你需要在同一個屬性存取很長很複雜的內容，也許不太適合。	看起來是說關聯式資料庫對於深度分析，擁有的效能比較差(這邊大家有空再去查查缺點)

實作Part

解釋完抽象概念後，當然要來一點實作的部分才能理解，這個部分分成三個階段:

• 開啟 Amazon Neptune 資料庫 + Jupyter Notebook
• 用 Gremlin 語言做簡單的塞資料跟搜尋資料
• 實現資料視覺化 (Data Visualization)

那麼就開始吧!

開啟 Amazon Neptune 資料庫 + Jupyter Notebook

我不確定大家要不要用Amazon的Neptune資料庫。

因為很貴

起初想說自己創了一個新帳號，用Free Tier免費方案應該不會扣到錢，但… 一開始免費方案的選項就選錯了，然後也不知道為什麼我選了免費方案的選項還是被扣，所以我總共就是兩個月被扣1400，看起來還好？不是，那是我在11月底玩了一週被扣700塊，然後不知道為什麼在12月初換了一個選項創Neptune又被扣700，真搶錢邪門，但反正…

我這一Part很兩光，會寫的很不負責任，你們自己評估看看吧XD

進到可愛的Amazon頁面，直接在Search Bar上搜尋 Neptune。

請把左上邊三條線點開。

點選 Database，然後按右上方的Create database。

好了這個部分要小心一點。

如果沒記錯的話，AWS Neptune免費方案是 Provisioned + db.t3.medium。

請確認你的地區，如果你怎麼創資料庫都Failed，去確認CloudWatch都報一個錯

那就是，你目前所在的地區(你可以看你右上方的地區)，沒有支援Neptune db.t3.medium 的選項。我可以創的地區是us-east-1。

在Create database 裡，Engine options，請選 Provisioned，Serverless不是免費的。

記住，Serverless不是免費的。

Templates 麻煩選 Development and Testing，DB instance size 請選 Buerstable classes: db.t3.medium。

Connectivity這個部分比較麻煩，關乎到權限問題，如果你沒有權限，還是請你家的MIS或DevOps幫你創吧XD，因為權限很麻煩。但如果你是Root User，就開外掛吧，VPC沒有的話就創一個，其他不用管。

Notebook configuration，我們需要用Jupyter Notebook來跟Neptune這個資料庫連線處理資料，所以要勾選Create notebook，IAM Role 有權限就直接創一個，其他好像都預設設定就可以了。

創完之後會看到資料庫正在創，然後去左邊的選單 Panel 點 Notebooks也會看到Jupter Notebook已經創好且連接於你創的資料庫了。

至於為什麼我這邊給的圖是 serverless? 因為，我的帳號被扣1400，後來我就把資料庫刪了，公司提供一個測試帳號做研究，然後公司的後端權限大神幫我們把資料庫開好了，開serverless選項。

但還是要提醒大家我一開始用我自己的帳號開serverless，不是免費的….，至於Provisioned, 是官方文件上說的，期待勇者驗證讓我知道了。

記得沒有用服務時，要把資料庫跟Notebook都先Stop停止，才不會一直花到錢。

用 Gremlin 語言做簡單的塞資料跟搜尋資料

接下來打開你的Notebook，我們用Gremlin簡單的塞幾筆資料。

首先可以使用指令來看看資料庫裡有什麼！

// 記得，在AWS的Jupyter Notebook 內要用這個語法先標示接下來是Gremlin語言
%%gremlin

// 列出所有 Nodes
g.V()

我的資料庫本來就有些之前輸入的資料，一般來說剛創好的資料庫會是空的，如果有報錯的話，可以檢查一下是不是忘記加 %%gremlin 或檢查是不是資料庫還沒創好或忘記start運行。

接下來我們來加一點資料，就加兩個人吧！

%%gremlin

g.addV("People").
     property(id,"PPL-0001").
     property("name","Amy").
     property("age",29).
     property("gender","F",).
     property("job","Engineer").
     as("PPL-0001").next()

g.addV("People").
     property(id,"PPL-0002").
     property("name","Jason").
     property("age", 31).
     property("gender","M",).
     property("job","Salesmen").
     as("PPL-0002")

我們加兩個 Node(兩個人)，分別是屬People的Label，Property 有id, name, gender, job，一個人名字是Amy，另外一個是Jason。

在用g.V()列出所有Node，便可以看到新增的兩個Node，PPL-0001跟PPL-0002。

然後，如果想看到屬性，可以用

g.V().valueMap(true)

列出所有的Node跟他們的屬性資料。

然後，我們來使用GraphDB特有的功能 Edge，為這兩個人加一點關係。

我想表示Amy喜歡Jason從2022年8月開始。

%%gremlin

// 給PPL-0001 Amy 加一個Edge like喜歡 指向 PPL-0002 Jason，
g.V('PPL-0001').addE('like').to(__.V('PPL-0002'))

可以看到Edge加進去囉！

所以現在在資料庫裡面我們有兩筆Node跟1筆Edge

• PPL-0001
• PPL-0002
• PPL-0001-like->PPL-0002

可是現在的資料都是以文字形式呈現，比較難理解，現在就來到了資料視覺化的部分了！

實現資料視覺化 (Data Visualization)

在我們的研究中，有研究三種方法是對於Graph Database的資料視覺化，其中有兩個工具是不需要真的安裝資料庫，所以如果你覺得害怕Neptune創立後，會花很多錢，但又想玩玩看Graph Database跟Gremlin語法，這邊會提供兩個工具。

總共是下面三個:

• aws/graph-notebook
• G.V()
• Gremlify

aws/graph-notebook

aws/graph-notebook 是一個Python Package，然後可以用Jupyter Notebook使用，所以這次我們的研究實作部分的視覺化呈現，主要就是用這個Package。沒意外的話，在AWS的Notebook創好後，已經內建在裡面。

有興趣的話可以去逛他的內容，不過我們這邊研究了一個指令可以將想要呈現的資料視覺化。

%%gremlin -p v,ine,outv,oute,inv
g.V().or(hasLabel("<Label1>"), hasLabel("<Label2>"))
     .inE().outV()
     .outE().inV().path().by(valueMap(true))

運用這個指令，然後在 or 這邊寫上所有你想要呈現的Label名稱，可以用圖形的方式呈現你的資料。

所以這是，我們剛剛輸入的三個資料，可以點Node或Edge，然後再點右上方的三個線來看屬性。

如果想找關鍵字，可以使用右上方的 Search Bar，輸入你想找的字，會秀出包含關鍵字的Node或者Edge，如圖。

視覺化的部分，我前面沒有輸入太多資料，所以沒怎麼能呈現，來曬一下我們這次研究自己模擬的一個場景，不會牽扯到公司機密。

用一樣的指令執行，可以看到撈出了很多先前創的資料，接著一樣點Graph的部分，就可以看到資料視覺化的呈現。

我承認當時Edge命名不好，所以看起來很亂哈哈。

一樣用Search Bar搜尋名字，該名字相關的Node會跳出。

以上就是用 aws/graph-notebook這個套件在Jupyter Notebook裡視覺化資料的過程。

G.V()

接下來介紹一下G.V()這個軟體，這個軟體是AWS提供Neptune可連接的第三方軟體，其中一個軟體。

他是直接下載到電腦端的桌機軟體，無論是Windows/Mac/Linux版本都有。

這個軟體就很像MySQL WorkBrach的感覺，他允許你可以創一個playground玩耍天地，而不用創任何資料庫，你就可以只在電腦端用Gremlin語言玩Graph Database，然後每個動作，無論是show V或者創V/E，都會有一個按鈕可以看目前的資料視覺化成圖型，可以說是非常方便。

但後來我們停止了研究，有幾個原因。

• 要能連接資料庫，要付費 Pro版本，我們的研究計畫中沒有這個經費。我們本身就希望能夠研究用這個軟體連接Neptune。
• 我發現當 addE，加Edge後，之前輸入的所有Node V都會不見，這會增加我們除錯的天數，所以後來就先停止。我不確定是不是只發生在Playground，我們當初是只有使用Playground。

Gremlify

最後一個資料視覺化的工具是線上網站，不用安裝，目前知道是免費使用，我覺得是如果沒有創資料庫的打算，可以試試看這個線上網站來試玩。

叫做 Gremlify，這個網站我目前沒有實際使用，但之所以這麼推，是因為這個網站是另外一個組員找到的，而且在會議中他也有實際操作給我們看，實際看過後覺得是一個很方便很讚的網站。

沒有圖可以show，但可允許你可以用滑鼠直接創立Node跟Edge，光這點不用輸入指令，我想應該就蠻人性化的哈哈，方便許多。

更多的功能等大家去試玩，有心得再分享給我啦！

好啦，以上就是我們這次跨團隊 Innovative Idea Research的研究筆記。除了跨團隊和其他團的組員合作很新奇之外，我也和我們團隊一直以來都沒合作過的組員一起合作，而且接觸的技術是一個全新0經驗的技術，真的是很棒的經驗，除了紀錄研究筆記外，也特別想把這個經驗給紀錄下來。

尤其在跨團隊合作時，得知該團隊的組員年後要離職，這會是第一次但也是最後一次的合作了，那我們更要趁這次機會好好的研究，好好的創造美好的回憶，好好的準備跟呈現完整我們的努力。