変換の概要

データを変換するために、次のいずれかの方法を選択できます: ピボット または 最新。

  • すべての変換は、ソースインデックスをそのまま保持します。変換されたデータ専用の新しいインデックスを作成します。
  • 変換には、Kibanaで利用可能なオプションよりも、APIによって提供されるより多くの設定オプションがある場合があります。すべての変換設定オプションについては、APIドキュメントを参照してください。

変換は永続的なタスクであり、クラスタの状態に保存されるため、ノードの障害に対して耐性があります。変換の背後にある仕組みについて詳しくは、チェックポイントの動作および エラーハンドリングを参照してください。

ピボット変換

変換を使用して、データを新しいエンティティ中心のインデックスにピボットすることができます。データを変換して要約することで、代替的で興味深い方法で視覚化および分析することが可能になります。

多くのElasticsearchインデックスは、イベントのストリームとして整理されています: 各イベントは個別のドキュメントであり、たとえば単一のアイテム購入です。変換を使用すると、このデータを要約し、整理された、より分析しやすい形式に持ち込むことができます。たとえば、単一の顧客のすべての購入を要約できます。

変換を使用すると、インデックスを異なる、より消化しやすい形式に変換する特徴のセットであるピボットを定義できます。ピボットの結果は、新しいインデックスにおけるデータの要約です。

ピボットを定義するには、まずデータをグループ化するために使用する1つ以上のフィールドを選択します。カテゴリフィールド（用語）や数値フィールドをグループ化に選択できます。数値フィールドを使用する場合、フィールド値は指定した間隔を使用してバケット化されます。

次のステップは、グループ化されたデータをどのように集約するかを決定することです。集約を使用する場合、実質的にインデックスに関する質問を行います。さまざまなタイプの集約があり、それぞれに目的と出力があります。サポートされている集約とグループ化フィールドについて詳しくは、変換の作成を参照してください。

オプションのステップとして、集約の範囲をさらに制限するためにクエリを追加することもできます。

変換は、ソースインデックスクエリによって定義されたすべてのデータをページネートする複合集約を実行します。集約の出力は宛先インデックスに保存されます。変換がソースインデックスをクエリするたびに、チェックポイントが作成されます。変換を一度だけ実行するか、継続的に実行するかを決定できます。バッチ変換は、単一のチェックポイントを持つ単一の操作です。継続的変換は、新しいソースデータが取り込まれると、チェックポイントを継続的に増分処理します。

たとえば、衣料品を販売するウェブショップを運営しているとします。各注文は、ユニークな注文ID、注文された商品の名前とカテゴリ、価格、注文数量、注文の正確な日付、および顧客情報（名前、性別、場所など）を含むドキュメントを作成します。データセットには、昨年のすべての取引が含まれています。

昨年度の異なるカテゴリの売上を確認したい場合は、データを商品カテゴリ（女性用靴、男性用衣料品など）と注文日でグループ化する変換を定義します。注文日の間隔として昨年を使用します。次に、注文数量の合計集約を追加します。結果は、昨年の各商品カテゴリで販売されたアイテムの数を示すエンティティ中心のインデックスです。

Kibanaにおけるピボット変換のプレビューの例

最新の変換

最新のドキュメントを新しいインデックスにコピーするために、latestタイプの変換を使用できます。データをグループ化するためのユニークキーとして1つ以上のフィールドを特定し、データを時系列でソートする日付フィールドを指定する必要があります。たとえば、このタイプの変換を使用して、各顧客の最新の購入や各ホストの最新のイベントを追跡できます。

Kibanaにおける最新変換のプレビューの例

ピボットの場合と同様に、最新の変換は一度だけ実行するか、継続的に実行することができます。ソースインデックス内のデータに対して複合集約を実行し、出力を宛先インデックスに保存します。変換が継続的に実行される場合、新しいユニークキー値が自動的に宛先インデックスに追加され、既存のキー値の最新のドキュメントが各チェックポイントで自動的に更新されます。

パフォーマンスの考慮事項

変換はソースインデックス上で検索集約を実行し、その結果を宛先インデックスにインデックスします。したがって、変換は集約およびインデックス処理よりも短い時間または少ないリソースを使用することはありません。

変換が大量の履歴データを処理する必要がある場合、最初のチェックポイント中に特に高いリソース使用量があります。

パフォーマンスを向上させるために、検索集約とクエリが最適化されていることを確認し、変換が必要なデータのみを処理していることを確認してください。変換にソースクエリを適用して、処理するデータの範囲を減らすことができるかどうかを検討してください。また、クラスタが複合集約検索とその結果のインデックスをサポートするのに十分なリソースを持っているかどうかも考慮してください。

クラスタへの影響を分散させたい場合（変換が遅くなる代わりに）、検索およびインデックスリクエストを実行する速度を制限できます。docs_per_second制限を設定して、作成または 更新する際に変換を行います。現在のレートを計算したい場合は、変換統計APIを取得から次の情報を使用してください: 

  1. documents_processed / search_time_in_ms * 1000