Optimisation : liste de regex dynamique

Version imprimable

Bonjour,

Nous avons des besoins d'analyse de fichiers (texte, des logs en fait) évolutif.
Suivant les besoins, il nous faut donc y chercher tel ou tel valeur à tel ou tel emplacement.
J'ai fait rapidement (... contrainte immédiate ^^) un petit script python qui va analyser les fichiers présents (je zappe les spécifications sur ce point, pas d'importance ici) et récupérer 3 ou 4 groupes (enregistrés dans un fichier texte ou une bdd).

Afin qu'il soit facilement utilisable et adaptable, la regex est configuré via un fichier .ini (par lot/type/source de fichiers).

Le script va donc récupérer la liste de fichier suivant le paramétrage et pour chaque va vérifier le pattern souhaité ligne par ligne en récupérant le cas échéant les données. Jusque là, tout va bien.
Seulement, nous pouvons avoir plusieurs recherches nécessaire. Avec des milliers de fichiers (voir plus!), faire plusieurs passes est hors de question!
Le fichier de configuration permet donc d'indiquer plusieurs regex (avec un nombre de groupe de capture variable suivant le besoin).

Côté script, pour chaque ligne je compile le Regex de chaque groupe de configuration présent et traire avec celui-ci.
Sauf que...
J'ai testé avec une regex, puis deux, et le temps de traitement double! Oui, j'ai deux regex, mais le parcours des fichiers hors traitement regex me semblait plus conséquent dans le temps global de traitement.
D'ailleurs, une première version non dymanique avait les deux regex dans le script. Et pour chaque ligne, je traitais celles-ci. Seules différences : elles étaient compilées hors boucle de lecture (et inscrite dans le python au lieu du fichier de conf). Côté résultat... moitié moins de temps (peu de différence qu'on ai une ou deux regex en fait).

Bref :
- pourquoi est-ce si lourd? L'opération "re.compile" est-elle si lourde en temps (je ne vois que ça comme explication)?
- auriez-vous des suggestions d'amélioration? Concaténer (|) les regex? Les compiler hors boucle? A votre avis, quelle est l'option la plus efficace? Sachant qu'il faudra que je gère le titre de la recherche (un par regex).

Le code actuel :
Code:

1 2 3 4 5 6 7 8 9 10 for file in list_files: for line in open(file): for groupe in config.sections(): pattern = config[groupe]['Regex'] pattern = re.compile(pattern) titre = config[groupe]['Nom'] for match in re.finditer(pattern, line): with open(logfile, 'a') as f: f.write('{};{};{};{}\n'.format(titre,match.group('Source'),match.group('Date'),match.group('Valeur'),match.group('Valeur2'))) f.closed
Exemple de regex :
Code:

1 2 3 4 5 6 7 [GROUP1] Regex=(?P<Source>\d{5})\s*\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}.*NumSerie\s(?P<Valeur>\d{5})(?P<Date>) Nom=SN [GROUP2] Regex=(?P<Source>\d{5})\s*(?P<Date>\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}).*Reboot.* Nouvelle valeur =(?P<Valeur>ERR|INC|NOK) Nom=Erreur démarrage
Je ne suis pas encore bloqué et vais continuer mes tests.
Mais si vous avez des conseils avisés, ça m'évitera de passer du temps sur un mauvais choix!
Merci!

PS : Bon, en relisant au calme, je devrais réfléchir à l'intérêt du compile si je le relance à chaque boucle...
Du coup, je penses partir sur une liste créé au départ selon la configuration, et parcourue à chaque analyse de ligne. Si ce n'est pas la meilleure solution, merci pour vos retours sinon je poursuis dans cette voie.

Salut,

Et si tu compiles une seule fois avant la boucle, ça change les performances ?

Code:

1
2
3
4
5
6
7
8
 
patterns = []
for groupe in config.sections():
    patterns.append(re.compile(config[groupe]['Regex']))
for file in list_files:  
    for line in open(file):
        for pat in patterns:
        ....

25/01/2016, 13h56
Shampra
N'étant pas un expert et de loin, je craignais être en train de faire un truc lourd et inefficient au possible en passant à côté de la bonne pratique / bonne méthode pour ce genre de traitement ;-).

Sinon, j'ai fait tourner :
- avec le code ci-dessous, compile des regex à chaque ligne (et regex)
- en supprimant le compile (qui si je ne me trompes sert uniquement à stocker dans un objet pour réutiliser... le recompiler à chaque ligne, pas d'intérêt je supposes.
- avec ta solution VinsS, je compile tout avant

Compile par ligne = 76s (bouh!)
Sans compile = 65s (mieux, mais encore pas top)
Compile avant la boucle = 35s...
Du coup, je crois que le choix est tout fait! Il me reste à intégrer les titres (à sortir et différent suivant le pattern) mais au moins j'ai l'axe à suivre, merci bien!

Pour mon propre apprentissage et d'après ce constat, compiler une regex permet donc de gagner en temps de traitement à chaque appel?

Autre question : y a-t-il un "format" autre qu'une liste pour chercher selon plusieurs regex possibles (avec groupes)?
C'était une solution que j'avais en tête.
J'ai testé :
Code:

1 2 3 (?P<Date>\d{4}-\d{2}-\d{2})|(?P<Date>\d{2}-\d{2}-\d{4}) ou (?:(?P<Date>\d{4}-\d{2}-\d{2}))|(?:(?P<Date>\d{2}-\d{2}-\d{4}))
qui, je l'espérait, me récupérerait la capture "date" dans les formats 25-01-2016 ou 2016-01-06, mais ce n'est pas le cas. Apparemment, avoir un groupe nommé pareil en deux endroits, même si c'est dans un "OU", ça ne passe pas.
(bien sûr, ce n'est qu'un exemple je pourrait faire (?P<Date>(?:\d{4}-\d{2}-\d{2})|(?:\d{2}-\d{2}-\d{4})) ici mais avec des regex complète comme mon post initial les éléments variants ne sont pas dans les groupes nommés eux-mêmes)
25/01/2016, 14h11
wiztricks

Salut,

Citation:

Envoyé par Shampra

Bref :
- pourquoi est-ce si lourd? L'opération "re.compile" est-elle si lourde en temps (je ne vois que ça comme explication)?
- auriez-vous des suggestions d'amélioration? Concaténer (|) les regex? Les compiler hors boucle? A votre avis, quelle est l'option la plus efficace? Sachant qu'il faudra que je gère le titre de la recherche (un par regex).

Un pouième de seconde multiplié par 1000 ou 10000 çà fait des secondes et/ou des minutes.
Hormi la remarque de VinsS, rien que le "with open(logfile, 'a') as f" à chaque itération coûte sans rien apporter.

Après il faut voir à quoi ressemblent vos lignes mais "re.finditer(pattern, line)" suppose que vous allez trouver le pattern plusieurs fois... alors qu'une ligne ressemblera plutôt soit au premier soit au second. De plus les 2 patterns semblent commencer par la même séquence: pourquoi refaire le boulot?

- W
25/01/2016, 14h31
Shampra

Le openfile à chaque itération était pour éviter de le laisser ouvert en cas de problème (ex : quand un fichier illisible se glisse dans la liste, j'ai eu le cas).
Est-ce réellement utile, à voir effectivement. Je l'ai fait pour faire "au mieux". Côté consommation, en ne l'ouvrant qu'une fois je gagne 5s sur mon lot de référence (15% quand même).

Pour le pattern, il ne démarre pas toujours pareil, je ne peux cumuler les deux regex (ou n'est pas trouvé comment, la chaine complète pouvant être différente et devant contenir plusieurs groupes de capture, voir réponse plus haut).
De même une ligne pourrait répondre à plusieurs pattern (mais ça, je peux le régler en jouant sur les groupes de captures pour limiter les regex tout en répondant aux demandes qui me sont faites). Je note au cas où...
Par contre un seul résultat par pattern puisque traitement par ligne, re.search serait préférable peut-être? Testé à l'instant, pas de différence de temps de traitement

D'ailleurs : est-ce préférable (point de vue qualité du code, efficience,...) de faire un finditer sur un fichier complet ou un search par ligne?

Merci pour les remarques!
Je pose beaucoup de questions pour bien comprendre tout ce qui entoure la question initiale (résolue sinon, je vais la passer) et apprécie vos réponses!
25/01/2016, 16h41
BufferBob

salut,

Citation:

Envoyé par Shampra

Pour mon propre apprentissage et d'après ce constat, compiler une regex permet donc de gagner en temps de traitement à chaque appel?

oui, c'est même à ça que sert la fonction en fait
"using re.compile() and saving the resulting regular expression object for reuse is more efficient when the expression will be used several times in a single program."

Citation:

je pourrait faire (?P<Date>(?:\d{4}-\d{2}-\d{2})|(?:\d{2}-\d{2}-\d{4})) ici mais avec des regex complète comme mon post initial les éléments variants ne sont pas dans les groupes nommés eux-mêmes)

je ne vois pas ce que tu veux dire ici, si tu n'as que le champ Date la regex remplit sa fonction, les regex que tu donnes dans ton premier post ne semblent pas plus compliquées (ou alors j'ai loupé un truc)

quant au fait d'ouvrir/fermer le fichier à chaque itération ça génére des i/o, par nature lourdes et plombantes en terme de perfs
on pourra faire aussi attention à l'utilisation du greedy operator .* qui peut souvent être remplacé par un opérateur non-gourmand .*?, selon la distance entre les deux champs à matcher de chaque côté du .* et le nombre de fois qu'on répète la regex, ça peut possiblement économiser quelques cycles
25/01/2016, 18h24
CosmoKnacki

Normalement un fichier log est (devrait être) quelque chose de plutôt calibré, et l'utilisation de regex pour le parser devrait être minimaliste, voire inutile. C'est pour cela qu'il serait bon que tu postes un ou plusieurs extraits significatifs de tes logs pour que l'on puisse voir le bien fondé de l'utilisation des regex.

Ok pour l'ouverture du fichier, je ne l'ouvre plus qu'une seule fois :).
Pour le "greedy operator", merci du conseil, je vais regarder ça (même si dans mon cas le gain sera trop minime, toujours bien de connaitre les bonnes pratiques).

@CosmoKnacki Malheureusement non. Ou plus un type de "log" est calibré, j'en ai environ 40 (plusieurs systèmes différents, qui envois des fichiers de plusieurs types différents; certains sont bien calibrés comme ceux que je traite avec ces regex, d'autres beaucoup moins, d'autres sont en xml, etc...). Comme suivant la situation on peut avoir besoin de récupérer des informations dans l'un ou l'autre de ces fichiers, j'ai opté pour une regex mis en fichier de configuration, ça marche pour quasiment tous.
Par contre, parser sans regex? Par curiosité, peux tu m'indiquer comment (ou pointer vers un article sur ça... j'ai regardé via google, les parsers regardés utilisent des regex).

@BufferBob Comme dit, la date n'est là que pour illustrer plus succinctement.
Pour reprendre la question avec un exemple réel...
J'ai des fichiers textes (très bien calibré ceux-là), contenant entre autres lignes :
Code:

1 2 3 4 5 6 7 8 ... 00001 2016-01-19 08:39:25 D ACTIVITE Configuration Service - Stat =80% Lancement =Auto NumSerie = 12345 ... 00001 2016-01-19 08:39:25 D Reboot Modification du service - Ancienne Valeur =NOK Nouvelle valeur =ERR ... 00001 2016-01-19 08:39:25 D Reboot Modification du service - Ancienne Valeur =ERR Nouvelle valeur =NOK ...
Ceux-là sont bien calibrés, d'autres n'ont pas de date ou pas de formalisme du tout...

Suite à une demande, je dois les traiter pour récupérer les valeurs et les enregistrer dans un même endroit.
Selon les fichiers ou les besoins, les valeurs à récupérer peuvent différer ou avoir un ordre différent dans le texte
Par exemple :
Code:

1 2 3 0001 Erreur critique sur le module 12345 Test reboot - Module 12345
Solution que j'ai choisie : nommer les groupes à récupérer, avec au moins DATE, SOURCE, VALEUR
Si pas de groupe date, on met un groupe vide en fin de regex. Si plus de 3 groupes à récupérer, le suivant sera par id (et devra être en fin de chaine, mais ça conviendra).

Regex faites :
Code:

1 2 3 4 5 Regex=(?P<Source>\d{5})\s*\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}.*NumSerie\s(?P<Valeur>\d{5})(?P<Date>) Nom=SN [GROUP2] Regex=(?P<Source>\d{5})\s*(?P<Date>\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}).*Reboot.* Nouvelle valeur =(?P<Valeur>ERR|INC|NOK)
...
Voilà l'exemple réel ;-).
Donc la question : y a-t-il une méthode pour combiner (avec un "OU") ces deux regex, en gardant les champs nommés? Juste pour éviter de traiter chaque lignes une fois pour chaque regex.
Comme dit, j'ai tenté :

Code:

(?:(?P<Source>\d{5})\s*\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}.*NumSerie\s(?P<Valeur>\d{5})(?P<Date>))|(?:(?P<Source>\d{5})\s*(?P<Date>\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}).*Reboot.* Nouvelle valeur =(?P<Valeur>ERR|INC|NOK))

... qui est refusé car j'ai deux groupes de capture avec le même nom.

Et non : faire une seule regex commune est difficilement envisageable. J'en ai déjà 4 actives, trouver la regex qui réponde à tout va vite devenir une activité à part entière surtout sur des fichiers moins bien formaté!

26/01/2016, 10h26
BufferBob

en clair ce que tu veux c'est avoir une unique regex qui puisse faire une capture de groupes nommés dans un ordre ou dans un autre (ce qui oblige à définir plusieurs fois l'étiquette des groupes), quelque chose comme ça finalement (?<Jour>\d{2})-(?<Mois>\d{2})-(?<Annee>\d{4})|(?<Annee>\d{4})-(?<Mois>\d{2})-(?<Jour>\d{2})

la réponse est non, c'est le moteur d'expressions régulières utilisé par Python qui ne le permet pas^*

extrait de http://www.regular-expressions.info/named.html :

Citation:

Python (...) do not allow multiple groups to use the same name. Doing so will give a regex compilation error.

quant à parser sans regex, c'est sous-entendu à coups de split, de slices etc. qu'on considère comme des traitements quasi-atomiques par rapport au fait de mettre en branle le moteur de regex, mais ledit moteur est quand même très optimisé, on considérait les regex comme des traitements un poil lourds il y a 10 ou 15 ans, je pense pas que ce soit encore à l'ordre du jour

^* sous-entendu d'autres moteurs le permettent, éventuellement disponible à travers Python moyennant l'installation du package qui va bien etc. mais est-ce pertinent dans ton cas ?
26/01/2016, 13h18
Shampra

Dommage.
Mais ça reste rapide même en traitant plusieurs fois chaque ligne alors en effet inutile de voir plus loin dans mon cas.

Merci pour vos réponse!

Citation:

Par contre, parser sans regex?

Oui, par exemple pour les trois lignes de ton log (d'après ce qu'elles révèlent ce sont des champs séparés par des tabulations) tu peux écrire ça:
Code:

1 2 3 4 5 6 7 8 from collections import deque results = deque() with open('logus.log') as f: for line in f: parts = line.split("\t") results.append(dict({'source':parts[0], 'date':parts[1], 'value':parts[4].split('=')[-1].strip()}))
Bien sûr, c'est un code très basique, je n'ai pas tous les éléments pour faire le code qui traitera parfaitement toutes les lignes (et une regex tout aussi basique pourrait faire la même chose). Mais c'est rapide et facile à modifier (tu peux aisément ajouter des tests, changer le format de la date si ça te chante..., regarde attentivement les deux derniers champs, la valeur du premier doit sûrement conditionner le format du deuxième) sans te heurter aux contraintes d'une pattern. Dans tous les cas ça reste bien meilleur que de tester x patterns jusqu'à trouver la bonne pour chaque ligne.

En ce qui concerne les divers formats propres à chaque type de fichier log, prend bien le temps regarder comment ils sont fichus: s'agit il de champs séparés par un délimiteur quelconque (dans ce cas commence par séparer les champs, voire utilise un module csv)? S'agit il de xml (parser xml)? N'existe t-il pas déjà un parseur pour tel ou tel format de log. Car le mieux est de s'appuyer au maximum sur la structure employée avant de partir à l'aventure avec une pattern.

Ça n'exclut pas d'utiliser des regex, pour par exemple faire des extractions d'informations dans un champ quand les manipulations basiques ne suffisent plus, mais ne cherche pas à décrire toutes lignes entières possibles avec, car c'est dans ces cas là que la lourdeur des regex se fait sentir (quand tu te retrouves avec des alternatives, des tests avant, arrière, des .* ou des .*? à n'en plus finir), et si tu dois traiter de gros volumes, cela n'aura rien d'anodin.

Citation:

on considérait les regex comme des traitements un poil lourds il y a 10 ou 15 ans, je pense pas que ce soit encore à l'ordre du jour

Oh bah oui ma bonne dame. Désolé, je ne suis pas archéologue.

Plaisanterie mise à part, je ne pense pas que les fées se soient particulièrement penchées sur le module re du point de vue optimisation (ce n'est ni Perl, ni PCRE de ce point de vue la, et je pense que le coût passe plus inaperçu du fait de l'amélioration des machines), je crois que sa grande force ce sont surtout ses méthodes qui sont particulièrement pratiques (notamment finditer, ma petite préférée). Mais ce n'est pas pour rien que les gens se tournent de plus en plus vers le module regex (pas pour ses performances du coup, mais pour ses features à la pointe) ou vers le module re2 pour les performances.

26/01/2016, 19h21
BufferBob

Citation:

Envoyé par CosmoKnacki

ça reste bien meilleur que de tester x patterns jusqu'à trouver la bonne pour chaque ligne.

je crois que tu te méprends, si le pattern ^toto (?:(?\\x[a-z0-9]{2}){4}|(?\\x[a-z0-9]{2}){8}) cherche à matcher sur "coincoin", la première lettre échoue, le moteur regex rend la main, le reste de la regex ne sera pas évalué, c'est aussi instantané que de tester "coincoin"[0] == "t", la lenteur des regex vient plus souvent des expressions malhabiles ou approximatives faites par des gens qui ne veulent pas s’embêter avec des considérations comme .* VS .*? par exemple, plutôt que du moteur en lui même

Citation:

Envoyé par CosmoKnacki

Oh bah oui ma bonne dame. Désolé, je ne suis pas archéologue.

y'a pas d'mal, ça reste bon esprit.

Citation:

Envoyé par CosmoKnacki

je pense que le coût passe plus inaperçu du fait de l'amélioration des machines

oui complètement, de fait il y a 15 ans on avait pas les mêmes machines qu'aujourd'hui si tu y réfléchis, on est passé du simple core à 600MHz à l'octocore à +3GHz, ceci expliquant peut-être cela

Citation:

Envoyé par CosmoKnacki

les gens se tournent de plus en plus vers le module regex (pas pour ses performances du coup, mais pour ses features à la pointe) ou vers le module re2 pour les performances

oui, c'est ce que je suggérais en parlant des autres moteurs disponibles y compris à travers Python

par contre dire qu'un fichier de logs est quelque chose de calibré est complètement hasardeux, il suffit de regarder le /var/log/syslog de n'importe quelle machine, et pour avoir eu le cas en production on peut avoir des logs de plusieurs Go très peu homogènes, et les regex tout à fait convenir pour faire le job, la question des performances n'est pas portée sur les seules expressions régulières mais sur l'architecture complète de l'outil d'analyse/corrélation des évènements (parallélisation, tokenisation etc.)

à titre indicatif sur un tool perso permettant des "regex utilisateur" complexes et arbitraires, l'analyse de quelques milliers de lignes passées au crible systématique d'une vingtaine de regex ne prend qu'une poignée de secondes sur une machine à 2GHz
le produit phare du moment ElasticSearch permet d'analyser des quantités astronomiques de logs et repose en grande partie sur les regex