時間: 2 時間
登録料: $200（税別）
言語: 英語、日本語
試験の形式: 50 ～ 60 問の多肢選択（複数選択）式
時間: 2 時間
登録料: $200（税別）
言語: 英語、日本語
試験の形式: 50 ～ 60 問の多肢選択（複数選択）式
1.データの取り込み
パフォーマンスのボトルネックはオンプレミス環境と Google Cloud 間のデータ転送部分にある可能性が高い状況を考える。分析処理（Dataproc）が開始されるのは、この転送が完了した後である。→ vCPUを増やし、VMごとのネットワーク帯域を引き上げる。
インターネットアクセスが制限された 状況を考える→VPC。
Cloud SQLのプライベートIPは同じ/ピアリングしたVPCから到達可能。
オンプレミスと接続するにはVPCではなく、Cloud VPNやDedicated/Partner Interconnectのような接続サービスが必要。
2.データの蓄積
マルチリージョン設定にする。
「一時的な外部テーブル」をクエリの都度作成するのは、永続的な外部テーブルに比べて管理が煩雑になり、API から繰り返し利用するシナリオには不向きである。
「較正（かくせい）」＝測定機器やセンサーの誤差を補正して正確にすること。なので、日常会話では「センサーのキャリブレーション」と言い換えることも多いです。
3.データ変換・加工・パイプラインの構築
dataprocは実践ではSparkしか殆ど使わないが、PDEではHadoop中心。
GCS にデータを置き、Dataproc からは GCS コネクタ経由でアクセスすれば、ストレージコストを大幅に削減できます。
Cloud Dataflow (Apache Beam) は特徴量作成にも使える。
Cloud DataflowはKafkaとも連携できる。
イベントの遅延到着 →Watermark
bq extract は BigQuery のデータを直接 Cloud Storage にエクスポートできるネイティブ機能で、Dataflow や Dataproc のような追加の計算リソースが不要なためコストを抑えられる。
100ms 以内に返したい → Bigtable
MariaDBとOPsエージェント
Dataflow で Parquet → BigQuery 変換。最初の ParDo 後に要素が激増し、さらに別 ParDo が続く。誤ったFusion 最適化を避けるには間に GroupByKey → ungroup を挟む（集約をまたぐと ParDo は融合されない）
4.データ分析・活用
低カーディナリティ列＋常時フィルタ → パーティショニング
高カーディナリティ列＋時々フィルタ → クラスタリング
ジョインキー列でクラスタリングすると、物理的に近い位置にデータがまとまるため、ジョイン時のスキャン範囲が狭くなりパフォーマンスが向上する。
Cloud Composer は使うが、Compute Engine で Airflow を自己管理することはしない。
（SQL変換＋運用負荷最小＋高速化）では、Spark を使わずに BigQuery に直接ロードしてSQL変換 がベスト。
Spark は「Python APIが必須」「複雑な処理ロジックが必要」「GCP外の分散処理との互換性が必要」な場合のみ選択肢になるべき。
「モデルの振る舞いを可視化して説明する」という要件は What-If Tool
高精度のモデルを構築するには BigQuery ML は多くのデータを必要とする。→ AutoML
5.データ管理・統制
Cloud LoggingとBigQuery
Cloud Logging のシンク機能を使えば、指定したフィルタ（例: BigQuery のデータアクセス監査ログ）に一致するログエントリを、Cloud Storage バケットへ継続的にエクスポートできる。これは、ログの長期アーカイブのための一般的なベストプラクティスである。
[参考サイト]
[BACK]