這一篇我們會介紹根據你的業務需求來選擇適合的GCP的儲存服務。同時也介紹甚麼是結構化/半結構化/非結構化的資料模型;與設計SQL與NoSQL Database 的schema.
一開始我們會從以下幾個方面來選擇我們應該用哪種GCP 儲存服務
讀完這一篇文章後根據多種的規則我們應該怎麼選擇GCP 的儲存服務。
從公司的業務角度來選擇
從公司的業務角度來看我們就要跟據需求來看整個Data的life cycle，分為以下四個主要階段
Ingestion是第一個主要階段，最主要是把資料放到GCP中。store就是把資料放在GCP儲存服務中讓它不會消失，並且稍後可以被存取。Process and Analyze是將資料做一些轉換成有用的格式並且可以作為分析之用。最後是Explore and visualize將資料轉化成圖表並從中產生新的洞見。
獲取資料通常我們會有三種Ingestion模式
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的類型可能有:
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是相反的，它是一個長時間的區間並且每次傳送的是一個大的資料量，通常是檔案類型的資料。類似這種類型的資料可能有
儲存
資料儲存的目的大都是為了資料轉換與分析。而有幾種因素會影響你的選擇
資料存取模式
資料存取有不同的方式。像是線上交易系統通常會使用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).
資料分析
在這個階段有好多種技術方式可供使用來將資料萃取成有用的資訊(從資料變成資訊)。統計學的方式通常被用來處理跟數字有關的資料，通常有如下的作法:
而文字資料的分析也有多種技術提供。一個簡單的範例像是計算一段文章中有多少相同的字出現的次數。另一種複雜一點的方法像是在一串文字中選取特定的文字，例如名字或區域等。
探索與視覺化
我們通常在拿到一個新的資料集時會進行資料探索與驗證我們對該資料集的假設。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
有些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可以再彈性增加需要的欄位資料(如下圖的比對)
上面兩種的資料內容都是相同的客戶基本資料，但從資料的屬性來看這一類的屬性都是固定不太會變的所以不需要放在Document DB裡(當然你硬要怎麼做也沒有規定不可以)。但若是用產品的屬性來看的話，產品的屬性隨時都有可能異動所以採用document DB是比較合理的選擇(如下圖)
除了document DB外，wide-column (可以隨時加欄位到table)的DB，像是Bigtable or Cassandra DB也都是使用在資料結構變動性較高的需求上。
不明
iThome鐵人賽
看影片追技術