生產實踐 | 基于 Flink 的直播實時資料建設 （一）| 需求和架構篇
?本系列每篇文章都是從一些實際生產實踐需求出發，解決一些生產實踐中的問題，拋磚引玉，以幫助小伙伴們解決一些實際生產問題，相信大家或多或少都觀看過直播，那大家有沒有想過，如果自己負責建設公司內整體直播實時資料，會怎樣去建設呢？本系列文章主要介紹直播實時資料建設的整個程序，如果對小伙伴有幫助的話，歡迎點贊 + 再看~
?
首先思考幾個問題
-
「WHAT：相信大家或多或少都觀看過直播，甚至自己就是一名主播或負責的業務就是直播相關的，那大家有沒有思考過，在直播業務場景中，你最關心什么指標以及需要關注、建設什么資料？」
-
「WHY：為什么需要建設直播實時資料？離線建設不能滿足嗎？」
-
「HOW：直播實時資料怎樣賦能業務的？怎樣根據公司直播場景的需求去劃分直播實時資料？怎樣去建設直播實時資料體？」
-
「WHO：在建設直播實時資料的程序中，需要使用什么樣的組件進行建設？每個組件都負責哪一部分？」
讓我們帶著以上幾個問題出發~
直播 + 短視頻，內容運營的下一個戰場
隨著互聯網路技術的發展，網路直播受到越來越多人的關注，直播在經過幾年前的噴涌式大爆發之后，近段時間熱度有所降低，內容的同質化和變現困難是直播現在面臨的主要問題，隨著移動終端普及和網路的提速，短視頻以短平快的大流量傳播方式快速獲得各大平臺、粉絲和資本的青睞，所以眾多直播軟體開始接入短視頻的功能， 同時，一些以短視頻為主發展起來的 app 也在軟體中加入了直播功能，直播和短視頻兩者互相彌補不足，相輔相成，給用戶帶來了更好的使用體驗，也給各大平臺帶來更多的流量，"直播 + 短視頻"的模式已經也成為新的發展趨勢，
本系列文章主要圍繞著直播實時資料建設而展開，本文是本系列文章的的第一篇，需求和架構篇，主要分為三個部分，按順序為「WHY - WHAT - HOW」，以這三個角度出發，解答開頭提出的三個問題，其中 「WHO」部分在本系列文章的后續建設細節章節進行介紹！
WHY：為什么建設直播實時資料？
相比短視頻的生產消費來說，直播的主播和觀看直播的觀眾的紐帶都是在直播間建立的，相互之間的互動行為也都只在直播間內產生，并且通常情況下，一場直播的時長也就在幾個小時之內，因此直播的生產消費時效性相比短視頻會更強，因而直播資料對于實時性的訴求也就更高，
WHAT：需要關注、建設什么直播實時資料？
需要關注、建設什么直播實時資料？換一句話來說就是根據「資料分析業務的需求」出發，決定建設什么樣的直播實時資料？
直播就是一個主播和觀眾聯絡互動的紐帶，其中一切操作都是圍繞著主播和觀眾而展開的，資料分析的同學都會以這個最基礎的角度出發進行分析，因此首先我們就可以將整個直播的資料按照「直播生產」和「直播消費」進最基本的劃分，
除此角度之外，資料分析的同學也還會從「全域直播業務洞察」和「單個直播間洞察」不同粒度上進行分析洞察，因此還可以按照「大盤資料」、「單直播間資料」進行劃分，
從這兩個角度出發，基本可以涵蓋對于直播業務分析場景的訴求，因此直播實時資料也自然可以從這兩個角度進行劃分和建設，
綜上則整體「直播實時資料業務劃分和賦能應用架構」如下圖所示，
業務劃分和應用架構
其中
「直播大盤實時資料」在宏觀上監控直播業務，提供預測大盤的能力；其中分鐘粒度時間序列可快速定位直播各行為的高峰時刻，可以基于該時刻進行詳細歸因，除此之外，當直播在做運營活動時，也能快速基于實時資料來看運營活動的活動效果，賦能活動策略實時優化，
「單直播間直播實時資料」可以以細粒度監控單直播間的直播業務，用來在直播程序中對外輸出直播資料戰報、以及可基于資料戰報效果實時對單直播間進資源投放進行實時效果評估和合理調配，
詳細的直播實時資料需求和樣例如下文，
大盤
「生產側」
-
「指標」：總體開播直播間數...
-
「維度」：直播間畫像、主播用戶畫像
-
「舉例」：[開播直播間為游戲類直播]的[總開播主播數]
「消費側」
-
「指標」：總體觀眾觀看、點贊、評論數...
-
「維度」：觀眾用戶畫像、日志上報其他維度
-
「舉例」：[目前在河北觀看直播]的[總觀眾數]
單直播間
「生產側」 單直播間一般都是一些畫像資訊，所以此類指標較少，暫時不做討論，
「消費側」
-
「指標」：單直播間觀眾觀看、點贊、評論數...
-
「維度」：觀眾用戶畫像、日志上報其他維度
-
「舉例」：某直播間[18-23歲年齡段]的[總觀眾數]
目前已經了解了要建設直播實時資料都包含了什么內容，接下來就是大干一場的時候了，
HOW：怎樣去建設？
怎樣去建設？換一句話來說就是從技術的角度出發，怎樣將「直播實時資料的業務需求」轉化為「直播實時資料的技術方案」進行落地？
從技術角度出發，上述直播實時資料需要建設的需求內容總結下來就是一個詞：「直播實時多維指標」，
多維
即產出指標是多維度的，包含公共維度和非公共維度，
第一類是「公共維度」，包含三部分，直播間畫像，主播用戶畫像，觀眾用戶畫像，公共兩字代表這類維度是可以被多個指標進行共享使用的，舉例：某直播間開播之后，該直播間畫像只需要一次建設，就可以被多個指標多次重復使用，不但可以作為大盤側生產、消費指標的維度，也可以作為單直播間生產、消費指標的維度，
第二類是「非公共維度」，非公共維度是和特定消費行為系結的，也就是和某個指標系結的，隨著日志上報一同上報的維度，舉例：某觀眾觀看直播時的客戶端型別（安卓？IOS？），觀看直播時的省份等維度，這類維度只和當前的消費行為相關，不能被其他指標所共享，
多維
指標
其實都是 pv，uv 類指標，簡單理解就是各個維度下對應的 xx 量，
指標
實時資料建設技術架構
對應到直播實時資料建設的程序主要包含兩部分：公共部分和非公共部分，
公共部分就是實時公共維表的建設，
非公共部分就是指標非公共維度以及對應生產、消費指標建設，
直接給出總體「技術架構」圖，本系列后續的文章進行介紹這樣進行整體架構設計的詳細原因，
技術架構
簡單說明下，
其中資料源包含生產側，消費側資料源；
資料處理部分包含公共實時維表建設，和指標建設，其中一部分公共維表的建設也使用了離線的方式提供了支持；
最后就是資料匯部分，產出了生產側，消費側的多維指標供資料分析師使用，
下節預告
下節主要介紹「直播實時公共畫像的建設」，其中是技術架構圖中的「主播用戶、關注用戶畫像、以及直播間畫像」的建設方案，
總結
本文首先提出了幾個關于直播實時資料建設的問題，以這幾個問題觸發，引出了一下三小節，
第一節簡單介紹了直播時效性強的原因，因此直播對于實時資料的需求更加強烈，
第二節從資料分析的角度出發，引出了我們需要建設的直播實時資料都包含哪些內容，并且從大盤/單直播間，生產/消費角度進行了模塊劃分，
第三節對資料需求進行了技術方案的整體架構設計，
最后一節對本文進行了總結，
如果你也有相同的建設需求或者你以及建設了直播實時資料，歡迎留言或者留下你的文章鏈接，相互交流~
**
公眾號(mangodata)里回復 flink 關鍵字可以獲取 flink 的學習資料以及視頻，
**
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/208676.html
標籤：其他
上一篇：雙十一秒殺系統這你搶得過嗎?