Slide 24
Slide 24 text
今後の課題・方針や各種技術・ツールへの言及等は、個人の見解や
知見のシェアを目的としており、組織を代表するものではありません。
補足:なぜCloud Run Jobsなのか?
24
前提:CSV連携をトリガーにBigQuery側へデータ転送する
→DataprocやDataflowのような分散処理基盤は現状は必要ないと判断し、Cloud Run Jobsでミニマムに構築
→ただ、今後要件次第で部分的に組み込む可能性はある
Cloud Run Jobs Dataflow(Apache Beam) Dataproc(Spark)
セットアップの容易さ コンテナ実行のみでOK(軽
量)
Apache Beam パイプラインの定義
が必要
Spark/Hadoop クラスタのセッ
トアップが必要
運用負荷 フルマネージド・ジョブ単発実行
(シンプル)
ジョブ監視・パイプライン管理が必要 クラスタのスケーリングや管理が必
要
適したジョブ規模 小〜中規模のバッチ処理向け ストリーミング&大規模バッチ向け 大規模データの分散処理向け
処理の柔軟性 コンテナ内で自由にコードを記
述可能(言語制約なし)
Apache Beam の制約あり(特殊
なAPIが必要)
Sparkエンジンの制約あり
スケーラビリティ 自動スケール(ジョブ単位で実
行)
ストリーミングスケール可能 Spark クラスタで分散処理
コスト 実行中のみ従量課金(アイドルコ
ストなし)
ジョブワーカーの最低コスト発生 クラスタ維持コストがかかる
Eventarc /
Workflows との連携
親和性が高く統合しやすい
(シンプルなバッチ処理向け)
パイプライン管理が複雑 ワークフロー組み込みが難しい
ユースケース 軽量・中規模のバッチ処理
(ETL, データ整形, マッピング)
ストリーミングデータ処理(ログ分
析, IoT, Big Data)
大規模バッチ(ML, DWH
処理, 分散ETL)