NoSQL et BI : un avenir (très) probable.

Bonjour,

Je m'intéresse depuis peu à la BI et plus particulièrement à la possibilité de coupler le noSQL à la BI. Outre le fait qu'aujourd'hui, aucune solution n'est proposé, je pense qu'il est possible que cela arrive demain.

Pour vous, quels seraient les impacts sur l'architecture d'un SID et sur les solutions classiques de la BI ?

Etant novice en la matière (faut bien débuter), ce qui suit est peut-être une totale bêtise de ma part :

Est-il possible d'utiliser pour la partie stockage (datawarehouse) une table NoSQL et laisser les datamarts en base de données relationnelle ?

Soyez indulgents svp ;)

Je suis également intéressé par cet aspect : utilisation de bases noSQL dans le cadre des entrepôts de données!!

C'est quelque chose qui m'avait paru évident sur le coup, mais je suis pas sur que pour les SCD par exemple, ce soit très pratique (ou raisonnable en terme de place).

Ca a sans doutes un avenir, après ça me semble une mauvaise idée.

La BI se fonde sur l'assertion sur l'assertion que les système de production n'ont pas envie de faire des contorsions pour le managements. Les systèmes de prod ressemblent de plus en plus à de l'anarchie, une décharge. La BI reprend tout et le fait monter en qualité. Du coup, histoire de rester propre et durable, on fait des process ETL clair, des data warehouse solides et prévus pour durer aussi longtemps que des cathédrales.

Le NoSQL, ce n'est pas propre (même pas de SQL), c'est la porte ouverte des des devs sauvages. En gros au bout d'un an ça deviendra une porcherie. Ca me semble contre indiqué.

Par contre le NoSQL peut servir dans des cas d'analyse poctuelle où c'est pratique. Une analyse n'est pas industrialisée ni prévue pour durer, il faut juste trouver le résultat au plus vite peu importe le moyen.

On commence à voir des annonces d'éditeurs ETL comme Informatica ou Talend (en Open source) sur des connecteurs avec le système de fichier Hadoop (HDFS). Les entreprises peuvent utiliser la puissance de MapReduce pour traiter les gros volumes de données puis envoyer les résultats vers un entrepôt de données cible où ils seront accessibles aux utilisateurs.

Je me trompe peut-être, mais le NoSQL servirait à gérer les grosses masses de données dans un contexte de BI. Ce que je comprends, c'est que le problème des Big Data en BI semble résolu... Si tel est le cas, pourquoi cherchons-nous à utiliser du NoSQL ?

De plus, HBase est une solution NoSQL basée sur Hadoop. Si des outils comme Talend utilisent Hadoop, alors, pourquoi n'est-il pas possible d'utiliser des solutions NoSQL comme HBase.

Je suis un peu dans le flou...

Techniquement, le NO-SQL, c'est juste une base de données qui ne s'accède pas via des requêtes SQL, donc on peut très bien envisager des connecteurs NO-SQL pour des bases de données relationnelles standard...

Les bases de données "NO-SQL" comme Hadoop, ont les mêmes fonctionnalités que les bases relationnelles quand il s'agit de reporting, donc on peut concevoir que, dans un avenir proche, des outils de reporting commencent à proposer des connecteurs adaptés, l'utilisation devrait être similaire (au final, la base derrière n'est qu'une boite noire, on se fout de la techno qui la fait fonctionner). Qlikview fonctionne déjà avec un stockage de données "NO-SQL", donc cela prouve bien que c'est possible et que les performances sont au rendez-vous (j'ai fait mumuse avec 20 millions de lignes dans 2 Go de RAM chez un client, cela fonctionne sans problème).

Concernant l'ETL, c'est plus complexe puisque l'on met plus les mains dans le camboui, mais dans l'ensemble, je pense que, bien que la façon de concevoir et de développer risque de changer, les fondamentaux resteront les mêmes.

Pour moi, les bases NO-SQL sont une "arme" en plus dans l'arsenal des BIeux, la façon dont les données sont stockées importe peu au final tant que le résultat est au rendez-vous.

Je voudrais être sûr de bien comprendre quand tu dis "on peut très bien envisager des connecteurs NO-SQL pour des bases de données relationnelles standard...". Pourrais-tu détailler un peu plus s'il te plaît ?

Si l'on modifie la manière dont sont stockés les données (passage d'une datawarehouse en BD relationnelle à une datawarehouse en BD non-relationnel (NoSQL)), les ETL's devront être aussi modifiés, non ? La manière dont les ETL feront leur chargement sera tout à fait différent (plus de stockage en ligne). De plus, les outils de reporting comme Birt devront eux aussi être modifiés. Ils ne pourront plus traiter les données de la même manière, n'est-ce pas ?

Je n'arrive pas à trouver d'information concernant l'utilisation du NoSQL chez Qlikview...

Le "NO-SQL", c'est un terme pour dire :
Ne pas accéder aux données avec du SQL.

Maintenant, beaucoup comprennent ce terme comme un nouveau truc magique qui va révolutionner les bases de données avec d'autres technologies que le stockage relationnel.

Effectivement, il existe de nouvelles technologies qui permettent de stocker et d'accéder aux données différemment, ces technologies sont présentées comme plus performantes.

A ma connaissance, ces technos stockent les données de façon vectorielle en ne stockant qu'une fois une valeur distincte et ensuite gèrent des tables d'associations pour modéliser les liens entre les objets.
En gros, on a des vecteurs (tables à 1 colonne) contenant les listes de valeurs, et des tables d'association contenant toutes les associations possibles entre les valeurs.
On accède donc rapidement aux données car elles ne sont pas stockées plusieurs fois, et les "jointures" sont simples car reposant sur des tables d'association.

Au final, que la donnée soit stockée dans une table, elle même stockée dans un tablespace ou qu'elle soit stockée dans un vecteur avec des associations dans un fichier hadoop, le résultat est le même, quand on demande telle donnée avec tels attributs, la base nous la restitue, quelle que soit la techno utilisée.

Ce que je voulais dire, c'est que dans une application BI, l'ETL ou l'outil de restitution voit la base comme une boite noire, il utilise un programme pour s'y connecter (le "client de connexion à la base") qui se charge de traduire les demandes du programme en langage compréhensible par la base, quelle que soit la technologie de la base.
On peut donc envisager un connecteur SQL pour Hadoop et des connecteurs NO-SQL pour Oracle, SQL Server ou MySQL...

Concernant Qlikview, il stocke ses données dans une base propio IN Memory qui fonctionne de la façon dont j'ai expliqué ci-dessus, cela le rend très rapide car toutes les données sont stockées en RAM.

Bonjour,

Je suis tombé sur un article qui semble fort intéressant. Qu'en pensez-vous ?

Voici l'article :
http://www.articlesenligne.com/artic...mat-natif.html

Du fake. Pour Hadoop et le sgbd MPP, ça se résume à mettre un driver JDBC.

Puis lancer un reporting sur une base de plusieurs To, même en NoSQL ça va prendre du temps à se générer, donc pas de ad-hoc.

Après la BI 2.0 on reviens à la 1.0 mais avec le cloud et le NoSQL. Vivement la mode automne/hiver.

Je vois souvent l'expression "ad-hoc", notamment dans ton message. Mais qu'est ce que cela signifie ?

ad-hoc signifie que l'utilisateur va faire quelque chose de spécifique, en général on parle de ad-hoc pour des rapports paramétrés.

En gros, t'es en train de me dire qu'on parle de quelque chose quand l'utilisateur va faire quelque chose... :ccool: C'est pas très précis comme réponse Jester...
Ca correspond à quoi en BI vraiment ?

Par exemple, tu as un rapport sur un portail BI qui permet à l'utilisateur de choisir le pays sur lequels il veut des résultats.

Il choisit dans la list box le pays puis il fait OK. Derrière, le serveur va calculer le rapport pour le pays donné. Si la requête met 30 minutes pour lui donner son rapport, il y a peu de chance que l'utilisateur trouve cela très pratique.

ad hoc = spécifique

Ok d'accord !

En SQL, le temps sera long. En NoSQL, il y a des chances pour que le temps soit réduit dû aux possibilités offertes par cette nouvelle techno je pense tout de meme.

En BI, on parle de reporting ad hoc pour définir le cas où ce sont les utilisateurs qui font eux-mêmes leurs rapports, plutôt que de se contenter des rapports développés par l'équipe informatique.

ça suppose des datamarts avec des couches sémantiques, ou bien des cubes.

Sujet intéressant, que je prends hélas en retard, mais bon je me permets de rajouter mon grain de sel :aie:

C'est vrai que sur le papier les bases NoSQL sont séduisantes pour la BI ...
En premier lieu pour les volumétries , et aussi pour leur abandon du côté transactionnel ( ACID ) qui est tout à fait approprié en décisionnel.

Cependant il faut rester vigilant sur les nouvelles technos, surtout quand à la base elles ne sont pas destinées à la BI. Certaines contraintes ne sont pas toujours mises en avant. Par exemple saviez-vous que si vous voulez rajouter une colonne dans Cassandra il faut redémarrer la base ?

Citation:

---

Envoyé par mike35000

En NoSQL, il y a des chances pour que le temps soit réduit dû aux possibilités offertes par cette nouvelle techno je pense tout de meme.

---

Les bases de données en colonne font mieux je pense ... Comme elles regroupent et compressent les données au même endroit certaines requêtes sur des milliards de lignes sont instantanées.
Après cela dépend aussi de la modélisation.

Pour moi les bases NoSQL sont une brique de la BI 3.0 avec du décisionnel sémantique et des données non structurées mais ce sera en + de la BI old school qui a encore de beaux jours devant elle.

Sinon si vous avez des exemples concrets en NoSQL je suis preneur !