一 背景
在營銷場景下，演算法同學會對廣告主提供個性化的營銷工具，幫助廣告主更好的精細化營銷，在可控成本內實現更好的ROI提升。我們在這一段時間支援了多個即時業務場景，比如出價策略的即時化預估、關鍵詞批次服務同步、即時特徵等場景，瞭解到業務側同學來說，針對ODPS場景來說大部分可以靈活使用，但對於Blink使用還有不足，我們這裡針對場景積累了一些經驗，希望對大家有一些幫助。
二 技術選型
為什麼要選擇Blink？大部分離線場景如果對於時效性沒有要求，或者資料來源是Batch模式的，非Streaming的(比如TT、SLS、SWIFT、順序)等，這個場景的話選擇ODPS就比較不錯；總體來說，資料來源是即時的(如TT/SLS/SWIFT)、需要順序讀取ODPS、對時效性要求高的場景，選擇Blink是比較好的。
Blink目前也是支援Batch模式和Steaming模式。Batch模式是指有固定的起始時間和結束時間， 相比ODPS而來，他最大的優勢是提前申請資源，可是獨佔的，這樣可以保障時效性；Streaming模式就是傳統意義上的即時消費，可實現毫秒級的處理。
從開發模式上看，主要分為Data Stream模式，類似於ODPS MR；第二種是SQL模式；從易用性角度看，SQL無疑是使用成本最低的；但對於複雜場景，Data Stream的掌控能力也是最好的，可靈活定義各類cache和資料結構，以及同時支援多類場景。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
三 主要場景
1 即時replay出價策略評估
業務背景
Replay系統是一套集線上競價日誌蒐集、結構化、後續處理的模擬系統。該系統記錄了直通車線上引擎在召回之後的競價資訊，主要涵蓋了線上的召回、出價、打分等佇列資訊。結合排序以及扣費公式，可以利用該日誌實現對線上競價環境的模擬。簡單來說，就是可以評估bidword上如果當時採用其他的出價，會帶來什麼樣的結果。透過replay系統，演算法團隊和廣告主可以在線上AB測試之前，利用離線流量預估使用者策略修改之後帶來的效果，這樣可以儘可能地減少策略的修改帶給線上的影響，讓結果變得更加可控。同時在進行負向策略測試的過程中，可以儘可能地減少對大盤的收益影響。
演算法團隊希望基於線上精排召回日誌實現業務側多種出價策略評估，回放1天內取樣日誌(10億資料)，在出價策略上評估，並支援ad的即時下線，避免下線ad對出價策略有影響，並且預期希望10億資料量在1-2個小時內跑完。
主要挑戰
-
1千萬物料資料如何載入； -
高qps(100萬)下線ad的即時同步；
-
業務側解耦，整個即時job鏈路如何實現和業務解耦
解決方案
-
物料資料載入：直接在blink啟動時載入所有資料，避免高qps情況下，對igraph訪問造成壓力；另外採用廣播模式，僅一次載入，每個節點都可以使用，避免多次載入odps資料；
-
下線的ad資訊採用分桶的方式存入到IGraph中，並週期性cache方式全量讀取全量下線ad，將查詢的200W+qps控制在1w左右，並使用RateLimit限流元件控制訪問併發，把IGraph併發控制限制在40萬左右，實現整體流量平滑；
-
整體即時工程框架，預留UDF介面，讓業務側僅實現SDK即可，其他工程效能、併發、限流、埋點等邏輯內部實現即可，支援工程框架和演算法策略Replay解耦。
總結
基於此業務需求，我們基於blink streaming Batch模式的靈活能力，實現了對tt資料固定開始和結束時間的資料處理。沉澱了讀寫tt元件 ，ODPS元件，iGraph元件和埋點元件 ，這些沉澱的元件很好地支援了後續相似業務的作業開發，同時元件作為之後作業產品化提供了基礎能力。
2 即時特徵
業務背景
隨著B端演算法發展，模型升級帶來的增量紅利越來越少，需要考慮從客戶即時資訊方面進一步捕捉使用者意圖，更全面、更即時的挖掘潛在需求，從B端視角進一步提升增長空間，基於線上使用者行為日誌產出使用者行為即時特徵，演算法團隊使用即時資料改進線上模型。
基於此需求我們產出一條使用者即時特徵產出鏈路，透過解析上游A+資料來源獲取使用者即時特徵，即時特徵主要包含以下幾種：
-
獲取使用者近50條特徵資料值，併產出到igraph中。 -
輸出具有某種特徵的使用者id，並按照分鐘時間聚合
-
輸出某種特徵近1小時的和、均值或者數目
主要挑戰
-
即時特徵資料開發數量非常多，對於每個特徵資料都需要開發即時資料鏈路、維護，開發成本、運維成本較高，重複造輪子；
-
特徵資料開發要求開發者瞭解：
-
資料來源頭，會基於事實資料來源進行ETL處理； -
計算引擎，flink sql維護了一套自己的計算語義，需要學習瞭解並根據場景熟練使用； -
儲存引擎，即時資料開發好需要落地才能服務，故需要關係儲存引擎選型，例如igraph、hbase、hologres等； -
查詢最佳化方法，不同儲存引擎都有自己的查詢客戶端、使用及最佳化方法，故要學習不同引擎使用方法。
解決方案
從產品設計角度，設計一套即時平臺能力，讓開發即時特徵跟在odps開發離線表一樣簡單。產品優勢是讓使用者只需要懂SQL就可以開發即時特徵：
-
不需要了解即時資料來源
-
不需要了解底層儲存引擎
-
只用sql就可以查詢即時特徵資料，不需要學習不同引擎查詢方法
整個即時開發產品聯動極光平臺、dolphin引擎、blink引擎和儲存引擎，把整個流程串聯打通，給使用者提供端到端的開發體驗，無需感知跟自己工作無關的技術細節。
相關平臺介紹：
Dolphin智慧加速分析引擎：Dolphin智慧加速分析引擎源自阿里媽媽資料營銷平臺達摩盤(DMP)場景，在通用OLAP MPP計算框架的基礎上，針對營銷場景的典型計算（標籤圈人，洞察分析）等，進行了大量儲存、索引和計算運算元級別的效能最佳化，實現了在計算效能，儲存成本，穩定性等各個方面的大幅度的提升。Dolphin本身定位是加速引擎，資料儲存和計算運算元依賴於底層的odps, hologres等引擎。透過外掛形式，在hologres中，完成了運算元整合和底層資料儲存和索引的最佳化,實現了特定計算場景計算效能和支撐業務規模的數量級的提升。目前Dolphin的核心計算能力主要包括：基數計算核心，近似計算核心，向量計算核心，SQL結果物化及跨DB訪問等。Dolphin同時實現了一套SQL轉譯和最佳化能力，自動將原始使用者輸入SQL，轉化成底層最佳化的儲存格式和計算運算元。使用者使用，不需要關心底層資料儲存和計算模式，只需要按照原始資料表拼寫SQL，極大的提升了使用者使用的便利性。
極光消費者運營平臺：極光是面向營銷加速場景的一站式研發平臺，透過平臺產品化的方式，可以讓特色引擎能力更好賦能使用者。極光支援的特色場景包含超大規模標籤交併差(百億級標籤圈選毫秒級產出)、人群洞察(上千億規模秒級查詢)、秒級效果歸因(事件分析、歸因分析)、即時和百萬級人群定向等能力。極光在營銷資料引擎的基礎上提供了一站式的運維管控、資料治理以及自助接入等能力，讓使用者使用更加便捷；極光沉澱了搜推廣常用的資料引擎模板，包含基數計算模板、報表模板、歸因模板、人群洞察模板、向量計算模板、近似計算模板、即時投放模板等，基於成熟的業務模板，讓使用者可以零成本、無程式碼的使用。
根據目前的業務需求，封裝了即時資料來源和儲存資料來源
使用舉例：
--- 註冊輸入表create table if not exists source_table_name( user_id String comment '', click String comment '', item_id String comment '', behavior_time String comment '') with ( bizType='tt', topic='topic', pk='user_id', timeColumn='behavior_time');---- 建立輸出表create table if not exists output_table_name ( user_id STRING click STRING) with ( bizType='feature', pk='user_id');實現即時特徵運算元：
concat_id:
-
含義：從輸入表輸入的記錄中，選取1個欄位，按照timestamps倒序排成序列，可以配置引數按照id和timestamp去重，支援使用者取top k個數據
使用舉例：
-- 使用者最近點選的50個商品idinsert into table ${output_table_name}select nickname, concat_id(true, item_id, behavior_time, 50) as rt_click_item_seqfrom ${source_table} group by user_id;-- 1分鐘內最近有特徵行為使用者id列表insert into table ${output_table_name}select window_start(behavior_time) as time_id, concat_id(true, user_id) as user_id_listfrom ${source_table} group by window_time(behavior_time, '1 MINUTE');sum、avg、count：
-
含義：從輸入表輸入的記錄中，選取1個欄位，對指定的時間範圍進行求和、求平均值或計數
使用舉例
-- 每小時的點選數和曝光數insert into table ${output_table_name}select user_id, window_start(behavior_time) as time_id, sum(pv) as pv, sum(click) as clickfrom ${source_table} group by user_id,window_time(behavior_time, '1 HOUR');總結
基於B端演算法的即時特徵需求，沉澱了一套基於blink sql + udf實現的即時特徵產出系統，對使用者輸入的sql進行轉義，在Bayes平臺生成bink SQL Streaming任務，產出即時特徵資料存入iGraph當中，沉澱了blink 寫入igraph元件，concat_id運算元、聚合運算元等基礎能力，為後續Dolphin streaming 即時特徵產出系統打下了基礎，支援後續多種特徵運算元擴充套件方式，快速支援此類使用者需求。
3 關鍵詞批次同步
業務背景
每天有很多商家透過不同渠道加入直通車；而在對新客承接方面存在比較大的空間。另一方面，對於系統的存量客戶的低活部分也有較大的最佳化空間。系統買詞作為新客承接、低活促活的一個重要抓手，希望透過對直通車新客和低活客戶進行更高頻率的關鍵詞更新（天級->小時級），幫助目標客戶的廣告嘗試更多關鍵詞，存優汰劣，達到促活的目標。
基於此需求，我們在現有天級別離線鏈路的基礎上補充小時級的訊息更新鏈路，用來支援標準計劃下各詞包、以及智慧計劃的系統詞更新，每小時訊息更新量在千萬量級，使用Blink將全量ODPS請求引數呼叫faas的函式服務，將每條請求的結果寫入到ODPS的輸出表中。更新頻率在兩個小時，更新時間：早8點到晚22點，單次增刪規模：增500W/刪500W。
主要挑戰
-
blink批處理作業需要進行小時級排程
-
faas函式呼叫需要限流
解決方案
-
使用Blink UDF實現對request請求呼叫HSF的函式服務功能
-
blink UDF使用RateLimiter進行限流，訪問函式服務的QPS可以嚴格被節點並行度進行控制
-
在Dataworks平臺配置shell指令碼，進行Bayes平臺批計算任務排程
總結
基於此需求，使用blink sql batch模式實現了近即時的此類更新鏈路，打通了此類批處理作業的排程模式，為後續批作業產品化打下了基礎。
四 未來展望
基於B端演算法的業務，Dolphin引擎目前已經設計開發了Dolphin streaming鏈路，使用者在極光平臺開發即時特徵變得跟在odps開發離線表一樣簡單，使用者無需瞭解即時資料來源、底層儲存引擎，只需要用sql就可以查詢即時特徵資料。但是B端演算法業務中還有類似於本文中提到的批處理業務，這些業務需要開發blink batch sql、blink streaming batch模式、ODPS UDF和java code任務，並且提供排程指令碼，最後將專案進行封裝提交給演算法團隊進行使用。未來我們希望使用者能夠在極光平臺自助開發批次計算業務，降低演算法同學開發成本，提供一個可擴充套件、低成本的批計算引擎能力，支援業務快速迭代，賦能業務落地快速拿到結果。
學習參考
對flink比較感興趣或者是初步接觸flink的同學可以參考以下內容進行一個初步學習：
-
Flink官方部落格：https://flink.apache.org/blog/
-
Flink Architecture：https://flink.apache.org/flink-architecture.html
-
Flink技術專欄：https://blog.csdn.net/yanghua_kobe/category_6170573.html
-
Flink原始碼分析：https://medium.com/@wangwei09310931/flink-%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-streamexecutionenvironment-4c1cd9695680
-
Flink基本元件和邏輯計劃：http://chenyuzhao.me/2016/12/03/Flink%E5%9F%BA%E6%9C%AC%E7%BB%84%E4%BB%B6%E5%92%8C%E9%80%BB%E8%BE%91%E8%AE%A1%E5%88%92/
關係型資料庫課程
點選閱讀原文檢視詳情
關鍵詞
離線
系統
場景
平臺
引擎
