Stockage des données de journaux analysés dans hadoop et exportation dans une base de données relationnelle

Question

J'ai besoin d'analyser les journaux d'accès Apache et les journaux Tomcat l'un après l'autre en utilisant map reduce. Peu de champs sont extraits du journal tomcat et reposent du journal Apache. J'ai besoin de fusionner/mapper les champs extraits en fonction de l'horodatage et d'exporter ces champs mappés dans un db relationnel traditionnel (ex: MySQL).

Je peux analyser et extraire des informations en utilisant une expression régulière ou un cochon. Le défi auquel je suis confronté concerne la façon de mapper les informations extraites des deux journaux dans un seul format ou fichier agrégé et comment exporter ces données vers MYSQL.

Peu approches que je pense à

1) sortie de la carte Réduire des deux journaux d'accès Apache et les journaux analysés tomcat dans des fichiers séparés et fusionner ceux dans un seul fichier (nouveau basé sur l'horodatage). Exportez ces données vers MySQL.

2) Utilisez Hbase ou Hive pour stocker des données sous forme de tableau dans Hadoop et d'exportation vers MySQL

3) écrire directement la sortie de la carte Réduire à l'aide de MySQL JDBC.

Quelle approche serait la plus viable et s'il vous plaît suggérer d'autres solutions alternatives que vous connaissez.

Answer 1

Il est presque toujours préférable d'avoir des travaux MR plus petits et plus simples et de les chaîner ensemble plutôt que d'avoir des tâches complexes de grande envergure. Je pense que votre meilleure option est d'aller avec quelque chose comme # 1. En d'autres termes:

1. Traite les journaux Apache httpd dans un format unifié.
2. Traite les journaux Tomcat dans un format unifié.
3. Joignez la sortie de 1 et 2 en utilisant la logique logique, en écrivant le résultat dans le même format.
4. Exportez l'ensemble de données résultant vers votre base de données.

Vous pouvez probablement effectuer la jointure et transformer (1 et 2) dans la même étape. Utilisez la carte pour transformer et faire une jointure de réduction.

Il ne semble pas que vous ayez besoin de la surcharge de l'accès aléatoire, donc je ne regarderais pas HBase. Ce n'est pas son point fort (bien que vous puissiez le faire dans le sens de l'accès aléatoire en recherchant chaque enregistrement dans HBase par horodatage, voir s'il existe, fusionner l'enregistrement, ou simplement l'insérer s'il n'existe pas, mais ceci est très lent, comparativement). Hive pourrait être pratique pour stocker le résultat "unifié" des deux formats, mais vous devrez quand même transformer les enregistrements dans ce format.

Vous absolument ne veulent pas que le réducteur écrit directement dans MySQL. Cela crée effectivement une attaque DDOS sur la base de données. Considérons un cluster de 10 nœuds, chacun exécutant 5 réducteurs, vous aurez 50 écrivains simultanés à la même table. Au fur et à mesure que vous développez le cluster, vous dépasserez les connexions max très rapidement et étoufferez le SGBDR. Tout cela étant dit, demandez-vous s'il est logique de mettre autant de données dans la base de données, si vous considérez les enregistrements complets du journal. Cette quantité de données est précisément le type de cas que Hadoop est censé stocker et traiter à long terme. Si vous calculez des agrégats de ces données, n'hésitez pas à les lancer dans MySQL.

Espérons que cela aide.