Google Cloud Data Engineer Professional 学習メモ

全般

BigQuery

データ取り込み

  • DML
    • INSERT, CREATE TABLE AS SELECT, LOAD DATA
  • バルクロード
    • BigQuery API の読み込みジョブ機能を利用
  • BigQuery Storage Write API
    • クライアント・ライブラリを利用し、該当 API を呼んで INSERT 処理する
    • バッチにもストリーミングにも対応
  • Streaming Insert API (tabledata.insertAll)
    • 旧 API
    • クライアント・ライブラリを利用し、該当 API を呼んで INSERT 処理する
  • BigQuery Data Transfer Service
    • 後述

クエリ

Routine

  • ユーザー定義関数（UDF）
    • SQL 内で利用する関数を定義できる
    • 利用可能言語
  • テーブル関数
    • テーブルを返すユーザー定義関数（FROM 句で利用）
  • リモート関数
    • ユーザー定義関数の処理を、Cloud Functions や Cloud Run で実行させる
    • 設定方法
      1. Cloud Functions や Cloud Run を用意し、エンドポイント URL 向けに Connection (bq mk -connection) を作成
        • エンドポイントは body で受け取った値で処理をして、JSON レスポンスを返す
      2. CREATE FUNCTION 文にて、上記 Connection を指定して関数を作成
  • SQL ストアド・プロシージャ

セッション

外部データソースへのクエリ

  • 各機能の比較一覧
  • BigLake テーブル
    • 外部データストア上の構造化データにアクセス
    • BigLake テーブルとは、外部データストアへの接続情報と実際のアクセスを託すことのできる機能
      • BigLake を介して、BigQuery 上にテーブル定義を作成できる
    • BigQuery Omni はこの機能を利用している
  • オブジェクトテーブル
    • Cloud Storage 上の非構造化データにアクセス
      • 該当の非構造化データを BigQuery ML や BigQuery リモート関数（Cloud Functions, Cloud Run）で利用できるようになる
    • BigLake 上に作成したテーブル定義をもとにアクセスする
  • 外部テーブル
    • BigLake で管理することのできない外部データストア（Cloud Bigtable, Google ドライブ）上の半構造化データにアクセス
    • 外部テーブル向けのテーブル定義を、BigLake を用いずに作成できる
  • Federated Query
    • Cloud SQL(MySQL, PostgreSQL), Cloud Spanner にアクセス
    • 該当データベースサービスの接続情報を BigQuery 内に作成できる
      • Cloud SQL の場合には、RDB の接続情報を登録する

テーブルスキーマ

ネスト（STRUCT）され、且つ繰り返しフィールド（ARRAY）のあるスキーマ

  • スキーマ定義
    • ネストデータ（STRUCT）列は、データ型を RECORD とする
    • 繰り返しデータ（ARRAY）列は、データモードを REPEATED とする
[
  {
    "name": "name",
    "type": "STRING",
    "mode": "NULLABLE"
  },
  {
    "name": "scores",
    "type": "RECORD",
    "mode": "REPEATED",
    "fields": [
      {
        "name": "subject",
        "type": "STRING",
        "mode": "NULLABLE"
      },
      {
        "name": "score",
        "type": "INTEGER",
        "mode": "NULLABLE"
      }
    ]
  }
]
  • SQL 上での表記
    • ネストデータ
      • STRUCT() or ()
    • 繰り返しデータ
      • ARRAY[] or []
-- レコードの挿入例
INSERT zunda.sample(name, scores)
VALUES ("zunko", ARRAY[STRUCT("English", 80), STRUCT("Math", 70)]),
       ("kiritan", ARRAY[STRUCT("English", 60), STRUCT("Math", 30)]);
(row) name scores.subject scores.score
1 zunko English 80
1 Math 70
2 kiritan English 60
2 Math 30 
SELECT name, scores[OFFSET(0)].subject, scores[OFFSET(0)].score
FROM zunda.sample;
(row) name scores.subject scores.score
1 zunko English 80
2 kiritan English 60
  • 繰り返しデータ（ARRAY）列 のすべての値を、１行毎に抽出する方法
    • ARRAY 列を UNNEST して、直積集合する
SELECT name, a.subject, a.score
FROM zunda.sample CROSS JOIN UNNEST(scores) AS a;
(row) name subject score
1 zunko English 80
2 zunko Math 70
3 kiritan English 60
4 kiritan Math 30

検索インデックス

  • 検索インデックス
  • 作り方
    • CREATE SEARCH INDEX ステートメント
    • インデックスを作成する列
      • テーブル内の全ての列
      • 指定した列
    • 指定可能なデータ型
      • STRING
      • ARRAY
      • STRING か ARRAY で STRUCT された列
      • JSON
    • テキスト分析ルール
      • データをインデックス化する方法を指定。データに応じて、適当なルールが存在する
      • 種類
        • LOG_ANALYZER
          • デフォルト
          • マシン・ログに最適
          • データを検索しやすい トークン という単位に分割して管理される
        • NO_OP_ANALYZER
          • 列内の値に完全一致する検索に最適
  • 使い方
    • 検索関数（SEARCH）を利用する
      • 検索インデックスがなくとも利用できるが、インデックスがあるとより効果的
      • 指定する要素
        • 検索対象のデータ（テーブル全体 or 列）
        • 検索する文字列
        • 利用アナライザ
      • 例
        • SELECT * FROM dateset.table WHERE SEARCH(table, "Tokyo", analyzer=>NO_OP_ANALYZER);
  • 管理方法
    • 方法
      • 共有スロットプール
        • デフォルト
        • 無料
        • 一定の上限までインデックス付テーブルを利用できる
          • 上限はインデックス付テーブルのデータサイズによる
            • 100TB（マルチリージョン）
            • 20TB（リージョン）
          • 上限を超えた場合、全インデックスの管理が停止する
      • 独自の Reservation
        • 本番環境での推奨
        • 既存の Reservation に、検索インデックス用のスロットを割り当てる
        • データサイズによる上限なし

BigQuery BI Engine

  • BI Engine とは
  • BigQuery が提供するオンメモリ機能
    • 主に BI ツールからのクエリをキャッシュする目的で利用
  • 利用方法
    • 利用するメモリサイズを予約する
      • メモリサイズに応じて課金
    • 優先テーブルを指定
      • 優先テーブルにアクセスしたクエリ結果がキャッシュされる

BigQuery Migration Service

  • BigQuery Migration Service

    • BigQuery Migration Service は、データ ウェアハウスを BigQuery に移行するための包括的なソリューションです。評価と計画、10 を超える言語の SQL 変換、データ転送、データ検証など、移行の各フェーズに役立つ無料ツールが用意されています。これらのツールを組み合わせて移行を加速し、リスクを軽減して、価値創出までの時間を短縮できます。

  • 機能
    • BigQuery 移行評価
      • 他データウェアハウスから BigQuery への移行の複雑さを測定できる
      • 作業
        1. 抽出ツールを用いて、移行元のデータウェアハウスからメタデータを抽出してくる
        2. 抽出したファイルを Cloud Storage において評価処理を実行
        3. 評価結果を BigQuery 内に作成し、Looker Studio でレポートを表示してくれる
    • バッチ SQL トランスレーター
      • SQL のトランスコンパイラ
      • 変換したい SQL ファイルを用意して API を実行すると、変換 SQL ファイルやレポートを作成してくれる
      • 対応
        • Redshift, Teradata
    • インタラクティブ SQL トランスレーター
      • WEB コンソール上で SQL 変換処理を実行できる

BigQuery Data Transfer Service

  • BigQuery Data Transfer Service
  • サポートされるデータソース
  • 設定方法
    • コンソール, bq コマンド, API
  • 設定内容イメージ
    • 転送ジョブを作成、みたいな
    • Source、Destination、ジョブのスケジュールオプションを指定する
  • その他ツール

データの暗号化・マスキング

BigQuery ML

アクセス制御

  • 各リソースへのアクセス権は、各 IAM ユーザー・グループ(principal)への IAM Role の付与により管理される
  • 付加的なアクセス制御
    • 承認によるアクセス制御
      • いわゆる「承認済みビュー」とか言われるもの
      • 承認できる種類
        • Authorized Dataset
        • Authorized Routine
        • Authorized View
      • 設定方法（利用法）
        1. view 参照者に、プロジェクトレベルで、bigquery.user ロールを付与
        2. source table とは別の dataset に view を作成
        3. view 参照者に、データセットレベルで、bigquery.dataViewer ロールを付与
        4. source table 側の dataset へ、view 側の dataset を承認データセット（承認ビュー）として登録
    • テーブル列（分類）による制御
      • 列レベルのアクセス制御の概要
        • ポリシータグを利用
      • 設定方法
        1. 新しい taxonomy を作成して、ポリシータグを追加
        2. 上で作った taxonomy に「アクセス制御の適用」を有効化し、ポリシータグ毎に適用する Principals を設定
          • アクセス許可したい principas に Data Catalog のきめ細かい読み取りのロール（the Data Catalog Fine-Grained Reader role） を設定
        3. アクセス制御させたいテーブルの列に、作成したポリシータグを付与する
    • テーブル行による制御 
--- ユーザー「abc@example.com」には、name 列が taro の行のみが表示される
CREATE ROW ACCESS POLICY sample_filter
ON project.dataset.my_table
GRANT TO ('user:abc@example.com')
FILTER USING (name = 'taro');
  • Analytics Hub の概要
    • BigQuery 内のデータを、他 BigQuery ユーザーと共有する仕組み
      • BigQuery データを Publish/Subscirbe するようなサービス
    • データセット・テーブル単位での共有権限（IAM を利用したもの）でも実現できるが、それを発展/柔軟にしたサービス

管理

  • custom quotas
    • １日に処理されるクエリデータ量の上限を設定
    • 種類
      • プロジェクト全体
      • ユーザー個別
  • スナップショット
    • テーブル スナップショットの概要
    • 制限
      • テーブル単位
      • 取得スナップショットの有効期間を設定可能
      • タイムトラベル機能を利用し、取得時点だけでなく、過去７日間までの指定した時点でのスナップショットを取得できる
      • スケジューリング機能はなし
        • 何らかのスケジューラーサービスにて、取得処理を叩く必要がある
    • 取得方法
      • CREATE SNAPSHOT TABLE 文
      • bq cp --snapshot
      • API
  • タイムトラベル
    • タイムトラベルを使用した履歴データへのアクセス
    • 過去７日間の、任意の時点のデータにアクセスできる ※デフォルト
    • 利用方法
      • FOR SYSTEM_TIME AS OF 句 を利用
        • SELECT * FROM t FOR SYSTEM_TIME AS OF '2017-01-01 10:00:00-07:00';
        • SELECT * FROM t FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR);
      • bp cp コマンドを利用して、テーブルとして復元
        • UNIX 時間を指定
          • bq cp dataset.table@1624046611000 dataset.table_restored
        • 相対時間（ミリ秒）で指定
          • bq cp dataset.table@-3600000 dataset.table_restored
  • モニタリング
    • INFORMATION SCHEMA
    • Cloud Monitoring の指標
      • query/scanned_bytes_billed
      • slots/allocated_for_project_and_job_type, slots/allocated_for_reservation
      • storage/stored_bytes
    • Cloud Auditlog
      • AuditLog
        • BigQuery 全体に関わる操作（Reservation, Connection）を記録
      • BigQueryAuditMetadata
        • テーブルに対する読み書きのアクセスを記録

Cloud SQL

インスタンス・構成

管理

アクセス制御

  • アクセス制御の認可
    • インスタンス・レベル
      • IAM で管理
    • データベース・レベル
      • データベース側機能
  • 接続制限
    • Cloud SQL Auth Proxy
      • Public IP/Private IP 環境
      • Forward Proxy として機能する
    • 承認済みネットワーク
      • Public IP 環境
      • アクセス可能な IP アドレスをデータ指定

Database Migration Service

Cloud Bigtable

アーキテクチャー

スキーマ設計

  • テーブルを構成する要素
    • 行
      • Bigtable は行志向データベース
    • 行キー（インデックス）
      • 検索時のキー
        • ２次インデックスはない
      • タブレット上に、辞書順に並ぶ
    • 列ファミリー
      • 列をグルーピングする概念
    • 列
      • 列修飾子という列名に近い概念
        • だが RDB における列名と同等の理解は危険
      • 列ファミリー内で、辞書順に並ぶ
    • セル
      • 特定の行と特定の列が交差する部分
      • 登録されたタイムスタンプをもとに、複数のデータを登録できる
        • つまり、単一のデータのみを登録/更新するのでなく、履歴が積み上がっていくイメージ
  • 最適なスキーマ設計・ベストプラクティス
    • 行キー
      • カーディナリティが低い順に、値を連結した文字列を使う
        • ドメインの場合 www.google.com より com.google.wwww のほうが望ましい
        • 最新の登録値を利用するケースが多い場合、リバース・タイムスタンプやシーケンシャル ID のリバース版を利用する
          • 行キーは辞書順/昇順に並ぶため、こうすれば該当行を早く見つけることができる
    • 列修飾子
      • データとして扱う（列名みたいに利用しない）
  • 時系列データ用のスキーマ設計
    • 時間バケットパターン
      • 1 行を月、週、日などの特定の期間で管理する
      • 後者の「単一タイムスタンプ毎に単一行を利用するパターン」よりパフォーマンスは良い
        • アクセスする行数が減るので
      • 更に細かい手法
        • 新しいイベント毎に新規列を追加
        • 新しいイベント毎に新規セルを追加
    • 単一タイムスタンプ毎に単一行を利用するパターン
      • 時間バケットパターンより実装が容易で、クエリ変更への柔軟性が高い
  • パフォーマンス
    • パフォーマンス低下の原因
    • パフォーマンステスト時の留意点
      • 十分なデータサイズ
      • 単一のテーブルでテスト
      • 負荷の大きな事前テストを数分間実行する
        • これによりノード間にデータを分散してくれる
      • 最低 10 分間テストする
        • これによりノード間にデータを分散してくれる
    • Cloud Monitoring のメトリックス
    • Key Visualizer
      • 行へのアクセス状況を視覚化できる
      • 警告指標
        • Read pressure index
          • 値が 100 以上の場合、Read 処理の高負荷
            • クエリ見直し・スキーマ見直し・アプリケーションファイルの再検討
        • Write pressure index
          • 値が 100 以上の場合、Write 処理の高負荷
        • Large rows

管理

アクセス制御

Cloud Spanner

Cloud Spanner のアーキテクチャー

  • Cloud Spanner のハイレベルアーキテクチャ解説
  • インスタンス
    • リージョン or マルチリージョン
      • コンピューティング層はゾーン間で分散されて配置
      • マルチリージョンである優位性
        • 距離的に離れた複数クライアントからのアクセスに早くなること
  • ノード/スロット
    • コンピューティング・リソースのサイズ
    • 以下より選択
      • ノード単位
        • 1000 スロット/1 ノード
      • スロット単位
        • 1000 スロットから
        • 以降は 100 単位で管理可能
  • ストレージ層
    • ノード/スロットに紐づく
    • 1 ノード（1000 スロット）あたり 4TB
    • データは Split という単位で管理される
      • ノードとストレージ層間の、データ I/O 単位みたいな
        • 複数ゾーンに跨った、ストレージ層上でのデータ分散も Split 単位で行われる
      • 4GB/1split
      • 主キーの辞書順に並べられて格納されている
  • データベース

スキーマ

  • 主キー
    • ホットスポットを防ぐ
      • 主キーとする列の順序を考慮
        • 「利用日時 + ユーザー ID」みたいな組み合わせ/順序にする
      • split シャーディング用の HASH 値を用意し、主キーに含める
        • 「HASH 値 + 利用日時 + ユーザー ID」みたいな組み合わせ/順序にする
      • UUID を利用
      • ビット反転の値を利用
        • 本来 11010001 という数値の場合 10001011 という数値として利用する
    • タイムスタンプ・キーを降順に格納する
      • 最新日付からデータを取得することが多い場合、主キーの設定時に降順の指定（DESC）を加える
    • テーブル作成後は変更できない
  • 親子テーブル関係
    • 正規化して複数に分かれたテーブルを、データ層上で近い位置（同一 Split 内）に配置する工夫、みたいな
    • テーブル・インターリーブを利用して作成
      • 子テーブルを作成する時に、親テーブルを指定
      • 子テーブルの主キーの先頭は、親テーブルの主キーでないといけない
      • Google 標準 SQL
        • CREATE TABLE 子テーブル名 ( ... ), PRIMARY KEY ( ... ), INTERLEAVE IN PARENT 親テーブル名 ON DELETE CASCADE;
  • ビュー
  • セカンダリ・インデックス
    • インデックス・オプション
      • インターリーブされていないインデックス
        • インデックスのデータは、インデックス元テーブルの位置を考慮せず、split 上に格納される

        • Spanner は、テーブルと同じ方法でインデックス データを格納し、インデックス エントリごとに 1 行を使用します。テーブルの設計上の考慮事項の多くは、インデックスにも適用されます。 インターリーブされていないインデックスは、ルートテーブルにデータを格納します。 ルートテーブルは任意のルート行の間で分割できるため、インターリーブされていないインデックスは、ほとんどどのようなワークロードでも、ホットスポットを無視して、任意のサイズに拡大できます。残念ながらこれは、通常はインデックス エントリがプライマリ データと同じスプリットに含まれないことも意味します。これにより、書き込みプロセスでは余分な作業とレイテンシが発生し、読み取り時には参照するスプリットが増えます。

      • インターリーブされたインデックス
        • インデックスのデータは、インデックス元テーブルの位置を考慮して、split 上に格納される

        • 一方、インターリーブされたインデックスでは、データはインターリーブされたテーブルに格納されます。これらは、単一エンティティのドメイン内を検索する場合に適しています。 インターリーブされたインデックスでは、データとインデックスのエントリは強制的に同じ行ツリーに格納され、それらの間の結合がはるかに効率的になります。

    • 作成方法（Google 標準 SQL）
      • インデックス
        • CREATE INDEX インデックス名 ON テーブル名(インデックス列, インデックス列, ...);
      • インターリーブされたインデックス
        • CREATE INDEX インデックス名 ON テーブル名(インデックス列, インデックス列, ...) INTERLEAVE IN 別テーブル名;
    • インデックス作成は、大規模なスキーマ更新処理にあたる
    • クエリ・ヒント
      • SELECT ... FROM ... @{FORCE_INDEX=MyTableIndex}
    • NULL 値
      • デフォルトでは NULL 値もインデックスされるので、利用有無の指定ができる
    • 一意のインデックス
      • インデックスされる値を UNIQUE と宣言できる
  • 外部キー
  • チェック制約

管理

アクセス制御

Cloud Dataflow

Apache Beam の基本

パイプラインの構成

  • パイプライン・オプションで指定
    • 設定方法
    • Pipeline options リファレンス
      • Resource utilization
        • num_workers, max_num_workers
      • Security and networking
        • service_account_email
        • network, subnetwork, no_use_public_ips
      • Worker-level options
        • worker_region, machine_type, disk_size_gb
  • Dataflow prime
    • 水平スケーリングと垂直スケーリングを使用してワーカーを管理できる
      • ※水平スケーリングは、普通の Dataflow でも可能
    • Dataflow と Dataflow Prime の機能比較
    • 自動垂直スケーリング
      • ワーカーの使用可能メモリサイズを動的に調整
    • Right Fitting

管理

ジョブ（パイプライン）の管理

種類 アクション バッチ ストリーミング 説明
停止 キャンセル ○ ○ 処理を直ちに停止
停止 強制キャンセル ○ ○ 処理を直ちに停止
キャンセルの処理で停止しない場合に実行する
停止 ドレイン ○ 現在処理しているデータをもって停止
ただし window の完結を待つことはなく、window の間隔が 30 分とかであれば途中で停止となる
更新 アップデート ○ 新規ジョブが作成され、既存ジョブを置換する
ジョブ名が一致している必要がある

モニタリング

  • Dataflow Monitoring Interface
  • Cloud Monitoring
    • Apache Beam Metrics を拾う
      • Counter, Distribution を取得してくれる
    • ジョブのアラートポリシーを設定
      • ジョブの失敗やリソース利用状況を検知できる
  • Cloud Logging
    • Apache Beam コード内のロギング内容を連携してくれる

アクセス制御

  • パイプラインの作成/管理、ワーカー所持のアクセス権
  • ネットワーク
    • ワーカーが動く VPC・サブネットを指定可能
      • パイプライン・オプションで指定する
      • 指定可能
        • VPC
        • 共有 VPC
        • 何も指定しないと default vpc を利用
    • ワーカーのインターネットアクセスの制御方法
      • 通常の VM Instance と同等の管理が可能
      • External IP, Cloud NAT, 限定公開の Google アクセス（Private Google Access）,Private Service Connect

Cloud Dataproc

関連サービス

サービス名 概要 コンピューティング・リソース
Dataproc Manged な Hadoop 向け PaaS VM
Dataproc on GKE Manged な Hadoop 向け PaaS GKE
Dataproc Hub Managed な Jupyter Hub -
Dataproc Serverless サーバーレスな Spark 実行環境 -
Dataproc Metastore サーバーレスな Hive ベースのメタストア -

Dataproc クラスタ

  • 配置先
    • global（特別なマルチリージョンを意）
    • リージョン
      • 複数リージョンを指定することも可能
  • エンドポイント
    • gcloud CLI コマンドでクラスタを管理する際に指定
    • グローバル・エンドポイント
    • リージョン・エンドポイント
      • 複数リージョンを指定した場合は、複数作成される
  • クラスタ・タイプ
    • 種類
      • 標準（マスター 1 個、ワーカー N 個）
      • 単一ノード（マスター 1 個、ワーカー 0 個）
      • 高可用性（マスター 3 個、ワーカー N 個）
    • 利用するスケーリングポリシー
    • 高度な柔軟性モード（Enhanced Flexibility Mode）
      • シャッフルデータを管理し、ノードの削除に起因するジョブの遅延を最小限に抑える
  • スケーリングポリシー
    • ワーカー構成（プライマリ/セカンダリの最小最大ノード数・重み）
    • graceful decommission timeout の管理

      • Timeout in seconds for YARN node graceful decommission. This is the maximal time to wait for running containers and applications to complete before transition a DECOMMISSIONING node into DECOMMISSIONED.

      • Graceful Decommission of YARN Nodes
    • クールダウン期間の管理
  • ノード種類
    • マネージャーノード
      • YARN Resource Manager 等
    • ワーカーノード
      • コンピューティング・リソースにあたる
      • 種類
        • プライマリ・ワーカーノード
          • 必須
        • セカンダリ・ワーカーノード
          • プライマリ・ノードの処理性能を補う目的で追加可能
          • HDFS 利用不可
          • VM タイプ
            • preemptible
            • 非 preemptible
            • SPOT
  • ノードの構成
    • マシンタイプ
    • ディスク
      • ディスク領域
        • メインディスク
          • ブートボリューム、システム領域、HDFS メタデータ
          • ディスク種類
            • Standard Persistent Disk (HDD)
            • SSD Persistent Disk (PD-SSD)
            • Balanced Persistent Disk
        • ローカル SSD
          • HDFS 領域
          • デフォルトではアタッチされない
  • ネットワーク
    • 利用する VPC,Subnet を選択する
      • インターネット・アクセスの管理は通常の VPC と同じ制御が可能
    • 種類
      • default VPC
      • 自動モード VPC ※VPC を勝ってに作ってくれるやつ
      • カスタム VPC

コネクタ

  • 連携可能なサービス
    • BigQuery コネクタ
      • BigQuery のデータを一時的に Cloud Storage へ退避し処理する
        • 処理成功時に退避した一次ファイルは削除される
        • 失敗時は残る
      • 利用方法
        • Hadoop 向けであれば初期設定不要。コード内で import するだけで利用可能
        • Spark 向けの場合
          • クラスタ作成時に Dataproc コネクタ初期化アクションで該当 jar ファイルを指定してクラスタを作成する
          • ジョブ送信時に、該当 jar ファイルを指定して実行する
    • Cloud Storage
      • 利用方法
        • Hadoop, Spark 向けのいずれにおいても、該当 jar ファイルがクラスタにインストール済みである
        • Cloud Storage と HDFS の比較

          • 一般に、大容量のデータ パイプラインでは、Cloud Storage をデータの最初と最後のソースとして使用することをおすすめします。たとえば、ワークフローに 5 つの Spark ジョブが連続して含まれている場合、最初のジョブは Cloud Storage から初期データを取得し、シャッフル データと中間ジョブ出力を HDFS に書き込みます。最後の Spark ジョブは、その結果を Cloud Storage に書き込みます。

    • Cloud Bigtable
      • java クライアントライブリが用意されている
      • Spark, HBase Spark 向けの jar ファイルが公開されている
      • 利用方法
        • ジョブ送信時に、該当 jar ファイルを指定して実行する
    • Cloud Pub/Sub Lite
      • java クライアントライブリが用意されている。python でも利用可
      • Spark 環境でのみ利用可
      • 利用方法
        • ジョブ送信時に、該当 jar ファイルを指定して実行する

データ移行

アクセス制御

管理

  • モニタリング
    • Cloud Monitoring
      • 収集されるもの
        • Dataproc のメトリクス（ワーカーのリソース情報）
        • Hadoop のメトリクス
    • Cloud Profiler
      • Dataproc Hadoop と Spark ジョブの CPU やメモリ使用状況を収集
      • 利用方法
        • クラスタ作成時に monitoring を有効
        • ジョブ実行時に Profiler オプションをつける

Dataprep by Trifacta

Cloud Data Fusion

Data Catalog

Cloud Pub/Sub

サブスクリプション

  • タイプ
  • オプション
    • デッドレター・トピック
      • 再試行ポリシーをもっても subscribe されない場合、エラー向けのトピックへ publish される
    • メッセージの順序指定
    • データのフィルタリング
    • データ・スキーマの検証
    • 1 回限りの配信
      • 一意のメッセージ ID に基づき１回限りの配信を行える
      • pull のみ
      • Ack の応答をもって配信済みと判断される
  • 他 Google Cloud サービスとの連携
    • BigQuery
      • Subscription タイプの BigQuery を利用
    • Cloud Functions
      • Cloud Fucntions の着火条件に Pub/Sub トリガーを利用
    • Cloud Run/App Engine
      • Cloud Run/App Engine のエンドポイントへ push する
    • Dataflow
      • Apache Beam 内の Pub/Sub 向けライブリを利用

管理

  • モニタリング
    • Cloud コンソール
      • Pub/Sub のページ内で、Topic, Subscription 毎にグラフ表示されている
      • Cloud Monitor の Alert 作成ページへ飛ぶリンクが用意されている
    • Cloud Monitoring
      • メトリックス
      • subscription/push_request_count, subscription/pull_request_count
      • topic/send_request_count, topic/num_retained_messages

アクセス制御

Cloud Monitoring

  • カスタム・メトリックス
    • Cloud Monitoring で利用できる独自の指標を作成する
    • 作成/データ登録方法
      • OpenCensus
        • Cloud Monitoring API への wrapper をもつ
      • Cloud Monitoring API
    • 命名規則

      • projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

Cloud Logging

転送

  • 要素
    • ログルーター
      • ログ転送を行う機能の総称
    • シンク
      • ルーティングを制御するためのコンフィグ的な
      • ログルーターにアタッチする
      • 可能な宛先
        • Cloud Storage
        • BigQuery
        • Cloud Pub/Sub
        • Cloud Logging ログバケット（任意のプロジェクトのログバケットに転送できる）
    • フィルター機能
      • inclusion filter
      • exclusion filter

Cloud DLP (Cloud Data Loss Preventation)

Cloud KMS (Cloud key Management Service)

  • Cloud KMS
  • 概念
    • key ring
      • 特定の Google Cloud ロケーション内で key をグルーピングするもの
    • key
      • まさに鍵のこと
      • key ring に紐づく
      • 種類
        • 対象鍵/非対称鍵
    • key version
      • key はバージョン管理できる
      • 自動ローテーションも可能

Looker Studio

  • データをキャッシュする仕組みをもつ
    • データの更新頻度を管理する

    • データソースがカスタム SQL クエリ SELECT \* FROM tableName に接続するとします。このクエリの結果は、データソース全体ではなくグラフとコンポーネントに適用されるため、キャッシュに保存されません。

    • ここで、レポートに指標 Sum(revenue) を含むスコアカードを追加したとします。スコアカードの基になるクエリは、SELECT Sum(revenue) FROM (SELECT \* from tableName)) のようになります。このクエリの結果は、このスコアカード用にキャッシュに保存されます。

Cloud Storage

Storage class

ストレージ クラス 最小保存期間 取得料金 利用ケース
STANDARD なし なし
NEARLINE 30 日 あり 月に 1 回程度アクセスするデータ
COLDLINE 90 日 あり 四半期に 1 回程度アクセスするデータ
ARCHIVE 365 日 あり 1 年間に 1 回未満しかアクセスしないデータ
  • ARCHIVE クラスでも、データは即時で取得できる

Storage Transfer Service

  • Storage Transfer Service
  • 可能な Data Source
    • 他のクラウド ストレージ プロバイダ（S3 等）
    • クラウドの POSIX ファイル システム
    • ローカル
      • 逆方向（Cloud Storage -> ローカル）も可
      • 1TB 超のデータの場合
      • 1TB 未満の場合には、gsutil を利用推奨
    • Cloud Storage
      • 1TB 超のデータの場合
      • 1TB 未満の場合には、gsutil を利用推奨
    • 利用ケース
      • データ処理パイプライン、または分析ワークフローの一部として、データを定期的に移動
      • Storage Transfer Service 内でスケジュールジョブを作成できる

管理

  • モニタリング
    • Cloud Audit Logs
      • 管理アクティビティ・ログ
      • データアクセス監査ログ
        • オブジェクトを変更/読み取りオペレーションを記録
        • 明示的な設定が必要
    • Cloud Monitoring
    • 使用状況ログ/ストレージログ
      • CSV 形式でログを出力してくれる
      • 基本的に、前述 2 つのサービスのいずれかで代替可能で、そちらが推奨される

Transfer Appliance

  • Transfer Appliance
  • 利用に適しているケース
    • データサイズが 10 TB 以上である
    • ネットワーク経由でデータをアップロードすると、1 週間以上かかる場合がある

Vertex AI

Vertex AI Workbench

AI Infrastructure

Cloud Vision API, Cloud Video Intelligence API

  • Cloud Vision API ドキュメント
  • Cloud Video Intelligence API
  • Managed AI サービス
    • 画像を分析する
    • 動画を分析する
  • 利用方法
    • クライアントライブリを利用して、画像ファイルを読み込む
    • Cloud Storage 上ファイルの URI を指定して、API を叩く
  • 可能な分析
    • テキスト検出
      • 単純な写真のほか、ドキュメント画像からも検出する
    • ランドマーク検出
      • ランドマークにあたるエンティティを検出して、その座標を返す
    • ロゴ検出
    • ラベル検出
    • 画像プロパティ
    • オブジェクトのローカライズ
    • クロップヒント検出
    • ウェブ エンティティとページ
      • 関連するウェブ コンテンツを画像に返す
    • 不適切なコンテンツの検出（セーフサーチ）
    • 顔・感情検出

Cloud Natural Language API

  • Cloud Natural Language ドキュメント
  • Managed AI サービス
    • 非構造化テキストを分析する
  • 利用方法
    • テキストを API へ投げる
    • Cloud Storage 上のファイルを指定して API へ投げる
  • 可能な分析
    • 感情分析
    • エンティティ分析
      • テキストに既知のエンティティ（著名人、ランドマークなどの固有名詞）が含まれていないかどうかを調べて、それらのエンティティに関する情報を返す
    • エンティティ感情分析
      • テキスト内でエンティティについて表現された感情（ポジティブかネガティブか）の特定を試みる
    • コンテンツ分類
      • テキストに適用されるコンテンツ カテゴリのリストを返す
    • 構文解析
      • テキストを一連の文とトークン（通常は単語）に分解し、それらのトークンに関する言語情報を提供する

Cloud Speech-to-Text, Cloud Text-to-Speech

  • Cloud Speech-to-Text API
  • Managed AI サービス
    • 音声をテキスト変換する
  • 利用方法
    • API の叩き方
      • （同期）音声入力のストリーミングデータを、そのまま API に渡す
      • （非同期）音声ファイルからデータを読み取って、そのデータを API に渡す
        • 音声データが 60 秒を超える場合、Cloud Storage 上に置いてファイルを置いて、API を叩く
    • レスポンス
      • レスポンスの JSON に変換結果が入っている
  • Cloud Text-to-Speech の基本
  • Managed AI サービス
    • テキストから合成音声を出力する

Cloud Translation API

Dialogflow

Document AI

  • Document AI
  • Managed AI サービス
    • ドキュメントから非構造化データを抽出（OCR）
    • ドキュメント全般に対して対応
  • 類似サービス

Recommendations AI

  • マネージド・レコメンドシステム

機械学習・AI の基本

  • 特徴量の正規化
    • 特徴量の大きさ(尺度)を揃える前処理
    • 分散正規化
      • 特徴量の平均が 0、標準偏差が 1 となるように、特徴量を変換
    • 最小最大正規化
      • 特徴量の最小値が 0、最大値が 1 となるように、特徴量を変換
  • モデルの種類
  • 過学習（overfitting）
    • 参考：オーバーフィットって何ですか？
    • 定義
      • 訓練データに対しては正確な予測を提供するが、テストデータ・実際のデータには不正確な予測となること
      • モデルが一般化できず、汎化誤差が大きくなるケース
    • 原因
      • 訓練データのサイズが小さすぎて、考えられる入力データ値を正確に表すデータサンプルでない
      • ノイズを含むデータが、訓練データに大量に含まれている
      • 1 つのサンプルデータセットに対して、モデルのトレーニング時間が長すぎる
      • モデルの複雑度が高いため、訓練データ内のノイズを学習してしまう
    • 検出する方法
    • 防ぐ方法
      • 訓練データの多様化
      • プルーニング
        • トレーニングセット内で最も重要な特徴を特定し、無関係な特徴を排除する
      • 早期停止
        • モデルがデータ内のノイズを学習する前に、トレーニングフェーズを一時停止させる
      • 正則化（regularization）
      • アンサンブル
        • 複数の弱学習器を一つにまとめて予測を行う
  • 過小学習（underfitting）
    • 定義
      • データに対して学習不足でモデルが単純過ぎて汎化誤差が大きくなるケース
  • 混合同列（Confusion Matrix）
    • 2 値分類問題で出力されたクラス分類の結果をまとめた表のこと
      • 予測と実績のクラスラベル組み合わせを集計した表
    • 2 値分類機械学習モデルの性能を測る
    • BigQuery ML で 2 値ロジスティック回帰モデルをつくる時の　ML.EVALUATE クエリ結果は、混合同列を返す
    • 指標
      • 適合率(precision)
        • 正例の場合
        • 正例と予測して、実際に正例だった割合
        • tp/(tp+fp)
        • 予測するクラスを間違えないようにしたい時に利用する指標
      • 再現率(recall)
        • 正例の場合
        • 実際の正例のうち、正例と予測した割合
        • tp/(tp+fn)
        • 一般的に、適合率と再現率はトレードオフの関係となる
      • F 値(F-Value)
        • 適合率と再現率の調和平均
        • 2/(1/適合率 + 1/再現率) = 2 _ 適合率 _ 再現率/(適合率 + 再現率)
        • 適合率と再現率のバランスが良い値になることを目指す時に利用する指標
      • 正解率(accuracy)
        • 正例と負例とを問わず、予測と実績が一致したデータの割合
        • (tp+tn)/(tp+fp+fn+tn)
  • ROC 曲線(Receiver Operating Characteristic)/AUC(Area Under the Curve)
    • 分類モデルを評価
    • ROC 曲線(Receiver Operating Characteristic)
      • 以下にて２次元上にプロットした図のこと
        • x 軸
        • y 軸
          • 信用性（True Positive）の割合
    • AUC(Area Under the Curve)
      • ROC 曲線の下線部の面積
      • モデルの良さを比較できる
        • 値が 1 に近いほど優秀
    • 参考：ROC 曲線
  • 平均二乗誤差（MSE：Mean Squared Error）
    • 損失関数
      • 「正解値」と、モデルによる出力された「予測値」とのズレの大きさを計算する関数、のこと
    • 主に、回帰問題における出力層の評価関数
    • 各データに対して「予測値と正解値の差（＝誤差）」の二乗値を計算し、その総和をデータ数で割った値（＝平均値）を出力する関数
      • 出力が 0 に近いほどより良い
  • 参考