Get best of the week

Do que criamos o JET BI. Arquitetura Business Intelligence System sem digressões líricas



Em um post anterior, falei sobre a evolução dos sistemas de BI e como chegamos a entender que é melhor criar sua própria plataforma do que se adaptar às já existentes.

Hoje, como prometido, estou falando sobre a arquitetura de nossa nova plataforma, que, espero, seja uma boa solução para a construção de qualquer sistema de BI.

Arquitetura funcional


No sistema, dois "Núcleos" principais podem ser funcionalmente distinguidos.

O núcleo da visualização e BI (a equipe e eu chamamos de "leitor") Ele se dedica ao fato de filtrar dados, calcular fatos e medidas, calcular e armazenar em cache agregados, etc. Em geral - o OLAP mais comum. Suporte para computação na memória também está disponível. Um local separado é ocupado pelo mecanismo ETL que desenvolvemos, suportando os dois métodos de carregamento padrão (por exemplo, SQL, consulta MongoDB, descarregando de arquivos do Excel etc.) e carregando qualquer coisa de qualquer lugar usando scripts JS. Como exatamente? O fato é que "vinculamos" o carregador JS a uma API especial, cujo objetivo é fornecer um conjunto de métodos fáceis de aprender que são mais procurados por consultas a diferentes fontes, além de transformação de dados (por exemplo, transpor, ingressar, adicionar colunas calculadas, vários tipos funções matemáticas e estatísticas).

Linguagem

Javascript? Você é louco?

Talvez ...

Mas a escolha do JS como idioma e a rejeição da invenção de outra bicicleta, como costuma ser o caso nas plataformas de BI, não são acidentais. A popularidade da linguagem em si, a simplicidade de seu desenvolvimento (pelo menos para tarefas de ETL) e o grande número de especialistas no mercado acabaram sendo fatores decisivos para nós. Em geral, de acordo com a ideologia de nossa plataforma, o mecanismo ETL é semelhante ao mecanismo de "carregamento de scripts" usado, por exemplo, no QlikView, exceto no idioma em que esses scripts são escritos. Espero que muitos fornecedores de plataformas de BI cheguem mais cedo ou mais tarde a uma linguagem de programação universal, mas por enquanto estamos trabalhando com o que é.

O núcleo da lógica de negócios.É uma estrutura que consolida a arquitetura do software e fornece várias APIs universais com as quais você pode adicionar componentes analíticos de informações aplicados adicionais ao sistema.

Pelo que já temos, podemos observar:

  • Construtor e manipulador para formulários de entrada de dados
  • Ambiente de modelagem e análise what-if
  • Sistema de Gerenciamento de Pedidos
  • Repositório Eletrônico de Documentos
  • Projeto e módulo de gerenciamento de projetos

Eu gostaria de enfatizar que esses componentes estão presentes no sistema por um motivo e não vivem suas próprias vidas. Eles estão intimamente relacionados entre si e diretamente ao sistema de visualização e relatório. De fato, eles se tornam fornecedores ou consumidores de dados. Por exemplo, no sistema de gerenciamento de pedidos, é possível fazer um relatório simples do zero, do zero, do zero, que exibe o status de todos os pedidos e uma lista das pessoas preguiçosas mais maliciosas. E, no módulo de gerenciamento de projetos, obtenha os dados dos projetos mais "paralisados" e identifique o motivo do atraso.

Arquitetura técnica


O back-end do aplicativo é executado no Node.JS, intercalando vários componentes nativos críticos (em termos de desempenho). Como qualquer aplicativo Node.JS, o sistema pode ser clusterizado, contêiner e implementado em qualquer ambiente que atenda aos requisitos do Node.

Para armazenar metadados, você pode usar a maioria dos DBMSs relacionais populares, os quais geralmente implantamos no PostgreSQL. O banco de dados armazena todas as meta-informações sobre relatórios, painéis de controle, processos ETL, módulos adicionais, etc. O sistema também pode ser usado como uma ferramenta para preencher o armazenamento de dados de terceiros. Para pequenas quantidades de dados, você pode organizar a visualização no modo ROLAP, ou seja, diretamente dos sistemas de origem. Algo como o "modelo associativo" do QlikView também está presente. Se você selecionar dois ou mais conjuntos de dados como fonte de dados para o visualizador, eles serão combinados de acordo com os nomes das colunas em um único conjunto.

Frontend é um SPA clássico no React, bibliotecas relacionadas e módulos adicionais do próprio JET BI. A comunicação com o back-end ocorre através do REST mais comum, parte do código é isomórfica, ou seja, é usada pela frente e por trás. Todo o código é ES7 com anotações de tipo (Flow), executadas em Babel. Abandonamos o Typecript em favor do Flow, porque quando começamos, este último deduziu os tipos um pouco melhor.

Frequentemente (em cerca de 80% dos casos), pegamos módulos de código aberto prontos e não inventamos os nossos (no back-end com um pouco menos de frequência). Isso simplifica e reduz o custo de desenvolvimento e suporte, mas reduz um pouco a flexibilidade. Houve erros de cálculo, após os quais algumas das bibliotecas ainda tiveram que ser reescritas por conta própria.

Conclusão


No final, gostaria de dizer que, como arquiteto, estou satisfeito por a “estrutura” do sistema ter se mostrado bastante sólida e estável, por um lado, e por outro lado, universal e com uma margem de flexibilidade suficiente (apesar da abundância das bibliotecas de código aberto mencionadas acima). É como uma árvore de Natal, na qual penduramos constantemente novos brinquedos. Afinal, a árvore deve suportar brinquedos de várias variedades e listras e, ao mesmo tempo, não cair sob seu peso. Na minha opinião, esse equilíbrio foi alcançado no JET BI, o que garante que nossos planos para o desenvolvimento do sistema serão implementados.

Albert Nurutdinov, Arquiteto, Jet Infosystems

More articles:


All Articles