我们从JET BI获得的东西。没有歌词的建筑商务智能系统



在上一篇文章中,我谈到了BI系统的发展以及我们如何理解创建自己的平台要比适应现有平台更好。

今天,正如我所承诺的,我在谈论我们新平台的体系结构,我希望它将是构建任何BI系统的良好解决方案。

功能架构


在系统中,可以在功能上区分两个主要的“核心”。

可视化和BI的核心我称之为团队的“读者”)它涉及以下事实:它过滤数据,计算事实和度量,计算和缓存聚合等。一般来说-最普通的OLAP。还支持内存计算。我们开发的ETL引擎占据了一个单独的位置,既支持标准加载方法(例如SQL,MongoDB查询,从Excel文件卸载等),又可以使用JS脚本从任何地方加载任何内容。到底如何事实是,我们用特殊的API“绑定”了JS加载程序,其目的是提供一组易于学习的方法,这些方法最需要对不同源进行查询以及数据转换(例如,转置,联接,添加计算列,各种数学和统计功能)。JavaScript

语言

?你疯了吗?

也许...

但是,选择JS作为语言以及拒绝另一辆自行车的发明(这在BI平台中通常如此)并非偶然。语言本身的普及,其开发的简便性(至少用于ETL任务)以及市场上的大量专家对我们而言是决定性因素。通常,根据我们平台的意识形态,ETL引擎类似于QlikView中使用的“加载脚本”机制,但这些脚本的编写语言除外。我希望BI平台的许多供应商迟早会采用通用编程语言,但是目前我们正在使用通用语言。

业务逻辑的核心。它是一个框架,可以合并软件体系结构并提供许多通用API,您可以使用它们向系统添加其他应用的信息分析组件。

从我们已经拥有的内容中,我们可以注意到:

  • 数据输入表单的构造函数和处理程序
  • 假设分析和分析环境
  • 订单管理系统
  • 电子文件库
  • 项目和项目管理模块

我要强调的是,这些组件存在于系统中是有原因的,它们并不能独立存在。它们彼此之间密切相关,并且与可视化和报告系统直接相关。实际上,他们成为数据的供应商或消费者。例如,在订单管理系统中,您可以从头开始创建一个简单的报表,从头开始,显示所有订单的状态以及最恶意的懒人列表。从项目管理模块中,获取最“停滞”的项目的数据,并确定滞后的原因。

技术架构


应用程序后端在Node.JS下运行,并散布了许多关键的(就性能而言)本机组件。像任何Node.JS应用程序一样,可以在满足Node要求的任何环境中对系统进行集群,容器化和部署。

要存储元数据,您可以使用大多数流行的关系型DBMS,我们最常在PostgreSQL上进行部署。该数据库存储有关报告,控制面板,ETL过程,附加模块等的所有元信息。该系统还可以用作填充第三方数据存储的工具。对于少量数据,您可以直接在源系统中以ROLAP模式组织可视化。还存在类似QlikView的“关联模型”。如果您选择两个或多个数据集作为可视化器的数据源,则它们将根据列名组合为一个集合。

Frontend是关于React,相关库和JET BI本身的其他模块的经典SPA。与后端的通信是通过最常见的REST进行的,部分代码是同构的,也就是说,它由前端和后端使用。所有代码都是带有类型注释(Flow)的ES7,通过Babel运行。我们放弃了Typescript,而赞成Flow,因为当我们第一次开始时,后者在推断类型方面要好一些。

我们经常(在大约80%的情况下)采用现成的开源模块,而不是发明自己的模块(在后端的频率要低一些)。这简化并降低了开发和支持的成本,但稍微降低了灵活性。进行了错误的计算,之后某些库最终仍然不得不自行重写。

结论


最后,我想对作为架构师的我感到高兴的是,该系统的``框架''一方面变得相当坚固和稳定,另一方面又具有通用性并具有足够的灵活性(尽管上述开源库很丰富)。就像一棵圣诞树,我们不断在上面挂新玩具。毕竟,树应能承受各种变种和条纹的玩具,并且同时不能承受其重量。我认为,在JET BI中已经实现了这种平衡,这使我们有信心执行我们的系统开发计划。

喷气信息系统架构师Albert Nurutdinov

All Articles