蘇寧精準營銷之排重服務優化實踐
精準營銷排重系統主要為集團八大產業所有會員的營銷活動的推廣進行排重服務，根據不同的規則進行實時排重，增加使用者體驗，定位為精準營銷核心平臺之一。在每次集團雙十一等大促活動中，各個產業活動所包含客群的促銷資訊會涉及到大量重疊會員資訊，如果不通過排重系統進行訊息過濾處理，客戶接受到大量促銷資訊，對客戶產生騷擾而引起客戶反感，降低體驗，進而會產生促銷反面效果，如果所有符合條件的會員都發送多個促銷資訊也會增加運營成本。
客戶營銷主要應用場景包括：線上營銷、離線營銷、各終端（紅孩子、蘇寧小店、蘇寧易購、PPTV、體育等）推送、各渠道（PUSH、簡訊、郵件等）觸達等。以上所有相關場景的資料交叉、實時排重的處理，將排重處理後的營銷會員資料傳送到待發送系統達到營銷活動的推送。
排重服務定位
精準營銷排重服務屬於營銷執行平臺核心元件，作用於營銷活動收尾環節，對營銷執行平臺中的營銷事件、營銷標籤、使用者特徵計算符合條件的使用者進行排重服務，將排重後的資料通過不同的渠道推送到各個終端中；通過排重服務能夠精準的對會員進行活動營銷，減少對使用者的多次騷擾，增加使用者體驗；通過排重服務能夠過濾掉黃牛會員資訊，減少營銷成本。
排重服務分為已立項排重、已執行排重
已立項排重：客戶群和預計傳送記錄表進行排重
已執行排重：客戶群和歷史傳送記錄表進行排重
排重服務對不同渠道的會員進行歷史排重，對同渠道的會員進行立項排重，對所有業務場景進行資料的交叉、實時排重等處理達到各種業務場景、各渠道的精準推送。如下圖：
排重前世
系統初期資料排重實現通過資料庫表關聯排重。通過表sql關聯進行排重隨著資料量的增加效率隨之降低，隨著業務的發展,活動涉及到的排重資料總量達到數十億以上，雖然採取了分庫分表策略提升處理能力,但是以表關聯進行排重方式已經不能支撐業務發展。而且待發送活動需要在前一日進行排重生成檔案上傳到FTP中，無法做到實時精準排重。
原有系統架構排重處理如下圖：
缺點：
- 資料庫效能：
多個業務場景進行高併發排重，資料庫存連線數固定，對歷史資料等資料的排重需要進行多表關聯，業務場景排重後的資訊還要持久化到表中，導致讀寫操作頻繁，致使資料庫的CPU、IO、網路等開銷增高，會出現資料庫宕機問題。
- 排重效率低：
歷史資料和實時資料分部在不同的表中，如果每張表資料量達到百萬級別，進行表關聯排重效率低下。平均一次排重操作耗費10分鐘以上。
- 排重無法併發處理
業務場景排重需要相互交叉排重，否則會出現同一使用者推送多次營銷類資訊，降低使用者體驗。資料庫排重需要將不同的活動進行持久化操作，只有在持久化後才能夠進行相互交叉排重，多個業務場景排重只能序列。
- 排重實時性差
資料庫排重效率低下和無法高併發處理，排重在傳送前日一日提前生成，無法將當日符合活動的會員進行篩選排重，無法達到實時性。
- 傳送準確性差
業務場景在排重後需要生成待發送的檔案，上傳到指定的FTP伺服器目錄中，傳送系統需要等待排重生成檔案後才能執行後續業務。如果排重生成的檔案大，傳送系統需要先進行檔案解析，傳送系統如果檔案解析出現失敗，會導致部分會員的營銷資料未傳送，會導致營銷效果大打折扣。
- 可擴充套件性差
從架構上應用資料庫進行排重處理，無法進行系統的橫向擴充套件。如果進增加資料庫機器進行分庫處理，業務邏輯處理單元需要對資料增刪改查操作進行分庫分表處理。不利於進行持續擴充套件。
- 持久化資料上限
依靠資料庫的儲存能力，資料庫容量已經達到瓶頸，如果進行機器記憶體等擴容也無法從根本上解決大資料量的持久化儲存。
排重今生
隨著蘇寧各個產業的發展，營銷業務場景的激增，涉及到的排重資料總量億級以上，尤其是在大促期間資料總量在幾十億級以上。通過以往大促的資料量的預估，排重系統優化方案為引入引入快取系統，應用ES、redis進行實時排重處理，依靠Hbase對資料儲存持久化，依靠Hive進行報表和圖形化系統的統計展示，依靠kafka topic 進行排重訊息資料實時推送。
從架構上設計如下：
- ES叢集
Elasticsearch（ES）是一個分散式文件資料庫，其中每個欄位均可被索引，而且每個欄位的資料均可被搜尋，ES能夠橫向擴充套件至數以百計的伺服器儲存以及處理PB級的資料。可以在極短的時間記憶體儲、搜尋和分析大量的資料。
通過ES特性，設立ES叢集，ES叢集中分配為不同的小叢集，每個叢集通過Shard進行分配，形成一個大的 ES叢集，從架構上解決了單索引量大與查詢時跨多 shards 後資料聚集到單 ES 例項導致此ES宕機等問題。
如下圖：
- REDIS叢集
Redis是當前比較熱門的NOSQL系統之一，它是一個開源的使用ANSI c語言編寫的key-value 儲存系統（區別於MySQL的二維表格的形式儲存。）。Redis讀取的速度是110000次/s，寫的速度是81000次/s，支援多種資料結構：string（字串）；list（列表）；hash（雜湊），set（集合）；zset(有序集合),持久化，主從複製（叢集）。針對redis的特性，對不同的排重場景分配不同的redis叢集，每個叢集通過shard進行資料分配，從架構上解決了不同排重場景資料的高併發處理排重達到資料處理的高效性、資料儲存的分散性。對每臺redis伺服器設定一主一從配置，redis的主從配置保證資料的安全性。
如下圖：
- 持久化
Hbase是一種nosql資料庫，是一種分散式資料庫系統,可以提供資料的實時隨機讀寫,資料的最終持久化儲存是基於hdfs的，特點是可以隨時實現線上通過廉價的PC擴容，將歷史排重記錄等資訊通過HBASE進行永久儲存，不會存在 儲存容量瓶頸問題。
- 報表
hive是基於Hadoop的一個ofollow,noindex" target="_blank">資料倉庫 工具，可以將結構化的資料檔案對映為一張資料庫表，並提供簡單的sql查詢功能，可以將sql語句轉換為MapReduce任務進行執行，可以為報表系統展示歷史資料業務場景的排重情況。
- 訊息推送
根據不同的渠道和終端，建立不同的kafka topic，在業務場景排重完成後，通過kafka實時傳送到各個渠道和終端系統中，保證了排重資料傳送的準確性和實時性，不再出現傳送方FTP檔案等待檔案上傳後再進行剩餘業務處理。使用 kafka 也解決了外圍系統的耦合，在設計上每個 kakfa topic 的 partition 均按支援 1萬 TPS設計。
如下圖：
優點：
- 效能
引用快取系統，目前系統架構支援縱向橫向擴充套件，不存在效能問題。
- 效率
在排重中使用ES作為歷史資料來源，針對歷史在不同的ES叢集中根據索引對資料進行聚合分析、排重、篩選形成歷史資料的初步排重，排除掉百分之70以上的資料量,ES排重後的資料，與REDIS中儲存的實時熱點等資料進行交 叉排重達到排重效果。
- 高併發
各種業務場景的排重可以啟動執行緒同時進行排重操作，因為ES與redis以叢集形式部署，可以很好的支撐多業務場景同事進行排重處理，在業務場景排重後通過rediskey進行交叉排重。
- 實時性、準確性
通過高併發實時處理的排重資料，通過kafka topic傳送到不同的渠道和終端，各發送系統通過實時消費處理資料進行營銷資料的傳送，避免出現解析檔案失敗出現部分營銷資料未傳送的情況，達到了實時性和準確性。
- 可擴充套件性
通過叢集和shard方式部署的ES和redis系統，可以達到系統的橫向擴充套件，不需要對現有業務邏輯進行程式碼處理，直接生效。
資料儲存結構的華麗轉身
資料儲存由原來的db儲存轉換成redis、es、Hbase等進行儲存處理，有效的解決了高併發、大資料場景下資料處理能力，實現了資料的永久儲存。
Redis叢集通過shard進行資料有效的將資料分配到不同的機器中，減少key儲存的大小可以應用redis的key的聚合和合並減少key處理的複雜度，增加處理效率。
ES資料的shard分配解決了單索引資料量大，進行排重、篩選、交叉提高執行效率和跨索引引起的宕機問題。
總結
根據蘇寧以往大促經驗和資料增長點,在雙十一中各個產業的促銷活動要對所有的會員使用者進行營銷，各種場景進行排重的資料達到數十億以上，通過Redis的高讀寫速度、所有操作的原子性、多重資料結構和ES可以在極短的時間記憶體儲、搜尋和分析大量的資料的能力可以很好的支援排重系統的高併發排重。通過ES的高可用和可擴充套件而生，可以通過購置效能更強的伺服器或者升級硬體來完成系統擴充套件，稱為垂直或向上擴充套件（Vertical Scale/Scaling Up）。另一方面，也可以增加更多的伺服器來完成系統擴充套件，稱為水平擴充套件或者向外擴充套件（Horizontal Scale/Scaling Out）。通過向叢集中新增更多的節點來分擔負載，增加可靠性,ES天生就是分散式的：它知道如何管理多個節點來完成擴充套件和實現高可用性,在後期持續擴充套件中應用不需要做任何的改動。現有的精準營銷之排重服務系統能夠支援叢集機器的橫向縱向擴充套件，能夠很好的支撐業務資料量的增長，能夠更加高效、實時、精準的資料排重服務，也能夠根據資料的永久儲存，追溯到歷史資料，提供為報表系統的更加準確、更加全面的報表資料，為運營人員進行促銷活動效果分析。
作者簡介
於海濤，蘇寧易購IT總部技術經理，主要負責精準營銷產品開發部技術研發工作。同時，參與 818、雙 11等大促保障、系統穩定和效能優化工作。在蘇寧的任職期間，經歷了精準營銷產品線產品的研發和系統的調優等工作。