本文共 3275 字，大约阅读时间需要 10 分钟。

电商财务结算系统重构实践

1.背景

1.1 业务背景 唯品会是全国第三大电商平台，连接全球几万家供应商，7x24为亿万会员提供优质的服务。唯品会的自营电商业务形态决定一方面要为广大的会员提供优质的产品服务，另外一方面又要为供应商提供优质，快捷，准确的仓储物流服务和财务服务。财务结算系统是电商后端业务中的核心功能，由它核算出在每一个结算周期内个供应商应该跟平台结算多少款项, 面对复杂的结算类型和供应商个性化的需求，在业务量/数据量持续增长的情况下，如何持续的为广大供应商提供更快捷的结算服务，一直是我们研究的课题。

1.2 技术背景

由于历史的原因，唯品会前面的财务系统技术架构比较简单， 就整一个All in one的ERP系统，采用的是Oracle E-Bussiness Suite，一套EBS包打天下，包括采购管理，建档，商品管理，应收，应付，付款，税务，总帐等几十个核心模块。近几年随着业务的发展以及带来的数量猛增，原来的ERP的运作模式和系统的性能已远远的不能满足业务的要求，近两年的重构陆续的将采购，建档和商品等售卖相关的功能模块迁移到其它自建系统当中，为EBS系统进行减负。最近一年公司的战略调整， 供应商数量和SKU数量都在迅猛增长，基于EBS的财务系统无论是存储和计算性能将要到达极限, EBS底层是一个 Oracle数据库实例，无论在运行效率和运维效率，都面临较大的风险。于是在2016年底推出FCS2.0项目，将财务系统EBS中的库存，结算，应收，应付等核心模块迁移到自研的财务协同系统(FCS)中。在所有核心模块中运算数据量最大，规则最为复杂的模块就是供应商结算部分，经过研发团队跟架构团队，大数据团队多次沟通，确定了以SPARK为基础构建供应商结算平台(VSP).

2. 设计目标

更高、更快、更强是奥运会选手在赛场上拼博的目标，而更快、更准、更灵活是我们每一个系统设计的所追求目标。更快明确要求在现有数据量下供应商帐单月结运算速度从现有EBS系统运行时间6小时缩短到1小时；更准要求新系统自身的计算准确之外，数据的核对和检查更加容易，提供多个角度的报表和查询进行多方对账；更灵活要求VSP平台具备业务流程可配置和条件可配置，以快速的适应业务变化。

3. 架构设计

3.1 为什么选择SPARK? 在技术选型之前，团队一直在思考讨论所需要技术和架构是怎么样的？业务场景可以总结大数据量移动(抽取)，大数据量预处理(清洗)和大数据量的聚合运算，而且涉及到不同的数据源，如关系型数据库Oracle,MYSQL和osp服务，以及同一个逻辑库下面的多个物理分库。另外，团队成员大都具备丰富的Java，MySQL和Oracle PLSQL开发经验。

针对以上的业务场景和团队技术经验，我们所选择的技术平台必须具备几个特点：

1) 对不同类型的数据源读写速度快 2) 数据访问支持数据库分片 3) 高效的内存计算和内存管理功能 4) 支持任务分片和结果聚合 5) 支持资源管理能力和扩展能力， 6) 支持Java语言和SQL，团队成员学习曲线比较平缓

面对上面的这些问题和需求，我们着重的比较了开源实时大数据计算平台-SPARK和传统的Java解决方案(现在采用公司已开源的分布式任务调度平台SATURN). SPARK和SATURN两者均具备任务的分片管理和扩展能力，且都支持Java+SQL的开发方式。根据业务的特点再找出两个典型的场景进行比较推演，一是跨库查询，二是分库匹配查询。

a) 跨库查询场景 b) 分库匹配查询场景

通过典型场景的比较，得到三个结论:

- SPARK SQL的开发效率比传统的JDBC方式高, 可以方便的创建视图和将视图关联来执行，无需关心JOIN的效率拖跨数据库，这一点符合原PLSQL开发人员习惯； - SPARK自带的分区存储/读取技术在MySQL数据库可承担负载内提升了数据读取速度(具体可参考：。 - SPARK 的机器资源管理是进程级，能够根据服务器上的硬件资源容量启动多个进程，且进程的状态由YARN管理，在稳定性方面和可扩展性方面胜出不少。

3.2 整体架构

在决定采用SPARK并将SPARK定位为一个计算引擎，是整个VSP平台的核心，它具备连接不同数据源的能力如MySql, Oracle, HBASE，Redis以及唯品会自研的服务化框架OSP。除了SPARK自带的SPARK UI对作业(Job)，任务(Task)，阶段(Stage), 存储(Storage)和查询(SPARK SQL)进行监控外，还集成了系统级监控工具Zabbix, 秒级服务监控工具Mercury和日志监控工具Dragonfly, 全方位的了解SPARK集群的运行状态和任务执行状况。

SPARK提供了三种集群运行模式：

一、Standalone模式，简单模式或称独立模式，可以单独部署到一个集群中，无依赖任何其他资源管理系统。不使用其他调度工具时会存在单点故障，使用Zookeeper等可以解决； 二、Spark Mesos模式：官方推荐模式，通用集群管理，有两种调度模式：粗粒度模式（Coarse-grained Mode）与细粒度模式（Fine-grained Mode）； 三、Spark YARN模式：Hadoop YARN资源管理模式； 结合公司的其它大数据集群管理经验和运维意见，采用了SPARK YARN模式，相对于Standalone模式和Mesos模式， YARN有以下几个优势: 1) YARN能够为运行在YARN集群上的不同的框架动态地分配或者集中式配置资源，如SPARK或者MapReduce Job. 用户可以在不改变任何配置的情况下把整个集群给一个MapReduce Job，或者留下一部分资源给一些查询和SPARK应用。 2) 用YARN 调度器进行作业的分类，隔离和优先级排序 3) Standalone模式需要为每一个应用在集群上每一个节点开启一个Executor, 在YARN，在资源允许情况可以选择任意数量的Executor使用。 4) YARN是唯一一个为SPARK提供安全性支持的集群管理器。在YARN里面，SPARK可以依赖Hadoop集群鉴权功能，提供进程间的安全认证。

4. 开发实践

4.1 业务流程抽象 前期我们对业务流程的梳理，将整个结算的流程进分解再结合SPARK的执行特点，将整个结算流程分成以下三大部分。三个阶段的任务集可按照不同时间进行独立运行，同一个任务集中有依赖关系任务则通过一个简单的任务编排系统管理，避免任务不空跑（低碳环保不费电）。

抽取：定时从不同的数据源抽取账单计算所需要的源数据，按照抽取的时间作为一个批次再写到不同的结算系统的分库中，在这个阶段需要连接不同类型的数据源，有MySQL和Hive.

预处理：定时从抽取后的源数据按批次抓取，对结算所需要的关键信息进行补充，如采购订单信息、销售订单信息、结算价格和税率等。 结算：定时从数据源中抓取已被预处理完成的数据，根据结算的规则为每一个供应商的计算结算的款项。

4.2 系统设计抽象

工欲善其事，必先利其器。在系统设计之初团队按以往的开发经验，根据面对对象的设计模式对任务和作业进行抽象化设计，形成一套基于SPARK之上的应用开发框架。该框架主要实现以下目标： 1. 通过框架形成一个标准的团队SPARK应用开发实践，降低后来的开发人员的入门门槛，让开发人员像开发Java项目一样方便快捷, 迅速入门。 2. 将作业的启停，配置，用户自定义函数的声明和任务并发控制都由框架基础类负责, 由框架来负责管理资源的调配，参数的优化，避免开发人员误设置。 3. 通过框架封装底层资源的访问请求，高效访问所需资源，提升代码的重用度。

下图为作业的类：

5. 相关文章

6. 关于我们

一支有文化，有思想，有原则团队，无论战斗力还是颜值爆表的队伍。 作者：王云 - 中年微胖不称职码农

转载地址：https://blog.csdn.net/vipshop_fin_dev/article/details/79761081 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！