LoginSignup
6
0

More than 1 year has passed since last update.

BeeXAdvent Calendar 2021Day 4beex-inc
@Shmwa2(Shohei Miwa)in株式会社BeeX

Challenge Google Cloud Data Engineering part1

Posted at

Google Cloud Data Engineering に関連する記事を複数回に渡って記載していこうと思います。

Google Cloud Storage Solution

Google Cloud にはストレージとして機能するサービスがいくつか存在します。
part1 では、こちらで挙げられたサービスの理解を中心に記載していきます。

image.png

Cloud Storage

Cloud Storageのサービスの全体イメージです。

image.png

Cloud Storage は、以下の特徴、機能を持ちます。
非構造化データの格納先として選択される理由は、1点目の特徴となるオブジェクトがバイナリデータとして保管される点です。

  • Cloud Storage はオブジェクトストアであるため、オブジェクトに含まれるデータに関係なく、バイナリのオブジェクトとして保存します。
  • Cloud Storage はバケットと呼ばれるデータンコンテナを単位として構成され、バケットはグローバルに一意の名前を付与します。バケットの中に、データにあたるオブジェクトが格納されます。
  • オブジェクトが格納されると Cloud Storage は、オブジェクトに対して複製をします。複製したオブジェクトをモニタリングし、破損や損失をトリガーにコピーと交換します。これにより 99.9999999999% の耐久性を誇ります。
  • バケットの配置場所はリージョン単位で選択が可能であり、複数リージョンを指定する事も可能です。
  • ストレージクラスと呼ばれるメタデータを使用して、データの保管用途に合わせた定義をバケット単位に適用できます。
Standard Storage - 頻繁にアクセスされるデータや、短時間だけ保存されるデータに最適な標準設定のストレージクラスとなります。
Nearline Storage - 頻繁にアクセスされるデータを保存するが、最小保存期間が 30 日となっており、データアクセスで費用が発生しても、保存時のストレージコストを抑えたい場合には、Standard Storage よりも Nearline Storage のほうが最適な選択肢となります。
Coldline Storage -アクセス頻度の低いデータの保存に適しています。最小保存期間が 90 日で、データアクセスの費用が高くても、保存時のストレージ コストを抑えたい場合には、Standard Storage や Nearline Storage よりも Coldline Storage のほうが最適な選択肢となります。 
Archive Storage - アーカイブ、オンライン バックアップ、障害復旧のためのストレージクラスであり、データに迅速にアクセスできます。必要なデータの取得に数時間あるいは数日かかることはありません。ただし、データアクセスと操作に関する費用が高く、365 日間という最小保存期間もあります。
  • バケット単位で複雑なアクセス制御を行う事が可能です。また、CMEK を使用したデータの暗号化も可能です。
  • APIでのストリーミング転送(アップロード、ダウンロード)をサポートしています。
  • Cloud Storage for Firebase により FirebaseSDKを使用して Firebase からのアクセスも可能にします。
  • バージョニング設定を行う事で、ライブバージョンの置換、削除の度にオブジェクトは非現行バージョンとなり、非現行バージョンへの戻しが可能となります。
  • Cloud Audit Logs を使用して、バケットの構成情報を管理するアクティビティログを取得可能にし、各オブジェクトへのREAD/WRITE 処理を確認するデータアクセスログを取得できます。
  • オブジェクトの変更処理を確認するために、Pub/Sub に登録されたサブスクライバーは変更をトリガーに通知を実装する事が出来ます。

非構造化データの格納先として使用するものの、データストレージとして Cloud Storage はOLTPのデータソースとしては向いていません。
システムの構造化データの保管先としては使用出来るものの、データへの処理を Cloud Storage 単体で行う事はなく、また、レイテンシが高頻度な書き込みに対応出来無いことを示します。
また、構造化データの分析にも向いていません。分析にはコンピューティングリソースが必要になりますのが、Cloud Storage 単体では、その機能を持ち合わせていません。

OLTP(トランザクション) とOLAP(分析)

OLTP(OnLine Transaction Processing) はデータ処理を行う上での手法で一つで、トランザクションを用いて複数の処理を一つのプロセスとしてまとめた処理となります。
OLTP 向きのサービスは、スナップショットと呼ばれる現在の状態を保持する機能を持ち合わせている事が多く、トランザクションデータを元に、ある地点への状態を維持します。
また、トランザクションワークロードとは、データの挿入と更新が迅速に要求されるワークロードであり、主にビジネス上の管理と実行を用途として使用します。

トランザクションワークロードでは、データの書き込み(挿入、更新)が大量に行われます。

image.png

OLAP(Online Analytical Processing)は、データ処理を行う手法の一つで、データ分析に使用される処理の流れです。
OLAP におけるデータソースは、Cloud Storage などのストレージサービスや特定のデータレイクなどを使用する場合もありますし、OLTP向けのデータベースを使用する場合もあります。
また、分析ワークロードはデータセットの情報を分析し、主に計画や意思決定を要する場面において、サポートを行う用途として使用されます。

分析ワークロードでは、データの読み取りが大量に行われます。

image.png

なお、OLTP/OLAP はリアルタイムが主旨であるため、これに対義する処理はバッチ処理となるかと思います。
バッチ処理は即座にレスポンスを返す処理ではなく、定量のデータがまとまった段階で処理を行うというものです。

Cloud SQL

Cloud SQLはGoogle Cloudにおけるトランザクションワークロード向けのSQLクエリ志向のデータベースサービスです。一般的なサービスの概要です。

image.png

Cloud SQL は以下のような特徴、機能を持ちます。

  • マネージドサービスのRDBMSであり、サードパーティーとして MySQL /Postgresql /SQL server のデータベースエンジンを使用する事が出来ます。
  • Comupute Engine インスタンスに サードパーティのデータベースエンジンがインストールされたイメージであり、インスタンスはCompute Engine 同様に配置先となるリージョンやゾーンの選択、IP(Private/Public)の取得、ストレージ容量の設定などが可能です。
  • データベースクライアントからの接続や、App Engine からの使用、外部アプリケーションから Cloud SQL Proxy を経由した接続なども可能です。
  • マシンタイプと呼ばれるデータベースとしての垂直スケーリングとなるコア数とメモリの容量(スループット、IOPS)をカスタムに設定できます。これによりトランザクションワークロードに耐えうる性能を検討出来ます。
  • リードレプリカを使用して水平にスケーリングする事も可能であり、Cloud SQL のみでなく、MySQLでは例えば Compute Engine 上の MySQL インスタンスを外部リードレプリカとして指定する事もできます。(replicate-ignore-dbの設定が必須となります。)
  • 高可用性としてのフェイルオーバー機能も使用出来ます。フェイルオーバーはマスターのゾーン障害である場合、自動で行われますが、特定のケースでは手動となります。なお、ここでいうフェイルオーバー レプリカは個別のインスタンスとして請求対象となり、フェイルオーバー先は、リードレプリカではなくスタンバイインスタンスとしての構成となります。
  • マネージドサービスの機能として、自動バックアップおよび手動バックアップを取得する事が可能です。切り戻しには、ポイントインタイムリカバリが使用出来ます。
  • Cloud Logging(Stackdriver Logs)を使用して、監査ロギング、インスタンスのログを取得する事が可能です。

Cloud Spanner

Cloud Spanner は Cloud SQL同様、トランザクションワークロード向けのフルマネージドのデータベースサービスです。
Cloud SQL との大きな違いは水平スケーリング向きな点、Cloud SQL では存在しない役割がレプリカに割り当てられます。高可用性であるもののコストが高い事も特徴の一つです。

image.png

  • 単一のリージョン構成では、3つのレプリカを別のzoneへ作成します。このうち書き込みを行えるレプリカも作成可能です。

  • マルチリージョン構成では、複数のリージョンに複数のレプリカ構成を配置します。各リージョンに配置するレプリカは任意で選択可能です。
    　レプリカの役割は以下の3種類です。

    • 読み書きレプリカ - 読み取りと書き込みの両方をサポートします。 データの完全なコピーを維持、読み取りを処理、書き込みを commit するかどうかを投票可能、リーダーの選出に参加できます。リーダーになる資格があります。単一リージョン インスタンスで使用できる唯一のタイプです。
    • 読み取り専用レプリカ - 読み取り専用レプリカは読み取りをサポートします（書き込みはサポートしません）。読み取りを処理、リーダーや書き込みの commit を決める投票に参加しません。リーダーにはなれません。書き込みに必要なクォーラム サイズを増やさずに読み取り容量をスケーリングできます。
    • ウィットネスレプリカ - ウィットネス レプリカは、読み取りをサポートしませんが、書き込みの commit を決める投票に参加します。レプリカにより、読み書きレプリカがデータの完全なコピーを保存し、読み取りを処理するために必要なストレージやコンピューティング リソースを使用せずに、書き込みクォーラムを簡単に実現できます。ウィットネス レプリカの特性は次のとおりです。

参考文献

  • Splitと呼ばれるデータを格納される単位が存在し、Splitを複数のインスタンスへ配置する事でスケーラビリティを実現します。

No SQL

NoSQL は以下で記載をしていますが、表形式の関係モデルではないデータベースの総称です。
https://qiita.com/Shohei_Miwa/items/f774ecdb37cec91c3a5b

image.png

また、ドキュメント志向のNoSQLを使用する場合、格納されるデータを半構造化データと呼びます。半構造化データとは、ある程度データ構造が決まっているものの、構造を柔軟に変更できるデータを指します。
データ型が固定でないため、格納するデータにあわせて自由に変更できる点があります。JSONやXML形式のデータが、半構造化データに該当します。

image.png

Cloud FireStore

Cloud FireStore は キーバリュー形式のNoSQL 形式のデータベースであり、Firebase とGoogle Cloud 上で使用出来るサービスです。
Firestoreには、ネイティブモードとDatastoreモードが存在し、どちらかを選択する必要があります。

ネイティブモードは、Firebase Realtime Database の機能が使用出来ます。Datastoreモードは、Cloud Datastoreの後継であり、ストレージがCloudDataStoreとなります。

データベースのロケーションを選択出来ますが、Firestoreは、NoSQL データベースであるため、通常のデータオブジェクト間の関係を表現する語句が異なります。

image.png

  • データ

filed(key)とvalueのペア。

サポートされるデータタイプ
Array
Boolean
Bytes
Date and time
Floating-point number
Integer
Map
Null
Reference
Text string
exsample.py
data = {
　　u'arrayExample': [5, True, u'hello'],
    u'booleanExample': True,
    u'BytesExample': 314159265,
    u'dateExample': datetime.datetime.now(tz=datetime.timezone.utc),
    u'Floating-pointExample': 3.14159265,
    u'IntegerExample': u'Hello World!',
    u'nullExample': None,
    u'ReferenceExample': u'/user/ver1',
    u'textExample': {
        u'a': 5,
        u'b': True
    }
  • ドキュメント

ストレージの単位。データあるいはサブコレクションを示し、IDが付与されます

db.collection(u'newcollection').document(u'newdoc').set(data)
  • コレクション

複数のドキュメントを示し、IDが付与される。データの編成とクエリの作成に使用できるドキュメントのコンテナです。サブコレクションと呼ばれるドキュメント内にコレクションを作成する事もでき、ドキュメントとサブコレクションは相互に定義する事でネストされた階層データを定義できます。

db.collection(u'newcollection').document(u'newdoc').set(data)
  • コレクショングループ

コレクション グループは、同じ ID を持つすべてのサブコレクションで構成されています。

exsample.py
cities = db.collection(u'cities')

sf_landmarks = cities.document(u'SF').collection(u'landmarks')
sf_landmarks.document().set({
    u'name': u'Golden Gate Bridge',
    u'type': u'bridge'
})
sf_landmarks.document().set({
    u'name': u'Legion of Honor',
    u'type': u'museum'
})
la_landmarks = cities.document(u'LA').collection(u'landmarks')
la_landmarks.document().set({
    u'name': u'Griffith Park',
    u'type': u'park'
})
la_landmarks.document().set({
    u'name': u'The Getty',
    u'type': u'museum'
})

概要レベルが多くなってしまいましたが、分析向きデータベースとなる、Big Table と Bigquery に関する記事はもう少し細かい記事にしようと思います。

6
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
0