腾小云导读
微信作为月活过10亿的国民级应用，其安全才能备受重视。值得注意的是，没有满意的特征数据，安全战略将是”无根之木，无源之水”。微信安全数据仓库作为安全事务的特征数据存储中心，每天服务了万亿级的特征数据读写恳求，为整个微信安全战略供给了牢靠的数据支撑，是微信安全的一块柱石。事实上，微信安全数据仓库不仅仅是一个存储中心，更是一个特征办理和数据质量办理的中心。本文将介绍安全数据仓库的来历、演进、当时的架构规划和数据质量确保体系的完成，请往下阅读。
目录
1 事务背景
1.1 安全战略开发流程
1.2 为什么需求数据仓库
1.3 安全事务后台架构
2 数据仓库架构演进
2.1 存储选型
2.2 架构规划和演进
3 数据质量确保
3.1 特征标准化
3.2 数据空跑体系
4 总结
01、事务背景
1.1 安全战略开发流程
安全事务的中心逻辑在安全战略中完成。整个的战略开发流程包括特征数据的搜集、安全战略的编写完成和战略的反应评价。其间特征数据的搜集是必不可少的环节，数据的质量将直接影响安全战略的效果。
特征数据搜集首要包括：数据接入、特征的计算、特征的存储。
在数据仓库还未树立时，事务搭档经过消费离线存储 mmdata 和 tdw 接入数据，经过 Flink 流式计算或许自定义模块对数据进行加工，计算出需求的特征，终究存储到自行保护的 KV。然后在安全战略渠道上编写安全战略，读取 KV 中的数据,，完成需求的安全逻辑。
传统特征数据搜集流程
1.2 为什么需求数据仓库
前面提到在还未树立数据仓库时，事务搭档都依照自己的方法去存储计算出的特征，大多经过自行恳求布置 KV 来存储，如 A 搭档把布置一套 KV 集群，存储特征到 KV 表中，B 搭档把特征存储到同 KV 集群的不同表中，C 搭档又额定恳求了别的一套 KV 集群存储。如下图中的架构：
传统安全后台: 各事务特征涣散存储
这种特征的涣散存储，导致事务搭档只了解自己了解的特征，难以沟通和同享，特征缺乏一致的办理，数据质量难以确保。不同的存储方法，也导致特征访问接口的混乱，事务体系的牢靠性也难以确保。
针对上述的问题，咱们期望把一切事务的特征，按一致的标准，树立一致的存储，便利特征的同享、办理和保护、并树立数据质量确保体系, 为战略供给牢靠的数据。所以咱们需求开发数据仓库。
问题和方针
1.3 安全事务后台架构
当时咱们现已把一切的安全战略一致到安全战略渠道进行开发和办理，特征数据的接入和计算一致到了 Flink 实时计算渠道和特征渠道。
数据仓库作为承上启下的部分，对上为在安全战略渠道上的安全战略供给了数据读写，对下为实时计算渠道和特征渠道计算输出的特征供给了存储，是整个事务体系中不可或缺的部分。
安全事务后台架构
02、数据仓库架构演进
2.1 存储选型
安全事务特征数据首要有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 存储时，value 一般是 protobuf 对象，新增特征时可以在 pb 中添加字段。 实时 KV ：合适实时特征的场景。在线实时读写功能优异，并且支撑数据过期淘汰，该 KV 供给了类 MySQL 表的概念，KV 表定义类似于一个 MySQL 表，而每一个安全事务特征刚好可以用表的一个字段表示。 |
|---|
2.2 架构规划和演进
2.2.1 一致存储一致接口
数据仓库第一个版别，针对特征存储涣散访问接口混乱问题，首先布置了公共的实时 KV/离线 KV 集群，并完成了一个接入层。新增特征和历史特征放到公共的 KV 存储集群，并且在接入层屏蔽了底层 KV 的细节，供给了一致的读写特征的接口。
数据仓库架构1.0
接入层支撑恣意多个 KV 集群，支撑多个表，为屏蔽 KV 的细节，接入层为每个特征分配仅有的标识<sceneid, columnid>，读写特征数据运用仅有标识进行，不需求重视 KV 类型和 KV 表 ID，便利事务的接入运用。
一致接口
接入层还完成装备办理、参数校验、模块校验、权限校验、流水上报、PV 计算等功用：
| 功用 | 说明 |
|---|---|
| 装备办理 | 数据仓库未开发时，事务上线特征需求在 KV 中新增字段，需求重新发布 KV 装备，整个流程十分的低效，为此数据仓库为接入的 KV 预先恳求必定数量的字段，在装备文件中为特征分配<scenid, columnid>，并映射到详细的 KV 集群和表字段，每次特征上线只需求发布装备即可，装备办理供给了装备的解析，加载，热更新等功用。 |
| 参数校验 | 查看输入的读写参数是否正确，如访问不存的集群，不存在表，参数供给的类型和特征实际类型不匹配：如参数是 int，实际特征是 string 类型。 |
| 模块校验 | 查看恳求来历模块是否有读写详细某个特征的权限。 |
| 权限校验 | 查看恳求来历人是否有读写某个特征的权限。 |
| 流水上报 | 上报数据仓库读和写的流水，便利问题排查和运营。 |
| PV 计算 | 计算特征读 PV，包括接口维度、模块维度等等，用于后续运营。 |
2.2.2 读写别离和多 IDC 同步
- 读写别离
数据仓库的读恳求量远远多于实时写入量，为了进步功能，减少读写之间的相互影响，接入层做了读写别离，将读和写接口拆分到两个模块。
- 数据多 IDC 同步
数据仓库和事务都选用的是多 IDC 布置。为了不降低查询功能，不期望事务跨 IDC 访问存储，所以底层的 KV 也是多 IDC 布置。
这儿就带来一个问题，特征数据如何在多 IDC 的 KV 之间进行同步？例如事务在上海写入一个特征，期望在深圳也能读到这个特征。这儿按特征类型进行分类处理：
| 离线特征数据同步：离线特征数据上线流程是经过离线计算在文件体系中生成一个文件，然后将文件导入到离线 KV, 而离线 KV 支撑多个 IDC 同享同一份数据，数据文件只需求生成一份，一切 IDC 的离线 KV 拉取同一个文件，新数据终究能同步到一切 IDC 上。 实时特征数据同步：实时特征的同步选用微信自研的分布式行列组件，该组件供给了高牢靠、高可用、高吞吐、低延时的数据音讯行列服务。数据仓库写接入模块在写入数据时，一起将数据写一份到分布式行列，运用行列做跨 IDC 的数据同步，在其他 IDC 发动进程消费行列中的数据，写入到本 IDC 的实时 KV，完成实时特征数据的同步。 |
|---|
数据仓库架构2.0
2.2.3 异步写和替代分布式行列
- 异步写入
前一个版别中实时特征是同步写入，影响事务的功能，事务期望是异步写入。
- 替代分布式行列
前一个版别中分布式行列选用的是公共的集群，众多事务运用，出现过数据仓库受搅扰影响特征数据同步。
为此在数据仓库中新增一个异步音讯行列模块写 MQ，用于异步写入。和分布式行列比较 MQ 更轻量，并且 MQ 咱们可以自行保护， 更可控。所以新架构中经过 MQ 完成实时特征的多 IDC 数据的同步，替代了分布式行列，确保数据同步不受其他事务影响。
数据仓库架构3.0
2.2.4 运营体系
前面3个版别处理了特征存储涣散、读写接口不一致、数据同步、读写功能问题，但是特征的上线仍然选用的是装备发布上线的方法，功率仍然低效。
更重要的是特征缺乏一致的办理，同享困难，难以满意事务的需求，事务常常也有各种疑问：
为此数据仓库新增运营体系模块，完成了特征恳求、特征上线、特征办理&剖析、特征值查询/修正、特征数据质量办理等功用。
数据仓库架构4.0
- 特征恳求
用户不再需求手动的修正装备文件来新增特征，可直接经过 WEB 页面恳求，填写必要的特征信息，经过通用批阅体系进行批阅。
- 特征上线
用户不再需求手动的发布装备上线特征，无论是新增的实时特征仍是离线特征，批阅经往后将主动化的上线，提高体验和功率。
- 特征办理
特征办理支撑对特征 meta 信息进行查询和修正，包括特征所属的事务分类(索引)、特征类型、特征负责人、给特征打 tag 等等，事务可以便利的查询需求特征信息，避免重复的计算，便利各事务同享特征。
- 特征剖析
追寻特征的原始数据来历、计算进程、数据流途径、终究的存储信息等等, 可以追寻特征完好生产流程。
- 特征值查询&修正
运营体系支撑在 WEB 页面查询特征值和修正特征值。
- 特征数据质量办理
确保数据质量，下一章节详细叙述。
03、数据质量确保
数据仓库首要经过两个方面来确保数据质量：特征的标准化和数据空跑体系。 接下来咱们进行详细介绍剖析。
3.1 特征标准化
特征的标准化是确保数据仓库数据质量的手段之一，标准化是指对数据仓库中的特征进行标准化处理，使得特征可以达到一致性、可重复性等标准，从而进步数据的牢靠性和准确性。
关于新增实时/离线特征，数据仓库制定了的特征标准文档，并按标准文档的要求，特征恳求/办理页面必须正确的补充完好特征信息，如特征类型、事务分类等等，后台对每个特征都会进行校验，不符合标准的特征无法录入。
别的数据仓库还供给了接入编程指导文档，并给出完好的 C++编程实例，致力于供给标准化的编程最佳实践。
3.2 数据空跑体系
离线特征数据来自于事务离线计算在分布式文件体系中生成数据文件，然后将文件上线。历史上曾由于生成的数据文件存在过错，存在过错的文件数据被上线到离线 KV，导致战略出现故障。
为了确保离线特征数据的质量，数据仓库规划了一套空跑体系，在上线前对数据文件进行查看，避免存在问题的数据上线到现网。
数据空跑架构
数据空跑架构如上图，离线特征数据的上线也归入到了运营体系的办理中，整个的空跑流程如下：
| 事务建议数据上线，运营体系将数据上线到备用的离线 KV 表，也便是用于空跑的 KV 表。 打开空跑开关，按必定的比率采样现网的读恳求，旁路到新增的读 MQ 模块，该模块读空跑表的数据，和当时现网做对比, 剖析差异率。这儿选用的动态采样， 假如表的 PV 高则采样率低，PV 低则采样率高或许100%采样，避免恳求量小的表无法进行空跑，而恳求量大的表空跑流量太高又耗费太多资源。 计算和剖析差异率。假如差异率超过了阈值，就主动的拦截数据上线，假如阈值查看经过，就持续后续的查看流程，终究主动上线数据文件到现网离线 KV。 |
|---|
差异率示例如下图，详细展示了详细的差异细节：
空跑结果差异率和差异概况
完好的数据上线流程如下图，空跑差异检测经往后，需求查看数据文件完好性，避免文件被修正或许掩盖，最终数据再上线到现网数据仓库体系，告诉事务数据上线成功。假如中心任何一个过程出错将告警给事务负责人，提示人工介入处理。
离线特征数据上线完好流程
04、总结
全体来说，咱们把数据仓库涣散的特征数据悉数集中一致办理，供给一致的访问接口，标准化每一个特征，树立了一致的标准。并且在此基础上确保了数据的质量，夯实了整个安全事务的基础，助力一站式的数据-战略开发，极大地提高了安全对立的功率，完成了数据价值的最大化。以上便是本次共享的悉数内容。假如觉得文章内容不错的话，欢迎转发共享。
-End-
原创作者｜remyliu
技术责编｜robintang
你以为数据库与数据仓库的本质区别是什么？数仓与常见的大数据处理框架如何集成？欢迎在腾讯云开发者大众号评论区共享。咱们将选取1则最有意义的共享，送出腾讯云开发者-文化衫1件（见下图）。7月6日正午12点开奖。
