Cardinalité sur histogramme de date

Les identifiants des utilisateurs sont répétés mais ils se produisent à des jours différents, donc les distribuer par jours fera que cela se produira plus d'une fois, sauf si vous regardez un jour spécifique. Même dans ce cas, si le même identifiant se produit le même jour plus d'une fois, vous pouvez toujours avoir des identifiants en double en fonction de la précision de la période que vous regardez. Puisque vous regardez à des intervalles d'un jour, il est correct qu'il renvoie 5 enregistrements et devrait dire que le 4, il y avait 3 identifiants dont l'un est le double et le jour suivant montre deux enregistrements avec deux identifiants différents dont l'un est le double. Si vous augmentez l'intervalle à une semaine ou un mois, ces doublons seront comptés pour un.

Je suis sûr que vous avez rencontré cela, mais donnez-lui un autre regard car il explique votre cas d'utilisation exact. Lien

En gros, il renvoie tous les visiteurs uniques d'un jour donné. Si vous ne vous souciez pas des utilisateurs individuels mais que vous voulez simplement savoir combien, vous avez besoin d'une approche différente. Peut-être un groupe par requête

Nous avons rencontré le même problème dans notre code et notre solution consistait à utiliser une agrégation de termes sur le champ UserId avec une agrégation min imbriquée dans le champ datetime. Cela vous fournit un bucket pour chaque userId contenant le bucket lors de la première visite. Nous faisons cette agrégation en dehors de l'histogramme des dates et la mappons manuellement par la suite.

"aggs": {
    "UniqueUsers": {
      "terms": {
        "field": "userId",
        "size": 1000,
      }, "aggs": {
        "FirstSeen": {
          "min": {
            "field": "date"
          }
        }
      }
    }
  }

Cela fonctionne pour nous, mais je suis sûr qu'il devrait y avoir une meilleure implémentation.

Même si je souhaite éviter les scripts, L'agrégation de métriques par script semble être le seul moyen d'accomplir ce qui a été demandé:

"aggregations": {
    "visitors": {
        "value": {
            "2019-03-04T13:40:18.514Z": 1,
            "2019-03-04T13:46:18.514Z": 1,
            "2019-03-04T13:50:18.514Z": 1,
            "2019-03-05T13:46:18.514Z": 1
        }
    }
}

Init crée simplement un HashMap vide, la carte remplit cette carte avec userId comme clé et définit le plus ancien eventDate comme valeur, et Combine déballe simplement la carte à passer à Reduce:

def dateMap = new HashMap();
for (map in params._aggs) {
    if (map == null) continue;
    for (entry in map.entrySet())
        dateMap.merge(entry.key, entry.value, (e1, e2) -> e1.isBefore(e2) ? e1 : e2);
}

def hist = new TreeMap();
for (entry in dateMap.entrySet())
    hist.merge(entry.value.toString(), 1, (a, b) -> a + 1);
return hist;

Up to Combine le code a été exécuté pour chaque cluster node, Reduce fusionne toutes les cartes en une seule (c'est-à-dire dateMap) en préservant le plus ancien eventDate par userId. Ensuite, il compte les occurrences de chaque eventDate.

Le résultat est:

{
    "size": 0,
    "aggs": {
        "visitors": {
            "scripted_metric": {
                "init_script": "params._agg.dateMap = new HashMap();",
                "map_script": "params._agg.dateMap.merge(doc.userId[0].toString(), doc.eventDate.value, (e1, e2) -> e1.isBefore(e2) ? e1 : e2);",
                "combine_script": "return params._agg.dateMap;",
                "reduce_script": "def dateMap = new HashMap(); for (map in params._aggs) { if (map == null) continue; for (entry in map.entrySet()) dateMap.merge(entry.key, entry.value, (e1, e2) -> e1.isBefore(e2) ? e1 : e2); } def hist = new TreeMap(); for (entry in dateMap.entrySet()) hist.merge(entry.value.toString(), 1, (a, b) -> a + 1); return hist;"
            }
        }
    }
}

La seule partie manquante est que ces valeurs doivent être regroupées dans un histogramme sur le code de l'application.

Remarque¹: Utilisez à vos risques et périls , je ne sais pas si la consommation de mémoire augmente beaucoup à cause de ces cartes de hachage ou de ses performances sur de grands ensembles de données.

Remarque²: à partir d'Elasticsearch 6.4, state et states doivent être utilisés à la place des paramètres params._agg et ._aggs .