広告におけるデータ パイプラインのインフラストラクチャ オプション(パート 2)

この記事では、さまざまな広告プラットフォームに共通するデータ パイプラインと機械学習のタスクに焦点を当てます。この記事は、広告ワークロードを処理するためのインフラストラクチャ オプション(パート 1)を補完するものです。この両方の記事で、シリーズに必要な背景情報を説明します。

この記事は、次のシリーズの一部です。

これらのプラットフォームがどのように連携しているかの概要と、このシリーズ全体で使用されている広告技術用語については、広告プラットフォームの構築(概要)をご覧ください。

データ パイプラインで使用されるデータストア(パート 1 で説明)には、(ユニーク)ユーザー プロフィール ストアコンテキスト ストア(パート 1 で説明)、レポート / ダッシュボード ストア(パート 1 で説明)があります。これらのデータストアへの主なデータ供給元は、イベントとサードパーティ データの 2 つです。この記事では、主にイベント管理を取り上げます。サードパーティのデータについて、およびそのデータを使用してユーザーデータをエンリッチする方法の詳細については、データをエンリッチする方法(パート 4 で説明)をご覧ください。

イベントのライフサイクル

生のイベントから有用なデータへのデータ パイプラインは、次の要素に分割できます。

  • 収集と保存(取り込み): メッセージング システムまたは繰り返しファイル アップロードを通してストレージ システムに渡します。
  • 処理: バッチで行うか、ストリーミング モードで行います。後者は、データの鮮度が重要なときにリアルタイムで処理するために使用します。
  • エクスポート(または読み込み): データ処理ツールから直接、またはカスタム ワークフローを通して行います。出力先は一般的に、前述のストアです。

広告技術における一般的なイベントは、次のものがあります。

  • 広告と入札のリクエスト: 一般的には外部システムから受け取ります。リクエストの中にある詳細情報が、広告選択の入力の一部となります。
  • インプレッション: クリエイティブがウェブページに読み込まれること。ただし、常に視認可能とは限りません。
  • 請求対象インプレッション: レンダリングされた、または視認可能なインプレッション。
  • クリック: クリエイティブをクリックすることによってユーザーが取ることのできるアクション。
  • コンバージョン: ターゲット ユーザーが広告主のウェブサイトで行うアクション。

リアルタイム入札に関連するイベントについては、RTB 入札者向けのインフラストラクチャ オプション(パート 4)で説明しています。

収集

イベントを作成するには、次の方法があります。

  • 広告または入札のリクエスト インスタンス: リクエストを受け取ったインスタンスは、クリエイティブの URL を返すか、入札レスポンスを返します。
  • コレクタ インスタンス: 不可視のピクセルを返すインスタンス。その目的は、インプレッションをログに記録することや、ターゲット ユーザーが広告に対して行ったアクション(クリックや動画再生などのアクション)を収集することです。
  • Stackdriver Logging: 場合によって、このロギングにおいてコレクタ インスタンスとサーバー ログファイルが置き換えられることがあります。

イベントを収集するには、次の方法があります。

  • カスタムコードを使用して、イベントをメッセージング システム(たとえば Cloud Pub/Sub)にパブリッシュするか、ローカルのログファイルに書き込む。
  • サードパーティ ツール、またはウェブサーバー上のネイティブのロギング機能を使用する。
  • 選択したサードパーティ ソフトウェアをサポートし Stackdriver Logging と統合される GCP Logging エージェントを使用する。

イベントを取り込むには、次の方法があります。

  • リアルタイムに近い状態で行うには、ログファイルをローカルで書き出してから、定期的に共有ストレージ(たとえば Cloud StorageBigQuery Capacitor)にコピーして処理します。BigQuery ストレージは一般的に、処理中に分析クエリが必要になる場合に使用されます。
  • リアルタイムで行うには、Stackdriver Logging を使用するか、コレクタから低レイテンシのデータストアまたはメッセージング システムに直接書き出します(たとえば Cloud Pub/SubApache KafkaRabbitMQ)。リアルタイム処理システムでは、よくこの方法が使用されます。

Stackdriver Logging を利用すると、これらのタスクの多くを簡単に実現できます。データを直接 GCP のプロダクトから、たとえば Compute Engine や Google Kubernetes Engine、さらには HTTP 負荷分散から取り込むことができるからです。また、データを直接 BigQuery にエクスポートしてその場で分析を行うことや、Cloud Pub/Sub にストリーミングしてアラートやリアルタイム処理目的に利用することや、バッチで Cloud Storage にエクスポートしてバックアップやフェデレーション分析を行うこともできます。

ここでは、いくつかの例を通して前述のポイントを説明するとともに、運用、コスト、データの鮮度を検討します。

オプション コスト 運用上のオーバーヘッド データの鮮度
ログファイルを Cloud Storage に X 秒間隔でコピーしてから、BigQuery に bq load を使用してコピーする Cloud Storage への上り方向のコストは発生しない

BigQuery への取り込みコストは発生しない

BigQuery のストレージ コスト
ファイル、失敗、再試行、同期の管理が必要 ほぼリアルタイム
ログファイルを Cloud Storage に X 秒間隔でコピーしてから、BigQuery に Cloud Functions を使用してコピーする Cloud Storage への上り方向のコストは発生しない

BigQuery への取り込みコストは発生しない

Cloud Functions に伴う追加コスト

BigQuery のストレージ コスト
Cloud Functions を利用すると負荷管理が容易になる。この場合もロジックのコーディングは必要です。 ほぼリアルタイム
Stackdriver Logging を Cloud Pub/Sub へのエクスポートとともに使用する Cloud Pub/Sub のコスト リアルタイム
ローカル デーモンを使用してログを Kafka にストリーミングする Kafka を実行するためのストレージとコンピューティングのコストが必要 Kafka のセットアップと管理(GCP マネージド オプションを使用する場合を除く) ほぼリアルタイム、ただし Kafka のセットアップ方法による

ヒント: イベントの収集にコンピューティング インスタンスを使用するときは、コスト節約のために常にプリエンプティブ VM の使用(コンピューティング プラットフォームのセクションで説明しています)を検討してください。

データの保存

データを保存する場所の決定に影響する要因としては、データの形式、データへのアクセスと使用の方法、データ保存のコストがあります。データ形式が非構造化の場合や、処理の前に保存する必要がある場合は、すでにおすすめした Cloud Storage の使用を検討してください。構造化データの場合は、レコードへのアクセスに必要な労力も考慮する必要があります。次の図は、オペレーションの数とコストを最小限に抑えるアクセス パターンを評価するときに役立ちます。

データのエクスポートに役立つ推奨事項

大量読み込みの保存パターン(パート 1)で、保存と配信に使用できる選択肢について説明しています。このセクションの残りの部分では、ストリーミングとバッチ処理の両方で使用される分析データストアを取り上げます。

ストリーミングでは、元データを処理してから保存します。データをすぐにクエリ処理に利用できるようにしたい場合は、BigQuery へのストリーミングを検討してください。このことを簡単に行うには、この Cloud Dataflow テンプレートを使用して Cloud Pub/Sub から BigQuery にストリーミングします。

繰り返しバッチ処理では、データを集約するために、スケーラブルな 1 つの共有環境に格納します。一般的なパターンの 1 つは、ログファイルを数分間隔でローカルの場所からオブジェクト ストレージに移動するというものです。多くの場合は、ファイル名に接頭辞と接尾辞が付けられます(例: logs_serverABC_timestamp123.txt)。

分析ワークロードを実行できるストレージ システムとしては、次のものがあります。

  • Cloud Storage: ストレージ クラス Standard、Nearline、または Coldline を使用してデータを保存すると、すばやくアクセス、バックアップ、アーカイブできます。標準ストレージ(分析用のおすすめオプション)を、可能であればリージョン バケットとしてセットアップします。ストレージをセットアップするリージョンは、そのデータを処理するコンピューティング リソースと同じリージョンにしてください。Cloud Storage には、Cloud DataprocCloud DataflowCloud Dataprep by Trifacta、BigQuery など、ほとんどの GCP プロダクトからアクセスできます。
  • BigQuery: BigQuery は強力なクエリエンジンであることに加え、専用のストレージ(Capacitor)があります。Capacitor を利用すると、エクサバイト規模のデータを格納でき、BigQuery のストレージに Cloud Dataproc、Cloud Dataflow、BigQuery クエリエンジンからアクセスできるようになります。BigQuery の長期保存を利用すると、90 日間編集されないパーティションのストレージ コストを約 50% 削減できます。
  • Cloud Bigtable: 毎日収集されるイベント数が億単位で、大量の書き込みと読み取りの両方を数ミリ秒で行う必要がある場合は、Cloud Bigtable が適しています。このストレージには HBase API や他のクライアントからアクセスできます。Cloud Bigtable は、ビッグデータ エコシステムとともにグラフ、時系列、分析に使用することもできます。

一般的な推奨事項は次のとおりです。

  • 元データを BigQuery に格納する処理は、他の処理と並行して行います。ここからロールアップを時間、日、週、または月単位で簡単に行うことができます。どの方法で読み込むかは、要件によって異なります。詳細については、BigQuery のデータ読み込みのドキュメントをご覧ください。
  • コストを抑えたい場合は、Cloud Storage に格納されたデータを BigQuery に読み込むと料金が発生しません。bq loadCloud Functions、ジョブ API、またはフェデレーション クエリを使用するときに発生する料金も、ストリーミングよりは低額です。最初の 2 つの方法は割り当ての対象です。
  • BigQuery のストレージ機能(たとえばパーティションクラスタリング)を使用してクエリの時間とコストを最小限に抑えます。

イベントの処理

処理パイプラインを構築する技術を選択する際は、次の点を考慮してください。

  • レイテンシ: どのデータをリアルタイムで処理する必要があるかを決定します。できるだけ早く計算する必要があるものとしては、たとえば予算関連のカウンタがあります。
  • 精度: 値によっては、正確に計算する必要があるものの、即時でなくてもよいものがあります。例としては、請求金額がこれに当たります。
  • 高可用性: 毎日何十億件ものデータ入力があるときは、数分のダウンタイムがかなりの金銭的影響をもたらす可能性があります。
  • 運用上のオーバーヘッド: 「常に明かりをつけておく」ことが、技術リソースの最善の使い方ではないこともあります。

次に例を示します。

  • HTTP 負荷分散ログの取り込みは、Stackdriver Logging を使用してリアルタイムで行います。
  • 一部のログは、即座に処理する必要があります。これは、残りの予算を計算するためです。
  • インプレッション数は 1 時間単位で集計する必要があります。キャンペーン フリークエンシー キャップは日単位です。

データ処理パイプラインでは、次の 2 つのバランスを取るためにラムダ アーキテクチャを採用するのが一般的です。

  • 高速近似: リアルタイム処理パイプラインを使用します。
  • 正確性: 追加のオフライン バッチ処理パイプラインを使用します。

Lambda データ処理パイプライン

このセクションでは、ラムダとカッパの両方のデータ処理アーキテクチャを実装するために利用できる GCP プロダクトのいくつかと、Cloud Dataflow について説明します。

  • Cloud Dataproc(バッチとストリーム): すでに Hadoop または Spark のジョブやスクリプトがある場合は、そのまま Cloud Dataproc、GCP マネージド Spark、または Hadoop に移行できます。
  • Cloud Dataflow(バッチとストリーム): 新しいワークロードがある場合や、高度なストリーミング機能の使用を検討している場合、または統一モデル プログラミング モデルを必要としている場合は、Cloud Dataflow を利用するとフルマネージド サービスで Apache Beam(Google がオープンソース化)を実行できます。Cloud Dataflow は多数の入力と出力もサポートしており、これには Cloud Pub/Sub や Kafka も含まれています。Cloud Dataflow では、1 つの統一プログラミング モデルでストリーミングとバッチの両方のデータに対応でき、「正確に 1 回」の処理がサポートされます。
  • BigQuery(バッチ): ELT(抽出、読み込み、変換)アプローチを検討しているときや、データ ウェアハウスへのデータの読み込みの後に変換を行うときは、BigQuery を使用して SQL 変換を行うことができます。このプロダクトはマネージド型であり、ユーザー定義関数も利用できます。このクエリのオーケストレーションには、Cloud Composer(マネージドの Apache Airflow)を検討してください。
  • サードパーティのツール: Hadoop エコシステムからのツールや Storm などのツールを Compute Engine や Google Kubernetes Engine(GKE)上にインストールして管理できます。

次に示すアーキテクチャは、これらの要件に基づく推奨案です。

  • イベントをリアルタイムで取り込む。
  • 一部のカウンタを 1 秒間隔で計算する。
  • インプレッションのロールアップを 1 時間間隔で行う。
  • 広告のクリック率を日単位で計算する。

Cloud Pub/Sub を使用するデータ処理パイプライン

データ処理の流れは次のとおりです。

  1. イベントが Cloud Pub/Sub に書き込まれます。
  2. Cloud Dataflow がイベントレベルのデータを直接 BigQuery に書き込みます。
  3. また、Cloud Dataflow はデータの枠を 1 秒間に設定して必要な集計を行い、カウンタをそのリージョンの Cloud Bigtable インスタンスに書き出します。
  4. BigQuery がクエリを繰り返し実行してデータをロールアップし、結果を実体化します。これをスケジュールに従って行うには、cron ジョブを使用するか、Apache Airflow のスケジューリング オプションを Cloud Composer を介して使用します。
  5. ユーザー フロントエンドでは BigQuery を OLAP データベースとして使用できます。詳細については、レポート(パート 1)をご覧ください。
  6. リージョンの広告サーバーが、近くの Cloud Bigtable インスタンスに問い合わせてすばやくカウンタを取得します。

データ処理パイプラインを構築するときの一般的な推奨事項を次に示します。

  • Cloud Pub/Sub を使用して運用上のオーバーヘッドを最小限に抑えます。または、Apache Kafka をマネージド サービスとして GCP 上で実行することを検討します。
  • パイプラインのプログラミングには Apache Beam の使用を検討します。バッチとストリームの両方に 1 つの統一プログラミング モデルで対応するためです。
  • Apache Beam を Cloud Dataflow 上で実行してフルマネージド サービスの利点を活用します。具体的には、ジョブのライフタイム全体を通してワーカーの数を自動スケーリングできることと、動的作業再調整によってジョブの全体的な処理時間を短縮できることです。

イベントやその他のデータを視覚的に探索してクリーニングし、分析用に準備するには、Cloud Dataprep の使用を検討してください。コードを書く必要はなく、Cloud Dataprep には Cloud Dataflow テンプレートをエクスポートする機能があるので、これを再利用してスケジュールできます。

エクスポート

イベントの取り込みと処理が完了すると、結果を次の場所にエクスポートできるようになります。

  • オフライン ストア(BigQuery、Cloud Storage など)。ロールアップや分析などのオフライン処理に使用します。
  • 配信ストア(Cloud Bigtable、Cloud Datastore、Cloud Memorystore など)やサードパーティのストア。フロントエンド サーバーはこのようなストアを、ユーザー プロフィールに関する情報を取得する、広告が選択されたときにカウンタを更新するといった目的で使用します。
  • メッセージング システム(Cloud Pub/Sub、Kafka など)。データをさらにダウンストリームで処理する必要があるときや、アラートとして送信するとき(たとえば、予算を管理するとき)に使用します。

データ レプリケーションも、エクスポートのユースケースの 1 つです。たとえば、データをフロントエンド サーバーの近くに、あるいはサーバー上に置きたい場合は、次の 2 つの方法があります。

  • 実際に使用するテクノロジーでサポートされていれば、ネイティブ レプリケーション機能を使用できる可能性があります。テクノロジーの中には、Redis や Aerospike のように、リージョン内のレプリケーションをサポートしているものがあります。ただし、リージョン間のレプリケーションはより難しくなる可能性があります。
  • その他のテクノロジーではレプリケーションがサポートされていない可能性があります。その場合は、メッセージング システムを使用して実装し、処理機能を Compute Engine または Cloud Pub/Sub 上で実行するという方法が考えられます。

次の図に、いくつかのアプローチを示します。

GCP のストアを使用するデータ レプリケーションの構造

データはリアルタイムで Cloud Dataflow を使用して処理され、オフラインでは BigQuery が使用されます。その後に、次のことを行います。

  • Cloud Dataflow がデータを直接 Redis クラスタに書き込み(これには Apache Beam Redis IO を使用します)、このデータをローカル ワーカーにレプリケートします。
  • Cloud Dataflow がメッセージを Cloud Pub/Sub にパブリッシュします。このメッセージを読み取るサブスクライバーのプールは自動スケーリングされ、Compute Engine 上にデプロイされます。サブスクライバーはメッセージを Aerospike クラスタに書き込みます。このクラスタは Compute Engine 上で実行されます。
  • BigQuery オフライン ジョブからのレコード(Cloud Composer を通してスケジュールされます)は、Redis と Aerospike のクラスタにエクスポートされます。

データをエクスポートするときは、次のことをおすすめします。

  • 実際に使用するデータストアが、読み取りと書き込みの両方のパターンを処理できることを確認します。そうでない場合は、読み取りインフラストラクチャの分離を検討してください。詳しい説明については、大量読み取りの保存パターン(パート 1)をご覧ください。
  • 分析を行うには、BigQuery をクラスタリングパーティショニングとともに使用してクエリのコストと所要時間を最小限に抑えます。
  • 数ミリ秒で読み取りと書き込みを行うには、Cloud Bigtable の使用を検討してください。可用性を高めるにはレプリケーションを有効にします。
  • リアルタイムで BigQuery への書き込みを行うには、Apache Beam BigQuery IO のデフォルトの Streaming API を使用します。Apache Beam Java SDK を使用すると、マイクロバッチでの書き込みを Cloud Storage を通して(FILE_LOADS を使用)行うことができるので、コストを削減できます。
  • 大量の書き込みを 1 ミリ秒未満で行う場合は、サードパーティのデータストアを Compute Engine または Cloud Pub/Sub 上にインストールして使用することを検討してください。

自動化

データ パイプラインでは、次のような目的でオフライン フローが必要になることがあります。

  • 高速 OLAP ダッシュボードのために、BigQuery ロールアップ データを別のストアにコピーします。
  • 配信データ(たとえば更新された顧客セグメント)を Redis、Aerospike、または Cloud Bigtable にコピーします。
  • データをデータセンター間でレプリケートします。
  • メタデータ データをユーザー フロントエンド データベース(パート 1)から、大量読み取りを処理できるストア(パート 1)にコピーします。

エンドツーエンドの自動化とエラー管理のために、Cloud Composer を Apache Airflow に使用することを検討してください。Airflow は、GCP 上のワークフローの管理のためにおすすめするオープンソース技術です。DAG は手動またはイベントによってトリガーすることも、スケジュールに従って繰り返し実行することもできます。

より単純なイベント駆動アクションが必要な場合は、Cloud Storage 上に作成された新しいファイルに対して、または Cloud Pub/Sub にパブリッシュされた新しいイベントに対して Cloud Functions をトリガーします。Cloud Functions はフルマネージドであるため、運用上のオーバーヘッドが排除されます。サーバーレスでさらにカスタマイズを行う場合は、Knative を検討してください。これは Kubernetes ベースの新しいアドオンであり、サーバーレス ワークロードの構築、デプロイ、管理を行うことができます。

分析

分析処理とアドホック クエリのためのデータ ウェアハウスとして BigQuery をおすすめします。その理由は次のとおりです。

  • フルマネージドです。
  • 最適化されたストレージ レイヤを持つ、スケーラブルなクエリエンジンです。
  • テラバイト規模のデータに対するアドホック クエリを、標準 SQL を使用して実行できます(これにはウィンドウ関数UDF も含まれます)。
  • クエリに使用する場合の料金オプションとしてオンデマンド定額があります。
  • 長期保存の場合の料金オプションとして長期料金が設定されています。
  • 機械学習機能が BigQuery ML として用意されています。
  • モニタリングコスト管理が統合されています。

ヒント:

BigQuery の承認済みビューの使用を検討してください。承認済みビューを利用すると、クエリ結果を共有するときに、使用されるテーブルへのアクセス権を与える必要がありません。また、どの列にユーザーがクエリを実行できるかを制限できます。

Hive からの移行に関心がある場合は、Parquet ファイルを BigQuery に読み込むことを検討してください。

分析と SQL ベースのオフライン処理には BigQuery の使用をおすすめしていますが、GCP には他にも次のような選択肢があります。

  • Hadoop ワークロード(Apache Spark、Hive、Pig など)については、Cloud Dataproc を検討してください。Cloud Dataproc コネクタを使用すると、Apache Spark や Hadoop のジョブを Cloud Storage に対して実行でき、多数の利点があります。たとえば、高いデータ可用性、他の GCP サービスとの相互運用性、HDFS との適合性です。
  • サードパーティのツールを Compute Engine または Cloud Pub/Sub 上にインストールして管理できます。 BigQuery に加えて Druid がフロントエンド ユーザー用の低レイテンシの OLAP データベースとして一般的に使用されています。

機械学習能力の構築

イベントの処理は、クリーニングと集約だけではありません。機械学習能力をデータ パイプラインに追加すると、インテリジェンスを追加できます。たとえば、より良い広告をレコメンドすることや、仮想ユーザー セグメントを作成してモデル特徴として使用することができます。GCP には、次のように多様な機械学習 AI ビルディング ブロックがあります。

毎日何十億件ものイベントが収集されてデータレイクやウェアハウス(Cloud Storage や BigQuery など)に保存される場合に、このデータを使用して、次のような入札に関連する強力なモデルをトレーニングすることができます。

  • 入札するかどうかを決定します。
  • クリック率を見積もります。
  • 入札価格を最適化します。
  • 顧客をセグメント化します。
  • 顧客ライフタイム バリュー(LTV)を計算します。
  • 選択されそうな広告をレコメンドします。

機械学習プラットフォームを選択するときは、次のような質問に答える必要があります。

  • 自分のデータをどれくらいよく理解しているか
  • データの量はどれくらいあるか
  • どれくらいの量のデータをトレーニングに使用するか
  • トレーニングはオンラインかオフラインか
  • 予測はオンラインとオフラインのどちらで行うか
  • サービングは予測とは独立して行うことができるか

次の図は、一般的な機械学習フローを示しています。このフローには、次のステップがあります。

  1. BigQuery でデータセットをクリーニングし、準備します。
  2. トレーニングと評価のデータセットを Cloud Storage にエクスポートします。
  3. Cloud Machine Learning Engine を使用してモデルをトレーニングします。
  4. モデルを Cloud Storage にエクスポートします。
  5. ワーカーが初期化されたら、モデルを Cloud Storage からインポートします。
  6. Tensorflow モデルをローカルで使用して予測を低レイテンシで実行します。

一般的な機械学習フロー

データと特徴エンジニアリングの準備

データを機械学習モデルに供給できる状態にするには、次のタスクを行います。

  1. データセットを探索します。これはデータが、実行したいタスクに適合しているかどうかを理解するためです。
  2. データセットをクリーニングして準備します。具体的には、複数のテーブルのデータを結合し、適用外のレコードを除外します。
  3. 特徴を抽出し、構成し、選択します。これで観察対象に関して、有益な識別特性が作成されます。

BigQuery は、このようなタスクを BigQuery に格納されたデータに対して、または外部のフェデレーション データソースに対して実行するのに適しています。BigQuery を使用してデータのクエリを実行し、探索してから、フィルタリングして選出したデータセットを Cloud Storage にエクスポートして特徴エンジニアリングを行うことができます。

ヒント: BigQuery をデータ探索に使用するだけでなく、Cloud Dataprep を BigQuery に接続してデータのサンプルやビジュアル プロファイルを作成できます。

次に行うのは一般的に、予測をオンラインとオフラインのどちらで行うかを検討することです。オンライン予測を行うときは、特徴がどのように予測のリクエスト データから抽出されるかを検討することが重要です。

  • オンライン予測の場合は、スキューを防止するために、同じ特徴作成ステップをトレーニングと予測で実行する必要があります。 tf.Transform を利用すると、これらの前処理ステップを定義し、Apache Beam を活用してこの作業をトレーニングおよび評価過程で大規模に行うことができます。また、これらのステップを Tensorflow グラフの一部としてエクスポートして予測処理を行うことができます。 このブログでは、このプロセスの仕組みを詳しく解説しています。
  • オフライン予測の場合は、同じアプローチをトレーニングと予測の両方のフェーズで使用できます。BigQuery を使用すれば、特徴をバッチ前処理の一部として作成することもできます。たとえば、ハッシュ関数を使用して特徴をベクトル化することや、結合を使用して対応する値をルックアップすることが考えられます。

トレーニングと評価

GCP には、モデルのトレーニングと評価を行う方法の選択肢として次のようにさまざまなものがあります。

  • Cloud Machine Learning Engine を使用して、XGboostScikit-Learn、Tensorflow のトレーニングと評価のタスクをフルマネージド環境で実行します。ML Engine には、自動化されたハイパー パラメータ チューニング分散トレーニングなどの機能もあります。

  • トレーニングと評価のタスクを Compute Engine インスタンス上で直接実行します。使用するソフトウェア パッケージをインストールする必要があります。GPUTPU、またはプリエンプティブ VM が効果を発揮する場面でこれらを活用すると、コストと処理時間を削減することもできます。

  • Kubeflow を使用して、Tensorflow や多数の機械学習ツール(たとえば Notebook)を Kubernetes 上のコンテナ化環境でインストールして実行します。

  • BigQuery ML を SQL インターフェースから直接使用して、構造化データのオフライン トレーニングを行います。

どの ML プラットフォームを選ぶかは、次のような要件によって決まります。

  • コストを最小限に抑えるには、Compute Engine をプリエンプティブ VM とともに使用します。
  • トレーニング、導入、およびサービス提供のためにフルマネージド環境が必要な場合は、Cloud ML Engine を使用してください。
  • 再現性のある、拡張 ML 環境を作成して任意の Kubernetes クラスタで実行できるようにするには、Kubeflow を使用します。
  • 構造化データがあるときは、予測をオフラインで行います。線形またはロジスティック回帰を実装したい場合は、BigQuery ML を使用します。

予測

予測はオフラインまたはオンラインで、トレーニングのセクションで説明したプロダクトと同じものを使用して行われます。Compute Engine、Kubeflow、Cloud ML Engine はいずれも、Tensorflow Serving を使用して予測を行えます。これらの選択肢の違いは、運用上のオーバーヘッド、チューニングのオプション、価格です。

低レイテンシが必須の要件である場合は、シリアル化またはコンパイルされたモデルを直接使用することもでき、これはデータ パイプラインでも役立ちます。次のステップに追加のリンクがあります。

サービング

予測とサービングは、同じタスクと考えられることもありますが、これが当てはまるのはオンライン予測の場合です。予測をオフラインで行ってからその結果をデータストアで永続化する場合は、予測が要求されたときにこのストアから予測をサーブする必要があります。

予測を高速でサーブすることは、有効性と効率とのトレードオフです。さまざまなアプローチがあり、そのいくつかを組み合わせることもできます。Tensorflow Serving を使用してリアルタイムで予測する場合は、GPU や TPU などのアクセラレータを使用することと、次のいずれかの方法を使用してモデルをサービング用に最適化することを検討してください。

  • tf.quantize で量子化します。
  • グラフの変数をフリーズして定数にします。
  • コードを書くとき、予測コードにトレーニングや評価の過程で生じるオーバーヘッド(たとえば余分なロギング)が含まれないようにコードを構造化します。
  • GPU を使用するときは、融合オペレーション(たとえば融合バッチ正規化)を検討してください。

作成済みの予測を高速 Key-Value ストアから使用する場合は、特徴の順列に基づいてキーを作成する必要があります。たとえば、入札するかどうかを大陸とデバイスタイプに基づいて予測するとします。

  1. 大陸名とモバイル / ウェブの、考えられる組み合わせをすべて作成します。
  2. これらの組み合わせに対応する予測の結果を保存します。

    キー 予測
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    これで、リクエストを受け取ったときに正しいキーの位置からすばやくフェッチすることができます。Redis、Aerospike、Cloud Bigtable はこのユースケースに適しています。

実装にあたっては、次の点に注意してください。

  • 多数の特徴がある場合は、組み合わせのサイズが、キー 1 個に対して許容される最大サイズを超える可能性があります。
  • 多数のリクエストと多数のキーをサポートするには、キー分散とキー(の一部)のハッシュ化を検討します(特定の行でのホットスポットを回避する必要がある場合)。Cloud Bigtable の Key Visualizer ツールは、このような問題の診断に役立ちます。
  • 連続値に対応するカテゴリデータがない場合は、バケット化する必要があります。特徴ごとにバケットサイズを決定すること自体がタスクの 1 つです。
  • キー間の距離を計算するために埋め込みを使用します。キーが存在しない場合は、最近傍値を探します。局所性鋭敏型ハッシュを作成する手法は、さまざまなものがあります。このようなハッシュを計算することは、機械学習のタスクの 1 つです。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...