处理信息的方法及系统与流程

本公开总体涉及数据处理技术领域，具体而言，涉及一种处理信息的方法及系统。

背景技术：

随着互联网金融的不断发展，人们的收入水平不断提高，投资理财也逐渐成为人们新的生活习惯。为了满足市场需求，不同种类的理财产品也应运而生。面对品类众多的理财产品，单一的理财方式已经不能满足大众的多元化需求。如何将理财与更多的消费模式连接起来，从而实现促进消费、推动生产的目的，已经成为当前市场的迫切需求。

通过将理财收益合理化前置的模式，从而使用户可以进行更多种方式的消费，可以有效的解决这一问题。但是，由于这种模式目前并不适合于所有的理财产品，并且收益与消费金额也不能完美的匹配，所以若想满足这一需求，可以通过消费金额反推适合的理财产品和投资金额。这样用户在选择不同方式消费的时候，可以通过购买理财，来实现提前消费的目的。

目前，由于消费场景比较固定，与上层应用的交互正在发展阶段，所以对于理财产品的装配主要还是采用传统的接口实时调用的模式。不同理财产品数据格式不同，并且存放在不同的内存模块中，不方便统一进行管理。针对不同场景，只能实时的对各个理财产品系统做差异化服务调用，不利于抽象和扩展。当用户进入消费页面的时候，才发起接口调用的流程：首先，根据不同的消费场景，对不同理财产品进行实时抓取；然后，根据不同理财产品自身的属性特点，调用各自的业务系统进行计算和过滤；最后，把过滤的产品展示给用户，如图1所示。由于不能预先加载理财产品，无法适应未来接入商城、金融或其他高并发消费系统的性能要求。针对不同理财产品，不能做统一的监控和预警服务。由于不同业务系统的限制，对于不同理财产品采用不同的监控策略，采用这种模式，效率非常低，并且不利于后续多消费场景的接入和扩展。

基于上述，如何在用户选择消费的时候，系统可以及时准确地将符合条件的理财产品和投资金额计算出来，并呈现给用户。因此，需要一种新的处理信息的方法及系统。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开提供一种处理信息的方法及系统，以解决现有技术中对于不同种类的产品实时调用各业务系统并且没有及时预警导致处理效率低的技术问题。

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

根据本公开的一方面，提供一种处理信息的方法，包括：

获取多个产品的数据；

对所述多个产品的数据做标准化处理，将得到的所述多个产品的标准化数据存储到通用产品池中；

对所述多个产品的标准化数据采用通用过滤策略进行过滤，得到多个第一过滤产品；

对所述多个第一过滤产品的标准化数据采用差异化过滤策略进行过滤，得到多个第二过滤产品；

根据需要提供组装产品，所述组装产品包括所述多个第二过滤产品中的至少一个第二过滤产品。

在本公开的一种示例性实施例中，所述多个产品的标准化数据包括通用信息和差异化信息。

在本公开的一种示例性实施例中，所述对所述多个产品的数据做标准化处理包括：

对所述多个产品的数据中无用的信息直接进行排除；

对所述多个产品的数据中有用的属性进行统一标准化处理，得到所述通用信息；

对所述多个产品的数据中特有的属性进行统一扩展处理，得到所述差异化信息。

在本公开的一种示例性实施例中，所述多个产品为不同的理财产品，至少包括以下一种：保险理财产品、基金理财产品、信保理财产品。

在本公开的一种示例性实施例中，对所述多个产品的数据做标准化处理之前还包括：

按照预设时间间隔定期地向所述多个产品的数据对应的内存中进行抓取得到所述多个产品的数据，如果抓取失败则隔预设间歇时间后重新开始抓取。

在本公开的一种示例性实施例中，所述对所述多个产品的标准化数据采用通用过滤策略进行过滤包括：

根据所述产品的状态进行过滤，留下有效的产品；

对所述有效的产品按照时限进行过滤，留下符合期限的产品。

在本公开的一种示例性实施例中，当所述产品为保险理财产品时，所述采用差异化过滤策略进行过滤包括：

按照理财期限进行分类，并对理财期限相同的多个理财产品进行过滤，留下收益率高的理财产品，得到的所述第二过滤产品为保险高收益策略包。

在本公开的一种示例性实施例中，当所述产品为信保理财产品时，所述采用差异化过滤策略进行过滤包括：

按照理财期限+收益率进行分类，并针对同一理财期限的理财产品扩展出虚拟产品，得到的所述第二过滤产品为信保全品类+额外收益策略包。

在本公开的一种示例性实施例中，还包括：

实时监测所述通用产品池中产品的库存，如果发生库存不足的情况，则进行库存预警；

采用所述通用过滤策略以及所述差异化过滤策略进行过滤时，如果任一种策略导致产品的库存为空，则进行策略预警；

根据需要的上层应用的场景采用选择相应的第二过滤产品进行装配时，如果某一场景下装配出现异常，则进行场景预警；

根据需要的上层应用的场景采用选择相应的第二过滤产品进行装配之后，所述上层应用调用所述理财产品时，同时监测产品的服务和/或性能，如果服务或性能出现异常，则进行服务性能预警。

根据本公开的一个方面，提供一种处理信息的系统，包括：

数据获取模块，用于获取多个产品的数据；

标准化处理模块，用于对所述多个产品的数据做标准化处理，将得到的所述多个产品的标准化数据存储到通用产品池中；

通用过滤模块，用于对所述多个产品的标准化数据采用通用过滤策略进行过滤，得到多个第一过滤产品；

差异化过滤模块，用于对所述多个第一过滤产品的标准化数据采用差异化过滤策略进行过滤，得到多个第二过滤产品；

组装模块，用于根据需要提供组装产品，所述组装产品包括所述多个第二过滤产品中的至少一个第二过滤产品。

在本公开的一种示例性实施例中，所述多个产品的标准化数据包括通用信息和差异化信息。

在本公开的一种示例性实施例中，所述标准化处理模块包括：

排除子模块，用于对所述多个产品的数据中无用的信息直接进行排除；

标准化子模块，用于对所述多个产品的数据中有用的属性进行统一标准化处理，得到所述通用信息；

扩展子模块，用于对所述多个产品的数据中特有的属性进行统一扩展处理，得到所述差异化信息。

在本公开的一种示例性实施例中，所述多个产品为不同的理财产品，至少包括以下一种：保险理财产品、基金理财产品、信保理财产品。

在本公开的一种示例性实施例中，还包括：

抓取模块，用于按照预设时间间隔定期地向所述多个产品的数据对应的内存中进行抓取得到所述多个产品的数据，如果抓取失败则隔预设间歇时间后重新开始抓取。

在本公开的一种示例性实施例中，所述通用过滤模块包括：

第一过滤子模块，用于根据所述产品的状态进行过滤，留下有效的产品；

第二过滤子模块，用于对所述有效的产品按照时限进行过滤，留下符合期限的产品。

在本公开的一种示例性实施例中，所述差异化过滤模块包括：

至少一个第三过滤子模块，用于对保险理财产品进行过滤；以及

至少一个第四过滤子模块，用于对信保理财产品进行过滤。

在本公开的一种示例性实施例中，所述系统还包括预警模块，所述预警模块包括：

库存预警子模块，用于实时监测所述通用产品池中产品的库存，如果发生产品的库存不足的情况，则进行库存预警；

策略预警子模块，用于采用所述通用过滤策略以及所述差异化过滤策略进行过滤时，如果任一种策略导致产品的库存为空，则进行策略预警；

场景预警子模块，用于根据需要的上层应用的场景采用选择相应的进行装配时，如果某一场景下装配出现异常，则进行场景预警；

服务性能预警子模块，用于根据需要的上层应用的场景采用选择相应的第二过滤产品进行装配之后，所述上层应用调用所述理财产品时，同时监测产品的服务和/或性能，如果服务或性能出现异常，则进行服务性能预警。

根据本公开的技术方案，能够得到以下技术效果：

针对不同种类的多个产品数据进行标准化处理，以使数据格式得到统一，从而可以将不同种类的产品存入到通用产品池中，便于进行统一管理，并将经过通用过滤策略和差异化过滤策略进行过滤抽象成一个接口提供给上层应用，可以进行统一调用，方便管理，提高处理效率。

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

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1示意性示出现有技术中对理财产品进行管理的示意图。

图2示意性示出本公开一实施例中提供的一种处理信息的方法的步骤流程图。

图3示意性示出本公开另一实施例中提供的一种处理信息的方法的步骤流程图。

图4示意性示出第一阶段得到通用产品池的流程。

图5示意性示出对数据进行标准化处理的原理性示意图。

图6示意性示出第二阶段基于过滤策略进行过滤的流程。

图7示意性示出保险高收益策略的基本流程示意图。

图8示意性示出信保全品类+额外收益策略的基本流程示意图。

图9示意性示出第三阶段进行智能装配的流程。

图10示意性示出系统架构示意图。

图11示意性示出本公开再一实施例中提供的一种处理信息的系统的示意图。

图12示意性示出本公开再一实施例中标准化处理模块的示意图。

图13示意性示出本公开再一实施例中预警模块的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

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

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

图2示出本公开一实施例中提供的一种处理信息的方法的步骤流程图。

如图2所示，在步骤S10中，获取多个产品的数据。

如图2所示，在步骤S20中，对多个产品的数据做标准化处理，将得到的多个产品的标准化数据存储到通用产品池中。

如图2所示，在步骤S30中，对多个产品的标准化数据采用通用过滤策略进行过滤，得到多个第一过滤产品。

如图2所示，在步骤S40中，对多个第一过滤产品的标准化数据采用差异化过滤策略进行过滤，得到多个第二过滤产品。

如图2所示，在步骤S50中，根据需要提供组装产品，组装产品包括多个第二过滤产品中的至少一个第二过滤产品。

基于上述方法，可以对不同种类的产品做标准化处理，使所有产品数据格式得到统一，这样可以由通用产品池进行统一管理，再经过通用过滤和差异化过滤两级过滤，针对不同的需要采用策略进行智能地调用和处理，更加灵活高效。

其中的产品可以为实体产品(如有实际形态的手机、电脑等)或者虚拟的服务产品(如旅游、保险等)。

图3还示出本公开另一实施例中提供的一种处理信息的方法的步骤流程图。除了图2所示的步骤S10～步骤S50，在步骤S10对多个产品的数据做标准化处理之前还包括：

如图3所示，在步骤S00中，按照预设时间间隔定期地向多个产品的数据对应的内存中进行抓取得到多个产品的数据，如果抓取失败则隔预设间歇时间后重新开始抓取。

基于上述，在服务器启动时，首先开启一个线程定期地向不同理财产品的内存中抓取产品数据，其中预设时间周期可以是每隔20秒、30秒、40秒……，预设时间间隔可以根据应用场景或者系统设定时间段来决定具体选择间隔的长短。但是如果抓取失败的话，则需要隔预设间歇时间(如60秒)后重新开始抓取。

以下主要是以保险这种虚拟的服务产品为例进行说明，从抓取理财产品数据开始直到最终实现智能装配大致需要以下三个阶段：第一阶段，得到通用产品池；第二阶段，基于过滤策略进行过滤；第三阶段，智能装配。

图4示出第一阶段得到通用产品池的流程，如图4所示，包括：首先，定时抓取不同的理财产品，本实施例中理财产品至少包括以下一种：保险理财产品、基金理财产品、信保理财产品以及其他理财产品。之后，对抓取的理财产品进行标准化处理，使得所有的理财产品的数据格式得到统一。然后，向通用产品池输出数据格式标准的理财产品。

由于不同的理财产品有不同的理财属性，但是对于后期理财产品的过滤、组装以及到最后呈现给用户，在标准化处理过程中，需要将一些无用的信息排除掉，并对一些有用的属性进行统一标准化处理，得到通用信息，同时还对一些特有的属性进行统一扩展处理，得到差异化信息。需要从中提取对于过滤装配策略有用的信息，同时排除剩下的无用信息。

图5示出的对数据进行标准化处理的原理性示意图，接下来以图5示出的标准化处理过程为例进行说明：

首先，获取不同理财产品的产品ID、产品名称、收益率等基本信息，并进行统一的命名处理，映射到通用的理财产品对象中，其中公共的属性信息需要在通用实体中体现出来。然后，对于不同理财产品中的无用字段进行忽略，也就是不会映射到通用的理财产品对象中。最后，对于某些理财产品的特殊属性，例如信保产品的募集期属性等，在通用的理财产品对象中采用了一个Map进行存储，特殊属性的名称用key值来存储，特殊属性的内容用value来存储。如通用的理财产品公用的属性信息包括：理财产品商务号、理财产品名称、理财产品类型、理财期限、购买说明、年化收益、理财商品详情、理财注意事项、可购买金额、起购金额以及限购金额等。而在标准化过程中，针对保险理财产品、信保理财产品、基金理财产品、票据理财产品等差异化的信息而言，对于差异化的命名都要进行统一命名处理，差异化的格式也根据特征由String、Bigdecimal等类型统一处理。这样标准化处理的灵活性比较强，容易扩展。

通用产品池可以用来存放标准化处理之后的理财产品，采用Map的存储结构可以通过理财产品类型将通用产品池分类，通过对比多种Map型存储结构，最后选择Google Guava中提供的Multimap来进行存储，能够快速的定位和分类。google guava库的Multimap数据结构，主要是对Map结构的一种衍生，主要是为了解决Map<Object,Collection>这种类型的数据结构。因为Multimap可以很方便的实现Map<Object,Collection>这样的存储结构，符合设计需求。当然这里也可以使用HashMap、Set或者List等存储结构进行手动处理。

图6示出第二阶段基于过滤策略进行过滤的流程，如图6所示，包括：首先，启用一个新的线程，定期(例如每隔30秒)抓取通用产品池中的理财产品数据。同样，如果抓取失败，也需要间隔预设间歇时间(例如30秒)后再重试。之后，采用通用过滤策略进行一级过滤，采用差异化过滤策略进行二级过滤，至此得到保险全品类策略包、信保全品类策略包、信保额外收益策略包以及其他策略包。

第二阶段主要是在策略中心完成，策略中心根据上层应用的不同场景，采用策略模式提供不同的理财产品。策略中心主要由三个部分组成：通用过滤模块、差异化过滤模块和场景装配模块。其中通用过滤模块主要针对不同理财产品的通用属性做计算和过滤，达到最基本展示条件。差异化过滤策块可以从理财产品的理财期限、收益率大小、是否具有额外收益、购买条件限制等维度来设计不同的理财策略，例如保险高收益策略、信保全品类+额外收益策略等。不同理财产品由于属性不同理财策略也会不同。同一种理财产品也会根据不同场景扩展出不同的理财策略，为后续的场景装配提供产品资源。场景装配模块可以根据不同的消费场景，从差异化过滤模块中选择需要的理财产品进行装配，提供给上层应用。

该第二阶段采用通用过滤策略进行一级过滤，包括：

根据理财产品的状态进行过滤，留下有效的理财产品，对有效的理财产品按照时限进行过滤，留下符合期限的理财产品。

针对不同的理财产品也有一些通用的过滤条件，采用通用过滤策略来进行第一次过滤，首先判断所有理财产品的状态，将下架的、失效的、有可能发生流标的产品统一过滤出去，即进行第一次减法处理。然后在针对理财产品的时间进行过滤，将所有超过募集期或者售卖期的理财产品过滤出去，即第二次减法处理，最后将留下来的产品(也就是通用过滤策略之后的产品)提供给下一个步骤使用。其中“流标”是针对募集型理财产品，在募集期内未满标的情况，就是投标期限已过，但是理财金额没有足额筹集齐，就会产生流标。流标后用户账户上的冻结金额自动转为用户可用金额，可以再次进行投资。

该第二阶段采用差异化过滤策略进行二级过滤，针对不同类型的理财产品需要采用不同的过滤策略，具体包括：

针对保险理财产品，按照理财期限进行分类，并对理财期限相同的多个理财产品进行过滤，留下收益率高的理财产品，得到的第二过滤产品就是保险高收益策略包；

针对信保理财产品，按照理财期限+收益率进行分类，并针对同一理财期限的理财产品扩展出虚拟产品，得到的第二过滤产品就是信保全品类+额外收益策略包。

二级过滤主要是针对不同理财产品采用不同的策略进行差异化的过滤，将不同的策略抽象成一个接口提供给上层应用，因此即便是不同的理财产品也可以统一进行调用。

以下以差异化过滤策略中保险高收益策略和信保全品类+额外收益策略为例进行说明：

保险高收益策略是指从通用过滤得到的通用产品池中抓取保险类理财产品，然后按照理财期限将产品分类，相同期限的理财产品过滤留下收益率高的理财产品。按照理财期限将产品进行分类，分类的方式可以为：构建一个Map存储结构，基于Map的特性，不允许出现同种key值，如果key值相同，则用最新的value值进行覆盖。所以用期限作为key值，理财产品作为value值。相同期限的理财产品用收益率高的理财产品进行覆盖，这样就可以解决分类的问题，最后将收益率高的不同理财期限的保险产品过滤出来。此时可以暂时不考虑库存的问题，因为通过业务沟通，可以允许存在售卖超出库存的情况，最后将收益率高的不同理财期限的保险产品过滤出来。图7示出保险高收益策略的基本流程示意图。

信保全品类+额外收益策略是指从通用过滤得到的通用产品池中抓取信保类理财产品，然后按照期限+收益率进行分类。此时并不按照收益率高的做过滤，而是把同期限不同收益率的信保资产作为不同的产品来处理，即采用期限+收益率作为key值，因为信保产品不允许卖超的情况发生。然后针对某一个期限内的产品，扩展出一个虚拟产品出来，通过让用户多投资从而得到额外收益的方式来选择理财，最后将不同信保产品过滤出来，为下一个步骤使用。图8示出信保全品类+额外收益策略的基本流程示意图。

因此，经过差异化过滤之后，差异化过滤包至少包括保险高收益策略包和信保全品类+额外收益策略包。当然，还可以包括其他策略包，此处不再一一列举。

图9示出第三阶段进行智能装配的流程，如图9所示，包括：

首先，定期根据场景抓取差异化策略包，具体根据商场消费场景、旅游消费场景、金融消费场景以及其他消费场景选取不同的策略包进行装配，也就是针对商场消费场景装配商场场景理财包、针对旅游消费场景装配旅游场景理财包、针对金融消费场景装配金融场景理财包以及针对其他消费场景装配相应的其他场景理财包。装配过程中进行场景预警，装配后提供给上层应用服务，同时进行服务性能预警。

该过程也就是步骤S50中根据需要提供相应的第二过滤产品，对于保险这种虚拟的服务型产品而言，最终呈现给用户用户的就是装配好的符合应用场景以及用户预期的理财产品，带来良好的用户体验。

另外，在本实施例中实现上述方法的系统架构图如图9所示，其中的理财产品智能装配系统除了通用产品池、策略中心之外，还可以进行预警监控系统，主要负责对策略中心中的各个关键节点做预警和监控，例如可以支持服务性能预警、场景预警、策略预警和库存预警。

其中服务性能预警主要用于监控策略中心向上层应用提供的理财产品服务。场景预警主要用于监控场景装配模块，在装配过程中如果发生异常需要报警。策略预警主要用于监控策略模块，如果某个策略，长时间频繁出现异常情况，需要进行报警提示。库存预警主要用于监控通用产品池的库存，对产品库存不足的情况提供预警。以下对几种预警做详细说明：

(1)实时监测通用产品池中理财产品的库存，如果发生库存不足的情况，则进行库存预警。库存预警可以自由配置多种策略，当所有理财产品库存不足的时候，需要进行产品售罄的预警。而当某些理财产品达到阈值的时候，也会进行库存预警。对于某些募集类的理财产品，在募集期结束之前，如果可能流标，也会进行库存预警。

(2)采用通用过滤策略以及差异化过滤策略进行过滤时，如果任一种策略导致产品的库存为空，则进行策略预警。针对通用过滤策略和差异化过滤策略进行预警，当理财产品按策略进行过滤的时候，如果发现因为某一种策略导致产品的库存为空的情况，则需要对此种策略进行报警，通过分析之后，及时调整策略，以使损失降到最小。

(3)根据上层应用的场景采用选择相应的策略包进行装配时，如果某一场景下装配出现异常，则进行场景预警。在根据不同消费场景进行理财产品装配的过程中，如果发现某一种场景的理财产品包为空的时候，则需要进行场景预警，这种预警的级别较高，因为会直接影响上层应用中理财产品的展示，所以需要立即针对预警进行响应。

(4)根据上层应用的场景采用选择相应的策略包进行装配之后，上层应用调用理财产品时，同时监测服务性能，如果服务性能出现异常，则进行服务性能预警。由于装配系统可以为上层应用提供场景包预加载的服务，需要针对服务的性能进行预警，主要监控响应时间和调用成功率。

如图10所示，系统架构中除了包括理财产品智能装配系统20以外，在底层具有理财业务系统10，包括保险业务系统、信保业务系统、基金业务系统以及其他业务系统。另外还具有上层应用系统30，包括商城系统、金融系统、白条系统以及其他消费系统。

需要说明的是，本实施例中第二阶段和第三阶段可以采用两个不同的线程进行处理，即一个线程负责第二阶段针对不同理财产品按策略进行过滤，另一个线程负责第三阶段针对不同的场景按策略进行装配。而在本公开的其他实施例中，还可以是这两个阶段通过一个线程进行处理，先策略中心过滤出不同策略的产品包，上层服务根据场景再实时调用、处理信息包。

综上所述，该方法对不同理财产品标准化处理，统一管理与控制，针对不同场景、不同的理财产品，采用策略模式定期进行过滤和装配，实现理财产品的预加载，当上级应用调用时，根据场景将已经准备好的理财产品包提供出去，提高服务性能，达到准确、高效的目的。另外，对理财产品智能装配流程中的各个节点进行监控和预警，保证策略合理、产品充足。

图11示出本公开再一实施例中提供的一种处理信息的系统的示意图，该系统1000包括数据获取模块100、标准化处理模块200、通用过滤模块300、差异化过滤模块400和组装模块500。

数据获取模块100用于获取多个产品的数据。标准化处理模块200用于对多个产品的数据做标准化处理，将得到的多个产品的标准化数据存储到通用产品池中。通用过滤模块300用于对多个产品的标准化数据采用通用过滤策略进行过滤，得到多个第一过滤产品。差异化过滤模块400用于对多个第一过滤产品的标准化数据采用差异化过滤策略进行过滤，得到多个第二过滤产品。组装模块500用于根据需要提供组装产品，组装产品包括多个第二过滤产品中的至少一个第二过滤产品。

除了上述模块，如图11所示，该系统还可以包括抓取模块000，用于按按照预设时间间隔定期地向多个产品的数据对应的内存中进行抓取得到多个产品的数据，如果抓取失败则隔预设间歇时间后重新开始抓取。

在服务器启动时，首先开启一个线程定期地向不同理财产品内存中抓取产品数据，其中预设时间周期可以是每隔20秒、30秒、40秒……，预设时间间隔可以根据应用场景或者系统设定时间段来决定具体选择间隔的长短。但是如果抓取失败的话，则需要隔预设间歇时间(如60秒)后重新开始抓取。

之后，启用一个新的线程，定期(例如每隔30秒)抓取通用产品池中的理财产品数据。采用通用过滤策略进行一级过滤，采用差异化过滤策略进行二级过滤，至此得到保险全品类策略包、信保全品类策略包、信保额外收益策略包以及其他策略包。

图12示出本实施例中标准化处理模块的示意图，该标准化模块200包括排除子模块210、标准化子模块220和扩展子模块230，其中排除子模块210用于对多个产品的数据中无用的信息直接进行排除；标准化子模块220用于对多个产品的数据中有用的属性进行统一标准化处理，得到通用信息；扩展子模块230用于对多个产品的数据中特有的属性进行统一扩展处理，得到差异化信息。

经过标准化处理后，多个产品的标准化数据包括通用信息和差异化信息，需要相应的两级过滤来完成。如图11所示，本实施例中的通用过滤模块300包括：第一过滤子模块310和第二过滤子模块320。第一过滤子模块310用于根据理财产品的状态进行过滤，留下有效的理财产品，第二过滤子模块320用于对有效的理财产品按照时限进行过滤，留下符合期限的理财产品。

针对不同的理财产品也有一些通用的过滤条件，通用过滤模块300采用通用过滤策略来进行第一次过滤，首先判断所有理财产品的状态，将下架的、失效的、有可能发生流标的产品统一过滤出去。然后在针对理财产品的时间进行过滤，将所有超过募集期或者售卖期的理财产品过滤出去，最后将留下来的产品提供给下一个步骤使用。其中“流标”是针对募集型理财产品，在募集期内未满标的情况，就是投标期限已过，但是理财金额没有足额筹集齐，就会产生流标。流标后用户账户上的冻结金额自动转为用户可用金额，可以再次进行投资。

由于理财产品至少包括以下一种：保险理财产品、基金理财产品、信保理财产品，因此经过差异化过滤所得到的差异化过滤包至少包括保险高收益策略包和信保全品类+额外收益策略包。

如图11所示，差异化过滤模块400包括：至少一个第三过滤子模块410和至少一个人第四过滤子模块420。第三过滤子模块410用于针对保险理财产品，按照理财期限进行分类，并对理财期限相同的多个理财产品进行过滤，留下收益率高的理财产品，生成保险高收益策略包。第四过滤子模块420用于针对信保理财产品，按照理财期限+收益率进行分类，并针对同一理财期限的理财产品扩展出虚拟产品，生成信保全品类+额外收益策略包。

除了上述第三过滤子模块和第三过滤子模块之外，还可以包括针对其他理财展品进行差异化过滤的子模块，二级过滤主要是针对不同理财产品采用不同的策略进行差异化的过滤，将不同的策略抽象成一个接口提供给上层应用，因此即便是不同的理财产品也可以统一进行调用。

本实施例中理财产品智能装配系统除了通用产品池、策略中心之外，还可以进行预警监控系统，主要负责对策略中心中的各个关键节点做预警和监控，例如可以支持服务性能预警、场景预警、策略预警和库存预警。

如图11所示，该系统还包括预警模块600，用以实现对处理信息的各个阶段进行预警。图13示出预警模块的示意图，该预警模块600包括库存预警子模块610、策略预警子模块620、场景预警子模块630和服务性能预警子模块640。

库存预警子模块610用于实时监测通用产品池中理财产品的库存，如果发生库存不足的情况，则进行库存预警。策略预警子模块620用于采用通用过滤策略以及差异化过滤策略进行过滤时，如果任一种策略导致库存为空，则进行策略预警。场景预警子模块630用于根据上层应用的场景采用选择相应的策略包进行装配时，如果某一场景下装配出现异常，则进行场景预警。服务性能预警子模块640用于根据上层应用的场景采用选择相应的策略包进行装配之后，上层应用调用理财产品时，同时监测服务性能，如果服务性能出现异常，则进行服务性能预警。

综上所述，该系统针对不同的理财产品进行标准化处理，以得到数据格式统一的理财产品，从而可以将不同类型的理财产品存入到通用产品池中，便于进行统一管理，并将不同的策略包抽象成一个接口提供给上层应用，可以进行统一调用，方便管理，提高处理效率。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施方式。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。