web-dev-qa-db-ja.com

Kibana、X以上のカウントでフィルタリング

Kibanaを使用して一部の（Elasticsearch）データを視覚化していますが、「カウント」lessが1000（X ）。

「カウント集計」でY軸を使用しています。これは、フィルタリングしたいカウントです。いくつかのオンラインリソースで提案されているように、min_document_countを追加しようとしましたが、何も変わりませんでした。どんな助けでも大歓迎です。

Kibanaの「データ」タブ全体：

Kibana settings

elasticsearchkibana
6
Rick van Lieshout

min_doc_countをorder: ascendingと一緒に使用すると、それ以外の場合とは異なります。

TL; DR：shard_sizeおよび/またはshard_min_doc_countを増やすとうまくいくはずです。

集計が空である理由

ドキュメント で述べられているように：

Min_doc_count基準は、すべてのシャードのローカル用語統計をマージした後にのみ適用されます。

これは、パラメーターsizeおよびmin_doc_countと降順で用語集計を使用すると、Elasticsearchがsizeデータセット内の頻度の低い用語。このリストをフィルタリングして、doc_count> min_doc_countの用語のみを保持します。

例が必要な場合は、次のデータセットを前提としています。

terms | doc_count
----------------
lorem | 3315
ipsum | 2487
olor  | 1484
sit   | 1057
amet  | 875
conse | 684
adip  | 124
elit  | 86

size=3およびmin_doc_count=100を使用して集計を実行すると、Elasticsearchは最初に頻度の低い3つの用語を計算します。

conse: 684
adip : 124
elit : 86

次に、doc_count>100をフィルタリングすると、最終結果は次のようになります。

conse: 684
adip : 124

「amet」（doc_count = 875）がリストに表示されることを期待していても。 Elasticsearchは結果の計算中にこのフィールドを失い、最後にそれを取得できません。

あなたの場合、doc_count <1000の用語が多すぎてリストがいっぱいになり、フィルタリングフェーズの後、結果が得られません。

Elasticsearchがこのように動作するのはなぜですか？

誰もがフィルターを適用して結果を並べ替えたいと考えています。古いデータストアでそれを行うことができ、それは素晴らしいことでした。ただし、Elasticsearchはスケーリングするように設計されているため、以前に使用されていた魔法の一部がデフォルトでオフになっています。

どうして？大規模なデータセットでは壊れてしまうからです。

たとえば、インデックスに800,000の異なる用語があり、データが異なるシャード（デフォルトでは4）に分散され、他のマシン（シャードごとに最大1つのマシン）に分散できるとします。

Doc_count> 1000の用語を要求する場合、各マシンは数十万のカウンターを計算する必要があります（用語の一部が1つのシャードにあり、他のシャードが別のシャードにあるなど、200,000を超える）。また、シャードが結果を1回だけ見たとしても、他のシャードが999回見た可能性があるため、結果をマージする前に情報を削除することはできません。したがって、ネットワークを介して100万を超えるカウンターを送信する必要があります。したがって、特に頻繁に行われる場合は、かなり重いです。

したがって、デフォルトでは、Elasticsearchは次のようになります。

  1. 各シャードの各項についてdoc_countを計算します。
  2. シャードのdoc_countにフィルターを適用しない（速度とリソース使用量の点では損失がありますが、精度は向上します）：いいえshard_min_doc_count。
  3. size * 1.5 + 10（shard_size）用語をノードに送信します。順序が昇順の場合は頻度の低い用語になり、そうでない場合は頻度の高い用語になります。
  4. このノードのカウンターをマージします。
  5. min_doc_countフィルターを適用します。
  6. sizeの頻度が最も高い/低い結果を返します。

一度は簡単でしょうか？

はい、確かに、この動作はデフォルトであると言いました。巨大なデータセットがない場合は、それらのパラメーターを調整できます:)

解決

あなたがそうでない場合精度がいくらか失われてOK：

  • shard_sizeパラメーターを[your number of terms with a doc_count below your threshold] + [the number of values you want if you want exact results]より大きくします。

    doc_count>=1000ですべての結果が必要な場合は、フィールドのカーディナリティ（異なる用語の数）に設定しますが、order: ascendingのポイントがわかりません。

    用語が多い場合はメモリに大きな影響があり、ESノードが複数ある場合はネットワークに大きな影響があります。

areOKの場合、精度が多少低下します（多くの場合マイナー）

  • この合計とshard_sizeの間に[the number of values you want if you want exact results]を設定します。より高速にしたい場合、または正確な計算を実行するのに十分なRAMがない場合に役立ちます。これの適切な値は、データセットによって異なります。

  • 用語集計の shard_min_doc_countパラメーター を使用して、頻度の低い値を部分的に事前フィルター処理します。これは、データをフィルタリングするための効率的な方法です。特に、データがシャード間でランダムに分散されている場合（デフォルト）や、シャードが少ない場合はなおさらです。

データを1つのシャードに入れることもできます。精度の面で損失はありませんが、パフォーマンスとスケーリングに悪影響を及ぼします。ただし、データセットが小さい場合は、ESの全機能を必要としない場合があります。

NB：用語集計の降順は非推奨です（正確には時間とハードウェアの点で多くの費用がかかるため）、おそらく削除されます将来は。

PS：Kibanaによって生成されたElasticsearchリクエストを追加する必要があります。これは、Kibanaがデータを返しているが、必要なデータを返さない場合に便利です。スクリーンショットのグラフの下にあるはずの矢印をクリックすると、[リクエスト]タブに表示されます（例： http://imgur.com/a/dMCWE ）。

7
Pandawan