腾讯内容..系统的架构实践

作者 | 孙子荀（授权）编辑 | 小智随着云结合微服务架构切实的提高了生产效率；深度学习不断深入内容处理的各个领域促进生产力的发展。 在消息系统，数据仓库，计算框架，存储系统等基础架构层建设逐步提升的基础上，大型互联网公司进一步提出了业务基础设施的需求。在基础架构和上层业务之间急需一个中台系统来承载。中台系统把业务层同性的算法能力，服务能力，业务能力高度集成，有效组织 ，动态规划。更好的帮助上层业务。工程篇前身

在 15 年的时候，内容..（承载腾讯包括手 Q 等内容业务等的内容中台）最初来源于 QQ 公众号系统（公众号系统承载了包括 QQ 服务号，订阅号的关注关系，..等大型活动的推送，订阅号消息下发，素材内容管理等）。当时公众号系统有几个子系统：资料子系统，消息子系统，关系链子系统 和 素材子系统。一个号主如果需要把自己的内容给粉丝，需要经过这 4 个子系统。 [原创文章：www.11jj.com]

[原创文章：www.11jj.com]

（蓝色部分）

（子系统就是有独立的存储 逻辑 数据流 接口体系。概念来自 Systems Analysis & Design 的 DFD sub-system）

在最简单的粉丝发送的场景，首先使用素材系统管理群发任务的内容，然后用关系链子系统拉取粉丝数据，通过消息子系统创建群发任务进行消息发送，过程中需要和资料子系统交互获得各自参数。

在 15 年下半年，内容战略升级，除了来自..的号主发送内容，我们还有大量来自其他外部合作..。他们通过公司其他..对接进来，当时我们复用这套基于消息发送的场景，让对方创建群发任务，内容进入素材库进行处理，然后就可以触达粉丝了。

但是后来整个业务形态从订阅变成了 Feeds 流，原来的粉丝关系变成了推荐，随着内容处理服务的越来越多，内容量的不断增加，老的这套系统就无法承载了。于是我们需要改造老的系统。

我们希望是有一套统一的多源内容库，在良好的扩展性框架下，各类型服务通过实现预定义接口，完成对内容的加工处理，人机结合，输出给订阅方。

内容的处理服务包括了内容安全质量（质量评价，暴力..，低俗，标题党，错别字等），内容建模特征（分类，主题，标签等），内容理解生成（封面图，摘要，结构化，剪辑等）。

（内容..顶层图）

文本介绍一下其中主要的架构部分工作。

原来存号主发送内容的素材系统就变成了内容..的最早雏形，素材还是通过 MySql 来存储用户发送的内容，所有的文本和 html 生成的页面样式也存储在一张表中，单表不堪重负，进行了 partition Sql 执行优化等工作，但是无济于事。在进入内容时代我们需要有一个性能更高的存储系统来支持。 当时的技术选项的考虑基于过去素材系统的痛点和未来需要支持的规模。

当时考虑过 Mongodb 和 Hbase ，Cassandra 以及其他 KV 存储。

Mongodb 的好处很多 。但是他的高效率访问带来的是内存资源的极大开销。冷热不均的分配，不可控的并发写入和副本存储都使得他无法承载未来几年更大的发展。

其他的就是 Hbase ，当初能预料到的是如果我们需要把 Hbase 当作 KV 对在线服务，是无法承受的，但是我们可以在其之上增加一个 KV 的 cache 解决这个问题，剩下的事情就是我们去打造一个中间层支持 Hbase 和内存 KV 的数据同步。

Hbase 的 row key + column family + column qualifier + timestamp + value 是 HFile 中数据排列依据。HFile 据此，对数据的索引到 data block 级别，而不是行级别。

另外当初还考虑过一个方案就是基于 LevelDB 的全新内容中间件方案，这样能做到内存 KV 和永久存储合二为一，可是在那个时候的环境下，我们就算之前做过初级版本，也无法快速开发来，但是 Hbase 的好处是他可以支撑一段时间的 KV 访问，未来扛不住再优化上增加 Cache，事实上后来我们也是这样走的。

关于存储这里的工作我们后面还会提到，我们怎么进化到存储中间件 RCS。存储有了接下来就是如何设计存储层的数据模型。

在设计存储模型的时候，在 16 年的时候 ，确认的事情有几个：

我们的目标：

在架构上，打造统一存储来托管所有模块需要读写存储的场景，这样每个模块的同学统一存储。无论是业务同学的业务逻辑字段。还是算法同学的模型业务输出 or 模型特征输出。开发人员需要更加关注于策略本身，存储上的事情统一收拢提供 API 就行。

在表结构上：

如果第 1 点做到了，那么我们未来可以基于这个宽表进行天然的单表检索，单表基础内容特征挖掘。甚至是算法实验字段都可以统一在一张宽表里。

于是我们做了几个重要的设计：

1、推广新的唯一 ID 体系，废除公众号的自增 articleID，ID 能支持以下特征：

ID 体系 = 预留字段 + 时间 + 自增 ID + 内容类型 + 业务来源

于是有了 rowkey，拿到任意一个 rowkey 我们至少能第一眼知道来源大概的时间和类型，便于路由。

2、规范列名，所有列名分为【状态类】和【内容特征类】，前者用于标记状态，处理情况。后者用于保存内容的基础元信息，模块处理过程中产生的结果信息，中间信息。当时列的结构约定的格式是：

列名 = 列属性（状态类 or 业务类 or 模型类） + 字段属主 + 字段描述

状态类

模型类

当时所不能预估的事情，现在思考有几点：

我们在这里的数据模型使用了宽表格式，相比复杂的 EVA 存储，我们觉得宽表更加利于数据汇总统计。后续 RCS 部分会再次介绍。

宽表事务性更好。HBase 对一行的写入（Put）是有事务原子性的，一行的所有列要么全部写入成功，要么全部没有写入。但是多行的更新之间没有事务性保证。

线上当前真实的情况是，单文章表已经有超过 500 多稀疏 column ，并且随和业务场景增加不断增加。测试数据验证并不会随着 column 增加而影响查找开销。

相关对比可阅读：

https://stackoverflow.com/questions/16447903/table-design-wide-table-vs-columns-as-properties

主要介绍服务的设计区分，这里的服务包括业务能力服务，比如转码，业务逻辑处理，也包括模型算法相的服务。还有数据流的架构方法。

我们把任何一个服务分层Ｌ０－Ｌ２三层，０层就是原子化的，不适合业务场景的无状态基础能力，如果在 NLP 的应用上，类似下图：

类似 kernel 支持 IO_DIRECT ，VFS 提供直接访问操作块设备层。我们的模型服务也可以支持直接越过业务逻辑访问底层基础能力。

（具体 linux io 相关参考 http://km.oa.com/group/17746/articles/show/208771）

从开发任何一个服务的时候，我们先梳理好层次关系。［对外的协议和接口］这里可以统一代码框架，由纯工程人员提供，包括并行化云化容灾过载保护熔断等。

业务测的算法团队使用其他公共库的 L0 or L1 层的能力，进行 L１－Ｌ２层的业务开发，工程人员也可以一起进行 L2 层的开发。

（服务模块内分层示意图）

我们根据以下几个维度可以来区分一个服务，下面提到的调度中心根据这些维度进行不同的处理策略。

是否需要全局的信息：

指的是针对一个内容的处理，是否需要历史上所有已经处理的内容的输出。比如去重，或者同质化内容控制，一定需要和历史上已经积累的内容处理状态做逻辑。增量 + 全量同步。

是否强业务逻辑

所谓强的业务逻辑 就是说这个服务是否和业务逻辑没有强关联，可以独立于业务场景。如封面图抽取。

不一样的有如：同质化的内容控制，这个和业务策略强相关，不同的业务场景 ，策略有存在特化的可能性，类似文件系统的实现有 ext4 xfs。同样标签抽取服务，也会对不同的垂类有不同的业务策略。

是否可以服务化

一般来说服务本身的业务逻辑越弱，又不依赖于其他业务全局信息的，可以提供对第三方的统一服务，比如图片标签抽取， 标题党。

这类服务可以充分输出服务自身的信息提供给上层业务方进行使用。

是否可以异步处理

是否能异步取决于，服务处理的时间效率，如果处理时间能保证实时返回那异步的需求不大，有的服务在特定业务场景下是严格依赖的，比如封面图，一定是需要处理完成才能继续。有的服务是可以在内容上线之后在执行并且更新，例如同质化控制，可以先曝光再下架。

是否有前置依赖性

如果有前置依赖的服务，一定需要在前置的若干服务处理完成之后才能进行本服务。

比如视频拍重，一定依赖之前的视频抽 frame，音频指纹服务都完成之后，才能继续进行。该服务需要任务图中依赖前置服务父节点都完成之后启动。

我们认为当开发一个服务之前，必须搞清楚这里的几个维度。比如我们现在需要引入 xLab 的标签能力，我们综合看这几个维度，

过去我们有几个思路，服务是否需要深入业务场景，那这里的问题就是，如果和模型能力强相关的业务逻辑，是需要放在服务自身实现的，因为这样可以更加有利于业务逻辑和算法输出相互配合，形成整体，对于开发人员来说，理解业务的需求，是业务部门的算法人员必须关注的，比如标签，去重， 模块内部算法特征使用和业务逻辑高度内聚。

Brendan（也是 Kubernetes 的作者，现在微软，之前在谷歌 Cloud）在 18 年的新书 Designing Distribution System 中提到了我们从 15 年开始尝试的几个路径， 几乎做了类似的模式和事情和经验总结，感慨的是这本书 18 年才出版。 （道路自信 理论自信 文化自信 ☺）

Brendan 称这种多阶段多模块协作的处理方式为 Batch Computational Patterns . 包括 Work Queue Systems ，Event-Driven Batch Processing， Coordinated Batch Processing。

（Event-Driven Batch Processing workflow 示意图）

（内容中心简化版的视频处理 workflow 示意图）

我们的处理框架经历了几个阶段。

批处理模式（2016）：

开始时完全的去中心化的思路。当时背景是时间紧，需要构建的模块多。在 16 年，团队不到十人的情况下，基情满满的开发了接近一百多个模块，出入库，图文的去重，封面图，外部能力对接，一些早期质量模型，视频视频转码，爬虫等，同时还在兼顾老的公众号系统的开发工作。