Discussion :

[i.chafai]

Bonjour,
Actuellement j'ai lancé un projet d BI pour mes clients qui utilisent Sage Ligne 100 comme ERP et d'autres solutions qui sont intégrés à Sage :
- Mon projet va touché les domaines suivants : Vente, Achat, Stock et Recouvrement Client
- J'ai pas un besoin spécifique, c'est un projet volontaire
- Tous mes clients ont SQL Server (version Express ou Standard édition selon sa licence Sage) : je pense utiliser SSIS, pour les clients qui ont une version Standard c'est ok, mais pour les versions express est ce que je peux lancer mes package ? Et comment je peux les planifiés?
- Mon DW va être synchronisé tous les soirs, pour les dimensions je compte utiliser du UPSERT, mais pour les tables de fait je compte supprimer les donnés d'un mois glissants et de les réintégrés, mais le prob que les utilisateurs peuvent toucher des anciennes données (Modifier une facture datée de 6 mois par exemple...) et si je fais un purge totale le traitement va être très lourds
-Tous mes clients ont plus qu'une société qui tourne sur Sage est c que le mieux est de.créer un DW unique avec une dimension Société qui touche toutes les mes tables?
- Pour la partie reporting je pense utiliser SSRS, mais mon souci est que les end users ne peuvent pas créer leur propre états

Comme j'ai mentionné au début, c'est un porjet très volontaire est mon but principal sera de montrer en compétence sur Microsoft BI et la BI en général.

[Elros]

Hello,

Je vais essayer de t'aider dans ta quête

Tous mes clients ont SQL Server (version Express ou Standard édition selon sa licence Sage) : je pense utiliser SSIS, pour les clients qui ont une version Standard c'est ok, mais pour les versions express est ce que je peux lancer mes package ? Et comment je peux les planifiés?

L'idéal serait avec SSIS de se connecter à distance à toutes les bases clientes pour récupérer les données brutes. Comme ça, tu n'auras pas besoin de lancer de package chez le client !

Mon DW va être synchronisé tous les soirs, pour les dimensions je compte utiliser du UPSERT, mais pour les tables de fait je compte supprimer les donnés d'un mois glissants et de les réintégrés, mais le prob que les utilisateurs peuvent toucher des anciennes données (Modifier une facture datée de 6 mois par exemple...) et si je fais un purge totale le traitement va être très lourds

Pour les dimensions, je ferai de même. Pour les tables de faits, je garderai l'exercice fiscal donc, 1 an. S'il modifie une facture, tu historises l'ancienne ligne (tu flag la ligne ou la déplace, il y'a d'autres solutions à adapter en fonction du contexte). Avec des index ou du partitionnement sur l'exercice fiscal, une purge devrait être rapide.

Tous mes clients ont plus qu'une société qui tourne sur Sage est c que le mieux est de.créer un DW unique avec une dimension Société qui touche toutes les mes tables?

Avec les informations que tu nous donnes, je ferais la même chose que toi.

Pour la partie reporting je pense utiliser SSRS, mais mon souci est que les end users ne peuvent pas créer leur propre états

Si les utilisateurs ont Excel, ils peuvent jouer avec PowerPivot. Tu devras préparer un modèle afin que les utilisateurs ne soient pas perdu. Mieux, fait un cube OLAP et ils pourront faire leurs TCD facilement dans Excel.
Autre solution, PowerBI qui devient de plus en plus complet.

En espérant t'avoir donné des pistes de réflexion.

Elros

[i.chafai]

Merci bien pour votre retour

L'idéal serait avec SSIS de se connecter à distance à toutes les bases clientes pour récupérer les données brutes. Comme ça, tu n'auras pas besoin de lancer de package chez le client !
Elros

là je n'ai pas très bien compris

Si les utilisateurs ont Excel, ils peuvent jouer avec PowerPivot. Tu devras préparer un modèle afin que les utilisateurs ne soient pas perdu. Mieux, fait un cube OLAP et ils pourront faire leurs TCD facilement dans Excel.
Autre solution, PowerBI qui devient de plus en plus complet.
Elros

J'ai pensé à utiliser SSAS mais le prob que certains clients ont SQL Server Express
serait-il fiable d'utiliser PowerPivot pour PowerBI en se basant sur des vues sur mon DW?

[Elros]

Merci bien pour votre retour

là je n'ai pas très bien compris



J'ai pensé à utiliser SSAS mais le prob que certains clients ont SQL Server Express
serait-il fiable d'utiliser PowerPivot pour PowerBI en se basant sur des vues sur mon DW?

Voici un schéma allégé de ce que j'essayais de t'expliquer.



Avec SSIS, tu rapatries dans ta "staging area" les données métiers qui sont stockées chez les différents clients. Tu n'auras pas besoin d’exécuter de package sur les serveurs de tes clients. Il faudra juste demander des droits d'accès.

Pour travailler sur un cube SSAS, Excel seulement suffit à l'exploiter. Tu peux également exploiter un cube SSAS avec Power Pivot et Power BI.

Elros

[nuke_y]

SSIS est un mauvais ETL
SQLServer est une bonne BDD
Power BI est (pour le moment) trop léger comme outil de dashboarding / analyse
SSRS est un assez bon générateur d'état mais pas pour du reporting ad hoc (donc pas d'utilisateur autonome)

Donc avec votre solution:
- vous allez souffrir sur la partie ETL
- vous allez pleurer des larmes de sang sur le dashboarding / analyse
- vos utilisateurs vont râler de la complexité pour faire du reporting par eux-même

D'un autre côté:
- Talend et Kettle ne sont pas forcément meilleurs en ETL
- Il n'y a pas d'outil de restitution gratuit / pas cher valable
- Il n'y a pas d'outil de reporting ad hoc gratuit / pas cher valable

Donc ça me semble la moins mauvaise solution. A noter que Power BI s'intègre de mieux en mieux avec la suite MS BI, et que si Microsoft continue ses efforts ça sera un bon produit d'ici 2 ans.

[Elros]

Hello Nuke_y,

J'apprécie énormément te lire car, à chaque fois j'apprends des choses ! Et ça tombe bien j'ai des questions

SSIS est un mauvais ETL

En quoi SSIS est un mauvais ETL ? Comment tu définis un bon, d'un mauvais ?

Power BI est (pour le moment) trop léger comme outil de dashboarding / analyse
SSRS est un assez bon générateur d'état mais pas pour du reporting ad hoc (donc pas d'utilisateur autonome)

En comparaison à Tableau ou Qlikview, Power BI est évidemment trop jeune (on joue le rôle des bêta-testeurs) mais, on pourrait rendre les utilisateurs autonomes.
On peut aussi les rendre autonomes dans un environnement qu'il maîtrise bien : Excel. Se connecter à un cube avec Excel est simple et pour faire du pseudo reporting/analyse ad hoc je trouve cela appréciable. J'ai croisé une multitude de personne qui travail principalement avec Excel et ils apprécient rester dans leur environnement de travail. Après, avec un bon projet de conduite de changement et de nouveaux outils plus performant et ils apprécieraient encore plus. Mais, changer les habitudes des utilisateurs ne sont pas une chose aisée.

Donc avec votre solution:
- vous allez souffrir sur la partie ETL
- vous allez pleurer des larmes de sang sur le dashboarding / analyse
- vos utilisateurs vont râler de la complexité pour faire du reporting par eux-même

Pour la partie ETL, si l'on doit gérer de gros volume, il vaut mieux changer ! L'installation est bordélique mais, la prise en main n'est pas compliquée. Tu as d'autres éléments de souffrance à partager ?

La partie dashboard/analyse est plus compliqué que les concurrents mais loin d'être insurmontable. Des exemples d'outils où les choses sont moins complexes ?

Pour le reporting ad hoc, ce n'est pas très compliqué mais les temps de traitements sont désespéramment trop long..

D'un autre côté:
- Talend et Kettle ne sont pas forcément meilleurs en ETL
- Il n'y a pas d'outil de restitution gratuit / pas cher valable
- Il n'y a pas d'outil de reporting ad hoc gratuit / pas cher valable

Je veux des noms !
Quels sont pour toi les meilleurs ETL et pourquoi ?
Pour les outils de restitution, est-ce que tu as regardé Pentaho ? Sur le papier ça l'aire intéressant mais, je n'ai pas assez de recul pour juger si c'est un bon outil ou non.
Si tu as des noms d'outils de reporting ad hoc, je suis preneur

Merci d'avance pour ta réponse.

Elros

[nuke_y]

SSIS est un mauvais ETL car il fait mal le travail d'un ETL:

• Ordonnancement, qui est assez lourd, limité, de toutes façons porté plus par SQLServer que SSIS lui-même
• Visibilité sur les flux : pouvoir savoir quel job accède à telle table, où est modifié telle colonne, etc., représentation graphique des flux
• Propagation de modification: un bon ETL est capable de faciliter la vie du développeur pour qu'il n'ait pas à tout modifier à la main. Il en fait, mais mal à mon sens
• Performance: il est plus lent que ses concurrents
• logs : il s'est amélioré mais en version 2008 il ne permettait même pas de retrouver la cause d'un plantage, il fallait tout faire manuellement
• peu de fonctionnalités de transformation côté serveur
• Mauvais connecteurs: il lit mal les fichiers Excel (cad qu'on peut avoir des situations ingérables), il a peu/pas de connecteurs Sharepoint, il est lent sur certaines sources, il est (très) mauvais sur les XML

Après je lui reconnais un très bon rapport qualité / prix et le fait que ceux qui ont dépensé une énergie phénoménale à le maîtriser savent faire de très bonnes choses. Mais bon l'intérêt d'un outil, surtout un ETL, à cause du turn-over à ces postes là, c'est de permettre d'atteindre rapidement des résultats, de pouvoir relire / comprendre ce qui a été fait par quelqu'un d'autre, pouvoir maintenir en minimisant les impacts, etc. Et les performances aussi, si c'est pour retomber sur des procédures stockées et que SSIS ne serve QUE à initialiser des variables c'est dommage...

Les bons ETL pour moi sont Informatica, Datastage et ODI (en ELT).


Pour le dashboarding la clé c'est le modèle de données et la complexité de mise en oeuvre:

• BO sait faire simplement des choses simples
• SSRS ne sait faire que du compliqué mais peut gérer des choses assez compliquées
• Cognos ne sait faire que du compliqué mais peut gérer des choses assez compliquées
• Power BI sait faire simplement des choses simples et peut arriver à faire des choses compliquées, mais il est un peu jeune
• Tableau / Spotfire savent faire simplement des choses simples mais peinent sur des choses compliquées
• Qlikview /Qlik Sense sait faire simplement des choses compliquées
• Pentaho... je ne sais pas je ne l'ai pas assez testé

[Waldar]

Pour les précautions d'usage, je n'ai pas retouché à cet outil depuis plusieurs années.
Je me permets de m'autociter depuis ce poste, qui date d'août 2013 :

Pour la question, les seuls ETL open source dont j'ai entendu parler sont Kettle Pentaho et Talend. Je ne les ai jamais utilisé mais c'est un point de départ.
Une petite recherche permet d'en trouver d'autres.

Par contre, je ne peux pas vous laisser dire que SSIS est bon !
C'est de loin le pire des ETL que j'ai côtoyé (parmi PowerCenter et OTIC / Genio).

• Client horriblement lent et peu réactif dès qu'on a trente boîtes à l'écran, avec des bugs dans tous les sens (des boîtes invisibles par exemple, qui existent mais avec lesquelles on ne peut plus interagir).
• On a le choix entre écrire du code ensembliste et donc rapide, ou utiliser les boîtes pré-faites et on se retrouve à faire du pseudo ligne à ligne.
• Quid des delete / truncates ? Il faut les écrire à la main.
• Les messages d'erreur quand les jobs plantent sont une plaisanterie.
  Si on n'a pas tout anticipé à l'avance, on n'a aucune idée de ce qui plante. Voici le message d'erreur type :
  

  Job has failed

• Les syntaxes update à l'ODBC : Update MaTable set col1 = ?, col2 = ?, col3 = ?, col4 = ?, col5 = ? where col6 = ? and col7 = ?.
  Très amusant quand on arrive à quelques dizaines de colonnes.
• Trois mille options inutiles dans lesquelles se noient cinq options intéressantes.
• Les connecteurs pour Oracle étaient une plaisanterie avant 2011/2012 et les connecteurs Attunity ! Pour un ETL il fallait l'expliquer au client qu'ils ne devaient pas avoir d'Oracle.
• Typages des données contre intuitifs. Vous êtes déjà perdu avec la dizaine de types de données SQL ? SSIS vous en a pondu trente dont douze rien que pour gérer des nombres.
• SSIS se prononce saucisse en français.

SSIS c'est bien pour écrire des jobs de maintenance DBA, des packages simples d'échange de données ou piloter des procédures stockées.
Ne faites pas de décisionnel avec.