## 使用者福利
阿裡雲最新釋出業界首款雲原生多模資料庫Lindorm，新使用者可申請首月免費試用，擷取産品技術支援，請加入釘釘群：35977898，更多内容請[參考連結](https://www.aliyun.com/product/apsaradb/lindorm?spm=a2c6h.12873639.0.0.74c15ad4EXvmuV)
1 什麼是歸因分析
歸因分析說明
（Attribution Analysis）歸因分析就是從客戶的行為軌迹（Customer Journey）中去分析營銷政策成功的原因（Attribution of Success）。舉例來講就是小明購買天貓精靈的消費行為是由哪些管道廣告促成的？這些管道的貢獻占比多少？
歸因模型介紹
“歸因模型指一個規則集，用于解釋和衡量轉化路徑中每個接觸點所貢獻的轉化量或轉化價值”。目前最通用的一種是“last click attribute model”，即把100%的功勞給與離轉化最近的一次廣告點選。其它還包括線性模型、時間衰退模型、資料驅動模型等等。詳情請參考文章[2]
歸因視窗介紹
歸因視窗（Attribution Window）有時也叫做轉化視窗（conversion window）是一個連續的時間段，在這段時間内可以推導出對已經發生的“轉化”的“貢獻”，這裡轉化通常指購買，貢獻通常指廣告曝光或廣告點選。Facebook提供的歸因服務預設采用1天的曝光視窗和28天的點選視窗。[3]
2 實時歸因的價值
歸因的作用就是找到“成功的原因”，這可以使你持續保持成功，并且通過對“成功過程”的深入洞察，可以調整營銷政策來獲得更大的成功，最終提高投資回報，提高産品的客戶群體。
實時歸因是未來發展趨勢[4][5]
2.1 天下武功唯快不破，今天的客戶已經進入快消時代越來越缺少耐心，今天的營銷管道也是多樣生态且有新場景湧現，今天RTB（實時廣告競價）已經大面積應用，是以實時歸因也必須跟上步伐。
2.2 real time = right time，更加快速、細粒度的客戶洞察使我們可以及時響應市場，及時優化營銷政策。我們也可以及時發現潛在客戶并給與定向幹預，進而加速轉化率以及轉化周期。
3 實時歸因的挑戰
3.1 歸因需要的使用者行為資料體量大、寫入頻率高，需要系統有很好的擴充性
3.2 歸因模型雖然以last click最常見，但其它更優秀的模型也在快速發展，需要系統支援多模型
3.3 歸因視窗差異性較大，有些隻需要20分鐘，有些幾天，有些要1個月或者更長。需要系統有靈活的存儲和讀取能力
4 如何設計歸因系統
站在巨人的肩膀上，先看一下業内大佬們的解決方案
4.1 Netflix方案
如下圖所示，Netflix使用Stream Processing層來實作Customer Journey的收集和存儲。具體資料模型上是兩張表，“impression table”存儲所有的曝光、點選等事件，事件中至少包含使用者ID與廣告供應商ID。“conversion table”（Netflix 叫做 play，因為對于他們來講轉化=播放）存儲所有的轉化事件，事件中也包含使用者ID。“impression table”和“conversion table”存儲在S3上。然後通過Spark跑批對這兩個表進行Join來實作歸因計算[6]。
這個一個比較成熟的方案，可以解決上面提到的很多問題。首先資料持久化在S3上，S3支援PB級别存儲且具備優秀的擴充性。其次Spark 可以支援豐富的計算，可以對一份資料應用多種歸因模型。最後計算本身不受視窗大小限制。
但是這個方案的缺點也很明顯，就是不那麼實時。
4.2 Databrics方案
Databrics方案其實在架構上并沒有跳脫出Netflix方案，隻是将S3換成了Delta Lake，但是把整個方案的實時性提高了[7]。
在Netflix方案中，Spark Streaing直接寫入S3，如果速度過快比如1秒一個檔案，勢必會産生非常多的小檔案，對計算不友好。為了解決這個問題就需要做Compaction合并，合并完要删除小檔案，但如果這個小檔案還在被讀取就會造成一緻性問題。Delta Lake很好的解決了資料湖更新問題，提供ACID保障，自動合并小檔案，還具備分布式中繼資料能力，綜上Delta Lake可以讓事件入湖達到秒級延遲。
但是解決了前半部分的實時性，後半部分還是有點問題，其架構圖中顯示歸因計算還是用Spark批處理。但在演講中提到Delta Lake提供CDC（
Change Data Capture） 即資料訂閱能力，可以對接Spark Streaming。
總的來看，繼承了Netflix方案的優點，在實時性上有較大優化。但整體鍊路還是有點長，距離實時差了點味道。感覺是一個near real time範本。
4.3 Flink方案
下面我們介紹小紅書基于Flink的實時歸因方案，原文見[9]。這是一個非常酷的方案，其鍊路非常短Kafka + Flink就足夠了，核心利用的是Flink的Session Window。Session Window是這樣一種Window，它包含一個起始時間和一個逾時時間，如果一個事件落在了起始時間和逾時時間之内，那麼該事件屬于這個Session，并且逾時時間會随之更新。
Flink使用Session Window來實作歸因視窗（Attribution Window），Customer Journey存儲在Session Window裡，在Session Window結束時調用處理函數做歸因計算。雖然在小紅書的例子中其實沒有做計算，隻是将歸因資料輸出到了下遊，但是這個架構是完全可以在Flink中就進行歸因分析的。
使用流計算（Flink or SparkStreaming）來實作歸因的最大好處就是鍊路短時效性強。但是也存在如下問題：
1 session window中狀态太多，消耗系統資源，成本高
2 很難處理周、月級别的歸因視窗，不管是Kafka還是Flink都不适合存儲大量的資料
3 準确性不足，Session Window的逾時時間設計是門藝術，比如逾時設定20分鐘，但在20分1秒發生了轉化怎麼破？
4.4 我們期待的是一個什麼樣的系統？
- 快，實時歸因是我們的追求
- 準，歸因分析能更真實的反應實際情況。這要求：歸因資料要一緻且全面，能支援多種歸因模型
- 通，通用性，可以支援不同的歸因場景，特别是不同的Attribution Window
- 穩，架構簡單易維護
- 省，盡量少花錢:)
5 一種基于Lindorm的Event Sourcing解決方案
為了達到實時歸因，采用流處理架構。把狀态外置解決流處理存儲大量狀态的問題，Session State中僅保留開始事件和結束事件，整個Customer Journey從外置存儲中攝取，這個外置存儲就特别符合一個Event Sourcing。
考慮用Kafka來做這個Event Sourcing，雖然kafka支援reprocessing，但其隻能做到分區級别的順序消費，無法支援Key級别的順序消費，很難支援基于單個使用者的歸因，另外Kafka也不适合存儲月級别的資料。
考慮使用HBase來做Event Sourcing，HBase支援水準擴充存儲PB級别資料（good），HBase支援高并發範圍查詢可以用來實作Customer Journey的攝取，掃描10000條也就百毫秒，而且支援反向掃描（good）。但是HBase沒有CDC功能，無法驅動流計算系統。是以你要再加一套Kafka，雙寫Kafka和HBase，這一看就很複雜難維護。
綜上，Kafka和HBase都有優點和缺點，我們推薦使用Lindorm來做Event Sourcing，Lindorm寬表完美繼承HBase優秀基因，Lindorm Streams提供資料訂閱能力。
這套架構的優勢：
- 快，Fink/Spark Streaming 提供實時處理
- 準，Lindorm 作為Event Sourcing可以支援批流一體，批計算保障最終一緻（本人傾向流計算終将一統天下，但目前看批流一體還是比較成熟）
- 通，支援不同的歸因場景，不同的Attribution Window。Fink/Spark支援豐富計算，Lindorm支援高效存儲和攝取
- 穩，隻需要Lindorm 和 流計算引擎
- 省，流計算引擎隻需要存儲少量的狀态。Lindorm具備高效壓縮、透明冷熱分離等降本手段。
參考
[1]
The 3 Biggest Problems with Advertising Attribution[2]
電商中，常用歸因模型的介紹與分析[3]
The Facebook Attribution Window[4]
The power of real-time attribution in a multi-channel world[5]
PREPARING FOR THE FUTURE: WHY REAL-TIME ATTRIBUTION IS ESSENTIAL[6]
Near Real-Time Netflix Recommendations using Apache Spark[7]
Real-Time Attribution with Structured Streaming & Databricks[8]
Building a Real-Time Attribution Pipeline with Databricks Delta[9]
小紅書如何實作高效推薦？## 咨詢交流
歡迎加入Lindorm技術交流群
