指標圈選在資料應用平臺的實現

1

業務背景

58營銷平臺從58主戰網站或其他來源收集到的聯絡過58的企業，可能聯絡58的服務付費的企業使用者，對於這樣的企業資訊在營銷平臺中稱為商機。一個商機透過一系列過濾補充及數倉計算後入到營銷的數倉中。其中商機包含很多對應屬性，類似於：商機名稱、企業所在行業、企業規模、企業地址、商機最後聯絡時間、商機近7天/30天/60天/90天聯絡次數。

平臺相關運營依據自定義配置規則，條件組合選出所需商機，對所選出的商機完成所需操作。類似於：商機打標籤(商機增加標籤標識，銷售人員依據標籤選出商機做對應跟進)、商機入沉寂(業務系統中資料狀態轉為沉寂，減少跟進)、商機迴流(將沉寂庫商機轉入公共庫使銷售人員持續跟進)......等等類似操作。

針對以上需求及場景，開發資料應用平臺基於數倉的商機表輸出的es索引，配置自定義資料圈選規則，並對圈選出的指定商機建立資料應用任務。資料應用任務根據場景配置呼叫時間視窗等規則定時呼叫，處理後的資料應用至各個業務場景。

2

平臺架構

資料應用平臺整體架構如圖所示：

• 應用層：使用者配置任務規則、建立標籤等與互動層直接操作

• 配置層：配置圈選規則時用到的指標欄位配置、對應字典配置、圈選所查詢的資料集索引配置、任務配置的具體執行動作配置

• 互動層：標籤建立，按設定的在業務系統中展示的位置設定應用位置並建立業務標籤；任務建立，建立的標籤在打標任務時選擇，建立的任務按配置的執行時間段執行；任務排程及任務檢視為具體執行任務及監控

• 執行層：建立任務時配置圈選資料的規則，組裝SQL；任務執行時按照配置的規則生成的SQL查詢資料並呼叫 打標/清洗介面；資料對比差集計算為打標時計算前一天結果與當天圈選結果差集

• 儲存層：資料圈選所用資料集使用es/mysql；差集計算使用spark查詢hive得到；任務執行佇列儲存在redis的list中；mysql中持久化相關任務圈選規則及其他配置

3

核心功能與整體流程

3.1 資料圈選

對於這樣的條件配置資料圈選，運營及業務方根據es表所輸出的欄位查出所需資料，並對圈選出的資料做對應操作的任務建立，則涉及到where條件的拼接。

本身單表的多個單指某個欄位的條件查詢，其實是個以 and/or為頭的二叉樹，兩邊是表示式。類似於像商機（企業資訊）的這種查詢，查詢企業名稱(customer)包含 裝修 或包含 餐飲，並且產品線(productLine)為招聘，並且最後發帖時間(lastTime)為7天以內，則寫SQL會表達為==>

(customer like '%裝修%' or customer like '%餐飲%') and productLine = 56 and lastTime >= DATE_FORMAT(DATE_SUB(now(),INTERVAL 1 DAY),'%Y-%m-%d')

要表達這樣一個關係，和前端商定對應的協議和引數，是用到了json形式中間包含陣列屬性來做到，同時涉及到不同型別的欄位處理，程式中再具體用到策略模式在不同實現類中處理等

3.2 任務排程

對於任務的排程，此處涉及到使用者建立的任務需要在一天的不同時間段執行，並且可能在一段時間內每天執行或每週執行。此時便涉及到將任務下發到叢集各個節點並行執行，並且多工在一定時間內很多的情況下，需排隊等待機器資源。想到過的解決方案

• 用公司封裝的wjob(xxl-job)元件的分片廣播策略完成

• 把任務當成訊息作為訊息佇列實現

此兩種方式的實現會遇到不同程度的問題，xxl-job來分發任務分片廣播策略會發到各個節點但不會是同一時間會有時間和資源上的浪費；訊息佇列則因為這種場景會遇到任務少量並且長時間執行的情況不完全使用訊息傳送的場景。同時等待過程中會需要觀察監控任務，佇列中的資料不容易完整檢視。

針對此場景，採用redis的list作為佇列存放任務，wjob的任務每小時掃描當前時間可放入佇列的任務資料，封裝放入list。每個節點的機器開啟每分鐘的定時任務pop佇列的第一個並執行。這樣放在redis的list中的任務資料，隨時使用lrange命令檢視，並且控制好命令下標做到分頁檢視。此方式和開源元件resque的實現方式不謀而合。

3.3 整體功能流程

• 任務不同頻率處理-一次性/每日/每週

• 採用策略模式處理對應每天job執行掃描到對應任務時判斷是否需要放入佇列

• 選擇資料來源（es、mysql、...）時配置在表中，透過模板方法執行相應步驟

• 連線資料來源-獲取配置sql-查詢資料-執行

• 執行呼叫資料介面過程，不同動作對應引數透過同一介面的map型別 ext額外引數欄位控制

• 下游對應不同業務時，不同主題資料欄位不同，透過ext的map引數擴充套件

• 執行動作透過表配置，並對應策略模式不同實現類對應不同呼叫方式

4

難點與迭代

4.1 商機打標-大資料量資料集對比

商機打標操作為當天任務配置的圈選條件查出的商機資料與前一天的做對比操作

• 對比結果中需新增的做對應操作，需解綁的做解綁操作

• 少量資料的情況下，100萬以下時在記憶體中對比，總量300萬以上預計佔用記憶體接近10g

• 大資料量時，使用配置的查詢條件生成的hive_sql，透過spark任務查詢商機hive表與標籤商機繫結關係hive表，對比結果存為2張表存入mysql

• 操作商機量計數與任務關係一張表

• 商機id與標籤對應關係的一張表，需新增及需解綁的資料在此表中

問題解決方案與迭代

• 資料側

• 啟動spark環境

• 獲取所有任務資訊，遍歷所有任務，每個任務提交一個spark sql job

• 查詢任務對應規則，生成對於過濾sql，獲得任務圈選商機
  

• 任務圈選商機 和 標籤繫結商機關聯，獲得 標籤新增商機 和解綁商機 

• 結果寫入對應的表
  

• 結果表寫入mysql

後端處理

• 讀取資料同學spark任務輸出的mysql表或記憶體中自主計算差集透過任務類別標識等判斷
  

• 讀取spark任務輸出的mysql表資料時分頁處理

• 分開讀取需新增標籤、解綁標籤

• 讀取表時使用不同條件讀取並處理

• 分頁處理一批後清除記憶體中相應list，節省記憶體

• 生成hive_sql 的where條件時，類似map介面等型別資料相應按sql配置生成時的策略模式實現類中處理
  

4.2 資料呼叫介面限流處理

問題分析

• 圈選商機->商機對應呼叫下游介面->介面設定商機狀態至 沉寂庫/公海/商機刪除...
  

• 呼叫下游介面時需限流，每分鐘只能呼叫2000次，超出介面呼叫上限時，scf雲平臺會限流拋棄請求並報警，導致資料未處理
  

• 相對應的，資料應用平臺作為上游呼叫方，對各個場景做主動限流，每分鐘只呼叫對應量資料，超出部門排隊到下一分鐘呼叫
  

功能迭代與問題解決

• 使用redis+lua指令碼作為限流key計數，傳送請求前計數並查詢

• 超出計數時排隊等待至下一分鐘

• 出現相應問題：

• 統計每分鐘計數，例：一分鐘的第50秒開始執行任務，執行2000條到下一分鐘

• 此時到下一分鐘後當前分鐘計數為0，執行2000條

• 實際情況則前一分鐘50秒至當前分鐘10秒見，20秒呼叫介面4000次，超出限流量

• 針對此問題使用滑動視窗計數

• 每10秒一個視窗，每次統計限流量時，統計當前視窗+前5個視窗，合計60秒6個視窗

5

總結

整體功能對資料圈選在業務方自定義配置下建立任務並定時調整資料，中間經過迭代對任務執行排程及資料對比等功能根據問題調整。整體達到預期，後續繼續接入新的資料應用業務時持續迭代改進功能。