ストリーミングとバッチ処理を統合したリアルタイム特徴量エンジニアリングプラットフォームの構築実践

この記事では主に、機能エンジニアリング開発における Alibaba Cloud FeatHub プロジェクト チームのプラットフォームの実践と構築の経験を共有します。

この共有は 4 つの部分に分かれています。最初の部分では、機能の開発、展開、監視、共有のプロセスで FeatHub が直面するシナリオ、目標、問題点、課題を概説します。 ; 2 番目のパートでは、FeatHub のアーキテクチャ上のアイデアと関連するコア概念の実践を紹介し、3 番目のパートでは、API の基本的な使用法、基本的なコンピューティング機能、FeatHub 使用時のサンプル シナリオのコード実践、パフォーマンスの最適化と将来の拡張を紹介します。オープンソース コミュニティの共同構築に加え、プロジェクトの学習、開発、利用を提供し、FeatHub の履歴データの再生機能の共有、オフライン、ニアライン、オンライン処理のサポート、およびAlibaba Cloud の上流および下流コンポーネント。

##1. FeatHub が必要な理由

1. 対象シナリオ

(1) Python 環境が必要なデータサイエンティスト

##今日人気のある機械学習の推論およびトレーニング プログラムのほとんどは、基本的にデータ サイエンティストによって Python で作成されています。たとえば、従来の機械学習シナリオで使用される人気の TensorFlow、PyTorch、scikit-learn などです。私たちは、データ サイエンティストが使い慣れた Python を使用して特徴量エンジニアリング コードを記述し、エンドツーエンドの機械学習リンクの開発とデプロイメントを完了し、使い慣れた Python エコシステムのライブラリを使用し続けることをサポートしたいと考えています。

(2) リアルタイム機能の生成

ますます多くの機械学習アプリケーションがリアルタイム方向に開発されており、機械学習の効率と精度はリアルタイムを通じて向上できます。処理。目標を達成するには、リアルタイム機能を生成する必要があります。これは、クエリ特徴をリアルタイムで取得するだけでなく、特徴をリアルタイムで生成することにも当てはまります。たとえば、過去 2 分間のユーザーのクリック数をリアルタイムで取得する必要がある場合は、ストリーミング コンピューティング エンジンを使用してリアルタイムの特徴計算を完了する必要があります。

(3) マルチクラウド展開をサポートするにはオープンソース ソリューションが必要です

ますます多くの中小企業が、本番環境のセキュリティ保証と入札獲得のためにマルチクラウド展開を実現したいと考えています。クラウドベンダーの中での優位性。したがって、私たちのソリューションでは、ユーザーがクラウド ベンダーにバインドする必要はなく、ユーザーはさまざまなクラウド ベンダーを自由に選択でき、プライベート クラウドに機能エンジニアリング操作を展開することもできます。

これらは、FeatHub プロジェクトが最初に設立されたときに満たすことを望んでいた条件の一部です。

2. リアルタイム特徴エンジニアリングの問題点

現在、多くの企業がリアルタイム特徴エンジニアリング運用を開発しています。開発、展開、監視、その後の共有など、機能のライフサイクル全体にわたって、いくつかの問題点があります。

(1) 開発難易度が高い

① 機能トラバーサル

開発段階では、リアルタイム機能フレームワーク Apache Flink Flink は基本的にリアルタイム ストリーム コンピューティングの事実上の標準であるため、主に使用されますが、Flink または同様のフレームワークを使用してリアルタイム機能を開発するには、機能トラバーサルの難しさを解決する必要があります。多くのデータ サイエンティストは機能トラバーサルを解決する経験を知らないため、この種の問題を解決するには多大な学習時間とコストが必要であり、これが開発段階の主な問題点です。

(2) 導入が難しい

① 手動翻訳が必要

多くの企業は、データ サイエンティストが作成した単一プロセスの Python ジョブを分散可能ファイルに変換するための専用のプラットフォーム チームを抱えています。 Flink または Spark ジョブを手動で実行して、高パフォーマンスおよび高可用性の展開を実現できます。その翻訳プロセスにより、開発ライフサイクル全体が延長されます。また、翻訳作業には追加の人手が必要となるため、開発コストが増加し、さらにバグが発生する可能性も生じます。別のグループがデータ サイエンティストの作業を翻訳した後のロジックは、元のロジックと一致しない可能性があり、デバッグの作業負荷が増加します。

(3) 監視が難しい

① 機能分布の変化

特徴量エンジニアリング ジョブの全体的な品質と効率は、ジョブにバグがあるかどうかだけでなく、上流の入力データの数値分布が特定の特性 (トレーニング中のデータの数値分布に近いなど) を満たすかどうかにも依存します。多くのジョブの推論パフォーマンスは低下します。これは、多くの場合、上流のジョブによって生成されたデータの分布の変化が原因です。この場合、開発者はリンク全体をセグメントごとに追跡して、特徴データの分布がどこで変化したかを確認し、特定の状況に基づいて再トレーニングやバグ修正が必要かどうかを確認する必要があります。この部分の人員の過剰な仕事量も問題点です。

(4) 共有が難しい

① 開発作業の重複

多くの特徴計算ジョブの開発チームとシナリオは異なっていても、類似、または同じ特徴定義さえあります。実際に使用されています。多くの企業には、社内のさまざまなチームが既存の機能をクエリして再利用するための適切なチャネルがありません。その結果、多くの場合、さまざまなチームが開発を繰り返し行う必要があり、同じ機能に対していくつかの機能を生成するためにジョブを繰り返し実行する必要さえあります。同じ機能を生成するにはより多くのコンピューティング、メモリ、およびストレージ スペースが必要となるため、これにより人的資源とコンピューティング/ストレージ リソースが無駄になります。

② ポイントインタイムの正しいセマンティクス

誰もが 機能交差 とは何かを理解できるように、上の図は次のとおりです。この問題を説明する簡単な例です。 図の左上のテーブルは、ユーザーの行動特性であり、さまざまな時間ノードでの、特定の ID を持つユーザーの過去 2 分間のクリック数を表します。このクリック数は、ユーザーが広告をクリックするかどうかを推測するのに役立ちます。これらの特徴をトレーニングに使用するには、通常、ラベルを使用して特徴をいくつかのユーザー データ セットに結合する必要があります。 図の左下の表は、ユーザーが実際に広告をクリックしたかどうかを示すいくつかの肯定的なサンプルと否定的なサンプルのデータセットを示し、さまざまな時点でユーザーによって生成された肯定的なサンプルまたは否定的なサンプルをマークします。間に合うように。これら 2 つのデータ セットの特徴を結合してトレーニング データ セットを形成するには、通常、ユーザー ID をキーとして特徴を結合する必要があります。タイムスタンプを考慮せずに単純にテーブル結合を実行すると、機能の交差の問題が発生する可能性があります。たとえば、6:03 分では、最後の 2 分間のユーザーのクリック数は 10 であるはずですが、結合によって得られる特徴量は、7:00 分から 6 になる可能性があります。このような特徴の交差は実際の推論効果の低下をもたらします。ポイントインタイムの正しいセマンティクスを備えた結合結果は、次の図に示すようになります。

サンプルをスプライスするときに特徴の交差を避けるために、サンプルの左側の部分については、上の図 テーブル の各データについて、タイムスタンプが左側のテーブルのタイムスタンプより小さく、最も近いフィーチャ値がディメンション テーブルの複数バージョンのフィーチャの中から見つけられ、結合される必要があります。最終的に生成されたトレーニング データ セットに組み込まれます。ポイントインタイムの正しいセマンティクスを使用したこのようなスプライシングにより、上の図 の右側に示されているトレーニング データ セットが生成されます。さまざまな時点について、過去 2 分間に生成された対応する特徴値があります。この方法で生成されたトレーニング データ セットにより、トレーニングと推論のパフォーマンスが向上します。

3. フィーチャー ストアのコア シナリオ

次に、フィーチャー ストアとしての FeatHub と、フィーチャー ストアの各段階で解決しようとする問題について紹介します。機能開発サイクル全体と提供されるツール。

(1) 機能開発

機能開発段階では、FeatHub は Python ベースの非常に使いやすい SDK を提供し、ユーザーは機能の計算ロジックを簡潔に表現できます。フィーチャ計算は本質的にフィーチャの ETL です。開発段階で最も重要なことは、SDK の使いやすさとシンプルさです。

(2) 機能のデプロイメント

機能のデプロイメント フェーズでは、FeatHub は、高性能、低レイテンシーの特徴計算ロジックのデプロイメントを実装するための実行エンジンを提供し、さまざまな機能に接続できます。特集ストア。デプロイメント段階で最も重要なことは、実行エンジンのパフォーマンスと、さまざまな機能ストアを接続できるかどうかです。

(3) 機能アラーム

機能監視フェーズでは、開発者が特徴値分布の変化を迅速に検出して対応できるようにするために、FeatHub は将来、共通の機能品質をカバーするいくつかの共通指標を生成する予定です。例えば、特徴量の不正な値や特徴量の平均値などを把握し、これらの指標に基づいてアラームを発行し、担当者に速やかに通知し、該当する特徴量の分布が変化した場合の原因究明と対応を行うことで、効果を維持することができます。最後までお勧めのリンク。

(4) 機能共有

機能共有段階では、FeatHub は将来的に機能登録機能と検索機能を提供し、同じ会社内の異なるチームの開発者が必要な機能をクエリできるようにする予定です。 . はまだ存在せず、これらのフィーチャ定義と既に生成されたフィーチャ データを再利用します。

上の図は、FeatHub の主要な機能を示しています。開発段階では、FeatHub は、ポイントインタイムの正しいセマンティクスを備えた機能スプライシング、機能集約、その他のロジックをサポートする使いやすい SDK を提供できます。デプロイメント段階では、FeatHub は高スループット、低レイテンシの特徴生成をサポートし、特徴を計算するための実行エンジンとして Flink の使用をサポートし、複数の特徴ストレージ システムをサポートできるため、ユーザーは使用したいストレージ タイプを自由に選択できます。モニタリング段階では、FeatHub は、オフラインおよびリアルタイムのモニタリングを含む機能配布の変化をモニタリングするためのリアルタイム インジケーターを提供し、開発者がタイムリーに問題を検出できるようにします。共有段階では、FeatHub は使いやすい Web UI と SDK を提供し、開発者による機能の登録、検索、再利用をサポートします。

Feature Store 分野には、今年初めに LinkedIn によってオープンソース化された Feathr や Feast など、すでに代表的な Feature Store プロジェクトがいくつかあります。長年にわたってオープンソース化されてきました。これらのプロジェクトを調査したところ、私たちが提案した目標シナリオの達成にはあまり適していないことがわかりました。

既存のソリューションと比較して、FeatHub は次のような追加の価値をもたらします。

① シンプルで使いやすい Python SDK。 FeatHub の SDK は、既存の Feature Store プロジェクトの SDK を参照し、これらのプロジェクトのコア機能をサポートし、SDK の抽象化機能と使いやすさをさらに向上させます。単独での開発と実験。

開発者は実験を実行するために分散 Flink または Spark クラスターに接続する必要はありませんが、開発と実験には単一マシン上の CPU またはメモリ リソースを使用するだけでよく、単一マシン上で次のような機械学習アルゴリズムを使用できます。 scikit-learn ライブラリ。

③ コードを変更せずに実行エンジンを切り替えることができます。

ユーザーが単一マシンでの開発を完了した後、特徴量計算ロジックを表現するコードを変更することなく、単一マシン実行エンジンを Flink や Spark などの分散実行エンジンに切り替えることができます。 Flink を実行エンジンとして使用すると、Feathhub は高スループット、低遅延のリアルタイム特徴計算をサポートできるようになります。 FeatHub は将来、実行エンジンとして Spark の使用をさらにサポートし、ユーザーがオフライン シナリオでより優れたスループット パフォーマンスを得ることができ、シナリオに応じて最適な実行エンジンを自由に選択できるようになります。

④ 実行エンジンに拡張機能を提供します。

FeatHub は、実行エンジンとして Flink と Spark をサポートするだけでなく、開発者が実行エンジンをカスタマイズし、機能 ETL に社内で開発された実行エンジンを使用することもサポートします。

⑤ コードはオープン ソースであり、

により、ユーザーは FeatHub を展開するクラウド ベンダーを自由に選択したり、プライベート クラウドに展開したりできます。

2. FeatHub のアーキテクチャとコア概念

1. アーキテクチャ

上記は、FeatHub の主要なモジュールを含むアーキテクチャ図です。最上位層は、ユーザー定義のデータ ソース、データ エンド ポイント、および特徴計算ロジックをサポートする Python SDK のセットを提供します。 SDK によって定義された機能は、機能メタデータ センターに登録できるため、他のユーザーやジョブが機能をクエリして再利用したり、機能メタデータに基づいて機能系統をさらに分析したりできるようになります。フィーチャー定義には、フィーチャーのソースとシンクのほか、UDF 呼び出し、フィーチャーのスプライシング、オーバー ウィンドウやスライディング ウィンドウに基づく集計などの一般的な計算ロジックが含まれます。ユーザー定義のフィーチャを生成する必要がある場合、FeatHub は既存のフィーチャの計算ロジックを実行するためのいくつかの組み込みフィーチャ プロセッサ、つまり実行エンジンを提供します。ユーザーが単一マシンで実験を行う必要がある場合、ローカル プロセッサを使用して、リモート クラスタに接続せずに単一マシン上のリソースを使用できます。リアルタイム機能を生成する必要がある場合、Flink Processor を使用して、高スループット、低遅延のストリーミング機能の計算を完了できます。

将来的には、Lambda 関数と同様のフィーチャ サービスをサポートしてオンライン特徴計算を実装することもでき、Spark に接続して高スループットのオフライン特徴計算を完了することもできます。実行エンジンは、オンライン機能ストレージには Redis、オフライン機能ストレージには HDFS、ニアライン機能ストレージには Kafka を使用するなど、さまざまなオフラインおよびオンライン機能ストレージ システムとインターフェイスできます。

上の図は、FeatHub がユーザーによってどのように使用され、ダウンストリームの機械学習トレーニングおよび推論プログラムに接続されるかを示しています。ユーザーまたは開発者は SDK を使用して、必要な機能を表現します。計算し、それをデプロイメントのために実行エンジンに送信します。特徴を計算した後、Redis や HDFS などの特徴ストアに出力する必要があります。機械学習オフライン トレーニング プログラムは、バッチ トレーニングのために HDFS 内のデータを直接読み取ることができます。オンライン機械学習推論プログラムは、オンライン推論のために Redis 内のデータを直接読み取ることができます。

2. コアコンセプト

上の図は、FeatHub のコアコンセプト間の関係を示しています。 TableDescriptor は機能のコレクションを表します。 TableDescriptor は論理変換を通じて新しい TableDescriptor を生成できます。

TableDescriptor は 2 つのカテゴリに分類されます。 FeatureTable は、特定の物理アドレスを持つテーブルを表します。たとえば、Redis のテーブルや HDFS のテーブルなどです。 FeatureView は、必ずしも物理アドレスを持たない論理テーブルであり、通常、一連の論理文字列変換の後に、FeatureTable から取得されます。

FeatureView には次の 3 つのサブクラスがあります。

① DerivedFeatureView 出力特徴テーブルとその入力特徴テーブル (つまりソース) の行は基本的に 1 対 1 です。 。単一行の変換ロジック (加算、減算、乗算、除算など)、ウィンドウ集約ロジック、およびフィーチャ スプライシング ロジックの表現をサポートできます。トレーニング データの生成に使用できます。たとえば、前に紹介した例では、実際のトレーニング データを取得するために、トレーニング サンプルを異なるディメンション テーブルの特徴と結合する必要がある場合、DerivedFeatureView を使用してこれを完了できます。

② SlidingFeatureView は、スライディング ウィンドウによって計算された特徴量の表現をサポートします。出力する特徴テーブルの行と入力する特徴テーブルの行は必ずしも 1 対 1 である必要はありません。これは、スライディング ウィンドウによって計算される特徴量は、新たな入力がなくても時間の経過とともに変化するためです。 SlidingFeatureView を使用すると、リアルタイムで生成された特徴を維持し、オンライン推論のために Redis などのオンライン特徴ストアに出力できます。たとえば、SlidingFeatureView を使用して、過去 2 分間に各ユーザーが特定の Web ページをクリックした回数を計算し、特徴値を Redis にリアルタイムで更新し、広告の推奨リンクでこの特徴の値をクエリできます。オンライン推論のためのオンライン。

③OnDemandFeatureView フィーチャ サービスとともに使用して、オンライン フィーチャ計算をサポートできます。たとえば、Amap を使用する場合、開発者は、推奨事項を支援するために、ユーザーの現在の物理的位置と、ユーザーのリクエストを受信した後、最後にリクエストが送信されたときの物理的位置に基づいて、ユーザーの移動の速度と方向を計算したい場合があります。決断。これらの特徴は、ユーザーのリクエストを受け取ったときにオンラインで計算する必要があります。 OnDemandFeatureView を使用して、このようなシナリオをサポートできます。

Transform は特徴量計算ロジックを表現します。 FeatHub は現在、次の 5 種類の特徴計算ロジックをサポートしています。

① Expression は、ユーザーが DSL 言語に基づいて 1 行の特徴計算ロジックを表現できるようにします。その表現機能は SQL 言語の select ステートメントに近く、加算、減算、乗算、除算に加えて組み込み関数呼び出しもサポートできるため、SQL に精通した開発者はすぐに使い始めることができます。

② Join は、フィーチャ スプライシング ロジックを表します。開発者は、寸法テーブルの名前やスプライスするフィーチャーの名前などの情報を指定できます。

③ PythonUDF は、特徴を計算するためのユーザー定義の Python 関数をサポートしています。

④ OverWindow は、Over window 集計ロジックを表します。たとえば、データ行を受信したときに、ユーザーは前の 5 行のデータを集計し、特定のルールに一致するデータがいくつあるかを計算したいとします。

⑤ SlidingWindow は、スライディング ウィンドウ集計ロジックを表します。

上の図からわかるように、通常、フィーチャ ETL ジョブはフィーチャ ソース テーブルからフィーチャを読み取り、複数のフィーチャ計算ロジックを通じて新しいフィーチャを生成し、生成されたフィーチャはフィーチャ結果テーブルに出力されます。フィーチャ ソース テーブルは、FileSystem、Kafka、Hive などのさまざまなフィーチャ ストアに接続できます。同様に、フィーチャー結果テーブルは、FileSystem、Kafka、Redis などのフィーチャー ストレージに接続することもできます。

Processor には、LocalProcessor、FlinkProcessor、および SparkProcessor が含まれており、スタンドアロンの物理リソース、分散 Flink クラスター、および分散 Spark クラスターを使用して、ユーザー定義の特徴計算ロジックを実行できます。

3. FeatHub API の表示

1. 特徴量計算機能

FeatHub のアーキテクチャとコアコンセプトを紹介した後、いくつかの説明を行います。サンプル プログラムは、FeatHub SDK の表現力と使いやすさを実証するために使用されます。機能開発 SDK の場合、その中核となる機能は、新しい機能計算ロジックを表現する方法です。 FeatHub SDK は、機能スプライシング、ウィンドウ集約、組み込み関数呼び出し、カスタム Python などの機能をサポートしており、将来的には JAVA または C に基づく UDF 呼び出しもサポートする予定です。

上の図は、フィーチャー スプライシングのコード スニペットを示しています。この例では、ユーザーの購入行動を記録するオリジナルのポジティブおよびネガティブ サンプル データが HDFS に存在すると想定しています。さらに、ユーザーが各製品を購入したときの製品価格を取得したいと考えています。 Price_updates テーブルには、製品の価格変更に関するデータが保持されます。製品の価格が変更されるたびに、製品 ID と最新の製品価格を含むデータ行がprice_updates テーブルに生成されます。 JoinTransform を使用し、table_name=price_updates、feature_name=price、key=item_id を設定して、対応するフィーチャ スプライシング ロジックを表現できます。このようにして、FeatHub は、price_updates で指定された item_id を持つ行を見つけ、タイムスタンプに基づいて最適な価格値を見つけて、サンプル データ テーブルに結合できます。

オーバー ウィンドウ集約コード スニペットは、OverWindowTransform を使用して特徴を計算する方法を示しています。ユーザーは expr=”item_counts * Price” および agg_fun=”SUM” を使用して、購入したアイテムの数量と価格に基づいて最新の時間枠での合計消費量を計算できます。ウィンドウの長さは 2 分です。 group_by_keys=["user_id"] は、対応する総消費量をユーザーごとに個別に計算することを意味します。

スライディング ウィンドウ集計はオーバー ウィンドウ集計と似ていますが、API での唯一の違いは、step_size を追加で指定できることです。 step_size=1 分の場合、ウィンドウはスライドして 1 分ごとに新しい特徴値を生成します。

組み込み関数呼び出しのコード スニペットは、DSL 言語を使用して加算、減算、乗算、除算、および UDF 呼び出しを表現する方法を示しています。入力データに、タクシーが乗客を乗せて降ろしたときのタイムスタンプが含まれているとします。 UNIX_TIMESTAMP 組み込み関数を呼び出すことで、乗客の乗降のタイムスタンプを整数型のエポック タイムに変換し、取得したエポック タイムを減算して各移動の長さを取得し、これを特徴として使用できます。その後のトレーニングと推論のために。

PythonUDF によって呼び出されるコード スニペットでは、ユーザーは Python 関数をカスタマイズして、小文字文字列の生成など、入力特徴に対して任意の処理を実行できます。

上記のコード スニペットから、FeatHub の API が比較的シンプルで使いやすいことがわかります。ユーザーは処理エンジンの詳細を知らなくても、計算ロジックに必要なパラメータを設定するだけで済みます。

#2. サンプル シナリオ

#上記のサンプル シナリオでは、ユーザーは 2 つのデータ ソースを持っています。その購入イベントには、ユーザーが購入した製品のサンプル データが含まれており、これは Kafka または FileSystem から取得できます。商品価格イベントには、製品価格の変更に関するデータが含まれています。アイテムの価格が変更されるたびに、アイテム ID や最新のアイテム価格を含むデータ行がアイテム価格イベントに生成されます。製品を購入するユーザーのサンプル データごとに、その行動が発生した最後の 2 分間のユーザーの合計消費量を計算し、ユーザーが特定の製品を購入するかどうかを推測するのに役立つ特徴として使用できることを期待しています。 。このフィーチャーを生成するには、上の図で説明されている計算ロジックを使用して、まず item_id を join_key として使用して、品目価格イベントの価格フィーチャーを購入イベントに結合します。次に、時間枠に基づいて集計し、user_id を group_by _keys として使用して、過去 2 分間の各ユーザーの合計消費量を計算します。

3. サンプル コード

上記のコード スニペットは、サンプル FeatHub アプリケーションで完了する必要がある手順を示しています。

① まず、ユーザーは FeatHubClient を作成し、processor_type を設定する必要があります。ローカル実験の場合は「ローカル」に設定でき、リモート分散運用環境の場合は「Flink」に設定できます。

② ユーザーはデータを読み取るためにソースを作成する必要があります。たとえば、FileSystemSource を使用してオフライン ストレージ システムのデータを読み取ることも、KafkaSource を使用してニアライン ストレージ システムのリアルタイム データを読み取ることもできます。 FileSystemSource では、ユーザーは data_format、スキーマ、ファイルの場所などの情報を指定できます。ユーザーが time_stamp_field と time_stamp_format を指定して、データ ソース テーブル内の時間を表す列と、対応する解析形式をそれぞれ表現できることは注目に値します。 FeatHub はこの情報を使用して、特定の時点での正しい特徴計算を完了し、特徴交差の問題を回避します。

③ ユーザーは、FeatureView を作成して、フィーチャーのスプライシングと集約のロジックを表現できます。スプライスしたい場合、ユーザーは item_price_events.price を使用して、スプライスしたいフィーチャを表現できます。 FeatHub は item_price_events という名前のテーブルを見つけ、そこから Price という名前の機能を取得します。ユーザーは、OverWindowTransform を使用してウィンドウ全体の集計を完了し、total_payment_last_two_ minutes という名前の特性を定義することもできます。 window_size=2 minutes は、指定された式と集計関数を適用して 2 分以内のデータの特徴を計算することを意味します。

④ 定義された FeatureView について、ユーザーがローカルで開発して実験し、単一マシンでのトレーニングに scikit-learn アルゴリズム ライブラリを使用したい場合は、 to_pandas() API Pandas DataFrame 形式で単一マシンのメモリにデータを取得します。

⑤ ユーザーは、機能の実運用展開を完了する必要がある場合、FileSystemSink を使用して、データを保存するためのオフライン機能ストレージを指定できます。次に、execute_insert() を呼び出して、指定されたシンクにフィーチャを出力します。

FeatHub の基本的な価値は、ユーザーが機能を開発しやすくするための SDK と、機能を計算するための実行エンジンを提供することです。さらに、FeatHub は実行エンジンのパフォーマンスの最適化も提供するため、ユーザーは機能の導入段階でより多くのメリットを得ることができます。たとえば、スライディング ウィンドウ集計に基づく特徴の場合、現在ネイティブ Flink API を使用して計算している場合、Flink は、特徴値が変更されたかどうかに関係なく、各スライディング step_size で対応する特徴値を出力します。 window_size=1 時間、step_size=1 秒のスライディング ウィンドウの場合、ほとんどの場合、Flink は同じ特徴値を出力します。これにより、ネットワーク トラフィック、ダウンストリーム ストレージ、その他のリソースが無駄になります。 FeatHub は、ユーザーによるスライディング ウィンドウの動作の設定をサポートしており、特徴量が変更された場合にのみスライディング ウィンドウが特徴量を出力して、特徴量計算ジョブのリソース使用量を最適化できます。

さらに、FeatHub はスライディング ウィンドウのメモリと CPU 使用率をさらに最適化します。シナリオによっては、ユーザーは多くの同様のスライディング ウィンドウ機能に落ち着きます。これらの機能の違いはウィンドウ サイズのみです。たとえば、過去 1 分間、5 分間、および 10 分間に各ユーザーが購入に費やした合計金額を取得したい場合があります。ネイティブ Flink API が計算に使用される場合、ジョブは 3 つの集計演算子を使用してこれら 3 つの特徴をそれぞれ計算できます。各集計演算子は個別のメモリ空間を持ちます。これらのオペレーターによって処理されるデータと計算ロジックには大きな重複があることを考慮して、FeatHub はカスタム オペレーターを使用してこれらの機能の計算を均一に完了し、メモリと CPU リソースを節約するという目標を達成できます。

FeatHub は現在 GitHub 上のオープンソースであり、いくつかの基本的な LocalProcessor および FlinkProcessor 機能をサポートできます。ユーザー特徴エンジニアリングの開発と実装を容易にするために、FeatHub のコア機能をさらに改善していきます。これらには、より一般的に使用されるオフライン ストレージとオンライン ストレージのサポート、Notebook とのドッキング、機能メタデータを視覚化する Web UI の提供、ユーザーによる機能の登録、検索、再利用のサポート、FeatHub の実行エンジンとしての Spark の使用のサポートが含まれます。

FeatHub コード ベース: https://github.com/alibaba/FeatHub

FeatHub コード サンプル: https://github.com/flink-extended/FeatHub-examples

FeatHub コード ベースは現在、github/alibaba ディレクトリに配置されています。誰もが FeatHub の使用方法を簡単に学習し、必要なシナリオのニーズを満たすコード スニペットをすばやく見つけて参照できるようにするために、flink-extended/feathub-examples コード ライブラリで追加のコード サンプルを提供しています。自由に使って試してみてください。どなたでもフィードバックを提供したり、PR に貢献したりすることを歓迎します。

4. 質疑応答セッション

Q1: ポイントインタイム結合中の機能の交差は、データの順序が正しくない遅延によって引き起こされるのか、それとも手動で結合を作成することによって引き起こされるのでしょうか?

A1: 原則としてデータの順序が狂っていなくても、結合時にタイムスタンプフィールドを考慮しないと順序が狂う可能性があります。実際のシナリオでは、ソース データが故障している可能性もあります。現時点では、Flink と同様のウォーターマーク戦略を使用して、遅れて到着するデータを待機し、順序外れの影響を軽減できます。さらに、定期的なオフライン ジョブを使用してオンライン フィーチャ データをバックフィルすることができるため、データ障害の影響をさらに軽減できます。

Q2: FeatHub の起動後、過去のトレーニング データとそれに対応する機能を生成するにはどうすればよいですか? FeatHub は履歴データの再生をサポートしていますか?

A2: FeatHub API は再生をサポートできますが、機能のこの部分はまだ本番環境で検証されていません。 FeatHub は実行エンジンとして Flink と Spark の使用をサポートするため、Flink と Spark のコンピューティング機能を再利用して履歴データの再生を完了できます。たとえば、Spark ジョブを開始し、過去 1 か月間 HDFS 上のすべてのデータを処理するようにソースを設定し、定義された特徴のスプライシングと集約ロジックを実行して、計算された特徴を出力できます。

Q3. FeatHub はオフライン特徴量の計算のみを担当しますが、一部のオンライン特徴量はどのように処理すればよいですか?

A3: 特徴量計算はオフライン、ニアライン、オンラインに分かれています. Flink は、過去 5 分間のユーザーのクリック数などの特徴量をリアルタイムで計算できるニアライン実行エンジンです。同時にオフライン計算もサポートできます。したがって、FeatHub はオフラインおよびニアラインの特徴計算をサポートできます。 FeatHub は、将来、OnDemandFeatureView で表現される特徴を計算するフィーチャ サービスに基づくアーキテクチャを使用して、オンライン特徴計算をサポートする予定です。

Q4: FeatHub は Alibaba Cloud でサービスを提供していますが、ODPS などの現在の上流および下流のエコロジー サポートは何ですか?

A4: FeatHub は、ODPS、Holo、および Alibaba Cloud によって提供されるその他のサービスを含む、Flink によってサポートされるすべてのソース/シンクをサポートします。現在、FeatHub は Kafka と FileSystem のみをサポートしています。ストレージのサポートを徐々に追加していきます。

以上がストリーミングとバッチ処理を統合したリアルタイム特徴量エンジニアリングプラットフォームの構築実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。