本文由腾讯技术工程师remyliu分享，原题“微信万亿数据仓库架构设计与实现”，本文收录时有内容修订和重新排版。
1、引言
没有足够的特征数据，安全策略将是“无根之木，无源之水”。
微信的安全数据特征仓库应运而生，并成为整个安全业务的特征数据存储中心，每天服务了万亿级的特征数据读写请求，为整个微信安全策略提供了可靠的数据支撑，是微信安全基石之所在。
然而，微信安全特征数据仓库不仅仅是一个存储中心，更是一个特征管理和数据质量管理的中心。
微信的安全数据特征仓库在演进过程中，一直致力于提升特征管理能力和数据质量保障，实现了特征的管理、共享、分析和数据质量检测等功能。
本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践，以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。
2、安全策略开发流程
安全业务的核心逻辑是在安全策略中实现的。整个的策略开发流程包括特征数据的收集，安全策略的编写实现，和策略的反馈评估（如下图所示）。
其中特征数据的收集是必不可少的环节，数据的质量将直接影响安全策略的效果。
特征数据收集主要包括：
传统特征数据收集流程：
如上图所示：在数据仓库还未建立时，业务同学通过消费离线存储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版：
6.3异步写和替代分布式队列
1）异步写入：前一个版本中实时特征是同步写入，影响业务的性能，业务希望是异步写入。
2）替代分布式队列：前一个版本中分布式队列采用的是公共的集群，众多业务使用，出现过数据仓库受干扰影响特征数据同步。
为此：在数据仓库中新增一个异步消息队列模块写MQ，用于异步写入。和分布式队列相比，MQ更轻量，而且MQ我们可以自行维护，更可控。所以新架构中通过MQ实现实时特征的多IDC数据的同步，替代了分布式队列，保证数据同步不受其他业务影响。
数据仓库架构3.0版：
6.4运营系统
前面3个版本解决了特征存储分散、读写接口不统一、数据同步、读写性能问题，但是特征的上线依然采用的是配置发布上线的方式，效率依然低效。
更重要的是特征缺乏统一的管理，共享困难，难以满足业务的需求。
业务常常也有各种疑问：
为此数据仓库新增运营系统模块，实现了特征申请、特征上线、特征管理&分析、特征值查询/修改、特征数据质量管理等功能。
数据仓库架构4.0版：
1）特征申请：
用户不再需要手动的修改配置文件来新增特征，可直接通过WEB页面申请，填写必要的特征信息，通过通用审批系统进行审批。
2）特征上线：
用户不在需要手动的发布配置上线特征，无论是新增的实时特征还是离线特征，审批通过后将自动化的上线，提升体验和效率。
3）特征管理：
特征管理支持对特征meta信息进行查询和修改，包括特征所属的业务分类（索引）、特征类型、特征负责人、给特征打tag等等，业务可以方便的查询需要特征信息，避免重复的计算，方便各业务共享特征。
▲ 特征管理页面
4）特征分析：
追踪特征的原始数据来源、计算过程、数据流路径、最终的存储信息等等, 可以追踪特征完整生产流程。
▲ 特征分析页面
5）特征值查询&修改：运营系统支持在WEB页面查询特征值和修改特征值；
▲ 特征值查询页面
6）特征数据质量管理：保障数据质量, 下一章节详细讲述。
7、数据质量保障手段1：安全特征标准化
数据仓库主要通过两个方面来保障数据质量：特征的标准化和数据空跑系统。本节分享特征的标准化。
特征的标准化是保证数据仓库数据质量的手段之一，标准化是指对数据仓库中的特征进行规范化处理，使得特征能够达到一致性、可重复性等标准，从而提高数据的可靠性和准确性。
对于新增实时/离线特征：数据仓库制定了的特征规范文档，并按规范文档的要求，特征申请/管理页面必须正确的补充完整特征信息，如特征类型、业务分类等等，后台对每个特征都会进行校验，不符合规范的特征无法录入。
另外：数据仓库还提供了接入编程指导文档，并给出完整的C++编程实例，致力于提供标准化的编程最佳实践。
8、数据质量保障手段2：数据空跑系统
离线特征数据来自于业务离线计算在分布式文件系统中生成数据文件，然后将文件上线。
历史上曾因为生成的数据文件存在错误，存在错误的文件数据被上线到离线KV，导致策略出现故障。
为了保障离线特征数据的质量，数据仓库设计了一套空跑系统，在上线前对数据文件进行检查，避免存在问题的数据上线到现网。
数据空跑架构：
数据空跑架构如上图所示，离线特征数据的上线也纳入到了运营系统的管理中。
整个的空跑流程如下。
1）业务发起数据上线：运营系统将数据上线到备用的离线KV表，也就是用于空跑的KV表；
2）打开空跑开关：按一定的比率采样现网的读请求，旁路到新增的读MQ模块，该模块读空跑表的数据，和当前现网做对比, 分析差异率。这里采用的动态采样， 如果表的PV高则采样率低，PV低则采样率高或者100%采样，避免请求量小的表无法进行空跑，而请求量大的表空跑流量太高又消耗太多资源。
3）计算和分析差异率：如果差异率超过了阈值，就自动的拦截数据上线，如果阈值检查通过，就继续后续的检查流程，最终自动上线数据文件到现网离线KV。
差异率示例会如下图（详细的展示了具体的差异细节）：
离线特征数据上线完整流程：
完整的数据上线流程如上图所示：空跑差异检测通过后，需要检查数据文件完整性，防止文件被修改或者覆盖，最后数据再上线到现网数据仓库系统，通知业务数据上线成功。如果中间任何一个步骤出错将告警给业务负责人，提醒人工介入处理。
9、本文小结
微信后台安全特征数据仓库将分散的特征全部集中统一管理，提供统一的访问接口，标准化每个一个特征，建立了统一的规范。
并且在此基础保障了数据的质量，夯实了整个安全业务的基础，助力一站式的数据-策略开发，极大的提升了安全对抗的效率，实现了数据价值的最大化。
10、相关资料
[1] 探讨组合加密算法在IM中的应用
[2] IM聊天系统安全手段之通信连接层加密技术
[3] IM聊天系统安全手段之传输内容端到端加密技术
[4] 理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）
[5] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解
[6] 移动端安全通信的利器——端到端加密（E2EE）技术详解
[7] 通俗易懂：一篇掌握即时通讯的消息传输安全原理
[8] 基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等
[9] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书
11、微信团队的其它技术文章
《IM全文检索技术专题(一)：微信移动端的全文检索优化之路》
《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》
《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》
《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》
（本文已同步发布于：http://www.52im.net/thread-4374-1-1.html）