GCPのPCAに合格したので、合格をもらうまでまとめていた学習ノートをブログ形式でまとめていく。
前回のGCP PCA合格したよという記事でノートまとめまで書きたかったが、長くなったので、別記事にした。
内容は学習ノートなので乱雑、項目もノートを書き写しながらなので、随時更新追記していくだろう。

DataprocとDataflow

DataprocとDataflowの使い分けをしっかりする必要がある
どちらも大量にあるデータを短時間で処理するよというフレームワーク

DataprocはApache SparkやApache Hadoopなど、大量にある静的なデータを処理するもの。10TBの画像データを機械学習にかけるような、そういう用途に使われるもの。Hadoopが使用するファイルシステムのHDFSも知識として必要。OSのファイルシステムではなく、その上に独自でファイルシステムを構築して、大量データの単位時間あたりの読み書き速度を向上させているもの。インデックスを構築し直したようなものという認識。

DataflowはApache Beamのバックエンドで動作しているフレームワーク。こちらはストリーミングでやってくるような動的データの大量処理が得意。「ストリーミングデータを並列処理させてリアルタイム分析できる」というフレームワークの説明からわかるように、GCPでもストリーミングデータの処理→Dataflowがベストプラックティスという流れが定石。

同じようにストリーミングデータをどう処理するかというものにCloud Pub/Subもある。こちらも100%問題に出るようなフレームワーク。PublishとSubscribeの略。Pullでデータを持ってくるかPushでデータを送り出すか、どちらでも利用できて、どんな状況であってもデータを送受信できる→モバイルやIoTにも最適という特徴がある。

DataprocもDataflowも、大量データの処理はできるという点は同じ。そのため、やろうと思えば、Dataflowで静的データを処理させることも、Dataprocでストリーミングデータを分析させることもできる。何が違うかと言うと、料金が大きく変わる。（どれぐらい変わるかは調べてない）
餅屋は餅屋でやらせることがベストプラックティス（当たり前っちゃ当たり前の話）

Bigtable,BigQuery,CloudSQL,Datastoreの比較

殆どが、前述の 「GOOGLE CLOUD PLATFORM エンタープライズ設計ガイド」 に記載されていたデータウェアハウスの選択フローの通り。
PCAの試験に向けては、こう覚えていた

レイテンシ(スループット)重視→BigTable
時系列データ→BigTable
大量データ→BigQuery
分析処理→BigQuery
SQLクエリが使いたい（既存環境と変えたくない）→CloudSQL
データ量が10TB以上→CloudSQL以外
ユーザプロファイルなど消えちゃダメなやつ→Datastore
AppEngine関係→Datastore

–2021/10/07 追記–
この間、Datastoreを使う要件に、実際に触る機会があったんだけど、最近はFirestoreという名前になっている
実際に機能としてはFirestoreがDatastoreの上位互換。基本的にFirestoreがいい
なんなら、こんな表記もされている
> 2021 年 6 月に Cloud Datastore から Datastore モードの Firestore への移行が開始されました。移行は、非常に低いトラフィック データベースから始まり、今後数か月でトラフィック量の多いデータベースに拡張する予定です。
> cite: https://cloud.google.com/datastore/docs/upgrade-to-firestore?hl=ja
なので、本や問題文でDatastoreとFirestoreの表記が入り乱れるであろう。
注意してください

分析のレイテンシを早くしたい場合等は、BigTableではなくBigQueryになることがあるが、だいたいこの順番で考えるとPCAは簡単だった。
未だにDatastoreの立ち位置がはっきりしてない。AppEngineのバックエンドだったり、データの整合性が重要なものはDatastoreという感じだろうか

同じデータウェアハウスとして、Spannerも重要だが、結構特殊。
Spannerに関して、どこかで特徴をまとめて書きたいが、これから業務に関係しそうで、書きにくい…
SQL文が使えて、大量データも扱える。それぐらいでいいんじゃないかなPCAに向けては

BigQueryの操作はbqコマンドで扱う。ビュー、テーブル、などBigQuery用語から、bq show、bq lsなどのコマンドオプションの知識も必要。

GCSの詳細

PCAの問題最頻出のGKEの次か同等ぐらいに多いと言われているのがこのGCS関係の問題。(と僕は思っている）

バケットというオブジェクト管理で、1オブジェクト5Tまで扱える。GCS自体には無制限にデータをおける。
GCPはCUI操作だとgcloudコマンドにて扱うが、GCSはgsutilで操作する。

普通のWindowsPCの言葉を使って、めちゃくちゃ雑に説明すると、
ハードディスク単位がバケット
1つのファイルを1オブジェクトと呼ぶ
で、この1オブジェクトが最大5TB

例えばCドライブやDドライブをフォルダの中に入れられないように、一番大きな単位がバケット
作成時にCドライブとかDドライブとか、ドライブに名前をつけるのだけれど、全世界で唯一の名前をつけないといけない。
Ruthという名前のバケットを作ったら、全世界で、俺しかRuthというバケットが使えない。

なんでオブジェクトって言うの思うと思う。俺も思った。
あるファイルに、これはどういうデータかって付加情報をつけるのが普通だと思う。
ファイルデータに、そういう付加情報も含めたものなので、オブジェクトって言う。
なので、ファイルデータは1KBでも、付加情報に4.999999TB分の情報を追加したらもう5TB制限ですよってなる。

例えば、
[えっちがぞう-2021_1007.jpg]
というファイルがあったとする。
えっちがぞうなので、一般人に見せるのは良くない。
なので、プロパティにR18というフラグを付けておく。すると一般人に見えなくなるよってできる。
いやいや、これは象の画像かもしれない。
この画像は象かどうか、というフラグも付ける。
そういうフラグがたくさん使える。そしてファイルと一緒に管理する。
でも無尽蔵ではなく、容量上限があるので、オブジェクトという単位で管理して、1オブジェクト5TB。
ちなみに、このフラグってのはオブジェクトメタデータって言うけど、PCAには出てこないかも。

説明して思ったけど、linuxとwindowsのファイル管理みたいな感覚でgsutilの操作する。
Windowsだと、
> dir c:\ecchi_folder
c:\ecchi_folder\ecchi.jpg

Linuxだと
$ ls /mnt/c/ecchi_folder
/mnt/c/ecchi_folder/ecchi.jpg

が合体して
$ gsutil ls gs://ecchi_bucket/ecchi_folder
gs://ecchi_bucket/ecchi_folder/ecchi.jpg
みたいな

コンピューティングリソースの詳細

GCPが提供しているコンピューティングリソースはたくさんある
まあそりゃクラウドサービスなんだしそりゃそうか

ただ、ここで述べるのは、今まで通りVM単位で使う時の話
なので、この2つだけ

• GCE
• GKE

GCEの詳細

VPSとか、今まで通りVMを提供するサービスがGCE
Google Compute Engineの略
GCEもGKEもそうだが、起動している間お金がかかる
普通のVMなので、CentOSとか、Ubuntuとか、Windowsとか、OSのimageを選択して起動する。

普通のVMなので、ある時点の中身をコピーして保存してくれってスナップショットを作れる。
そういうスナップショットを使ってカスタムイメージを作れる。

例えば、CentOSにApacheやPHP類を配置、普通のWebサーバを構築する。
負荷が増えてきたので、マシンを増強(スケールアップ)するのではなく、マシンを増設(スケールアウト)して、2台のVMで負荷の分散を行いたい。
そんなときに、またCentOSを入れたVMを作って、Apacheをインストールして、PHPを配置して…
そんなのは煩わしいので、既に出来上がったVMのスナップショットを作り、スナップショットからカスタムイメージを作成。そのカスタムイメージを利用してVMを作成。
するとクローンが出来上がる。
コレ自体はGCP特有の機能や特徴というわけではない、AWSでもできるし、従来のVPSやらと同じことができるというだけ。
だが、今の時代はコンテナですってよ奥さん