微信萬億數據倉庫架構設計與實現

沒有足夠的特征數據，安全策略將是"無根之木，無源之水"。微信安全數據倉庫應運而生，成為整個安全業務的特征數據存儲中心，每天服務了萬億級的特征數據讀寫請求，為整個微信安全策略提供了可靠的數據支撐，是微信安全基石之所在。
然而，微信安全數據倉庫不僅僅是一個存儲中心，更是一個特征管理和數據質量管理的中心。
在演進過程中，數據倉庫一直致力於提升特征管理能力和數據質量保障，實現了特征的管理、共用、分析和數據質量檢測等功能。
本文將介紹安全數據倉庫的起源、演進、當前的架構設計和數據質量保證系統的實現。

業務背景

安全策略開發流程

安全業務的核心邏輯在安全策略中實現。整個的策略開發流程包括特征數據的收集，安全策略的編寫實現，和策略的反饋評估。其中特征數據的收集是必不可少的環節，數據的質量將直接影響安全策略的效果。

特征數據收集主要包括：數據接入、特征的計算、特征的存儲。

在數據倉庫還未建立時，業務同學通過消費離線存儲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，導致策略出現故障。為了保障離線特征數據的質量，數據倉庫設計了一套空跑系統，在上線前對數據文件進行檢查，避免存在問題的數據上線到現網。

數據空跑架構如上圖，離線特征數據的上線也納入到了運營系統的管理中，整個的空跑流程如下：

1. 業務發起數據上線，運營系統將數據上線到備用的離線KV表，也就是用於空跑的KV表。

2. 打開空跑開關，按一定的比率採樣現網的讀請求，旁路到新增的讀MQ模塊，該模塊讀空跑表的數據，和當前現網做對比, 分析差異率。這裡採用的動態採樣， 如果表的PV高則採樣率低，PV低則採樣率高或者100%採樣，避免請求量小的表無法進行空跑，而請求量大的表空跑流量太高又消耗太多資源。

3. 計算和分析差異率，如果差異率超過了閾值，就自動的攔截數據上線，如果閾值檢查通過，就繼續後續的檢查流程，最終自動上線數據文件到現網離線KV。

差異率示例會如下圖：詳細的展示了具體的差異細節：

完整的數據上線流程如下圖，空跑差異檢測通過後，需要檢查數據文件完整性，防止文件被修改或者覆蓋，最後數據再上線到現網數據倉庫系統，通知業務數據上線成功。如果中間任何一個步驟出錯將告警給業務負責人，提醒人工介入處理。

總結

數據倉庫將分散的特征全部集中統一管理，提供統一的訪問介面，標準化每個一個特征，建立了統一的規範，並且在此基礎保障了數據的質量，夯實了整個安全業務的基礎，助力一站式的數據-策略開發，極大的提升了安全對抗的效率，實現了數據價值的最大化。

作者：remy

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Design-and-Implementation-of-WeChat-Trillion-Data-Warehouse-Architecture.html