微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

本文由腾讯技术工程师remyliu分享，原题“微信万亿数据仓库架构设计与实现”，本文收录时有内容修订和重新排版。

1、引言

没有足够的特征数据，安全策略将是“无根之木，无源之水”。

微信的安全数据特征仓库应运而生，并成为整个安全业务的特征数据存储中心，每天服务了万亿级的特征数据读写请求，为整个微信安全策略提供了可靠的数据支撑，是微信安全基石之所在。

然而，微信安全特征数据仓库不仅仅是一个存储中心，更是一个特征管理和数据质量管理的中心。

微信的安全数据特征仓库在演进过程中，一直致力于提升特征管理能力和数据质量保障，实现了特征的管理、共享、分析和数据质量检测等功能。

本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践，以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4374-1-1.html）

2、安全策略开发流程

安全业务的核心逻辑是在安全策略中实现的。整个的策略开发流程包括特征数据的收集，安全策略的编写实现，和策略的反馈评估（如下图所示）。

其中特征数据的收集是必不可少的环节，数据的质量将直接影响安全策略的效果。

特征数据收集主要包括：

1）数据接入；
2）特征的计算；
3）特征的存储。

传统特征数据收集流程：

如上图所示：在数据仓库还未建立时，业务同学通过消费离线存储mmdata和tdw接入数据，通过Flink流式计算或者自定义模块对数据进行加工，计算出需要的特征，最终存储到自行维护的KV，然后在安全策略平台上编写安全策略，读取KV中的数据, 实现需要的安全逻辑。

3、为什么需要安全特征数据仓库

前面提到在还未建立数据仓库时，业务同学都按照自己的方式去存储计算出的特征，大多通过自行申请部署KV来存储（如下图中的架构）：如A同学把部署一套KV集群，存储特征到KV表中，B同学把特征存储到同KV集群的不同表中，C同学又额外申请了另外一套KV集群存储。

传统安全后台（各业务特征分散存储）：

这种特征的分散存储，导致业务同学只了解自己熟悉的特征，难以交流和共享，特征缺乏统一的管理，数据质量难以保证，不同的存储方式，也导致特征访问接口的混乱，业务系统的可靠性也难以保证。

针对上述的问题：我们希望把所有业务的特征，按统一的规范，建立统一的存储，方便特征的共享、管理和维护、并建立数据质量保障体系, 为策略提供可靠的数据。所以我们需要开发数据仓库。

问题和目标：

4、安全业务的后台架构

当前，我们已经把所有的安全策略统一到安全策略平台进行开发和管理，特征数据的接入和计算统一到了Flink实时计算平台和特征平台。

数据仓库作为承上启下的部分，是整个业务体系中不可或缺的部分。

总结一下它作用就是：

1）对上为在安全策略平台上的安全策略提供了数据读写；
2）对下为实时计算平台和特征平台计算输出的特征提供了存储。

安全业务后台架构：

5、安全特征数据仓库的存储选型

微信的安全业务特征数据主要有2种类型：

1）离线特征：用来满足离线计算数据导入线上实时使用的需求（通常特征离线计算，定期的批量后台上线，提供在线读，但不支持实时写入）；
2）实时特征：用来满足实时的在线读写需求。

微信内部有多种非常成熟稳定的自研KV：实时读写KV（简称实时KV）、离线写实时读KV（简称离线KV）、***KV等等，这些KV已经在多个业务被验证，有非常好的性能和可靠性，有团队做长期的维护，为此数据仓库的底层存储采用了微信自研的KV。

微信自研的KV主要特点如下：

具体就是：

1）离线KV适合离线特征要求的场景：拥有非常好的读性能，并且提供了版本管理功能，在处理有问题数据时可以非常方便的可以回退版本，采用这种KV存储时，value一般是protobuf对象，新增特征时可以在pb中增加字段；
2）实时KV适合实时特征的场景：在线实时读写性能优秀，而且支持数据过期淘汰，该KV提供了类MySQL表的概念，KV表定义类似于一个MySQL表，而每一个安全业务特征刚好可以用表的一个字段表示。

6、数据仓库的架构设计和演进

6.1统一存储统一接口

数据仓库第一个版本，针对特征存储分散访问接口混乱问题，首先部署了公共的实时KV/离线KV集群，并实现了一个接入层。新增特征和历史特征放到公共的KV存储集群，并且在接入层屏蔽了底层KV的细节，提供了统一的读写特征的接口。

数据仓库架构1.0版：

接入层支持任意多个KV集群，支持多个表，为屏蔽KV的细节，接入层为每个特征分配唯一的标识<sceneid, columnid>，读写特征数据使用唯一标识进行，不需要关注KV类型和KV表ID，方便业务的接入使用。

统一接口：

接入层还实现配置管理、参数校验、模块校验、权限校验、流水上报、PV统计等功能。

6.2读写分离和多IDC同步

1）读写分离：数据仓库的读请求量远远多于实时写入量，为了提高性能，减少读写之间的相互影响，接入层做了读写分离，将读和写接口拆分到两个模块。

2）数据多IDC同步：数据仓库和业务都采用的是多IDC部署，为了不降低查询性能，不希望业务跨IDC访问存储，所以底层的KV也是多IDC部署。这里就带来一个问题，特征数据如何在多IDC的KV之间进行同步? 例如业务在上海写入一个特征，希望在深圳也能读到这个特征。

这里按特征类型进行分类处理：

1）离线特征数据同步：离线特征数据上线流程是通过离线计算在文件系统中生成一个文件，然后将文件导入到离线KV, 而离线KV支持多个IDC共享同一份数据，数据文件只需要生成一份，所有IDC的离线KV拉取同一个文件，新数据最终能同步到所有IDC上；
2）实时特征数据同步：实时特征的同步采用微信自研的分布式队列组件，该组件提供了高可靠、高可用、高吞吐、低延时的数据消息队列服务。数据仓库写接入模块在写入数据时，同时将数据写一份到分布式队列，使用队列做跨IDC的数据同步，在其他IDC启动进程消费队列中的数据，写入到本IDC的实时KV，实现实时特征数据的同步。

数据仓库架构2.0版：