一种处理数据仓库中数据的方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种处理数据仓库中数据的方法及装置。
背景技术
数据仓库(Data Warehouse)是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。数据仓库中的数据,一般具有固定的生命周期,都会经历从热到冷的过程。其中,所谓的“冷”和“热”是根据数据近期(比如最近一周、10天或一个月等)的被访问频率定义的。一般地,可以将近期被用户频繁访问的数据,称为热数据;而将用户近期极少访问的数据称为冷数据。
针对单个数据仓库而言,其保存的数据中一般既有冷数据也有热数据。在大数据环境下,冷数据和热数据的数据量,往往都非常的庞大,甚至达到拍字节(Petabyte,PB)以上,其中1PB=1024TB=1048576GB。
用户对于数据仓库的访问,往往是对热数据的访问,但数据仓库中数量巨大冷数据的存在,势必会占用数据仓库较大的存储空间,从而降低数据仓库的性能,(比如数据库对于数据访问请求的响应速度变慢,等)。
为了解决上述问题,目前有技术提出,将冷数据与热数据分别保存在两个不同的数据仓库中。例如,有技术提出设置历史数据仓库以及当前数据仓库两个数据仓库,其中,历史数据仓库用于存储冷数据,而当前数据仓库用于存储热数据。用户在对数据仓库进行访问时,其访问请求优先被发送至当前数据仓库,若在当前数据仓库中未能查询到期望访问的数据,则该访问请求再被转发给历史数据仓库。
上述现有技术,虽然可以避免冷数据占用当前数据仓库较多的存储空间,进而避免冷数据对于热数据所在的当前数据仓库的性能产生影响。然而,由于数据被分离保存在两个数据仓库中,当用户期望访问的数据分散在这两个数据仓库中时,需要分别向两个数据仓库发送访问请求,从而导致数据访问过程较为繁琐,且会耗费较多的处理资源。
需要说明的是,上述现有技术,也被用在对具备不同属性的数据的存储上。比如,将具备指定属性的数据存储在第一数据仓库,将具备其他属性的数据存储在第二数据仓库。其中,这里所说的指定属性,除了可以是访问频率外,比如还可以是数据格式、数据重要程度或数据等级,等等。
发明内容
本申请实施例提供一种处理数据仓库中数据的方法,用以解决现有技术中为了使得具备指定属性的数据不影响数据仓库性能,会导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
本申请实施例还提供一种处理数据仓库中数据的装置,用以解决现有技术中为了使得具备指定属性的数据不影响数据仓库性能,会导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
本申请实施例采用下述技术方案:
一种处理数据仓库中数据的方法,包括:
获取数据仓库中至少一个表示数据指定属性的元数据;从获取的所述至少一个表示数据指定属性的元数据中,识别出符合数据判定规则的元数据;对识别出的元数据对应的数据进行压缩处理。
一种处理数据仓库中数据的装置,包括:
元数据获取单元,用于获取数据仓库中至少一个表示数据指定属性的元数据;元数据识别单元,用于从获取的所述至少一个表示数据指定属性的元数据中,识别出符合数据判定规则的元数据;压缩单元,用于对识别出的元数据对应的数据进行压缩处理。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
由于可以通过对符合数据判定规则的元数据所对应的数据进行压缩,达到减少所述对应的数据所占用的存储空间的目的,因此,所述对应的数据无需保存到其他数据仓库中,避免了现有技术中为了使得具备指定属性的数据不影响数据仓库性能,会导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的一种处理数据仓库中数据的方法的具体实现流程示意图;
图2为本申请实施例提供的一种数据分区表的示意图;
图3为本申请实施例提供的一种处理数据仓库中冷数据系统的具体结构示意图;
图4为本申请实施例提供的一种处理数据仓库中冷数据的方法的具体实现流程示意图;
图5为本申请实施例提供的一种处理数据仓库中数据的装置的具体结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地表示。显然,所表示的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
实施例1
本实施例提供一种处理数据仓库中数据的方法,用以解决通过现有方法导致数据访问过程较为繁琐,且会耗费较多的处理资源的问题。该方法的具体实现流程示意图如图1所示,主要包括下述步骤:
步骤11,获取数据仓库中至少一个表示数据指定属性的元数据;
需要说明的是,元数据,是用于表示数据属性的数据。针对数据仓库中的元数据而言,其按照用途可以分为:技术元数据和业务元数据。
其中,所述的业务元数据是用来表示数据所对应的业务的元数据。例如,支付宝服务器上的一组用于记录用户支出项目的数据,则该组数据的业务元数据可以用来表示该组数据的具体支出项目类别(如,生活用品类支出、娱乐类支出、电子用品类支出、食品类支出以及服装类支出,等等)。
所述技术元数据是用来表示与开发和管理数据仓库相关的数据的元数据。具体地,技术元数据可以是用于表示数据所在数据分区表属性的元数据,比如,可以是用于表示数据所在数据分区表的名称、数据所在数据分区表的创建时间、数据所在数据分区表的访问时间以及数据所在数据分区表的访问量等数据分区表属性中的至少一个属性的元数据。
需要说明的是,在一种实施方式中,本申请实施例所述的表示数据指定属性的元数据,可以为业务元数据,也可以为技术元数据,还可以是其他元数据。其中,数据的指定属性,比如可以是技术元数据所表示的属性,例如,可以是技术元数据所表示的数据所在数据分区表的名称、数据所在数据分区表的创建时间、数据所在数据分区表的访问时间以及数据所在数据分区表的访问量等属性中的至少一个属性;比如还可以是业务元数据所表示的属性,例如,可以是业务元数据所表示的业务的名称以及业务的类型等属性中的至少一个属性;此外,还可以是用于表示数据的名称、数据的重要等级、数据的类型、数据的创建时间、数据的访问时间、数据的访问量等属性中的至少一个属性的元数据。
本申请实施例中,数据仓库中保存的元数据,可以是从数据存储请求中获取到的,也可以是通过对数据仓库日志中的相关记录进行分析得到的,等等。例如,通过对数据仓库日志中的创建记录的分析,可以生成表示数据分区表的创建时间的元数据;通过对日志中的访问记录的分析,可以生成表示数据分区表的访问时间的元数据;通过对日志中的访问量的分析,可以生成表示数据分区表的访问量的元数据;等。
本申请实施例中,可以将通过上述途径获得的元数据保存在数据仓库的指定存储空间(比如数据分区表的分区名称栏等)中,以便于后续从该指定存储空间中获取元数据。
此外需要说明的是,上述数据分区表,是指数据仓库中的存储子空间。本申请实施例中,可以按照数据的至少一个属性,建立不同的数据分区表。比如,按照数据的“保存时刻”这一属性,可以建立不同的数据分区表,其中,建立的单个数据分区表中存储的数据的保存时刻满足:处于同一时间段。该时间段比如可以是某年某月某日的00:00~01:00、某年某月某日或某年的某一周,等等。类似地,也可以按照其他属性建立不同的数据分区表。
在建立了数据分区表的情况下,数据的属性,可以是数据所在的数据分区表的属性。这里所说的数据分区表的属性,比如可以是数据分区表的名称或者是数据分区表的访问时间,等。
本申请实施例中,可以按照数据的“保存时刻”这一属性,建立不同的数据分区表,并将数据的保存时刻所属时间段作为单个数据分区表的名称,该名称可以作为表中数据的属性之一。
例如,假设该时间段是2015年1月1日,则可以建立一个以该时间段作为名称的数据分区表,该数据分区表的名称具体可以为dt=20150101,如图2所示。图2中各数据分区表的命名方式依此类推,不再赘述。
需要说明的是,数据分区表的访问时间为用户最近一次对数据分区表进行访问的时间。例如,假设用户分别在2015年1月3日以及2015年5月3号对数据分区表A进行了访问,则数据仓库服务器可以将数据分区表的访问时间由“2015年1月3日”更新为“2015年5月3号”,并以“2015年5月3号”作为数据分区表的访问时间。
步骤12,从获取的所述至少一个表示数据指定属性的元数据中,识别出符合数据判定规则的元数据;
其中,所述的数据判定规则,是用于判断获取到的元数据所表示的数据指定属性是否满足判定条件的规则。
举例而言,所述的数据判定规则包括但不仅限于有以下几种:
规则一,与“数据分区表的创建时间”这一数据属性相关的规则。
比如,该规则一可以设置为“数据所在的数据分区表的创建时间早于设定时刻S”。那么,假设S为2014年1月1日00:00,则用于表示“早于2014年1月1日00:00创建的数据分区表的创建时间”的元数据符合该规则。
当所述的数据判定规则为规则一时,获取的所述至少一个表示数据指定属性的元数据所表示的数据指定属性为“数据分区表的创建时间”。
规则二,与“数据分区表的修改时间”这一数据属性相关的规则。
比如,该规则二可以设置为“数据所在的数据分区表的修改时间早于设定时长T”。那么,假设T为3个月,则用于表示“最后的修改时间距当前时间在3个月以上”的元数据符合数据判定规则。
当所述的数据判定规则为规则二时,获取的、所述至少一个表示数据指定属性的元数据所表示的数据指定属性为“数据分区表的修改时间”。
规则三,与“数据分区表的访问频率”这一数据属性相关的规则。
比如,该规则三可以设置为“在设定时长M内,对数据所在的数据分区表的访问次数低于N次”。那么,假设M为6个月,N为5次,则用于表示“在6个月内访问次数小于5次”的元数据符合数据判定规则。
当所述的数据判定规则为规则三时,获取的、所述至少一个表示数据指定属性的元数据所表示的数据指定属性为“数据分区表的访问频率”。
本申请实施例中,可以根据期望对作为处理对象的数据属性,灵活设置数据判定规则。此处不再对各种可能出现的数据判定规则进行一一例举。
需要说明的是,数据仓库中存储的数据往往具有不同的数据类型,而对不同数据类型的数据使用相同的数据判定规则时,可能会存在一些问题。例如,若针对具备数据类型x的数据a而言,当a满足在最近6个月的访问频率小于4次/月时,a被认为是冷数据;针对具备数据类型y的数据b而言,当b满足在最近6个月的访问频率小于2次/月时,b被认为是冷数据。那么,若对于数据a与数据b采用相同的冷数据判定规则“访问频率小于2次/月”,则在a在最近6个月的访问频率为3次/月的情况下,就会出现将a错误地判定为热数据的情况。
为避免出现上述问题,在一种实施方式中,从获取的所述至少一个表示数据指定属性的元数据中,识别出符合数据判定规则的表示数据指定属性的元数据之前,本申请实施例提供的方法还包括:根据所述至少一个表示数据指定属性的元数据分别表示的数据类型,确定与所述分别表示的数据类型匹配的数据判定规则。
其中,所述的数据类型可以是获取的表示数据指定属性的元数据表示的数据的指定属性之一。
例如,若按照数据在数据仓库所处的层级对数据进行划分,可以得到三种具备不同数据类型的数据:原始层数据、基础层数据以及应用层数据。其中不同类型的数据与不同的数据判定规则相匹配。
假设原始层数据与上述判定规则二相匹配,则由判定规则二的具体内容可知,数据类型为原始层数据的数据判定规则为:按照数据分区表的修改时间设置的规则。
假设基础层数据与上述判定规则一相互匹配,则由判定规则一的具体内容可知,数据类型为基础层数据的数据判定规则为:按照数据分区表的创建时间设置的规则。
假设应用层数据与上述判定规则三相匹配,则由判定规则三的具体内容可知,数据类型为应用层数据的数据判定规则为:按照数据分区表的访问频率设置的规则。
在一种实施方式中,数据判定规则中,可以包含针对至少两个数据指定属性分别设置的判定条件。例如,可以包括按照数据分区表的创建时间设置的第一条件,以及按照数据分区表的访问频率设置的第二条件。那么,在执行步骤12时的识别出对象为:同时符合第一条件和第二条件的、表示数据指定属性的元数据。
举例而言,上述第一条件比如可以为创建时间在2014年5月1日之前;第二条件比如可以为最近6个月的访问频率低于2次/月。等等。
步骤13,对识别出的元数据对应的数据进行压缩处理。
其中,所述的元数据对应的数据为:元数据表示的数据属性所属的数据。比如,某元数据表示的属性为“创建时间为2014年5月1日”,且该属性属于某数据S,则该数据S为该元数据所对应的数据。
需要说明的是,若所述元数据为处于同一数据分区表中的数据所共享的元数据,则对识别出的元数据对应的数据进行压缩时,将对该数据所在的数据分区表中的所有数据均进行压缩。
在一种实施方式中,为了减少数据仓库的存储空间的占用率,可以对数据仓库中存储的所有数据均进行压缩。然而,考虑到在对压缩率较高的数据进行读取时,将耗费大量的处理资源,因此,本申请实施例中,为了在节省存储空间和节省处理资源之间达到一个平衡,在对数据仓库中存储的所有数据进行压缩时,采用的压缩方案可以包括:对识别出的元数据对应的数据进行第一压缩率的压缩,而对数据仓库中的其他数据进行第二压缩率的压缩,其中第一压缩率高于第二压缩率。
本申请实施例中,也可以不对数据仓库中存储的所有数据均进行压缩。比如,假设数据判定规则用于判定数据是否为冷数据,则其中符合数据判定规则的元数据对应的数据为冷数据,而数据仓库中的不符合数据判定规则的元数据对应数据为热数据。那么,本申请实施例中,可以仅对冷数据进行高压缩率的压缩,而对热数据保持原样不做特殊处理。
本申请实施例1提供的上述方法,通过对符合数据判定规则的表示数据指定属性的元数据所对应的数据进行压缩,达到减少所述对应的数据所占用的存储空间的目的,因此,所述对应的数据无需保存到其他数据仓库中,避免了现有技术中为了使得具备指定属性的数据不影响数据仓库性能,从而导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设备(比如同一数据仓库服务器),或者,该方法也由不同设备作为执行主体。比如,步骤11和步骤12的执行主体可以为设备1,步骤13的执行主体可以为设备2;又比如,步骤11的执行主体可以为设备1,步骤12和步骤13的执行主体可以为设备2;等等。
实施例2
本申请实施例提供一种处理数据仓库中冷数据的方法,解决通过现有方法将冷数据与热数据分别存储在不同的存储设备中,导致数据访问过程较为繁琐,且会耗费较多的处理资源的问题。该方法可以通过如图3所示的系统实现,该系统主要包括以下五部分:
数据仓库存储平台:包括多个数据仓库仓储设备,负责数据仓库存储数据的集群。
数据仓库计算平台:包括多个数据计算设备,负责运行数据仓库查询任务并负责对数据仓库存储平台中存储数据的计算工作。
技术元数据采集模块:负责分析“数据仓库计算平台”中运行的任务,采集“数据仓库存储平台”中存储的数据表的技术元数据。
冷数据定义模块:负责对“技术元数据采集模块”采集到的技术元数据进行分析,从而确定“数据仓库存储平台”储存的数据表中的冷数据,并生成需要“冷数据压缩模块”进行处理的任务列表。其中该任务列表用于指示作为压缩对象的冷数据。
冷数据压缩模块:按照“冷数据定义模块”生成的任务列表,对该任务列表中指示的、作为压缩对象的冷数据进行数据压缩。
其中,数据压缩是指:在不丢失有用信息的前提下,缩减数据量以减少存储空间,提高其传输、存储和处理效率,或按照一定的算法对数据进行重新组织,减少数据的冗余和存储的空间的一种技术方法。不同的算法压缩率不同,压缩和解压缩的消耗时间不同,一般来说压缩率的高的压缩算法,需要消耗较多的计算资源。保存冷数据的压缩算法需要选择压缩率较高的。相对来说,高压缩率的编码方式可以把原始数据文件压缩到十分之一以下,但是读取高压缩率的数据需要消耗更多的计算资源,适合存储很少访问的冷数据。低压缩率的编码方式,可以把原始数据文件压缩到二分之一到三分之一,同时读取低压缩率的数据消耗的计算资源较少,适合存储经常访问的热数据。
需要说明的是,上述数据仓库存储平台为:一种底层文件系统采用分布式文件系统(Distributed File System)的数据仓库计算平台。其中的数据是以文件方式保存在分布式文件系统上。
该方法的具体实现流程示意图如图4所示,主要包括下述步骤:
步骤21,技术元数据采集模块获取数据仓库存储平台中的表示数据指定属性的元数据;
若假设冷数据判定规则为:创建时间在2014年5月1日之前,且最近6个月被用户访问的次数小于3次,则步骤21中获取的表示数据指定属性的元数据所表示的数据属性,一般是指数据所属数据分区表的创建时间、数据分区表最近6个月被用户访问的总次数。
步骤22,冷数据定义模块判读获取到的表示数据指定属性的元数据是否符合冷数据判定规则,当符合时,执行步骤23,当不符合时,执行步骤24;
例如,假设冷数据判定规则为上述的“创建时间在2014年5月1日之前,且最近6个月被用户访问的总次数小于3次”,则将符合此规则的元数据对应的数据判定为冷数据。
步骤23,冷数据压缩模块对符合所述规则的元数据对应的数据(后文称冷数据),按照第一压缩率进行压缩处理;
还需要说明的是,若符合所述规则的元数据为处于同一数据分区表中的数据所共享的元数据,则对冷数据进行压缩时,可以对符合所述规则的元数据对应的冷数据所在的数据表分区中的所有数据均进行压缩。
步骤24,冷数据压缩模块对不符合所述规则的元数据表示的数据(热数据),按照第二压缩率进行压缩处理。
需要说明的是,因为在对压缩率较高的数据进行读取时,将耗费大量的处理资源,为了在节省存储空间的同时,减少对热数据进行读取时耗费的处理资源,本申请实施例提供的方法包括:对冷数据进行压缩率较高的压缩,对热数据进行压缩率较低的压缩。
或者,也可以对冷数据所在的数据表分区中的所有数据均进行高压缩率的压缩,而对热数据所在的数据表分区则进行低压缩率的压缩或者保持原样不做特殊处理。
本申请实施例2提供的方法,通过对冷数据进行压缩,达到减少所述冷数据所占用的存储空间的目的,因此,所述的冷数据无需保存到其他数据仓库中,避免了现有技术中为了使得冷的数据不影响数据仓库性能,从而导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
实施例3
本实施例提供一种处理数据仓库中数据的装置,用以解决通过现有方法导致数据访问过程较为繁琐,且会耗费较多的处理资源的问题。该装置的具体结构示意图如图5所示,包括元数据获取单元31、元数据识别单元32以及压缩单元33。
其中,元数据获取单元31,具体用于获取数据仓库中的至少一个表示数据指定属性的元数据。
元数据识别单元32,具体用于从获取的所述至少一个表示数据指定属性的元数据中,识别出符合数据判定规则的元数据。
压缩单元33,具体用于对识别出的元数据对应的数据进行压缩处理。
在一种实施方式中,元数据识别单元32,用于:当元数据获取单元获取元数据表示的数据指定属性包括数据类型,所述数据判定规则为与数据类型匹配的数据判定规则时;根据所述至少一个表示数据指定属性的元数据分别表示的数据类型,确定与所述分别表示的数据类型分别匹配的各数据判定规则;从获取的所述至少一个表示数据指定属性的元数据中,识别出符合相应的数据判定规则的元数据。
在一种实施方式中,元数据识别单元32,用于:当元数据获取单元获取的元数据表示的数据指定属性包括数据被访问时刻时;根据所述至少一个表示数据指定属性的元数据分别表示的数据被访问时刻,确定所述至少一个表示数据指定属性的元数据对应的数据在指定时间段内的被访问频率;根据所述被访问频率,从所述至少一个表示数据指定属性的元数据中,识别出对应的数据的所述被访问频率低于设定频率阈值的数据对应的元数据。
在一种实施方式中,元数据识别单元,用于针对至少两个数据指定属性分别设置的判定条件。
在一种实施方式中,压缩单元33,用于:对识别出的元数据对应的数据进行压缩处理,使得压缩后的所述对应的数据具备第一压缩率;其中,所述第一压缩率高于所述数据仓库中其他数据具备的第二压缩率。
在一种实施方式中,元数据获取单元,用于获取数据仓库中处于同一数据分区表中的数据所共享的元数据。
采用本申请实施例3提供的上述装置,通过元数据获取单元31获取表示数据指定属性的元数据,并通过元数据识别单元对所述获取到的表示数据指定属性的元数据进行判定,并且通过压缩单元对元数据识别单元识别出的符合数据判定规则的元数据对应的数据进行压缩。减少了符合数据判定规则的元数据所对应的数据所占用的存储空间,所述对应的数据无需保存到其他数据仓库中,避免了现有技术中为了使得具备指定属性的数据不影响数据仓库性能,从而导致数据访问过程较为繁琐,且数据访问过程会耗费较多的处理资源的问题。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来表示的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。