google Professional Data Engineer資格
学習リソース
officialコンテンツ
模擬試験
ラボ
coursera
関連動画
gcpイベント
試験参考
データベースのベストな選択
以下の問いに答えられるようにしておきます。 Google Cloud のデータベースサービスの特徴とユースケースを必ず押さえておきましょう。
超大量に押し寄せる IoT のセンサーデータを格納して低レイテンシで読み出しするのにベストなデータベースは? (BigTable)
複数のリージョンにまたがるトランザクションワークロードに適したデータベースは? (Cloud Spanner)
Web アプリケーションから使う No SQL データベースは? (Cloud Datastore ※現在は Firestore に統合)
一般的なアプリケーションからリレーショナルデータベースを使いたいときは? (Cloud SQL)
大量のデータに対して SQL を使って分析を行いたいときは? (BigQuery)
udemy
これが解ければだいたいOKらしい
模擬試験の設問回答参考
サービス別
bigtable
no sql
hbase的な。ドキュメント型で大規模なデータをリアルタイム処理を得意とする
key visualizer
bigqueryにある実行ログから使用パターンを分析できる
cbt
cli hbase shellの代替もできる
用途とかメリット
cloud spanner
マルチリージョンで作成できるため可用性が高い
主キーにはincrementalな列は指定しない。主キーによってデータの分割配置単位を決めているが、これだとアクセスが特定のサーバに偏る(これをホットスポットという
もし移行時にそのようなキーを使用してれば、hash値を結合して連番でないように加工するといい
uuid v4を推奨している
主キー戦略を指定することで、生成時に指定することでおこなう。作成後は主キーの変更はできない
セカンダリインデックス
indexやunique制約をつける
posgreからcloud spannerに移行するときはDDLを編集したりする
replication
単一なregionのread-writeのreplicationのみできる
replicaの種類はread-write read-only witnessの3つ
DBの分割
データ量が多くなってきた場合は、splitというチャンクで分割する
連続した行の範囲を保持する。サイズと負荷に応じて自動的に追加、削除をおこない、DB内の分割数を変更する
table interleave
テーブルの親子関係を定義する。7層までできる。他には外部キーを用いること表現することも可能
親テーブルをinterleaveとしてDDL(interleave句)で指定するときに、子テーブルの主キーを入れることで、関連づける
cloud ハイブリッド接続
priveteなアドレスにピアリングで直接アクセスできる。VPNなどは不要
大量のデータでは
Dedicated Interconnect
Partner Interconnect
オンネットでアクセス
オンネット:
データが少ないときは。基本低帯域での利用
cloud VPN
VPN経由で接続
ダイレクトピアリング
キャリアピアリング
transfer appliance
大容量のストレージデバイスのこと。物理デバイス
データを入れて、googleに返送するとstorageなどにアップロードする
データの転送時に用いる。次のときに適している
GCPにデータを移行する際
データサイズが10TB
使用可能なリージョンである
ネットワーク経由でアップロードして移行しようとすると1週間かかる
その他転送サービス
他のクラウドなどからデータを転送する
SaaSからBQにデータ転送
文字通りオンプレから転送する
Cloud Interconnect
dataflow
コレクション(PCollection)
データセット。パイプライン上に分散して存在する
ストリーミング処理と集計
pubsub dataflow bq なんかでストリーム分析
ウィンドウ
時間単位などでコレクションを分割する
cloud pub/sub
サブスクリプション。メッセージを受信する対象のこと
push
pub/subサーバから受信対象にリクエストを送ること。受信確認、acknowledeは、200ステータスコードを返すことでおこなう
利用されるのは
同じwebhookで処理する必要がある複数のトピックがある(pullしたいとき対象が一つでない)。app engine/cloud functionsが受信者
pull
受信する対象がpub/subサーバに対して取得することpullを行って、メッセージを取得、acknowledgeを呼び出すことで受信確認
利用されるのは
メッセージ多いとき(1message/1s)。処理の効率やスループットが重要。パブリックなHTTPSエンドポイントが現実的でない(pub/subのwebサーバだとうまくいかないとき)
cloud sql
auth proxy
read replicaのfail over
定期的にメンテナンスが入ることによりHAであってもダウンタイムは起きる
dataproc
hadoopのクラウド版
分散ストレージとして
hdfs local SSDを選ぶことができる
gcsとhdfsを併用することもできる
bq
監視はaudit logがいい
cost
ストレージの使い分け gcsか、永続化かボリュームか
configのcli
サービスごとにregionの設定ができる
GCE google compute engine
sole-tenant nodes.
VMの種類?
セキュリティー的にOK
windowsもできる
gaming?もできる
deployment manager
テンプレートを使うといい
api explorer
APIの定義とかわかる
試すときは画面からパラメータ等指定してやるといい
GAE google app engine
エンドポイントを作る。スクリプト単体で起動するアプリのようなもの
ランタイムはdockerで定義する
environment standard flexibleがある
flexible
カスタムできる
インスタンスはhealth checkされる
インスタンスはregionに応じて自動配置
standard
usecase別
リアルタイムでGCSの変更を検知してなにかしたいとき
cloud function eventを使って、triggerを設定してやる
cloud spannerでクエリの最適化をしたいとき
縦にスケールさせたりkeyのないカラムをクエリしたりする
あらたにindexを定義するといい
グローバルな、トランザクションでリレーショナルなストレージがほしいとき
cloud SQL cloud Spannerが選択肢にあがる
ストレージのコストをミニマイズ
処理に使う期間はstandard storage classで
その後はcold lineで
別な用途(MLなど)でアプリケーションのデータを使いたい時
リードレプリカを検討
semi structuredなデータを検索用途でつかうとき
cloud datastore
mongoDB
cloud app engineとオンプレのdbをつなぐ
flexibleなタイプを使ってcloud VPN経由でつなぐ
standard / flexible
SSD / HDD
bigtableインスタンスの話
SSDはほとんどの場合で優位
はやい
スループットもいい
データ量に対して、ノード量が必要になることが欠点
HDDはレイテンシーを気にしない、アクセス頻度が少ない大量なデータ (10TB以上)の時に適している
大量なデータについてはHDDの方がコスト的にいい
その他トピック
bqのストリームのユースケース
datafution
bqデータ増えて遅くなったら。クラスタの作成とか
firestoreの設定