具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

应该理解，目前各大互联网公司的离线数据建设一般采用以下两种方式：

方式一，基于Hadoop的MapReduce计算引擎或Spark计算引擎的离线ETL(Extract-Transform-Load，用来描述数据从来源端经过抽取、转换、加载至目的端的过程)。这是当前的主流离线数据处理方案，可以进行维度建模、数仓分层、复杂逻辑处理、多种格式转化、PB级大数据量ETL。

应该理解，Hadoop是由Apacche基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。

还应该理解，MapReduce计算引擎是基于MapReduce算法实现的分布式计算引擎。

还应该理解，Spark计算引擎是专为大规模数据处理而设计的快速通用的计算引擎。

方式二，基于OLAP(Online Analytical Processing，简称联机分析处理)引擎的离线数据处理方案，比如clickhouse、kylin等。这是当前比较热门的离线数据处理方案，可以进行多维数据查询、大数据量预计算、即席查询等。

应该理解，clickhouse是一种用于OLAP的列式数据库管理系统。Kylin是一个开源的分布式分析引擎。

还应该理解，对于方式一而言，基于MapReduce或Spark计算引擎的处理方案，其最大缺陷在于ETL处理时间过长，hive或Spark SQL(Structured Query Language，结构化查询语句)的查询都是分钟级甚至小时级的，无法做到即席查询。此外，上述方式一也无法实现多维数据查询，且其cube查询能力和大数据量预计算能力缺失。对于方式二而言，基于OLAP引擎的处理方案，无法适应数仓分层、维度建模、复杂逻辑处理、多种格式转化等复杂应用场景。

需要说明的是，hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。

对此，本公开实施例提供了一种改进型的用于OLAP引擎的数据处理方案，可以兼顾离线计算引擎和OLAP引擎的优点。即，可以进行维度建模、数仓分层、复杂逻辑处理、多种格式转化、PB级大数据量ETL，也可以进行多维数据查询、大数据量预计算、即席查询。

以下将结合附图和具体实施例详细阐述本公开。

适于本公开实施例的用于联机分析处理引擎的数据处理方法和装置的系统架构介绍如下。

图1示例性示出了适于本公开实施例的系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他环境或场景。

如图1所示，系统架构100可以包括：联机分析处理引擎101、离线计算引擎102、报表端103和数据仓库104。

在本公开实施例中，联机分析处理引擎101与数据仓库104关联，联机分析处理引擎101响应于报表查询请求，可以从数据仓库104中获取用户请求查询的数据报表并反馈给用户。

数据仓库104自下往上依次可以包括：操作数据层(Operational Data Store，简称ODS)，明细数据层(Data Warehouse Detail，简称DWD)，汇总数据层(Data WarehouseSummary，简称DWS)，应用数据层(Application Data Store，简称ADS)。

在本公开实施例中，可以利用联机分析处理引擎101中内嵌的离线计算引擎102对多个数据源的操作数据进行维度建模，得到对应的数据报表。

具体地，联机分析处理引擎101中内嵌的离线计算引擎102，可以对来自多个数据源的操作数据(包括中间表)进行ETL处理，并将经ETL处理后得到的操作数据存入ODS层。进一步，离线计算引擎102还可以从ODS层读取对应的操作数据，并对其进行复杂聚合，得到对应的明细数据，如多事务事实表等，并将获得的明细数据存入DWD层。更进一步，离线计算引擎102还可以对DWD层中的明细数据进行汇总，得到对应的快照表(事实表)和多维表(多个维度表)，并存入DWS层。更进一步，离线计算引擎102可以将对应的至少一个维度表与事实表关联，生成对应的数据报表，并存入ADS层。即，将数据报表存入与OLAP引擎关联的数据库(数据仓库)，以便联机分析处理引擎101响应于来自报表端103的报表查询请求，基于该数据库进行数据报表的查询。

应该理解，图1中的数据仓库的数目仅仅是示意性的。根据实现需要，可以具有任意数目的数据仓库。

适于本公开实施例的用于联机分析处理引擎的数据处理方法和装置的应用场景介绍如下。

应该理解，本公开实施例提供的用于联机分析处理引擎的数据处理方案，可以用于涉及报表展示的智能搜索场景，尤其可以用于多维度数据表的即席查询场景。

根据本公开的实施例，本公开提供了一种用于联机分析处理引擎的数据处理方法。

图2示例性示出了根据本公开实施例的用于联机分析处理引擎的数据处理方法的流程图。

如图2所示，用于联机分析处理引擎的数据处理方法200可以包括：操作S210和S220。

在操作S210，利用联机分析处理引擎对操作数据进行维度建模，得到对应的数据报表。

在操作S220，将数据报表存入与联机分析处理引擎关联的数据库，以便通过联机分析处理引擎查询数据报表。

应该理解，在本公开实施例中，维度建模是数据仓库建设中的一种数据建模方法，将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。简单来讲，维度建模可以理解为，按照事实表和维度表来构建数据仓库和数据集市等。

应该理解，相关技术中，维度建模仅能应用于Spark计算引擎和MapReduce计算引擎等离线计算引擎，无法应用于OLAP引擎，导致利用OLAP引擎进行离线数据建设时，无法适应数仓分层、维度建模、复杂逻辑处理、多种格式转化等复杂应用场景。

本公开实施例中，将维度建模引入OLAP引擎，可以利用OLAP引擎对来自一个或者多个数据源的操作数据进行维度建模，最终得到对应的数据报表，并将获得的数据报表存入与OLAP引擎关联的数据库，以便通过OLAP引擎查询这些数据报表。

通过本公开实施例，在基于OLAP引擎的离线数据建设方案中引入维度建模，使得OLAP引擎也可以具备维度建模能力，因而可以克服相关技术中OLAP引擎因为缺乏维度建模能力而导致无法适应数仓分层、维度建模、复杂逻辑处理、多种格式转化等复杂应用场景的问题，同时可以达到兼顾OLAP引擎和离线计算引擎的优势的技术效果。即，可以进行维度建模、数仓分层、复杂逻辑处理、多种格式转化、PB级大数据量ETL，也可以进行多维数据查询、大数据量预计算、即席查询。

换言之，相关技术中利用独立的离线计算引擎进行维度建模，但是这种方案由于离线计算引擎需要对操作数据进行批量处理，导致报表查询速度很慢。此外，相关技术中利用独立的OLAP引擎可以实时查询数据，但是这种方案的数据建模能力较差。通过本公开实施例，将在OLAP引擎中引入维度建模，因而可以兼顾OLAP引擎和离线计算引擎的优点。

实验表明，在本公开实施例中，在OLAP引擎中引入维度建模后，可以提高数据/任务的执行效率，使最终复杂逻辑的单日任务平均执行时间小于1秒以下，并且可以支持数据的大跨度快速回溯。

实验还表明，通过本公开实施例，可以使报表端近7天的数据查询时间由平均3秒以上降低到0.1秒以下，真正做到了所查即所得，查询无感知。并且，还可以使报表端的数据模型代码量由每张数百行全部降低到几十行，实现轻量级的代码模型。并且，还可以支持数据的大跨度快速回溯。并且，还可以支持复杂逻辑的多维数据查询。并且，使得展示层不再受上游任务的重度依赖。并且，使得OLAP引擎可以拥有数据建模能力和指标扩展能力，进而使得OLAP引擎能应对PB级大数据量的复杂逻辑查询和数据分层调度。并且，维度建模后的数据可以保证数据的历史细节不丢失、能反应历史变化，使得基于维度聚合的数据结构更加清晰。

作为一种可选的实施例，利用OLAP引擎对操作数据进行维度建模，得到对应的数据报表，可以包括如下操作。

在OLAP引擎内嵌入离线计算引擎。

利用OLAP引擎内嵌入的离线计算引擎，对操作数据进行维度建模，得到对应的数据报表。

通过本公开实施例，在OLAP引擎内嵌离线计算引擎，以使OLAP引擎具备维度建模能力。而内嵌离线计算引擎的OLAP引擎的维度建模能力与独立的离线计算引擎的维度建模能力相比，前者的能力更强，且对离线数据的处理效率更高，因而可以提高数据/任务的处理效率，并且可以通过OLAP引擎对数据报表实现即席查询。

进一步，作为一种可选的实施例，在OLAP引擎内嵌入离线计算引擎，可以包括：在OLAP引擎内嵌入Spark计算引擎或MapReduce计算引擎。

通过本公开实施例，可以兼顾OLAP引擎和Spark计算引擎(或MapReduce计算引擎)的优点。即，在OLAP引擎内嵌Spark计算引擎(或MapReduce计算引擎)，以使OLAP引擎具备维度建模能力。而内嵌离线计算引擎的OLAP引擎的维度建模能力与独立的离线计算引擎的维度建模能力相比，前者的能力更强，且对离线数据的处理效率更高，因而可以提高数据/任务的处理效率，并且可以通过OLAP引擎对数据报表实现即席查询。

在本公开的一个实施例中，可以在OLAP引擎中内嵌入离线计算引擎，由OLAP引擎利用内嵌的离线计算引擎对操作数据或中间表进行预处理，使得来自不同数据源的操作数据或中间表能够预处理成事实表和与之关联的多个维度表，从而实现维度建模。此外，还可以利用OLAP引擎天然的实时查询能力，对基于维度建模生成的数据报表进行即席查询，实现实时地多维度数据查询。

应该理解，基于spark离线计算引擎或MapReduce离线计算引擎均无法做到实时查询，并且基于OLAP引擎无法做到离线数据批处理，而报表端的数据查询需要做到实时查询，并且需要做到大跨度数据回溯。因而可以将上述的离线计算引擎与OLAP引擎结合，以兼顾两种引擎各自的优势。但是，简单地将两种引擎结合，势必需要跨越多个平台进行离线数据处理，导致数据流过长。

对此，本公开实施例提出将spark离线计算引擎或MapReduce离线计算引擎嵌入OLAP引擎内，可以解决实时、准确地进行数据查询与数据流过长之间的矛盾，同时可以兼顾两种引擎各自的优势。

在本公开实施例中，由内嵌的离线计算引擎(即离线数据平台)负责对数据仓库中ODS层的操作数据和DWD层的明细数据进行离线批处理，由OLAP引擎负责对数据仓库中DWD层的明细数据和ADS层的数据报表进行数据实时查询。与OLAP引擎关联的数据仓库中的所有改造后的数据，还能方便公司级的数据流通。

示例性的，用于OLAP引擎的报表查询流程可以参考图3。具体流程可以包括如下操作：将从多个数据源抽取的操作数据存入数据仓库；调度数据仓库中的ODS层数据并进行ETL处理；将处理结果导入OLAP引擎的数据仓库；利用内嵌的离线计算引擎调度数据仓库中的DWD层数据和DWS层数据并进行ETL处理；将处理结果再次导入OLAP引擎的数据仓库；为了数据流通，可以将调度DWD层数据和DWS层数据进行ETL处理得到的中间表导入数据仓库的ODS层；基于数据仓库的各数据层展示数据报表和/或执行临时跑数据操作。

进一步，作为一种可选的实施例，利用OLAP引擎内嵌入的离线计算引擎，对操作数据进行维度建模，得到对应的数据报表，可以包括：利用OLAP引擎内嵌入的离线计算引擎，执行以下操作。

对操作数据进行维度建模，得到对应的事实表和维度表。

将上述操作得到的维度表与事实表关联，得到对应的数据报表。

在本公开的一个实施例中，通过在OLAP引擎内嵌入离线计算引擎，基于打点规范的数据源，同时基于内嵌的离线计算引擎如Spark离线计算引擎的复杂逻辑处理能力，从数据源抽取操作数据，并对抽取的数据进行数据清洗、格式转换后，将最终得到的操作数据导入OLAP引擎的数据仓库的ODS层。进一步，在OLAP引擎中利用内嵌的离线计算引擎如Spark离线计算引擎，对ODS层的操作数据进行离线批处理后导入上述数据仓库的DWD层。进一步，在OLAP引擎中利用内嵌的离线计算引擎如Spark离线计算引擎，对DWD层中的数据进行复杂聚合，并将结果数据继续导入上述数据仓库的DWS层。进一步，基于DWS层中的数据进行事实表与维度表的映射后可以将得到的数据报表直接存入上述数据仓库的ADS层。

示例性的，通过在OLAP引擎内嵌的离线计算引擎实现的维度建模，可以参考图4。如图4所示，最终生成的数据报表可以包括XX交易多事务事实表，以及与该事实表关联的类目维度表、售后维度表、杂项维度表、用户维度表、店铺维度表和商品维度表。如图4所示，XX交易多事务事实表可以包括：订单ID、用户ID、店铺ID、商品ID、购买数量、售后ID、一级品类ID、下单时间、支付时间、订单状态更新时间、退款全额、分区时间和下单日期等信息。类目维度表可以包括：一级品类ID和一级品类名称等信息。售后维度表可以包括：售后ID、售后单申请时间、售后单状态和售后单更新时间等信息。杂项维度表可以包括：订单ID、支付状态、订单状态、订单渠道、外部内容来源、订单内容来源、支付渠道、风险标识、设备类型和业务来源标识等信息。用户维度表可以包括：用户ID、用户收货地址ID、用户购买偏好、用户最后登录时间等信息。店铺维度表可以包括：店铺ID、店铺名称、店铺成立时间、店铺第一笔交易时间等信息。商品维度表可以包括：商品ID、商品支付金额、商品单价等信息。

通过本公开实施例，将OLAP引擎和离线计算引擎打通，可以实现基于维度建模的OLAP引擎离线数据处理方案，该方案可以进行维度建模，可以进行复杂逻辑查询，可以实现快速例行调度。

本公开实施例中，首次将OLAP引擎、离线计算引擎、报表端多维查询数据流全链路打通，具有针对复杂统计结果的快速查询能力和针对明细数据的多维查询能力，即，具有上述的双重能力。

此外，作为一种可选的实施例，将数据报表存入与OLAP引擎关联的数据库，可以包括：将数据报表存入与OLAP引擎关联的数据库的应用数据层，OLAP引擎响应于报表查询请求使用。

示例性的，通过在OLAP引擎内嵌的离线计算引擎实现的数仓分层，可以参考图5。如图5所示，数据仓库可以包括DWD层和ADS层。其中，DWD层为明细数据，可以包括各种事实表，如交易多事务事实表、小程序多事务事实表、App多事务事实表、H5多事务事实表、直播多事务事实表等。基于交易多事务事实表获得的统计监测信息和运营决策信息可以存入ADS层。基于交易多事务事实表获得的统计监测信息可以包括各种快照表，如店铺交易快照表、用户交易快照表、买卖双方交易快照表、全量交易快照表、商品交易快照表等。基于交易多事务事实表获得的运营决策信息可以包括：用户生命周期、售后、电商GMV、交易风控、爆品/商品销量等信息。基于小程序多事务事实表、App多事务事实表、H5多事务事实表等获得的统计监测信息可以包括各种快照表，如小程序流量快照表(如启动次数、时长等)、小程序留存快照表(如新增留存、活跃留存等)、App流量快照表(如启动次数、时长等)、App留存快照表(如新增留存、活跃留存等)、H5流量快照表(如启动次数、时长等)、H5留存快照表(如新增留存、活跃留存等)等。基于小程序多事务事实表、App多事务事实表、H5多事务事实表等获得的运营决策信息可以包括：全端流量(如用户规模、留存、每日新增、渠道来源等)、用户画像、用户行为轨迹和用户喜好等。基于直播多事务事实表获得的统计监测信息可以包括商家/直播快照表。基于直播多事务事实表获得的运营决策信息可以包括开播场次/时长、商家/主播人数、观看时长/开播在线峰值、直播互动率和直播转化漏斗等。如图5所示，DWD层数据可以满足10％的临时需要(如解放人力)。ADS层数据可以用户报表展示，可以满足70％的长期统计监测需求(如有规范、查询快速、避免重复开发)，且还可以满足20％的运营决策需求(如有规范、查询快速)。如图5所示，ADS层中70％的长期统计监测数据可以提供核心指标(如最粗粒度、最刚需、每天都需要查看的数据等)。ADS层中70％的长期统计监测数据还可以提供基础指标(如长期看、粒度比核心指标细、覆盖维度多、业务线共性指标等)。如图5所示，ADS层中20％的运营决策信息和DWD层中满足10％的临时需求的数据可以提供决策指标(如临时、个性化、活动监测和计算复杂等指标)。核心指标、决策指标、基础指标等具体可以来自用户增长、内容生态、用户、广告投放、直播、电商等方面的内容数据，同时核心指标、决策指标、基础指标反过来也可以对用户增长、内容生态、用户、广告投放、直播、电商等方面的运营决策提供帮助。

应该理解，基于Spark计算引擎和MapReduce计算引擎的离线数据仓库采用的是维度建模和数据分层方式，可以在数据报表展示和数据源之间进行多层隔离，因而可以保证输出的数据具有指标统一、完整，数据血缘关系清晰的特点。但是，这都是基于独立的Spark计算引擎和MapReduce计算引擎的数据仓库的优点。而OLAP引擎本身是不具备维度建模能力，OLAP引擎本身是为多维分析和数据快速计算服务的。但是，当OLAP引擎和Spark(或MapReduce)计算引擎打通以后，任务/数据快速执行和维度建模也就可行了。

此外，在本公开实施例中，与OLAP引擎关联的数据仓库自下往上依次可以包括：ODS层，DWD层，DWS层，ADS层。ODS层、DWD层、DWS层以及ADS层存储的数据可以参考其他实施例中的描述，在此不再赘述。

通过本公开实施例，在OLAP引擎中引入维度建模后，可以实现对应的仓库分层，使得数据结构更加清晰。

应该理解，在本公开实施例中，可以使OALP引擎具备维度建模能力，对应数据仓库的ODS层数据源可以满足公司级的数据流通。DWD层的多事务事实表可以满足10％的临时需求，大大解放人力资源。ADS层可以负责70％的长期统计监测需求，ADS层同时可以负责20％的运营决策个性化指标需求。且维度建模后的数据，可以保证数据的历史细节不丢失，能反应历史变化，基于维度聚合后数据结构更加清晰。尤其相对于业界的离线任务小时级的执行时间，采用OLAP引擎计算后的维度建模数据，其执行时间通常是秒级。

此外，作为一种可选的实施例，该方法还包括：响应于报表查询请求命中聚合查询预处理任务的列，利用OLAP引擎进行数据报表查询。

和/或，作为一种可选的实施例，该方法还包括：响应于报表查询请求未命中聚合查询预处理任务的列，利用预先设定的离线计算引擎进行数据报表查询。

通过本公开实施例，可以基于OLAP引擎实现维度建模、数仓分层和数据即时查询。进一步，利用OLAP引擎无法实现的场景，还可以退而求其次，即利用外部独立的离线计算引擎(如独立于OLAP引擎之外的Spark计算引擎和MapReduce计算引擎，不同于内嵌的离线计算引擎)实现数据查询，以增强系统的数据查询能力。

根据本公开的实施例，本公开还提供了一种用于联机分析处理引擎的数据处理装置。

图6示例性示出了根据本公开实施例的用于联机分析处理引擎的数据处理装置的框图。

如图6所示，用于联机分析处理引擎的数据处理装置600可以包括：数据建模模块610和报表存储模块620。

数据建模模块610，用于利用联机分析处理引擎对操作数据进行维度建模，得到对应的数据报表。

报表存储模块620，用于将所述数据报表存入与所述联机分析处理引擎关联的数据库，以便通过所述联机分析处理引擎查询所述数据报表。

作为一种可选的实施例，所述数据建模模块包括：引擎处理单元，用于在所述联机分析处理引擎内嵌入离线计算引擎；以及数据建模单元，用于利用所述联机分析处理引擎内嵌入的离线计算引擎，对所述操作数据进行维度建模，得到所述对应的数据报表。

作为一种可选的实施例，所述数据建模单元包括：表生成子单元，用于利用所述联机分析处理引擎内嵌入的离线计算引擎，对所述操作数据进行维度建模，得到对应的事实表和维度表；以及表关联子单元，用于利用所述联机分析处理引擎内嵌入的离线计算引擎，将所述维度表与所述事实表关联，得到所述对应的数据报表。

作为一种可选的实施例，所述引擎处理单元还用于：在所述联机分析处理引擎内嵌入Spark计算引擎或MapReduce计算引擎。

作为一种可选的实施例，所述报表存储模块还用于：将所述数据报表存入与所述联机分析处理引擎关联的数据库的应用数据层。

作为一种可选的实施例，该装置还包括：第一报表查询模块，用于响应于报表查询请求命中聚合查询预处理任务的列，利用所述联机分析处理引擎进行数据报表查询。

作为一种可选的实施例，该装置还包括：第二报表查询模块，用于响应于报表查询请求未命中所述聚合查询预处理任务的列，利用预先设定的离线计算引擎进行数据报表查询。

应该理解，本公开装置部分的实施例与本公开方法部分的实施例对应相同或类似，所解决的技术问题和所达到的技术效果也对应相同或类似，本公开在此不再赘述。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，电子设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储电子设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

电子设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如用于OLAP引擎的数据处理方法。例如，在一些实施例中，用于OLAP引擎的数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的用于OLAP引擎的数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行用于OLAP引擎的数据处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务(″Virtual Private Server″，或简称〞VPS〞)中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

本公开的技术方案中，所涉及的用户数据的记录，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。