本文由騰訊技術工程師remyliu分享，原題“微信萬億數據倉庫架構設計與實現”，本文收錄時有內容修訂和重新排版。
1、引言
沒有足夠的特征數據，安全策略將是“無根之木，無源之水”。
微信的安全數據特征倉庫應運而生，并成為整個安全業務的特征數據存儲中心，每天服務了萬億級的特征數據讀寫請求，為整個微信安全策略提供了可靠的數據支撐，是微信安全基石之所在。
然而，微信安全特征數據倉庫不僅僅是一個存儲中心，更是一個特征管理和數據質量管理的中心。
微信的安全數據特征倉庫在演進過程中，一直致力于提升特征管理能力和數據質量保障，實現了特征的管理、共享、分析和數據質量檢測等功能。
本文將介紹微信的安全數據特征倉庫的背景起源、技術演進、當前的架構設計和實踐，以及數據質量保證系統的實現。希望給中大型IM系統的安全數據特征倉庫的設計帶來啟發。
2、安全策略開發流程
安全業務的核心邏輯是在安全策略中實現的。整個的策略開發流程包括特征數據的收集，安全策略的編寫實現，和策略的反饋評估（如下圖所示）。
其中特征數據的收集是必不可少的環節，數據的質量將直接影響安全策略的效果。
特征數據收集主要包括：
傳統特征數據收集流程：
如上圖所示：在數據倉庫還未建立時，業務同學通過消費離線存儲mmdata和tdw接入數據，通過Flink流式計算或者自定義模塊對數據進行加工，計算出需要的特征，最終存儲到自行維護的KV，然后在安全策略平臺上編寫安全策略，讀取KV中的數據, 實現需要的安全邏輯。
3、為什么需要安全特征數據倉庫
前面提到在還未建立數據倉庫時，業務同學都按照自己的方式去存儲計算出的特征，大多通過自行申請部署KV來存儲（如下圖中的架構）：如A同學把部署一套KV集群，存儲特征到KV表中，B同學把特征存儲到同KV集群的不同表中，C同學又額外申請了另外一套KV集群存儲。
傳統安全后臺（各業務特征分散存儲）：
這種特征的分散存儲，導致業務同學只了解自己熟悉的特征，難以交流和共享，特征缺乏統一的管理，數據質量難以保證，不同的存儲方式，也導致特征訪問接口的混亂，業務系統的可靠性也難以保證。
針對上述的問題：我們希望把所有業務的特征，按統一的規范，建立統一的存儲，方便特征的共享、管理和維護、并建立數據質量保障體系, 為策略提供可靠的數據。所以我們需要開發數據倉庫。
問題和目標：
4、安全業務的后臺架構
當前，我們已經把所有的安全策略統一到安全策略平臺進行開發和管理，特征數據的接入和計算統一到了Flink實時計算平臺和特征平臺。
數據倉庫作為承上啟下的部分，是整個業務體系中不可或缺的部分。
總結一下它作用就是：
- 1）對上為在安全策略平臺上的安全策略提供了數據讀寫；
- 2）對下為實時計算平臺和特征平臺計算輸出的特征提供了存儲。
安全業務后臺架構：
5、安全特征數據倉庫的存儲選型
微信的安全業務特征數據主要有2種類型：
- 1）離線特征：用來滿足離線計算數據導入線上實時使用的需求（通常特征離線計算，定期的批量后臺上線，提供在線讀，但不支持實時寫入）；
- 2）實時特征：用來滿足實時的在線讀寫需求。
微信內部有多種非常成熟穩定的自研KV：實時讀寫KV（簡稱實時KV）、離線寫實時讀KV（簡稱離線KV）、***KV等等，這些KV已經在多個業務被驗證，有非常好的性能和可靠性，有團隊做長期的維護，為此數據倉庫的底層存儲采用了微信自研的KV。
微信自研的KV主要特點如下：
具體就是：
- 1）離線KV適合離線特征要求的場景：擁有非常好的讀性能，并且提供了版本管理功能，在處理有問題數據時可以非常方便的可以回退版本，采用這種KV存儲時，value一般是protobuf對象，新增特征時可以在pb中增加字段；
- 2）實時KV適合實時特征的場景：在線實時讀寫性能優秀，而且支持數據過期淘汰，該KV提供了類MySQL表的概念，KV表定義類似于一個MySQL表，而每一個安全業務特征剛好可以用表的一個字段表示。
6、數據倉庫的架構設計和演進
6.1統一存儲統一接口
數據倉庫第一個版本，針對特征存儲分散訪問接口混亂問題，首先部署了公共的實時KV/離線KV集群，并實現了一個接入層。新增特征和歷史特征放到公共的KV存儲集群，并且在接入層屏蔽了底層KV的細節，提供了統一的讀寫特征的接口。
數據倉庫架構1.0版：
接入層支持任意多個KV集群，支持多個表，為屏蔽KV的細節，接入層為每個特征分配唯一的標識<sceneid, columnid>，讀寫特征數據使用唯一標識進行，不需要關注KV類型和KV表ID，方便業務的接入使用。
統一接口：
接入層還實現配置管理、參數校驗、模塊校驗、權限校驗、流水上報、PV統計等功能。
6.2讀寫分離和多IDC同步
1）讀寫分離：數據倉庫的讀請求量遠遠多于實時寫入量，為了提高性能，減少讀寫之間的相互影響，接入層做了讀寫分離，將讀和寫接口拆分到兩個模塊。
2）數據多IDC同步：數據倉庫和業務都采用的是多IDC部署，為了不降低查詢性能，不希望業務跨IDC訪問存儲，所以底層的KV也是多IDC部署。這里就帶來一個問題，特征數據如何在多IDC的KV之間進行同步? 例如業務在上海寫入一個特征，希望在深圳也能讀到這個特征。
這里按特征類型進行分類處理：
- 1）離線特征數據同步：離線特征數據上線流程是通過離線計算在文件系統中生成一個文件，然后將文件導入到離線KV, 而離線KV支持多個IDC共享同一份數據，數據文件只需要生成一份，所有IDC的離線KV拉取同一個文件，新數據最終能同步到所有IDC上；
- 2）實時特征數據同步：實時特征的同步采用微信自研的分布式隊列組件，該組件提供了高可靠、高可用、高吞吐、低延時的數據消息隊列服務。數據倉庫寫接入模塊在寫入數據時，同時將數據寫一份到分布式隊列，使用隊列做跨IDC的數據同步，在其他IDC啟動進程消費隊列中的數據，寫入到本IDC的實時KV，實現實時特征數據的同步。
數據倉庫架構2.0版：
6.3異步寫和替代分布式隊列
1）異步寫入：前一個版本中實時特征是同步寫入，影響業務的性能，業務希望是異步寫入。
2）替代分布式隊列：前一個版本中分布式隊列采用的是公共的集群，眾多業務使用，出現過數據倉庫受干擾影響特征數據同步。
為此：在數據倉庫中新增一個異步消息隊列模塊寫MQ，用于異步寫入。和分布式隊列相比，MQ更輕量，而且MQ我們可以自行維護，更可控。所以新架構中通過MQ實現實時特征的多IDC數據的同步，替代了分布式隊列，保證數據同步不受其他業務影響。
數據倉庫架構3.0版：
6.4運營系統
前面3個版本解決了特征存儲分散、讀寫接口不統一、數據同步、讀寫性能問題，但是特征的上線依然采用的是配置發布上線的方式，效率依然低效。
更重要的是特征缺乏統一的管理，共享困難，難以滿足業務的需求。
業務常常也有各種疑問：
為此數據倉庫新增運營系統模塊，實現了特征申請、特征上線、特征管理&分析、特征值查詢/修改、特征數據質量管理等功能。
數據倉庫架構4.0版：
1）特征申請：
用戶不再需要手動的修改配置文件來新增特征，可直接通過WEB頁面申請，填寫必要的特征信息，通過通用審批系統進行審批。
2）特征上線：
用戶不在需要手動的發布配置上線特征，無論是新增的實時特征還是離線特征，審批通過后將自動化的上線，提升體驗和效率。
3）特征管理：
特征管理支持對特征meta信息進行查詢和修改，包括特征所屬的業務分類（索引）、特征類型、特征負責人、給特征打tag等等，業務可以方便的查詢需要特征信息，避免重復的計算，方便各業務共享特征。
▲ 特征管理頁面
4）特征分析：
追蹤特征的原始數據來源、計算過程、數據流路徑、最終的存儲信息等等, 可以追蹤特征完整生產流程。
▲ 特征分析頁面
5）特征值查詢&修改：運營系統支持在WEB頁面查詢特征值和修改特征值；
▲ 特征值查詢頁面
6）特征數據質量管理：保障數據質量, 下一章節詳細講述。
7、數據質量保障手段1：安全特征標準化
數據倉庫主要通過兩個方面來保障數據質量：特征的標準化和數據空跑系統。本節分享特征的標準化。
特征的標準化是保證數據倉庫數據質量的手段之一，標準化是指對數據倉庫中的特征進行規范化處理，使得特征能夠達到一致性、可重復性等標準，從而提高數據的可靠性和準確性。
對于新增實時/離線特征：數據倉庫制定了的特征規范文檔，并按規范文檔的要求，特征申請/管理頁面必須正確的補充完整特征信息，如特征類型、業務分類等等，后臺對每個特征都會進行校驗，不符合規范的特征無法錄入。
另外：數據倉庫還提供了接入編程指導文檔，并給出完整的C++編程實例，致力于提供標準化的編程最佳實踐。
8、數據質量保障手段2：數據空跑系統
離線特征數據來自于業務離線計算在分布式文件系統中生成數據文件，然后將文件上線。
歷史上曾因為生成的數據文件存在錯誤，存在錯誤的文件數據被上線到離線KV，導致策略出現故障。
為了保障離線特征數據的質量，數據倉庫設計了一套空跑系統，在上線前對數據文件進行檢查，避免存在問題的數據上線到現網。
數據空跑架構：
數據空跑架構如上圖所示，離線特征數據的上線也納入到了運營系統的管理中。
整個的空跑流程如下。
1）業務發起數據上線：運營系統將數據上線到備用的離線KV表，也就是用于空跑的KV表；
2）打開空跑開關：按一定的比率采樣現網的讀請求，旁路到新增的讀MQ模塊，該模塊讀空跑表的數據，和當前現網做對比, 分析差異率。這里采用的動態采樣， 如果表的PV高則采樣率低，PV低則采樣率高或者100%采樣，避免請求量小的表無法進行空跑，而請求量大的表空跑流量太高又消耗太多資源。
3）計算和分析差異率：如果差異率超過了閾值，就自動的攔截數據上線，如果閾值檢查通過，就繼續后續的檢查流程，最終自動上線數據文件到現網離線KV。
差異率示例會如下圖（詳細的展示了具體的差異細節）：
離線特征數據上線完整流程：
完整的數據上線流程如上圖所示：空跑差異檢測通過后，需要檢查數據文件完整性，防止文件被修改或者覆蓋，最后數據再上線到現網數據倉庫系統，通知業務數據上線成功。如果中間任何一個步驟出錯將告警給業務負責人，提醒人工介入處理。
9、本文小結
微信后臺安全特征數據倉庫將分散的特征全部集中統一管理，提供統一的訪問接口，標準化每個一個特征，建立了統一的規范。
并且在此基礎保障了數據的質量，夯實了整個安全業務的基礎，助力一站式的數據-策略開發，極大的提升了安全對抗的效率，實現了數據價值的最大化。
10、相關資料
[1] 探討組合加密算法在IM中的應用
[2] IM聊天系統安全手段之通信連接層加密技術
[3] IM聊天系統安全手段之傳輸內容端到端加密技術
[4] 理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）
[5] 微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解
[6] 移動端安全通信的利器——端到端加密（E2EE）技術詳解
[7] 通俗易懂：一篇掌握即時通訊的消息傳輸安全原理
[8] 基于Netty的IM聊天加密技術學習：一文理清常見的加密概念、術語等
[9] 手把手教你為基于Netty的IM生成自簽名SSL/TLS證書
11、微信團隊的其它技術文章
《IM全文檢索技術專題(一)：微信移動端的全文檢索優化之路》
《IM全文檢索技術專題(二)：微信移動端的全文檢索多音字問題解決方案》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程?；钇?》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅》
《社交軟件紅包技術解密(十一)：解密微信紅包隨機算法(含代碼實現)》
《微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路》
《企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等》
《IM全文檢索技術專題(四)：微信iOS端的最新全文檢索技術優化實踐》
《微信團隊分享：微信后臺在海量并發請求下是如何做到不崩潰的》
《微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等》
（本文已同步發布于：http://www.52im.net/thread-4374-1-1.html）