この記事では主に、機能エンジニアリング開発における Alibaba Cloud FeatHub プロジェクト チームのプラットフォームの実践と構築の経験を共有します。
この共有は 4 つの部分に分かれています。最初の部分では、機能の開発、展開、監視、共有のプロセスで FeatHub が直面するシナリオ、目標、問題点、課題を概説します。 ; 2 番目のパートでは、FeatHub のアーキテクチャ上のアイデアと関連するコア概念の実践を紹介し、3 番目のパートでは、API の基本的な使用法、基本的なコンピューティング機能、FeatHub 使用時のサンプル シナリオのコード実践、パフォーマンスの最適化と将来の拡張を紹介します。オープンソース コミュニティの共同構築に加え、プロジェクトの学習、開発、利用を提供し、FeatHub の履歴データの再生機能の共有、オフライン、ニアライン、オンライン処理のサポート、およびAlibaba Cloud の上流および下流コンポーネント。
##1. FeatHub が必要な理由1. 対象シナリオ
(1) Python 環境が必要なデータサイエンティスト
(1) 開発難易度が高い 
特徴量エンジニアリング ジョブの全体的な品質と効率は、ジョブにバグがあるかどうかだけでなく、上流の入力データの数値分布が特定の特性 (トレーニング中のデータの数値分布に近いなど) を満たすかどうかにも依存します。多くのジョブの推論パフォーマンスは低下します。これは、多くの場合、上流のジョブによって生成されたデータの分布の変化が原因です。この場合、開発者はリンク全体をセグメントごとに追跡して、特徴データの分布がどこで変化したかを確認し、特定の状況に基づいて再トレーニングやバグ修正が必要かどうかを確認する必要があります。この部分の人員の過剰な仕事量も問題点です。
① 開発作業の重複
多くの特徴計算ジョブの開発チームとシナリオは異なっていても、類似、または同じ特徴定義さえあります。実際に使用されています。多くの企業には、社内のさまざまなチームが既存の機能をクエリして再利用するための適切なチャネルがありません。その結果、多くの場合、さまざまなチームが開発を繰り返し行う必要があり、同じ機能に対していくつかの機能を生成するためにジョブを繰り返し実行する必要さえあります。同じ機能を生成するにはより多くのコンピューティング、メモリ、およびストレージ スペースが必要となるため、これにより人的資源とコンピューティング/ストレージ リソースが無駄になります。
② ポイントインタイムの正しいセマンティクス
誰もが 機能交差 とは何かを理解できるように、上の図は次のとおりです。この問題を説明する簡単な例です。 図の左上のテーブルは、ユーザーの行動特性であり、さまざまな時間ノードでの、特定の ID を持つユーザーの過去 2 分間のクリック数を表します。このクリック数は、ユーザーが広告をクリックするかどうかを推測するのに役立ちます。これらの特徴をトレーニングに使用するには、通常、ラベルを使用して特徴をいくつかのユーザー データ セットに結合する必要があります。 図の左下の表は、ユーザーが実際に広告をクリックしたかどうかを示すいくつかの肯定的なサンプルと否定的なサンプルのデータセットを示し、さまざまな時点でユーザーによって生成された肯定的なサンプルまたは否定的なサンプルをマークします。間に合うように。これら 2 つのデータ セットの特徴を結合してトレーニング データ セットを形成するには、通常、ユーザー ID をキーとして特徴を結合する必要があります。タイムスタンプを考慮せずに単純にテーブル結合を実行すると、機能の交差の問題が発生する可能性があります。たとえば、6:03 分では、最後の 2 分間のユーザーのクリック数は 10 であるはずですが、結合によって得られる特徴量は、7:00 分から 6 になる可能性があります。このような特徴の交差は実際の推論効果の低下をもたらします。ポイントインタイムの正しいセマンティクスを備えた結合結果は、次の図に示すようになります。
サンプルをスプライスするときに特徴の交差を避けるために、サンプルの左側の部分については、上の図 テーブル の各データについて、タイムスタンプが左側のテーブルのタイムスタンプより小さく、最も近いフィーチャ値がディメンション テーブルの複数バージョンのフィーチャの中から見つけられ、結合される必要があります。最終的に生成されたトレーニング データ セットに組み込まれます。ポイントインタイムの正しいセマンティクスを使用したこのようなスプライシングにより、上の図 の右側に示されているトレーニング データ セットが生成されます。さまざまな時点について、過去 2 分間に生成された対応する特徴値があります。この方法で生成されたトレーニング データ セットにより、トレーニングと推論のパフォーマンスが向上します。
次に、フィーチャー ストアとしての FeatHub と、フィーチャー ストアの各段階で解決しようとする問題について紹介します。機能開発サイクル全体と提供されるツール。
機能開発段階では、FeatHub は Python ベースの非常に使いやすい SDK を提供し、ユーザーは機能の計算ロジックを簡潔に表現できます。フィーチャ計算は本質的にフィーチャの ETL です。開発段階で最も重要なことは、SDK の使いやすさとシンプルさです。
機能のデプロイメント フェーズでは、FeatHub は、高性能、低レイテンシーの特徴計算ロジックのデプロイメントを実装するための実行エンジンを提供し、さまざまな機能に接続できます。特集ストア。デプロイメント段階で最も重要なことは、実行エンジンのパフォーマンスと、さまざまな機能ストアを接続できるかどうかです。
機能監視フェーズでは、開発者が特徴値分布の変化を迅速に検出して対応できるようにするために、FeatHub は将来、共通の機能品質をカバーするいくつかの共通指標を生成する予定です。例えば、特徴量の不正な値や特徴量の平均値などを把握し、これらの指標に基づいてアラームを発行し、担当者に速やかに通知し、該当する特徴量の分布が変化した場合の原因究明と対応を行うことで、効果を維持することができます。最後までお勧めのリンク。
機能共有段階では、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 内のデータを直接読み取ることができます。
上の図は、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 クラスターを使用して、ユーザー定義の特徴計算ロジックを実行できます。
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. サンプル シナリオ
② ユーザーはデータを読み取るためにソースを作成する必要があります。たとえば、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 に貢献したりすることを歓迎します。
A1: 原則としてデータの順序が狂っていなくても、結合時にタイムスタンプフィールドを考慮しないと順序が狂う可能性があります。実際のシナリオでは、ソース データが故障している可能性もあります。現時点では、Flink と同様のウォーターマーク戦略を使用して、遅れて到着するデータを待機し、順序外れの影響を軽減できます。さらに、定期的なオフライン ジョブを使用してオンライン フィーチャ データをバックフィルすることができるため、データ障害の影響をさらに軽減できます。
A2: FeatHub API は再生をサポートできますが、機能のこの部分はまだ本番環境で検証されていません。 FeatHub は実行エンジンとして Flink と Spark の使用をサポートするため、Flink と Spark のコンピューティング機能を再利用して履歴データの再生を完了できます。たとえば、Spark ジョブを開始し、過去 1 か月間 HDFS 上のすべてのデータを処理するようにソースを設定し、定義された特徴のスプライシングと集約ロジックを実行して、計算された特徴を出力できます。
A3: 特徴量計算はオフライン、ニアライン、オンラインに分かれています. Flink は、過去 5 分間のユーザーのクリック数などの特徴量をリアルタイムで計算できるニアライン実行エンジンです。同時にオフライン計算もサポートできます。したがって、FeatHub はオフラインおよびニアラインの特徴計算をサポートできます。 FeatHub は、将来、OnDemandFeatureView で表現される特徴を計算するフィーチャ サービスに基づくアーキテクチャを使用して、オンライン特徴計算をサポートする予定です。
A4: FeatHub は、ODPS、Holo、および Alibaba Cloud によって提供されるその他のサービスを含む、Flink によってサポートされるすべてのソース/シンクをサポートします。現在、FeatHub は Kafka と FileSystem のみをサポートしています。ストレージのサポートを徐々に追加していきます。
以上がストリーミングとバッチ処理を統合したリアルタイム特徴量エンジニアリングプラットフォームの構築実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
