[點晴永久免費OA][轉(zhuǎn)帖]微信月活破10億,安全性靠誰來支撐?
當(dāng)前位置:點晴教程→點晴OA辦公管理信息系統(tǒng)
→『 經(jīng)驗分享&問題答疑 』
微信作為月活過10億的國民級應(yīng)用,其安全能力備受關(guān)注。值得注意的是,沒有足夠的特征數(shù)據(jù),安全策略將是"無根之木,無源之水"。微信安全數(shù)據(jù)倉庫作為安全業(yè)務(wù)的特征數(shù)據(jù)存儲中心,每天服務(wù)了萬億級的特征數(shù)據(jù)讀寫請求,為整個微信安全策略提供了可靠的數(shù)據(jù)支撐,是微信安全的一塊基石。事實上,微信安全數(shù)據(jù)倉庫不僅僅是一個存儲中心,更是一個特征管理和數(shù)據(jù)質(zhì)量管理的中心。 01、業(yè)務(wù)背景1.1 安全策略開發(fā)流程安全業(yè)務(wù)的核心邏輯在安全策略中實現(xiàn)。整個的策略開發(fā)流程包括特征數(shù)據(jù)的收集、安全策略的編寫實現(xiàn)和策略的反饋評估。其中特征數(shù)據(jù)的收集是必不可少的環(huán)節(jié),數(shù)據(jù)的質(zhì)量將直接影響安全策略的效果。 特征數(shù)據(jù)收集主要包括:數(shù)據(jù)接入、特征的計算、特征的存儲。 在數(shù)據(jù)倉庫還未建立時,業(yè)務(wù)同事通過消費離線存儲 mmdata 和 tdw 接入數(shù)據(jù),通過 Flink 流式計算或者自定義模塊對數(shù)據(jù)進行加工,計算出需要的特征,最終存儲到自行維護的 KV。然后在安全策略平臺上編寫安全策略,讀取 KV 中的數(shù)據(jù),,實現(xiàn)需要的安全邏輯。 傳統(tǒng)特征數(shù)據(jù)收集流程 1.2 為什么需要數(shù)據(jù)倉庫前面提到在還未建立數(shù)據(jù)倉庫時,業(yè)務(wù)同事都按照自己的方式去存儲計算出的特征,大多通過自行申請部署 KV 來存儲,如 A 同事把部署一套 KV 集群,存儲特征到 KV 表中,B 同事把特征存儲到同 KV 集群的不同表中,C 同事又額外申請了另外一套 KV 集群存儲。如下圖中的架構(gòu): 傳統(tǒng)安全后臺: 各業(yè)務(wù)特征分散存儲 這種特征的分散存儲,導(dǎo)致業(yè)務(wù)同事只了解自己熟悉的特征,難以交流和共享,特征缺乏統(tǒng)一的管理,數(shù)據(jù)質(zhì)量難以保證。不同的存儲方式,也導(dǎo)致特征訪問接口的混亂,業(yè)務(wù)系統(tǒng)的可靠性也難以保證。 針對上述的問題,我們希望把所有業(yè)務(wù)的特征,按統(tǒng)一的規(guī)范,建立統(tǒng)一的存儲,方便特征的共享、管理和維護、并建立數(shù)據(jù)質(zhì)量保障體系, 為策略提供可靠的數(shù)據(jù)。所以我們需要開發(fā)數(shù)據(jù)倉庫。 問題和目標 1.3 安全業(yè)務(wù)后臺架構(gòu)當(dāng)前我們已經(jīng)把所有的安全策略統(tǒng)一到安全策略平臺進行開發(fā)和管理,特征數(shù)據(jù)的接入和計算統(tǒng)一到了 Flink 實時計算平臺和特征平臺。 數(shù)據(jù)倉庫作為承上啟下的部分,對上為在安全策略平臺上的安全策略提供了數(shù)據(jù)讀寫,對下為實時計算平臺和特征平臺計算輸出的特征提供了存儲,是整個業(yè)務(wù)體系中不可或缺的部分。 安全業(yè)務(wù)后臺架構(gòu) 02、數(shù)據(jù)倉庫架構(gòu)演進2.1 存儲選型安全業(yè)務(wù)特征數(shù)據(jù)主要有2種類型:
騰訊有多種非常成熟穩(wěn)定的自研 KV:實時讀寫 KV(簡稱實時 KV)、離線寫實時讀 KV(簡稱離線 KV)、其他 KV 等等。這些 KV 已經(jīng)在多個業(yè)務(wù)被驗證,有非常好的性能和可靠性、有團隊做長期的維護。其中,部分 KV 比較適配數(shù)據(jù)倉庫的底層存儲的需求。其主要特點如下:
2.2 架構(gòu)設(shè)計和演進2.2.1 統(tǒng)一存儲統(tǒng)一接口數(shù)據(jù)倉庫第一個版本,針對特征存儲分散訪問接口混亂問題,首先部署了公共的實時 KV/離線 KV 集群,并實現(xiàn)了一個接入層。新增特征和歷史特征放到公共的 KV 存儲集群,并且在接入層屏蔽了底層 KV 的細節(jié),提供了統(tǒng)一的讀寫特征的接口。 數(shù)據(jù)倉庫架構(gòu)1.0 接入層支持任意多個 KV 集群,支持多個表,為屏蔽 KV 的細節(jié),接入層為每個特征分配唯一的標識<sceneid, columnid>,讀寫特征數(shù)據(jù)使用唯一標識進行,不需要關(guān)注 KV 類型和 KV 表 ID,方便業(yè)務(wù)的接入使用。 統(tǒng)一接口 接入層還實現(xiàn)配置管理、參數(shù)校驗、模塊校驗、權(quán)限校驗、流水上報、PV 統(tǒng)計等功能:
2.2.2 讀寫分離和多 IDC 同步
數(shù)據(jù)倉庫的讀請求量遠遠多于實時寫入量,為了提高性能,減少讀寫之間的相互影響,接入層做了讀寫分離,將讀和寫接口拆分到兩個模塊。
數(shù)據(jù)倉庫和業(yè)務(wù)都采用的是多 IDC 部署。為了不降低查詢性能,不希望業(yè)務(wù)跨 IDC 訪問存儲,所以底層的 KV 也是多 IDC 部署。 這里就帶來一個問題,特征數(shù)據(jù)如何在多 IDC 的 KV 之間進行同步?例如業(yè)務(wù)在上海寫入一個特征,希望在深圳也能讀到這個特征。這里按特征類型進行分類處理:
數(shù)據(jù)倉庫架構(gòu)2.0 2.2.3 異步寫和替代分布式隊列
前一個版本中實時特征是同步寫入,影響業(yè)務(wù)的性能,業(yè)務(wù)希望是異步寫入。
前一個版本中分布式隊列采用的是公共的集群,眾多業(yè)務(wù)使用,出現(xiàn)過數(shù)據(jù)倉庫受干擾影響特征數(shù)據(jù)同步。 為此在數(shù)據(jù)倉庫中新增一個異步消息隊列模塊寫 MQ,用于異步寫入。和分布式隊列相比 MQ 更輕量,而且 MQ 我們可以自行維護, 更可控。所以新架構(gòu)中通過 MQ 實現(xiàn)實時特征的多 IDC 數(shù)據(jù)的同步,替代了分布式隊列,保證數(shù)據(jù)同步不受其他業(yè)務(wù)影響。 數(shù)據(jù)倉庫架構(gòu)3.0 2.2.4 運營系統(tǒng)前面3個版本解決了特征存儲分散、讀寫接口不統(tǒng)一、數(shù)據(jù)同步、讀寫性能問題,但是特征的上線依然采用的是配置發(fā)布上線的方式,效率依然低效。 更重要的是特征缺乏統(tǒng)一的管理,共享困難,難以滿足業(yè)務(wù)的需求,業(yè)務(wù)常常也有各種疑問: 為此數(shù)據(jù)倉庫新增運營系統(tǒng)模塊,實現(xiàn)了特征申請、特征上線、特征管理&分析、特征值查詢/修改、特征數(shù)據(jù)質(zhì)量管理等功能。 數(shù)據(jù)倉庫架構(gòu)4.0
用戶不再需要手動的修改配置文件來新增特征,可直接通過 WEB 頁面申請,填寫必要的特征信息,通過通用審批系統(tǒng)進行審批。
用戶不再需要手動的發(fā)布配置上線特征,無論是新增的實時特征還是離線特征,審批通過后將自動化的上線,提升體驗和效率。
特征管理支持對特征 meta 信息進行查詢和修改,包括特征所屬的業(yè)務(wù)分類(索引)、特征類型、特征負責(zé)人、給特征打 tag 等等,業(yè)務(wù)可以方便的查詢需要特征信息,避免重復(fù)的計算,方便各業(yè)務(wù)共享特征。
追蹤特征的原始數(shù)據(jù)來源、計算過程、數(shù)據(jù)流路徑、最終的存儲信息等等, 可以追蹤特征完整生產(chǎn)流程。
運營系統(tǒng)支持在 WEB 頁面查詢特征值和修改特征值。
保障數(shù)據(jù)質(zhì)量,下一章節(jié)詳細講述。 03、數(shù)據(jù)質(zhì)量保障數(shù)據(jù)倉庫主要通過兩個方面來保障數(shù)據(jù)質(zhì)量:特征的標準化和數(shù)據(jù)空跑系統(tǒng)。 接下來我們進行詳細介紹分析。 3.1 特征標準化特征的標準化是保證數(shù)據(jù)倉庫數(shù)據(jù)質(zhì)量的手段之一,標準化是指對數(shù)據(jù)倉庫中的特征進行規(guī)范化處理,使得特征能夠達到一致性、可重復(fù)性等標準,從而提高數(shù)據(jù)的可靠性和準確性。 對于新增實時/離線特征,數(shù)據(jù)倉庫制定了的特征規(guī)范文檔,并按規(guī)范文檔的要求,特征申請/管理頁面必須正確的補充完整特征信息,如特征類型、業(yè)務(wù)分類等等,后臺對每個特征都會進行校驗,不符合規(guī)范的特征無法錄入。 另外數(shù)據(jù)倉庫還提供了接入編程指導(dǎo)文檔,并給出完整的 C++編程實例,致力于提供標準化的編程最佳實踐。 3.2 數(shù)據(jù)空跑系統(tǒng)離線特征數(shù)據(jù)來自于業(yè)務(wù)離線計算在分布式文件系統(tǒng)中生成數(shù)據(jù)文件,然后將文件上線。歷史上曾因為生成的數(shù)據(jù)文件存在錯誤,存在錯誤的文件數(shù)據(jù)被上線到離線 KV,導(dǎo)致策略出現(xiàn)故障。 為了保障離線特征數(shù)據(jù)的質(zhì)量,數(shù)據(jù)倉庫設(shè)計了一套空跑系統(tǒng),在上線前對數(shù)據(jù)文件進行檢查,避免存在問題的數(shù)據(jù)上線到現(xiàn)網(wǎng)。 數(shù)據(jù)空跑架構(gòu) 數(shù)據(jù)空跑架構(gòu)如上圖,離線特征數(shù)據(jù)的上線也納入到了運營系統(tǒng)的管理中,整個的空跑流程如下:
差異率示例如下圖,詳細展示了具體的差異細節(jié): 空跑結(jié)果差異率和差異詳情 完整的數(shù)據(jù)上線流程如下圖,空跑差異檢測通過后,需要檢查數(shù)據(jù)文件完整性,防止文件被修改或者覆蓋,最后數(shù)據(jù)再上線到現(xiàn)網(wǎng)數(shù)據(jù)倉庫系統(tǒng),通知業(yè)務(wù)數(shù)據(jù)上線成功。如果中間任何一個步驟出錯將告警給業(yè)務(wù)負責(zé)人,提醒人工介入處理。 離線特征數(shù)據(jù)上線完整流程 04、總結(jié)整體來說,我們把數(shù)據(jù)倉庫分散的特征數(shù)據(jù)全部集中統(tǒng)一管理,提供統(tǒng)一的訪問接口,標準化每一個特征,建立了統(tǒng)一的規(guī)范。并且在此基礎(chǔ)上保障了數(shù)據(jù)的質(zhì)量,夯實了整個安全業(yè)務(wù)的基礎(chǔ),助力一站式的數(shù)據(jù)-策略開發(fā),極大地提升了安全對抗的效率,實現(xiàn)了數(shù)據(jù)價值的最大化。 該文章在 2023/7/29 9:38:17 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |