CN105808656B - 一种用于自助取数的处理架构及其取数方法 - Google Patents

Abstract

本发明实施例公开了一种用于自助取数的处理架构及其取数方法，解决了目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，而导致的效率低下的技术问题。本发明实施例用于自助取数的处理架构包括：Presto查询引擎、数据仓库和分布式文件系统；其中，Presto查询引擎通过获取到筛选指令进行在数据仓库提取满足筛选指令的SQL语句，并生成与SQL语句对应的结果表，并存储在分布式文件系统中，使得将满足筛选指令的数据进行导出处理。

Description

一种用于自助取数的处理架构及其取数方法

技术领域

本发明涉及大数据技术领域，尤其涉及一种用于自助取数的处理架构及其取数方法。

背景技术

大数据就是互联网发展到现今阶段的一种表象或特征而已，没有必要神话它或对它保持敬畏之心，在以云计算为代表的技术创新大幕的衬托下，这些原本很难收集和使用的数据开始容易被利用起来了，通过各行各业的不断创新，大数据会逐步为人类创造更多的价值。

电子商务是以信息网络技术为手段，以商品交换为中心的商务活动；也可理解为在互联网(Internet)、企业内部网(Intranet)和增值网(VAN，Value Added Network)上以电子交易方式进行交易活动和相关服务的活动，是传统商业活动各环节的电子化、网络化、信息化。电子商务通常是指在全球各地广泛的商业贸易活动中，在因特网开放的网络环境下，基于浏览器/服务器应用方式，买卖双方不谋面地进行各种商贸活动，实现消费者的网上购物、商户之间的网上交易和在线电子支付以及各种商务活动、交易活动、金融活动和相关的综合服务活动的一种新型的商业运营模式。各国政府、学者、企业界人士根据自己所处的地位和对电子商务参与的角度和程度的不同，给出了许多不同的定义。电子商务分为：ABC、B2B、B2C、C2C、B2M、M2C、B2A(即B2G)、C2A(即C2G)、O2O等。同时网络营销也是电子商务的一种产物，而且对于网络营销来说，在做之前要先做好网络营销方案，那样才有便于计划的实施。

目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，从而导致了效率低下的技术问题。

发明内容

本发明实施例提供的一种用于自助取数的处理架构及其取数方法，解决了目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，而导致的效率低下的技术问题。

本发明实施例提供的一种用于自助取数的处理架构，包括：

Presto查询引擎、数据仓库和分布式文件系统；

其中，所述Presto查询引擎通过获取到筛选指令进行在所述数据仓库提取满足所述筛选指令的SQL语句，并生成与所述SQL语句对应的结果表，并存储在所述分布式文件系统中，使得将满足所述筛选指令的数据进行导出处理。

优选地，所述Presto查询引擎为SQL引擎。

优选地，所述SQL引擎包括：

初条件分类单元，用于进行有where过滤条件又有having过滤条件的SQL子查询处理；

第一筛选处理单元，用于进行union分组上移归并到所述SQL子查询的处理；

第二筛选处理单元，用于进行所述SQL子查询的条件下移到所述union分组处理；

第三筛选处理单元，用于进行完全下移判定，从所述SQL子查询中移除SQL语句处理。

优选地，所述初条件分类单元，具体用于进行所有所述union分组中所有的where过滤条件的非聚合条件合并为一个where非聚合子查询,剩下的与所述非聚合条件相对应的所有聚合条件按照同属一表的SQL语句或不同属一表的SQL语句归类处理，并将同属一表的SQL语句合并为一个子查询。

优选地，所述第一筛选处理单元，具体用于将所述union分组中只有一个where过滤条件的非聚合子查询和/或所述union分组中只有一个having过滤条件的只有一个聚合子查询，进行上移归并到所述SQL子查询的处理。

优选地，所述第二筛选处理单元，具体用于将所述SQL子查询中的过滤条件以是否同属一个表为集合单位，将对应的限制条件整体下移到所述union分组里有相同表的子查询中。

优选地，所述第三筛选处理单元，具体用于将当所述SQL子查询中一个表单位的所有条件在一个所述union分组中被完全下移到union中的每个子查询中时，则进行完全下移处理。

优选地，所述用于自助取数的处理架构还包括：

复数个应用服务器、负载均衡路由装置和客户端；

所述客户端与所述负载均衡路由装置通信连接，所述负载均衡路由装置与所述应用服务器通信连接；

所述应用服务器与所述Presto查询引擎、所述数据仓库和所述分布式文件系统组成的资源层通信连接。

本发明实施例提供的一种自助取数的处理架构的取数方法，包括：

获取到筛选指令，并确定与所述筛选指令对应的筛选条件；

获取到与所述筛选条件相对应的导出字段；

确定与所述筛选条件、所述导出字段相对应的导出时间，并保存。

优选地，所述导出字段为用户账号和/或用户名和/或营销手机号。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例提供的一种用于自助取数的处理架构及其取数方法，其中，用于自助取数的处理架构包括：Presto查询引擎、数据仓库和分布式文件系统；其中，Presto查询引擎通过获取到筛选指令进行在数据仓库提取满足筛选指令的SQL语句，并生成与SQL语句对应的结果表，并存储在分布式文件系统中，使得将满足筛选指令的数据进行导出处理。本实施例中，通过Presto查询引擎通过获取到筛选指令进行在数据仓库提取满足筛选指令的SQL语句，并生成与SQL语句对应的结果表，并存储在分布式文件系统中，使得将满足筛选指令的数据进行导出处理，解决了目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，而导致的效率低下的技术问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例提供的一种用于自助取数的处理架构的一个实施例的结构示意图；

图2为本发明实施例提供的一种自助取数的处理架构的取数方法的一个实施例的流程示意图；

图3为自助取数功能结构示意图；

图4为自助取数任务列表的界面示意图；

图5为条件筛选的界面示意图；

图6为导出的界面示意图；

图7为功能的界面示意图

图8(a)至(f)为案例一的界面示意图

图9(a)至(c)为自助取数的处理架构的取数方法应用例的界面示意图。

具体实施方式

本发明实施例提供的一种用于自助取数的处理架构及其取数方法，解决了目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，而导致的效率低下的技术问题。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1，本发明实施例提供的一种用于自助取数的处理架构一个实施例包括：

Presto查询引擎11、数据仓库12和分布式文件系统13；

其中，所述Presto查询引擎11通过获取到筛选指令进行在所述数据仓库12提取满足所述筛选指令的SQL语句，并生成与所述SQL语句对应的结果表，并存储在所述分布式文件系统13中，使得将满足所述筛选指令的数据进行导出处理。

进一步地，所述Presto查询引擎11为SQL引擎。

进一步地，所述SQL引擎包括：

初条件分类单元，用于进行有where过滤条件又有having过滤条件的SQL子查询处理；

第一筛选处理单元，用于进行union分组上移归并到所述SQL子查询的处理；

第二筛选处理单元，用于进行所述SQL子查询的条件下移到所述union分组处理；

第三筛选处理单元，用于进行完全下移判定，从所述SQL子查询中移除SQL语句处理。

进一步地，所述初条件分类单元，具体用于进行所有所述union分组中所有的where过滤条件的非聚合条件合并为一个where非聚合子查询,剩下的与所述非聚合条件相对应的所有聚合条件按照同属一表的SQL语句或不同属一表的SQL语句归类处理，并将同属一表的SQL语句合并为一个子查询。

进一步地，所述第一筛选处理单元，具体用于将所述union分组中只有一个where过滤条件的非聚合子查询和/或所述union分组中只有一个having过滤条件的只有一个聚合子查询，进行上移归并到所述SQL子查询的处理。

进一步地，所述第二筛选处理单元，具体用于将所述SQL子查询中的过滤条件以是否同属一个表为集合单位，将对应的限制条件整体下移到所述union分组里有相同表的子查询中。

进一步地，所述第三筛选处理单元，具体用于将当所述SQL子查询中一个表单位的所有条件在一个所述union分组中被完全下移到union中的每个子查询中时，则进行完全下移处理。

进一步地，所述用于自助取数的处理架构还包括：

复数个应用服务器、负载均衡路由装置和客户端；

所述客户端与所述负载均衡路由装置通信连接，所述负载均衡路由装置与所述应用服务器通信连接；

所述应用服务器与所述Presto查询引擎、所述数据仓库和所述分布式文件系统组成的资源层通信连接。

需要说明的是，SQL引擎的实现过程如下：

名词解释

主题是对一群相关表的归纳、聚集。一个主题下包含了若干个表，一个主题规定了一个关联键，此关联键是该主题下所有表都必须包含的,每个主题都有指定的一个主表,该主题下其它表用主题的关联键和该表join。一个表可以属于多个主题。主题之前也存在包含关系，一个主题可以是其父主题的原子组成部分。

多批次导出字段，引擎解析条件后转化为若干个sql任务(针对不同类型的数据源,对应的sql任务也会不同),其中间结果为请求中的顶级主题的去重关联键作为唯一字段的临时表。比如:用户基本信息作为顶级主题，那么对应的结果表就是user_id数据集合。而多批次导出字段可以拆分为多个导出任务,每个导出任务包含若干个导出字段,产生和中间结果表join后生成其它若干字段的结果表。

且，表明相邻的两个筛选条件必须都满足

或，表明相邻的两个筛选条件满足一个即可

过滤器，代表了某个主题下的一系列条件过滤组合，一个过滤器必指定一个主题，一个过滤器可以标记为包含或者不包含，其中不包含的意思是在最后结果中要排除该过滤器下所有符合情况的数据。

交集，过滤器之间以且关联

并集，过滤器之间以或关联

补集，排除某个过滤器的筛选结果

该引擎对数据的筛选就好像是2层星型模型

每个主题按照自己的关联键进行join，得到该主题所属的父主题关联键对应的结果集合，然后继续作为整体的一个单元再向上降纬重复循环直到顶级。

自助取数生成的zip文件提供最长半年的保存时间，之后将过期。

实际引擎代码的实现预设了两个前提:1逻辑嵌套最多两层、2或优先级高于且。例:A and B and(C or D)and(E or F or G)。

名词说明:w带有非聚合过滤条件相当于sql中的where的一部分的子查询、h带有聚合性质的过滤条件相当于sql中having中的一部分的子查询(h1h2...分别代指多个having子查询)、wh指既有where又有having过滤条件的sql子查询(子查询内部可能也有join)、join子查询之间的自然关联、union子查询之间的union操作。

1.初步条件分类wh join(w1 union h1 union h2)join(w2 union h3)。所有union分组中所有的w非聚合条件合并为一个w非聚合子查询,剩下的所有聚合条件按照是否同属一表进行归类，同属一表的合并为一个子查询即:w union h1union h2，h1h2分属不同的表。

2.union分组上移归并到wh。以下几种情况的union分组不再视为union分组而合并至wh中，如(w)只有一个非聚合子查询、(h)只有一个聚合子查询。

3.wh条件下移到union分组。wh中的filter条件以是否同属一个表为集合单位，将对应的限制条件整体下移到union分组里有相同表的子查询中，原则上不在子查询中增加新的join。

4.完全下移判定，从wh中移除。如果wh中一个表单位的所有条件在某一个union分组中被完全下移到union中的每个子查询中则视为完全下移，这样在wh中就不再保留该表相关的所有字段限制条件，即wh中将减少该表的join，从而达到了减少join次数的目的。

PS:在以上4个步骤中第一第二步完成了符合预期的可用sql。第三第四步提供了对sql的性能优化，优化遵循的原则是：减少可能的join次数、减少每个待join的子查询的数据集大小(通过增加更多的where或having限制达到)。

如图3所示的自助取数功能结构，如下表：

如图4所示，任务列表页。

如图5所示，输入框支持导入excel和csv。

如图7所示，任务名称区

·定义任务的名

·2.条件筛选区

·2.1默认包含，表示包含此过滤器中筛选出的人群；不包含表示排除此过滤器筛选出的人群

·2.2选择要筛选的业务主题，当前可选用户基本信息、访问、收藏、营销、优惠券、购物车、订单七大模块

·2.3选择筛选条件值。条件之间的关系可选“且”、“或”，分别表示交集、并集关系

·2.4新增过滤器，不同过滤器之间是交集关系

·3.导出设置区

·3.2如果导出内容需要排序，此处设置排序字段

·4.任务设置区

·4.1设定排除其他任务，将排除另一任务筛选出的所有用户

·4.2设定执行任务的时间，如选立即，则保存时立即开始执行任务；选不导出，保存时不执行；设定时间，则在设定的时间执行任务。

下面以多个案例进行描述：

案例一：

715早预热第一轮9:00 1对1收藏人群或历史收藏了大促品牌的人群

步骤1.将过滤器主题选为“商品收藏”，并设定收藏时间2015-07-13 10:00至2015-07-15 07：00

步骤2.点击“且”增加一个过滤条件，选择“档期ID”，输入预热档期ID列表(不同ID之间“；”分割)

步骤3.点击“且”增加一个过滤条件，设定收藏状态为”收藏”,过滤掉已删除收藏的用户；

步骤4.增加一个过滤器，选择主题为“用户基本信息”，并设定用户注册的时间(最早2008年8月25号开始有数据)

步骤5.点击“且”增加一个过滤条件，选择主账户，设定值为1，再设定营销手机能接受push或者能接受短信。

步骤6.命名这个任务，假设命名为“715商品收藏预热”，并设定导出内容为“用户id”,“营销手机是否接受PUSH”，“营销手机是否接受短信”，设定导出时间，设定内容的排序字段(可选)，每个文件最大数据量(可选)，保存。

步骤7.待任务执行完成后，导出文件，分别筛选出能收PUSH的用户id(即user_id)导出到营销系统中发送PUSH，筛选出能接受短信不能接受PUSH的用户id导入到营销系统中发送。

步骤8.复制刚刚建成功的案例“715商品收藏预热”，修改任务名称为“715品牌收藏预热”，将“商品收藏”过滤器改为“品牌收藏”，设定收藏时间为历史某个时间段(收藏最早2013-06-04号)，设定收藏品牌为大促品牌。

步骤9.设定导出任务排除“715商品收藏预热”，防止二次打扰客户，剩余操作同步骤7。

案例二

7月18日早9：00预热第三轮：715 1对1收藏人群或历史收藏了大促品牌的人群中，715以来无访问网站人群。

步骤1.复制案例一的“715商品收藏预热”，修改任务名称为“715以来有商品收藏无访问”,修改商品收藏的时间为2015-07-15 10:00至2015-07-18 07:00

步骤2.在复制的任务上增加一个过滤器，选择包含关系为“不包含”，选择主题为“访问”，并设定访问时间为2015-07-15 10：00至2015-07-18 07：00

步骤3.设定导出内容为“用户id”,“营销手机是否接受PUSH”，“营销手机是否接受短信”，设定导出时间，设定内容的排序字段(可选)，每个文件最大数据量(可选)，保存。

步骤4.待任务执行完成后，导出文件，分别筛选出能收PUSH的用户id(即user_id)导出到营销系统中发送PUSH，筛选出能接受短信不能接受PUSH的用户id导入到营销系统中发送

步骤5.复制案例一创建的任务“715品牌收藏预热”，修改任务名称为“718-715历史有品牌收藏无访问”

步骤6.操作同步骤2，添加筛选出715未来访用户的过滤器

步骤7.设定导出时排除任务“718-715以来有商品收藏无访问”，防止二次打扰客户

步骤9.同步骤3-4

案例三

7月18日晚6:00，预热期间无红包无收藏的活跃高危用户

步骤1.复制案例一种创建的任务“715商品收藏预热”，修改任务名称为“718-预热无商品收藏无红包”，将“商品收藏”过滤器关系改为“不包含”

步骤2.添加一个过滤器，包含关系选为“不包含”，将过滤器主题选为“优惠券”，”领券时间”选为大促预热时间

步骤3.添加一个“且”条件，“优惠券券类型”设置为“719IN大促”或选择券ID输入719IN大促的券号

步骤4.在“用户基本信息“主题中增加一个”且“条件，选择活跃状态属于“活跃”,”高危”

设定导出内容为“用户id”,“营销手机是否接受PUSH”，“营销手机是否接受短信”，设定导出时间，设定内容的排序字段(可选)，每个文件最大数据量(可选)，保存。

步骤4.待任务执行完成后，导出文件，分别筛选出能收PUSH的用户id(即user_id)导出到营销系统中发送PUSH，筛选出能接受短信不能接受PUSH的用户id导入到营销系统中发送

步骤5.按照如上步骤复制案例一创建的“715品牌收藏预热”，筛选出历史没有收藏过大促品牌并且无红包的活跃高危用户群，并排除任务“718-预热无商品收藏无红包”，导入到营销系统中发送。

本实施例中，通过所述Presto查询引擎11通过获取到筛选指令进行在所述数据仓库12提取满足所述筛选指令的SQL语句，并生成与所述SQL语句对应的结果表，并存储在所述分布式文件系统13中，使得将满足所述筛选指令的数据进行导出处理，解决了目前的电子商务在贸易过程中，在电子商务平台端需要做大型营销时，需要有针对性的提取用户数据，便于精准营销，然而现有的数据量太大，容易导致在用户数据的提取过程中产生错误，而导致的效率低下的技术问题。

请参阅图2，本发明实施例中提供的一种自助取数的处理架构的取数方法的一个实施例包括：

201、获取到筛选指令，并确定与筛选指令对应的筛选条件；

202、获取到与筛选条件相对应的导出字段；

203、确定与筛选条件、导出字段相对应的导出时间，并保存。

如图9(a)至(c)所示，应用例包括：

步骤一：选择筛选条件

1、给任务起个名字，选择【用户】主题下的【订单】表；

2、选择活动时间段，截至到2015年9月28日09：59，选到9月28日10：00；

3、历史无订单用户：用户类型选择新客；

4、购买指定专题页的商品，及用户购买过的专题选择【专题id】，输入指定专题id；

5、订单为有效订单；

步骤二、设置导出字段，导出条件等；

选择导出字段：user_id，会员名，营销手机号；

步骤三、设定导出时间，并保存。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (8)

1.一种用于自助取数的处理架构，其特征在于，包括：

Presto查询引擎、数据仓库和分布式文件系统；

其中，所述Presto查询引擎通过获取到筛选指令进行在所述数据仓库提取满足所述筛选指令的SQL语句，并生成与所述SQL语句对应的结果表，并存储在所述分布式文件系统中，使得将满足所述筛选指令的数据进行导出处理；

所述Presto查询引擎为SQL引擎；

所述SQL引擎包括：

初条件分类单元，用于进行有where过滤条件又有having过滤条件的SQL子查询处理；

第一筛选处理单元，用于进行union分组上移归并到所述SQL子查询的处理；

第二筛选处理单元，用于进行所述SQL子查询的条件下移到所述union分组处理；

第三筛选处理单元，用于进行完全下移判定，从所述SQL子查询中移除SQL语句处理。

2.根据权利要求1所述的用于自助取数的处理架构，其特征在于，所述初条件分类单元，具体用于进行所有所述union分组中所有的where过滤条件的非聚合条件合并为一个where非聚合子查询,剩下的与所述非聚合条件相对应的所有聚合条件按照同属一表的SQL语句或不同属一表的SQL语句归类处理，并将同属一表的SQL语句合并为一个子查询。

3.根据权利要求2所述的用于自助取数的处理架构，其特征在于，所述第一筛选处理单元，具体用于将所述union分组中只有一个where过滤条件的非聚合子查询和/或所述union分组中只有一个having过滤条件的聚合子查询，进行上移归并到所述SQL子查询的处理。

4.根据权利要求2所述的用于自助取数的处理架构，其特征在于，所述第二筛选处理单元，具体用于将所述SQL子查询中的过滤条件以是否同属一个表为集合单位，将对应的限制条件整体下移到所述union分组里有相同表的子查询中。

5.根据权利要求2所述的用于自助取数的处理架构，其特征在于，所述第三筛选处理单元，具体用于将当所述SQL子查询中一个表单位的所有条件在一个所述union分组中被完全下移到union中的每个子查询中时，则进行完全下移处理。

6.根据权利要求1至5中任意一项所述的用于自助取数的处理架构，其特征在于，所述用于自助取数的处理架构还包括：

复数个应用服务器、负载均衡路由装置和客户端；

所述客户端与所述负载均衡路由装置通信连接，所述负载均衡路由装置与所述应用服务器通信连接；

所述应用服务器与所述Presto查询引擎、所述数据仓库和所述分布式文件系统组成的资源层通信连接。

7.一种自助取数的处理架构的取数方法，通过如权利要求1～6中任意一项所述的用于自助取数的处理架构实现，其特征在于，包括：

获取到筛选指令，并确定与所述筛选指令对应的筛选条件；

获取到与所述筛选条件相对应的导出字段；

确定与所述筛选条件、所述导出字段相对应的导出时间，并保存。

8.根据权利要求7所述的自助取数的处理架构的取数方法，其特征在于，所述导出字段为用户账号和/或用户名和/或营销手机号。