MySQL, XML, BigData – Résorber la dette technique et unifier les données pour le marketing


Il est beaucoup question du phénomène du Cloud, de la big data. Toutefois, la consolidation des données dans un espace viable et optimale n’est pas une tache aisée. Comme il existe de la dette technique, il existe des adhérences fortes dans la manipulation des données liées à des pesanteurs historiques (données sous différents formats, données non structurées). La première phase avant d’envisager de structurer les données, il faut d’abord les récolter et d’auditer l’existant.

Il faudra donc souvent manipuler des fichiers physiques qu’il faut traiter et cela souvent à moindre frais. Bref, uniformiser rapidement avec une contrainte financière et de temps forte (pas de thune, peu de temps).

En substance, on va transférer des données mortes “dumpés” au format XML pour les injecter dans une BDD MySQL, ce qui consiste à explorer la commande SQL LOAD DATA LOCAL INFILE

Note : Le test de transfert de données à été fait via un client MySQL sur MAMP dont la version est la suivante MySQL 5.5.33

MySQL Cookbook 2e

MySQL Cookbook 2e

Un livre vraiment complet pour "masteriser" le format de base de données le plus répandu sur le Web : MySQL. Un livre très pratique, truffé de cas pratiques avec des solutions clé en main notamment les bonnes lignes de commande pour parfaire votre maitrise de la console MySQL.

Genre(s) : , , ,
Auteur(s) :

The XML Transfert

Bon, il est vrai que notre exemple est relativement facile, on triche un peu. Notre source de données est à la base, déjà dans un format quelque peu structuré (données structurés au format XML) et prêt à l’échange ! Cela pourrait être tout aussi bien des fichiers statiques de JSON, des tableurs excel au format CSV… La question de la consolidation devient beaucoup plus problématique lorsque on a une hétérogénéité de format de données, de structure ! Comment mapper, comment structurer, comment tirer la substantifique moelle de tout ce “fatras” digital, quelle socle technologique pour requêter l’ensemble (NoSQL, RDBM)… Bref, des questions éminemment importantes car la qualité informationnel dépend des recoupements pertinents et de la facilité à agréger/consolider d’autres sources de données en cours de projet, appelons cela la scalabilité de pertinence.

Bon, laissons tomber les concepts, donnons plutôt une petite recette.
La base de données MYSQL qui va recevoir les données du XML
MySQL, XML, BigData - Résorber la dette technique et unifier les données pour le marketing

Dans la client MySQL, le mot de passe sur Mac et sur MAMP est généralement root

/Applications/MAMP/Library/bin/mysql -u root -p

MySQL, XML, BigData - Résorber la dette technique et unifier les données pour le marketing

Dans la client MySQL, sélection de la base via la commande

USE le_nom_votre_base;

Bien s’assurer que la table est vide avant de lancer l’import

TRUNCATE TABLE person;

MySQL, XML, BigData - Résorber la dette technique et unifier les données pour le marketing

MySQL, XML, BigData - Résorber la dette technique et unifier les données pour le marketing

MySQL, XML, BigData - Résorber la dette technique et unifier les données pour le marketing

Histoire de créer la table qui va bien. La BDD se nomme le_nom_votre_base et la table member_list_index

  -- --------------------------------------------------------
 
  --
  -- Structure de la table `member_list_index`
  --
 
  CREATE TABLE member_list_index (
     id INT(11) NOT NULL AUTO_INCREMENT,
     email VARCHAR(255) NOT NULL DEFAULT '',
     firstname VARCHAR(255) NOT NULL DEFAULT '',
     lastname VARCHAR(255) NOT NULL DEFAULT '',
     PRIMARY KEY (id)
  ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
 
  --
  -- Full text search email, firstname, lastname
  --
 
 
 
  CREATE FULLTEXT INDEX ind_full_email
  ON member_list_index (email);
 
  CREATE FULLTEXT INDEX ind_full_firstname
  ON member_list_index (firstname);
 
  CREATE FULLTEXT INDEX ind_full_lastname
  ON member_list_index (lastname);
 
  CREATE FULLTEXT INDEX ind_full_ema_fir_las
  ON member_list_index (email, firstname, lastname);

Le fichier person_dump_1.xml

  <?xml version="1.0"?>
  <list>
         <person>
             <PersonId num="1"></PersonId>
             <FirstName>Mikael</FirstName>
             <LastName>Ronström</LastName>
         </person>
         <person>
             <PersonId num="2"></PersonId>
             <FirstName>Lars</FirstName>
             <LastName>Thalmann</LastName>
         </person>
   </list>
  LOAD DATA LOCAL INFILE '/le-chemin/vers-votre/fichier/person_dump_3_1.xml'
   INTO TABLE person
   CHARACTER SET BINARY
   LINES STARTING BY '<person>' TERMINATED BY '</person>'
   (@person)
   SET
     person_id = ExtractValue(@person:=CONVERT(@person USING utf8), 'PersonId/@num'),
     fname = ExtractValue(@person, 'FirstName'),
     lname = ExtractValue(@person, 'LastName')
   ;

Conclusion : Il existe bien une tâche ingrate, celle de devoir consolider des données provenant de sources diverses et d’y trouver une cohérence en vue d’une exploitation future. C’est le sens d’une API mais avant de se lancer dans un projet aussi ambitieux, “N’oubliez pas de nettoyer les chiottes numériques et d’éteindre la lumière ?”, ce qui en novlangue digito-consultant signifie “Avez-vous une stratégie claire dans la consolidation des vos données, la cible étant le bigdata, afin d’en tirer des métriques significatifs pour une pertinence informationnelle optimale ?”.

En savoir plus