作者:remy
没有足够的特征数据,安全策略将是"无根之木,无源之水"。微信安全数据仓库应运而生,成为整个安全业务的特征数据存储中心,每天服务了万亿级的特征数据读写请求,为整个微信安全策略提供了可靠的数据支撑,是微信安全基石之所在。然而,微信安全数据仓库不仅仅是一个存储中心,更是一个特征管理和数据质量管理的中心。在演进过程中,数据仓库一直致力于提升特征管理能力和数据质量保障,实现了特征的管理、共享、分析和数据质量检测等功能。本文将介绍安全数据仓库的起源、演进、当前的架构设计和数据质量保证系统的实现。
安全业务的核心逻辑在安全策略中实现。整个的策略开发流程包括特征数据的收集,安全策略的编写实现,和策略的反馈评估。其中特征数据的收集是必不可少的环节,数据的质量将直接影响安全策略的效果。
特征数据收集主要包括:数据接入、特征的计算、特征的存储。
在数据仓库还未建立时,业务同学通过消费离线存储mmdata和tdw接入数据,通过Flink流式计算或者自定义模块对数据进行加工,计算出需要的特征,最终存储到自行维护的KV,然后在安全策略平台上编写安全策略,读取KV中的数据, 实现需要的安全逻辑。
传统特征数据收集流程
前面提到在还未建立数据仓库时,业务同学都按照自己的方式去存储计算出的特征,大多通过自行申请部署KV来存储,如A同学把部署一套KV集群,存储特征到KV表中,B同学把特征存储到同KV集群的不同表中,C同学又额外申请了另外一套KV集群存储。如下图中的架构:
传统安全后台: 各业务特征分散存储
这种特征的分散存储,导致业务同学只了解自己熟悉的特征,难以交流和共享,特征缺乏统一的管理,数据质量难以保证,不同的存储方式,也导致特征访问接口的混乱,业务系统的可靠性也难以保证。
针对上述的问题,我们希望把所有业务的特征,按统一的规范,建立统一的存储,方便特征的共享、管理和维护、并建立数据质量保障体系, 为策略提供可靠的数据。所以我们需要开发数据仓库。
问题和目标
当前我们已经把所有的安全策略统一到安全策略平台进行开发和管理,特征数据的接入和计算统一到了Flink实时计算平台和特征平台。
数据仓库作为承上启下的部分,对上为在安全策略平台上的安全策略提供了数据读写,对下为实时计算平台和特征平台计算输出的特征提供了存储,是整个业务体系中不可或缺的部分。
安全业务后台架构
安全业务特征数据主要有2种类型:
微信内部有多种非常成熟稳定的自研KV:实时读写KV(简称实时KV), 离线写实时读KV(简称离线KV), ***KV等等, 这些KV已经在多个业务被验证,有非常好的性能和可靠性,有团队做长期的维护,为此数据仓库的底层存储采用了微信自研的KV。其主要特点如下:
存储KV | 特点 | 是否选用 |
---|---|---|
离线写实时读KV | 非常适用大量key的定时批量更新,在线只读,具有版本管理功能,支持版本历史版本回退,具有非常优秀的读性能。 | 是 |
实时读写KV | 强一致性的key-value服务,存在类MySQL的表概念,提供了Select Insert Update Delete接口,在单表操作保证ACID,支持过期淘汰TTL。 | 是 |
***KV | 提供强一致性的key-value读写服务,类似STL中的容器,不支持TTL, 不提供新集群,不建议使用。 | 否 |
数据仓库第一个版本,针对特征存储分散访问接口混乱问题,首先部署了公共的实时KV/离线KV集群,并实现了一个接入层。新增特征和历史特征放到公共的KV存储集群,并且在接入层屏蔽了底层KV的细节,提供了统一的读写特征的接口。
数据仓库架构1.0
接入层支持任意多个KV集群,支持多个表,为屏蔽KV的细节,接入层为每个特征分配唯一的标识<sceneid, columnid>,读写特征数据使用唯一标识进行,不需要关注KV类型和KV表ID,方便业务的接入使用。
统一接口
接入层还实现配置管理、参数校验、模块校验、权限校验、流水上报、PV统计等功能。
读写分离:数据仓库的读请求量远远多于实时写入量,为了提高性能,减少读写之间的相互影响,接入层做了读写分离,将读和写接口拆分到两个模块。
数据多IDC同步:数据仓库和业务都采用的是多IDC部署,为了不降低查询性能,不希望业务跨IDC访问存储,所以底层的KV也是多IDC部署。这里就带来一个问题,特征数据如何在多IDC的KV之间进行同步? 例如业务在上海写入一个特征,希望在深圳也能读到这个特征。这里按特征类型进行分类处理:
数据仓库架构2.0
异步写入:前一个版本中实时特征是同步写入,影响业务的性能,业务希望是异步写入。
替代分布式队列:前一个版本中分布式队列采用的是公共的集群,众多业务使用,出现过数据仓库受干扰影响特征数据同步。
为此在数据仓库中新增一个异步消息队列模块写MQ,用于异步写入。和分布式队列相比MQ更轻量,而且MQ我们可以自行维护, 更可控,所以新架构中通过MQ实现实时特征的多IDC数据的同步,替代了分布式队列,保证数据同步不受其他业务影响。
数据仓库架构3.0
前面3个版本解决了特征存储分散、读写接口不统一、数据同步、读写性能问题,但是特征的上线依然采用的是配置发布上线的方式,效率依然低效,更重要的是特征缺乏统一的管理,共享困难,难以满足业务的需求,业务常常也有各种疑问:
业务的疑问
为此数据仓库新增运营系统模块,实现了特征申请、特征上线、特征管理&分析、特征值查询/修改、特征数据质量管理等功能
数据仓库架构4.0
特征管理页面
特征分析页面
特征值查询页面
数据仓库主要通过两个方面来保障数据质量:特征的标准化和数据空跑系统。
特征的标准化是保证数据仓库数据质量的手段之一,标准化是指对数据仓库中的特征进行规范化处理,使得特征能够达到一致性、可重复性等标准,从而提高数据的可靠性和准确性。
对于新增实时/离线特征, 数据仓库制定了的特征规范文档,并按规范文档的要求,特征申请/管理页面必须正确的补充完整特征信息,如特征类型、业务分类等等,后台对每个特征都会进行校验,不符合规范的特征无法录入。
另外数据仓库还提供了接入编程指导文档,并给出完整的C++编程实例,致力于提供标准化的编程最佳实践。
离线特征数据来自于业务离线计算在分布式文件系统中生成数据文件,然后将文件上线。历史上曾因为生成的数据文件存在错误,存在错误的文件数据被上线到离线KV,导致策略出现故障。为了保障离线特征数据的质量,数据仓库设计了一套空跑系统,在上线前对数据文件进行检查,避免存在问题的数据上线到现网。
数据空跑架构
数据空跑架构如上图,离线特征数据的上线也纳入到了运营系统的管理中,整个的空跑流程如下:
差异率示例会如下图:详细的展示了具体的差异细节:
空跑结果差异率和差异详情
完整的数据上线流程如下图,空跑差异检测通过后,需要检查数据文件完整性,防止文件被修改或者覆盖,最后数据再上线到现网数据仓库系统,通知业务数据上线成功。如果中间任何一个步骤出错将告警给业务负责人,提醒人工介入处理。
离线特征数据上线完整流程
总结
数据仓库将分散的特征全部集中统一管理,提供统一的访问接口,标准化每个一个特征,建立了统一的规范,并且在此基础保障了数据的质量,夯实了整个安全业务的基础,助力一站式的数据-策略开发,极大的提升了安全对抗的效率,实现了数据价值的最大化。