一种可扩展的自助数据分析方法及系统与流程

1.本发明涉及计算机和数据分析技术，具体涉及一种可扩展的自助数据分析方法及系统。


背景技术：

2.目前数据分析软件发展都比较成熟，国内外产品众多，但绝大部分产品都不支持开放扩展。而做数据分析时经常会出现系统无法满足需求的情况，比如有个新的算法需要加入分析过程中，或者需要增加新的分析模型，遇到这种情况时，都需要找到系统开发商去支撑，周期都特别漫长，且价格昂贵，严重阻碍分析工作的开展，这也是为什么大部分数据分析工具都无法全面使用起来的一个主要原因。
3.此外，现有数据分析系统，其分析模型和核心分析流程管理是紧密混杂在一起的，每增加新的分析模型，都需要修改和变得核心代码，这给相应的计算机程序带来了不稳定。


技术实现要素：

4.鉴于现有技术所存在的问题，本发明提出一种可扩展的自助数据分析方法及系统，以微内核方式实现了对数据分析模型的插件管理以及快速扩展的功能，以分布式架构实现了对分析过程的稳定性进行了保障，功能扩展易于实现，让各类个性化的需求都能快速实现，有效促进数据分析领域的健康发展，系统结构稳定，具备高可用、数据零丢失的特点。
5.本发明分析方法采用如下技术方案来实现：可扩展的自助数据分析方法，包括以下步骤：
6.s1、定义数据分析的底层结构，将数据分析的实体对象进行抽象，定义分析对象及各分析对象之间的联系，同时对分析操作进行抽象化，形成系统的基础架构模型；
7.s2、基于微内核架构设计、封装核心层；所述核心层为分析引擎，负责将业务层的分析任务转换成数据查询任务并返回数据，以支撑不同业务场景的分析需求；核心层基于分布式架构开发扩展插件，将业务功能扩展的变化封装在插件里；
8.s3、定义可扩展接口，根据核心层提供的分析能力，将扩展层各业务功能按标准接口形式进行开放；
9.s4、将步骤s1所定义的分析对象及各分析对象之间的联系，以插件的形式设置为业务层；并根据实际业务计算逻辑开发分析对象中相应的分析模型，通过核心层进行校验和管理，核心层以事件的形式驱动插件运行。
10.在优选的实施例中，步骤s1根据综合业务，对实体对象抽象后，定义的分析对象包括：分析看板、分析图形、分析窗口、分析节点、分析路径、分析模型及分析方法；其中，分析看板负责管理分析窗口，以及布局分析窗口的位置；分析路径负责记录分析节点之间的先后计算、依存关系；分析窗口负责将分析节点提供的数据以及图形配置展现出来；分析节点设有可扩展的分析模型以及分析方法，分析模型是分析算法的参数配置且可持久化存储，
分析方法通过分析算法的业务逻辑代码实现，根据分析模型定义的参数配置执行实际的分析计算。
11.进一步优选地，所述分析对象的数据通过分析操作和分析操作参数进行修改变动；对分析看板的任意改动将产生一个分析操作，每个分析操作均为可序列化的。
12.本发明分析系统采用如下技术方案来实现：可扩展的自助数据分析系统，包括：
13.底层结构定义模块，用于将数据分析的实体对象进行抽象，定义分析对象及各分析对象之间的联系，同时对分析操作进行抽象化，形成系统的基础架构模型；
14.核心层设计模块，用于基于微内核架构设计、封装核心层；所述核心层为分析引擎，负责将业务层的分析任务转换成数据查询任务并返回数据，以支撑不同业务场景的分析需求；核心层基于分布式架构开发扩展插件，将业务功能扩展的变化封装在插件里；
15.可扩展接口定义模块，用于根据核心层提供的分析能力，将扩展层各业务功能按标准接口形式进行开放；
16.业务层设置模块，用于将底层结构定义模块所定义的分析对象及各分析对象之间的联系，以插件的形式设置为业务层；并根据实际业务计算逻辑开发分析对象中相应的分析模型，通过核心层进行校验和管理，核心层以事件的形式驱动插件运行。
17.本发明在提供自助数据分析基础功能的同时，将各业务功能的扩展属性都开放出来，只需要按照规定的接口标准做功能实现，即可在系统上扩展需要的功能，让各类个性化的需求都能快速实现，有效促进数据分析领域的健康发展。与现有技术相比，本发明主要有如下优点及有益效果。
18.1、本发明以微内核方式实现了对数据分析模型的插件管理以及快速扩展的功能，同时微内核保证了系统架构的稳定性，新的模型均属于挂载的插件，无需修改核心代码，不会影响系统内核，使得整个系统更加健壮。本发明还以分布式架构实现了对分析过程的稳定性进行了保障，具备高可用、数据零丢失的特点。
19.2、本发明基于微内核结构的核心层中具备完善事件机制和分析生命周期钩子，具备高实时性的响应式编程，这样使得更易于扩展开发新的插件，插件的代码只需在一个地方注册事件或挂载分析生命周期钩子即可，体现了高内聚-低耦合的思想，职责单一，易于维护。内置的智能标题、节点执行、刷新计划、预告警等插件都是一个文件实现功能的开发，易于实现。
20.3、本发明具备多用户分析会话功能，同样的一个分析路径结构，对于不同用户，他们的权限往往是不同的，因此能够根据不同用户启动不同的分析会话，分析会话里带上当前用户的权限约束条件。
21.4、将分析操作(action)请求和实际分析执行分离，使得分析操作请求拥有更为稳定的接口响应时间，不会因为业务数据库资源不足导致操作响应时间延长。
22.5、在微内核的架构下，拥有严格的调用范围约束，降低编写错误代码的几率，例如不在分析操作的执行期间，无法调用修改看板的数据，保证修改都是通过分析操作指令完成的。每个操作都有确定性结果，输入和输出固定，因此可以更方便地进行单元测试；可以采用json文件来记录看板的状态，每个分析操作的执行，代表着看板的状态转移。此外，分析操作(action)为可序列化的，能够进行撤销、重做，甚至是重播分析过程，再现看板是如何一步一步分析生成的。
23.6、传统的负载均衡都是利用一些预先定义好的规则，而在本发明中采用了ai实时计算最佳负载，能根据各个机器的实时资源供应情况，智能负载均衡，达到最佳的资源利用率。
附图说明
24.图1是本发明实施例中数据分析方法的流程图；
25.图2是本发明实施例中抽象定义的分析对象关系图；
26.图3是本发明实施例中设计的微内核系统的应用架构图；
27.图4是本发明实施例中分析操作接口调用、异步执行过程示意图。
具体实施方式
28.下面将结合实施例和附图，对本发明作进一步描述；显然，所描述的实施例只是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员没有付出创造性劳动前提下所获得的所有其他实施例都属于本发明保护的范围。
29.实施例1
30.如图1所示，本实施例中可扩展的自助数据分析方法，包括以下步骤：
31.s1、定义数据分析的底层结构：将数据分析的实体对象进行抽象，定义分析对象及各分析对象之间的联系，同时也对分析操作进行抽象化，形成系统的基础架构模型。
32.本实施例根据综合业务，对实体对象抽象后，定义了如下分析对象：分析看板(dashboard)、分析图形(analysisgraph)、分析窗口(analysiswindow)、分析节点(analysisnode)、分析路径(analysisconnector)、分析模型(analysismodel，可扩展)、分析方法(analysis method，可扩展)，如图2所示。图2概要地展示了分析看板、分析路径、分析窗口、分析节点等分析对象之间的关系，其中分析看板负责管理分析窗口，以及布局分析窗口的位置；分析路径负责记录分析节点之间的先后计算、依存关系；分析窗口负责将分析节点提供的数据以及图形配置展现出来；分析节点设有可扩展的分析模型以及分析方法，分析模型是分析算法的参数配置且可以持久化存储，而分析方法通过分析算法的业务逻辑代码实现，根据分析模型定义的参数配置执行实际的分析计算。其中，分析模型包括转化分析、多维分析、算子分析等分析类型。
33.分析对象的数据通过分析操作(analysis action，可扩展)和分析操作参数(analysis action arguments，可扩展)进行修改变动。凡用户对看板的任意改动都会产生一个分析操作，例如移动图表的坐标位置，修改图表展示类型，增加拟合计算。值得注意的是，每个分析操作都是可序列化的，它可以作为日志化保存，可以重播，回放分析过程。
34.优选地，为了提升性能，所有的分析对象具备两种序列化方式，一种是基于protobuf的二进制序列化，另一种是基于json的序列化。基于protobuf的序列化占用空间小，性能高，适用于缓存加载，用于服务端集群leader和follower之间的分析对象，以提升对用户端请求的响应性能。基于json的序列化具备良好的可读性，用于前端与后端之间的分析对象，此外数据库存储使用基于json的序列化结构，便于升级。
35.s2、基于微内核架构设计、封装核心层：核心层作为分析引擎，用于确保数据分析系统稳定、高效运行，主要负责将业务层的分析任务转换成数据查询任务并返回数据，核心
层的工作要尽量抽象，确保能够支撑不同业务场景的分析需求。
36.本实施例中，核心层的设计思路参考微内核架构。微内核架构的本质就是将业务功能扩展的变化封装在插件里，从而达到快速、灵活扩展的目的，而又不影响整体系统的稳定。核心系统(core system)功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断扩展。由于业务功能会随着业务需求的变更而一直变化，即数据分析的代码会调整，本实施例所设计的基于微内核的核心层架构却极少会变动，这样整个数据分析系统会更加稳定；如果系统在业务扩展后出现问题，也只是变动的那个业务扩展模块，不会影响到其他模块，因而也为系统运行过程中快速排查问题提供了可行性。
37.本实施例在核心层中，基于分布式架构开发扩展插件。而分布式架构根据cap理论，一致性(consistency)、可用性(availability)、分区容错性(partition tolerance)，这三个要素最多只能同时保证两点，三者不可兼顾。为了保证分析过程中数据不丢失，那么要有分区容错性，数据一定要冗余，存有备份。再者，由于分析过程中一个分析看板往往是有一个用户或者几个用户，不是全局所有的用户。因此本实施例在cap理论三要素中最终选择了ap，即可用性(availability)和分区容错性(partition tolerance)，保证了系统的高可用性和分区容错性。
38.此外，本实施例的核心层在算法上选择了raft算法，结合分析操作日志化，当用户发起一个分析操作，首先序列化为json文本，统一转发到leader，再由leader分发给相对的follower机器(可以是多台，冗余，互为备份)。当部分机器发生故障宕机时，集群自动恢复正常。如果是leader宕机了，那么集群重新选举leader；如果是follower宕机了，其数据会从其他的follower备份还原数据，再次形成冗余备份，保障数据安全。
39.在核心层还设置查询计算层。查询计算层这部分是serverless架构。serverless的全称是serverless computing无服务器运算，又被称为函数即服务(function-as-a-service，缩写为faas)，是云计算的一种模型。本实施例在查询计算层引入ai来做资源调度，首先是读取数据库的信息，诸如数据量、数据类型等评估一个资源消耗量，再采集提供计算的机器的状态信息，例如cpu、内存、磁盘、带宽等，由ai选择合适的机器来计算处理，可以动态调整调度策略。具体来说，ai根据服务器cpu、内存、磁盘、带宽的利用率情况，结合程序任务的资源消耗，自动做资源调度的均衡，实现智能负载均衡，使资源利用率达到最佳状态。
40.为了让整个系统可以运转，每个地方状态改变都由事件触发，可配置事件是否只在服务端内部流转还是发送给前端，部分事件也可以直接发给前端。另外，在计算处理过程也加了生命周期钩子，例如，分析节点添加前(后)，计算开始前(后)，计算完成前(后)等。举例来说，数据脱敏插件运行在计算完成后这个生命周期钩子上，当数据计算完成，即将发送给前端的时候，如果需要进行脱敏，数据脱敏插件首先会拦截事件，再进行数据脱敏，最后再以事件通知到前端获取数据，渲染界面。
41.s3、定义可扩展接口。根据核心层提供的分析能力，将扩展层(也叫接口层)各业务功能按标准接口形式进行开放，扩展层支持的功能包括数据平台的自定义扩展、分析模型的扩展、分析算法的扩展、分析操作的扩展、图形渲染的扩展等。
42.对于一个微内核的架构，支持扩展开发是必须的，因此本实施例对分析模型、扩展插件、分析操作以及api接口进行扩展开发，具体分别如下：
43.扩展分析模型。分析模型主要开发两个部分，一个是模型参数配置(analysis entity)，一个是模型算法(analysismethod)实现。分成两部分是因为，在传统的面向对象编程中，一个对象的属性和方法放在一起，看似没有问题，但是当属性、业务逻辑多的时候，就会造成过于臃肿而难以维护，因此采用了组合的方式。模型参数是要持久化保存的，而模型算法的逻辑代码则不需要，将模型参数配置与模型算法分开可以更方便地看到哪些数据是要保存的，后续升级的时候需要关注哪些数据，提升了系统的维护性，降低了低级错误的发生。
44.扩展分析插件。除了内核已有的一些插件，还可以开发新的插件以增强分析功能，插件的运行有三种方式：1)、接口调用；2)、生命周期钩子调用；3)、分析事件触发。
45.扩展分析操作。分析操作，即对看板执行修改动作，所有的类都继承analysis action类，以保证所有的更改能被记录下来。分析操作有个强制的要求，即必须写正向操作对应的反向操作，以保证任何操作都是可撤销的；如前所述，分析对象都是可序列化成json的，所以内核的测试套件，也对扩展开发的分析操作进行检测，判断是否满足要求。
46.扩展api接口。api接口分为graphql和restful两种类型，可以按需获取各种需要的数据。值得注意的是两种接口都是只读的，符合幂等性，没有副作用。假如接口代码里尝试修改了看板的数据，内核将检测非法修改操作，因此不能修改任何需要持久化存储的数据(如果需要修改数据，需要分析操作实现)。
47.s4、将步骤s1所定义的分析对象及各分析对象之间的联系，以插件的形式设置为业务层；并根据实际业务计算逻辑开发分析对象中相应的分析模型，通过核心层进行校验和管理，核心层以事件的形式驱动插件运行。例如更新条件时，就会自动触发智能标题插件，智能标题插件根据条件生成对应的标题，如果分析节点之间的连接没有锁定，那么智能标题插件将自动级联每个分析节点的标题，并以事件形式实时通知前端更新界面。
48.在本实施例中，微内核系统的应用架构分为三层，分别为接口层、业务层、核心层，如图3所示。其中接口层负责与客户端交互；业务层包含具体分析业务逻辑，包括各种分析模型、分析操作、业务扩展插件等；核心层是整个系统运行的底座，负责和具体业务无关的通用功能，例如：模块加载、事件流控制、执行调度、操作历史管理等。
49.如图4所示，当用户发起分析操作时，核心层对分析操作的接口调用包括以下步骤：一)、用户(即前端)根据需求选择分析模型及参数；二)、将分析模型和对应参数封装成分析操作，发送给服务端(即后端)；三)、master节点调度，将分析操作发给对应的分析引擎，由分析引擎处理分析操作对分析看板的修改。
50.其中，如果在master节点调度过程中涉及数据计算，则将数据计算转到后台，当前的接口请求直接返回后台计算的状态，并将数据计算的内容封装发送给计算调度中心，由计算调度中心根据ai实时预测最快的机器进行计算处理；最后将计算结果以事件的方式返回给分析引擎，再由分析引擎进行后续数据处理(例如：提前序列化成二进制，提升前端获取数据的速度，提升单次http请求速度，提升浏览器端并发能力)，再把事件通知前端获取结果，进行界面渲染。
51.实施例2
52.与实施例1基于相同的发明构思，本实施例提供可扩展的自助数据分析系统，具体包括以下步骤：
53.底层结构定义模块，用于将数据分析的实体对象进行抽象，定义分析对象及各分析对象之间的联系，同时对分析操作进行抽象化，形成系统的基础架构模型；
54.核心层设计模块，用于基于微内核架构设计、封装核心层；所述核心层为分析引擎，负责将业务层的分析任务转换成数据查询任务并返回数据，以支撑不同业务场景的分析需求；核心层基于分布式架构开发扩展插件，将业务功能扩展的变化封装在插件里；
55.可扩展接口定义模块，用于根据核心层提供的分析能力，将扩展层各业务功能按标准接口形式进行开放；
56.业务层设置模块，用于将底层结构定义模块所定义的分析对象及各分析对象之间的联系，以插件的形式设置为业务层；并根据实际业务计算逻辑开发分析对象中相应的分析模型，通过核心层进行校验和管理，核心层以事件的形式驱动插件运行。
57.其中，底层结构定义模块根据综合业务，对实体对象抽象后，定义的分析对象包括：分析看板、分析图形、分析窗口、分析节点、分析路径、分析模型及分析方法；其中，分析看板负责管理分析窗口，以及布局分析窗口的位置；分析路径负责记录分析节点之间的先后计算、依存关系；分析窗口负责将分析节点提供的数据以及图形配置展现出来；分析节点设有可扩展的分析模型以及分析方法，分析模型是分析算法的参数配置且可持久化存储，分析方法通过分析算法的业务逻辑代码实现，根据分析模型定义的参数配置执行实际的分析计算；
58.分析对象的数据通过分析操作和分析操作参数进行修改变动；对分析看板的任意改动将产生一个分析操作，每个分析操作均为可序列化的；当一个分析操作被发起时，核心层对分析操作的接口调用包括以下步骤：前端根据需求选择分析模型及参数；将分析模型和对应参数封装成分析操作，发送给服务端；master节点调度，将分析操作发给对应的分析引擎，由分析引擎处理分析操作对分析看板的修改。
59.本实施例各模块对应执行、实现实施例1的各步骤，在此不赘述。
60.以上实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。