Professional Data Engineer 完全攻略ガイド:データ取り込み編
はじめに
こんにちは、クラウドエース 第三開発部の松本です。
普段はデータ基盤や機械学習システムを構築したり、Google Cloud 認定トレーナーとしてトレーニングを提供しています。
今回は、Professional Data Engineer 完全攻略ガイドのデータ取り込み編として、データエンジニアリング基礎編に続き、データ取り込みプロダクトを中心に試験対策の内容をご紹介します!
尚、前回のデータエンジニアリング基礎編をまだ見ていない方は、以下をぜひご覧ください。
対象読者
- 試験で問われる Google Cloud のデータ取り込みプロダクトを効率的に把握したい方
- 試験対策として、データ取り込み分野を強化したい方
- Google Cloud データ取り込みプロダクトを実務で活用したい方
データ取り込みプロダクト
Google Cloud におけるデータ取り込みプロダクトとして、以下のプロダクトを押さえておくと良いでしょう。特に、データの転送元(ソース)と転送先(シンク)、ユースケースは把握しておきましょう。
データ取り込みプロダクトの比較
また、各プロダクトごとの詳細なポイントを以下に記載しましたので、確認しておきましょう。尚、私が考える試験対策としての重要度を各プロダクトごとに記載していますので、学習優先度の参考にしてみてください!
1. Storage Transfer Service(重要度:★★★★☆)
Storage Transfer Service は、外部ストレージ(Amazon S3、Azure Blob Storage、オンプレミスなど)から Cloud Storage へデータを転送するフルマネージドサービスです。以下の内容を押さえておきましょう。
サポートされているソースとシンク
サポートされているソース(転送元)とシンク(転送先)は以下の通りです。特に、Amazon S3 や Azure Blob Storage などの外部クラウドや、オンプレミスのファイルシステムから Cloud Storage またはファイルシステムへの転送が可能であることは押さえておきましょう。
サービス名 | ソース(転送元) | シンク(転送先) |
---|---|---|
Cloud Storage | ⚪︎ | ⚪︎ |
Amazon S3 | ⚪︎ | |
S3 互換ストレージ | ⚪︎ | |
Azure Blob Storage | ⚪︎ | |
一般公開または署名付きの HTTP および HTTPS URL | ⚪︎ | |
ファイルシステム | ⚪︎ | ⚪︎ |
Hadoop 分散ファイルシステム | ⚪︎ |
転送トリガー
データ転送のトリガーとして以下を指定することができます。
- スケジューリング転送: 定期的なスケジュールを設定して、自動的にデータを転送できます。日次、週次、月次、カスタム、オンデマンド(随時)から頻度を設定可能です。また、設定した転送構成を使用して、任意のタイミングで手動実行することも可能です。
- イベントドリブン転送: Amazon S3 または Cloud Storage から Cloud Storage へのイベントドリブン転送がサポートされています。この転送では、ソースバケット(Amazon S3 または Cloud Storage のバケット)にファイルが追加または更新されたタイミングで、自動的に Cloud Storage にファイルを転送することができます。
フィルタリング
接頭辞を使用して、データソースに含めるファイルまたは除外するファイルをフィルタリングできます。接頭辞として、包含接頭辞、除外接頭辞、またはその両方を使用できます。
例:
接頭辞の指定により対象のパスを指定します。(この例では、包含接頭辞と除外接頭辞の両方を指定しています。)
include: path_1/
exclude: path_1/subpath_1/
以下のようなパスがある場合、赤色部分のパスが除外されます。
- xx://bucketname/object_1
- xx://bucketname/object_2
xx://bucketname/path_1/object_3
- xx://bucketname/path_2/object_4
- xx://bucketname/path_1/subpath_1/object_5
xx://bucketname/path_1/subpath_2/object_6
- xx://bucketname/path_2/subpath_3/object_7
- xx://bucketname/path_2/subpath_4/object_8
また、包含接頭辞と除外接頭辞を使ったジョブ分割や並列実行による高速化、直列実行による API 制限回避が可能です。詳細は以下の公式ドキュメントをご参照ください。
転送オプション
転送の作成時に、以下の転送オプションを設定することができます。
-
上書き条件: ファイル転送における、以下の上書き条件を選択することができます。
- なし: シンクにソースファイルと同じ名前のファイルがすでに存在する場合、(ファイルの中身が異なっていても)ソースファイルの転送をスキップします。
- 異なる場合: シンクにソースファイルと同じ名前のファイルがすでに存在するが、ファイルの中身が異なる場合、シンクのファイルを上書きします。
- 常時: シンクにソースファイルと同じ名前のファイルがすでに存在する場合でも、シンクファイルを上書きします。
-
削除タイミング: ファイル転送後に、ファイル削除するかを選択できます。削除する場合は、削除タイミングを以下から選択できます。
- 転送後にファイルをソースから削除する
- ソースにはないファイルをシンクから削除する
- オブジェクトのメタデータ保持: データ転送時に、オブジェクトのメタデータ(ファイルサイズと最終更新日時など)を保持することができます。(尚、保持できるメタデータはソースによって異なります。)
詳細は以下の公式ドキュメントをご参照ください。
セキュリティ
転送中のデータは暗号化されており、転送先 Cloud Storage バケットの暗号化設定も適用できます。また、顧客管理の暗号鍵(CMEK)もサポートしています。
ベストプラクティス
Storage Transfer Service では、以下の公式ドキュメントにて、ファイルシステム転送におけるベストプラクティスが紹介されていますので、一度、目を通しておくと良いでしょう。
2. Transfer Appliance(重要度:★★☆☆☆)
Transfer Appliance は、Google Cloud への大規模なデータ移行をオフラインで行うための物理アプライアンスです。Google から下図のような物理的なハードウェアアプライアンスを借り受け、そこにデータをコピーし、そのアプライアンスを Google に返送することで、安全かつ効率的にデータを Cloud Storage にアップロードします。
出典: Transfer Appliance
Transfer Appliance は、以下のようなユースケースで使用します。
- ペタバイト(PB)規模のデータ移行
- ネットワーク帯域幅が限られた環境での数百 TB 規模のデータ移行
3. BigQuery Data Transfer Service(重要度:★★★★☆)
BigQuery Data Transfer Service は、様々なデータソースから BigQuery へのデータ転送を自動化するフルマネージドサービスです。以下の内容を押さえておくと良いでしょう。
多様なデータソースをサポート
サポートされているデータソースとして、Amazon S3 や Amazon Redshift、Azure Blob Storage、Cloud Storage、Google 広告など多様にあります。以下の公式ドキュメントに目を通して、どういったデータソースがあるかを把握しておきましょう。
転送トリガー
BigQuery Data Transfer Service では、転送トリガーとしてスケジューリング転送をサポートしています。事前にスケジュール(日次、週次、月次、カスタム頻度など)を設定し、それに基づいてデータを自動的に BigQuery に転送できます。また、設定した転送構成を使用して、任意のタイミングで手動実行することも可能です。
増分転送と切り捨て転送
Cloud Storage、Amazon S3、Azure Blob Storage などからの転送を設定する場合は、新しいデータの増分のみを転送する増分転送と、全データを転送する切り捨て転送がサポートされています。増分転送を使用することで、コストと時間を削減できます。
詳細は以下の公式ドキュメントをご参照ください。
バックフィル実行
過去のデータを取り込むバックフィル実行により、特定の過去の期間のデータを BigQuery に取り込むことができます。
実行通知
BigQuery Data Transfer Service の実行通知として、メール通知(転送失敗時)または Pub/Sub 通知(転送成功または失敗時)による実行通知が可能です。
4. Datastream(重要度:★★★☆☆)
Datastream は、サーバーレスの変更データキャプチャ(CDC)およびレプリケーション サービスです。以下の内容を押さえておくと良いでしょう。
変更データキャプチャとは
変更データキャプチャ(Change Data Capture、CDC)とは、データベースなどのデータソースで発生した変更点を検出し、その変更情報をキャプチャ(記録)する技術です。
キャプチャした変更情報を様々なシステムやツールに連携させることができ、例えば、データベースからデータウェアハウスに対してほぼリアルタイムでデータ同期が可能です。
サポートされているソースとシンク
Datastream でサポートされているソースとシンクは以下の通りです。
ソース
- MySQL
- Oracle Database
- PostgreSQL
- SQL Server
シンク
- BigQuery
- Cloud Storage
容易なセットアップと管理
Datastream は、サーバーレスかつシームレスなスケーリングを提供し、インフラストラクチャ管理を最小限に抑え、簡単な設定ですぐに始められます。そのため、「CDC アーキテクチャを最小コストで構築したい場合に最適なプロダクトは何か」と問われた場合、Datastream は最適な選択肢の一つになります。
イベント配信
Datastream における「イベント」とは、データソースで発生した変更を表す情報のことです。Datastream ではデータがこのイベント単位で処理され、ソースからのイベントの継続的な取り込みとシンクへの書き込みによる「イベント配信」が行われます。
このイベント配信には、「少なくとも 1 回(At Least Once)の配信保証」や「イベントサイズの制限」などの制約がありますので、以下の公式ドキュメントに目を通し、確認しておきましょう。
高可用性と障害復旧
Datastream は、リージョンレベルで高可用性を実現するように設計されています。Datastream のデータ処理は各リージョンの複数ゾーンで実行されており、もし特定のゾーンで障害が発生しても他のゾーンでサービスが継続されるため可用性に影響しません。
また、リージョンに障害が発生してサービスが停止した場合、そのリージョンで実行されている Datastream の処理は全て中断されます。サービス停止が解決した後、Datastream は中断したところから処理を再開します。また、処理の再開に伴い、データ転送先でのデータ重複が発生する可能性がありますが、前述のイベント配信により重複データ削除が可能です。
詳細は以下の公式ドキュメントをご参照ください。
Dataflow との統合
Datastream は、シンクに対して直接のデータ同期をサポートしていますが、シンクへのデータ格納前にデータを変換したり、論理主キー設定などが必要な場合は、Datastream と Dataflow を統合することで実現可能です。
出典: 分析のために Datastream と Dataflow を実装する
Datastream と Dataflow の統合における例として、上図のような構成があります。ここでは、Datastream にてデータベースの変更を検知し、その変更データを Cloud Storage に格納、Dataflow が Cloud Storage に格納されたデータを取得し、データ処理して、BigQuery へ格納します。
5. Database Migration Service(重要度:★★☆☆☆)
Database Migration Service は、データベースを Google Cloud にスムーズに移行できるサービスです。以下の内容を押さえておくと良いでしょう。
サポートされているソースとシンク
Database Migration Service でサポートされているソースとシンク(データベースの移行元から移行先)は以下の通りです。
同種のデータベース移行
- MySQL から Cloud SQL for MySQL
- PostgreSQL から Cloud SQL for PostgreSQL
- PostgreSQL から AlloyDB for PostgreSQL
- SQL Server から Cloud SQL for SQL Server
異種のデータベース移行
- Oracle から Cloud SQL for PostgreSQL
- Oracle から AlloyDB for PostgreSQL
リフト&シフト
Database Migration Service によって、オンプレミスや他のクラウド環境にある MySQL や PostgreSQL などのワークロードを、Google Cloud のマネージドデータベースサービスにそのまま移行でき、データベースの運用コストの削減やスケーラビリティの向上、高可用性の実現、他 Google Cloud サービスとのシームレスな連携が可能になります。
最小限のダウンタイム
継続的なデータレプリケーションを利用するため、移行中のダウンタイムを最小限に抑えることができ、ビジネスに影響を与えることなく移行を進めたい場合に有効です。
6. Pub/Sub(重要度:★★★★☆)
Pub/Sub は、フルマネージドのメッセージングサービスであり、個別のアプリケーション間でメッセージを送受信することが可能です。
また、下図のように Pub/Sub は Dataflow と組み合わせて、ストリーミングパイプラインを構築する際にもよく利用されます。(詳細はデータパイプライン編で解説します。)
Pub/Sub と Dataflow によるストリーミングパイプライン
構成要素
まずは、Pub/Sub の構成要素を押さえておきましょう。
出典: Pub/Sub サービスの概要
- メッセージ(message): 送り手(パブリッシャー)から受け手(サブスクライバー)に送信される通信データです。メッセージ形式として、JSON、テキスト、バイナリなど、任意の形式が使用可能です。
- スキーマ(Schema): メッセージの型定義であり、データの形式を定義します。
- パブリッシャー(Publisher): メッセージを特定のトピック(送信先チャネル)に送信する役割を持つアプリケーションまたはサービスです。
- トピック(Topic): パブリッシャーからのメッセージ送信先となるチャンネルです。
- サブスクリプション(Subscription): トピックに公開されたメッセージを受信し、サブスクライバーに送信するエンティティです。
- サブスクライバー(Subscriber): サブスクリプションを通じてメッセージを受信し、処理を行うアプリケーションまたはサービスです。
Pub/Sub の構成要素を理解した上で、以下の内容を押さえておきましょう。
Push と Pull
Push とは、サブスクリプションにメッセージが到達したら、そのまま自動的にサブスクライバーへメッセージを送信する方式です。メッセージをサブスクライバーに送りつけるイメージになります。
Pull とは、サブスクライバーがサブスクリプションにメッセージを取りに行く方式です。サブスクリプションに保持されたメッセージは、サブスクライバーが取得するまで、または設定された保持期間が過ぎるまで保持されます。サブスクライバーが能動的にメッセージを取得しに行くため、必要なタイミングでメッセージを受信することができます。
また Pull と Push ともに、メッセージをサブスクライバーが正常に受け取ったら、それを Pub/Sub に知らせるため、サブスクリプションに対して確認応答(Ack: Acknowledge) を行います。
Pull と Push の使い分けに関しては、以下の公式ドキュメントが参考になりますので、目を通しておくと良いでしょう。
メッセージの保持期間
Pub/Sub では、メッセージは送信後に一定期間保持されます。サブスクライバーがメッセージを受信し、確認応答すると、メッセージは削除されます。しかし、何らかの理由で確認応答されない場合、メッセージはこの保持期間が過ぎると自動的に削除されます。サブスクリプションで設定できるメッセージの保存期間は以下の通りです。
<サプスクリプションのメッセージ保持期間>
- デフォルトの保持期間: 7 日間
- 最小保持期間: 10 分
- 最大保持期間: 31 日間
また、トピックでは通常、トピックに関連付けられたサブスクリプションが確認応答された時点でメッセージを破棄しますが、メッセージ保持の設定を行うことで、確認応答後にトピックでのメッセージを最大 31 日間保持できます。
Exactly-Once 配信
Pub/Sub は、デフォルトで At Least Once(最低でも 1 回)配信を保証しています。しかし、メッセージが複数回行われてしまう場合もあるため、メッセージを正確に 1 回だけ配信することを保証したい場合は、Exactly-Once 配信を設定します。これにより、メッセージの重複処理による不整合を防ぐことができます。
指数バックオフでの再試行
指数バックオフとは、Pub/Sub がメッセージ配信に失敗するなどで再試行する場合、再試行の間隔を指数関数的に長くしながらメッセージを再送信する手法です。
指数関数的に長くするとは、例えば、初回の再試行は 1 秒後、2 回目の再試行は 2 秒後、3 回目の再試行は 4 秒後といった具合に、間隔が指数関数的に増加していくことを意味します。
この指数バックオフを利用することで、サブスクライバーが一時的な過負荷状態になっていても柔軟に対応でき、メッセージの配信成功率を高めることができます。
スナップショットとシーク
スナップショットは、ある時点におけるサブスクリプション内のメッセージの確認応答状態を保存する機能です。
シークとは、スナップショットを使用して、サブスクリプションを指定した時点に戻すための機能です。過去に遡ってシークし、確認応答済みのメッセージを再生することができます。尚、事前設定として、トピックのメッセージ保持するか、確認済みのメッセージを保持するようにサブスクリプションを構成する必要があります。
デッドレタートピック
デッドレタートピックは、Pub/Sub がメッセージ配信を試みても、サブスクライバーが確認応答できない場合に、配信不能メッセージをデッドレタートピックに転送することができます。後に原因を調査したい場合などで利用します。
メッセージの順序指定
Pub/Sub では、通常のメッセージ配信において順序の保証はありません。これは、Pub/Sub が水平スケーリングを前提としており、複数のサーバーやリージョンにまたがってメッセージを処理するためです。ただし、順序が重要なユースケースではメッセージの順序指定を使用することで、順序付けキーをもとにしたメッセージの順序を保証できます。
Apach Kafka からの移行
Apache Kafka と呼ばれる OSS のメッセージングサービスを Pub/Sub への移行することが可能です。移行することで、フルマネージドサービスによる運用負荷の軽減、グローバルな配信、低レイテンシを実現することができます。
ベストプラクティス
Pub/Sub については、以下の公式ドキュメントにて、パブリッシュやサブスクライブに関するベストプラクティスが紹介されていますので、目を通しておくと良いでしょう。
まとめ
今回の記事では、Professional Data Engineer 試験対策として、Google Cloud の主要なデータ取り込みプロダクトについて解説しました。それぞれのプロダクトの特徴、ユースケースなどこの記事で解説した内容をしっかりと理解し、試験に臨めると良いと思います。また、記載しているポイントに関連する公式ドキュメントも併せて参照することで、より深い理解が得られますので、ぜひ取り組んでみてください!
Discussion