腾小云导读
微信作为月活过 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 点开奖。