GCPのデータ処理サービスまとめ

# この記事はなに？
- Google Cloud認定資格の[Professional Data Engineer](https://cloud.google.com/certification/data-engineer?hl=ja)の勉強内容をまとめたものです。
- 一部、筆者の理解不足により誤った内容が書かれている可能性があります。
- 参考にしていただく際は必ず公式リファレンスも併せてご参照ください。
- また、`この内容を覚えれば資格に合格できる`と保証されたものではないことをご了承ください。

# Cloud Dataproc
## 特徴
- Apache SparkやApache Hadoopなどのマネージドサービス。
- Cloud Storageコネクタを使うことで、データをクラスタ内のHDFSではなくGCSに保管することができる。
    - クラスタをコンピュート専用リソースとして扱えたり、データの永続化を実現できる。
    - ソースとシンクのデータセットをGCSに保存し、中間データセットをHDFSに保存することとで、HDFSのパフォーマンスとGCSのバランスを取ることができる。

## コスト最適化
- ジョブの実行前にクラスタを起動し、ジョブの完了後にクラスタを破棄することで運用コストを下げることができる。
    - このようなクラスタを`エフェメラルクラスタ`と呼ぶ。
- HDFSを使用しないワーカーを`セカンダリワーカー`と呼ぶ。
    - セカンダリワーカーではコストの安い`プリエンプティブルVM`を利用することができる。
    - プリエンプティブルVMは、バッチジョブやフォールトトレラント(システムの一部が停止しても、予備のシステムに切り替えて稼働を続行できる仕組み)なワークロードに適した、有効時間が短く手頃な料金のコンピューティングインスタンス。
    - ただし、予告なしにクラスタから削除される可能性を持っているため、総ワーカー数の50%未満に抑えることが推奨される。

## 高度な柔軟性モード(EFM)
- スケールダウンやプリエンプション(実行中のプログラムを強制的に中断し、他のプログラムの実行に切り替えること)のためにワーカーノードを削除すると、ノードに保存されているシャッフル(中間データ)が失われる可能性がある。
    - プリエンプティブルVMを使用したり、自動スケーリングの安定性を改善したい場合は、高度な柔軟性モードを有効にすることが推奨される。

## 自動スケーリング
- 次の場合に、自動スケーリングの使用が推奨される。
    - GCSやBigQueryなどの外部ストレージにデータを格納するクラスタである。
    - 多数のジョブを処理するクラスタである。
    - 単一ジョブのスケールアップをするクラスタである。
    - Sparkバッチジョブの高度な柔軟性モードを使用している。

## コネクタ
- Apache Sparkクラスタでspark-bigquery-connectorを利用すると、Dataprocから直接BigQueryのデータを読み書きすることができる。

## ワークフローテンプレート
- YAML形式でDAGでワークフローを定義することができる。

# Cloud Dataflow
## 特徴
- Apache Beamのフルマネージドサービス。
- ストリーミング処理とバッチ処理の両方できる。
- Java、Python、Go、SQLでパイプラインを定義できる。
    - 要件によっては、Googleが用意したテンプレートを使うことで実装コストを削減することもできる。
- BigQueryにデータをインサートする際に、破損しているデータがあった場合は、BigQueryにデッドレターテーブルを作成して、サイドアウトを利用して破損データをインサートできる。
- ジョブをキャンセルする方法は2つ。
    - キャンセルは、その時点で処理中のデータも失われて停止する。
    - ドレインは、処理中のデータがすべて処理し終わったら停止する。
- ワーカー数を増やすことでスケールアップできる。
    - ワーカーの最大数は、maxNumWorkersオプションで制御可能。

## Apache Beamプログラミングモデル
- パイプラインを定義する際に採用されているプログラミングモデル。
- `パイプライン`は、入力→変換→出力の一連の処理をカプセル化したもの。
- `PCollection`は、パイプライン上でデータを保持するデータセット。
- `Transform`は、PCollectionに対して変換処理を加えるもの。
- `ParDo`は、Transform内で機能し、PCollectionに対してユーザー指定の関数を適用させることができる処理。

## ウィンドウ
- イベントの発生時刻とサーバーの処理時刻は必ずしも一致しない。
- イベント発生時刻のどこまでを処理するかを定めたものを`ウィンドウ`と呼ぶ。
- 固定ウィンドウ(タンブリングウィンドウ)
    - イベント発生時刻に基づいて集計するウィンドウ。
    - 例えば30秒で設定すると、イベント発生のタイムスタンプ値が[00:00:00〜00:00:30]までのデータが1つの塊として処理される。
- スライディングウィンドウ(ホッピングウィンドウ)
    - ウィンドウ処理の開始時間をずらすことができるウィンドウ。
    - 例えばウィンドウサイズを1時間とし、ピリオドを10分とした場合、10分間隔で1時間を集計区間としたウィンドウが処理される。
    - 移動平均の計算に使われることが多い。
- セッションウィンドウ
    - ユーザーIDなど、キーごとに異なるウィンドウを割り当てる。
    - 最小ギャップ時間以降に発生したイベントは、別ウィンドウとして処理される。

## ウォーターマーク、トリガー、アミュレーション
- ウィンドウのデータが、パイプラインにすべて到着したとシステムがみなす時間のことを`ウォーターマーク`と呼ぶ。
    - ウォーターマーク以降のデータは、遅延データとして処理される。
- ウォーターマークに基づいてデータを出力するタイミングを指定するものを`トリガー`と呼ぶ。
- 集計結果を出力する際の計算方法を、`アミュレーション`と呼ぶ。
    - 破棄モードでは、ウォーターマーク以降の遅延データを破棄して計算する。
    - 累積モードでは、遅延データがあった場合に再計算を行う。
    - 破棄＆後退モードでは、まずウォーターマークに基づいて計算を行い、その後遅延データがあった場合は再計算を行った上で、間に合えば結果の差し替えを行う。

## テンプレート
- パイプラインの処理をまとめたもの。
- Google提供のものもあれば、Pythonで独自に定義することもできる。
- テンプレートはGCSに保存され、DataflowはGCS内のテンプレートファイルを読み取ってジョブを実行する。

## サイドインプット
- 通常の入力のPCollectionに加えて、追加の入力をTransformに渡すことができる機能。

## 有効にする必要のあるAPI
- GCE、Cloud Logging、GCS、BigQuery、Cloud Pub/Sub、Datastore


# Cloud Data Fusion
## 特徴
- フルマネージドなデータ統合サービス。
- GUIベースでETL/ELTのパイプラインを構築できる。
- ハイブリッドやマルチクラウドに対応。
- 裏ではDataprocが起動している。

# Dataprep by Trifacta
## 特徴
- サーバーレスなETLサービス。
- ノーコードでパイプラインを実装できる。
- 裏ではDataflowが起動している。