Google Cloud的儲存服務介紹

這一篇我們會介紹根據你的業務需求來選擇適合的GCP的儲存服務。同時也介紹甚麼是結構化/半結構化/非結構化的資料模型;與設計SQL與NoSQL Database 的schema.

一開始我們會從以下幾個方面來選擇我們應該用哪種GCP 儲存服務

• 從公司的業務角度來選擇
• 從技術角度來選擇
• 從結構化/半結構化/非結構化的資料模型來選擇
• 從relational and NoSQL 兩個不同型態來設計schema

讀完這一篇文章後根據多種的規則我們應該怎麼選擇GCP 的儲存服務。

從公司的業務角度來選擇

從公司的業務角度來看我們就要跟據需求來看整個Data的life cycle，分為以下四個主要階段

• Ingest
• store
• Process and Analyze
• Explore and visualize

Ingestion是第一個主要階段，最主要是把資料放到GCP中。store就是把資料放在GCP儲存服務中讓它不會消失，並且稍後可以被存取。Process and Analyze是將資料做一些轉換成有用的格式並且可以作為分析之用。最後是Explore and visualize將資料轉化成圖表並從中產生新的洞見。

獲取資料通常我們會有三種Ingestion模式

• Application mode
• Streaming mode
• Batch mode

Application mode

這是由Application 所產生的Data(包含行動裝置類別的)，然後將資料推送到後端系統。資料大約分成兩種，一種是使用者產生的資料(例如交易性資料)，另一種是Application自己產生的資料(例如log/event data).這一類Application資料量的多寡大都取決於使用者的數量，資料種類，以及Application被使用的時間長度來決定。而每一種資料的大小也非常不一樣，滑鼠的點擊資料(可能1KB都不到)到上傳幾MB的圖檔。而在GCP中的Application data大都由這幾種服務產生 : Compute engine, Kubernetes engine, App engine. 而Application data可以 GCP的stackdriver Logging或是託管式的資料庫: 像是 Cloud SQL或 Cloud data Store.

Streaming data

streaming data是一種從資料端持續不斷傳送的小量的資料，這一類的資料通常會是感測器類型(週期性的傳送資料出來)與event data(因特殊事件而產生的資料)。streaming data的類型可能有:

• 機器的監控資料，像是CPU /memory的使用率
• IoT 設備
• 客戶交易資料所產生出來的額外資料

streaming data一定都會包含timestamp(時間戳記)，就是該筆時間產生的時間。這通常也稱作event time. 有些Application會需要這一類的資料來追蹤整個資料處裡流程或是pipeline 的整個處裡時間。有些服務特別需要知道資料的時間序列，這樣資料處理才會準確。但有時因為網路的狀況資料到達後端系統的時間可能就不是照資料產生出來的時間先後到達，所以我們需要一個機制來處理這種狀況。這種機制稱作"緩存"，將後到的資料短暫的儲存下來等待較早產生的資料到達後再依序(資料產生的時間)處理。有關於這一部分的細節我們會在"Google Cloud 資料流程解決方案介紹"文章中介紹。

streaming data對應GCP服務就是Pub/Sub, Pub/Sub ingestion可以處理資料因網路狀況到達的次序不同來排序。 Pub/Sub topic則可以處理因為極短時間湧入大量的資料，保留這些資料讓後端系統有時間慢慢消化(不會因為像地端機房一樣有資源限制而有掉資料或服務掛掉的狀況) 。原因在於GCP pub/sub使用的是Google 的全球節點搭配Google 全球性的Load balacner來支援這樣的短時間大流量的需求。

Batch data

這跟streaming data是相反的，它是一個長時間的區間並且每次傳送的是一個大的資料量，通常是檔案類型的資料。類似這種類型的資料可能有

• 儲存在資料庫裡的一段時間的交易資料然後需要倒到機器學習的data pipeline中
• 歸檔資料
• 你要將Application data從地端移到雲端

GCP的cloud storage 通常運用這種類型的資料將資料放進來。如果要把它變成是自動化的話可以使用Cloud transfer service或是Transfer Appliance(如果你要搬的是TB等級的資料)。

儲存

資料儲存的目的大都是為了資料轉換與分析。而有幾種因素會影響你的選擇

• 資料的讀取方式 — -是要讀取單獨讀records(row)或是在同一個cloumn中加總在一起的records(row)資料
• 存取的控制方式，是要在scheam or DB level 或是更細緻化的存取控制
• 資料要存多久

以上三種的因素都會影響你在選擇GCP存儲服務時要納入的考量。

資料存取模式

資料存取有不同的方式。像是線上交易系統通常會使用filter來尋找某筆特定的records(row)。例如電商平台可能需要查找某個客戶的送貨地址，每個客戶可能還有好幾個送貨地址存在。這種資料就適合放在GCP的Cloud SQL 或是Cloud Datastore來做資料查找。

另外一個例子就像是機器學習的pipeline，每次可能都要存取一個有數千筆資料的檔案做為訓練的資料集。通常機器學習模型都是batch mode，所有檔案訓練資料集的存取就是必要的，這種案例clous storage就適合放此類的檔案型資料。

Access control

資料的security 與access control也影響著資料如何被存放。Relational DB(如GCP的Cloud SQL與Spanner)提供了一種嚴謹的資料存取方法，例如限制那些使用者能update 資料，那些只能看資料，哪些連看都看不到。更細細緻化的access control可以被implement在Application levle或是做一個DB View給特定帳號觀看。

有些access control的存取就比較粗略一點。像是clous storage, access control可以用在bucket或是bnucket 裡的object(通常是檔案類型資料，像是文件或圖檔)，通常如果你有bucket access權限則裡面的object都可以讀取到(因為檔案是繼承bucket當初設定的權限)。但clous storage也把每個object視為單一個體，也就是你可以單獨針對某一個object設定獨立的access list，不必去fllow bucket的access list。但檔案裡的內容就無法再控管(不像Relational DB一樣可以再管控更細)。

在其他的案例中你可能也有其他方式的access control來存取資料。例如BigQuery是一種分析性的DB，針對 data warehousing/ data analytics / Machine learning所設計的資料庫。資料可以被集中在一個稱為dataset的群組，這個群組是由table / view組成的。現階段BigQuery支援dataset的access control，但還無法直接支援dataset裡tabel/view的access control。目前的解方在這個dataset製作一個一被授權的view，這個view可以被其他的dataset給存取。這種方式可以讓這個dataset需要被外部access時不用直接存取到裡面的table or view.

資料存放時間

資料存放的時間長度也是我們選擇GCP儲存服務的考量點之一。有些資料可能是過渡的，例如Application 跑在GCP的compue engine(有SSD硬碟)時可能只是暫時存放的。因為如果這個instance 關機了裡面的資料也消失了(除非你掛上另一個持續性的硬碟)。資料通常存活的資料都需要比VM的時間長，你可以把資料放在cloud storage中。特別的是你可以在clous storage中實行你的data lifecycle，把不常用的資料歸到(根據你的polciy 自動歸類)near-line(大約是30天內的) or cold storage(大約是一年內)以節省費用。以長期的資料分析角度來看，將資料放入cloud storage或是BigQuery都是一個選擇。如果資料是經常被存取的話，哪麼將資料放在Relational or NoSQL DB。隨著資料變舊你可能不在需要經常存取，就會有被刪除/匯出/歸檔的情況發生。

處理與分析

在這個階段資料會進行各種樣態或格式的轉換，以方便進行ad hoc querying或是其他形式的分析。

資料轉換

這部分包含了資料清理流程，所謂流程是指從資料中偵測與修正資料的錯誤。有些資料清理是包含資料型態的修正。例如一個cloumn(欄位)中的資料預期只會有數字不應該存在著文字。哪麼資料清理處理這一個不正確的內容可能就會用刪除該筆資料或給一個替代值(例如給一個零)或是Null值等方式。也可能會用業務邏輯的方式偵測不正確的資料。例如貨品下單日期不可以早於該筆下單的接單日。當然也可以在增加其他更複雜的規則。

資料轉換包含了normalizing 或standarding . 例如Application會預期客戶資料的電話會包含到地方區碼(例如台北是02),若沒有找到區碼哪麼Application可能就會去看該客戶資料的地址去查找所在地址後自動地補上區碼。在這個案例中Clolud Dataflow就適合拿來做這樣的資料轉換(streaming or batch mode).

資料分析

在這個階段有好多種技術方式可供使用來將資料萃取成有用的資訊(從資料變成資訊)。統計學的方式通常被用來處理跟數字有關的資料，通常有如下的作法:

• 描述資料集的特徵，像是資料集的平均或標準差。
• 產生直方圖以了解資料屬性值的分布狀況。
• 找尋變數之間的相關性，例如客戶的種類以及平均每筆下單的價錢。
• 使用回歸模型進行預測，這個方式可以讓你基於一個attribute預測另一個attribute. 以統計學的術語來說，回歸模型是基於兩個變數的相依性。
• 集群分析。零售業想要看哪一群的客戶會買類似的產品與花費相差不多的金錢。

而文字資料的分析也有多種技術提供。一個簡單的範例像是計算一段文章中有多少相同的字出現的次數。另一種複雜一點的方法像是在一串文字中選取特定的文字，例如名字或區域等。

探索與視覺化

我們通常在拿到一個新的資料集時會進行資料探索與驗證我們對該資料集的假設。GCP的datalab是基於Jupyter Notebooks發展出來的資料探索/分析/視覺化的工具。被廣泛的使用在資料科學與機器學習 的libraries(像是pandas/scikit-learn/TensorFlow)都可以被使用在datalab中。資料分析人員可以在datalab中使用python or SQL語法進行資料探索。

而GCP的Data Studio 則提供簡單的表格與圖表進行資料視覺化的呈現。採用資料拖拉的方式而無須要寫code.

以上就是我們介紹的data life cycle的四個階段 — ingestion, storage, process and analyze, explore and visualize. 這個提供了一個我們在處理資料的基本哭框架。

資料的技術觀點: Volume, Velocity, Variation, Access and Security

我們之前提到GCP有多種的儲存服務。這些服務是跟根據不同的需求而選擇不同的服務。之前我們是從業務觀點來看該選擇哪種儲存服務，現在我們會從技術層面來看該選擇哪種儲存服務。一些技術性的特徵如下

• 資料的volume與vleocity
• Variation in structure
• Data access patterns
• security requirement

Volume

有些GCP的儲存服務可以儲存到PB等級的資料量而有些則沒有提供這種容量。

Cloud storage則是這種大資料量的範例之一，它可容納單一的檔案容量為5TB。而總容量則沒有限制，你想放多少就放多少。Cloud Bigtable則是一種儲存遙測資料與大容量的資料分析服務，Bigtable的群集裡的node(VM)可以在HDD硬碟存放8TB的資料，而在SSD可以存放2.5TB。而每個Bigtable的instance可以存放達1000個table. BigQuery GCP的託管式Data warehouse與分析服務，在一個dataset不會限制你可以放多少table, 而一個table可以切分到4000個partations. 而Compute engine(GCP的VM)的硬碟單顆可存放64TB的資料量。

第一代的託管式的MySQL服務單一 instance可以存放500G的資料量。而第二代的MySQL與Postgre SQL與SQL server則每一個instace 則可以存放30TB的資料量。Cloud SQL(RDBMS)適合在GCP的單一個region使用。

Velocity

這是指資料被Application處理與傳送的速率。這種高速率處理與傳送例子像是網頁服務或手機app的資料，平常沒有很多人使用時可能速率就沒哪麼高，一旦大量使用者同一時間使用(像訂一場熱門演場會的票)哪在短時間內的資料速率就會變高。另一種機器產生的高速率資料量就是類似IoT物聯網裝置。

而這種短時間乘載高速率資料寫入的GCP服務為 — Bigtable，例如Bigtable的cluster 10 nodes且為SSD硬碟，則每秒鐘可寫入10,000 row的資料。另外一個高速率寫入資料的服務為 Pub/Sub topic，當你的Application(網頁/手機App)推送資料到pub/sub topic時，它將根據收到的資料量自動擴展可以處理全部寫入資料量的能力。我們不用像Bigtable一樣要計算底層需要多少的運算資源。

有高速率資料傳送就有低資料速率傳送。例如我們要將資料用Transfer Appliance服務將大量資料傳送到 Cloud storage 等待的時間單位可能就會以天計。

Variation in structure

另一個考量則是資料結構的變動性，例如天氣感測器固定時間傳送天氣的溫度/濕度/大氣壓力。這種資料結構就很固定幾乎不會有變化，固定傳送這三種資料型態除非傳送的過程中出了問題(可能是網路問題)導致資料有錯誤。而一些會使用RDBMS 的Application也很少會變化它的schema，因為一但變動整個資料結構就會有問題。

然而NoSQL的資料結構彈性比較大，像是MongoDB, CouchDB或是OrientDB這些都是屬於document 型的DB。這些DB採用key-vaule pairs來呈現多樣的attribute. 跟一般Relational DB有著固定的結構相比這些document DB可以再彈性增加需要的欄位資料(如下圖的比對)

Relational DB資料結構

Document DB的資料結構

上面兩種的資料內容都是相同的客戶基本資料，但從資料的屬性來看這一類的屬性都是固定不太會變的所以不需要放在Document DB裡(當然你硬要怎麼做也沒有規定不可以)。但若是用產品的屬性來看的話，產品的屬性隨時都有可能異動所以採用document DB是比較合理的選擇(如下圖)

Document DB範例

除了document DB外，wide-column (可以隨時加欄位到table)的DB，像是Bigtable or Cassandra DB也都是使用在資料結構變動性較高的需求上。

Data Access Patterns

資料讀取與寫入會根據不同的狀況而有不同的方式。例如時間序列特性的資料在接收到資料就要馬上寫入，但它可以之後被讀取的次數一天可能只有一次。像是客戶的下單資料在整個業務流程上就是一直被讀取。而歸檔資料可能一年都讀取不到一次。有四種量測指標是我們評估Data Access的考量點

• 每次"讀"資料時有"多少"資料要被讀取
• 每次寫資料時，有多少資料需要被一次寫入
• 資料多久讀取一次
• 資料多久寫入一次

有些資料的讀取與寫入的資料量是很小的，像是IoT物聯網感測器產生的資料。或是電商的客戶每次的交易資料也是小量的。但上述的兩種資料類型如果是在短時時間大量的裝置或客戶產生，哪麼這個資料量就會大的嚇人。而上面兩種例子所需要的GCP儲存服務又不太一樣。像是IoT的資料就比較適合Bigtable，因為資料持續不斷進來就需要寫入時是低延遲的能力。而電商的交易資料就適合Cloud SQL(Relational DB)，這種需有高I/O的資料寫入能力。

而寫入大體積資料時可以用GCP提供的Cloud transfer service or Transfer Appliance工具將資料寫入Cloud storage。 cloud storage 支援stream data但通常都是用在大資料的讀取與寫入。資料被讀取時在cloud storage的單位是object or file level的形式，它不是像filesystem 一樣是以block 的形式來讀取資料的。

在讀取大量的資料時BigQuery也是一個好的用法，但不一樣的是它是在大量的資料(例如有100欄位)中選取需要的幾個欄位來進行讀取。所以這個實際讀到的就是較小的資料量。能夠這樣做是因為Bigquery是使用column-base為主的DB，它是讀取需要的cloumns而不是每一筆row的所有column. columnar storage我們也稱它為 capacitor，。Capactior是被設計用來儲存半結構化的資料，這種半結構資料型態通常會伴隨nested and repeated fields.

這些data access patterns可以協助我們辨認該用哪種儲存技術較為合適。

Security requirement

不一樣的儲存服務有著不一樣的access control level。像是Cloud storage，它的access control 就只有bucket and object level。不論是哪種User都可以看到該檔案的全部內容。如果是Database則就可以控制到User可以看到甚麼樣的資料內容。

資料加密也是另一個重要的議題，在Cloud storage上存放的 資料預設都是加密的。當選擇儲存技術時access control也是重要的考量點之一。

資料結構型態:結構化，半結構化，非結構化

為了正確的選擇適當的儲存技術，我們需要對資料的結構有一定的了解。通常會分為結構化/半結構化/非結構化的型態。

結構化資料 有固定的資料屬性，由row and column組合成的table資料。

半結構化資料 如同我們上面提到的產品屬性的例子，它的屬性會經常的異動。半結構資料通常會被組織成array或是 key-value pairs的方式。

非結構化資料 就不會有固定表格式的資料呈現，通常可能是圖檔或影像檔都屬於這一類資料。

結構化資料: 交易型 VS分析型

結構化資料基本就是以row(records) and column組合而成的table, 而column都會帶有屬性而record則是真實的資料(如上圖-Relational DB資料結構). 結構化資料通常會運用在交易處理或分析處理的資料模式。

交易型結構化的資料都會是一次讀取一筆row(records)進去。例如一個公司的Application需要用地址查找在客戶的相關資料時(table中查找)，這一筆record會帶出相對應多個cloumn的資料，查到的資料可能就會被寫到另一個table中。這種以row為基本的資料操作方式可以使用 Cloud SQL 或Spanner.

另一種是以分析資料為主的結構化資料，通常是分析歷史性的資料。會以Data warehouse為主，最主要是靠長期的歷史資料分析(資料便資訊，資訊轉換成智慧)後得出業務上的新見解。 所以每次分析的資料筆數(records)可能都是以數百萬甚至千萬筆資料來進行分析，但是通常這樣的分析方式我們只會挑幾個在table中我們有興趣的幾個少數的cloumn來分析。以大量的row 加上少量的cloumns分析的方式會以BigQuery為主。

半結構化資料: Full indexed VS Row Key Access

如同之前說的，這種資料結構並不是固定的row/columns組合而成的table型式，而是用schema attribute來儲存資料的。在之前的Document DB的範例中，它可以讓開發人員加上所需要的資料attribute而不用像結構化資料一樣去修改DB的schema. 半結構化的資料儲存方式有兩種 — document and wide column, 這兩種不一樣的地方在於資料的存取方式。

Full indexed
我們以客戶要找尋洗碗機為例(資料結構如上圖 : Document DB範例 dishwasher)，客戶的考量因素可能會因為家裡的空間的因素要用洗碗機的長寬來找尋適合的產品。為了加快查詢的速度Document DB會create data的indexes 。在這個案例使用Cloud Datastore,視需求你可以針對每個attribute(長或寬)create indexes, 或者是兩個attribute(長+寬)create一個indexes。

但是為了增加查詢速度想到甚麼indexes就做新的indexes並不是一個好方法。因為indexes也是要佔儲存空間的，而且有時indexes資料量可能還大於實際資料量。另外indxeses大太會造成資料庫在實行資料的insert/update/delete時造成效能問題，因為以上三個動作每次都要去更新相對應的indexes。

Row Key Access
而wide-column DB的搜尋則不是indexes來查詢資料。它是使用類似Relational DB的Primary Key的方式稱作row key 來查詢資料。它有兩種實現方式

在Wide-column DB的Table使用特別的查詢方式。雖然Relational DB裡的資料是已經過正規化的，但wide-column DB2的設計是低延遲的資料寫入與同時間的大量資料讀取。這種方式會導致資料會有重複的現象。我們以IoT感測器為例子(如下圖)

在上圖中我們看到資料查詢的key通常是Sensor ID而timestamp(單位是: milliseconds )則可能是另一個查詢依據。所以在未來查詢資料時我們將以 Sensor ID +Timestamp一起查詢資料。這樣的組合我們稱之為Row key.

雖然這樣可以查詢資料，但是要使用timestamp來查詢資料卻不太適合。例如我們要看過去一個鐘頭以來的資料，比起對timestamp 做indexes，wide-column DB使用不同的row key來查詢資料(如下圖)。

由上圖中我們可以看到以時間為查詢依據的row key組合(timestamp + Sensor ID)改變了.上面兩個row key的範例代表著不同的table，意味著根據你想要的row key查詢可能會有不同的table.這樣就有資料重複的狀況發生了。(PS. wide-column DB沒有支援像indexes這樣的查詢方式)

非結構化資料
最大的特徵就是沒有schema 或data model。 Relational必需先定義好schema(columns/ row)才可以科開始塞資料進去。半結構化資料一開始在塞資料的同一時間也是要指定好schema. 非結構化資料通常是

• 文字檔資料，裡面包含文字語言
• 聲音檔
• 影像檔
• Binary large objects(BLOBs)

非結構化的儲存與存取方式的選擇並非靠它的schema(因為它沒有)，而是這些檔案都有它自己的內部結構存在。例如人類語言是因為有著語言規則而有高度結構化的方式。聲音與影像檔也是因為它的格式包含了它自己的metadata。這些檔案都有它自己的內部格式只是因為它們的格式不會影響它們怎麼被儲存與存取而影響，所以才稱為非結構化資料。

而GCP則有一個決策樹讓你可以根據這張圖依據你的需求與資料結構來選擇適合的儲存服務(如下圖)

設計Schema的考量

結構化與半結構化資料如同之前說的需要有schema來儲存相對應的資料。結構化資料通常儲存在Relationa DB，半結構化則是NoSQL DB。Schema影響著資料的儲存與存取方式，所以一旦決定你要使用哪種儲存技術接下來就要設計schema. (PS. 近來Relationa DB與 NoSQL的界線越來越模糊，因為本來在各自獨有的功能特徵現在也開始在另一邊也支援了)

Relational DB Design

這裡有兩種DB的Data model一開始就要決定了。一種是OLTP(Online Transaction processing ) DB另一種是 OLAP(Online Analytics processing) DB.(PS. SAP 的HANA DB同時可支援OLTP/OLAP 的Data model.有興趣的讀者可以參考本blog其他文章)

OLTP

是設計用來處理交易型的資料，並且這個資料schema是要經過資料正規化的。現行有10種資料正規化的型式，但大部分的OLTP通常不會超過三種以上的形式。

• 第一正規化型式 — 一格(cell)只能有一筆資料(atomic values)，每個table都有一個唯一的primary key作為識別.以便讓該table後面接下來的columns能以此為主識別資料。
• 第二種正規型式 — 符合第一正規化。並另外create一個table，這個table會有foreign keys而這個foreign keys是跟接續來的column資料會與primary key相對應。
• 第三正規化 — 包含第二正規化，從table消除任何沒有跟key有相依性的columns.

這些正規化的設計都是為了將降低資料未正規化的風險並且並免多餘的資料存在。這樣的正規化運作方式一直以來都很不錯，但這樣的方式也產生了一些問題。例如當DB要做join table或update 大量的indexes時會對硬碟產生大量的I/O操作。所以使用OLTP的data model必須在設計資料庫正規化與效能間取得平衡。

去正規化

正規化的反面，就是把所有的正規化規則去掉，將所有資料放在一個大的table中。這通常是為了"查詢"資料的效能而設計的。通常在正規化的DB中我們經常需要join兩個table做資料查詢，但在去正規化的DB資料通通在一個table中所以不太需要使用join的方式。

OLAP

OLAP的Data model通常都是用在Data warehouse的DB或是Data mart application. OLAP model也稱作Dimensional model因為資料是由多個Dimensions組合起來的。OLAP model是用來設計加速以下的工作的:

• Rolling up and aggregating data
• Drilling data from summary data to detail data
• Pivoting and looking at data from different dimensions — sometimes call slicing and dicing

OLAP方式可以運作在Relational DB或是特別的多維度 data store。

No SQL Database Design

NoSQL DB是資料結構的嚴謹度較低的模式。沒有著Relational DB嚴謹的正規化規則。在GCP中提供四種形式的NoSQL DB.

• Key-Value
• Document
• Wide Column
• Graph

以上四種方式會根據不同情況或需求加以選擇，例如Data Ingestion, entity relationships, and query requirement.

Key-Value data store

這類型的DB基本datatype以 array 或 dictionaries為主。key data是用來尋找相對應的Value的。一個key-value的例子(如下圖)，key是機器的名稱而value則是向對應partations名稱

這種儲存資料的框架就很簡單(因為就只有key and value)，但是資料本身的架構就可能會複雜多。例如一個JSON object就可能是一個value. 以這個方式來想的話就會合理多，因為如果我是要找一個JSON object以key 來查詢相對應的Value(JSON object)這樣搜尋速度就會很快。因為我要找的不是這個JSON object內的資料(用JSON的架構來找資料)而是它本身。而如果是要找尋JOSN obejct裡的資料則以Document DB較為適合。

Cloud memorystroe是GCP一個基於Redis的全托管式的key-value data store.在寫這一篇文章的時間點， cloud memorystore還沒有支援資料寫入硬碟的服務(也就是如果你停止或關掉memorystore上面的資料就會消失, 不過AWS的有支援)。

Document Databases

這種允許複雜的資料結構稱作documents. 查詢document的方式跟key-value方式是一樣的，document 就是一個value. 但這個document 內的資料結構會是需要經常一起讀到的資料。我們以一個線上遊戲為例，需要一個document來儲存玩家的資料包含如下

• player name
• health score
• list of possessions
• list of past session start and end times
• player ID

前面三個資料是需要一起讀取並呈現給每個玩家看的。其中"list of past session"是我們要用來分析玩家如何進行遊戲的。這兩種不同需求的資料讀取方式會造成有不同的document。不論讀取或分析都會需要player ID，所以第一個讀取需求會是player ID加上表列的前三個資料。第二個讀取需求則會是player ID加上第四個資料。而在GCP的document DB則是Cloud datastore.

Wide-column Databases

此類資料庫使用的場景如下

• 大量的資料
• 低延遲(就是快速)的寫入資料
• 寫入的操作比讀取資料次數要高
• 有限度範圍的查詢 — 意思是沒有ad hoc query
• lookup by a single key

此種DB跟Relationa DB一樣會有DB tables的形式存在，但有一點很大的不同是。此種DB通常是spare的，從一開始只有一個table幾個column到後面長到幾十個column但是你用永遠只會用到少數幾個column.

而GCP的Bigtable(全托管)也是此種資料庫的型式，若你在地端機房的hadoop運行Hbase你也可以考慮將Hbase的資料移轉到Bigtable上。

Graph Database

此種DB是將每一個點(entities)之間的關係連結起來成為一個圖像或網路圖。最好的例子就是社群網路(六度分隔理論)，每個就是一個資料點(也稱作edges)彼此因為認識的關係而連結起來。下圖是一個簡單的例子。

上圖中我們可以看到Chengdong會有6個朋友，而Lem只有一個朋友。

這一類DB的資料查詢方式有兩種。一種是SQL-like的宣告是語法，描述在這個graph 要找尋的pattern，像是Cypher查詢語言。這個查詢可以查詢這個人的朋友的朋友，查詢語法如下。

MATCH (n:person) -[:FRIEND]-(f)
MATCH (n)-[:FRIEND]-()-[:FRIEND]-(fof)
MATCH n, fof

其他的選項有traversal語法(像Gremlin)，這是一種在Graph中指定如何在edges間移動。GCP目前還沒有託管式的Graph DB.

總結

這一篇文章我們data lifecycle的四階段的生命週期 — ingest/storage/process and analyze/explore and visualize。另外我們也介紹的streaming data的特徵，而GCP Pub/Sub適合套用在這種需求上。另外我們也介紹了Batch data，而不論是要對stream and batch data做轉換或處理都可以適用在Dataflow服務。我們也根據一些技術因素(Data的volume/velocity, 資料結構的形式，access control，data access patterns)來選擇合適的儲存服務。也介紹了結構化/半節構化/非結構化資料。