[點晴永久免費OA][轉帖]微信月活破10億，安全性靠誰來支撐？
當前位置：點晴教程→點晴OA辦公管理信息系統
→『 經驗分享&問題答疑 』
微信作為月活過10億的國民級應用，其安全能力備受關注。值得注意的是，沒有足夠的特征數據，安全策略將是"無根之木，無源之水"。微信安全數據倉庫作為安全業務的特征數據存儲中心，每天服務了萬億級的特征數據讀寫請求，為整個微信安全策略提供了可靠的數據支撐，是微信安全的一塊基石。事實上，微信安全數據倉庫不僅僅是一個存儲中心，更是一個特征管理和數據質量管理的中心。 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 比較適配數據倉庫的底層存儲的需求。其主要特點如下：
2.2 架構設計和演進2.2.1 統一存儲統一接口數據倉庫第一個版本，針對特征存儲分散訪問接口混亂問題，首先部署了公共的實時 KV/離線 KV 集群，并實現了一個接入層。新增特征和歷史特征放到公共的 KV 存儲集群，并且在接入層屏蔽了底層 KV 的細節，提供了統一的讀寫特征的接口。
數據倉庫架構1.0 接入層支持任意多個 KV 集群，支持多個表，為屏蔽 KV 的細節，接入層為每個特征分配唯一的標識<sceneid, columnid>，讀寫特征數據使用唯一標識進行，不需要關注 KV 類型和 KV 表 ID，方便業務的接入使用。
統一接口 接入層還實現配置管理、參數校驗、模塊校驗、權限校驗、流水上報、PV 統計等功能：
2.2.2 讀寫分離和多 IDC 同步
數據倉庫的讀請求量遠遠多于實時寫入量，為了提高性能，減少讀寫之間的相互影響，接入層做了讀寫分離，將讀和寫接口拆分到兩個模塊。
數據倉庫和業務都采用的是多 IDC 部署。為了不降低查詢性能，不希望業務跨 IDC 訪問存儲，所以底層的 KV 也是多 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，導致策略出現故障。 為了保障離線特征數據的質量，數據倉庫設計了一套空跑系統，在上線前對數據文件進行檢查，避免存在問題的數據上線到現網。
數據空跑架構 數據空跑架構如上圖，離線特征數據的上線也納入到了運營系統的管理中，整個的空跑流程如下：
差異率示例如下圖，詳細展示了具體的差異細節：
空跑結果差異率和差異詳情 完整的數據上線流程如下圖，空跑差異檢測通過后，需要檢查數據文件完整性，防止文件被修改或者覆蓋，最后數據再上線到現網數據倉庫系統，通知業務數據上線成功。如果中間任何一個步驟出錯將告警給業務負責人，提醒人工介入處理。
離線特征數據上線完整流程 04、總結整體來說，我們把數據倉庫分散的特征數據全部集中統一管理，提供統一的訪問接口，標準化每一個特征，建立了統一的規范。并且在此基礎上保障了數據的質量，夯實了整個安全業務的基礎，助力一站式的數據-策略開發，極大地提升了安全對抗的效率，實現了數據價值的最大化。 該文章在 2023/7/29 9:38:17 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
