Associate Data Practitioner試験対策マニュアル

G-genの杉村です。Google Cloud（旧称 GCP）の認定資格である Associate Data Practitioner 資格の試験対策に有用な情報を記載します。

基本的な情報

Associate Data Practitioner とは

Associate Data Practitioner 試験は、Google Cloud（旧称 GCP）の認定資格の一つです。当試験は2024年10月30日、Beta 版として公開されました。2024年11月現在では Beta 版の位置づけであり、一般公開（GA）時には内容が一部変更になる可能性があります。

当試験は Associate レベルの資格であり、Google Cloud 上でのデータ取り込み、変換、パイプライン管理、分析、機械学習、および可視化等に関する知識や技能が問われます。

試験時間は Beta 版時点で150分、問題数は70問です。ただし、当社社員が2024年11月10日時点で受験した際には、Beta 版としてフィードバックを得るためか、73問が出題されました。2024年11月現在、英語版のみが提供されています。

2024年11月現在、Google Cloud のデータエンジニアリング関連の認定資格としては Professional Data Engineer が存在しています。Professional レベルの認定資格は、技術的な知識だけでなく、ビジネスユースケースにあわせてソリューションを検討するより高度な知見が求められるのに対して、Associate レベルの資格は、技術的な知見のみに特化しています。当記事で紹介する Associate Data Practitioner は、Professional Data Engineer の下位資格の位置づけと考えれます。

• 参考 : Associate Data Practitioner - Beta

当資格の上位資格である Professional レベル試験である Professional Data Engineer については、以下の記事も参照してください。

blog.g-gen.co.jp

難易度

Associate Data Practitioner 試験の難易度は、他の認定試験と比較して低〜中程度 といえます。

「RDBMS」「トランザクション」「データモデリング」「SQL」「分散データベース」など、基本情報技術者試験でも学ぶような基礎レベルのリレーショナルデータに関する知識に加えて、非正規化を含むデータ分析向けのデータモデリング、オブジェクトストレージの基本などを理解されている方であれば、追加の学習を1ヶ月程度行うことで十分に合格を狙えます。

また基礎知識として、Associate Cloud Engineer 程度の Google Cloud の基礎知識を持っておくことで、IAM による権限管理などを1から学習しなくても済みます。

受験者に推奨される経験として、公式サイトには「Google Cloud 上での6ヶ月以上の実務経験」とありますが、細かな操作やコマンドに関する出題は多くありません。むしろ普遍的な標準 SQL の書き方に親しんでおくことが重要です。また、Google Cloud のベストプラクティスを正しく理解し、それに沿って答えることが重要です。

出題傾向

当試験では、以下のような Google Cloud ソリューションに関する出題がほとんどです。

• Cloud Storage
• BigQuery
• Pub/Sub
• Dataflow
• Dataform
• Cloud Data Fusion
• Dataproc

また一部では、Cloud SQL の可用性など、オペレーショナルデータベースに関する出題もされます。

試験で出題される Google Cloud で実装されるデータ分析基盤は、必ず BigQuery が中心であるといって差し支えありません。BigQuery をデータウェアハウス（データ分析用データベース）として、そこにデータを取り込み（ingest）するためのツールとして Pub/Sub、Dataflow、Cloud Data Fusion などが登場します。それを理解しつつ、Google が提唱する以下のようなベストプラクティスに沿うような回答を心がけることが重要です。どの認定試験でも共通して言えることですが、原則から大きく外れなければ、合格は難しくありません。

• データ分析用データベースは BigQuery
• 管理工数を小さくするために、可能であればフルマネージドサービスや、備え付けの機能を選ぶ
  • Apache Airflow on Compute Engine より Cloud Composer
  • Spark on GKE より Dataproc Serverless
  • 機械学習フレームワークよりも BigQuery ML
• 維持・保守工数を小さくするために、可能であればノーコードで実装できる方法を選ぶ
  • BigQuery のハウスキーピングは、Cloud Run functions で実装するよりも、パーティションの有効期間設定を使う
  • Cloud Storage のハウスキーピングは、Cloud Run functions で実装するよりも、オブジェクトライフサイクルを選ぶ

試験対策

以下の勉強方法はあくまで一例であり、最適な方法は、受験者の予備知識や経験によって異なるものとご了承ください。

1. Associate Cloud Engineer レベルの Google Cloud 基礎知識を習得する
2. 前掲のデータ基礎知識をキーワードベースで理解する
3. 試験ガイドを読み、知らないキーワードや機能について公式ドキュメントで学ぶ
4. 当記事の出題傾向を読み足りない知識領域をカバーする学習を行う
5. ウインドウ関数や BigQuery ML など特殊な SQL の使い方を理解する

なお Associate Cloud Engineer 試験の学習については、以下の記事も参照してください。

blog.g-gen.co.jp

当記事ではこれ以降、試験にあたって何を勉強しておくべきか、機能分野ごとに紹介しますので、参考にしてください。当記事では、Google Cloud の基礎知識を詳細にお伝えすることはありませんので、その点にはご留意ください。

ETL と ELT

ETL と ELT の基本

BigQuery はスケーラブルなコンピュート基盤を持っているので、まずデータを BigQuery に取り込んでから変換する「ELT（Extract、Load、Transform）」の順番で処理することが可能です。ELT は、スケジュールされたクエリ（Scheduled queries）や Dataform で行うことが多いといえます。

しかし当試験では、BigQuery へ Load する前に Cloud Data Fusion や Dataflow、Dataproc でデータクレンジングを行う「ETL（Extract、Transform、Load）」の出題も多くあります。

多くの問題では、ELT と ETL どちらを採るべきか、問題文を読めば明確です。

上記に登場したそれぞれのサービスが、どのようなものであるか、概要を理解しておいてください。

オープンソースツールとフルマネージドサービス

Google Cloud のデータ分析向けフルマネージドサービスは、多くがオープンソースソフトウェア（Open Source Software、OSS）をベースとしていることに注意してください。例えば Cloud Composer は、OSS である Apache Airflow のフルマネージドサービスです。Google Cloud プロダクトと、その元となった OSS の名称との対照は覚えてください。試験では、例えば「オープンソースの技術スタックを利用したい」などの要件が提示されるかもしれません。

Google Cloud プロダクト名	OSS 名
Cloud Composer	Apache Airflow
Dataflow	Apache Beam
Dataproc / Dataproc Serverless	Apache Hadoop、Apache Spark 等
Cloud SQL for PostgreSQL	PostgreSQL
Cloud SQL for MySQL	MySQL

また、これらの各プロダクトの（= OSS の）得意分野とユースケースをしっかり把握しておきましょう。以下のような大原則をしっかり覚えておいてください。

Google Cloud プロダクト名（OSS 名）	ユースケース
Cloud Composer（Apache Airflow）	DAG（有向非巡回グラフ。いわゆるワークフローまたはジョブネット）を Python で記述。多くの組み込みオペレーターがある
Dataflow（Apache Beam）	バッチ処理とストリーミング処理を両方処理できる
Dataproc（Apache Hadoop、Apache Spark 等）	ファイルを大規模に並列処理
Cloud SQL（PostgreSQL、MySQL）	オペレーショナルなリレーショナルデータベース

このようなことから、例えばもし「バッチ処理とストリーミング処理を同じ技術スタックで処理したい」という要件があれば必ず Dataflow を選べますし、「Apache Spark ワークロードをクラウドに移行したい。クラスタの管理は行いたくない」とあれば Dataproc Serverless が選べます。

Cloud Data Fusion

Cloud Data Fusion は、ノーコードで開発可能な、フルマネージドの ETL ソリューションです。ノーコードで ETL パイプラインを開発したいシチュエーションで活用できます。以下のような利用が可能です。

• Cloud Storage のデータを読み取り、データ変換してから BigQuery に格納
• データベースに接続し、データを抽出し、変換してから BigQuery に格納

イベントドリブンアーキテクチャ

イベントドリブンアーキテクチャとは、ある1つの処理が完了したことをきっかけに、別の処理がトリガーされるようなアーキテクチャをいいます。例えば、Cloud Storage バケットにオブジェクトがアップロードされたことをきっかけに Cloud Run functions（旧称 Cloud Functions）が起動し、ファイルを読み込んでデータを BigQuery にロードするようなアーキテクチャです。多くの場合、処理のためのプログラムはサーバーレスプラットフォームにホストされます。

次々に到着する小さいデータを順次処理するような仕組みでは、イベントドリブンなアーキテクチャが適しています。反対に、Cloud Run functions のようなサーバーレスプラットフォームは実行時間に制限があることから、大きなファイルの処理（長時間の処理）には適していません。イベントドリブンがどのようなユースケースに適しているかを意識してください。

イベントドリブンについては、以下の記事も参照してください。

blog.g-gen.co.jp

blog.g-gen.co.jp

データベースの選択

Google Cloud の多用なデータベースサービスを一通り理解し、ユースケースに対して適切なデータベースを選択できるようにしてください。

以下の記事の「データベースの選択」の項を参照してください。

• 参考 : Professional Data Engineer試験対策マニュアル。出題傾向・勉強方法 - データベースの選択 - G-gen Tech Blog

BigQuery

BigQuery の基本

BigQuery は当試験で最も重要なプロダクトです。以下の記事を参照し、機能を理解してください。以下の「基本編」記事の内容が主な出題範囲と概ね重なっていますが、例外として「応用編」で簡単に紹介されている BigQuery ML は頻出範囲です。

blog.g-gen.co.jp

ELT と ETL

Google Cloud のデータ分析基盤の中心は BigQuery です。前述の通り、ELT と ETL の両方のパターンが出題されます。ELT はスケジュールされたクエリ（Scheduled queries）や Dataform で、ETL は Cloud Data Fusion や Dataflow、Dataproc で実装されます。

Dataform は SQL の拡張言語である SQLX を使い、データの変換（transformation）、テストや品質チェックまで行えるのが特徴です。

Cloud Data Fusion はノーコード、や Dataflow はバッチ処理とストリーミング処理を両方扱えること、Dataproc は Hadoop / Spark 技術スタック、というようにキーワードを覚えておけば、出題時の選択に迷うことはあまりないはずです。

また、単純で1回きりの（one-time の）データロードをローカル PC から行う、などのシンプルなユースケースでは、bq コマンドラインを用いて bq load コマンドを行うことで済む場合もあります。

半構造化データの扱い（JSON 型）

半構造化データとは、JSON フォーマットのように、ある程度構造化されているもののスキーマに柔軟性があるようなデータ構造を指します。当試験においては JSON をイメージすれば事足ります。

BigQuery には JSON 型があり、JSON 形式のような半構造的なキー・バリューを柔軟に格納することができます。SELECT 文では以下のように、key1.key2 と指定することで選択が可能です。

SELECT json_payload.id FROM `my_dataset.my_table`

このようなキーバリュー型をネストして格納できる型には他に STRUCT 型がありますが、STRUCT 型はスキーマが決まっているため、例えば日時経過でスキーマに変更がかかる可能性があり柔軟性が求められるケースでは JSON 型が便利です。また、テキスト形式であれば何でも格納できる STRING 型と比べても、パフォーマンス面とコスト面で JSON 型が有利です。

• 参考 : BigQuery の JSON 型を活用して半構造化データの力を引き出す

パーティションとクラスタリング

BigQuery のパーティションとクラスタリングについては正しく理解してください。

blog.g-gen.co.jp

また、パーティションには有効期限が設定でき、作成から一定時間が経過したデータを削除することができます。いわゆるハウスキーピングの自動化に最適です。

外部テーブル

外部テーブル（External Tables）機能を使うと、Cloud Storage に格納した CSV、JSON、Parquet、Avro ファイルや Google スプレッドシートのデータ、あるいは Bigtable に対して、BigQuery から SQL を使ってクエリすることができます。

ただし外部テーブル定義を行っても、データを BigQuery に取り込むわけではなく、あくまでデータは外部に置いたままクエリするため、パフォーマンス（処理速度）は高くありません。あくまで、クエリパフォーマンスが求められない場合や、データが少ない場合、また1回きり（one-time）のオンデマンドな分析などに利用します。

• 参考 : 外部テーブルの概要

SQL

Google Cloud 認定資格では珍しく、当試験では SQL の具体的なソースコードを選択肢から選ばせる問題が出題されます。とはいえ、複雑にネストされた長大な SQL が出題されるわけではありません。

基本的な SELECT 文、また JOIN や UNION ALL などを使って複数テーブルを組み合わせて表示する際の SQL などを理解しておいてください。

ウインドウ関数

分析用途で用いられるウインドウ関数は、文法を理解しておく必要があります。以下は公式ドキュメントですが、必ずしもわかりやすいとは言い難いため、インターネット上の情報や各種書籍を参考にして、文法を理解しておいてください。

• 参考 : Window function calls

例えば RANK () 関数を使って、「各店舗の日次売上を集計し、上位5位を表示する」といった簡単な SQL がどのようなものになるか、わかるようにしておいてください。

コネクテッドシート

コネクテッドシート（Connected Sheets）は、Google スプレッドシート（Google Sheets）から BigQuery のデータを読み取ることができる機能です。

反対に、BigQuery の外部テーブル機能では、Google スプレッドシートの URI を指定することでスプレッドシートを外部テーブルとして定義し、SQL でクエリすることができます。

これらを組み合わせると BigQuery 外部テーブルを使ってスプレッドシートの中身を読み取り、BigQuery のデータと結合して結果をテーブルに保存し、その結果をコネクテッドシートを使ってスプレッドシートから読み取る、といった相互の連携が容易に実現できます。

BigQuery のアクセス制御と暗号化

権限管理（IAM）

BigQuery へのアクセス制御は、IAM（Identity and Access Management）を用いて行います。最小権限の原則に従うのがキーです。

BigQuery と IAM については以下の記事で詳細に解説しています。

blog.g-gen.co.jp

記事でも紹介しているとおり、たとえば BigQuery のデータへの読み取りアクセスのために必要な最小権限を与える場合、対象アカウント（グループ）に以下の権限をプロジェクトレベルで付与します。

• BigQuery ジョブユーザー（roles/bigquery.jobUser）
• BigQuery データ閲覧者（roles/bigquery.dataViewer）

データの編集（UPDATE や DELETE）が必要な場合は、上記の「BigQuery データ閲覧者」の代わりに「BigQuery データ編集者（roles/bigquery.dataEditor）」あるいは「BigQuery データオーナー（roles/bigquery.dataOwner）」を付与します。ポイントは、ジョブ（クエリ）の実行には「BigQuery ジョブユーザー（roles/bigquery.jobUser）」が必要になるという点です。詳細は前掲の当社記事を参照してください。

承認されたビュー

承認されたビュー（Authorized view）機能を使うと、ビューへのアクセス制御を簡素化できます。シンプルで効率の良い方法で、ビュー（特定のクエリ結果）へのアクセスを制御したい場合に利用できます。以下の記事を参照して、仕様を理解してください。

blog.g-gen.co.jp

透過的な暗号化

透過的な暗号化では、暗号鍵への適切なアクセス権限を持っていれば、利用者は暗号化を意識せずにストレージ上のデータを利用できます。

Google Cloud では転送中のデータ（data in transit）と保管中のデータ（data at rest）は共にデフォルトで暗号化されています。これをデフォルトの暗号化と呼びます。デフォルトの暗号化で暗号鍵として使われる鍵は Google が管理されており、適切に保管、ローテーションや廃棄が行われます。この鍵のことを Google-managed encryption keys、略して GMEK と呼称します。

• 参考 : デフォルトの保存データの暗号化
• 参考 : 転送データの暗号化

また、BigQuery のコンソール画面（BigQuery Studio）や bq コマンドを使うとき、データはインターネットを経由して転送されますが、通信は HTTPS で暗号化されています。これは BigQuery だけでなくすべてのサービスで共通です。つまり、ユーザーが何もしなくても、Google Cloud を利用している限り、転送中のデータ（data in transit）と保管中のデータ（data at rest）はともに、暗号化されていることになります。

ただしセキュリティ向上や法的規制の要件への遵守などの目的で、GMEK ではなく独自の暗号鍵を利用する必要がある場合もあります。その場合は、Cloud KMS を使って独自の暗号鍵を管理することができまし。このとき、この顧客独自の鍵のことを Customer-managed encryption keys（CMEK）と呼びます。

blog.g-gen.co.jp

さらに厳しい規制要件等では、クラウド環境に鍵を保管することが許されない場合もあります。その場合は顧客の独自環境で鍵を保管・管理し、暗号化・復号のたびに鍵を保管場所から取り出して利用することができます。このとき、この鍵のことを Customer-supplied encryption keys（CSEK）と呼びます。

• 参考 : 顧客指定の暗号鍵

GMEK < CMEK < CSEK の順で保守や運用の工数は大きくなりますが、厳しい要件に対応することができます。試験では、これら3種類の鍵の意味を正しく理解していれば、正答を選ぶことができます。

BigQuery ML

BigQuery ML の基本

当試験では BigQuery ML の基本的な理解を問われます。BigQuery ML では何が実現できるのか、またリモートモデルによる Vertex AI モデルの呼び出しといった概念を理解してください。

• 参考 : BigQuery の AI と ML の概要

組み込みモデル

BigQuery ML には、すぐに利用可能なビルトインモデルが存在します。これらのモデルを指定し、トレーニングデータを投入すれば、SQL だけで簡単に独自モデルを開発可能です。

• 参考 : 内部でトレーニングされたモデル

代表的なモデルとユースケースを頭に入れておいてください。時系列（Time series）と線形回帰（Linear regression）はよく似ていますが、例えば店舗の需要予測の際、セールなどの異常値や季節性の変化を考慮に入れてトレーニングできるのは時系列予測です。

モデル名	用途
時系列（Time series）	時系列予測。異常値、季節性、休日が考慮される
線形回帰（Linear regression）	線形の予測。例えば、特定の日の商品売上
ロジスティック回帰（Logistic regression）	True である可能性を0と1の間で予測
K 平均法クラスタリング（K-means clustering）	データの分類。顧客セグメントの分別など
行列分解（Matrix factorization）	商品のレコメンデーション等。過去の行動を評価しておすすめを作成
主成分分析（Principal component analysis、PCA）	データの次元削減

またモデルをトレーニングする際にどのような SQL を書けばよいのかという細かい点も出題されます。例えば以下のドキュメントでは、ロジスティック回帰の目的変数となる列の列名を input_label_cols オプションで指定しています。デフォルトでは目的変数列は label となるため、CREATE MODEL 文の中の SELECT 文で as label として列を選択すれば、その列が目的変数としてトレーニングされます。

• 参考 : ロジスティック回帰モデルを作成する

スキューとドリフト

トレーニングしたモデルを本番運用する際に重要なキーワードとして、データスキュー（Data skew）とデータドリフト（Data drift）という言葉を理解しておいてください。BigQuery ML の公式ドキュメントでは以下のように定義しています。

名称	意味
データスキュー（Data skew）	トレーニングデータの分布が、本番環境でサーブされるデータと大きく異なる場合に発生
データドリフト（Data drift）	本番環境でのデータが時間の経過とともに大きく変化した場合に発生

すなわち、データスキューを監視することでトレーニングと実践のデータのずれを、データドリフトを監視することで時間経過に伴うモデルの劣化を、それぞれ検知することができるといえます。

• 参考 : モデル モニタリングの概要

Gemini

BigQuery では、リモートモデルを作成することで LLM である Gemini を呼び出すことができます。CREATE OR REPLACE MODEL でリモートモデルを定義したあと、ML.GENERATE_TEXT で Gemini を呼び出し、BigQuery 内部のデータをインプットしてテキストを生成させることが可能です。

AutoML

AutoML に関する問題も、若干出題されます。Google Cloud の AutoML では、大量の教師データを Cloud Storage 等に配置しておき、AutoML のトレーニングを実行することで、簡単に独自の機械学習モデルをトレーニングすることができます。

• 参考 : AutoML 初心者向けガイド

Cloud Storage

Cloud Storage の基本

Cloud Storage は頻出プロダクトです。以下の記事を参照し、機能を理解してください。

blog.g-gen.co.jp

特に、この後の見出しで列挙する機能名は必ず押さえてください。

ストレージクラス

Cloud Storage の ストレージクラスの概念は正確に理解してください。

ストレージクラス	保管料金	オペレーション料金	最低保管期間
Standard Storage	高い	安い	なし
Nearline Storage	↑	↓	30 日
Coldline Storage	↑	↓	90 日
Archive Storage	安い	高い	365 日

Standard > Nearline > Coldline > Archive の順で保管料金が安くなっていくことや、最低保管期間（この期間より短くオブジェクトを削除すると、この期間分の保管料金は発生する）が長くなっていくことを理解してください。最低保管期間は0、30、90、365と覚え、ストレージクラスの名称と合わせて覚えておいてください。

オブジェクトライフサイクル

オブジェクトライフサイクル（ライフサイクルルール）を設定することで、古くなったオブジェクトを自動的によりアーカイブ寄りのストレージクラスに移動したり、削除したりできます。ライフサイクルのアクションは、以下の3つのみです。

• Delete（オブジェクトを削除する）
• SetStorageClass（ストレージクラスを設定する）
• AbortIncompleteMultipartUpload（途中だったマルチパートアップロードを削除する）

ライフサイクルルールを設定することで、「作成から30日経過したオブジェクトは Nearline に移動、90日経過したら Coldline に移動。1年間経過したら削除する」などの複雑なルール設定も可能です。

バージョニング

バージョニングの機能も必ず理解しておいてください。オブジェクトが上書きされても、指定した世代を残しておくことができます。前述のライフサイクルルールと組み合わせて、「オブジェクトは3世代保管する。作成から30日経過したオブジェクトは Nearline に移動し...」といった設定も可能です。

Autoclass

Autoclass 機能も出題されます。Autoclass を有効化すると、オブジェクトのアクセス状況に応じて自動的にストレージクラスを設定してくれますので、運用工数を節減することが可能です。

デュアルリージョン、マルチリージョン

Cloud Storage バケットを作成時、バケットの配置場所をシングルリージョン、デュアルリージョン、マルチリージョンの中から選択できます。それぞれの特徴は、以下のドキュメントから理解しておいてください。

• 参考 : ロケーションに関する留意事項

データの冗長性を確保しつつ、データの所在を明らかにしておくためにはデュアルリージョンを選択するシチュエーションがありえます。データの冗長化は非同期で行われます。デフォルトの非同期レプリケーションでは、1時間以内に99.9%のオブジェクトが複製され、12時間以内に100%に達します。これでは RPO（Recovery Point Objective）要件を満たせない場合、ターボレプリケーション（Turbo replication）を有効化することで、15分以内に100%のデータを複製できます。

• 参考 : データの可用性と耐久性

Storage Transfer Service

Storage Transfer Service は、Amazon S3 などの外部ストレージサービスや、オンプレミスのファイルサーバー等から Cloud Storage にデータを転送するためのフルマネージドサービスです。

BigQuery Transfer Service が BigQuery への転送を管理するサービスである一方、Storage Transfer Service は Cloud Storage への転送を管理するサービスであると覚えてください。

包含接頭辞（include filter）や除外接頭辞（exclude filter）を使い、対象範囲を絞ってジョブ複数作り、並列実行することで転送時間を短くしたり、逆に直列で実行することで API 実行制限を回避することができます。

• 参考 : 転送速度を向上させる

また Storage Transfer Service では、オンプレミスのファイルサーバーからのデータ転送も実現できます。この場合、オンプレミス側に Docker ベースのエージェントを起動する必要があります。またネットワーク帯域が限らえている場合は、エージェントが利用する帯域の上限を設定することもできます。

• 参考 : ファイル システム転送の要件
• 参考 : ネットワーク帯域幅を管理する

Storage Transfer Appliance

Storage Transfer Appliance は物理的なアプライアンスをユーザーのデータが存在する場所に配送し、物理的に結線してデータを取り込み、また Google に返送することで Google のデータセンターに直接データを持ち込めるサービスです。持ち込み先は Cloud Storage バケットになります。インターネットや専用線経由でのデータ転送ではあまりに時間がかかってしまう場合や、十分な帯域が確保できない場合に利用します。なお、日本でも利用可能です。類似サービスとして、Amazon Web Services（AWS）の AWS Snowball があります。

ペタバイト（PB）級の量のデータを Google Cloud に持ち込む場合や、数百 TB のデータを移行したいがネットワーク帯域が限られている場合等には、有力な選択肢の1つです。

• 参考 : Overview

Looker

Looker の基本

Looker は、Google Cloud が提供する BI プラットフォームサービスです。LookML というデータモデリング言語を使ってあらかじめセマンティックレイヤを定義することで、高度なデータガバナンスを実現できるのが特徴です。

LookML によるデータモデリングや、分析から後続の施策に繋げる豊富な機能、また組織外へのデータ共有に関する機能などにより、Looker は単なる BI ツールではなく、高度なデータプラットフォームとして用いられます。

なお、Looker には、従来型の Looker（Original） と、Google Cloud と高度に統合された Looker（Google Cloud Core） の2バージョンがあります。

• 参考 : Looker（Google Cloud コア）で利用可能な機能

メジャーとディメンション

Looker を使うには、データベース上のデータを使い、事前に LookML でメジャー（measures）とディメンション（dimensions）を定義します。

メジャーとディメンションは、BI ツール等では一般的な用語ですので、意味を理解しておいてください。

また、メジャーとディメンションは Looker 上では view ファイルと呼ばれる定義ファイルに定義します。

Looker における権限管理

Looker では、ダッシュボード等への権限管理のため、ユーザーをグループに格納できます。

部署やチームごとにグループを作成し、ユーザーをその中に配置したら、フォルダにおいてグループ単位で権限を付与するのがベストプラクティスです。運用負荷軽減のため、個々のユーザーにではなくグループに権限を付与するべきであるという原則は Google Cloud の IAM とも共通しています。

• 参考 : グループ

Analytics Hub

Analytics Hub は、異なる組織間でデータを効率よく、セキュアに提供しあうためのプラットフォームです。Analytics Hub は BigQuery や Pub/Sub のデータ交換に対応しています。

自社のデータを、アクセス権限を適切に管理しながら効率よく他社に提供したいシチュエーションでは、Analytics Hub が選択できます。

• 参考 : Analytics Hub の概要

Colab Enterprise

Colab Enterprise は、フルマネージドの Python ノートブックサービスです。BigQuery や Dataproc など他の Google Cloud サービスとも柔軟に連携できます。

Colab Enterprise のノートブック上から Python を使って BigQuery 上のデータを操作したいときなどに、Google アカウントの認証情報を使ってスムーズにデータ連携が可能です。

• 参考 : Introduction to Colab Enterprise

Cloud SQL

Cloud SQL に関する問題も若干出題されます。以下の記事を読み、基本を理解してください。

blog.g-gen.co.jp

Cloud SQL の高可用性（HA）インスタンスを使うと、簡単な設定で、あるリージョンの中の複数のゾーンに Primary インスタンスと Secondary インスタンスを起動し、高い可用性を実現することができます。また、これに加えて非同期レプリケーションのレプリカを加えることで、リージョン単位での障害に対応することもできます。

• 参考 : 障害復旧アーキテクチャ

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。

Follow @y_sugi_it