微信萬億數據倉庫架構設計與實現
作者：remy
沒有足夠的特徵數據，安全策略將是 "無根之木，無源之水"。微信安全數據倉庫應運而生，成爲整個安全業務的特徵數據存儲中心，每天服務了萬億級的特徵數據讀寫請求，爲整個微信安全策略提供了可靠的數據支撐，是微信安全基石之所在。然而，微信安全數據倉庫不僅僅是一個存儲中心，更是一個特徵管理和數據質量管理的中心。在演進過程中，數據倉庫一直致力於提升特徵管理能力和數據質量保障，實現了特徵的管理、共享、分析和數據質量檢測等功能。本文將介紹安全數據倉庫的起源、演進、當前的架構設計和數據質量保證系統的實現。
業務背景
安全策略開發流程
安全業務的核心邏輯在安全策略中實現。整個的策略開發流程包括特徵數據的收集，安全策略的編寫實現，和策略的反饋評估。其中特徵數據的收集是必不可少的環節，數據的質量將直接影響安全策略的效果。
特徵數據收集主要包括：數據接入、特徵的計算、特徵的存儲。
在數據倉庫還未建立時，業務同學通過消費離線存儲 mmdata 和 tdw 接入數據，通過 Flink 流式計算或者自定義模塊對數據進行加工，計算出需要的特徵，最終存儲到自行維護的 KV，然後在安全策略平臺上編寫安全策略，讀取 KV 中的數據, 實現需要的安全邏輯。
爲什麼需要數據倉庫
前面提到在還未建立數據倉庫時，業務同學都按照自己的方式去存儲計算出的特徵，大多通過自行申請部署 KV 來存儲，如 A 同學把部署一套 KV 集羣，存儲特徵到 KV 表中，B 同學把特徵存儲到同 KV 集羣的不同表中，C 同學又額外申請了另外一套 KV 集羣存儲。如下圖中的架構：
這種特徵的分散存儲，導致業務同學只瞭解自己熟悉的特徵，難以交流和共享，特徵缺乏統一的管理，數據質量難以保證，不同的存儲方式，也導致特徵訪問接口的混亂，業務系統的可靠性也難以保證。
針對上述的問題，我們希望把所有業務的特徵，按統一的規範，建立統一的存儲，方便特徵的共享、管理和維護、並建立數據質量保障體系, 爲策略提供可靠的數據。所以我們需要開發數據倉庫。
安全業務後臺架構
當前我們已經把所有的安全策略統一到安全策略平臺進行開發和管理，特徵數據的接入和計算統一到了 Flink 實時計算平臺和特徵平臺。
數據倉庫作爲承上啓下的部分，對上爲在安全策略平臺上的安全策略提供了數據讀寫，對下爲實時計算平臺和特徵平臺計算輸出的特徵提供了存儲，是整個業務體系中不可或缺的部分。
數據倉庫架構演進
存儲選型
安全業務特徵數據主要有 2 種類型：
微信內部有多種非常成熟穩定的自研 KV：實時讀寫 KV(簡稱實時 KV), 離線寫實時讀 KV(簡稱離線 KV), ***KV 等等, 這些 KV 已經在多個業務被驗證，有非常好的性能和可靠性，有團隊做長期的維護，爲此數據倉庫的底層存儲採用了微信自研的 KV。其主要特點如下：
-
離線 KV 適合離線特徵要求的場景，擁有非常好的讀性能，並且提供了版本管理功能，在處理有問題數據時可以非常方便的可以回退版本，採用這種 KV 存儲時，value 一般是 protobuf 對象，新增特徵時可以在 pb 中增加字段。
-
實時 KV 適合實時特徵的場景，在線實時讀寫性能優秀，而且支持數據過期淘汰，該 KV 提供了類 MySQL 表的概念，KV 表定義類似於一個 MySQL 表，而每一個安全業務特徵剛好可以用表的一個字段表示。
架構設計和演進
統一存儲統一接口
數據倉庫第一個版本，針對特徵存儲分散訪問接口混亂問題，首先部署了公共的實時 KV/ 離線 KV 集羣，並實現了一個接入層。新增特徵和歷史特徵放到公共的 KV 存儲集羣，並且在接入層屏蔽了底層 KV 的細節，提供了統一的讀寫特徵的接口。
接入層支持任意多個 KV 集羣，支持多個表，爲屏蔽 KV 的細節，接入層爲每個特徵分配唯一的標識 <sceneid, columnid>，讀寫特徵數據使用唯一標識進行，不需要關注 KV 類型和 KV 表 ID，方便業務的接入使用。
接入層還實現配置管理、參數校驗、模塊校驗、權限校驗、流水上報、PV 統計等功能。
讀寫分離和多 IDC 同步
讀寫分離： 數據倉庫的讀請求量遠遠多於實時寫入量，爲了提高性能，減少讀寫之間的相互影響，接入層做了讀寫分離，將讀和寫接口拆分到兩個模塊。
數據多 IDC 同步： 數據倉庫和業務都採用的是多 IDC 部署，爲了不降低查詢性能，不希望業務跨 IDC 訪問存儲，所以底層的 KV 也是多 IDC 部署。這裏就帶來一個問題，特徵數據如何在多 IDC 的 KV 之間進行同步? 例如業務在上海寫入一個特徵，希望在深圳也能讀到這個特徵。這裏按特徵類型進行分類處理：
-
離線特徵數據同步： 離線特徵數據上線流程是通過離線計算在文件系統中生成一個文件，然後將文件導入到離線 KV, 而離線 KV 支持多個 IDC 共享同一份數據，數據文件只需要生成一份，所有 IDC 的離線 KV 拉取同一個文件，新數據最終能同步到所有 IDC 上。
-
實時特徵數據同步： 實時特徵的同步採用微信自研的分佈式隊列組件，該組件提供了高可靠、高可用、高吞吐、低延時的數據消息隊列服務。數據倉庫寫接入模塊在寫入數據時，同時將數據寫一份到分佈式隊列，使用隊列做跨 IDC 的數據同步，在其他 IDC 啓動進程消費隊列中的數據，寫入到本 IDC 的實時 KV，實現實時特徵數據的同步。
異步寫和替代分佈式隊列
異步寫入： 前一個版本中實時特徵是同步寫入，影響業務的性能，業務希望是異步寫入。
替代分佈式隊列： 前一個版本中分佈式隊列採用的是公共的集羣，衆多業務使用，出現過數據倉庫受干擾影響特徵數據同步。
爲此在數據倉庫中新增一個異步消息隊列模塊寫 MQ，用於異步寫入。和分佈式隊列相比 MQ 更輕量，而且 MQ 我們可以自行維護， 更可控，所以新架構中通過 MQ 實現實時特徵的多 IDC 數據的同步，替代了分佈式隊列，保證數據同步不受其他業務影響。
運營系統
前面 3 個版本解決了特徵存儲分散、讀寫接口不統一、數據同步、讀寫性能問題，但是特徵的上線依然採用的是配置發佈上線的方式，效率依然低效，更重要的是特徵缺乏統一的管理，共享困難，難以滿足業務的需求，業務常常也有各種疑問：
爲此數據倉庫新增運營系統模塊，實現了特徵申請、特徵上線、特徵管理 & 分析、特徵值查詢 / 修改、特徵數據質量管理等功能
-
特徵申請： 用戶不再需要手動的修改配置文件來新增特徵，可直接通過 WEB 頁面申請，填寫必要的特徵信息，通過通用審批系統進行審批。
-
特徵上線： 用戶不在需要手動的發佈配置上線特徵，無論是新增的實時特徵還是離線特徵，審批通過後將自動化的上線，提升體驗和效率。
-
特徵管理： 特徵管理支持對特徵 meta 信息進行查詢和修改，包括特徵所屬的業務分類 (索引)、特徵類型、特徵負責人、給特徵打 tag 等等，業務可以方便的查詢需要特徵信息，避免重複的計算，方便各業務共享特徵。
- 特徵分析： 追蹤特徵的原始數據來源、計算過程、數據流路徑、最終的存儲信息等等, 可以追蹤特徵完整生產流程。
- 特徵值查詢 & 修改： 運營系統支持在 WEB 頁面查詢特徵值和修改特徵值。
- 特徵數據質量管理： 保障數據質量, 下一章節詳細講述。
數據質量保障
數據倉庫主要通過兩個方面來保障數據質量：特徵的標準化和數據空跑系統。
特徵標準化
特徵的標準化是保證數據倉庫數據質量的手段之一，標準化是指對數據倉庫中的特徵進行規範化處理，使得特徵能夠達到一致性、可重複性等標準，從而提高數據的可靠性和準確性。
對於新增實時 / 離線特徵, 數據倉庫制定了的特徵規範文檔，並按規範文檔的要求，特徵申請 / 管理頁面必須正確的補充完整特徵信息，如特徵類型、業務分類等等，後臺對每個特徵都會進行校驗，不符合規範的特徵無法錄入。
另外數據倉庫還提供了接入編程指導文檔，並給出完整的 C++ 編程實例，致力於提供標準化的編程最佳實踐。
數據空跑系統
離線特徵數據來自於業務離線計算在分佈式文件系統中生成數據文件，然後將文件上線。歷史上曾因爲生成的數據文件存在錯誤，存在錯誤的文件數據被上線到離線 KV，導致策略出現故障。爲了保障離線特徵數據的質量，數據倉庫設計了一套空跑系統，在上線前對數據文件進行檢查，避免存在問題的數據上線到現網。
數據空跑架構如上圖，離線特徵數據的上線也納入到了運營系統的管理中，整個的空跑流程如下：
-
業務發起數據上線，運營系統將數據上線到備用的離線 KV 表，也就是用於空跑的 KV 表。
-
打開空跑開關，按一定的比率採樣現網的讀請求，旁路到新增的讀 MQ 模塊，該模塊讀空跑表的數據，和當前現網做對比, 分析差異率。這裏採用的動態採樣， 如果表的 PV 高則採樣率低，PV 低則採樣率高或者 100% 採樣，避免請求量小的表無法進行空跑，而請求量大的表空跑流量太高又消耗太多資源。
-
計算和分析差異率，如果差異率超過了閾值，就自動的攔截數據上線，如果閾值檢查通過，就繼續後續的檢查流程，最終自動上線數據文件到現網離線 KV。
差異率示例會如下圖：詳細的展示了具體的差異細節：
完整的數據上線流程如下圖，空跑差異檢測通過後，需要檢查數據文件完整性，防止文件被修改或者覆蓋，最後數據再上線到現網數據倉庫系統，通知業務數據上線成功。如果中間任何一個步驟出錯將告警給業務負責人，提醒人工介入處理。
總結
數據倉庫將分散的特徵全部集中統一管理，提供統一的訪問接口，標準化每個一個特徵，建立了統一的規範，並且在此基礎保障了數據的質量，夯實了整個安全業務的基礎，助力一站式的數據 - 策略開發，極大的提升了安全對抗的效率，實現了數據價值的最大化。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/E0X7094kk9My7JTEOELjDg