Amazon Web Services ブログ

URL パスを分析して Amazon Elasticsearch Service の個々の要素を検索する

AWS クラウドにデータレイクを構築するのであれば、おそらく基礎となるデータのメタデータやカタログを検索する機能が必要になります。S3 キー、S3 およびオブジェクトメタデータの保存と検索には Amazon Elasticsearch Service (Amazon ES) をお勧めします。少なくとも、S3 キーにはオブジェクト名が含まれていますが、さらに検索したい追加の識別パス要素も含まれているでしょう。この記事では、キーパスを検索できるように Amazon ES を設定する方法について説明します。その過程で、テキストフィールドのためのカスタムアナライザーを作る方法も取り上げます。

分析

Amazon Elasticsearch Service (Amazon ES) を使用すると、Elasticsearch を使用してアプリケーションのデータを簡単に検索することができます。この記事は、Elasticsearch の機能に関するものです。Amazon ES は、データ、マッピング、検索リクエストなどが通過する管理レイヤーです。Amazon ES と Elasticsearch の関係の詳細については、当社のドキュメントを参照してください。

ドキュメントは、マッピングと一緒に Amazon ES に送信されます。このマッピングによって、Elasticsearch がフィールド内の値をどのように解析するかが決まり、クエリのターゲットとなる用語が作成されます。Amazon ES にクエリを送信すると、Elasticsearch はクエリ内の用語とドキュメントのフィールド内の用語を照合して、そのドキュメントがクエリと一致するかどうかを判断します。Elasticsearch は、こうした一致のランク付けされたセットをスコア付けし、クエリ結果として返します。

この記事では、テキストタイプの値に焦点を当てます。Elasticsearch 6.x のマッピングは、テキストとキーワードの 2 種類のテキストフィールドをサポートしています。キーワードフィールドは最低限の処理が行われ、完全一致の基礎として機能します。テキストフィールドは分析され、用語と呼ばれる個々の単語に分割されます。(Elasticsearch の一部の以前のバージョンでは、テキストタイプに異なる名前が使用されていたことに注意してください。)

Elasticsearch はテキストフィールドを分析し、いくつかの処理段階を経てテキストを渡します。これは、文字のストリームを文字フィルターに渡し、次にトークナイザを適用して用語のストリームを発行し、最後に生成されたトークンにトークンフィルターを適用します。

下記のように、こうした各段階の動作をカスタマイズすることができます。

Elasticsearch のアナライザー

Elasticsearch には、以下のような多数のアナライザーが組み込まれています。

  • Whitespace – ソース文字列を空白で分割し、文字の追加やトークンのフィルタリングを行わずに用語を作成します。
  • Simple – ソース文字列を英字以外の文字で分割し、テキストを小文字に変換して用語を作成します。
  • Standard – Unicode テキストセグメンテーションを適用して用語を作成します。これはテキストフィールドのデフォルトのアナライザーです。用語を小文字に変換しません。
  • Keyword – 入力文字列全体が、変更されずに単一の用語として使用されます。
  • 言語アナライザー – 言語固有のアナライザーには、ステミング、ストップワード、シノニム (ステミング、ストップワード、シノニムの詳細) を含む、言語ごとの特殊なテキスト処理が含まれています。

アナライザーの操作

インデックスを作成するときにマッピングでフィールドを指定することで、フィールドに使用するアナライザーを設定します。たとえば、以下のマッピングは my_field のアナライザーを whitespace アナライザーに設定します。

PUT scratch_index
{
  "mappings": {
    "my_data": {
      "properties": {
        "my_field": {
          "type": "text",
          "analyzer": "whitespace"
        }
      }
    }
  }
}

注意: Amazon Elasticsearch Service の既存のフィールドでアナライザーを変更することはできません。アナライザーをテストするときは、簡単に削除して再作成できるスクラッチインデックスを使用します。

例

サンプル分析を進めるために、ニューメキシコ州サンタフェ近くの砂漠にソーラーパネルがある IoT のユースケースを想像してみます。電力会社は、米国全土にこのような施設を多数備えており、気温、周辺光、日光などに関するデータを保存しています。このデータは、地域、州、都市、フィールドの地理的な場所ごとに整理されたキー、および各デバイスの 1 時間ごとのファイルと共に、S3 (s3://devices/region/state/city/geo-ip/date-time/device name.txt) に流れます。

電力会社はこのデータから地域、都市、州、場所、およびデバイス名を検索します。また、Kibana を使用して、それらのファイルのタイムスタンプに基づいてファイルの存在の監視も行います。

_analyze API を使用すると、Elasticsearch がどのように文字列を分析するのかを確認できます。standard、simple、whitespace のアナライザーを使用して、文字列「s3://devices/southwest/new-mexico/santa-fe/9wkdvgw781z9/2019-02-08-00/Location-15.txt」を処理しました。たとえば、standard アナライザーの出力を確認するには、以下の呼び出しを使用します。(注意: 場所にはジオハッシュを使用しています—9wkdvgw781z9 は、サンタフェ郊外の場所を指定しています。ジオハッシュの使い方の詳細は、Wikipedia を参照してください。)

GET _analyze
{
  "text": "s3://devices/southwest/new-mexico/santa-fe/9wkdvgw781z9/2019-02-08-00/Location-15.txt",
  "analyzer": "standard"
}

standard、simple、whitespace のアナライザーを使用して上記の URL を分析すると、次の用語が得られます。

これらの結果はそれぞれほぼ正しいですが、完全に正確ではありません。standard アナライザーは、ファイル名を 3 つのトークンに解析し、ハイフンの場所に基づいて都市と州の両方を 2 つの用語に分割します。simple アナライザーは、タイムスタンプを含むすべての数字を削除し、ジオハッシュを数字のない複数のトークンに分割します。whitespace アナライザーは、パス内検索ができない単一のトークンを発行します。それぞれの結果は、少なくとも URL スキーマからの「s3」の一部も保持します。

カスタムアナライザーの定義

前のセクションで示したように、インデックスのマッピングの設定部分でカスタムアナライザーを定義し、それを名前によってフィールドに適用します。カスタムアナライザーを定義するには、以下のコマンドを実行します。

PUT scratch_index
{
  "settings": {
    "analysis": {
      "char_filter": {
        "my_clean": {
          "type": "mapping",
          "mappings": ["/ => \\u0020",
                       "s3: => \\u0020"]
        }
      },
      "tokenizer": {
        "my_tokenizer": {
          "type": "simple_pattern",
          "pattern": "[a-zA-Z0-9\\.\\-]*"
        }
      },
      "analyzer": {
        "s3_path_analyzer": {
          "char_filter": ["my_clean"],
          "tokenizer": "my_tokenizer",
          "filter": ["lowercase"]
        }
      }
    }
  },
  "mappings": {
    "my_data": {
      "properties": {
        "s3_key": {
          "type": "text",
          "analyzer": "s3_path_analyzer"
        }
      }
    }
  }
}

このサンプルリクエストでは、char_filter、tokenizer、およびトークンフィルター (filter) を使用するカスタムアナライザー s3_path_analyzer を定義しています。マッピングは、マッピングプロパティでフィールドを定義し、アナライザーディレクティブを使用して、s3_path_analyzer を単一のフィールド s3_key に適用します。

s3_path_analyzer は、マッピング char_filter を使用して、「s3:」および「/」のインスタンスをスペース (Unicode 32) に置き換えます。単純なパターンマッチングを使用して英数字をグループ化し、ハイフンとピリオドを同じトークンに保持するトークナイザーを使用します。マッチングを向上させるために、小文字フィルターを使用してすべてのトークンを小文字にします。

このアナライザーは、用語 [devices, southwest, new-mexico, santa-fe, 9wkdvgw781z9, 2019-02-08-00, location-15.txt] を生成します。

アナライザーがすべての用語を正しく解析できなかった前の例とは異なり、このカスタムアナライザーは S3 URL を正しく解析して、都市、州、地理的位置、日付、ファイル名に関する用語を生成します。これで、URL のすべてのパス要素に基づいて検索 (および発見) することができます。

結論

今回は、Elasticsearch の分析とアナライザーの上っ面をなでただけです。先ほど説明したカスタムアナライザーは、サンプルデータではうまく機能しますが、すべてのサンプルで必ずしもうまく機能するとは限りません。たとえば、データ内に期間を保持することは、この場合には機能しますが、すべての場合に機能するわけではありません。Elasticsearch で、さまざまなアナライザーを試してみましょう。 マッチングとクエリ結果の関連性が向上します。

著者について

Jon Handler (@_searchgeek) は、カリフォルニア州パロアルトに拠点を置くアマゾン ウェブ サービスのプリンシパルソリューションアーキテクトです。Jon は、CloudSearch および Elasticsearch のチームと緊密に連携し、AWS クラウドへの移行を希望する検索ワークロードを抱えている幅広い顧客に支援と指導を提供しています。AWS に入社する前、Jon はソフトウェア開発者として 4 年間、大規模な e コマース検索エンジンのコーディングに携わっていました。