URLベースのクライアント監視と分析における機械学習の最適化と実践

従来のクライアント監視および分析シナリオでは、特定の URL に基づく統計分析方法が使用されます。ただし、アプリケーションが数万の URL にアクセスする場合、結果は不十分であり、アプリケーションがアクセスした URL に潜在的な問題があるかどうかを明確に特定することは不可能です。

MDAP プラットフォームは、クライアントの監視と分析を実行する際に、確率統計と機械学習ソリューションを使用して、いくつかの類似した URL を同じルールモデルに正規化し、ルールモデルに基づいて関連する統計分析を実行します。これにより、URL ベースのクライアントの監視と分析の可用性と精度が向上し、MDAP ユーザーによる独自のアプリケーション品質の監視と分析がさらに向上します。

1. はじめに

URL は、クライアントの監視と分析の重要な要素です。従来の URL ベースの統計分析方法では、次のように元の URL 値を直接統計分析に使用します。

 `url` を選択し、 count ( 1 ) を`cnt` として計算します。
 `web_analysis_tab` から
ここで、 `app_name` = 'app_1'
 GROUP BY `url` ;

上記のクエリステートメントを使用した統計分析の結果は非常に貧弱であり、主に次の点で顕著です。

アプリ開発者は 迅速かつ正確に 分析結果を通じて潜在的なアプリケーションの問題とリスクを特定して発見します。
統計結果も分散ユーザーは統計分析結果を見ることに興味を失う可能性があります。
プラットフォームは、大量の離散データの統計分析を処理し、フィルタリングします。 システムオーバーヘッド クエリ効率、ネットワーク転送、ページ表示など。

例えば、 アプリ_1 訪問した 1,000,000 異なる値を持つ URL とその URL ルールモデル 100未満 。

初版 MDAP （多次元解析プラットフォーム）ユーザーや開発者もこのような問題に悩まされています。 MDAP ユーザーにより良いサービスを提供するために、MDAP ユーザーが独自のアプリケーションの品質を迅速かつ効果的に分析できるように支援します。 MDAPプラットフォームは、 確率と統計 理論と 機械学習 アプリケーションによって報告されたURLに基づいて、テクノロジーは、 自動学習 派生フィールドを使用して対応するURLモデルを出力する url_pattern オリジナルというより url 統計分析が実行され、URL ベースの統計分析のオーバーハッシュが大幅に削減され、統計分析結果がより収束し、ユーザーが MDAP を使用して独自のアプリケーションの品質を分析および表示しやすくなります。

この論文の残りの部分は次のように構成されています。セクション 2 では、URL 正規化の問題を解決するための MDAP の考え方を具体的な例とともに説明します。セクション 3 では、MDAP が URL を正規化する方法の全体的なフレームワークを紹介し、セクション 4 では詳細なアルゴリズムの説明を示します。最適化効果のテストと評価については、セクション 5 で説明します。最後に、第 6 章では、まとめと今後の展望を示します。

2. 検討すべき質問

このセクションでは、この作業の背景にある詳細な動機と考え方について説明します。構成/アップロード URL モデルルールの実行不可能性を説明するために 3 つの異なるスキームが分析され、ボトムアップのペアワイズ戦略がどのように機能し、いつ失敗するかを示すために具体的な例が使用され、パターンツリーが効果的な理由が説明されています。

2.1 ユーザー設定スキーム

URLモデルルールの設定/アップロード

URL を対応する URL モデルルールに変換するために最初に検討された解決策は、ユーザーがプラットフォームでアプリケーション関連の URL モデルルールを構成/アップロードできるようにすることですが、この解決策にはいくつかの問題があることがすぐにわかりました。

golang/ジン : GET http://example.com/users/:user_name ;

golang/grpc-ゲートウェイ : GET http://example.com/{name=users/*} 、従う Google API 設計仕様;

ジャバ/スプリング : GET http://example.com/users/{user_name} 。

複雑なユーザー設定。 MDAP プラットフォームの目的は、プラットフォームユーザーが独自のアプリケーションの品質を監視、カウント、分析できるように支援することです。 URL モデルのマッチングを実行するには、プラットフォームユーザーが URL モデルルールを設定/アップロードする必要があり、プラットフォームユーザーの負担が間違いなく増加します。同時に、プラットフォームユーザーは新しい URL モデルルールの変更を忘れる可能性が高く、URL モデルのマッチング効果に重大な影響を与え、従来の URL 統計分析モデルに戻ってしまいます。
差別化された URL モデルルール。言語やフレームワークによって URL ルーティングルールは大きく異なります。スタイルの違いが大きいため、プラットフォーム上で URL ルールモデルを統一的に管理することができません。たとえば、特定のユーザーの詳細情報を取得するための次の 3 つの URL モデルルールは次のとおりです。
膨大なデータを含む外部 URL。 MDAP プラットフォームの統計分析によると、単一のアプリケーションがアクセスする外部 URL アドレスのうち、アプリケーションによって提供されていないアドレスの数は、平均で約 10% ～ 30% を占めています。これらの外部 URL のほとんどは、Google や Facebook などの Web サイトのルーティングアドレスです。MDAP プラットフォームのユーザーが独自のアプリケーションを開発する場合、外部 URL のモデルルールを完全に理解していないため、MDAP プラットフォームで関連する構成を実行できません。

まとめると、ユーザーが設定したURLモデルルールに基づくソリューションは 実現不可能 。したがって、MDAP プラットフォームは、アプリケーションによって報告された URL に基づいて、対応する URL ルールモデルを自動的に学習する必要があります。

2.2 機械学習ソリューション

2.2.1 URLプロトコル構文の概要

読者が後続のアルゴリズム設計と問題解決に関する MDAP の考え方をよりよく理解できるように、この記事では次の図に示すように、URL の構文構造を簡単に紹介する必要があります。

上の図に基づいて、URL をいくつかの一般的な URL コンポーネントに分解できます。 schema 、 authority 、 path 、 query そして fragment 、これは : 、 / 、 ? そして # 分割する。たとえば、URL http://example.com/books/search?name=go&isbn=1234 それは次のコンポーネントに分解できます。

 スキーマ: http
 権限: 例.com
 パス: { "path0" : "books" , "path1" : "search" }
 クエリ: { "name" : "go" , "isbn" : "1234" }

後半のアルゴリズム設計では、本論文では path そして query 2つのデータ部分、上記のURLを Tuple(authority, Array[Tuple(K, V)]) 構造は次のとおりです。

 （
 「example.com」 、
 [
 ( "path0" 、 "本" )、
 ( "path1" 、 "検索" )、
 ( 「名前」 、 「行く」 )、
 ( "isbn" 、 "1234" )
 ]
 ）

2.2.2 ボトムアップペアリング戦略を考える

上の図に示すように、8 つの異なる URL があります。MDAP は 2.2.1 を使用して各 URL を KV 構造に変換します。例: U1 -> {"K1": "a", "K2": "b", "K3": "y", "K4": "c", "K5": "*"} 。ボトムアップ戦略を使用してURLルールモデルを生成すると、次のことがはっきりとわかります。 K3 そして K5 正規化されるべきである * 。正規化プロセスは次のとおりです。

U5 + U6 -> P1 : ({"K1": "a", "K2": "b", "K3": "y", "K4": "c", "K5": "*"})
U7 + U8 -> P2 : ({"K1": "a", "K2": "b", "K3": "z", "K4": "c", "K5": "*"})
P1 + P2 -> P3 : ({"K1": "a", "K2": "b", "K3": "*", "K4": "c", "K5": "*"})

上記の手順では、まず U5、U6、U7、U8 に基づいてそれぞれ P1 と P2 を生成し、次に P1 と P2 に基づいて理想的な URL モデルルール P3 を生成します。しかし、U6が存在しない場合は、P1を生成できず、さらにP3も生成できません。また、上記の例では、U1 - U4 もルールモデルを生成するためのペアリングには適していません。

2.2.3 URLパターンツリー

ボトムアップ戦略と比較して、パターンツリーはトレーニングセット全体の統計情報を最大限に活用できます。このようにして、学習プロセスの信頼性と堅牢性が向上し、ランダムノイズの影響を受けなくなります。 2.2.2の例では、一部のURLが存在しない場合でも、他のすべてのURL（U1〜U4を含む）を考慮することで解決できます。

第二に、パターンツリーを使用すると、ツリーノードに基づいてルールを直接要約することで、学習効率を大幅に向上させることができます。たとえば、P1 と P2 は不要になり、上記のパターンに従って P3 を直接生成できます。詳細なアルゴリズムの説明はセクション 4 で詳しく説明します。

3. フレームワークの概要

この章では、URL モデルルールの学習とマッチングのための MDAP の方法とアーキテクチャについて説明します。

上の図に示すように:

まず、MDAP は URL モデル学習器を使用して、アプリケーションから報告された URL データに基づいて URL ルールモデルを自動的に学習し、それを保存します。
次に、URLモデルマッチャーで、MDAPはアプリケーションから報告されたURLデータにURLルールモデルを適用してタプルを生成します。 Tuple(url, url_pattern) 次に、データウェアハウスに保存します。

さまざまなアプリケーションによって MDAP に報告される膨大な量の URL データを考慮して、MDAP プラットフォームは次のように Flink を使用して URL モデルルールを学習します。

データソースから URL データを読み取ります。
2.2.1に従って、各URLを Tuple(authority, Array[Tuple(K, V)]) 構造;
権限 + 塩権限塩塩の長さ(配列[Tuple( K , V)])
同じグループ内の URL については、パターンツリーアルゴリズムを使用して URL ルールモデルが生成されます。
次に authority ステップ 4 で生成された結果をグループ化します。
同じものをマージ authority 次のモデル;
URL ルールモデルを保存します。

URLパターンマッチャーに関しては、MDAPは Trie URL モデルマッチングの効率を向上させるための派生バリアント構造については、この記事では説明しません。興味のある読者は、詳細を学んでください。トライこのデータ構造。

4. アルゴリズムの説明

この章では、エントロピーに基づくノード分割と、ガウス分布とマルコフ連鎖に基づく有意値と離散値の区別に焦点を当て、パターンツリーに基づいて URL ルールモデルを生成する方法について説明します。

上の図に示すように、URL ルールモデルを生成するアルゴリズムには、次の 6 つのステップが含まれます。

すべての URL を含むパターンツリーのルートノードを初期化します。
探し出す価値要素 分割に最適 URLキー（ path_index または query_key );
ステップ2で見つかったURLキーを特定する 重要な価値 （顕著な価値）と 離散値 （自明な値）
有意な値は保持され、離散値は正規化される。 * 、そして重要な価値と * パターンツリーを分割します。
すべての URL キーが処理されるまで手順 2 ～ 4 を繰り返します。
パターンツリーのリーフノードをトラバースし、各 URL ノードのモデルルールを収集します。

このアルゴリズムでは、最も重要な 2 つのステップはステップ 2 とステップ 3 です。

4.1 値要素に最も適したURLキーを見つける

情報 エントロピ 分割の概念は、分割に最適な URL キーを見つける方法を解決するために使用されます。 URL キーの値がランダムであればあるほど、エントロピーは大きくなります。キー値の変化が少ない部分をできるだけ集約し、変化が多い部分については事後計算やワイルドカード処理を行い、エントロピーを最小化できるURLキーを見つける必要があります。 URL キーに対応するエントロピーを計算する式は次のとおりです。

このうち、V は URL キーに対応する値要素の数、N はすべての要素が出現する合計回数、vi は i 番目の要素の出現頻度です。

上記の式に従って、エントロピーが最小の URL キーを見つけ、4.2 と組み合わせて有意値と離散値を区別し、モデルツリーノードを分割します。

4.2 有意値と離散値の区別

4.2.1 ガウス分布に基づく有意値と離散値の区別

MDAP によって収集された URL 履歴データの分析に基づいて、URL 内の各キーに対応する値のリストはガウス分布に従うと想定されます。

したがって、エントロピーが最も小さいキーの値を頻度の逆順に並べ替え、隣接する 2 つの値間の頻度の減少率を計算します。減少率が最も大きい 2 つのノードを境界として、有意値と離散値を区別します。分割点の左側が有意値、右側が離散値です。例:

上の図では、周波数速度の低下が最も大きい2つのノードは videos そして 0 したがって、重要な値は次のとおりです。

 [ 「インデックス」 、 「ユーザー」 、 「書籍」 、 「ビデオ」 ]

離散値には次のものが含まれます。

 [ "0" 、 "12323" 、 "a3df56" 、 "bher43" ]

4.2.2 マルコフ連鎖と密度関数に基づく剪定

4.2.1 は有意な値と離散値を区別するために使用できますが、その効果は必ずしも効果的ではありません。次に例を示します。

上図では、URL キーに対応する値が青い線のガウス分布に従う場合、4.2.1 は有意値と離散値を区別できます。しかし、URL キーに対応する値がオレンジ色の線のガウス分布に従う場合、またはオレンジ色の線よりも平坦である場合、離散値を有意値と誤認する可能性が非常に高いため、プルーニング操作を実行するための補助アルゴリズムが必要になります。

MDAP プラットフォームによる URL データの分析によると、個別の URL は次の特性を満たしていることがわかります。

次のような数字: /users/123 で 123 ;
ハッシュ値: /files/12af8712 で 12af8712 ;
base64 の場合、例: /something/aGVsbG8K で aGVsbG8K およびその他の非人間言語。

上記の特性を満たす文字列（数字を除く）を総称して意味不明な文字列と呼びます。 MDAP では、意味不明な文字や数字の URL キー値を除去するために、意味不明な文字や数字の認識にマルコフ連鎖と密度関数を導入しています。ただし、略語 (Abbreviate) は標準的な人間の言語に属していないため、意味不明な文字と誤判定される可能性が高くなります。そのため、事前判定用の略語テーブルを構成する必要があります。具体的なアルゴリズムの手順は次のとおりです。

指定された文字列が略語表に含まれているかどうかを判断します。含まれている場合は、それを重要な値として保持して終了します。含まれていない場合は、後続の手順に進みます。
指定された文字列が意味不明であるかどうかを判断します。意味不明である場合は、それを離散値として分類して終了します。そうでない場合は、次の手順に進みます。
指定された文字列に多数の数字が含まれているかどうかを判別し、含まれている場合はそれを離散値として分類し、含まれていない場合は重要な値として保持します。

マルコフ連鎖に基づくナンセンス検出

マルコフ連鎖は NLP (自然言語処理) で広く使用されています。MDAP プラットフォームは、比較的単純な方法でマルコフ連鎖を使用します。 2-gram 文字列の分割は、次のように連続する文字列が出現する確率を計算するために実行されます。

マルコフ連鎖と大きなテキストをトレーニングセットとして使用して、対応する確率行列を生成します。

次に、マトリックスを正常なテキストと不良なテキストに適用して、文字列が意味不明かどうかを判断するためのしきい値を計算します。

最後に、次の式を使用して、指定された文字列が意味不明であるかどうかを判断します。

密度関数に基づくデジタルコンテンツの識別

次のようなメジャーバージョン番号のような文字列を考えてみましょう。 v1 は重要な値として保存する必要がありますが、ユーザーIDなどの文字列は、 1234 は離散値として分類する必要があるため、文字列配列の内容を決定するには次の数式が必要です。

5. アルゴリズムの最適化テストと効果表示

このセクションでは、パターンツリーによって生成された URL ルールモデルの重複排除効果と URL 一致度を示し、MDAP プラットフォームでの実際の効果を示します。

5.1 アルゴリズム最適化テスト

5.1.1 圧縮比テスト

まず、MDAPは本番環境からデータの一部をトレーニングセットとして収集し、URLルールモデルを生成します。このモデルでは、各ドメイン名に 100,000 - 2,000,000 元の URL データを次の図に示します。

元のURLは distinct 重複排除後、 10 - 16,000 URLは以下のとおりです。

最後に、元のURLが第4節のアルゴリズムによって処理された後、生成されるURLルールモデルの数は 1 - 85 下の図に示すように:

重複排除されたURLとURLルールモデルの統計的効果図を比較すると、次のことがはっきりとわかります。パターンツリーによって生成されるURLモデルルールの数は、単純な distinct 重複排除の結果。

5.1.2 マッチングテスト

5.1.1 で生成された URL ルールモデルは、2 つの異なるテストセット間で検証されます。テストセット 1 (Test-1) はトレーニングセットと同じ日ですが期間が異なるデータであり、テストセット 2 (Test-2) はテストセット 1 の 1 週間後のデータです。上の図に示すように、テストセット 1 のデータマッチングルールモデルのヒット率は非常に高く (99.99% 以上)、テストセット 2 のヒット率は比較的低くなっています (80.89% - 100%)。

5.1.3 テストの結論

5.1.1 と 5.1.2 のテスト結果に基づいて、次の結論を導き出すことができます。

パターンツリーに基づいて生成された URL ルールモデルの統計分析により、統計分析結果の収束性が大幅に向上します。
URL とモデルルールの一致度は、トレーニング時間と一致時間の範囲によって異なります。時間差が近いほど、一致度は高くなります。

5.2 エフェクト表示

MDAPプラットフォームは現在、 T + 1 URLルールモデルはこのようにマッチングされます。プラットフォームデータモニタリング統計に基づくと、モデルルールの平均マッチング失敗率は約 0.3% 。このモデルに基づくルールを用いたURL統計分析に基づくページ表示効果は以下のとおりです。最初の図は、 distinct 重複排除後の URL の統計分析 (約 1.5 倍) 8110 2番目の図はURLルールモデルに基づく統計分析です（約 60 ストリップ）。