共计 5092 个字符，预计需要花费 13 分钟才能阅读完成。
作者 | 交易中台团队
导读
随着公司内容生态的蓬勃发展，内容产出方和流量提供方最关注的“收益结算”的工作，也就成为重中之重。本文基于内容分润结算业务为入口，介绍了实现过程中的重难点，比方千万级和百万级数据量下的技术选型和最终实现，满足了业务需要的同时，最终实现了高效，精确的资金结算，文章旨在抛砖引玉，心愿能给读者带来思考和帮忙。
全文 5185 字，预计浏览工夫 13 分钟。
01 业务介绍
什么是内容分润平台呢？简略来说，百家号等平台负责内容的生产和引入，手百等渠道方负责内容的散发，凤巢等广告平台负责在此流量上进行变现。而分润平台，则是根据上述各方提供的数据，通过外围策略模型，赋予作者、媒体、小程序主和用户，正当的、差异化的、有竞争力的分润收益，以吸引更加优质的内容和流量的入驻和单干。通过这种多方相互协作模式，实现互惠共赢的目标。
1.1 三大性能点
针对上述的业务特点，结算零碎须要蕴含三大性能，用于撑持内容分润业务的准确性、合规性、及时性。
性能一：结算模型
这是咱们最要害的性能，它负责将杰出的文章转化为作者的分润收益。该模型的输出数据包含数据中台生成的用户维度的日分润明细和日补贴明细，而输入则是每月的结算账单，这些账单会被发送到对立业务平台用于付款。在这个过程中，咱们经验了一系列步骤，包含每日的计算、每月的总结、预提、计提和账单生成等，所有这些步骤都是依照不同的维度逐层计算和聚合的，最终实现了账单的付款。
性能二：C 端内容交易平台
这个性能次要面向用户，旨在帮忙作者及时查看他们的收益，并进一步激励他们的创作能源。作者只需登录平台，即可查看每日的预估收益、文章的散发状况、浏览量等数据，还能够查看每月理论的付款账单，提供发票等相干数据。
性能三：O 端治理端平台
为了确保资金结算更加合规和精确，整个结算体系引入了经营治理和反作弊等不同角色。这些角色在治理端负责资金管控、发票审核、黑名单治理等各种操作，以确保整个过程的合规性。
1.2 名词解释
PALO：百度数据仓库，是基于开源 ApacheDoris 构建的企业级 MPP 云数据仓库，可无效地反对在线实时数据分析。
BNS（Baidu Naming Service）：是指百度名字服务。BNS 提供服务名称或服务组名称到服务所有运行实例的映射，你能够依据一个名字（服务名或服务组）获取服务的信息，包含实例的主机名和 IP、实例的运行状态、端口、负载、实例自定义配置标签以及其余实例自定义信息。用于满足服务交互中常见的资源定位、IP 白名单保护、查问服务下的机器列表、负载平衡以及其余任何依赖于这些信息的开发、测试和运维需要。目前 BNS 曾经在全百度各业务线中宽泛应用，UB、RAL 等框架的反对和各语言 SDK 也曾经公布。
02 业务架构
2.1 架构分层介绍
图 1 是整个内容分润的业务架构。内容分润结算面向数据中台，业务方，用户（作者）和经营治理提供服务。
△图 1. 内容分润结算平台零碎架构
2.2 要害汇总文件
对于数据中台，咱们是间接上游，同时在整个内容分润流程的流程中，咱们表演的是最末端的角色。百家号、问一问、百度文库等业务会将作者的内容散发数据、广告奉献等给到数据中台，数据中台依照各种分润计算模型归一化数据结构，产出三份较为具体的明细文件，包含日分润明细，日内容散发明细，日补贴明细。
日分润明细：作者内容散发或流量奉献所取得的分润详情，明细中包含分润金额，文章散发渠道，父子账号等字段。
日补贴明细：基于运管治理的二次资金分配详情。
日内容散发明细：作者的内容散发奉献报表。
数据中台会将这些数据以离线文件的模式提供给咱们，结算零碎每日基于配置规定，进行离线计算，最终将数据进行降维汇总。后续每月月初，基于这些汇总数据，做二次汇聚产出用户收益账单。
2.3 服务提供形式
结算零碎依据内部需要，提供多种接入形式。面对业务方，结算零碎提供 API、网页嵌入模式接入形式。若业务有其自建平台，可将结算零碎提供的网页嵌入其平台外部，用于展现用户的支出信息或上传发票等。若无自建平台，也可 API 模式接入。新用户在业务侧申请入驻作者后，业务调用结算零碎 API 实现用户注册，开明计费单元，保护财务信息等。后续作者在内容分润平台查看其支出，文章散发报表，从新保护财务信息等。若有重要变更或告诉，零碎通过站内信形式告诉作者。
零碎整体反对三种账号体系，面向作者提供两类百度罕用账号登录形式，面向治理端提供内网账号登录形式，基于此账户体系做了灵便权限管制，不同用户登录治理端，看到的可操作菜单栏各不相同，避免出现越权操作。同时基于此账号体系，能灵便获取上下级，构建了自动化的审批流程。
结算零碎的安稳、合规、高效运行离不开各类协同生态的合力反对。反作弊能力贯通整个内容分润的始终，着力于打击黑产，辨认舞弊用户。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 所示。
△图 4. 主节点生命周期
图 5 形容了主节点的生命周期，主节点收到出账指令后，优先做的是账户余额类表的数据备份，这个动作归因于咱们月度工作的特殊性，月度工作产出的数据表在其余工夫不会更新，即上个月出账完结后，账户余额类的相干表会在下一次出账结束才更新。
备份表的环节十分重要：
1. 是能够在月度工作完结后做数据总额验证工作；
2. 是能够用于兜底，一旦月度工作产出数据异样，也可回退到备份数据，重新启动工作。
主节点工作的第二步则是确认出账工作的用户 uid 范畴，咱们零碎为了既反对 C 端用户体系，也反对商家账号体系，从新设计了一套外部用户 id，不论是用户账号还是商家账号的 id 均会惟一映射成一个外部 uid，后文提到的该工作的 uid 均为外部 uid。外部 uid 为自增 id，因而查询数据库，即可获取到最大 uid 和最小 uid，也就确定了咱们本次工作的 uid 范畴。在 redis 中设置两个 key 代表 uid 的最值。至此，出账工作的前置筹备工作就实现了。主节点获取执行子工作配置的 BNS，基于 BNS 解析出所有实例，发送子出账工作指令，子实例获取到指令后，启动 N 个线程执行工作，即假如有 M 个子实例，那最终就是 M * N 个线程同时执行工作。从主节点的工作可看出，该工作无其特殊性，即主节点理论和从结点是平等关系，任何实例都可成为主，也可成为从，这就为调度工作进一步提高了灵活性。
3.2.2 woker 节点的工作流程
△图 5. 从节点生命周期
图 5 以上述实例中的一个线程作为示例，详细描述了线程启动后，执行的子工作的过程。首先获取目前的最大 uid 和最小 uid，最大 uid 为主节点固定值，最小 uid 则是一个游标。若最小 uid 曾经大于最大 uid，则代表所有 uid 曾经处理完毕，线程完结。若不满足上述条件，则继续执行工作，利用 redis 的 incryBy 指令，将最小 uid 向前挪动 N 个数值，这 N 个 uid 就是本次子工作的执行范畴。拿到 uid 后，先将 uid 变为 N 条工作批量落入 Job 表, 并设置初始化状态。落库失败，引入报警机制。落库胜利后，依照出账模型，启动过滤规定。所有被过滤的用户 uid 均批量写入 job 表，设置工作完结状态，并且标记过滤起因，便于后续经营查问。过滤规定执行结束，残余 uid 十不存一，此时咱们利用 sql 计算本月用户结算金额。计算结束，写入 jobDB 的长期产出表，设置 job 工作完结态，此时一轮子工作就执行结束。线程持续反复执行上述过程，直至所有线程均完结，代表出账工作执行结束。
3.2.3 出账确认工作
所有工作执行结束后，主节点会收到出账工作确认指令。
△图 6. 出账确认工作
该工作的次要目标就是确认所有 uid 均执行结束，无疏漏，具体如图 6 所示。上文提到，子工作执行时，都是先置落库 job 表的，确认工作的第一步：扫描 job 表，看是否有非完结态的工作，若有，则启动子工作，从新执行这批数据。确认工作第二步：获取 job 表中所有执行的 uid 数量和须要执行工作的 uid 数量，确认数量是否统一，若不统一，从新执行出账工作，工作基于 uid 和业务期间重入，曾经被执行的工作会被跳过。屡次兜底策略执行结束后，数据总量校验统一后，会将长期月度产出数据写入正式 DB，清理长期数据。之所以设置长期表：1. 是为了数据校验工作，若数据校验异样，可疾速清理该表，重新启动工作；2. 若间接写入正式线上库，大量数据的并发写入会导致数据库的主从提早，会影响其余线上实时业务场景。后置写入实现了另类的『读写拆散』，工作过程中仅读正式表，工作结束长期表往正式表写入数据。
04 总结
本文次要介绍了在构建结算零碎过程中的几个技术重点和难点，而要保护整套零碎的安稳运行，不仅有这些技术重点，也有看似微不足道但却环环相扣的细枝末节，保障每个环节不掉链子是运维工作的重要一环，后续咱们将着力于晋升运维效率，节俭人力老本，向着运维自动化、智能化革新。另外目前的技术计划取决于咱们的数据量级，将来业务蓬勃发展，业务架构也会继续迭代，期待咱们向着更加齐备的架构后退。
——END——
举荐浏览
小程序编译器性能优化之路
百度 APP iOS 端包体积 50M 优化实际 (六) 无用办法清理
基于异样上线场景的实时拦挡与问题散发策略
极致优化 SSD 并行读调度
AI 文本创作在百度 App 发文的实际