百度交易中台之内容分润结算系统架构浅析( 二 ) _系统架构

系统整体支持三种账号体系，面向作者提供两类百度常用账号登录方式，面向管理端提供内网账号登录方式，基于此账户体系做了灵活权限控制，不同用户登录管理端，看到的可操作菜单栏各不相同，避免出现越权操作。同时基于此账号体系，能灵活获取上下级，构建了自动化的审批流程。
结算系统的平稳、合规、高效运行离不开各类协同生态的合力支持。反作弊能力贯穿整个内容分润的始终，着力于打击黑产，识别作弊用户。OCR、发票平台为发票识别，发票鉴定提供了通用服务。财务的各类审核，业务的多维度监管则进一步为资金结算的合规安全保驾护航。各类角色、各个系统协同合作，促成了目前内容分润结算系统。
03 技术难点和细节
上文以整体的视角介绍了内容分润结算系统的架构设计，下面我们将枚举几种业务场景构建过程中的技术选型，来详细介绍该系统的技术落地。
3.1 千万级数据日度任务的技术选型
场景：每日上游会给我们产出明细数据，数据为细粒度，量级为大几千万级别，格式为AFS文件（离线文件），需要基于某些过滤规则和计算规则做二次汇聚，后续支持多维度查询，作者端展示报表。
3.1.1 DB批处理方案
最初任务是在物理机上通过sql批处理，任务串行执行，简单明了，同时成功同时失败。但随着数据量持续递增，串行执行可能面临着实效性问题。基于原始的DB思路，我们构建了基于DDBS（关系型分布式数据库系统）的解决方案，全部依赖于DB ，因汇聚是基于用户维度，所以基于子账号uid计算shardingKey分表，过滤规则也落入库中，后续使用表之间连接过滤，相同分表中的同子用户数据汇聚。使用在线服务，按照分表规则，启动多线程执行任务，实时写入日汇总数据表。具体方案如图2 。

文章插图
△图2.基于DDBS的解决方案
3.1.2 离线计算
利用SPARK天然的分布式计算能力，采用离线计算方案，汇聚时使用SPARK计算。基于上游提供的离线文件，构建RDD1文件，后续基于一些过滤规则过滤数据和然后基于集合规则，使用reduceBykey聚合，产出新的RDD2文件。这个RDD2文件就是我们后续使用的日表数据。因有各类在线查询需求，需持久化到数据库中，又因产出的日表需支持各角色多维度查询，调研后采用PALO数据仓库，具体方案如图3所示。

文章插图
△图3.基于SPARK+PALO+DB解决方案
对比两种方案后，我们最终选择方案二实施。方案二的优点比较突出：1.SPARK集群自带分布式计算能力，无需我们按照方案一方式自行实现分布式计算；2.数据存储于PALO，相比于传统的MySQL，在大批量数据和多维度报表场景，PALO性能优势更加明显。3.方案一有一个最大也是我们最踩坑的性能问题，实时大批量写入DDBS数据库导致较高的主从延迟，影响了其他业务场景。
3.2 百万级数据的月度任务
场景：基于上述场景会产出月表，数据量大约在百万级别，遵循月度出账计算模型，产出最终的预提数据。日度任务和月度任务的最主要区别在于日度任务计算过程密集，月度任务过滤过程密集。
月度产出计提任务实际就是计算用户本月收入以及本月可结算的收入，可结算收入=以前累积未结算金额+本月收入。目前该任务输入的数据量相对较少，且以过滤为核心，因此此类任务未采用SPARK计算。而各类过滤规则与当前用户各种属性息息相关，因此任务围绕用户uid展开，采用以用户uid为底表，先通过各类策略过滤uid,后置再计算的方案。数据量虽然相对日度任务较少，但毕竟在百万级别，如果使用单一线程处理所有用户，速度会极其缓慢，所以必须拆分任务，使用并行计算的方式提升效率，而如何拆分任务，如何保障任务全部执行是月度任务模型需要考虑的核心问题。
3.2.1 幂等的分布式数据批处理框架master节点
我们设计了主从任务模型，用于支持上述任务拆分执行，主结点先置启动，用于数据备份、初始化出账任务，以及调度从节点。从结点则等待主结点启动子任务指令，启动后获取子任务执行。具体模型如下图4，5所示。