Get best of the week

De qué hicimos JET BI. Sistema de inteligencia de negocios de arquitectura sin digresiones líricas



En una publicación anterior, hablé sobre la evolución de los sistemas de BI y cómo llegamos a comprender que es mejor crear su propia plataforma que adaptarse a las existentes.

Hoy, como prometí, estoy hablando de la arquitectura de nuestra nueva plataforma, que, espero, sea una buena solución para construir cualquier sistema de BI.

Arquitectura funcional


En el sistema, se pueden distinguir funcionalmente dos "núcleos" principales.

El núcleo de visualización y BI (el equipo y yo lo llamamos "lector") Se dedica al hecho de que filtra datos, calcula hechos y mediciones, calcula y almacena en caché los agregados, etc. En general, el OLAP más común. El soporte para computación en memoria también está disponible. El motor ETL que desarrollamos ocupa un lugar separado, que admite ambos métodos de carga estándar (por ejemplo, SQL, consulta MongoDB, descarga de archivos de Excel, etc.) y carga cualquier cosa desde cualquier lugar usando scripts JS. ¿Cómo exactamente? El hecho es que "vinculamos" el cargador JS con una API especial, cuyo propósito es proporcionar un conjunto de métodos fáciles de aprender que tienen mayor demanda de consultas a diferentes fuentes, así como la transformación de datos (por ejemplo, transponer, unir, agregar columnas calculadas, varios tipos funciones matemáticas y estadísticas).

Lenguaje

Javascript? ¿Estas loco?

Quizás ...

Pero la elección de JS como lenguaje y el rechazo de la invención de otra bicicleta, como suele ser el caso en las plataformas de BI, no es accidental. La popularidad del lenguaje en sí, la simplicidad de su desarrollo (al menos para las tareas de ETL) y la gran cantidad de especialistas en el mercado resultaron ser factores decisivos para nosotros. En general, de acuerdo con la ideología de nuestra plataforma, el motor ETL es similar al mecanismo de "scripts de carga" utilizado, por ejemplo, en QlikView, excepto por el lenguaje en el que se escriben estos scripts. Espero que muchos proveedores de plataformas de BI tarde o temprano lleguen a un lenguaje de programación universal, pero por ahora estamos trabajando con lo que es.

El núcleo de la lógica empresarial.Es más bien un marco que consolida la arquitectura de software y proporciona una serie de API universales con las que puede agregar componentes analíticos de información aplicados adicionales al sistema.

De lo que ya tenemos, podemos notar:

  • Constructor y manejador de formularios de ingreso de datos.
  • Entorno de modelado y análisis hipotético
  • Sistema de gestión de pedidos
  • Depósito de documentos electrónicos
  • Proyecto y módulo de gestión de proyectos

Me gustaría enfatizar que estos componentes están presentes en el sistema por una razón y no viven sus propias vidas. Están estrechamente relacionados entre sí y directamente con el sistema de visualización e informes. De hecho, se convierten en proveedores o consumidores de datos para ello. Por ejemplo, desde el sistema de gestión de pedidos, puede hacer un informe simple desde cero desde cero que muestre el estado de todos los pedidos y una lista de las personas perezosas más maliciosas. Y desde el módulo de gestión de proyectos, obtenga los datos de los proyectos más "estancados" e identifique el motivo de los retrasos.

Arquitectura técnica


El backend de la aplicación se ejecuta bajo Node.JS, intercalando una serie de componentes nativos críticos (en términos de rendimiento). Al igual que cualquier aplicación Node.JS, el sistema se puede agrupar, poner en contenedores e implementar en cualquier entorno que cumpla con los requisitos de Node.

Para almacenar metadatos, puede usar la mayoría de los DBMS relacionales populares, que a menudo implementamos en PostgreSQL. La base de datos almacena toda la metainformación sobre informes, paneles de control, procesos ETL, módulos adicionales, etc. El sistema también se puede usar como una herramienta para llenar el almacenamiento de datos de terceros. Para pequeñas cantidades de datos, puede organizar la visualización en modo ROLAP, es decir, directamente desde los sistemas de origen. Algo así como el "modelo asociativo" de QlikView también está presente. Si selecciona dos o más conjuntos de datos como fuente de datos para el visualizador, se combinarán de acuerdo con los nombres de las columnas en un solo conjunto.

Frontend es un clásico SPA en React, bibliotecas relacionadas y módulos adicionales de JET BI. La comunicación con el backend ocurre a través del REST más común, parte del código es isomorfo, es decir, es utilizado por el frente y la parte posterior. Todo el código es ES7 con anotaciones de tipo (Flow), ejecutado a través de Babel. Abandonamos Typecript a favor de Flow, porque cuando comenzamos, este último dedujo los tipos un poco mejor.

Muy a menudo (en aproximadamente el 80% de los casos) tomamos módulos de código abierto listos para usar y no inventamos los nuestros (en el backend con un poco menos de frecuencia). Esto simplifica y reduce el costo de desarrollo y soporte, pero reduce ligeramente la flexibilidad. Hubo errores de cálculo, después de lo cual algunas de las bibliotecas eventualmente tuvieron que reescribirse por su cuenta.

Conclusión


Al final, me gustaría decir que yo, como arquitecto, me complace que el "marco" del sistema resultó ser bastante sólido y estable, por un lado, y por otro, universal y con un margen suficiente de flexibilidad (a pesar de la abundancia de las bibliotecas de código abierto antes mencionadas). Es como un árbol de Navidad, en el que colgamos constantemente juguetes nuevos. Después de todo, el árbol debe soportar juguetes de varias variedades y rayas, y al mismo tiempo no caer bajo su peso. En mi opinión, este equilibrio se ha logrado en JET BI, lo que da confianza en que se implementarán nuestros planes para el desarrollo del sistema.

Albert Nurutdinov, arquitecto, Jet Infosystems

More articles:


All Articles