一种基于分布式数据节点的对账系统的制作方法

1.本发明涉及财务管理系统技术领域，具体涉及一种基于分布式数据节点的对账系统。


背景技术：

2.传统的对账是指核对账目，是指在会计核算中，为保证账簿记录正确可靠，对账簿中的有关数据进行检查和核对的工作。在银行或者第三方支付公司中，对账是对一定周期内的交易进行双方确认的过程，一般都是在第二天对前一日交易进行清分，生成对账单供平台商户下载，并将应结算款结算给平台商户。再往下一层，在互联网金融行业或者电商行业中，对账是确认在固定周期内和支付提供方(银行和第三方支付公司)的交易、资金的正确性，保证双方的交易、资金一致正确。
3.广义地来说，所有跨应用的数据交互理论上都应该进行对账。所以对账也可以分为信息流对账，资金流对账。信息流对账一般用在自己内部系统的对账，比如支付系统的支付数据和业务系统的业务数据进行对账，保证资金交易和业务交易的一致性。资金流对账也就是支付系统和银行或者第三方支付系统之间的资金交易对账。
4.现有的对账技术主要存在以下缺点：
5.1、合作行无法实时了解到引发备付金账户变动的贷款借还交易明细信息；
6.2、合作行无法及时了解到账务是否不平；
7.3、合作行需要自己开发对账系统；
8.4、缺乏统一全面的信息视图；
9.5、对账过程中查询相关数据，如果数据量巨大，对数据库性能影响较大，而且对账逻辑扩展极为麻烦；
10.6、逐行比对算法效率较低，但算法上并无好的优化余地，如果采用数据库intersect、minus，对数据库压力也高；
11.7、在业务量大的情况下，如有上百家上游渠道需要对，每家都有几十万条交易记录，对账服务器及数据库服务器负荷较高，即便采用读写分离，对账时候使用读库，压力一样很大；
12.8、导入批量文件，逐行入库效率较为低下，每一次都需要建立网络连接、关闭连接。
13.针对以上缺点，本发明的目的即在于提出一种能够解决以上问题的对账系统。


技术实现要素：

14.为克服现有技术的不足，本发明提出一种基于分布式数据节点的对账系统，能确保数据的真实透明可追溯，提升了对账的时效性与准确度。
15.为实现上述目的，本发明的一种基于分布式数据节点的对账系统，一种基于分布式数据节点的对账系统，包括：用于对接各交易方支付系统的分布式节点，分布式节点上设
有：
16.文件获取模块，用于下载或读取各渠道的对账文件；
17.文件解析模块，用于创建不同的解析模板，根据渠道和文件类型获取对应的解析模板进行解析；
18.对账处理模块，用于对账的业务逻辑处理；
19.差错处理模块，处理差错池中的订单。
20.进一步地，文件获取模块的文件获取方式包括主动获取、对方推送和人工上传，主动获取通过定时任务在每天的固定时间点触发下载文件的操作，主动获取具备重试机制，在下载文件失败的情况下会进行重新下载文件的操作。
21.进一步地，文件解析模块解析的文件类型包括且不限于excel、txt和cvc，文件解析模块将不同渠道的账单数据、订单数据解析后统一转化并存入通用的账单数据表中，账单数据表对不同的数据端进行定义并赋予相应的字段并填入表中，账单数据表采用glusterfs文件存储，账单数据表存储在postgresql数据库上。
22.进一步地，对账处理模块在获取账单数据表后对账单数据和支付订单数据进行比对，对账处理模块将账单数据、支付订单数据分别清洗到账单待对账中间表和订单待对账中间表中，然后将两张中间表进行sql full join操作得到一个集合全量，集合包括一个交集、两个补集，处于交集部分的数据集进行订单金额的比对一致则说明无差错，对平的数据集按照结算数据要求取账单数据结合平台订单数据业务字段全集，直接生成对账明细表，不一致的则需要生成差错数据并记入对账差错数据表移入差错池。
23.进一步地，对账处理模块处理后的对账数据采用tidb分布式关系型数据库存储。
24.进一步地，差错信息表根据差错类型记录该笔差错的详细信息，包括不限于渠道类型、金额、交易时间，并会对差错进行分类，定义特定的差错类型编码，根据不同情况将差错分为：长款、短款、金额错误。
25.进一步地，对于长款差错的处理包括人工合账、平账，或自动处理。
26.进一步地，分布式节点运行的系统采用开源系统，采用glusterfs作为存储系统，交易各方通过https将交易流水、资金流水上传。
27.本发明的一种基于分布式数据节点的对账系统利用分布式多信任节点技术将备付金交易信息分支节点，确保数据的真实透明可追溯，解决支付系统与合作方的对账问题，降低了合作方的人力和时间成本，提升了对账的时效性与准确度，非常适用于金融行业的交易数据同步和对账等场景，解决传统“批量文件对账”模式长久以来未能解决的问题。
附图说明
28.下面结合附图对本发明作进一步描写和阐述。
29.图1是本发明首选实施方式的一种基于分布式数据节点的对账系统的系统框图；
30.图2是一种基于分布式数据节点的对账系统的流程图；
31.图3是长款差错消除的流程图；
32.图4是短款差错消除的流程图。
具体实施方式
33.下面将结合附图、通过对本发明的优选实施方式的描述，更加清楚、完整地阐述本发明的技术方案。
34.如图1所示，本发明的一种基于分布式数据节点的对账系统，包括：用于对接各交易方支付系统的分布式节点，分布式节点上设有：
35.文件获取模块，用于下载或读取各渠道的对账文件，文件获取模块的文件获取方式包括主动获取、对方推送和人工上传，主动获取通过定时任务在每天的固定时间点触发下载文件的操作，主动获取具备重试机制，在下载文件失败的情况下会进行重新下载文件的操作；
36.文件解析模块，用于创建不同的解析模板，根据渠道和文件类型获取对应的解析模板进行解析，文件解析模块解析的文件类型包括且不限于excel、txt和cvc，文件解析模块将不同渠道的账单数据、订单数据解析后统一转化并存入通用的账单数据表中，账单数据表对不同的数据端进行定义并赋予相应的字段并填入表中，账单数据表采用glusterfs文件存储，账单数据表存储在postgresql数据库上；
37.对账处理模块，用于对账的业务逻辑处理，对账处理模块在获取账单数据表后对账单数据和支付订单数据进行比对，对账处理模块将账单数据、支付订单数据分别清洗到账单待对账中间表和订单待对账中间表中，然后将两张中间表进行sql full join操作得到一个集合全量，集合包括一个交集、两个补集，处于交集部分的数据集进行订单金额的比对一致则说明无差错，对平的数据集按照结算数据要求取账单数据结合平台订单数据业务字段全集，直接生成对账明细表，不一致的则需要生成差错数据并记入对账差错数据表移入差错池；
38.差错处理模块，处理差错池中的订单，差错信息表根据差错类型记录该笔差错的详细信息，包括不限于渠道类型、金额、交易时间，并会对差错进行分类，定义特定的差错类型编码，根据不同情况将差错分为：长款、短款、金额错误，对于长款差错的处理包括人工合账、平账，或自动处理。
39.本发明的一种基于分布式数据节点的对账系统基于多信任节点技术，多信任节点技术是一种不可篡改的分布式账本技术，多信任节点技术最大的特征是“分布式账本”，即链上的各个参与机构共同拥有一个账本。多信任节点上所有的交易信息都会被记录，并且无法篡改，可确保数据的真实透明可追溯，非常适用于金融行业的交易数据同步和对账等场景。
40.其设计原则体现在：
41.不影响现有业务，通过旁路上链的方式，将业务数据脱敏后发送到多信任节点上；开发一个web系统，方便合作行查询多信任节点上的对账结果；业务数据传输、存储均采用加密方式，确保数据安全性；具体而言，基于多信任节点技术实现的对账平台具有以下优势：使用简单，通过内网访问web系统，输入管理员账号密码即可登录；数据实时触达，实时监测备付金账户当日账户余额、当日放款总金额、当日还款总金额、当日其它划入款项总金额、当日其它划出款项总金额和当日流水数据；数据安全性高，数据的通信和存储都经过加密处理；数据可用性高，多信任节点之间相互同步数据，提升数据的可用性；合作行可控性强，合作行可以自由选择自己的节点数为1到多个，节点可以选择部署在合作行内或公有云
上，不同合作行之间的数据是物理隔离，保护隐私。
42.优点在于：
43.节点互通：根据业务功能、隐私保护、数据隔离、或者性能容量扩展的需求，建立多个独立的链并行工作，链和链之间可以通过跨链服务进行交互，如发送交易，查询交易结果，读取配置数据等。跨链交互目前是多信任节点领域的研究重点，在安全、防欺诈、数据一致性、效率等方面还需要进行深入探索。包括：实现并行和跨链共识，提高共识效率；用组合签名替代交易执行进行区块验证，减少交易执行次数；跨链通信和数据校验、实现跨链安全交易，进行跨链对账。
44.分布式存储：现有多信任节点实现中，每个节点存储全量多信任节点数据，数据冗余度较高，且数据容量受单机存储硬件影响，在海量服务中，如需存储较长时间段的数据，其数据量一般不是单服务器能容纳的。多信任节点数据一般采用文件型本地数据库，在本节点的物理硬盘上基于文件系统保存，不提供跨网络的存储结构。而在对数据安全要求较高的机构里，数据一般存储在和外网隔离的安全区域里，以保障数据的安全。同时，这些机构已经建立了成熟的数据存储和维护方案，在基础架构层面保障数据存储服务的高可用、可扩容、可迁移、可维护，并和大数据平台等系统进行整合。采用分布式数据存储的方案，可综合考虑数据的容量、可维护性、安全性，支持使用现有的企业级分布式存储解决方案，如数据仓库、数据库集群等存储多信任节点数据。
45.隐私保护：多信任节点技术虽然有一定匿名性，但收发地址和金额都是可追溯的，对于某些行业应用如金融类应用，显然缺乏隐私性。因此，对账平台考虑对以下数据进行周密的加密处理。交易身份匿名，交易中对交易双(多)方地址进行完全匿名，满足一次一密、不可伪造、无关联性和可跟踪性。交易数据加密，加密传输和存储交易数据。账户状态加密，加密传输和存储账户状态数据。对于以上加密数据，满足利益相关方(交易对手方、监管方)有权利看到明文数据，其他参与者没有权利看到明文数据，但其必须可以对密文数据的真实性进行验证，平台计划实现多层次的隐私保护。身份匿名，使用群签名进行身份匿名，同时监管方可对用户身份进行跟踪。数据隐私保护，已经在客户端和智能合约上实现加法同态加密算法，计划增加零知识证明用于证明加密数据的正确性(如账户余额数据是否足够用于支付)。细粒度的权限控制，基于属性加密算法和代理授权密码算法的多级访问控制，用于控制对加密数据的隐私访问。
46.如图2所示，本发明的一种基于分布式数据节点的对账系统的对账流程主要包括：
47.s1：支付系统将交易流水和资金流水上传到分布式节点中进行对账；
48.s2：合作方可以查询对账结果，如果有查询可以从分布式节点中获取原数据；
49.s3：分布式节点的创建可以通过分布式数据库来实现，分布式节点系统采用开源系统：glusterfs作为存储系统，交易各方可以通过https将交易流水、资金流水上传；
50.s4：从上游渠道(银行、银联等金融机构)获取对账文件，程序逐行解析入库；
51.s5：在程序处理中，以上游对账文件的表为基准，程序逐行读取并与我们系统的交易记录对比账务记录(有账务系统情况下，合理方案应该是于账务记录)对比，查找出差异记录；
52.s6：以对账系统的交易记录对比账务记录为基准，程序逐行读取与上游对账文件对比，查找出差异记录。
53.具体地，各个渠道的账单接口下载形式，账单数据格式等会存在不同的差异，而如果完全按照第三方的原始账单格式存储，对于后续的账单数据处理逻辑会比较复杂，并且每增加一个新的支付渠道，账单存储表都需要根据渠道账单结构新建，增加开发工作量，存在不合理情况。为了实现账单数据的统一格式化，需要将各渠道原始的账单文件进行统一标准化转化，同时也需要设计一张相对通用的渠道账单数据表来存储不同渠道账单格式化后的数据，具体结构如下：
54.55.[0056][0057]
另外，在进行账单数据存储时为了提高效率，需要将标准账单文件格式设计得与表结构一致，这样在完成数据转换后可以直接将文件load/copy到数据库中，这样速度会快很多；而考虑数据规模会增长得超级大，这张表也可以存储在hive上，只是对于大部分公司的交易量来说，这么做会有一些技术实现上的成本，采用的是postgresql数据库(版本为9.5.4)作为账单存储库。
[0058]
此外，对于账单的下载逻辑也需要考虑防重逻辑的，即同一个渠道账号的同一天的账单数据不能重复下载和入库，所以除了存储具体的账单数据外，也需要设计一张账单下载记录表，用于存储那个渠道账号哪一天的下载情况，并在账单下载任务启动起根据该表进行防重复下载逻辑判断。这里还需要说明下，在下载原始账单和转化标准账单时由于账单文件读写都是本地磁盘，为了统一集中管理这些账单文件、也为了数据安全需要采用统一文件存储服务，采用glusterfs文件存储，或者自己搭建一个文件夹共享服务。
[0059]
账单下载记录中也需要存储原始账单文件及标准账单文件的下载位置，平时基本上不会用到，只是为方便日后用于数据问题排查，需要检索原始文件时，方便查找及数据重新加载。
[0060]
本发明的一种基于分布式数据节点的对账系统的核心对账逻辑是在完成相应渠道的账单下载任务后，系统可以根据各个渠道的特点及对账平台任务系统的排班逻辑，启动相应渠道的对账任务了，例如微信账单在10点左右开始下载，预计完成时间为10分钟以内，那么就可以将第三方的对账任务安排在11点开始执行，以此类推，各个渠道根据自身实际情况确定对账时点。
[0061]
一般情况下，与第三方支付渠道进行对账时，会以平台订单号作为关联条件，将账单表中的数据与支付平台订单表的数据进行full join得到一个集合全量，得到的集合会是一个交集、两个补集。处于交集部分的数据集说明根据订单号是可以对应上的，但是我们还需要进行订单金额的比对，如果一致则说明无差错，对平的数据集按照结算数据要求取账单数据+平台订单数据业务字段全集，直接生成对账明细表，而不一致的则需要生成差错类型为“金额不一致”的差错数据，并记入对账差错数据表。
[0062]
处于账单数据这一侧的补集属于长款差错，即这部分数据在第三方账单中存在，而在支付平台订单成功数据集中未找到，导致这部分差错数据的原因，可能有跨天交易的情况、也可能是线上测试数据导致、或者属于系统层面的订单掉单，在后面差错处理中会详解介绍。
[0063]
而处于支付平台订单这一侧的补集则属于短款差错，即这部分数据在支付平台成功订单中存在，而在渠道对账时点的账单中不存在，造成这部分差错的原因有可能是跨天
交易情况导致，也有可能是第三方结算错误，具体原因需要在设计差错处理逻辑是根据不同情况进行处理。
[0064]
将账单数据表与支付平台订单表进行full join，但是由于账单表我们是存储在postgresql上的，而支付系统所采用的数据库可能是mysql或oracle，总之，从系统拆分的角度看，一般是不会将对账处理与在线支付订单放在一个库中的，即便在一个库直接关联账单表与支付订单表也是不明智的，一方面这样可能会影响实时支付系统的稳定性，另外这些表的数据都是不断增长的，随着数据的积累会也会导致对账数据查询变慢。
[0065]
所以，在进行某个渠道对账时需要根据条件将账单数据、支付平台订单数据分别清洗到两张中间表中，分别叫做账单待对账中间表(a表)、订单待对账中间表(b表)，然后通过这两张表进行full join操作，这样可以确保对账逻辑不影响别的业务，同时这部分数据可以在日终完成对账任务后定期清理掉，确保中间表数据规模处于可控状态。
[0066]
在代码层面通过a表full join b表后，会得到一个结果集，如果这个结果集数据比较大，系统没有采用spark+hive这种方式话，通过传统编程方式则需要对查询进行分页，考虑到数据逐条对账处理速度较慢，可以一页获取数据条数稍多一些，例如一次取5w条，然后在系统内部采用多线程方式对数据集分割后并行处理，每个线程按照特定的对账逻辑执行，得到对账明细结果集或差错结果集后，批量存入对账数据库。
[0067]
考虑完成对账、以及后面会涉及的处理差错，其结果都是产生对账明细数据，而对账明细数据是渠道vs平台后最为准确的资金数据，对于后续的商户清分、资金清算、结算都具有重大意义，所以复杂查询的频率会比较高，并且数据的使用时间范围也比较大，对于交易量比较大的公司一年的支付数据量可能达到数十亿规模，在数据存储方面，可以考虑采用tidb这类分布式关系型数据库来存储对账结果相关的数据，这样后续的数据处理逻辑效率会提高很多。可能有人会问为什么不直接使用hive进行查询，这是因为hive的单条查询和批量查询的效率是一样的，所以并不太适合实时查询，而如果需要将对账、结算等数据通过管理系统进行管理，涉及的查询场景比较多，所以综合考虑使用分布式关系型数据库会更合适一些。
[0068]
本发明的一种基于分布式数据节点的对账系统对账逻辑执行完成后，会产生一部分对账逻辑执行过程中，系统无法匹配的对账差错数据，这部分数据会在对账完成后记录在对账差错信息表中，差错信息表根据差错类型记录该笔差错的详细信息，除包括渠道类型、金额、交易时间等关键信息外，还会对差错进行分类、定义特定的差错类型编码。
[0069]
根据不同情况差错大概可以分为三类：长款、短款、金额错误。其中长款根据对账处理方式的不同可以分为“渠道成功，平台订单不存在”、“渠道成功、平台状态非成功”两种情况，从生产实践上看，因为支付系统中会存在比较多的支付失败订单，而国内支付渠道的账单多数情况下只会提供用户支付成功的账单数据，所以在实际进行对账时，在a中间表、b中间表清洗的都是双方认为成功的订单数据，在这种情况下产生的长款类型也就只有“渠道成功，平台订单不存在”这种类型了。
[0070]
而对于短款来说，就是在当日的账单数据中没有匹配到，差错类型也就是“平台成功，账单数据不存在”。而“金额不一致”的情况相对少见，主要出现在如微信、支付宝进行营销活动时，造成的支付平台订单金额与第三方不一致的情况；另外，存在订单部分退款时，如果支付系统订单模型没有很好地满足这类情况的话，也会导致对账金额不一致的情况发
生。
[0071]
针对不同的差错类型情况，需要根据系统实际情况，设计相应地处理流程。例如，对于长款差错需要识别其产生的原因，如果是因为交易跨天导致的，例如交易在平台时间为某日的23:59:59秒，那么发送到第三方渠道的时间可能已经是第二天的00:00:01秒这样，那么在第一天对账是会产生一笔短款差错，此时只需要消除这笔差错、同时生成对应的对账明细即可。而如果是因为支付平台状态未处理成功，则是系统掉单问题导致，除了正常消除这笔差错、产生对应的对账明细数据外，还需要通知支付系统进行状态更新操作，其涉及的业务逻辑，还需要根据整个支付平台的流程设计，触发商户回调、或者还需要通知账务系统进行补记账操作。
[0072]
需要根据具体的差错类型及原因，结合整个支付系统的流程来保证系统间数据的一致性，以下是长款差错通用处理流程：
[0073]
如图3所示，首先确定是长款错误，确定后查询支付订单表，确定该订单是否存在，如订单不存在则确认该订单为线上测试订单，调用支付系统补单接口发起交易补记账操作；如果订单存在则进一步判断支付订单状态是否为成功；如支付订单状态为非成功状态，以支付账单问题通知支付系统进行订单补偿，支付系统进行逻辑处理，发起交易补记账操作并发送商户订单支付结果通知；如支付订单状态为成功状态，查询对账明细是否存在，存在则消除长款差错，更新明细结算时间为账单下发时间，不存在则判断是否存在对应短款差错记录，存在则交易跨天消除长款和短款记录，不存在则交易跨天消除长款差错记录。
[0074]
在以上长款处理流程中，关于跨天交易情况的区分：在判断完支付订单状态为成功后，之所以在判断是否在t-1天或者t-n天是否存在同一笔匹配的短款差错之前，判断是否存在对账明细的情况，是因为在系统设计时考虑订单结算的实时性，允许对于短款差错采取t+1日的处理方式。
[0075]
如图4所示，短款差错通用处理流程：
[0076]
首先确定是短款错误，检查对账明细是否存在，判断是否重复对账，如果存在重复对账则在t+1、t+n的长款处理中被处理以消除短款差错；如果不存在对账明细则判断是否存在于历史账单数据中，存在则根据账单数据生成对账明细并消除短款差错；如果不存在于历史账单数据中，则通过渠道支付订单查询接口查询状态是否成功，不成功则人工核实、人工对冲；如果状态为成功则根据差错信息和查询结果生成对账明细消除差错数据，设置对账明细渠道结算时间为正常交易时间+1。
[0077]
本发明的一种基于分布式数据节点的对账系统利用分布式多信任节点技术将备付金交易信息分支节点，确保数据的真实透明可追溯，解决支付系统与合作方的对账问题，降低了合作方的人力和时间成本，提升了对账的时效性与准确度，非常适用于金融行业的交易数据同步和对账等场景，解决传统“批量文件对账”模式长久以来未能解决的问题。
[0078]
上述具体实施方式仅仅对本发明的优选实施方式进行描述，而并非对本发明的保护范围进行限定。在不脱离本发明设计构思和精神范畴的前提下，本领域的普通技术人员根据本发明所提供的文字描述、附图对本发明的技术方案所作出的各种变形、替代和改进，均应属于本发明的保护范畴。本发明的保护范围由权利要求确定。