Woraus wir JET BI gemacht haben. Architektur Business Intelligence System ohne lyrische Abweichungen



In einem früheren Beitrag habe ich über die Entwicklung von BI-Systemen gesprochen und darüber, wie wir verstanden haben, dass es besser ist, eine eigene Plattform zu erstellen, als sich an vorhandene anzupassen.

Wie versprochen spreche ich heute über die Architektur unserer neuen Plattform, die hoffentlich eine gute Lösung für den Aufbau von BI-Systemen darstellt.

Funktionale Architektur


Im System können zwei Hauptkerne funktional unterschieden werden.

Der Kern von Visualisierung und BI (das Team und ich nennen es "Leser")) Es befasst sich mit der Tatsache, dass es Daten filtert, Fakten und Messungen berechnet, Aggregate berechnet und zwischenspeichert usw. Im Allgemeinen - das gewöhnlichste OLAP. Unterstützung für In-Memory-Computing ist ebenfalls verfügbar. An einem separaten Ort befindet sich die von uns entwickelte ETL-Engine, die sowohl Standardlademethoden (z. B. SQL, MongoDB-Abfrage, Entladen aus Excel-Dateien usw.) als auch das Laden von JS-Skripten von überall aus unterstützt. Wie genau? Tatsache ist, dass wir den JS-Loader mit einer speziellen API „gebunden“ haben, deren Zweck darin besteht, eine Reihe leicht zu erlernender Methoden bereitzustellen, die für Abfragen an verschiedene Quellen sowie für die Datentransformation am gefragtesten sind (z. B. transponieren, verknüpfen, berechnete Spalten hinzufügen, verschiedene Arten) mathematische und statistische Funktionen). Javascript

Sprache

? Sie sind verrückt geworden?

Vielleicht ...

Aber die Wahl von JS als Sprache und die Ablehnung der Erfindung eines anderen Fahrrads, wie es auf BI-Plattformen häufig der Fall ist, ist kein Zufall. Die Popularität der Sprache selbst, die Einfachheit ihrer Entwicklung (zumindest für ETL-Aufgaben) und die große Anzahl von Spezialisten auf dem Markt erwiesen sich für uns als entscheidende Faktoren. Gemäß der Ideologie unserer Plattform ähnelt die ETL-Engine im Allgemeinen dem Mechanismus von „Skripten laden“, der beispielsweise in QlikView verwendet wird, mit Ausnahme der Sprache, in der diese Skripte geschrieben sind. Ich hoffe, dass viele Anbieter von BI-Plattformen früher oder später zu einer universellen Programmiersprache kommen werden, aber im Moment arbeiten wir mit dem, was ist.

Der Kern der Geschäftslogik.Es handelt sich vielmehr um ein Framework, das die Softwarearchitektur konsolidiert und eine Reihe universeller APIs bereitstellt, mit denen Sie dem System zusätzliche angewandte informationsanalytische Komponenten hinzufügen können.

Nach dem, was wir bereits haben, können wir feststellen:

  • Konstruktor und Handler für Dateneingabeformulare
  • Was-wäre-wenn-Modellierungs- und Analyseumgebung
  • Auftragsverwaltungssystem
  • Elektronisches Dokumenten-Repository
  • Projekt- und Projektmanagementmodul

Ich möchte betonen, dass diese Komponenten aus einem bestimmten Grund im System vorhanden sind und kein eigenes Leben führen. Sie sind eng miteinander und direkt mit dem Visualisierungs- und Berichtssystem verbunden. Tatsächlich werden sie entweder Lieferanten oder Konsumenten von Daten dafür. Über das Auftragsverwaltungssystem können Sie beispielsweise einen einfachen Bericht von Grund auf neu erstellen, der den Status aller Bestellungen und eine Liste der böswilligsten faulen Personen anzeigt. Rufen Sie im Projektmanagementmodul die Daten zu den am stärksten blockierten Projekten ab und ermitteln Sie den Grund für die Verzögerung.

Technische Architektur


Das Anwendungs-Backend wird unter Node.JS ausgeführt und verteilt eine Reihe kritischer (in Bezug auf die Leistung) nativer Komponenten. Wie jede Node.JS-Anwendung kann das System in jeder Umgebung, die die Node-Anforderungen erfüllt, geclustert, containerisiert und bereitgestellt werden.

Zum Speichern von Metadaten können Sie die meisten gängigen relationalen DBMS verwenden, die wir am häufigsten unter PostgreSQL bereitstellen. In der Datenbank werden alle Metainformationen zu Berichten, Kontrollfeldern, ETL-Prozessen, zusätzlichen Modulen usw. gespeichert. Das System kann auch als Tool zum Befüllen von Datenspeichern von Drittanbietern verwendet werden. Für kleine Datenmengen können Sie die Visualisierung im ROLAP-Modus organisieren, dh direkt aus Quellsystemen. So etwas wie das „assoziative Modell“ von QlikView ist ebenfalls vorhanden. Wenn Sie zwei oder mehr Datensätze als Datenquelle für den Visualizer auswählen, werden diese gemäß den Namen der Spalten zu einem einzigen Satz zusammengefasst.

Frontend ist ein klassisches SPA für React, verwandte Bibliotheken und zusätzliche Module von JET BI. Die Kommunikation mit dem Backend erfolgt über das am häufigsten verwendete REST. Ein Teil des Codes ist isomorph, dh er wird von vorne und hinten verwendet. Der gesamte Code ist ES7 mit Typanmerkungen (Flow), die über Babel ausgeführt werden. Wir haben Typescript zugunsten von Flow aufgegeben, da letztere zu Beginn die Typen etwas besser abgeleitet haben.

Sehr oft (in etwa 80% der Fälle) nehmen wir fertige Open-Source-Module und erfinden keine eigenen (im Backend etwas seltener). Dies vereinfacht und reduziert die Kosten für Entwicklung und Support, verringert jedoch die Flexibilität geringfügig. Es gab Fehleinschätzungen, nach denen einige der Bibliotheken schließlich selbst neu geschrieben werden mussten.

Fazit


Abschließend möchte ich sagen, dass ich als Architekt erfreut bin, dass sich das „Framework“ des Systems einerseits als ziemlich solide und stabil herausgestellt hat und andererseits universell und mit einem ausreichenden Flexibilitätsspielraum (trotz der Fülle der oben genannten Open-Source-Bibliotheken). Es ist wie ein Weihnachtsbaum, an den wir ständig neues Spielzeug hängen. Schließlich sollte der Baum Spielzeugen verschiedener Sorten und Streifen standhalten und gleichzeitig nicht unter ihr Gewicht fallen. Meiner Meinung nach wurde dieses Gleichgewicht in JET BI erreicht, was Vertrauen gibt, dass unsere Pläne für die Entwicklung des Systems umgesetzt werden.

Albert Nurutdinov, Architekt, Jet Infosystems

All Articles