Data warehouse en temps réel

**i.chafai** · 16/10/2016, 15h04

Bonjour,
Je suis un consultant BI et reporting dans une SSII spécialiste dans l'intégration des ERP. Nos clients sont généralement des PME.
Le reporting qu'on est entrain de fait est basé généralement sur des vues ou des requêtes qui sont exécutés sur les bases de prod, mais pour des problèmes de performance et pour ne pas bloquée les utilisateurs on a pensé a passer par un data warehouse mais le problème ici est que les décideurs veulent toujours avoir les résultats en temps réel.
Existe-t-il une solution pour avoir un data warehouse en temps réel?

Merci par avance

**mbdsi** · 16/12/2016, 14h50

Bonjour,
le temps réel est abordé de nombreuses manière dans la BI.
Mais de manière générale, tu devrais tenté de passer par les solutions ETL. Je n'ai travaillé que sur un seul projet en temps réel qui suivait le flux de donnée des logs des applications sources via Informatica Power exchange. Ensuite, dans Informatica Power Center, on gérais dans une mapplet les retour de Power Exchange. Le tout finissais par faire intervenir les nouvelles données en quelques minutes dans les rapports.
Et pour le reste que j'ai pu lire, c'est surtout les ETL qui permettent de gérer le temps réel. Même Talend a lancé une offre l'année dernière.
J'espère que cela pourras t'être utile

**Prjprj** · 20/12/2016, 11h00

Les solutions CDC (Change Data Capture) qui permettent de faire du temps quasi réel aux ETL sont effectivement applicables, mais il faut bien tenir compte qu'elles nécessitent de gros pré-requis, une connaissance assez pointue des produits impactés (et pas seulement l'ETL, la base source est primordiale dans ce type de cas).

Ce sont par ailleurs des produits très sensibles a tout incident et nécessitant une supervision très pointue.

En gros je ne recommande quasi jamais ce type de solution car les impacts organisationnels et techniques sont en général si lourds que les clients abandonnent.

**i.chafai** · 25/12/2016, 14h16

Envoyé par Prjprj

Les solutions CDC (Change Data Capture) qui permettent de faire du temps quasi réel aux ETL sont effectivement applicables, mais il faut bien tenir compte qu'elles nécessitent de gros pré-requis, une connaissance assez pointue des produits impactés (et pas seulement l'ETL, la base source est primordiale dans ce type de cas).

Ce sont par ailleurs des produits très sensibles a tout incident et nécessitant une supervision très pointue.

En gros je ne recommande quasi jamais ce type de solution car les impacts organisationnels et techniques sont en général si lourds que les clients abandonnent.

J'ai déjà pensé au CDC, mais le problème et que je suis sous la version Standard de SQL Server

**nuke_y** · 27/12/2016, 12h25

Honnêtement sur du SQLServer Standard c'est pas évident. En investissant un peu il y a la solution d'avoir de la réplication SQLServer et donc d'avoir 1 base pour l'opérationnel et 1 base pour le reporting, la 2e étant synchronisée avec la 1ere avec une faible latence.

Est-ce que tous les rapports sont vraiment nécessaires en temps réel? On s'en sort souvent ainsi: séparer

opérationnel temps réel : directement sur la base opérationnelle, faible volume, requêtes bien maîtrisées, seulement quelques cas d'usage éligibles
opérationnel quotidien : sur le DWH mis à jour tous les jours, pas de limitation de volume
décisionnel : forcément pas temps réel, sur le DWH
analytique (si on le sépare du décisionnel): forcément pas temps réel, sur le DWH (je ne rentre pas sur le débat des data lake)
alerting : réagir à un événement, l'analyser et prendre la décision de prévenir automatiquent l'utilisateur pour qu'il agisse. C'est le cas compliqué du décisionnel puisque c'est du décisionnel MAIS en temps réel, là il n'y a pas beaucoup de solutions propres (Bus de données + Complex Event Processing), mais pas mal de sales: triggers sur la BDD, process qui vérifie en permanence dans la base. L'idéal dans ce cas c'est de faire remonter ce besoin dans l'outil source (Sage ici si j'ai bien compris, pas de chance).

**i.chafai** · 29/12/2016, 18h42

Envoyé par nuke_y

Honnêtement sur du SQLServer Standard c'est pas évident. En investissant un peu il y a la solution d'avoir de la réplication SQLServer et donc d'avoir 1 base pour l'opérationnel et 1 base pour le reporting, la 2e étant synchronisée avec la 1ere avec une faible latence.

Est-ce que tous les rapports sont vraiment nécessaires en temps réel? On s'en sort souvent ainsi: séparer

opérationnel temps réel : directement sur la base opérationnelle, faible volume, requêtes bien maîtrisées, seulement quelques cas d'usage éligibles
opérationnel quotidien : sur le DWH mis à jour tous les jours, pas de limitation de volume
décisionnel : forcément pas temps réel, sur le DWH
analytique (si on le sépare du décisionnel): forcément pas temps réel, sur le DWH (je ne rentre pas sur le débat des data lake)
alerting : réagir à un événement, l'analyser et prendre la décision de prévenir automatiquent l'utilisateur pour qu'il agisse. C'est le cas compliqué du décisionnel puisque c'est du décisionnel MAIS en temps réel, là il n'y a pas beaucoup de solutions propres (Bus de données + Complex Event Processing), mais pas mal de sales: triggers sur la BDD, process qui vérifie en permanence dans la base. L'idéal dans ce cas c'est de faire remonter ce besoin dans l'outil source (Sage ici si j'ai bien compris, pas de chance).

Merci pour votre réponse.
Dans la majorité des cas, il n'y a pas vraiment un très grand besoin du temps réel c'est juste une culture chez mes clients.
Le besoin est plutôt du opérationnel quotidien, ça sera mon rôle de convaincre mes clients a changé quelques mauvaise habitudes.

**nuke_y** · 31/12/2016, 21h04

Oui essayez de les faire changer un peu dans leurs habitudes, ça vous facilitera la vie. Actuellement certains gros acteurs sont en train de tenter une nouvelle approche pour faire de la BI et de l'analytique au même endroit (et donc de la BI temps réel) comme SAP HANA mais honnêtement on attend de voir ce que ça donne avant de pousser ça comme l'architecture du futur.

Autre solution : avez-vous contacté l'éditeur Sage pour savoir s'il n'est pas possible de mettre en place des événements ou des logs ? J'ai un autre client qui a Sage et ça nous avait déjà cassé les pieds, mais je n'ai pas eu l'occasion de questionner l'éditeur.

Sinon il y a la solution "sale" d'avoir un très très bon DBA qui arrive à ajouter des fonctionnalités directement dans la BDD sans perturber Sage, des triggers par exemple mais il doit exister d'autres solutions. Il me semble que Sage est plutôt Old School et donc assez limité sur les accès BDD. C'est dangereux, donc il ne faut le faire qu'avec des experts reconnus et seulement si ça leur semble jouable. Moi par exemple je ne le ferais pas, pas assez compétent pour prendre ce risque.