このドキュメントは、教師あり学習タスクに焦点を当てて、機械学習 (ML) のためのデータ エンジニアリングと特徴エンジニアリングのトピックを探求する 2 部構成のシリーズの第 1 部です。この最初のパートでは、Google Cloud 上の ML パイプラインでデータを前処理するためのベスト プラクティスについて説明します。このドキュメントでは、TensorFlow とオープンソースのTensorFlow Transform ( tf.Transform ) ライブラリを使用して、データを準備し、モデルをトレーニングし、予測用にモデルを提供することに焦点を当てています。このドキュメントでは、ML 用のデータの前処理の課題に焦点を当て、Google Cloud でデータ変換を効果的に実行するためのオプションとシナリオについて説明します。
このドキュメントは、読者がBigQuery 、 Dataflow 、 Vertex AI 、および TensorFlow Keras API に精通していることを前提としています。
2 番目のドキュメント「 Google Cloud を使用した ML のデータ前処理」では、 tf.Transformパイプラインを実装する方法についてのステップバイステップのチュートリアルが提供されます。
導入
ML は、データ内の複雑で潜在的に有用なパターンを自動的に見つけるのに役立ちます。これらのパターンは ML モデルに凝縮されており、新しいデータ ポイントで使用できます。これは、予測の実行または推論の実行と呼ばれるプロセスです。
ML モデルの構築は複数のステップからなるプロセスです。各ステップには、独自の技術的および概念的な課題が存在します。この 2 部構成のシリーズは、教師あり学習タスクと、ターゲット変数に対する強力な予測シグナルを作成するためにソース データを選択、変換、および拡張するプロセスに焦点を当てています。これらの操作では、ドメインの知識とデータ サイエンスの技術が組み合わされます。この操作は特徴量エンジニアリングの本質です。
現実世界の ML モデルのトレーニング データセットのサイズは、簡単に 1 テラバイト (TB) 以上になることがあります。したがって、これらのデータセットを効率的かつ分散的に処理するには、大規模なデータ処理フレームワークが必要です。 ML モデルを使用して予測を行う場合は、トレーニング データに使用したのと同じ変換を新しいデータ ポイントに適用する必要があります。同じ変換を適用することで、モデルが期待する方法でライブ データセットを ML モデルに提示できます。
このドキュメントでは、特徴量エンジニアリング操作のさまざまな粒度レベル (インスタンス レベル、フルパス、およびタイム ウィンドウの集約) に関するこれらの課題について説明します。このドキュメントでは、Google Cloud で ML のデータ変換を実行するためのオプションとシナリオについても説明します。
このドキュメントでは、データ前処理パイプラインを通じてインスタンス レベルとフルパスのデータ変換の両方を定義できる TensorFlow のライブラリであるTensorFlow Transform ( tf.Transform ) の概要も提供します。これらのパイプラインはApache Beamで実行され、モデルの提供時と同じ変換を予測中に適用できるようにするアーティファクトを作成します。
ML 用のデータの前処理
このセクションでは、データの前処理操作とデータ準備の段階について紹介します。また、前処理操作の種類とその粒度についても説明します。
データ エンジニアリングと特徴量エンジニアリングの比較
ML 用のデータの前処理には、データ エンジニアリングと特徴エンジニアリングの両方が含まれます。データ エンジニアリングは、生のデータを準備されたデータに変換するプロセスです。次に、特徴エンジニアリングにより、準備されたデータが調整されて、ML モデルで期待される特徴が作成されます。これらの用語には次の意味があります。
- 生データ(または単なるデータ)
- ML 用の事前準備を行わない、ソース形式のデータ。このコンテキストでは、データは生の形式 (データ レイク内) または変換された形式 (データ ウェアハウス内) である可能性があります。データ ウェアハウス内にある変換されたデータは、分析に使用するために元の生の形式から変換されている可能性があります。ただし、この文脈では、生データは、データが ML タスク専用に準備されていないことを意味します。データが、最終的に予測のために ML モデルを呼び出すストリーミング システムから送信された場合も、生データとみなされます。
- 用意したデータ
- ML タスクの準備が整った形式のデータセット: データ ソースが解析され、結合され、表形式に変換されています。準備されたデータは適切な粒度で集約され、要約されます。たとえば、データセットの各行は一意の顧客を表し、各列は過去 6 週間の支出合計など、顧客の概要情報を表します。準備されたデータ テーブルでは、無関係な列が削除され、無効なレコードがフィルターで除外されています。教師あり学習タスクの場合、ターゲット特徴が存在します。
- 設計された機能
- モデルで期待される調整された特徴を含むデータセット。つまり、後で説明するように、準備されたデータセット内の列に対して特定の ML 固有の操作を実行し、トレーニングと予測中にモデルの新しい特徴を作成することによって作成される特徴です。前処理操作で。これらの操作の例には、数値列を 0 ～ 1 の間の値にスケーリングすること、値をクリッピングすること、およびカテゴリ特徴量のワンホット エンコーディングが含まれます。
次の図 (図 1) は、前処理されたデータの準備に含まれる手順を示しています。
実際には、同じソースからのデータが異なる準備段階にあることがよくあります。たとえば、データ ウェアハウス内のテーブルのフィールドは、エンジニアリング機能として直接使用される場合があります。同時に、同じテーブル内の別のフィールドは、エンジニアリング フィーチャになる前に変換が必要になる場合があります。同様に、データ エンジニアリングと特徴エンジニアリングの操作を同じデータ前処理ステップで組み合わせることができます。
前処理操作
データの前処理にはいくつかの操作が含まれます。各操作は、ML がより優れた予測モデルを構築できるように設計されています。これらの前処理操作の詳細はこのドキュメントの範囲外ですが、このセクションではいくつかの操作について簡単に説明します。
構造化データの場合、データ前処理操作には次のものが含まれます。
- データ クレンジング:破損した値または無効な値を持つレコードを生データから削除または修正し、多数の列が欠落しているレコードを削除します。
- インスタンスの選択と分割:入力データセットからデータ ポイントを選択して、トレーニング、評価 (検証)、およびテスト セットを作成します。このプロセスには、反復可能なランダム サンプリング、少数派クラスのオーバーサンプリング、層別分割などの手法が含まれます。
- 特徴量の調整: ML の特徴量の品質を改善します。これには、数値のスケーリングと正規化、欠損値の代入、外れ値のクリッピング、分布の偏った値の調整が含まれます。
- 特徴変換:数値特徴をカテゴリ特徴に変換 (バケット化を通じて)、およびカテゴリ特徴を数値表現に変換 (ワンホット エンコーディング、カウントによる学習、スパース特徴埋め込みなどを通じて)。一部のモデルは数値またはカテゴリの特徴でのみ機能しますが、他のモデルは混合タイプの特徴を処理できます。モデルが両方のタイプを処理する場合でも、同じ特徴の異なる表現 (数値とカテゴリ) から恩恵を受けることができます。
- 特徴抽出: PCA 、埋め込み抽出、ハッシュなどの手法を使用して、低次元のより強力なデータ表現を作成することにより、特徴の数を削減します。
- 特徴の選択:フィルターまたはラッパー メソッドを使用して、モデルをトレーニングするための入力特徴のサブセットを選択し、無関係または冗長なものを無視します。特徴の選択には、特徴に多数の値が欠落している場合に単純に特徴を削除することも含まれます。
- 特徴の構築:多項式展開(一変量数学関数を使用) や特徴交差(特徴の相互作用を捕捉するため) などの一般的な手法を使用して新しい特徴を作成します。 ML ユースケースのドメインのビジネス ロジックを使用して機能を構築することもできます。
非構造化データ (画像、音声、テキスト ドキュメントなど) を扱う場合、ディープ ラーニングはモデル アーキテクチャに組み込むことで、ドメイン知識ベースの特徴エンジニアリングを置き換えます。畳み込み層は、自動特徴プリプロセッサです。適切なモデル アーキテクチャを構築するには、データに関する経験的な知識が必要です。さらに、次のようなある程度の前処理が必要です。
- テキスト文書の場合:ステミングと見出し語化、 TF-IDF計算、 N グラム抽出、埋め込み検索。
- 画像の場合: クリッピング、サイズ変更、トリミング、ガウスぼかし、カナリア フィルター。
- すべてのタイプのデータ (テキストや画像を含む):転移学習。完全にトレーニングされたモデルの最後の層を除くすべての層を特徴量エンジニアリングのステップとして扱います。
前処理の粒度
このセクションでは、データ変換の種類の粒度について説明します。これは、トレーニング データに適用される変換を使用して予測用の新しいデータ ポイントを準備するときに、この観点が重要である理由を示しています。
前処理と変換の操作は、操作の粒度に基づいて次のように分類できます。
トレーニングおよび予測中のインスタンスレベルの変換。これらは単純な変換であり、変換には同じインスタンスの値のみが必要です。たとえば、インスタンス レベルの変換には、ある特徴の値を何らかのしきい値にクリップすること、別の特徴を多項式に拡張すること、2 つの特徴を乗算すること、または 2 つの特徴を比較してブール フラグを作成することが含まれる場合があります。
モデルは生の入力値ではなく、変換された特徴に基づいてトレーニングされるため、これらの変換はトレーニング中と予測中に同じように適用する必要があります。データが同一に変換されない場合、トレーニングされていない値の分布を持つデータがモデルに提示されるため、モデルの動作が低下します。詳細については、 「前処理の課題」セクションのトレーニングとサービングのスキューに関する説明を参照してください。
トレーニング中はフルパス変換ですが、予測中はインスタンス レベルの変換です。このシナリオでは、事前に計算された統計を使用して変換を実行するため、変換はステートフルです。トレーニング中に、トレーニング データ全体を分析して、トレーニング データ、評価データ、予測時の新しいデータを変換するための最小値、最大値、平均、分散などの量を計算します。
たとえば、トレーニング用に数値特徴を正規化するには、トレーニング データ全体にわたってその平均 (μ) と標準偏差 (σ) を計算します。この計算はフルパス(または分析) 操作と呼ばれます。予測用にモデルを提供する場合、トレーニングと提供のスキューを避けるために、新しいデータ ポイントの値が正規化されます。したがって、トレーニング中に計算される μ 値と σ 値は、次のような単純なインスタンス レベルの操作である特徴値の調整に使用されます。
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$フルパス変換には次のものが含まれます。
- MinMax はトレーニング データセットから計算された最小値と最大値を使用して数値特徴をスケーリングします。
- トレーニング データセットで計算された μ と σ を使用した標準スケーリング (Z スコア正規化) 数値特徴。
- 分位数を使用した数値特徴のバケット化。
- 中央値 (数値特徴) または最頻値 (カテゴリ特徴) を使用して欠損値を代入します。
- 入力カテゴリ特徴量のすべての個別の値 (語彙) を抽出することにより、文字列 (公称値) を整数 (インデックス) に変換します。
- すべての文書（インスタンス）内の用語（特徴量）の出現をカウントし、TF-IDF を計算します。
- 入力フィーチャの PCA を計算して、データを低次元空間に投影します (線形依存フィーチャを使用)。
μ、σ、 min 、 maxなどの統計量を計算するには、トレーニング データのみを使用する必要があります。これらの操作のテスト データと評価データを追加すると、モデルをトレーニングするために評価データとテスト データから情報が漏洩することになります。テストや評価結果の信頼性に影響します。すべてのデータセットに一貫した変換を確実に適用するには、トレーニング データから計算された同じ統計を使用して、テスト データと評価データを変換します。
トレーニングおよび予測中の履歴集計。これには、予測タスクへの入力信号としてビジネスの集計、派生、およびフラグを作成することが含まれます。たとえば、顧客が傾向モデルを構築するための最新性、頻度、金額 (RFM)メトリクスを作成します。これらのタイプの特徴は、事前計算して特徴ストアに保存し、モデルのトレーニング、バッチ スコアリング、およびオンライン予測の提供中に使用できます。トレーニングや予測の前に、これらの集計に対して追加の特徴エンジニアリング (変換や調整など) を実行することもできます。
トレーニング中は履歴集計ですが、予測中はリアルタイム集計です。このアプローチには、時間の経過に伴うリアルタイム値を要約することによって特徴を作成することが含まれます。このアプローチでは、集約されるインスタンスは時間ウィンドウ句を通じて定義されます。たとえば、過去 5 分間、過去 10 分間、過去 30 分間などのルートの交通メトリックに基づいてタクシーの移動時間を推定するモデルをトレーニングする場合、このアプローチを使用できます。間隔。このアプローチを使用して、過去 3 分間に計算された温度と振動の値の移動平均に基づいてエンジン部品の故障を予測することもできます。これらの集計はトレーニング用にオフラインで準備できますが、提供中にデータ ストリームからリアルタイムで計算されます。
より正確には、トレーニング データを準備するときに、集計された値が生データにない場合、その値はデータ エンジニアリング フェーズで作成されます。生データは通常、
(entity, timestamp, value)の形式でデータベースに保存されます。前の例では、entityはタクシー ルートのルート セグメント識別子、およびエンジン故障のエンジン部品識別子です。ウィンドウ操作を使用して(entity, time_index, aggregated_value_over_time_window)を計算し、モデル トレーニングの入力として集計機能を使用できます。リアルタイム (オンライン) 予測のモデルが提供される場合、モデルは入力として集計された値から導出される特徴を期待します。したがって、Apache Beam などのストリーム処理テクノロジを使用して、システムにストリーミングされたリアルタイム データ ポイントから集計を計算できます。ストリーム処理テクノロジーは、新しいデータ ポイントが到着すると、時間枠に基づいてリアルタイム データを集約します。トレーニングや予測の前に、これらの集計に対して追加の特徴エンジニアリング (変換や調整など) を実行することもできます。
Google Cloud 上の ML パイプライン
このセクションでは、マネージド サービスを使用して Google Cloud 上で TensorFlow ML モデルをトレーニングし、提供するための一般的なエンドツーエンド パイプラインのコア コンポーネントについて説明します。また、さまざまなカテゴリのデータ前処理操作を実装できる場所と、そのような変換を実装するときに直面する可能性のある一般的な課題についても説明します。 「tf.Transform の仕組み」セクションでは、TensorFlow Transform ライブラリがこれらの課題の解決にどのように役立つかを示します。
高レベルのアーキテクチャ
次の図 (図 2) は、TensorFlow モデルをトレーニングおよび提供するための典型的な ML パイプラインの高レベル アーキテクチャを示しています。図内のラベル A、B、および C は、データの前処理が行われるパイプライン内のさまざまな場所を指します。これらの手順の詳細については、次のセクションで説明します。
パイプラインは次のステップで構成されます。
- 未加工データがインポートされた後、表形式のデータは BigQuery に保存され、画像、音声、動画などのその他のデータは Cloud Storage に保存されます。このシリーズの第 2 部では、例として BigQuery に保存されている表形式のデータを使用します。
- データ エンジニアリング (準備) と特徴エンジニアリングは、Dataflow を使用して大規模に実行されます。この実行により、ML 対応のトレーニング、評価、テスト セットが生成され、Cloud Storage に保存されます。理想的には、これらのデータセットは、TensorFlow 計算に最適化された形式であるTFRecordファイルとして保存されます。
- TensorFlow モデルトレーナー パッケージは Vertex AI Training に送信され、前のステップで前処理されたデータを使用してモデルをトレーニングします。このステップの出力は、Cloud Storage にエクスポートされるトレーニング済みの TensorFlow SavedModelです。
- トレーニングされた TensorFlow モデルは、REST API を備えたサービスとして Vertex AI Prediction にデプロイされ、オンライン予測に使用できるようになります。同じモデルはバッチ予測ジョブにも使用できます。
- モデルが REST API としてデプロイされた後、クライアント アプリと内部システムは、いくつかのデータ ポイントを含むリクエストを送信し、予測を含むモデルからの応答を受信することにより、API を呼び出すことができます。
- このパイプラインをオーケストレーションおよび自動化するには、 Vertex AI Pipelines をスケジューラーとして使用し、データの準備、モデルのトレーニング、モデルのデプロイのステップを呼び出すことができます。
Vertex AI Feature Store を使用して、予測を行うための入力フィーチャを保存することもできます。たとえば、最新の生データからエンジニアリング フィーチャを定期的に作成し、Vertex AI Feature Store に保存できます。クライアント アプリは、必要な入力特徴を Vertex AI Feature Store から取得し、モデルに送信して予測を受け取ります。
前処理を行う場所
図 2 のラベル A、B、C は、データ前処理オペレーションが BigQuery、Dataflow、または TensorFlow で実行できることを示しています。次のセクションでは、これらの各オプションがどのように機能するかについて説明します。
オプション A: BigQuery
通常、ロジックは次の操作のために BigQuery に実装されます。
- サンプリング: データからサブセットをランダムに選択します。
- フィルタリング: 無関係または無効なインスタンスを削除します。
- パーティショニング: データを分割して、トレーニング、評価、およびテスト セットを作成します。
BigQuery SQL スクリプトは、Dataflow 前処理パイプラインのソース クエリとして使用できます。これは、図 2 のデータ処理ステップです。たとえば、システムがカナダで使用されており、データ ウェアハウスに世界中からのトランザクションがある場合、カナダのみのトレーニング データを取得するには、BigQuery を使用するのが最適です。 BigQuery の特徴エンジニアリングはシンプルかつスケーラブルで、インスタンス レベルおよび履歴集計の特徴変換の実装をサポートします。
ただし、モデルをバッチ予測 (スコアリング) に使用する場合、または特徴が BigQuery で事前計算されているが、オンライン予測中に使用するために Vertex AI Feature Store に保存されている場合にのみ、特徴エンジニアリングに BigQuery を使用することをお勧めします。オンライン予測用にモデルをデプロイする予定で、オンライン特徴ストアにエンジニアリングされた特徴がない場合は、SQL 前処理操作を複製して、他のシステムが生成する生データ ポイントを変換する必要があります。つまり、ロジックを 2 回実装する必要があります。1 回目は SQL で BigQuery のトレーニング データを前処理し、2 回目はモデルを使用するアプリのロジックで予測用のオンライン データポイントを前処理します。
たとえば、クライアント アプリが Java で記述されている場合は、ロジックを Java で再実装する必要があります。これにより、このドキュメントの後半の前処理の課題のトレーニングとサービングのスキューのセクションで説明されているように、実装の不一致によるエラーが発生する可能性があります。また、2 つの異なる実装を維持するための余分なオーバーヘッドも発生します。トレーニング データを前処理するために SQL のロジックを変更するときは常に、提供時にデータを前処理するように Java 実装を変更する必要があります。
モデルをバッチ予測のみに使用しており（たとえば、 Vertex AIバッチ予測を使用）、スコアリング用のデータが BigQuery から供給されている場合は、これらの前処理オペレーションを BigQuery SQL スクリプトの一部として実装できます。その場合、同じ前処理 SQL スクリプトを使用して、トレーニング データとスコアリング データの両方を準備できます。
フルパス ステートフル変換は、BigQuery での実装には適していません。フルパス変換に BigQuery を使用する場合は、数値特徴をスケーリングするための平均や分散など、ステートフル変換に必要な量を保存するための補助テーブルが必要です。さらに、BigQuery で SQL を使用したフルパス変換を実装すると、SQL スクリプトの複雑さが増し、トレーニングとスコアリング SQL スクリプトの間に複雑な依存関係が生じます。
オプション B: データフロー
図 2 に示すように、計算コストのかかる前処理操作を Apache Beam に実装し、Dataflow を使用して大規模に実行できます。 Dataflow は、バッチおよびストリーム データ処理のためのフルマネージド自動スケーリング サービスです。 Dataflow を使用する場合、BigQuery とは異なり、データ処理に外部の特殊なライブラリを使用することもできます。
Dataflow は、インスタンス レベルの変換、および履歴およびリアルタイムの集計機能の変換を実行できます。特に、ML モデルがtotal_number_of_clicks_last_90secのような入力特徴を予期している場合、Apache Beamウィンドウ関数は、リアルタイム (ストリーミング) イベント データ (クリック イベントなど) のタイム ウィンドウの値の集計に基づいてこれらの特徴を計算できます。変換の粒度に関する前述の説明では、これは「トレーニング中は履歴集計、予測中はリアルタイム集計」と呼ばれていました。
次の図 (図 3) は、ほぼリアルタイムの予測のためにストリーム データを処理する際の Dataflow の役割を示しています。
図 3 に示すように、処理中に、データ ポイントと呼ばれるイベントがPub/Subに取り込まれます。 Dataflow はこれらのデータ ポイントを消費し、長期にわたる集計に基づいて特徴を計算し、予測のためにデプロイされた ML モデル API を呼び出します。その後、予測は送信 Pub/Sub キューに送信されます。 Pub/Sub から、予測は監視や制御などの下流システムで使用することも、元の要求側クライアントに (通知などとして) プッシュバックすることもできます。予測は、リアルタイムで取得するためにCloud Bigtableのような低レイテンシのデータ ストアに保存することもできます。 Cloud Bigtable を使用して、これらのリアルタイム集計を蓄積して保存し、予測に必要なときに検索できるようにすることもできます。
同じ Apache Beam 実装を使用して、BigQuery などのオフライン データストアから取得したトレーニング データをバッチ処理したり、オンライン予測を提供するためにリアルタイム データをストリーム処理したりできます。
図 2 に示すアーキテクチャなど、他の一般的なアーキテクチャでは、クライアント アプリはオンライン予測のためにデプロイされたモデル API を直接呼び出します。その場合、トレーニング データを準備するために前処理オペレーションが Dataflow に実装されている場合、そのオペレーションはモデルに直接送信される予測データには適用されません。したがって、このような変換は、オンライン予測の提供中にモデルに統合する必要があります。
データフローを使用すると、必要な統計を大規模に計算することにより、フルパス変換を実行できます。ただし、これらの統計は、予測中に予測データ ポイントを変換するために使用できるようにどこかに保存する必要があります。 TensorFlow Transform ( tf.Transform ) ライブラリを使用すると、これらの統計を他の場所に保存するのではなく、モデルに直接埋め込むことができます。このアプローチについては、「 tf.Transform の仕組み 」で後述します。
オプション C: TensorFlow
図 2 に示すように、TensorFlow モデル自体にデータの前処理と変換操作を実装できます。図に示すように、TensorFlow モデルをトレーニングするために実装する前処理は、モデルが予測用にエクスポートおよびデプロイされるときに、モデルの不可欠な部分になります。 TensorFlow モデルの変換は、次のいずれかの方法で実行できます。
-
input_fn関数とserving_fn関数にインスタンス レベルの変換ロジックをすべて実装します。input_fn関数は、モデルをトレーニングするためにtf.data.DatasetAPIを使用してデータセットを準備します。serving_fn関数は、予測用のデータを受信して準備します。 - Keras 前処理レイヤーを使用するかカスタムレイヤーを作成することにより、変換コードを TensorFlow モデルに直接配置します。
serving_fn関数の変換ロジック コードは、オンライン予測用の SavedModel のサービス インターフェイスを定義します。トレーニング データの準備に使用したものと同じ変換を、 serving_fn関数の変換ロジック コードに実装すると、新しい予測データ ポイントが提供されるときに、同じ変換が確実に適用されます。
ただし、TensorFlow モデルは各データ ポイントを独立して処理するか、小さなバッチで処理するため、すべてのデータ ポイントから集計を計算することはできません。結果として、フルパス変換を TensorFlow モデルに実装することはできません。
前処理の課題
データ前処理の実装における主な課題は次のとおりです。
トレーニングとサービスのスキュー。トレーニングとサービングのスキューとは、トレーニング中とサービング中の有効性 (予測パフォーマンス) の差を指します。この偏りは、トレーニング パイプラインとサービス パイプラインでのデータの処理方法の不一致によって発生する可能性があります。たとえば、モデルが対数変換されたフィーチャでトレーニングされていても、提供中に生のフィーチャが表示される場合、予測出力は正確ではない可能性があります。
変換がモデル自体の一部になる場合は、オプション C: TensorFlowで前述したように、インスタンス レベルの変換を簡単に処理できます。その場合、モデル提供インターフェイス (
serving_fn関数) は生データを期待しますが、モデルは出力を計算する前にこのデータを内部的に変換します。変換は、生のトレーニングおよび予測データ ポイントに適用されたものと同じです。フルパス変換。 TensorFlow モデルでは、スケーリングや正規化変換などのフルパス変換を実装することはできません。フルパス変換では、 「オプション B: データフロー」で説明されているように、一部の統計 (たとえば、数値特徴をスケーリングするための
maxとmin値) をトレーニング データに対して事前に計算する必要があります。この値は、新しい生データ ポイントをインスタンス レベルの変換として変換するための予測のためのモデルの提供中に使用できる場所に保存する必要があります。これにより、トレーニングと提供のスキューが回避されます。 TensorFlow Transform (tf.Transform) ライブラリを使用して、統計を TensorFlow モデルに直接埋め込むことができます。このアプローチについては、「 tf.Transform の仕組み 」で後述します。トレーニングの効率を高めるために、事前にデータを準備します。インスタンスレベルの変換をモデルの一部として実装すると、トレーニング プロセスの効率が低下する可能性があります。この劣化は、各エポックで同じトレーニング データに同じ変換が繰り返し適用されるために発生します。 1,000 個の特徴を含む生のトレーニング データがあり、インスタンス レベルの変換を組み合わせて適用して 10,000 個の特徴を生成すると想像してください。これらの変換をモデルの一部として実装し、生のトレーニング データをモデルに供給すると、これらの 10,000 の操作が各インスタンスにN回適用されます ( Nはエポック数)。さらに、アクセラレータ (GPU または TPU) を使用している場合、CPU が変換を実行している間アクセラレータはアイドル状態になります。これは、高価なアクセラレータの効率的な使用法ではありません。
理想的には、オプション B: データフローで説明されている手法を使用して、トレーニング前にトレーニング データが変換されます。この手法では、10,000 の変換操作が各トレーニング インスタンスに 1 回だけ適用されます。次に、変換されたトレーニング データがモデルに提示されます。それ以上の変換は適用されず、アクセラレータは常にビジー状態になります。さらに、Dataflow を使用すると、フルマネージド サービスを使用して大量のデータを大規模に前処理することができます。
トレーニング データを事前に準備すると、トレーニングの効率が向上します。ただし、モデルの外部に変換ロジックを実装しても (オプション A: BigQueryまたはオプション B: Dataflowで説明されているアプローチ)、トレーニングとサービングのスキューの問題は解決されません。トレーニングと予測の両方に使用するためにエンジニアリングされた特徴を特徴ストアに保存しない限り、モデル インターフェイスは変換されたデータを想定しているため、予測のために来る新しいデータ ポイントに適用される変換ロジックをどこかに実装する必要があります。次のセクションで説明するように、TensorFlow Transform (
tf.Transform) ライブラリは、この問題の解決に役立ちます。
tf.Transform の仕組み
tf.Transformライブラリは、完全なパスを必要とする変換に役立ちます。 tf.Transformライブラリの出力は、インスタンス レベルの変換ロジックとフルパス変換から計算された統計を表す TensorFlow グラフとしてエクスポートされ、トレーニングとサービスに使用されます。トレーニングとサービスの両方に同じグラフを使用すると、両方の段階で同じ変換が適用されるため、スキューを防ぐことができます。さらに、 tf.Transformライブラリは、Dataflow 上のバッチ処理パイプラインで大規模に実行して、トレーニング データを事前に準備し、トレーニング効率を向上させることができます。
次の図 (図 4) は、 tf.Transformライブラリがトレーニングと予測のためにデータを前処理および変換する方法を示しています。このプロセスについては、次のセクションで説明します。
tf.Transformの動作。 トレーニングおよび評価データを変換する
tf.Transform Apache Beam API に実装された変換を使用して生のトレーニング データを前処理し、Dataflow 上で大規模に実行します。前処理は次のフェーズで行われます。
- 分析フェーズ:分析フェーズでは、ステートフル変換に必要な統計 (平均、分散、分位数など) がフルパス操作を使用してトレーニング データに対して計算されます。このフェーズでは、
transform_fnグラフを含む一連の変換アーティファクトが生成されます。transform_fnグラフは、インスタンス レベルの操作として変換ロジックを持つ TensorFlow グラフです。これには、分析フェーズで計算された統計が定数として含まれます。 - 変換フェーズ:変換フェーズでは、
transform_fnグラフが生のトレーニング データに適用され、計算された統計情報がインスタンス レベルの方法でデータ レコードを処理する (数値列のスケール変更など) ために使用されます。
このような 2 フェーズのアプローチは、フルパス変換を実行するという前処理の課題に対処します。
評価データが前処理されるときは、 transform_fnグラフのロジックとトレーニング データの分析フェーズから計算された統計を使用して、インスタンス レベルの操作のみが適用されます。つまり、評価データをフルパス方式で分析して、μ や σ などの新しい統計を計算して、評価データの数値特徴を正規化するわけではありません。代わりに、トレーニング データから計算された統計を使用して、インスタンス レベルの方法で評価データを変換します。
変換されたトレーニング データと評価データは、モデルのトレーニングに使用される前に、Dataflow を使用して大規模に準備されます。このバッチデータ準備プロセスは、トレーニング効率を改善するためにデータを前もって準備するという前処理の課題に対処します。図4に示すように、モデル内部インターフェイスは変換された機能を期待しています。
エクスポートされたモデルに変換を取り付けます
前述のように、 tf.Transformパイプラインによって生成されるtransform_fnグラフは、エクスポートされたTensorFlowグラフとして保存されます。エクスポートされたグラフは、インスタンスレベルの操作としての変換ロジックと、フルパス変換でグラフ定数として計算されたすべての統計で構成されています。訓練されたモデルがサービングのためにエクスポートされると、 transform_fnグラフは、そのserving_fn関数の一部としてsavedmodelに接続されます。
予測のためにモデルを提供している間、モデルサービングインターフェイスは、生形態のデータポイント（つまり、変換の前）を期待しています。ただし、モデル内部インターフェイスは、変換された形式のデータを期待しています。
現在、モデルの一部になっているtransform_fnグラフは、着信データポイントにすべての前処理ロジックを適用します。予測中にインスタンスレベルの操作で、保存された定数（μやσなどの数値の特徴を正規化する）を使用します。したがって、 transform_fnグラフは、生データポイントを変換された形式に変換します。図4に示すように、変換された形式は、予測を生成するためにモデル内部インターフェイスによって予想されるものです。
このメカニズムは、トレーニングと評価データを変換するために使用される同じロジック（実装）が予測中に新しいデータポイントを変換するために使用されるため、トレーニングを介したスキューの前処理課題を解決します。
前処理オプションの概要
次の表は、このドキュメントが説明したデータの前処理オプションをまとめたものです。テーブルでは、「n/a」は「該当なし」の略です。
| データプリプセッシングオプション | インスタンスレベル （ステートレス変換） | トレーニング中のフルパスとサービング中のインスタンスレベル（ステートフル変換） | トレーニングとサービング中のリアルタイム（ウィンドウ）集約（ストリーミング変換） |
|---|---|---|---|
BigQuery （SQL） | バッチスコアリング：OK - トレーニング中およびバッチスコアリング中のデータに同じ変換の実装が適用されます。 オンラインの予測：推奨されません- トレーニングデータを処理できますが、さまざまなツールを使用してデータを提供するため、トレーニングを提供するスキューが発生します。 | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 たとえばレベルのバッチ/オンライン変換のためにBigQueryを使用して計算された統計を使用できますが、トレーニング中に統計ストアを維持し、予測中に使用する必要はありません。 | バッチスコアリング：n/a -このような集合体は、リアルタイムイベントに基づいて計算されます。 オンラインの予測：推奨されません- トレーニングデータを処理できますが、さまざまなツールを使用してデータを提供するため、トレーニングを提供するスキューが発生します。 |
データフロー（Apacheビーム） | バッチスコアリング：OK - トレーニング中およびバッチスコアリング中のデータに同じ変換の実装が適用されます。 オンライン予測：OK - サービング時間のデータがPub/Subからデータフローによって消費される場合。それ以外の場合は、トレーニングを介したスキューになります。 | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 データフローを使用して計算された統計を使用して、例えばレベルのバッチ/オンライン変換を使用できますが、トレーニング中に統計ストアを維持し、予測中に使用する必要はありません。 | バッチスコアリング：n/a -このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：OK - 同じApacheビーム変換がトレーニング中（バッチ）およびサービング（ストリーム）中にデータに適用されます。 |
データフロー（Apacheビーム + TFT） | バッチスコアリング：OK - 同じ変換の実装がトレーニングとバッチスコアリング中にデータに適用されます。 オンラインの予測：推奨- トレーニングを介したスキューを回避し、トレーニングデータを前もって準備します。 | バッチスコアリング：推奨。 オンライン予測：推奨。 トレーニング中の変換ロジックと計算された統計は、サービングのためにエクスポートされたモデルに添付されたTensorflowグラフとして保存されるため、両方の用途が推奨されます。 | バッチスコアリング：n/a -このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：OK - 同じApacheビーム変換がトレーニング中（バッチ）およびサービング（ストリーム）中にデータに適用されます。 |
Tensorflow * | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 どちらの場合もトレーニング効率を得るには、トレーニングデータを前もって準備することをお勧めします。 | バッチスコアリング：不可能です。 オンライン予測：不可能です。 | バッチスコアリング：n/a -このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：不可能です。 |
* Tensorflowを使用すると、交差、埋め込み、1ホットのエンコードなどの変換をfeature_columns列として宣言的に実行する必要があります。
次は何ですか
tf.Transformパイプラインを実装してデータフローを使用して実行するには、このシリーズのパート2、 Tensorflow変換を使用してMLのデータ前処理を読みます。- Google CloudのTensorflowを使用して、MLでCourseraの専門化を行います。
- MLのルールにおけるMLエンジニアリングのベストプラクティスについて学びます。
- 参照アーキテクチャ、図、およびベストプラクティスについては、 TFXクラウドソリューションを調べてください。
このドキュメントは、監視された学習タスクに焦点を当てた、機械学習のためのデータエンジニアリングと機能エンジニアリングのトピックを探求する2部構成のシリーズの最初のものです。この最初の部分では、GoogleクラウドのMLパイプラインでの前処理データのベストプラクティスについて説明します。このドキュメントは、TensorflowとオープンソースのTensorflow変換（ tf.Transform ）ライブラリの使用に焦点を当てて、データを準備し、モデルを訓練し、予測のためにモデルを提供します。このドキュメントは、MLの前処理データの課題を強調し、Googleクラウドでデータ変換を効果的に実行するためのオプションとシナリオを説明します。
このドキュメントは、 BigQuery 、 Dataflow 、 Vertex AI 、およびTensorflow Keras APIに精通していることを前提としています。
Google Cloudを使用したML用の2番目のドキュメントの前処理は、 tf.Transformパイプラインを実装する方法に関する段階的なチュートリアルを提供します。
導入
MLは、データに複雑で潜在的に有用なパターンを自動的に見つけるのに役立ちます。これらのパターンは、新しいデータポイントで使用できるMLモデルで凝縮されています。これは、予測の作成または実行の実行と呼ばれるプロセスです。
MLモデルの構築は多段階プロセスです。各ステップは、独自の技術的および概念的な課題を提示します。この2部構成のシリーズは、監視された学習タスクと、ソースデータを選択、変換、および拡張して、ターゲット変数に強力な予測信号を作成するプロセスに焦点を当てています。これらの操作は、ドメインの知識とデータサイエンステクニックを組み合わせています。操作は機能エンジニアリングの本質です。
実際のMLモデルのトレーニングデータセットのサイズは、1テラバイト（TB）以上を簡単に等しくできます。したがって、これらのデータセットを効率的かつ分散的に処理するために、大規模なデータ処理フレームワークが必要です。 MLモデルを使用して予測を行う場合、新しいデータポイントのトレーニングデータに使用したのと同じ変換を適用する必要があります。同じ変換を適用することにより、モデルが期待する方法でライブデータセットをMLモデルに提示します。
このドキュメントでは、機能エンジニアリング操作のさまざまなレベルの粒度、インスタンスレベル、フルパス、およびタイムウィンドウ集約に関するこれらの課題について説明します。このドキュメントでは、Google CloudでMLのデータ変換を実行するオプションとシナリオについても説明しています。
このドキュメントは、 Tensorflow変換（ tf.Transform ）の概要も提供します。TensorFlowのライブラリであるTensorFlowのライブラリでは、データプリプレスパイプラインを介してインスタンスレベルとフルパスのデータ変換の両方を定義できます。これらのパイプラインはApacheビームで実行され、モデルが提供されるときと同じ変換を適用できるアーティファクトを作成します。
MLの前処理データ
このセクションでは、データの前処理操作とデータの準備の段階を紹介します。また、前処理操作の種類とその粒度についても説明します。
機能エンジニアリングと比較したデータエンジニアリング
MLのデータを前処理するには、データエンジニアリングと機能エンジニアリングの両方が含まれます。データエンジニアリングは、生データを準備したデータに変換するプロセスです。機能エンジニアリングは、準備されたデータを調整して、MLモデルで予想される機能を作成します。これらの用語には次の意味があります。
- 生データ（または単なるデータ）
- MLの事前の準備なしに、そのソース形式のデータ。これに関連して、データは生の形式（データ湖）または変換された形式（データウェアハウス）にある可能性があります。データウェアハウスにある変換されたデータは、分析に使用されるために元の生の形式から変換された可能性があります。ただし、これに関連して、生データは、データがMLタスク専用に作成されていないことを意味します。データは、予測のために最終的にMLモデルを呼び出すストリーミングシステムから送信される場合、生データと見なされます。
- 準備されたデータ
- MLタスクの準備ができているフォームのデータセット：データソースは解析され、結合され、表形式に配置されています。準備されたデータは集計され、右の粒度に合計されます。たとえば、データセットの各行は一意の顧客を表し、各列は過去6週間の合計と同様に顧客の要約情報を表します。準備されたデータテーブルでは、無関係な列が削除され、無効なレコードが除外されました。監視された学習タスクの場合、ターゲット機能が存在します。
- エンジニアリング機能
- モデルが予想される調整された機能を備えたデータセット、つまり、準備されたデータセットの列で特定のML固有の操作を実行し、トレーニングと予測中にモデルの新しい機能を作成することで作成された機能は、後で説明したように前処理操作。これらの操作の例には、数値列を0〜1の間の値にスケーリングすること、クリッピング値、 1ホットエンコードのカテゴリ機能が含まれます。
次の図、図1は、前処理されたデータの準備に伴う手順を示しています。
実際には、同じソースからのデータは、多くの場合、準備のさまざまな段階にあります。たとえば、データウェアハウスのテーブルからのフィールドは、エンジニアリング機能として直接使用される場合があります。同時に、同じテーブルの別のフィールドが、エンジニアリング機能になる前に変換を通過する必要がある場合があります。同様に、データエンジニアリングと機能エンジニアリングの操作は、同じデータ前処理ステップで組み合わせることができます。
前処理操作
データの前処理には、いくつかの操作が含まれます。各操作は、MLがより良い予測モデルを構築できるように設計されています。これらの前処理操作の詳細は、このドキュメントの範囲外ですが、一部の操作については、このセクションで簡単に説明します。
構造化されたデータの場合、データ前処理操作には以下が含まれます。
- データクレンジング： RAWデータから値が破損または無効なレコードの削除または修正、および多数の列が欠落しているレコードの削除。
- インスタンスの選択とパーティション化：入力データセットからデータポイントを選択して、トレーニング、評価（検証）、およびテストセットを作成します。このプロセスには、繰り返し可能なランダムサンプリング、少数派クラスオーバーサンプリング、および層別化されたパーティション化の手法が含まれます。
- 機能チューニング： MLの機能の品質の向上。これには、数値値のスケーリングと正規化、欠損値の帰属、外れ値の切り抜き、および分布を歪む値の調整が含まれます。
- 特徴変換：数値機能をカテゴリー機能に変換し（バケツ化を通じて）、カテゴリの特徴を数値表現に変換します（1ホットのエンコーディング、カウントでの学習、まばらな特徴の埋め込みなど）。一部のモデルは、数値またはカテゴリの特徴でのみ機能しますが、他のモデルは混合タイプの機能を処理できます。モデルが両方のタイプを処理する場合でも、同じ機能のさまざまな表現（数値とカテゴリー）の恩恵を受けることができます。
- 機能抽出： PCA 、埋め込み抽出、ハッシュなどの手法を使用して、より低い次元、より強力なデータ表現を作成することにより、機能の数を減らします。
- 機能の選択：モデルをトレーニングするための入力機能のサブセットを選択し、フィルターまたはラッパー方法を使用して、無関係または冗長なものを無視します。機能の選択には、機能に多数の値が欠落している場合、単に機能を削除することも含まれます。
- 機能構造：多項式の拡張（単変量数学機能を使用して）や機能の交差（機能の相互作用をキャプチャする）などの典型的な手法を使用して、新しい機能を作成します。 MLユースケースのドメインからのビジネスロジックを使用して、機能を構築することもできます。
非構造化データ（画像、オーディオ、テキストドキュメントなど）を使用すると、Deep Learningは、モデルアーキテクチャに折りたたむことでドメイン知識ベースの機能エンジニアリングを置き換えます。畳み込みレイヤーは、自動機能前処理器です。適切なモデルアーキテクチャを構築するには、データの経験的知識が必要です。さらに、以下のように、いくらかの量の前処理が必要です。
- テキストドキュメントの場合：ステム化とlemmatization 、 TF-IDF計算、およびn-Gram抽出、埋め込み検索。
- 画像の場合：クリッピング、サイズ変更、トリミング、ガウスブラー、カナリアフィルター。
- あらゆる種類のデータ（テキストと画像を含む）について：転送学習。完全に訓練されたモデルの全層を機能エンジニアリングステップとして扱います。
前処理粒度
このセクションでは、データ変換の種類の粒度について説明します。トレーニングデータに適用される変換を使用して、予測用の新しいデータポイントを準備する際に、この視点が重要である理由を示します。
操作の粒度に基づいて、前処理および変換操作は次のように分類できます。
トレーニングと予測中のインスタンスレベルの変換。これらは単純な変換であり、変換には同じインスタンスからの値のみが必要です。たとえば、インスタンスレベルの変換には、機能の値を何らかのしきい値にクリップすること、別の機能を多項に拡張する、2つの機能を掛けるか、2つの機能を比較してブールフラグを作成することが含まれます。
モデルは、生の入力値ではなく、変換された機能でトレーニングされるため、これらの変換はトレーニングと予測中に同じように適用する必要があります。データが同一に変換されない場合、モデルは、訓練されていない値の分布を持つデータが表示されるため、動作が不十分です。詳細については、トレーニング前のスキューの議論を前処理の課題セクションで参照してください。
トレーニング中のフルパス変換ですが、予測中のインスタンスレベルの変換。このシナリオでは、変換を実行するためにいくつかの事前計算された統計を使用しているため、変換はステートフルです。トレーニング中に、トレーニングデータの全身を分析して、トレーニングデータ、評価データ、および予測時間での新しいデータの変換のための最小、最大、平均、差異などの数量を計算します。
たとえば、トレーニングの数値機能を正規化するために、トレーニングデータ全体にわたって平均（μ）と標準偏差（σ）を計算します。この計算は、フルパス（または分析）操作と呼ばれます。予測のためにモデルを提供する場合、新しいデータポイントの値は正規化されて、トレーニングを介してスキューを避けます。したがって、トレーニング中に計算されるμおよびσ値は、機能値を調整するために使用されます。これは、次の単純なインスタンスレベルの操作です。
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$フルパス変換には以下が含まれます。
- minmaxは、トレーニングデータセットから計算されたminとmaxを使用して数値機能をスケーリングします。
- 標準スケーリング（Zスコア正規化）トレーニングデータセットで計算されたμおよびσを使用した数値機能。
- 分位を使用した数値機能をバケツ化します。
- 中央値（数値機能）またはモード（カテゴリ機能）を使用して欠損値を帰属させます。
- 入力カテゴリ機能のすべての異なる値（語彙）を抽出することにより、文字列（名目値）を整数（インデックス）に変換します。
- すべてのドキュメント（インスタンス）での用語（機能値）の発生をカウントして、TF-IDFを計算します。
- 入力機能のPCAを計算して、データをより低い次元空間に投影します（線形に依存する機能を使用）。
トレーニングデータのみを使用して、μ、σ、 min 、 maxなどの統計を計算する必要があります。これらの操作のテストと評価データを追加すると、評価データとテストデータから情報を漏らしてモデルをトレーニングします。そうすることは、テストと評価の結果の信頼性に影響します。すべてのデータセットに一貫した変換を適用するために、トレーニングデータから計算された同じ統計を使用して、テストと評価データを変換します。
トレーニングと予測中の歴史的集約。これには、予測タスクへの入力信号としてビジネス集約、派生、フラグを作成することが含まれます。たとえば、顧客が傾向モデルを構築するための最新性、頻度、および金銭（RFM）メトリックを作成します。これらのタイプの機能は、モデルトレーニング、バッチスコアリング、およびオンライン予測中に使用される機能ストアに事前計算および保存できます。トレーニングと予測の前に、これらの集計に追加の機能エンジニアリング（たとえば、変換やチューニング）を実行することもできます。
トレーニング中の歴史的集約ですが、予測中のリアルタイム集計。このアプローチでは、時間の経過とともにリアルタイムの値を要約することにより、機能を作成することが含まれます。このアプローチでは、集約されるインスタンスは、時間窓節を介して定義されます。たとえば、過去5分間、過去10分間、最後の30分間、およびその他で、ルートのトラフィックメトリックに基づいてタクシー旅行時間を推定するモデルをトレーニングする場合は、このアプローチを使用できます。間隔。また、このアプローチを使用して、過去3分間に計算された温度と振動値の移動平均に基づいて、エンジン部品の故障を予測することもできます。これらの集計はトレーニングのためにオフラインで準備できますが、サービング中にデータストリームからリアルタイムで計算されます。
より正確には、トレーニングデータを準備するとき、集計値が生データに含まれていない場合、値はデータエンジニアリングフェーズ中に作成されます。生データは通常、
(entity, timestamp, value)の形式を持つデータベースに保存されます。以前の例では、entityはタクシールートのルートセグメント識別子であり、エンジン障害のエンジン部品識別子です。 Windowing操作を使用して(entity, time_index, aggregated_value_over_time_window)計算し、モデルトレーニングの入力として集約機能を使用できます。リアルタイム（オンライン）予測のモデルが提供されると、モデルは集約値から入力として派生した機能を期待します。したがって、Apache Beamなどのストリーム処理テクノロジーを使用して、システムにストリーミングされたリアルタイムデータポイントから集約を計算できます。ストリーム処理テクノロジーは、新しいデータポイントが到着したときにタイムウィンドウに基づいてリアルタイムデータを集約します。トレーニングと予測の前に、これらの集計に追加の機能エンジニアリング（たとえば、変換やチューニング）を実行することもできます。
GoogleクラウドのMLパイプライン
このセクションでは、マネージドサービスを使用してGoogleクラウドでTensorflow MLモデルを訓練および提供するための典型的なエンドツーエンドパイプラインのコアコンポーネントについて説明します。また、データの前処理操作のさまざまなカテゴリを実装できる場所と、そのような変換を実装するときに直面する可能性のある一般的な課題についても説明します。 TF.Transform Worksセクションのセクションは、TensorFlow Transform Libraryがこれらの課題にどのように役立つかを示しています。
高レベルのアーキテクチャ
次の図、図2は、Tensorflowモデルのトレーニングと提供のための典型的なMLパイプラインの高レベルアーキテクチャを示しています。図のラベルA、B、およびCは、データの前処理が行われるパイプラインのさまざまな場所を指します。これらの手順の詳細については、次のセクションに記載されています。
パイプラインは次の手順で構成されています。
- 生データがインポートされた後、表形式データはBigQueryに保存され、画像、オーディオ、ビデオなどの他のデータはクラウドストレージに保存されます。このシリーズの第2部では、例としてBigQueryに保存されている表形式データを使用しています。
- データエンジニアリング（準備）と機能エンジニアリングは、データフローを使用して大規模に実行されます。この実行により、クラウドストレージに保存されているML対応トレーニング、評価、およびテストセットが生成されます。理想的には、これらのデータセットはTfrecordファイルとして保存されます。これは、Tensorflow計算のための最適化された形式です。
- Tensorflowモデルトレーナーパッケージは、頂点AIトレーニングに提出されます。これは、モデルをトレーニングするために前の手順から前処理されたデータを使用します。このステップの出力は、クラウドストレージにエクスポートされる訓練されたTensorflow SavedModelです。
- 訓練されたTensorflowモデルは、REST APIを備えたサービスとして頂点AI予測に展開され、オンライン予測に使用できるようにします。同じモデルをバッチ予測ジョブにも使用できます。
- モデルがREST APIとして展開された後、クライアントアプリと内部システムは、いくつかのデータポイントを使用してリクエストを送信し、予測でモデルから応答を受信することによりAPIを呼び出すことができます。
- このパイプラインを調整および自動化するには、頂点AIパイプラインをスケジューラとして使用して、データの準備、モデルトレーニング、モデルの展開ステップを呼び出すことができます。
Vertex AI機能ストアを使用して、入力機能を保存して予測を行うこともできます。たとえば、最新のRAWデータからエンジニアリング機能を定期的に作成し、Vertex AI機能ストアに保存できます。クライアントアプリは、Vertex AI機能ストアから必要な入力機能を取得し、予測を受信するためにモデルに送信します。
前処理場所
図2では、ラベルA、B、およびCは、データの前処理操作がBigQuery、Dataflow、またはTensorflowで行われることを示しています。次のセクションでは、これらのオプションのそれぞれがどのように機能するかについて説明します。
オプションA：BigQuery
通常、ロジックは次の操作のためにBigQueryに実装されます。
- サンプリング：データからサブセットをランダムに選択します。
- フィルタリング：無関係または無効なインスタンスの削除。
- パーティション化：データを分割してトレーニング、評価、テストセットを作成します。
BigQuery SQLスクリプトは、図2のデータ処理ステップであるデータフロー前処理パイプラインのソースクエリとして使用できます。たとえば、カナダでシステムが使用されている場合、データウェアハウスには世界中からのトランザクションがあります。カナダ専用のトレーニングデータを取得することは、BigQueryで最適です。 BigQueryの機能エンジニアリングはシンプルでスケーラブルであり、インスタンスレベルと履歴集約の実装をサポートしています。
ただし、バッチ予測にモデルを使用する場合、または機能がBigQueryで事前計算されているが、オンライン予測中に使用されるVertex AI機能ストアに保存されている場合にのみ、機能エンジニアリングにBigQueryを使用することをお勧めします。オンライン予測用のモデルを展開する予定であり、オンライン機能ストアにエンジニアリング機能がない場合は、SQL前処理操作を複製して、他のシステムが生成する生データポイントを変換する必要があります。言い換えれば、ロジックを2回実装する必要があります。SQLでトレーニングデータを1回実装し、BigQueryのトレーニングデータをプリセスし、モデルを消費するアプリのロジックでは、オンラインデータポイントを予測するために2回目です。
たとえば、クライアントアプリがJavaで記述されている場合、Javaのロジックを再実装する必要があります。これにより、このドキュメントの後半で前処理の課題のトレーニングを提供するスキューセクションで説明されているように、実装の不一致によるエラーが導入されます。また、2つの異なる実装を維持するための余分なオーバーヘッドです。 SQLのロジックを変更してトレーニングデータを前処理するときはいつでも、サービング時にPreprocessデータにそれに応じてJava実装を変更する必要があります。
バッチ予測にのみモデルを使用している場合（たとえば、頂点AIバッチ予測を使用して）、スコアリングのデータがBigQueryから供給されている場合は、BigQuery SQLスクリプトの一部としてこれらの前処理操作を実装できます。その場合、同じ前処理SQLスクリプトを使用して、トレーニングデータとスコアリングデータの両方を準備できます。
フルパスステートフル変換は、BigQueryでの実装には適していません。フルパス変換にBigQueryを使用する場合は、数値機能を拡大するための平均や分散など、ステートフルな変換によって必要な量を保存するために補助テーブルが必要です。さらに、BigQueryでSQLを使用したフルパス変換の実装は、SQLスクリプトの複雑さの増加を生み出し、トレーニングとスコアリングSQLスクリプトの間に複雑な依存関係を作成します。
オプションB：データフロー
図2に示すように、Apacheビームに計算上の高価な前処理操作を実装し、データフローを使用して規模で実行できます。 DataFlowは、バッチおよびストリームデータ処理のための完全に管理された自動化サービスです。データフローを使用する場合、BigQueryとは異なり、データ処理に外部専門ライブラリを使用することもできます。
データフローは、インスタンスレベルの変換、および履歴およびリアルタイムの集約機能変換を実行できます。特に、MLモデルがtotal_number_of_clicks_last_90secのような入力機能を期待する場合、Apacheビームウィンドウ機能は、リアルタイム（ストリーミング）イベントデータ（たとえば、イベントをクリックする）の時間ウィンドウの値を集約することに基づいてこれらの機能を計算できます。変換の粒度に関する以前の議論では、これは「トレーニング中の歴史的集計が、予測中のリアルタイム集計」と呼ばれていました。
次の図（図3）は、リアルタイムに近い予測のためのストリームデータの処理におけるデータフローの役割を示しています。
図3に示すように、処理中に、データポイントと呼ばれるイベントがPub/Subに摂取されます。 DataFlowはこれらのデータポイントを消費し、時間の経過とともに集約に基づいて機能を計算し、展開されたMLモデルAPIを予測用に呼び出します。その後、予測はアウトバウンドパブ/サブキューに送信されます。 Pub/Subから、監視や制御などのダウンストリームシステムによって予測を消費することも、元の要求クライアントに対して（たとえば、通知として）押し戻すこともできます。予測は、リアルタイムのフェッチングのために、 Cloud Bigtableのような低遅延データストアに保存することもできます。 Cloud Bigtableを使用して、これらのリアルタイム集約を蓄積および保存することもできます。そのため、予測に必要なときに調べることができます。
同じApacheビームの実装を使用して、オンライン予測を提供するためのBigQueryやStream-Processのリアルタイムデータなどのオフラインデータストアから生じるバッチプロセストレーニングデータに使用できます。
図2に示すアーキテクチャなど、他の典型的なアーキテクチャでは、クライアントアプリは、オンライン予測のために展開されたモデルAPIを直接呼び出します。その場合、トレーニングデータを準備するために前処理操作がデータフローに実装されている場合、操作はモデルに直接送信される予測データに適用されません。したがって、このような変換は、オンライン予測のためにサービスを提供する際にモデルに統合する必要があります。
データフローは、必要な統計を大規模に計算することにより、フルパス変換を実行するために使用できます。ただし、これらの統計は、予測データポイントを変換するために、予測中に使用する場所に保存する必要があります。 Tensorflow Transform（ tf.Transform ）ライブラリを使用することにより、これらの統計を他の場所に保存するのではなく、モデルに直接埋め込むことができます。このアプローチは、TF.Transformの仕組みについて後で説明します。
オプションC：Tensorflow
図2に示すように、Tensorflowモデル自体にデータの前処理と変換操作を実装できます。図に示されているように、トレーニングのために実装する前処理は、モデルがエクスポートされ、予測のために展開されたときにモデルの不可欠な部分になります。 Tensorflowモデルの変換は、次の方法のいずれかで達成できます。
-
input_fn関数とserving_fn関数にすべてのインスタンスレベル変換ロジックを実装します。input_fn関数は、モデルをトレーニングするためにtf.data.DatasetAPIを使用してデータセットを準備します。serving_fn関数は、予測のためにデータを受信して準備します。 - Keras Preprocessingレイヤーを使用するか、カスタムレイヤーを作成することにより、Tensorflowモデルに変換コードを直接配置します。
serving_fn関数の変換ロジックコードは、オンライン予測のためにSavedModelのサービングインターフェイスを定義します。 serving_fn関数の変換ロジックコードでトレーニングデータを準備するために使用された同じ変換を実装すると、同じ変換が提供されたときに新しい予測データポイントに適用されることが保証されます。
ただし、TensorFlowモデルは各データポイントを個別にまたは小さなバッチで処理するため、すべてのデータポイントから集約を計算することはできません。その結果、Tensorflowモデルにフルパス変換を実装することはできません。
前処理の課題
以下は、データの前処理を実装する主な課題です。
訓練を受けるスキュー。トレーニングを受けるスキューとは、トレーニング中とサービング中の有効性（予測パフォーマンス）の違いを指します。このスキューは、トレーニングでデータを処理する方法とサービスを提供するパイプラインの間の矛盾によって引き起こされる可能性があります。たとえば、モデルが対数変換された機能でトレーニングされているが、サービング中に生の機能が表示されている場合、予測出力は正確ではない場合があります。
変換がモデル自体の一部になる場合、オプションC：Tensorflowで前述したように、インスタンスレベルの変換を処理するのは簡単です。その場合、モデルサービングインターフェイス（
serving_fn関数）は生データを期待し、モデルは出力を計算する前にこのデータを内部的に変換します。変換は、生のトレーニングおよび予測データポイントに適用されたものと同じです。フルパス変換。 You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example,
maxandminvalues to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform (tf.Transform) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform (
tf.Transform) library can help you to address this issue, as described in the following section.
How tf.Transform works
The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.
The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.
tf.Transform for preprocessing and transforming data. Transform training and evaluation data
You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:
- Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the
transform_fngraph. Thetransform_fngraph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants. - Transform phase: During the transform phase, the
transform_fngraph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.
A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.
When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.
The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.
Attach transformations to the exported model
As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.
While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.
The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.
This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.
Preprocessing options summary
The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."
| Data preprocessing option | Instance-level (stateless transformations) | Full-pass during training and instance-level during serving (stateful transformations) | Real-time (window) aggregations during training and serving (streaming transformations) |
|---|---|---|---|
BigQuery (SQL) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. | Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. |
Dataflow (Apache Beam) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew. | Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
Dataflow (Apache Beam + TFT) | Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front. | Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
TensorFlow * | Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front. | Batch scoring: Not Possible . Online prediction: Not Possible . | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible . |
* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.
次は何ですか
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .
This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.
This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.
The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.
導入
ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .
Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .
The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.
This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.
This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.
Preprocessing data for ML
This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.
Data engineering compared to feature engineering
Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:
- Raw data (or just data )
- The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.
- Prepared data
- The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.
- Engineered features
- The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.
The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:
In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.
Preprocessing operations
Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.
For structured data, data preprocessing operations include the following:
- Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
- Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
- Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
- Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
- Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
- Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
- Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.
When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:
- For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
- For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
- For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.
Preprocessing granularity
This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.
Preprocessing and transformation operations can be categorized as follows, based on operation granularity:
Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.
These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.
Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.
For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$Full-pass transformations include the following:
- MinMax scaling numerical features using min and max computed from the training dataset.
- Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
- Bucketizing numerical features using quantiles.
- Imputing missing values using the median (numerical features) or the mode (categorical features).
- Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
- Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
- Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).
You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.
Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other間隔。 You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.
More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of
(entity, timestamp, value). In the previous examples,entityis the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute(entity, time_index, aggregated_value_over_time_window)and use the aggregation features as an input for your model training.When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.
ML pipeline on Google Cloud
This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.
High-level architecture
The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.
The pipeline consists of the following steps:
- After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
- Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
- A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
- The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
- After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
- For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.
You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.
Where to do preprocessing
In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.
Option A: BigQuery
Typically, logic is implemented in BigQuery for the following operations:
- Sampling: randomly selecting a subset from the data.
- Filtering: removing irrelevant or invalid instances.
- Partitioning: splitting the data to produce training, evaluation, and test sets.
BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.
However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.
For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.
If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.
Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.
Option B: Dataflow
As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.
Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."
The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.
As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.
The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.
In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.
Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .
Option C: TensorFlow
As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:
- Implementing all of the instance-level transformation logic in the
input_fnfunction and in theserving_fnfunction. Theinput_fnfunction prepares a dataset using thetf.data.DatasetAPI for training a model. Theserving_fnfunction receives and prepares the data for predictions. - Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .
The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.
However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.
Preprocessing challenges
The following are the primary challenges of implementing data preprocessing:
Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.
If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the
serving_fnfunction) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example,
maxandminvalues to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform (tf.Transform) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.
Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.
Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform (
tf.Transform) library can help you to address this issue, as described in the following section.
How tf.Transform works
The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.
The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.
tf.Transform for preprocessing and transforming data. Transform training and evaluation data
You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:
- Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the
transform_fngraph. Thetransform_fngraph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants. - Transform phase: During the transform phase, the
transform_fngraph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.
A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.
When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.
The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.
Attach transformations to the exported model
As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.
While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.
The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.
This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.
Preprocessing options summary
The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."
| Data preprocessing option | Instance-level (stateless transformations) | Full-pass during training and instance-level during serving (stateful transformations) | Real-time (window) aggregations during training and serving (streaming transformations) |
|---|---|---|---|
BigQuery (SQL) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. | Batch scoring: Not recommended . Online prediction: Not recommended . Although you can use statistics computed using BigQuery for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not recommended —you can process training data, but it results in training-serving skew because you process serving data using different tools. |
Dataflow (Apache Beam) | Batch scoring: OK —the same transformation implementation is applied on data during training and batch scoring. Online prediction: OK —if data at serving time comes from Pub/Sub to be consumed by Dataflow. Otherwise, results in training-serving skew. | Batch scoring: Not recommended . Online predictions: Not recommended . Although you can use statistics computed using Dataflow for instance-level batch/online transformations, it isn't easy because you must maintain a stats store to be populated during training and used during prediction. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
Dataflow (Apache Beam + TFT) | Batch scoring: OK —the same transformation implementation is applied to data during training and batch scoring. Online prediction: Recommended —it avoids training-serving skew and prepares training data up front. | Batch scoring: Recommended . Online prediction: Recommended . Both uses are recommended because transformation logic and computed statistics during training are stored as a TensorFlow graph that's attached to the exported model for serving. | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: OK —the same Apache Beam transformation is applied on data during training (batch) and serving (stream). |
TensorFlow * | Batch scoring: Not recommended . Online prediction: Not recommended . For training efficiency in both cases, it's better to prepare the training data up front. | Batch scoring: Not Possible . Online prediction: Not Possible . | Batch scoring: N/A —aggregates like these are computed based on real-time events. Online prediction: Not Possible . |
* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.
次は何ですか
- To implement a
tf.Transformpipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform . - Take the Coursera specialization on ML with TensorFlow on Google Cloud .
- Learn about best practices for ML engineering in Rules of ML .
- For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .