账单处理方法、装置及计算机可读存储介质与流程

本发明涉及计算机技术领域，尤其涉及一种账单处理方法、装置及计算机可读存储介质。

背景技术：

目前市场上的交易系统有两个，一个是订单系统，一个是渠道方的系统，这两个系统的对账都是通过将渠道方的对账文件落地到数据库中，然后在数据库中对两者的数据做对账操作以及导出文件，然而如果需要对账的数据量很大，历史帐户数据量很大，这种对账方式将会非常慢，而且随着数据量越来越大这种对账性能会越来越差。

技术实现要素：

本发明提供一种账单处理方法、装置及计算机可读存储介质，其主要目的在于实现了对账性能稳定，随着交易的数据量越来越大，对账和导出文件性能不会有明显的下降；可扩展性强。

为实现上述目的，本发明还提供一种账单处理方法，所述方法包括：

获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中；

从渠道方的文件服务器读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上；

调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对；

当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

可选地，所述将订单系统的交易请求相关的交易数据存储于订单系统的数据库中包括：

按照滑动窗口策略，在每个时间窗口启动定时任务，将时间窗口内的订单系统的交易数据分片批量写入hadoop分布式文件系统，按照订单的申请单号的哈希码hashcode进行分片。

可选地，所述调用订单系统的交易数据及渠道方的交易数据包括：

订单系统调用spark集群的driver，启动spark任务调度，spark的各个任务task从nas盘上将渠道方的交易数据读取到spark节点中，其中渠道方的交易数据包括渠道来源标识；

并基于渠道来源标识、根据渠道方的交易数据中订单的申请单号的哈希码hashcode进行重分区处理，处理完后spark节点从hadoop分布式文件系统中读入订单系统的交易数据，分别读取到spark的任务task编号id对应的分片。

可选地，所述当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中，包括：当订单系统的交易数据及渠道方的交易数据进行比对成功时，spark将订单系统的map对象转成string对象写入到hdfs系统；

所有分片写入完成后，调用hadoop分布式文件系统的api，将每个分配的文件合并，并上传到订单系统的nas盘，订单系统将该nas盘下的文件上传到渠道方的sftp服务器上。

可选地，当订单系统的交易数据及渠道方的交易数据进行比对不成功时，接收对问题数据的处理，并重新进行对账。

可选地，所述hadoop分布式文件系统配置有容错结构，其中容错结构由元数据与时间戳组成，相同订单号数据，时间戳大者为有效数据。

为实现上述目的，本发明还提供一种账单处理装置，所述装置包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的账单处理程序，所述账单处理程序被所述处理器执行时实现如下步骤：

获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中；

从渠道方的文件服务器读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上；

调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对；

当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

可选地，所述账单处理程序还可被所述处理器执行，还实现如下步骤：

按照滑动窗口策略，在每个时间窗口启动定时任务，将时间窗口内的订单系统的交易数据分片批量写入hadoop分布式文件系统(hdfs)分布式文件系统，按照订单的申请单号的哈希码hashcode进行分片。

可选地，所述账单处理程序还可被所述处理器执行，实现如下步骤：

订单系统调用spark集群的driver，启动spark任务调度，spark的各个任务task从nas盘上将渠道方的交易数据读取到spark节点中，其中渠道方的交易数据包括渠道来源标识；

并基于渠道来源标识、根据渠道方的交易数据中订单的申请单号的哈希码hashcode进行重分区处理，处理完后spark节点从hadoop分布式文件系统中读入订单系统的交易数据，分别读取到spark的任务task编号id对应的分片。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有账单处理程序，所述账单处理程序可被一个或者多个处理器执行，以实现如上所述的账单处理方法的步骤。

本发明获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中，从渠道方的文件服务器读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的nas盘上，调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对，当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。本发明对账性能稳定，随着交易的数据量越来越大，对账和导出文件性能不会有明显的下降；可扩展性强：可以通过增加机器节点的方式提高性能；减小系统压力：采用类滑动窗口式处理思想，减少对账和导出文件的处理对数据库造成的压力；业务容错：针对hadoop分布式文件系统只可新增和追加的特点，设计容错结构，避免数据修改带来大的性能损耗。

附图说明

图1为本发明一实施例提供的账单处理方法的流程示意图；

图2为本发明一实施例提供的账单处理装置的内部结构示意图；

图3为本发明一实施例提供的账单处理装置中账单处理程序的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明提供一种账单处理方法。参照图1所示，为本发明一实施例提供的账单处理方法的流程示意图。该方法可以由一个装置执行，该装置可以由软件和/或硬件实现。

在本实施例中，账单处理方法包括：

s10、获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中。

在本实施例中，渠道方发送实时交易请求给到订单系统，订单系统实时将交易请求相关的交易数据存储于数据库。

优选地，所述将订单系统的交易请求相关的交易数据存储于订单系统的数据库中包括：

按照滑动窗口策略，在每个时间窗口启动定时任务，将时间窗口内的订单系统的交易数据分片批量写入hadoop分布式文件系统(hdfs)，按照订单的申请单号的哈希码hashcode进行分片。例如文件名以0开始，步长为1，递增。

s20、从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的nas盘上。

在本实施例中，从渠道方的文件服务器上定期(如每天等等)读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上。定期读取的时间频率可以事先配置。

其中，按照渠道方的订单的申请单号的哈希码hashcode进行分片。例如文件名以0开始，步长为1，递增。

s30、调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对。

其中以集群的架构形式管理订单系统的交易数据及渠道方的交易数据。spark应用在集群上以独立的进程集合运行，在主程序(称作驱动程序)中以sparkcontext对象来调节。特别的，为了在集群上运行，sparkcontext可以与几个类型的集群管理器(spark自身单独的集群管理器或者mesos/yarn)相连接，这些集群管理器可以在应用间分配资源。一旦连接，spark需要在集群上的线程池子节点，也就是那些执行计算和存储应用数据的工作进程。然后，它将把你的应用代码(以jar或者python定义的文件并传送到sparkcontext)发送到线程池。最后，sparkcontext发送任务让线程池运行。

各个应用有自己的线程池进程，会在整个应用的运行过程中保持并在多个线程中运行任务。这样做的好处是把应用相互孤立，既在调度方面(各个驱动调度它自己的任务)也在执行方面(不同应用的任务在不同的jvm上运行)。

对于潜在的集群管理器来说，spark是不可知的。只要它需要线程池的进程和它们间的通信，那么即使是在也支持其他应用的集群管理器(例如，mesos/yarn)上运行也相对简单。

因为驱动在集群上调度任务，它应该运行接近到工作节点，在相同的局域网内更好。

优选地，所述调用订单系统的交易数据及渠道方的交易数据包括：

订单系统调用spark集群的driver，启动spark任务调度，spark的各个任务task从nas盘上将渠道方的交易数据读取到spark节点中，其中渠道方的交易数据包括渠道来源标识；并基于渠道来源标识、根据渠道方的交易数据中订单的申请单号的哈希码hashcode进行重分区步骤处理，处理完后spark节点从hdfs系统中读入订单系统的交易数据，分别读取到spark的任务task编号id对应的分片。

优选地，通过上面的处理步骤后，在spark中的各个分片中存在了订单系统的交易数据和渠道方的交易数据，各个任务task开始比对对订单系统的交易数据和渠道方的交易数据处理。

s40、当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

优选地，当订单系统的交易数据及渠道方的交易数据进行比对成功时，也就是订单系统的交易数据和渠道方的交易数据完全一致时，spark将订单系统的map对象转成string对象写入到hdfs系统；所有分片写入完成后，调用hdfs系统的api，将每个分配的文件合并，并上传到订单系统的nas盘，订单系统将该nas盘下的文件上传到渠道方的sftp服务器上。

当订单系统的交易数据及渠道方的交易数据进行比对不成功时，也就是说对账有问题，则需要人工处理数据，将数据处理完成后，在次重复上面的步骤重新对账。

因此，优选地，当订单系统的交易数据及渠道方的交易数据进行比对不成功时，接收对问题数据的处理，并重新进行对账。

优选地，所述hdfs系统配置有容错结构，其中容错结构由元数据与时间戳组成。相同订单号数据，时间戳大者为有效数据。因为针对hdfs上数据可能修改，同时hdfs不支持修改的问题，涉及一个容错结构，避免因数据修改而重新导入数据库数据。容错结构由元数据与时间戳组成，相同订单号数据，时间戳大者为有效数据。

本发明获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中，从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的nas盘上，调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对，当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。本发明对账性能稳定，随着交易的数据量越来越大，对账和导出文件性能不会有明显的下降；可扩展性强：可以通过增加机器节点的方式提高性能；减小系统压力：采用类滑动窗口式处理思想，减少对账和导出文件的处理对数据库造成的压力；业务容错：针对hdfs只可新增和追加的特点，设计容错结构，避免数据修改带来大的性能损耗。

本发明还提供一种账单处理装置。参照图2所示，为本发明一实施例提供的账单处理装置的内部结构示意图。

在本实施例中，账单处理装置1可以是pc(personalcomputer，个人电脑)，也可以是智能手机、平板电脑、便携计算机等终端设备。该账单处理装置1至少包括存储器11、处理器12，通信总线13，以及网络接口14。

其中，存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、磁性存储器、磁盘、光盘等。存储器11在一些实施例中可以是账单处理装置1的内部存储单元，例如该账单处理装置1的硬盘。存储器11在另一些实施例中也可以是账单处理装置1的外部存储设备，例如账单处理装置1上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。进一步地，存储器11还可以既包括账单处理装置1的内部存储单元也包括外部存储设备。存储器11不仅可以用于存储安装于账单处理装置1的应用软件及各类数据，例如账单处理程序01的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。

处理器12在一些实施例中可以是一中央处理器(centralprocessingunit,cpu)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器11中存储的程序代码或处理数据，例如执行账单处理程序01等。

通信总线13用于实现这些组件之间的连接通信。

网络接口14可选的可以包括标准的有线接口、无线接口(如wi-fi接口)，通常用于在该装置1与其他电子设备之间建立通信连接。

可选地，该装置1还可以包括用户接口，用户接口可以包括显示器(display)、输入单元比如键盘(keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是led显示器、液晶显示器、触控式液晶显示器以及oled(organiclight-emittingdiode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在账单处理装置1中处理的信息以及用于显示可视化的用户界面。

图2仅示出了具有组件11-14以及账单处理程序01的账单处理装置1，本领域技术人员可以理解的是，图1示出的结构并不构成对账单处理装置1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

在图2所示的装置1实施例中，存储器11中存储有账单处理程序01；处理器12执行存储器11中存储的账单处理程序01时实现如下步骤：

获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中。

在本实施例中，渠道方发送实时交易请求给到订单系统，订单系统实时将交易请求相关的交易数据存储于数据库。

进一步地，在本发明装置的另一实施例中，账单处理程序还可被处理器调用，以实现如下步骤：

按照滑动窗口策略，在每个时间窗口启动定时任务，将时间窗口内的订单系统的交易数据分片批量写入hadoop分布式文件系统(hdfs)，按照订单的申请单号的哈希码hashcode进行分片。例如文件名以0开始，步长为1，递增。

从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的nas盘上。

在本实施例中，从渠道方的文件服务器上定期(如每天等等)读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上。定期读取的时间频率可以事先配置。

其中，按照渠道方的订单的申请单号的哈希码hashcode进行分片。例如文件名以0开始，步长为1，递增。

调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对。

其中以集群的架构形式管理订单系统的交易数据及渠道方的交易数据。spark应用在集群上以独立的进程集合运行，在主程序(称作驱动程序)中以sparkcontext对象来调节。特别的，为了在集群上运行，sparkcontext可以与几个类型的集群管理器(spark自身单独的集群管理器或者mesos/yarn)相连接，这些集群管理器可以在应用间分配资源。一旦连接，spark需要在集群上的线程池子节点，也就是那些执行计算和存储应用数据的工作进程。然后，它将把你的应用代码(以jar或者python定义的文件并传送到sparkcontext)发送到线程池。最后，sparkcontext发送任务让线程池运行。

各个应用有自己的线程池进程，会在整个应用的运行过程中保持并在多个线程中运行任务。这样做的好处是把应用相互孤立，既在调度方面(各个驱动调度它自己的任务)也在执行方面(不同应用的任务在不同的jvm上运行)。

对于潜在的集群管理器来说，spark是不可知的。只要它需要线程池的进程和它们间的通信，那么即使是在也支持其他应用的集群管理器(例如，mesos/yarn)上运行也相对简单。

因为驱动在集群上调度任务，它应该运行接近到工作节点，在相同的局域网内更好。

优选地，账单处理程序还可被处理器调用，以实现如下步骤包括：

订单系统调用spark集群的driver，启动spark任务调度，spark的各个任务task从nas盘上将渠道方的交易数据读取到spark节点中，其中渠道方的交易数据包括渠道来源标识；并基于渠道来源标识、根据渠道方的交易数据中订单的申请单号的哈希码hashcode进行重分区步骤处理，处理完后spark节点从hdfs系统中读入订单系统的交易数据，分别读取到spark的任务task编号id对应的分片。

优选地，通过上面的处理步骤后，在spark中的各个分片中存在了订单系统的交易数据和渠道方的交易数据，各个任务task开始比对对订单系统的交易数据和渠道方的交易数据处理。

当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

优选地，当订单系统的交易数据及渠道方的交易数据进行比对成功时，也就是订单系统的交易数据和渠道方的交易数据完全一致时，spark将订单系统的map对象转成string对象写入到hdfs系统；所有分片写入完成后，调用hdfs系统的api，将每个分配的文件合并，并上传到订单系统的nas盘，订单系统将该nas盘下的文件上传到渠道方的sftp服务器上。

当订单系统的交易数据及渠道方的交易数据进行比对不成功时，也就是说对账有问题，则需要人工处理数据，将数据处理完成后，在次重复上面的步骤重新对账。

因此，优选地，当订单系统的交易数据及渠道方的交易数据进行比对不成功时，接收对问题数据的处理，并重新进行对账。

优选地，所述hdfs系统配置有容错结构，其中容错结构由元数据与时间戳组成。相同订单号数据，时间戳大者为有效数据。因为针对hdfs上数据可能修改，同时hdfs不支持修改的问题，涉及一个容错结构，避免因数据修改而重新导入数据库数据。容错结构由元数据与时间戳组成，相同订单号数据，时间戳大者为有效数据。

本发明获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中，从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的nas盘上，调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对，当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。本发明对账性能稳定，随着交易的数据量越来越大，对账和导出文件性能不会有明显的下降；可扩展性强：可以通过增加机器节点的方式提高性能；减小系统压力：采用类滑动窗口式处理思想，减少对账和导出文件的处理对数据库造成的压力；业务容错：针对hdfs只可新增和追加的特点，设计容错结构，避免数据修改带来大的性能损耗。

可选地，在其他实施例中，账单处理程序还可以被分割为一个或者多个模块，一个或者多个模块被存储于存储器11中，并由一个或多个处理器(本实施例为处理器12)所执行以完成本发明，本发明所称的模块是指能够完成特定功能的一系列计算机程序指令段，用于描述账单处理程序在账单处理装置中的执行过程。

例如，参照图3所示，为本发明账单处理装置一实施例中的账单处理程序的程序模块示意图，该实施例中，账单处理程序可以被分割为板块获取模块10、存储模块20、比对模块30和发送模块40，示例性地：

获取模块10用于：获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中；

存储模块20用于：从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上；

比对模块30用于：调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对；

发送模块40用于：当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

上述获取模块10、存储模块20、比对模块30和发送模块40等程序模块被执行时所实现的功能或操作步骤与上述实施例大体相同，在此不再赘述。

此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有账单处理程序，所述账单处理程序可被一个或多个处理器执行，以实现如下操作：

获取订单系统的交易请求，将订单系统的交易请求相关的交易数据存储于订单系统的数据库中；

从渠道方的文件服务器上读取渠道方的交易数据，将渠道方的交易数据存储于订单系统的网络附属存储nas盘上；

调用订单系统的交易数据及渠道方的交易数据，将订单系统的交易数据及渠道方的交易数据进行比对；

当订单系统的交易数据及渠道方的交易数据进行比对成功时，将订单系统的nas盘中的文件上传到渠道方的文件服务器中。

本发明计算机可读存储介质具体实施方式与上述账单处理装置和方法各实施例基本相同，在此不作累述。

需要说明的是，上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。并且本文中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。