Question

La société pour laquelle je travaille produit un système de gestion de contenu (CMS) avec différents différents add-ons pour la publication, le commerce électronique, l'impression en ligne, etc. Nous sommes en train d'ajouter « module de reporting » et je dois étudier quelle stratégie devrait être suivie. Le "module de reporting" est autrement connu comme Business Intelligence , ou BI.

Le module est censé être en mesure de suivre les téléchargements d'articles, exécutés recherches et de produire différents rapports sur lui. En fait, ce n'est pas important quel type de données est en cours baratté comme à long terme, nous pourrions vouloir être en mesure de pousser tout ce que nous pensons est nécessaire et obtenir un rapport sur lui.

En gros, nous avons deux options.

Option 1 consiste à écrire une solution basée sur Apache Solr (en particulier, en utilisant https://issues.apache.org/jira/browse/SOLR-236 ). Pour de cette approche:

  • libre / open source / de bonne qualité
  • nous utilisons Solr / Lucene ailleurs si nous savons que le domaine très bien
  • flexibilité totale sur ce qui est en cours d'indexation que nous pourrions prendre les données entrantes (au format XML), le pousser à travers XSLT et le nourrir à Solr
  • flexibilité totale de la façon de montrer les résultats de recherche. Semblable à l'étape ci-dessus, nous pourrions avoir modèle de recherche XSLT personnalisé et afficher les résultats dans ne importe quel format que nous pensons est nécessaire
  • nos développeurs frontend maîtrisent XSLT si ce mécanisme pour montage d'un autre client devrait être relativement facile
  • Solr offres en temps réel / full text / recherche par facettes qui sont absolument nécessaires pour nous. Un prototype rapide (basé sur Solr, dossiers 1M) a été en mesure de fournir des résultats de recherche en 55ms. Notre maximale estimée des dossiers est d'environ 1 milliard de lignes (ce n'est pas beaucoup pour l'application BI typique) et si le pire arrive au pire, nous pouvons toujours regarder SolrCloud, etc.
  • il y a des entreprises qui font des choses très similaires en utilisant Solr (Honeycomb Lexicon, par exemple)

Inconvénients de cette approche:

  • SOLR-236 pourrait ou non être stable, d'ailleurs, il ne sait pas encore quand / si elle sera libérée en tant que partie de la publication officielle
  • il y aurait peut-être des choses que nous devrions écrire pour obtenir des BI fonctionnalités spécifiques de travail. Cela sonne un peu comme réinventer la roue
  • le plus gros problème est que nous ne savons pas ce que nous pourrions avoir besoin à l'avenir (comme l'intégration avec un morceau de logiciel BI, l'exportation vers Excel, etc.)

2 est de faire une intégration avec une pièce libre ou commerciale de logiciels de BI. Jusqu'à présent, je l'ai regardé Wabit et aura un oeil à QlikView , peut-être d'autres. Pour de cette approche:

  • pas besoin de réinventer la roue, le logiciel est (je l'espère) essayé et testé
  • nous permettrait d'économiser du temps, nous pourrions passer la résolution des problèmes que nous spécialisés dans

Moins:

  • que nous sommes un magasin Java et notre solution est multi-plateforme, nous aurions dû éliminer beaucoup d'options qui sont sur le marché
  • Je ne sais pas comment le logiciel BI flexible peut être. Il faudra du temps pour passer par des offres de BI pour voir si elles peuvent faire l'indexation flexible, temps réel / recherche en texte intégral, les résultats entièrement personnalisables, etc.
  • On m'a dit que les offres de BI open source ne sont pas assez matures alors que BIs commerciaux (SAP, autres) fortunes de coûts, leurs licences partent de dizaines de milliers de livres / dollars. Bien que je ne suis pas contre le choix commercial en tant que tel, il ajoutera au niveau du prix global qui peut facilement devenir trop grand
  • ne sais pas comment BI est fait pour travailler avec des données de schéma-less

Je suis certainement pas le meilleur candidat pour trouver l'option la plus d'intégration approprate sur le marché (principalement en raison de l'absence de connaissances dans le secteur BI), mais a besoin de décision à faire rapidement.

Quelqu'un at-il été dans une situation similaire et pourrait donner des conseils sur la route à take, ou mieux encore - donner des conseils sur avantages / inconvénients possibles de l'option # 2? Le plus gros problème est que je ne sais pas ce que je ne sais pas;)

Était-ce utile?

La solution

J'ai passé un certain temps à jouer avec les deux QlikView et Wabit , et dois dire que je suis très déçu.

J'ai eu une attente que toute l'industrie BI a fait une science en elle, mais de ce que je trouvais cela est juste un simple mot à la mode. Cet article MSDN était en fait ouvert les yeux. L'affaire de BI consiste à prendre des données à partir des schémas bien normalisés (ils l'appellent OLTP ), le mettre dans des schémas moins normalisés ( OLAP , snowflake- ou étoile de type ) et la création d'indices pour tous les aspects que vous voulez (jargon de l'industrie en est cube de données ). Le reste est juste des scripts pour obtenir les jolis graphiques.

OK, je sais que je suis ici des choses simplifie à l'extrême. Je sais que je pourrais avoir manqué beaucoup d'aspects différents (rapports Nice? Exportation vers Excel? Prédictions?), Mais d'un point de science informatique de vue, je ne peux pas voir quoi que ce soit au-delà d'un index de base de données ici.

On m'a dit que certains outils de BI en charge la compression. supports Lucene, aussi. On m'a dit que certains outils de BI sont capables de garder tous les index dans la mémoire. Pour qu'il y ait un cache Lucene.

En parlant des deux candidats (Wabit et QlikView) - le premier est tout simplement immature (j'ai des dizaines d'exceptions en essayant de sortir de ce qui a été suggéré dans leur démo) alors que les autres ne fonctionne que sous Windows (pas très belle, mais je pourrais vivre avec ça) et l'intégration serait susceptible de me obliger à écrire quelques VBScript (beurk!). Je devais passer quelques heures sur les forums QlikView juste pour obtenir un contrôle de la plage de dates simples de travail et a échoué parce que l'édition personnelle, je ne l'avais pas soutenir des projets de démonstration téléchargeables disponibles sur leur site. Ne vous méprenez pas, ils sont tous les deux bons outils pour ce qu'ils ont été construits pour, mais je ne vois tout simplement pas le point de faire l'intégration avec eux comme je ne gagnerait pas beaucoup.

Pour adresse (défendables) de Solr I immaturité définit une API abstraite afin que je puisse déplacer toutes les données à une base de données qui prend en charge les requêtes en texte intégral si quelque chose va mal. Et si le pire arrive au pire, je peux toujours écrire des choses sur le dessus de Solr / Lucene si je dois.

Autres conseils

Si vous êtes vraiment dans un scénario où vous n'êtes pas sûr de ce que vous ne savez pas Je pense qu'il est préférable d'explorer un outil open-source et d'évaluer son utilité avant de plonger dans votre propre la mise en oeuvre. Il pourrait très bien être la solution que l'utilisation open-source vous aidera plus votre compréhension cristalliser et les caractéristiques requises.
Je l'avais déjà travaillé avec / une solution open-source appelée Pentaho . Je me sentais sérieusement que je comprenais beaucoup plus en apprenant à utiliser les fonctions de Pentaho pour ma fin. Bien sûr, comme est le cas de travail avec / la plupart des solutions open source, Pentaho semblait être un peu intimidant au début, mais j'ai réussi à obtenir une bonne adhérence de celui-ci dans le temps d'un mois. Nous avons également travaillé avec bouilloire et outil ETL

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top