Elastic : Problème avec format décimal à l'indexation (document non indexé)

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

Je vous expose ici un souci rencontré chez nos environnement avec l'indexation d'une ligne dans Elasticsearch qui ne se fait pas dès que la valeur décimale contenue dans la clé dépasse 64 ( effet de bord d'un connecteur en base 64?).

Contexte: réplication des donnée d'un DB2 Z/os vers un Kafka (confluent) et indexation dans un Elasticsearch 7.6.2 via un connecteur (Kafka connect confluent).

Données: ligne contenant une clé composée de:

  • 1 colonne format CHAR
  • 1 colonne format décimal
  • 1 colonne format CHAR

Exemple:

PAUL 1 DUBOIS ADRESSE1 BOULANGER
PAUL 2 DUBOIS ADRESSE2 BOUCHER
PAUL 3 DUBOIS ADRESSE2 PLOMBIER
.../...
PAUL 65 DUBOIS ADRESSE65 MENUISIER

Tentative d'insertion de plus de 64 lignes avec clé identique sauf la colonne décimale.

Description du problème: à partir de la 64è ligne on ne retrouve plus l'enregistrement dans Elasticsearch.
Les lignes > à 64 sont pourtant bien extraits (via change data capture) de la base DB2 Z/os, bien écrite dans le topic Kafka (vérifié) mais on ne les retrouve pas dans Elasticsearch après indexation via Kafka connect.

Le problème se produit donc dans la chaine à l'indexation. Le connecteur Kafka n'affiche aucun rejet ou warning.
Elasticsearch n'est pas non plus parlant.

Test fait plusieurs fois avec enregistrements différents mais avec toujours col1 et col3 de la clé identiques et col2 incrémentée (1,2,3,4 etc..jusque plus de 64).

Remarque:
La clé fonctionnelle utilisée dans la définition du connecteur est celle indiquée au dessus.
Mais l'ID interne généré par Elasticsearch sert malgré tout de clé technique.
Est ce que cela est la source du problème?
Si oui comment la contourner?

D'autres avis?
Merci pour votre aide.

2

Peux-tu tu donner un exemple complet du document json qui est rejeté et du message d'erreur ?

Ou de l'ID exact qui ne "passe" pas ?

3

Comme dit dans ma description du souci je n'ai pas de message d'erreur dans la chaine.
J'en ai déduit ce comportement via des tests multiples.
Le doc contient des données personnelles jen e peut donc pas le publier complètement.
Néanmoins voilà les éléments que je peux poster (j'ai ajouté .../... pour ignorer des colonnes et changer un nom en TOTO).

=> Sur la sources j'ai 78 lignes (en gras la clé dont la colonne décimale):

000078 **0679008906**                 **78**  MD             N           .../...**TOTO**           
****** **************************** BOTTOM OF DATA ************************

=> Après réplication les 75è/76è/77/è et 78è lignes se retrouvent dans le topic Kafka (format AVRO):
Lignes 75/76/77/78:

^@^@^@^D^@^T0679008906<96>^A^DMD^BN^^ .../...TOTO
^@^@^@^D^@^T0679008906<98>^A^DMD^BN^^.../...TOTO
^@^@^@^D^@^T0679008906<9a>^A^DMD^BN^^.../...TOTO
^@^@^@^D^@^T0679008906<9c>^A^DMD^BN^^.../...TOTO

=> Et dans Elasticsearch on ne retrouve d'indexées que les 64 1eres lignes + la dernière, donc en tout 65:

image

L'ID Elasticsearch (contenant la clé) du 63eme document indexé:

"_type": "_doc",
"_id": "\u0000\u0000\u0000\u0004\u0004\u00140679008906n@TOTO

L'ID Elasticsearch (contenant la clé) du 64eme document indexé:

"_type": "_doc",
"_id": "\u0000\u0000\u0000\u0004\u0004\u00140679008906p@TOTO

L'iD Elasticsearch (contenant la clé) du 65è (et dernier ) document indexé:

"_type": "_doc",
"_id": "\u0000\u0000\u0000\u0004\u0004\u00140679008906�\u0001@TOTO

En résumé:

En source on a 78 lignes avec la même clé si ce n'est le champs décimal.
Sur Kafka on retrouve les 78 enregistrements.
Dans Elasticsearch on retrouve les 64 1er enregistrements + le 78è ce qui en fait 65.

Structure de la clé Col1 = char Col2 = décimal Col3 = char

Merci.

4

Ne peux-tu pas changer l_id? Certains caractères ne sont probablement pas supportés (� est un exemple) et avoir un _id aussi long, a t'il un sens?

Je ne connais pas le connecteur Kafka mais je n'ai pas l'impression qu'il donne cette flexibilité.

Peut-être as-tu un problème d'encoding. Elasticsearch ne parle que UTF8. Si Kafka envoie autre chose (� semble indiquer un caractère non UTF8), il est possible que ce soit rejeté par Elasticsearch. Tu devrais voir ça dans les logs Kafka.

Ne pourrais-tu pas utiliser à la place ceci ?

Ca permet de lire du Kafka et d'indexer dans Elasticsearch.

5

La seule partie de l'ID sur laquelle j'ai la main (via le kafka connect) dans notre use case est la partie clé fonctionnelle, donc les 3 colonnes. Le reste c'est Elastic qui le génère.
Cette clé fonctionnelle permet de gérer les insert/update/delete et nous est obligatioire.
Le connecteur Kafka permet la flexibilité sur la clé dite "fonctionnelle" mais elasticsearch utilisé également en interne sa propre clé technique pour éviter les doublons.

Je ne vois rien justement dans les logs Kafka ce qui me poussait à dire que c'est plutôt côté Elastic que cela pêche.

Sais tu où je pourrais voir ce type de rejet si c'est côté Elasticsearch un endroit où je n'aurais pas regardé?
Le ( � est la partie décimale de la clé fonctionnelle (qui est simplement un nombre à 2 chiffres).
Si je modifie le format sur la source de la colonne décimale en char je n'ai plus le souci mais malheureusement fonctionnellement cela n'est pas envisageable.

Filebeat et d'autre solutions ne répondent pas au besoin (je ne m'étale pas mais le sujet a été travaillé chez de manière très poussée).
Pour le problème d'encoding c'est une piste que j'ai envisagé. Mais pourquoi toutes les lignes à partir de 64+1 ne sont pas indexées sauf la dernière? Bizarre comme comportement.

Merci.

6

J'ajoute test fait à l'instant:

Suppression des 14 1eres lignes sur la source afin de n'en garder que 64 mais avec les colonnes décimales supérieures à 64.
Résultat sur Elasticsearch seulement 51 lignes d'indexées.
Cela confirme que le format décimal pose problème dès lors que l'on doit indexer des chiffres supérieures à 64.
De mémoire le connecteur Kafka utilisé est en base 64 je me demande toujours si ce n'est pas lié.

A priori d'après mes recherches du jour un souci de conversion du format AVRO (kafka connect) avec le décimal (base64) qui entraine du loss data.

7

Je ne comprends pas ce dont tu parles avec cette histoire de décimale.
Je n'arrive pas à comprendre si ton problème est un problème d'_id de document ou de contenu de document.

Serait-il possible d'abstraire la partie Kafka du problème pour le moment et de se focaliser sur Elasticsearch seulement ?

Donc, peux-tu fournir :

  • Le mapping elasticsearch
  • Un document au format JSON qui est probablement envoyé par Kafka vers Elasticsearch

Sans cela, j'ai peur de ne toujours pas comprendre et donc de ne pas pouvoir aider.

9

Pour plus de clareté j'ai simplifié les données en source.
A présent une table DB2 Z/os avec 2 colonnes: COL1 (char 10) COL2 (decimal(2,0)
Col1 est toujours identique
Col2 incrémentée de 1 à 78 donc unique.
=> Voici le mapping de l'index, on peut y constater que le problème a lieu côté elasticsearch pendant la phase d'indexation.
Sur les 78 documents envoyés depuis Kafka, 14 sont delete.

{
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"stats": {
"uuid": "ru3lry_RQs-TjHICHYTqgg",
"primaries": {
"docs": {
"count": 64,
"deleted": 14
},
"store": {
"size_in_bytes": 15604
},
"indexing": {
"index_total": 78,
"index_time_in_millis": 17,
"index_current": 0,
"index_failed": 0,
"delete_total": 0,
"delete_time_in_millis": 0,
"delete_current": 0,
"noop_update_total": 0,
"is_throttled": false,
"throttle_time_in_millis": 0
},
"get": {
"total": 78,
"time_in_millis": 17,
"exists_total": 14,
"exists_time_in_millis": 17,
"missing_total": 64,
"missing_time_in_millis": 0,
"current": 0
}

=> Voici le document JSON (le doc avec COL2 incrémenté de 1 à 64 est bien indexé et de 65 à 78 sont en delete, rien de particulier sur le motif de delete dans la log elasticsearch):
{
"_index": "tabels_elsx_01",
"_type": "_doc",
"_id": "\u0000\u0000\u0000\u0000\u000b\u00140679008906\u0002",
"_version": 1,
"_score": 0,
"_source": {
"COL1": "0679008906",
"COL2": 1
}
}

COL1:

0679008906

COL2:

1

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

3

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

7

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

8

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

10

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

11

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

15

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

18

_id:

0679008906$

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

19

_id:

0679008906&

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

21

_id:

0679008906*

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

23

_id:

0679008906.

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

25

_id:

06790089062

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

26

_id:

06790089064

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

27

_id:

06790089066

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

30

_id:

0679008906<

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

31

_id:

0679008906>

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

35

_id:

0679008906F

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

37

_id:

0679008906J

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

39

_id:

0679008906N

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

41

_id:

0679008906R

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

42

_id:

0679008906T

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

44

_id:

0679008906X

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

46

_id:

0679008906\

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

47

_id:

0679008906^

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

48

_id:

0679008906`

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

51

_id:

0679008906f

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

52

_id:

0679008906h

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

53

_id:

0679008906j

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

60

_id:

0679008906x

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

61

_id:

0679008906z

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

62

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

63

_id:

0679008906~

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

78

_id:

0679008906�

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

2

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

4

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

5

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

6

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

9

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

12

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

13

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

14

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

16

_id:

0679008906

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

17

_id:

0679008906"

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

20

_id:

0679008906(

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

22

_id:

0679008906,

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

24

_id:

06790089060

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

28

_id:

06790089068

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

29

_id:

0679008906:

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

32

_id:

0679008906@

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

33

_id:

0679008906B

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

34

_id:

0679008906D

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

36

_id:

0679008906H

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

38

_id:

0679008906L

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

40

_id:

0679008906P

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

43

_id:

0679008906V

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

45

_id:

0679008906Z

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

49

_id:

0679008906b

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

50

_id:

0679008906d

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

54

_id:

0679008906l

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

55

_id:

0679008906n

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

56

_id:

0679008906p

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

57

_id:

0679008906r

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

58

_id:

0679008906t

_type:

_doc

_index:

tabels_elsx_01

_score:

0
COL1:

0679008906

COL2:

59

_id:

0679008906v

_type:

_doc

_index:

tabels_elsx_01

_score:

0

10

Peux-tu formater correctement le code, les examples, etc? Pour que ce soit plus facilement lisible. Merci. A lire.

Ca veut dire que 14 documents ont le même _id.

Peux-tu faire la liste ici des 14 documents qui manquent? Juste leur _id suffira.
Et trouver quels sont les documents mis à jour?

Si tu fais:

GET INDEX/_doc/ID

Ca te donnera dans la réponse le champ _version. Donne la liste de ceux dont la version est 2.

11

Je confirme il s'agit bien de doublons au delà de la 64è valeur décimale.
Après quelques recherches Il s'agit d'un problème côté connecteur Kafka non solutionné à ce jour.

Merci en tout cas pour le temps passé David.

12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.