Auswahl einer Strategie für das BI -Modul

Question

Das Unternehmen, für das ich arbeitet, erzeugt ein Content Management System (CMS) mit verschiedenen Add-Ons für Veröffentlichungen, E-Commerce, Online-Druck usw. Wir sind jetzt im Prozess des Hinzufügens von "Berichtsmodul" und ich muss untersuchen, welche Strategie sollte verfolgt werden. Das "Berichtsmodul" ist auch als bekannt als Business Intelligence, oder bi.

Das Modul soll in der Lage sein, Element -Downloads zu verfolgen, Suchanfragen auszuführen und verschiedene Berichte daraus zu erstellen. Tatsächlich ist es nicht so wichtig, welche Art von Daten auf lange Sicht aufgewendet werden, wie wir in der Lage sein möchten, alles zu drücken, was wir für benötigt halten, und einen Bericht herauszuholen.

Grob gesagt haben wir zwei Optionen.

Option 1 ist, eine Lösung basierend auf Apache Solr zu schreiben (speziell mit Verwendung https://issues.apache.org/jira/browse/solr-236). Vorteile dieses Ansatzes:

• kostenlos / Open Source / gute Qualität
• Wir verwenden Solr/Lucene anderswo, damit wir die Domain ziemlich gut kennen
• Gesamtflexibilität über das indizierte, da wir eingehende Daten (im XML -Format) aufnehmen können, sie durch XSLT drücken und an Solr füttern
• Gesamtflexibilität, wie man Suchergebnisse anzeigt. Ähnlich wie bei Schritt können wir eine benutzerdefinierte XSLT -Suchvorlage haben und die Ergebnisse in jedem Format anzeigen, von dem wir für notwendig halten
• Unsere Frontend -Entwickler sind mit XSLT kompetent, so dass der Mechanismus für einen anderen Kunden relativ einfach sein sollte
• Solr bietet Echtzeit- / Volltext- / facettierte Suche, die für uns unbedingt erforderlich sind. Ein schneller Prototyp (basierend auf Solr-, 1M -Datensätzen) konnte Suchergebnisse in 55 ms liefern. Unser geschätztes Maximum von Aufzeichnungen beträgt etwa 1 Mrd. Zeilen (dies ist nicht viel für die typische BI -App), und wenn schlimmer noch schlimmer werden, können wir uns immer Solrcloud usw. ansehen.
• Es gibt Unternehmen, die sehr ähnliche Dinge mit Solr (zum Beispiel) mit Solr (Wonycomb Lexikon) tun.

Nachteile dieses Ansatzes:

• SolR-236 könnte stabil sein oder nicht. Darüber hinaus ist es noch nicht klar, wann/ob es als Teil der offiziellen Veröffentlichung veröffentlicht wird
• Es würde möglicherweise einige Dinge geben, die wir schreiben müssten, um einige bispezifische Funktionen zum Laufen zu bringen. Das klingt ein bisschen so, als würde man das Rad neu erfinden
• Das größte Problem ist, dass wir nicht wissen, was wir in Zukunft brauchen könnten (z.

Option 2 ist eine Integration mit einer kostenlosen oder kommerziellen BI -Software. Bisher habe ich mir angesehen Wabit und wird einen Blick darauf werfen Qlikview, möglicherweise andere. Vorteile dieses Ansatzes:

• Sie müssen das Rad nicht neu erfinden, Software wird (hoffentlich) bewährt und getestet
• Würde uns Zeit retten, auf die wir Probleme damit verbringen könnten, Probleme zu lösen, auf die wir uns spezialisiert haben

Nachteile:

• Da wir ein Java-Shop sind und unsere Lösung plattformübergreifend ist, müssten wir viele Optionen beseitigen, die sich auf dem Markt befinden
• Ich bin mir nicht sicher, wie flexibles BI -Software sein kann. Es würde einige Zeit dauern, um einige BI -Angebote zu durchlaufen, um festzustellen, ob sie flexible Indizierung, Echtzeit- / Volltext -Suche, vollständig anpassbare Ergebnisse usw. durchführen können.
• Mir wurde gesagt, dass Open Source BI -Angebote nicht ausgereift genug sind, während kommerzielle Bis (SAP, andere) Vermögen kostete, beginnen ihre Lizenzen mit Zehntausenden von Pfund/Dollar. Ich bin zwar nicht gegen kommerzielle Wahl an sich, aber es wird zu dem Gesamtpreis führen, der leicht einfach zu groß werden kann
• Ich bin mir nicht sicher, wie gut BI gemacht ist, um mit schema-nicht-Daten zu arbeiten

Ich bin definitiv nicht der beste Kandidat, um die am meisten angemessene Integrationsoption auf dem Markt zu finden (hauptsächlich aufgrund des Fehlens von Wissen im BI -Gebiet). Eine Entscheidung muss jedoch schnell getroffen werden.

War jemand in einer ähnlichen Situation und könnte beraten, welchen Weg oder noch besser man sich über mögliche Vor-/Nachteile der Option Nr. 2 handeln kann? Das größte Problem hier ist, dass ich nicht weiß, was ich nicht weiß;)

Answer 1

Ich habe einige Zeit damit verbracht, mit beiden zu spielen Qlikview und Wabit, und, muss ich sagen, ich bin ziemlich enttäuscht.

Ich hatte die Erwartung, dass die gesamte BI -Branche tatsächlich eine Wissenschaft unter sich hat, aber soweit ich feststellte, ist dies nur ein bloßes Schlagwort. Dieser MSDN -Artikel war eigentlich ein Augenöffner. Das gesamte Geschäft von BI besteht darin, Daten aus gut ormalisierten Schemata zu nehmen (sie nennen es es OLTP), um es in weniger normalisierte Schemata zu setzen (Olap, Schneeflocke- oder Sternentyp) und Indizes für jeden gewünschten Aspekt zu schaffen (Branchenjargon dafür ist Datenwürfel). Der Rest ist nur ein Skript, um die hübschen Grafiken zu erhalten.

OK, ich weiß, dass ich hier die Dinge vereinfachen kann. Ich weiß, ich hätte vielleicht viele verschiedene Aspekte verpasst (schöne Berichte? Export in Excel? Vorhersagen?), Aber aus Sicht der Informatik kann ich hier einfach nichts über einen Datenbankindex hinaussehen.

Mir wurde gesagt, dass einige BI -Werkzeuge die Komprimierung unterstützen. Lucene unterstützt das auch. Mir wurde gesagt, dass einige BI -Tools in der Lage sind, den gesamten Index im Speicher zu halten. Dafür gibt es einen Lucene -Cache.

Apropos zwei Kandidaten (Wabit und Qlikview) - das erste ist einfach unreif (ich habe Dutzende von Ausnahmen, wenn ich versuche, aus dem zu treten, was in ihrer Demo vorgeschlagen wurde), während die anderen nur unter Fenstern arbeitet (nicht sehr nett, aber Ich könnte damit leben) und die Integration würde wahrscheinlich erforderlich sein, dass ich ein VBSCript (Yuck!) Schreiben würde. Ich musste ein paar Stunden in Qlikview -Foren verbringen, um eine einfache Date -Range -Kontrolle zu erhalten, und fehlgeschlagen, da die persönliche Ausgabe, die ich nicht herunterladbare Demo -Projekte unterstützt hatte, auf ihrer Website verfügbar war. Versteh mich nicht falsch, sie sind beide gute Werkzeuge für das, wofür sie gebaut wurden, aber ich sehe einfach keinen Sinn, in die Integration in sie zu machen, da ich nicht viel gewinnen würde.

Um die (argumentierbare) Ungeräte von Solr anzusprechen, werde ich eine abstrakte API definieren, damit ich alle Daten in eine Datenbank verschieben kann, die Volltextabfragen unterstützt, wenn etwas schief geht. Und wenn schlimmer noch schlimmer wird, kann ich immer Sachen über Solr/Lucene schreiben, wenn ich muss.

Answer 2

Wenn Sie sich wirklich in einem Szenario befinden, in dem Sie sich nicht befinden Sicher, was Sie nicht wissen Ich denke, es ist am besten, ein Open-Source-Tool zu erkunden und seine Nützlichkeit zu bewerten, bevor Sie in Ihre eigene Implementierung eintauchen. Es könnte sehr gut sein, dass die Verwendung der Open-Source-Lösung Ihnen hilft, Ihr eigenes Verständnis und die erforderlichen Funktionen weiter zu kristallisieren.
Ich hatte zuvor mit einer Open-Source-Lösung namens gearbeitet Pentaho. Ich hatte ernsthaft das Gefühl, dass ich viel mehr verstanden habe, indem ich lernte, Pentahos Funktionen für mein Ende zu verwenden. Wie bei den meisten Open-Source-Lösungen schien Pentaho zuerst wie bei den meisten Open-Source-Lösungen ein bisschen einschüchternd zu sein, aber ich schaffte es, in einem Monat einen guten Griff zu haben. Wir haben auch mit gearbeitet Kessel ETL Werkzeug und Mondrian Würfel - von denen ich denke, dass die meisten ernsthaften BI -Werkzeuge heutzutage auf dem neuesten Stand sind.
Früher waren alle diese Komponenten unabhängig, aber ich glaube, Pentaho hat all diese Projekte in Besitz genommen.

Aber wenn Sie zuversichtlich sind, was Sie brauchen und was Sie nicht benötigen, würde ich empfehlen, ein eigenes grundlegendes Berichterstattungsinstrument zusätzlich zu einer Mondrian -Implementierung zu erstellen. Das Anpassen eines anspruchsvollen Open-Source-Tools kann in der Tat ein großes Problem sein. Außerdem gibt es Lizenzen, vor denen vorsichtig sein muss. Ich glaube, Pentaho ist GPL, obwohl Sie das vielleicht überprüfen möchten.

Answer 3

Zuerst sollten Sie klarstellen, was Ihre Berichte zeigen sollten. Welche Berichtsfunktion benötigen Sie? Welche Ausgangsformate möchten Sie? Möchten Sie es im Browser (HTML) oder als PDF oder mit einem interaktiven Betrachter (Java/Flash) anzeigen. Wo sind die Daten (Datenbank, Java usw.)? Benötigen Sie eine Ad-hoc-Berichterstattung oder nur einige hart codierte Berichte? Dies sind nur einige Fragen.

Ohne Antworten auf diese Frage ist es schwierig, eine echte Empfehlung zu geben, aber meine allgemeine Empfehlung wäre i-net klare Berichte (Früher wurde I-NET-Kristallklaren bezeichnet). Es ist ein Java -Tool. Es ist ein kommerzielles Werkzeug, aber die Kosten sind niedriger als SAP und CO.