G-gen の杉村です。Google Cloud (旧称 GCP) 認定資格である Professional Data Engineer 試験 は、 Google Cloud でのデータエンジニアリングに関する難関資格です。当記事では試験の合格に役立つ情報を記載します。

はじめに

当記事の内容

試験の利用規約において、試験の内容を公開することは禁じられています。そのため当記事では試験問題そのものを書くこと等はせず、主にサービスカットで 合格するためには何を知っているべきか を中心に記載します。

"何を知っているべきか" が分かっていれば Google Cloud サービスの公式ドキュメント等を中心とした学習の方向性が決まりますし、何より 実務にも応用可能 だと思います。

なお、当記事で試験範囲を全てカバーできているわけでは無い点、ご了承ください。公式で発表されている試験ガイドや模擬試験などもぜひ駆使して、学習を進めてください。

当記事の想定読者

当記事は以下のような方向けです。

Professional Data Engineer 試験を受けるために勉強をしており出題傾向を知りたい
Google Cloud サービスやデータエンジニアリングの基本的な知識は把握済みだ
近日中に試験を受けようと思っているので、最後の勉強をしている

また前提知識として Google Cloud の基礎知識を押さえるため、 Associate Cloud Engineer 試験相当の知見は持っておいたほうが良いと言えます。

以下の記事も参考にしてください。

blog.g-gen.co.jp

Professional Data Engineer 試験の難易度

当試験の難易度としては、比較的高いと言えます。

"応用情報技術者試験" 程度の基本的な IT の知識があり、かつ Google Cloud をある程度業務で使用した経験があるのがベースです。これに加えて、データモデリングや ETL/ELT 、分散アーキテクチャのデータ処理基盤や RDBMS 、 NoSQL データベースなどのデータ関連技術要素に関する基礎知識は必要です。

これらの基礎知識のうえに、 Google Cloud のデータベースやデータ処理に関するサービスや、サービスの組み合わせなどについて、書籍や公式ドキュメントで理解しておくことが必要です。

また普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、 Google の考えるクラウドらしいクラウドの使い方が何か、という一種の哲学を頭にインプットしておくことが重要です。

これに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。

推奨の勉強法

Associate Cloud Engineer を先に取得する
書籍や各社のブログ等で Google Cloud のデータ関係サービスの概要を理解する。特に以下のサービスに着目する
- BigQuery / BigTable / Dataprep / Data Fusion / Dataflow / Pub/Sub / Cloud Composer / Dataproc / AutoML * / BigQuery ML
試験ガイドを読み出題範囲を理解する
当記事を読み、出題傾向を理解する
把握した試験範囲・出題傾向をもとに勉強する
模擬試験を受け、足りない知識を認識して、ギャップを埋める勉強をする

出題傾向

当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。分からない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。

そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。

組織 / IAM

IAM の継承の概念や、リソースとの紐づけ、またリソース階層 (組織/フォルダ/プロジェクト/各リソース...) などはしっかり押さえておきましょう。
以下の記事をぜひ参考にしてください。

blog.g-gen.co.jp

また IAM と BigQuery の組み合わせの応用として 承認されたビュー 機能の活用も問われます。
この機能については、ドキュメントを読んでしっかり理解しておきましょう。

blog.g-gen.co.jp

オペレーションスイート

基本

Cloud Monitoring の基本機能をしっかり理解しておきましょう。

blog.g-gen.co.jp

Google の指標のリファレンスページで Compute Engine や Pub/Sub、Cloud Storage などデータエンジニアリングにおいて重要なサービス群のメトリクスは、簡単でいいので眺めておくと良いです。

注目すべきメトリクス

もちろん全てを覚える必要はありませんが「Pub/Sub からデータを読み取って Cloud Storage にデータを書き込むパイプライン」があるとして、これを Cloud Monitoring で監視するときにどうするか、などのシチュエーションを想像してください。

Pub/Sub のメトリクスのうち subscription/num_undelivered_messages が上昇していると「処理の遅延等が起きている」とみなせるはずです。

また BigQuery には slots/allocated_for_project といったメトリクスがあります。プロジェクトごとに割り当てられたスロット数が確認できるため、複数の部署で BigQuery を使っているときにどの部署がスロットを多く消費しているのか、などが確認できます。

データパイプライン

Dataflow

Dataflow は Apache Beam のマネージドサービスです。リアルタイム処理とバッチ処理を両方扱うことができ、少なくとも一回 (at-least-once) が原則である Pub/Sub からのデータを受け取って、一回限り (exactly-once) の処理を実現します。

マネージドサービスであるため、自動的なスケールイン・スケールアウトなどを実現することで低い運用負荷が実現されます。

Apache Beam のプログラミングモデルをさらりと読んで把握しておきます。

なお、以下のドキュメントを読んで「タンブリングウインドウ」「ホッピングウインドウ（=スライディングウインドウ)」「セッションウインドウ」の用語は押さえておきましょう。

参考 : ウィンドウとウィンドウ処理関数

Pub/Sub

多くの問題文、または選択肢で Dataflow とセットで Pub/Sub が現れます。Apache Kafka を Pub/Sub で置き換える、という定番パターンが多く出題されます。

ただし、場合によっては Kafka を Compute Engine にインストールして利用するという選択肢もありえます。

Cloud Composer

Google Cloud のサービスを活用してジョブオーケストレーションを行うには Cloud Composer が有用な選択肢です。

ジョブ実行ツールとしては他に Cloud Scheduler がありますが、 Cloud Composer は DAG (有向非巡回グラフ) によるジョブの前後関係の管理やモニタリングの面で強みがあります。

Dataproc

Hadoop/Spark のマネージドサービスである Dataproc も頻出です。

ドキュメントでクラスタ構成や管理運用方法について押さえておきましょう。

Dataproc では基盤として Compute Engine VM を使います。そのためパフォーマンス向上やコスト削減にあたっては Compute Engine と同じ知識が使えます。例えば、ローカル SSD は永続ディスク（=ネットワークストレージ）よりもレイテンシが低い、であったり、セカンダリワーカーとしては Spot VM（プリエンプティブル VM）が使える、などです。

また、オンプレミスの Spark / Hive 環境をクラウドに移行する際の移行先として Dataproc が第1選択肢になります。

参考 : Apache Spark ジョブの Dataproc への移行
参考 : Dataproc での Apache Hive の使用

Dataprep / Data Fusion

Dataprep / Data Fusion は類似したサービスです。
いずれも GUI でデータ収集・変換のパイプラインを構築できるマネージドサービスです。

ノーコーディングでデータパイプラインを構築できるのが魅力です。「データアナリストがデータパイプラインを構築したいが、コードは書きたくない」といったユースケースにピッタリです。

また、Dataprep や Data Fusion では内部にスケジューリング機構を持っているため、定期的なデータパイプラインジョブの実行も可能です。

データベース

BigQuery

なんといっても Google Cloud の誇るフルマネージドなデータウェアハウスである BigQuery は、当然ながら当試験で最も出題される分野の一つです。以下をしっかり押さえておきましょう。

BigQuery の特質 (列志向, 分散アーキテクチャ, スロット...)
パーティショニング・クラスタリング
- クラスタリング列は複数指定できるが、順番にどのような意味があるか
権限管理 (IAM, 承認されたビュー...)
バックアップの実現方法
タイムトラベル機能
ロケーション選択にてマルチリージョンを選択する意味
特殊な使い方
- ストリーミングインサート (メリット/デメリット)
- コスト管理 (スキャン量, Reservation...)

以下の記事も参考にしてください。

blog.g-gen.co.jp

BigTable

基本

BigTable のユースケースを押さえておきます。

スキーマ設計についてはドキュメントをよく読み込んでおき、特に大事な行キーの設計はよく理解しておきます。

モニタリング、本番用ワークロードと分析用ワークロードの分離（アプリプロファイル）、クラスタ拡張、 Key Visualizer...など管理運用面も把握しておきましょう。

テーブル設計

基本的なこととして、行キーにタイムスタンプを使うのはバッドプラクティスです。タイムスタンプは連続した値になってしまうので、データ格納先のストレージ位置が集中してしまい、ホットスポットの原因となります。machine_4223421#1425330757685 のように先頭にカーディナリティの高い ID などを付与してキーとする手法が使われます。

また Bigtable のテーブル設計の特徴として、似たスキーマを持つデータは単一テーブルに格納する方が良い、というものがあります。また、1行に多数の列を作ることはあまり望ましくありません。すなわち、Bigtable では縦長のテーブルになる傾向があります。

参考 : スキーマ設計のベストプラクティス
参考 : 時系列データ用のスキーマ設計

その他のデータベース

Cloud SQL, Datastore, Spanner, BigTable, BigQuery...

それぞれのユースケース、できること、できないことを把握しておきましょう。どういったユースケースでどの DB を選ぶのか、問われたら答えられるようにしておきます。

以下に、役に立つであろう表を掲載します。

名称	Cloud SQL	Datastore (Firestore)	Cloud Spanner	Cloud BigTable	BigQuery
概要	マネージドRDB。MySQL/PostgreSQL/SQL Serverが利用可能	NoSQL。現在ではFirebaseサービス群に統合	無制限のスケーリング、グローバル利用が可能なリレーショナルデータベース	NoSQL。高スループット・高スケーラビリティ	データウェアハウス。分析目的のカラムナDB
ユースケース	一般的なアプリ。RDB	Web, モバイル,ゲーム等でKVSがマッチする場合	金融, ヘルスケア, ゲーム等でグローバルなトランザクション	時系列データ, 購入履歴, IoT等、高スループット・高スケーラビリティ	SQLでの分析やELT
種類	RDB	NoSQL (ドキュメントDB)	RDB かつ分散アーキ	NoSQL (ワイドカラム)	データウェアハウス (表形式・列志向)
クエリ方法	SQL	API もしくはSQLライク言語	SQL	API	SQL
トランザクション	○	△ (※)	○	✕ (1行のみ可)	✕

(※) Firestore と Datastore で仕様が違い、制限もいくつかある

データ移行

データ移行というテーマも扱われます。

オンプレミスから Google Cloud への大規模なデータ移行には Transfer Appliance という選択肢もあり、どのようなシチュエーションやどのくらいの規模のデータにこのサービスが適しているのかは頭の片隅に入れておきます。

gcloud storage rsync (gsutil rsync) コマンドを使って、手作業で Cloud Storage にデータ移行を行うこともありますし、Storage Transfer Service を使えば Cloud Storage へのデータ移行を自動化できます。

参考 : Cloud Storage とビッグデータの使用
参考 : Storage Transfer Service とは

BigQuery Data Transfer Service と Storage Transfer Service の違いには注意してください。前者は外部から BigQuery へデータを転送する仕組みで、後者は Cloud Storage へデータを転送する仕組みです。