一种铝工业数据补充采集方法、装置、介质、电子设备

技术领域

本申请涉及铝工业技术领域，特别地，涉及一种铝工业数据补充采集方法、装置、介质、电子设备。

背景技术

铝工业各生产企业每天会产生海量的生产、经营等数据，而这些数据普遍存储在各分子公司企业内部，形成数据孤岛、业务孤岛。为了满足技术分析和决策需要，需从各分子公司业务系统中采集数据集中存储，进行数据治理，提高数据质量，形成有效数据资产。相比于电商、金融、服务领域，铝工业企业信息化相对落后，许多企业业务系统技术陈旧、数据库结构设计难以对增量采集起到良好的效果。

如一张表存储多个业务数据字段，但仅有数据的业务日期字段，没有数据最后更新时间戳字段。只能基于业务日期做增量数据采集，而业务实际中经常出现不同部门在不同时间更新同一条记录不同字段。如果增量采集后企业又更新了数据，会导致数据漏采。现有的技术中无法针对数据漏采的问题进行有效地解决，进而导致数据混乱、数据缺失等情况发生。

发明内容

本申请提供了一种铝工业数据补充采集方法、装置、介质、电子设备，以解决铝工业生产当中存在的数据漏采的问题。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种铝工业数据补充采集方法，所述方法包括：

每间隔预设时间获取预设的数据库中的数据补采任务列表，所述数据补采任务列表包括至少一个补采任务，所述补采任务用于在所述数据库中采集目标对象在目标时间区间内的第一目标数据；

对所述数据补采任务列表中的补采任务依次进行数据补充采集；

监测所述补采任务的采集状态，所述采集状态用于表征所述补采任务的执行状态；

每个所述补采任务完成后，生成采集记录，所述采集记录包括采集的起始时间；

基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据；

将所述可存储数据保存到hadoop数据平台或基于所述采集记录将所述补采任务对应的第一目标数据保存到关系数据库中。

在本申请的一个实施例中，基于前述方案，所述对所述数据补采任务列表中的补采任务依次进行数据补充采集，包括：

基于所述数据补采任务列表按照时间顺序对每个所述补采任务进行排序，得到排序结果；

根据所述排序结果依次对所述补采任务进行数据补充采集。

在本申请的一个实施例中，基于前述方案，所述对所述补采任务进行数据补充采集，包括：

根据所述目标时间区间在所述数据库中筛选出与所述目标时间区间对应的第二目标数据；

在所述第二目标数据中查询与所述目标对象对应的所述第一目标数据；

对所述第一目标数据进行补充采集。

在本申请的一个实施例中，基于前述方案，所述对所述第一目标数据进行补充采集，包括：

将所述补采任务对应的第一目标数据转换成第一目标数据流；

将所述采集记录对应的采集的起始时间作为属性增加到所述第一目标数据流中，得到第二目标数据流；

对所述第二目标数据流进行补充采集。

在本申请的一个实施例中，基于前述方案，所述将所述补采任务对应的第一目标数据转换成第一目标数据流，包括：

将所述补采任务对应的第一目标数据转换成JSON格式的第三目标数据；

将所述第三目标数据转换成所述第一目标数据流。

在本申请的一个实施例中，基于前述方案，所述基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据，包括：

基于所述采集记录获取与所述第一目标数据对应的第二目标数据流；

将所述第二目标数据流转换成ORC格式的可存储数据。

在本申请的一个实施例中，基于前述方案，所述采集状态包括完成状态、补采中状态以及待补采状态；所述监测所述补采任务的采集状态，包括：

若所述补采任务已完成数据补充采集，将所述采集状态标记为完成状态；

若所述补采任务正在进行数据补充采集，将所述采集状态标记为补采中状态；

若所述补采任务未进行数据补充采集，将所述采集状态标记为待补采状态。

根据本申请实施例的一个方面，提供了一种铝工业数据补充采集装置，其特征在于，所述装置包括：获取单元，被用于每间隔预设时间获取预设的数据库中的数据补采任务列表，所述数据补采任务列表包括至少一个补采任务，所述补采任务用于在所述数据库中采集目标对象在目标时间区间内的第一目标数据；采集单元，被用于对所述数据补采任务列表中的补采任务依次进行数据补充采集；监测单元，被用于监测所述补采任务的采集状态，所述采集状态用于表征所述补采任务的执行状态；记录单元，被用于每个所述补采任务完成后，生成采集记录，所述采集记录包括采集的起始时间；转换单元，被用于基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据；存储单元，被用于将所述可存储数据保存到hadoop数据平台或基于所述采集记录将所述补采任务对应的第一目标数据保存到关系数据库中。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序包括可执行指令，当该可执行指令被处理器执行时，实现如上述实施例中所述的铝工业数据补充采集方法。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储所述处理器的可执行指令，当所述可执行指令被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的铝工业数据补充采集方法。

在本申请实施例的技术方案中，通过每间隔预设时间获取预设的数据库中的数据补采任务列表，数据补采任务列表在有更新的情况下可以及时获取得到。通过所述数据补采任务列表中的补采任务依次进行数据补充采集并监测补采任务的采集状态，有序地进行数据补充采集。在补采任务完成后，通过生成的采集记录以及采集记录中的起始时间来更新记录中的不同字段，以保证每一次数据被采集后都有相应的采集记录，可根据采集记录去按照实际需要对尚未采集的时间段的数据进行补充采集，以达到数据补充采集的目的。通过将补采任务对应的第一目标数据转换成ORC格式的可存储数据保存到hadoop数据平台中，可以通过查询hadoop数据平台快速得到所需的数据，或者，基于采集记录将所述补采任务对应的第一目标数据保存到关系数据库中，此时不需要对第一目标数据进行转换格式，直接保留采集得到的原有格式保存到关系数据库中。增加数据存储方式的多样性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为根据本申请实施例示出的铝工业数据补充采集方法的流程图；

图2为根据本申请实施例示出的数据交互的流程示意图；

图3为根据本申请实施例示出的可视化人机界面的示意图；

图4为根据本申请实施例示出的一个实施例中的补采任务具体执行的流程示意图；

图5为根据本申请实施例示出的另一实施例中的补采任务具体执行的流程示意图；

图6为根据本申请实施例示出的对所述第一目标数据进行补充采集的方法流程图；

图7为根据本申请实施例示出的一种铝工业数据补充采集装置的结构框图；

图8为根据本申请实施例示出的计算机可读存储介质的示意图；

图9为根据本申请实施例示出的电子设备的系统结构的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制节点装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

首先，需要说明的是，本申请中所提出的铝工业数据补充采集方案可以应用于铝工业的相关技术领域，本方案是基于NiFi技术来进行的，通过获取数据补采任务列表中的补采任务依次进行数据补充采集并监测补采任务的采集状态，有序地进行数据补充采集。通过生成的采集记录以及采集记录中的起始时间来更新记录中的不同字段，以保证每一次数据被采集后都有相应的采集记录，可根据采集记录去按照实际需要对尚未采集的时间段的数据进行补充采集，以达到数据补充采集的目的。

根据本申请的一个方面，提供了一种铝工业数据补充采集方法，图1为根据本申请实施例示出的铝工业数据补充采集方法的流程图，该铝工业数据补充采集方法至少包括步骤110至步骤160，详细介绍如下：

在步骤110中，每间隔预设时间获取预设的数据库中的数据补采任务列表，所述数据补采任务列表包括至少一个补采任务，所述补采任务用于在所述数据库中采集目标对象在目标时间区间内的第一目标数据。

在本申请中，预设时间可以根据实际需要去设定，预设的数据库包含了需要查询的各个公司或企业的数据库中的数据。目标对象指的是需要进行数据补充采集的公司或企业；目标时间区间指的是需要进行数据补充采集对应的时间段，如采集2022年10月11日到2022年10月12日之间的数据。

可以通过每间隔预设时间获取预设的数据库中的数据补采任务列表，其中数据补采任务列表可以包含一个或多个补采任务，通过补采任务来对目标对象在目标时间区间内的第一目标数据进行采集。

下面就参照图2来进一步解释说明，图2为可视化人机交互界面。用户可以在该界面中选择企业名称、起始时间、终止时间、源表名等信息写入到数据补采任务列表中，设置每个补采任务初始状态为“待补采”，如果补采任务正在补采中则将状态改成“补采中”的状态，如果补采任务已经完成则将状态改成“完成”的状态。

可在当前界面上查看到所有任务的状态，如果超时未完成，排除故障后可重复下发补采任务。在图3中，包括人机交互组件1、NiFi数据处理组件2、任务列表数据库3。其中，任务列表数据库3对应的是数据补采任务列表，是通过在任务列表数据库3来获取得到数据补采任务列表。

人机交互组件1，如图2所示，包括企业名称选择控件10、时间区间选择控件20、待补采数据源选择控件30，执行按钮控件40，任务状态表控件50五部分。

界面控件初始化，将已接入的企业名称填充到企业名称选择控件,将各企业多个可采数据源表的表名填充到数据源选择控件30，将时间区间默认选择到当前日期前R天，R可以设置为任意大于0的整数值。

选择企业E

NiFi数据处理组件2布置在各分子公司，可访问任务列表数据库3，也可访问企业内部的数据源库；对每个企业E

如图4所示，数据处理流程F

数据处理流程F

如图4所示，数据处理流程Fij的ExccuteSQL组件2，接收上一步的输出，并可从属性P1和P2中动态获得所需补采的时间区间T0和T1，将T0和T1按NiFi的Expression语法拼接到SQL查询语句中，设置到SQL Post-Query属性，就可以查询到该数据表待补采数据记录。增加ConvertAvroToORC和PutHDFS组件将结果存到hadoop大数据平台中，也就是下述所说的将所述第二目标数据流转换成ORC格式的可存储数据。

如图5所示，在本申请的另一实施例中，通过增加一个ExecuteSQLRecord组件接收上一步的输出，并可从属性P1和P2中动态获得所需补采的时间区间T0和T1，将T0和T1按NiFi的Expression语法拼接到SQL查询语句中，设置到SQL Post-Query属性；增加一个PutDatabaseRecord组件将第二目标数据流保存到目标数据库中。其中，目标数据库可以为根据实际需要预设的数据库。

任务列表数据库tasklist表的结构如表1所示：

表1

在本申请的一个实施例中，实施流程如图4所示，在人机交互组件1的时间区间选择起始时间2022-09-10，终止时间2022-09-11，在企业选择控件选择甲公司，源库表控件选择槽控工艺报，点击执行后，程序将甲公司对应的编号1001、2022-09-10、2022-09-11，槽控工艺报对应的表名gongyi_rpt、当前日期2022-10-07，任务状态0保存到任务列表数据库tasklist表的Ent_id，Ddate_b，Ddate_e,Source_Name,Ddate_p，Status字段中。

部署在甲公司的NiFi系统上建立一个槽控工艺报补采流程，从ExecuteSQL组件1开始，调度规则为每6小时执行一次。“Database Connection Pooling Service”属性设置好任务列表数据库访问地址，“SQL select query”属性设置为查询任务表tasklist的过滤条件为Ent_id＝1001and Source_Name＝‘gongyi_rpt’and Status＝0的记录。

如果没有返回记录，则流程结束，找到记录则继续进行。

进一步地，ConvertAvroToJSON按默认属性将上一步的记录转成json对象；

进一步地，EvaluateJsonPath组件增加三个属性mid、rq_b和rq_e,其对应的value分别设置为$.id，$.Ddate_b和$.Ddate_e，下游组件将可通过mid属性获得当前记录用以更新任务状态，通过rq_b与rq_e属性读取到起始时间2022-09-10和终止时间2022-09-11。

进一步地，PutSQL组件1更新当前任务记录设置任务状态Status＝1

进一步地，ExecuteSQL组件2设置“Database Connection Pooling Service”属性为企业槽控工艺报表gongyi_rpt所在的数据库连接信息，“SQL select query”属性的sql语句增加过滤条件为RecordDate>＝'${rq_b}'and RecordDate<＝'${rq_e}'，其中RecordDate为槽控工艺报gongyi_rpt表的业务日期字段。

进一步地，ConvertAvroToORC组件将上游查询到的数据流转换成orc格式。

进一步地，PutHDFS组件将上游orc格式的数据保存到Hadoop ConfigurationResources属性指定的hadoop数据平台中。

进一步地，PutSQL组件2更新当前任务记录设置任务状态Status＝2。

在本申请的另一实施例中，实施流程如图5所示，在人机交互组件1的时间区间选择起始时间2022-09-08，终止时间2022-09-11，在企业选择控件选择乙公司，源库表控件选择电解质化验，点击执行后，程序将乙公司对应的编号1002、2022-09-08、2022-09-11，电解质化验对应的表名Qdata_bath、当前日期2022-10-07，任务状态0保存到任务列表数据库tasklist表的Ent_id，Ddate_b，Ddate_e,Source_Name,Ddate_p，Status字段中。

部署在乙公司的NiFi系统上建立一个电解质化验补采流程，从ExecuteSQLRecord组件1开始，调度规则为每12小时执行一次。“Database Connection Pooling Service”属性设置好任务列表数据库访问地址，“SQL select query”属性设置为查询任务表中过滤条件为Ent_id＝1002and Source_Name＝’Qdata_bath’and Status＝0的记录。

进一步地，设置JsonRecordSetWriter组件，并将ExecuteSQLRecord的RecordWriter属性设置为JsonRecordSetWriter组件，实现数据转成json格式；

进一步地，如果所述ExecuteSQLRecord组件没有返回记录，则流程结束，找到记录则继续进行。

进一步地，EvaluateJsonPath组件增加三个属性mid、rq_b和rq_e,其对应的value分别设置为$.id，$.Ddate_b和$.Ddate_e，下游组件将可通过mid属性获得当前记录用以更新任务状态，通过rq_b与rq_e属性读取到起始时间2022-09-08和终止时间2022-09-11。

进一步地，PutSQL组件1更新当前任务记录设置任务状态Status＝1

进一步地，ExecuteSQLRecord组件2设置“Database Connection PoolingService”属性为企业电解质化验数据库表Qdata_bath所在的数据库连接信息，“SQLselect query”属性的sql语句增加过滤条件为QDate>＝'${rq_b}'and QDate<＝'${rq_e}'，其中QDate为电解质化验数据库表Qdata_bath的业务日期字段。

进一步地，PutDatabaseRecord组件将上一步查询到的数据存储到关系数据库中。

进一步地，PutSQL组件2更新当前任务记录设置任务状态Status＝2。

继续参照图1，在步骤120中，对所述数据补采任务列表中的补采任务依次进行数据补充采集。

在本申请的一个实施例中，所述对所述数据补采任务列表中的补采任务依次进行数据补充采集，可以按照步骤S1至步骤S2进行：

步骤S1：基于所述数据补采任务列表按照时间顺序对每个所述补采任务进行排序，得到排序结果。

步骤S2：根据所述排序结果依次对所述补采任务进行数据补充采集。

在本申请中，通过将补采任务写入到数据补采任务列表的先后顺序，来依次对补采任务进行排序，得到排序结果，再通过排序结果依次对补采任务进行数据补充采集。

在本申请的一个实施例中，如图6所示，所述对所述第一目标数据进行补充采集，包括步骤S21-步骤S23：

步骤S21：将所述补采任务对应的第一目标数据转换成第一目标数据流。

步骤S22：将所述采集记录对应的采集的起始时间作为属性增加到所述第一目标数据流中，得到第二目标数据流。

步骤S23：对所述第二目标数据流进行补充采集。

在本申请中，通过将补采任务对应的第一目标数据转换成第一目标数据流，也就是上述所说的将任务列表数据库中查询得到的任务记录转换成JSON对象，将所述采集记录对应的采集的起始时间作为属性增加到所述第一目标数据流中，得到第二目标数据流，再将第二目标数据流进行补充采集。

在本申请的一个实施例中，上述将所述补采任务对应的第一目标数据转换成第一目标数据流，包括步骤S211-步骤S212。

步骤S211：将所述补采任务对应的第一目标数据转换成JSON格式的第三目标数据。

步骤S212：将所述第三目标数据转换成所述第一目标数据流。

在本申请中，通过将所述补采任务对应的第一目标数据转换成JSON格式的第三目标数据进而转换成第一目标数据流。

继续参照图1，在步骤130中，监测所述补采任务的采集状态，所述采集状态用于表征所述补采任务的执行状态。

在本申请的一个实施例中，所述采集状态包括完成状态、补采中状态以及待补采状态；所述监测所述补采任务的采集状态，包括步骤S31-步骤S33：

步骤S31：若所述补采任务已完成数据补充采集，将所述采集状态标记为完成状态。

步骤S32：若所述补采任务正在进行数据补充采集，将所述采集状态标记为补采中状态。

步骤S33：若所述补采任务未进行数据补充采集，将所述采集状态标记为待补采状态。

在本申请中，如果补采任务未进行补采时将状态设定为“待补采”，如果补采任务正在补采中则将状态改成“补采中”的状态，如果补采任务已经完成则将状态改成“完成”的状态。

继续参照图1，在步骤140中，每个所述补采任务完成后，生成采集记录，所述采集记录包括采集的起始时间。

在本申请中，可以通过生成采集记录来得知对哪个企业的哪个时间段的数据进行了补充采集，这样就可以使得在后续的数据补采时可以通过查看采集记录防止同一时间段的数据的重复采集，进一步提高了数据补采的效率。

继续参照图1，在步骤150中，基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据。

在本申请的一个实施例中，所述基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据，包括：

基于所述采集记录获取与所述第一目标数据对应的第二目标数据流；

将所述第二目标数据流转换成ORC格式的可存储数据。

在本申请中，通过将第二目标数据流转换成ORC格式的可存储数据，进而可以保存在hadoop大数据平台中，方便后续对所需要的数据进行查询。

继续参照图1，在步骤160中，将所述可存储数据保存到hadoop数据平台或基于所述采集记录将所述补采任务对应的第一目标数据保存到关系数据库中。

在本申请中，hadoop数据平台是一个开源的分布式存储和分布式计算平台，通过将可存储数据保存到hadoop数据平台中，可以方便数据的存储与调用，进一步提高读取数据的效率。或者，基于采集记录将所述补采任务对应的第一目标数据保存到关系数据库中，此时不需要对第一目标数据进行转换格式，直接保留采集得到的原有格式保存到关系数据库中。

图7为根据本申请实施例示出的一种铝工业数据补充采集装置的框图。

参照图7所示，根据本申请的一个实施例的铝工业数据补充采集装置700，所述装置700包括：

获取单元701，被用于每间隔预设时间获取预设的数据库中的数据补采任务列表，所述数据补采任务列表包括至少一个补采任务，所述补采任务用于在所述数据库中采集目标对象在目标时间区间内的第一目标数据；

采集单元702，被用于对所述数据补采任务列表中的补采任务依次进行数据补充采集；

监测单元703，被用于监测所述补采任务的采集状态，所述采集状态用于表征所述补采任务的执行状态；

记录单元704，被用于每个所述补采任务完成后，生成采集记录，所述采集记录包括采集的起始时间；

转换单元705，被用于基于所述采集记录将所述补采任务对应的第一目标数据转换成ORC格式的可存储数据；

存储单元706，被用于将所述可存储数据保存到hadoop数据平台或基于所述采集记录将所述补采任务对应的第一目标数据保存到关系数据库中。

参考图8所示，描述了根据本申请的实施方式的用于实现上述方法的程序产品800，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

作为另一方面，本申请还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图9来描述根据本申请的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元910执行，使得所述处理单元910执行本说明书上述“实施例方法”部分中描述的根据本申请各种示例性实施方式的步骤。

存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)921和/或高速缓存存储单元922，还可以进一步包括只读存储单元(ROM)923。

存储单元920还可以包括具有一组(至少一个)程序模块925的程序/实用工具924，这样的程序模块925包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备900也可以与一个或多个外部设备1200(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备900交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口950进行。并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。

此外，上述附图仅是根据本申请示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围执行各种修改和改变。本申请的范围仅由所附的权利要求来限制。