微信月活破10億,安全性靠誰來支撐?
?? 騰小云導讀
微信作為月活過10億的國民級應用，其安全能力備受關注。值得注意的是，沒有足夠的特征數據，安全策略將是"無根之木，無源之水"。微信安全數據倉庫作為安全業(yè)務的特征數據存儲中心，每天服務了萬億級的特征數據讀寫請求，為整個微信安全策略提供了可靠的數據支撐，是微信安全的一塊基石。事實上，微信安全數據倉庫不僅僅是一個存儲中心，更是一個特征管理和數據質量管理的中心。本文將介紹安全數據倉庫的起源、演進、當前的架構設計和數據質量保證系統(tǒng)的實現，請往下閱讀。?? 目錄
1?業(yè)務背景 ????1.1?安全策略開發(fā)流程 ? ? 1.2 為什么需要數據倉庫? ? 1.3 安全業(yè)務后臺架構 2 數據倉庫架構演進 ????2 .1?存儲選型 ? ? 2.2?架構設計和演進 3?數據質量保障 ????3.1?特征標準化 ????3.2?數據空跑系統(tǒng) 4 總結
01
業(yè)務背景
? ? ? 1.1?安全策略開發(fā)流程
安全業(yè)務的核心邏輯在安全策略中實現。整個的策略開發(fā)流程包括特征數據的收集、安全策略的編寫實現和策略的反饋評估。其中特征數據的收集是必不可少的環(huán)節(jié)，數據的質量將直接影響安全策略的效果。
在數據倉庫還未建立時，業(yè)務同事通過消費離線存儲 mmdata 和 tdw 接入數據，通過 Flink 流式計算或者自定義模塊對數據進行加工，計算出需要的特征，最終存儲到自行維護的 KV。然后在安全策略平臺上編寫安全策略，讀取 KV 中的數據,，實現需要的安全邏輯。
? ? ? 1.2?為什么需要數據倉庫
前面提到在還未建立數據倉庫時，業(yè)務同事都按照自己的方式去存儲計算出的特征，大多通過自行申請部署 KV 來存儲，如 A 同事把部署一套 KV 集群，存儲特征到 KV 表中，B 同事把特征存儲到同 KV 集群的不同表中，C 同事又額外申請了另外一套 KV 集群存儲。如下圖中的架構：
傳統(tǒng)安全后臺: 各業(yè)務特征分散存儲
針對上述的問題，我們希望把所有業(yè)務的特征，按統(tǒng)一的規(guī)范，建立統(tǒng)一的存儲，方便特征的共享、管理和維護、并建立數據質量保障體系, 為策略提供可靠的數據。所以我們需要開發(fā)數據倉庫。
問題和目標
? ? ? 1.3?安全業(yè)務后臺架構
當前我們已經把所有的安全策略統(tǒng)一到安全策略平臺進行開發(fā)和管理，特征數據的接入和計算統(tǒng)一到了 Flink 實時計算平臺和特征平臺。
數據倉庫 作為承上啟下的部分，對上為在安全策略平臺上的安全策略提供了數據讀寫，對下為實時計算平臺和特征平臺計算輸出的特征提供了存儲，是整個業(yè)務體系中不可或缺的部分。
安全業(yè)務后臺架構
02
數據倉庫架構演進
? ? ? 2.1?存儲選型
安全業(yè)務特征數據主要有2種類型：
| 離線特征： 用來滿足離線計算數據導入線上實時使用的需求，通常特征離線計算，定期的批量后臺上線，提供在線讀，但不支持實時寫入。 實時特征：用來滿足實時的在線讀寫需求。 |
騰訊有多種非常成熟穩(wěn)定的自研 KV：實時讀寫 KV (簡稱實時 KV) 、離線寫實時讀 KV (簡稱離線 KV) 、其他 K V 等等。 這些 KV 已經在多個業(yè)務被驗證，有非常好的性能和可靠性、有團隊做長期的維護。其中，部分 KV 比較適配數據倉庫的底層存儲的需求。其主要特點如下：
| 存儲KV | 特點 | 是否選用 |
| 離線寫實時讀 KV |
非常適
用大量 key 的定時批量更新，在線只讀，具
有版本管理功能，支持版本歷史版本回退，具有非常優(yōu)秀的讀性能。 |
? ?是 |
| 實時讀寫 KV | 強一致性的 key-value 服務，存在類 MySQL 的表概念，提供了 Select Insert ?Update Delete 接口，在單表操作保證 ACID，支持過期淘汰 TTL。 | ? ?是 |
| 其他 KV | 提供強一致性的 key-value 讀寫服務，類似 STL 中的容器，不支持 TTL， 不提供新集群,不建議使用。 | ? ?否 |
| 離線 KV ： 適合離線特征要求的場景。擁有非常好的讀性能，并且提供了版本管理功能，在處理有問題數據時可以非常方便地回退版本，采用這種 KV 存儲時，value 一般是 protobuf 對象，新增特征時可以在 pb 中增加字段。 實時 KV ：適合實時特征的場景。在線實時讀寫性能優(yōu)秀，而且支持數據過期淘汰，該 KV 提供了類 MySQL 表的概念，KV 表定義類似于一個 MySQL 表，而每一個安全業(yè)務特征剛好可以用表的一個字段表示。 |
? ? ? 2.2?架構設計和演進
2.2.1?統(tǒng)一存儲統(tǒng)一接口
數據倉庫第一個版本，針對特征存儲分散訪問接口混亂問題，首先部署了公共的實時 KV/離線 KV 集群，并實現了一個接入層。新增特征和歷史特征放到公共的 KV 存儲集群，并且在接入層屏蔽了底層 KV 的細節(jié)，提供了統(tǒng)一的讀寫特征的接口。
數據倉庫架構1.0
接入層支持任意多個 KV 集群，支持多個表，為屏蔽 KV 的細節(jié)，接入層為每個特征分配唯一的標識<sceneid, columnid>，讀寫特征數據使用唯一標識進行，不需要關注 KV 類型和 KV 表 ID，方便業(yè)務的接入使用。
統(tǒng)一接口
接入層還實現配置管理、參數校驗、模塊校驗、權限校驗、流水上報、PV 統(tǒng)計等功能：
| 功能 | 說明 |
| 配置管理 | 數據倉庫未開發(fā)時，業(yè)務上線特征需要在 KV 中新增字段，需要重新發(fā)布 KV 配置，整個流程非常的低效，為此數據倉庫為接入的 KV 預先申請一定數量的字段，在配置文件中為特征分配<scenid, columnid>，并映射到具體的 KV 集群和表字段，每次特征上線只需要發(fā)布配置即可，配置管理提供了配置的解析，加載，熱更新等功能。 |
| 參數校驗 | 檢查輸入的讀寫參數是否正確，如訪問不存的集群，不存在表，參數提供的類型和特征實際類型不匹配：如參數是 int，實際特征是 string 類型。 |
| 模塊校驗 | 檢查請求來源模塊是否有讀寫具體某個特征的權限。 |
| 權限校驗 | 檢查請求來源人是否有讀寫某個特征的權限。 |
| 流水上報 | 上報數據倉庫讀和寫的流水，方便問題排查和運營。 |
| PV 統(tǒng)計 | 統(tǒng)計特征讀 PV，包括接口維度 、 模塊維度等等，用于后續(xù)運營。?? |
? ? ? 2.2.2?讀寫分離和多 IDC 同步
- 讀寫分離
數據倉庫的讀請求量遠遠多于實時寫入量，為了提高性能，減少讀寫之間的相互影響，接入層做了讀寫分離，將讀和寫接口拆分到兩個模塊。
- 數據多 IDC 同步
數據倉庫和業(yè)務都采用的是多 IDC 部署。為了不降低查詢性能，不希望業(yè)務跨 IDC 訪問存儲，所以底層的 KV 也是多 IDC 部署。
這里就帶來一個問題，特征數據如何在多 IDC 的 KV 之間進行同步？例如業(yè)務在上海寫入一個特征，希望在深圳也能讀到這個特征。這里按特征類型進行分類處理：
| 離線特征數據同步： 離線特征數據上線流程是通過離線計算在文件系統(tǒng)中生成一個文件，然后將文件導入到離線 KV, 而離線 KV 支持多個 IDC 共享同一份數據，數據文件只需要生成一份，所有 IDC 的離線 KV 拉取同一個文件，新數據最終能同步到所有 IDC 上。 實時特征數據同步：實時特征的同步采用微信自研的分布式隊列組件，該組件提供了高可靠、高可用、高吞吐、低延時的數據消息隊列服務。數據倉庫寫接入模塊在寫入數據時，同時將數據寫一份到分布式隊列，使用隊列做跨 IDC 的數據同步，在其他 IDC 啟動進程消費隊列中的數據，寫入到本 IDC 的實時 KV，實現實時特征數據的同步。 |
數據倉庫架構2.0
? ? ? 2.2.3?異步寫和替代分布式隊列
- 異步寫入
前一個版本中實時特征是同步寫入，影響業(yè)務的性能，業(yè)務希望是異步寫入。
- 替代分布式隊列
前一個版本中分布式隊列采用的是公共的集群，眾多業(yè)務使用，出現過數據倉庫受干擾影響特征數據同步。
為此在數據倉庫中新增一個異步消息隊列模塊寫 MQ，用于異步寫入。和分布式隊列相比 MQ 更輕量，而且 MQ 我們可以自行維護， 更可控。所以新架構中通過 MQ 實現實時特征的多 IDC 數據的同步，替代了分布式隊列，保證數據同步不受其他業(yè)務影響。
數據倉庫架構3.0
? ? ? 2.2.4?運營系統(tǒng)
前面3個版本解決了特征存儲分散、讀寫接口不統(tǒng)一、數據同步、讀寫性能問題，但是特征的上線依然采用的是配置發(fā)布上線的方式，效率依然低效。
更重要的是特征缺乏統(tǒng)一的管理，共享困難，難以滿足業(yè)務的需求，業(yè)務常常也有各種疑問：
為此數據倉庫新增運營系統(tǒng)模塊，實現了特征申請、特征上線、特征管理&分析、特征值查詢/修改、特征數據質量管理等功能。
數據倉庫架構4.0
- 特征申請
用戶不再需要手動的修改配置文件來新增特征，可直接通過 WEB 頁面申請，填寫必要的特征信息，通過通用審批系統(tǒng)進行審批。
- 特征上線
用戶不再需要手動的發(fā)布配置上線特征，無論是新增的實時特征還是離線特征，審批通過后將自動化的上線，提升體驗和效率。
- 特征管理
特征管理支持對特征 meta 信息進行查詢和修改，包括特征所屬的業(yè)務分類 (索引) 、特征類型、特征負責人、給特征打 tag 等等，業(yè)務可以方便的查詢需要特征信息，避免重復的計算，方便各業(yè)務共享特征。
- 特征分析
追蹤特征的原始數據來源、計算過程、數據流路徑、最終的存儲信息等等, 可以追蹤特征完整生產流程。
- 特征值查詢&修改
運營系統(tǒng)支持在 WEB 頁面查詢特征值和修改特征值。
- 特征數據質量管理
保障數據質量，下一章節(jié)詳細講述。
03
數據質量保障
數據倉庫主要通過兩個方面來保障數據質量：特征的標準化和數據空跑系統(tǒng)。接下來我們進行詳細介紹分析。
? ? ? 3.1?特征標準化
特征的標準化是保證數據倉庫數據質量的手段之一，標準化是指對數據倉庫中的特征進行規(guī)范化處理，使得特征能夠達到一致性、可重復性等標準，從而提高數據的可靠性和準確性。
對于新增實時/離線 特征，數據 倉庫制定了的特征規(guī)范文檔，并按規(guī)范文檔的要求，特征申請/管理頁面必須正確的補充完整特征信息，如特征類型、業(yè)務分類等等，后臺對每個特征都會進行校驗，不符合規(guī)范的特征無法錄入。
另外數據倉庫還提供了接入編程指導文檔，并給出完整的 C++編程實例，致力于提供標準化的編程最佳實踐。
? ? ? 3.2?數據空跑系統(tǒng)
離線特征 數據來自于業(yè)務離線計算在分布式文件系統(tǒng)中生成數據文件，然后將文件上線。歷史上曾因為生成的數據文件存在錯誤，存在錯誤的文件數據被上線到離線 KV，導致策略出現故障。
為了保障離線特征數據的質量，數據倉庫設計了一套空跑系統(tǒng)，在上線前對數據文件進行檢查，避免存在問題的數據上線到現網。
數據空跑架構
|
差異率示例如下圖，詳細展示了具體的差異細節(jié)：
完整的數據上線流程如下圖，空跑差異檢測通過后，需要檢查數據文件完整性，防止文件被修改或者覆蓋，最后數據再上線到現網數據倉庫系統(tǒng)，通知業(yè)務數據上線成功。如果中間任何一個步驟出錯將告警給業(yè)務負責人，提醒人工介入處理。
離線特征數據上線完整流程
04
總結
整體來說，我們把數據倉庫分散的特征數據全部集中統(tǒng)一管理，提供統(tǒng)一的訪問接口，標準化每一個特征，建立了統(tǒng)一的規(guī)范。并且在此基礎上保障了數據的質量，夯實了整個安全業(yè)務的基礎，助力一站式的數據-策略開發(fā)，極大地提升了安全對抗的效率，實現了數據價值的最大化。 以上便是本次分享的全部內容。 如果覺得文章內容不錯的話，歡迎轉發(fā)分享。
-End- 原創(chuàng)作者｜remyliu 技術責編｜robintang
你認為數據庫與數據倉庫的本質區(qū)別是什么？數倉與常見的大數據處理框架如何集成？歡迎在評論區(qū)分享。我們將選取1則最有意義的分享，送出騰訊云開發(fā)者-文化衫1件（見下圖）。7月6日中午12點開獎。
關注并星標騰訊云開發(fā)者
第一時間看鵝廠技術