Le contexte :
- Des sources natives de données (internes et externes) sont disponibles,
- A partir de ces données on va chercher à en tirer du sens par l’intermédiaire de dispositifs (data products) : du décisionnel classique (tableau de bord avec KPI par exemple) à des algorithmes de data science (identification de patterns comportementaux par clustering par exemple).
La question : quel choix de modèle de stockage des données sources pour une exploitation par des data products ? Plus largement quelle plate-forme data pour mes données ?
Deux situations récentes m’ont amené à proposer une grille de synthèse de cette problématique de choix :
- Première situation, un débat entre un DSI et un architecte de domaine métier sur cette question. Le besoin métier est classique : production de tableaux de bord, mise en place de portails de navigation dans les données, production de datasets pour un usage tiers. D’un côté l’architecte du domaine métier pousse à la mise en place d’une plate-forme data sur la base d’un pipeline (ETL) nocode/lowcode et d’un SGBDR. De l’autre côté le DSI pousse une architecture standard de type Datawarehouse (ODS/DW/DataMart).
- Deuxième situation, la mise au rebut d’une plate-forme Big Data (initiée en 2017 et au budget conséquent) pour être remplacée par un SGBDR open source et un environnement de data visualisation.
Dans la première situation, le choix (simplifié) porte sur SGBDR ou ODS/DW/DataMart ?
Dans la seconde situation, le choix porte sur un environnement Big Data ou un SGBDR voire un DataMart ?
A noter que pour cette dernière situation, la question s’était vaguement posée au départ du projet. Mais à l’époque le choix Big Data avait tout balayé par le tsunami effet de mode / marketing du discours Big Data : il vous/nous faut un Big Data sinon vous êtes/on est mort (explosion des données et tout le monde a/veut un Big Data) !
Le schéma ci-dessous illustre les combinaisons possibles entre différentes natures de sources, différents types de supports (data products) pour tirer du sens des données et différents types de stockage des données entre les sources et les supports.
Et sans rentrer dans le détail, une liste de critères de choix est proposée.
A ce problème de choix, bien entendu il n’y a pas de réponse générique toute faite. Chaque contexte est spécifique. La grille formée par ce schéma est un support pour aider à répondre à la question.
NB : mon critère préféré est l’alignement sources – usages. A savoir la réduction autant faire se peut de toute transformation des données sources pour en tirer les usages. Avec le risque de rupture entre le fait de disposer de sources de données parfaitement connues des métiers et des données transformées pour rentrer dans le moule de stockage des usages (rupture de la continuité de lisibilité pour les métiers, avec potentiellement une validation difficile, une analyse des écarts chronophage…). Exemple (classique) :
- A la source, des données en tables, sous excel, interrogeables via des objets métier portés par un ERP, le tout faisant l’objet d’une manipulation quotidienne par les métiers,
- Et pour produire des analyses, des données transformées dans une structure en étoile (décisionnel) ou NoSQL … difficilement accessible aux métiers.
Pour terminer quelques arguments à évaluer en fonction du contexte :
- Si l’envie Big data est toujours présente, êtes vous sûr que l’argument volume est viable ? (quels volumes de données avez-vous besoin / interrogez-vous pour vos data products ? Seules les dernières données en date sont utiles ? A noter que depuis l’idée des Big Data 2004/2005 les performances de stockage/traitement des systèmes mémoire/CPU ont très largement évolué et là où il était nécessaire d’avoir un cluster de serveurs, une seule machine suffit maintenant).
- Les solutions de Business Intelligence, data visualisation savent attaquer efficacement des bases relationnelles.
- A-t-on vraiment besoin de centraliser les données ? Lorsqu’on rapatrie des données sources, a-t-on bien à disposition le contexte qui les accompagne (lineage, qualité, définition…) ? Ne peut-on pas les exploiter par partage voire par virtualisation ?
Bon choix !
Tous droits réservés – datassence.fr. Cet article a été publié originellement sur www.datassence.fr.
Les commentaires sont fermés.