終於有人把不同標籤的加工內容與落庫講明白了丨DTVision分析洞察篇
上一篇文章詳細給大家介紹了標籤的設計與加工,在標籤生命週期流程中,標籤體系設計完成後,便進入標籤加工與上線執行階段,一般來說資料開發團隊會主導此過程,但我們需要關心以下幾個問題:
・標籤如何快速建立和實現標籤邏輯的線上化管理
・業務人員怎麼參與到標籤建設流程中
・百萬級別的標籤如何落表
一、加工方式:傳統 VS 線上
當企業無標籤系統時,一般由資料開發在離線數倉中完成標籤的加工和執行,運營或市場同學需要某個標籤需要透過產品經理向資料開發提需求,這個過程存在很多問題:
・標籤資產不可見:標籤是存在於表裡的欄位,業務人員不清楚現在有多少標籤;標籤的加工邏輯與業務邏輯是否一致只能檢視 SQL 程式碼;新上線的標籤只有部分人知道,標籤價值散發慢等
・標籤資產不可管:加工好的標籤,有多少在真正被使用,有多少沒人用,完全黑盒,不用的標籤每天繼續執行浪費計算與儲存資源
・標籤加工效率低:當業務人員需要某個簡單標籤時,也需要提交需求給資料開發,加工到上線基本需要 2-3 天流程
基於以上這些問題,標籤的線上化建立與管理顯得尤為重要,線上化主要包含以下內容:
・標籤線上化加工
・標籤線上化管理
・標籤線上化更新
其讓標籤加工過程以及有哪些標籤變得透明,業務人員也可以參與進標籤建設的流程中。
二、各型別標籤加工
標籤型別的區分在此處便不再贅述了。在袋鼠雲智慧標籤產品 ——「客戶資料洞察」中,我們按照標籤加工邏輯,將標籤分為以下型別,各型別標籤的加工層次如下圖:
接下來,我們來看看具體各型別標籤的加工。
1、原子標籤
該類標籤由資料開發在數倉加工中完成,一般基於數倉 DWD、DWS 層的明細表與彙總表加工而來,處理邏輯較為複雜,同時維表中的一些欄位也可以作為原子標籤。這類標籤一般包含哪些內容呢?
● 建立使用者的標籤體系:
使用者維表中的使用者基礎屬性:性別、年齡、置業、會員等級、手機號、身份證號等資訊,一般使用者系統會有該類資訊。
● 基於交易表加工的交易指標
最近 30 天購買次數、最近 30 天交易金額、最近 7 天購買次數、最近 7 天交易金額。這部分標籤也建議放在數倉中實現,有以下幾點原因:
・因為其本身也是一個指標,除後續作為標籤進行畫像分析外,也常用於在資料門戶、BI 報表中分析,可作為對外服務的指標放在 ADS 層中,並且市場上也會有專門指標管理的產品,來實現該指標的加工
・這類標籤若屬於同一個統計維度(如都計算最近 7 天),資料開發可以在一個 SQL 片段中計算多個標籤,節約計算成本
・若業務人員直接基於 DWS 層的輕度彙總表(每天彙總的交易次數、交易金額)、或 DWD 層的明細表(每條交易記錄一行資料)來加工最近 30 天購買次數這個標籤,需要針對對應的欄位進行求和,稍微涉及到一點 SQL 理解,有一些難度
故該類使用場景多、對於業務人員有計算難度,可在數倉中合併加工降低成本的標籤,可在數倉中作為原子標籤加工。
● 基於行為表加工的行為指標
可經過數倉加工成如下表格式,加工行為類的標籤,便於後續業務人員去衍生。
原子標籤在數倉加工好後,可匯入到標籤系統中,進行線上化管理。
2、規則標籤
該類標籤配置可由資料開發或資料分析師來完成,可基於單張表或關聯表中的欄位進行線上化加工,可設定統計週期、資料過濾條件,其內建常用的聚合函式(求和、均值、計數、去重技術、最大值、最小值等)、運算子(大於、小於、區間、有值、無值、包含等),透過規則化的線上配置完成標籤加工。配置介面如以下:
根據上面的描述,該類標籤可以將指標的型別的標籤在數倉或指標平臺加工好,匯入至標籤平臺作為原子標籤,再基於這些原子標籤取運算子更好。但在實際場景中,基於不同考慮,有的客戶也會在標籤平臺直接加工此型別標籤,如以下場景:
・數倉無對應的基礎標籤,但業務人員很著急需要該標籤某標籤,走正常的排期、數倉加工、測試,上線到使用基本 2 天以上了,基於這種情況可以透過該類標籤在標籤系統直接配置,5 分鐘即可配置、更新完成,業務人員便可以使用了
・客戶方想把標籤的加工邏輯線上化呈現、方便查詢與追溯,透過視覺化的方式線上配置
3、SQL 標籤
SQL 標籤主要由資料開發、資料分析師使用,主要解決透過規則標籤無法表達的邏輯,如用到排序函式、字元轉化函式、子查詢等內容,可以透過標準 SQL 語法靈活完成標籤加工。
4、模型標籤
模型標籤可由業務人員建立。系統整合常見的使用者分層 RFM 模型,使用者營銷 AIPL 模型、使用者生命週期模型,使用者輸入對應的指標值區間,便可定義對應的標籤值。
以 RFM 模型舉例,基於該模型生成 “客戶價值” 標籤。可基於最近一次購買時間、最近一年消費金額、最近一年消費頻率等幾個原子標籤,進行不同區間的取值,給使用者打上 “重要價值客戶”、“重要發展客戶”、“重要發展客戶”、“重要挽留客戶” 等。
5、組合標籤
模型標籤可由業務人員建立。基於已生成的原子、規則、SQL、模型標籤等,進行規則衍生,生成組合標籤。如組合標籤 “高收入低購買” 使用者,可透過 “收入水平” 衍生標籤,與 “最近 3 年消費金額區間” 衍生標籤組合加工,如下圖:
6、自定義標籤
自定義標籤可由業務人員建立。手動為某些使用者打上標籤,該類標籤手動匯入,常見場景如下:
・客服人員和使用者 ID 為 1001 的使用者溝通後,給該使用者打上” 性格:溫和、有耐心” 標籤
・如監管機構提供的一些信貸黑名單使用者,該類標籤可直接匯入進標籤系統,為使用者打上新的標籤
7、演算法標籤
演算法標籤由演算法開發同學建立,該類標籤可在演算法平臺完成,將算好的結果儲存至 Hive 表中,標籤系統可獲取演算法標籤的後設資料,拿到演算法標籤的中文名、英文名,註冊至標籤系統中,在標籤系統中完成演算法標籤的標籤資訊檢視、標籤查詢等。
如利用機器學習模型加工預測類的演算法標籤,如根據使用者的特徵,預測哪些使用者是否即將流失,流失的機率等,從而在使用者流失之前做一些措施來挽留。
8、實時標籤
實時標籤由資料開發同學建立,該類標籤可在流計算平臺完成,實時行為資料打入到 kafka 中,用 FlinkSQL 消費,再輸出到 Kafka、或資料表中,下游直接訂閱或查詢。
三、標籤更新與落庫
標籤配置完成後,便需要進行標籤更新與落庫,即將標籤打到物件(如使用者)的身上,這樣業務同學就可以根據標籤圈選目標群組啦。在此處我們需要說明以下幾個問題:
1、技術選型
首先說明一下標籤加工的技術選型,在袋鼠雲智慧標籤產品「客戶資料洞察」中我們用的 Trino(Presto)高效能分析引擎讀寫 Hive 表的方式,標籤表儲存在 Hive 中。主要有以下幾點原因:
・隨著國家對數字化轉型的支援,從金融、政府到小企業都在建設數倉,進行數字化應用,在這個過程中,大多采用的是分散式的 Hadoop 系統作為計算儲存引擎(不論是開源 Hadoop,還是發行版的 CDH、TDH、FusionInsight 等),Hive 表便是最常用的儲存形式。標籤是基於數倉模型搭建出來的,與數倉用同一種儲存可以節省儲存資源以及不用兩種儲存之間進行資料交換
・而用 Trino(Presto)的原因是其首先是一個分析型引擎,讀寫速度均可;其次是其 SQL 語法完備、函式豐富、靈活,可以處理絕大多是業務場景的需求;並且支援跨庫同時讀取,如 Trino 可以同時取 Hive 與 MySQL 的資料進行資料處理
但沒有一種完美的技術選型,只能貼合企業自己的業務,選取最合適的技術。在這裡我們就不分析各種標籤的技術選型了。
2、落表方式
上面我們介紹了有各種型別的標籤,那麼標籤如何落表呢,大家看下面這個圖:
在業務場景中,存在有的標籤需要每天更新,如最近 30 天消費金額區間;而有的標籤周更新、月更新即可,更新頻率不高,如活動型別偏好。
這樣,便需要支援每個標籤有不同的更新頻率,但 hive2.x 版本不支援單列更新,為了解決該問題,我們將每個標籤先在臨時表存一下(就包含 2 列,1 列使用者 ID,1 列標籤)該臨時表即建即用即刪,每個標籤只有一個臨時表(非分割槽表),每個標籤佔用的佔用不大,又能解決標籤更新週期不一致的問題。
但如果後續的標籤圈群、群組畫像分析,我們基於這些單獨表的去做聯合查詢,那效率會很低。
因為每個用營銷活動,我們需要 5 個標籤圈選出來一批人群,並查詢出這群人的性別、年齡、月消費、會員等級、是否活躍使用者等資訊,加起來用到了 10 個標籤左右,會涉及到 10 個表的 join 操作,客戶叢集資源不豐裕的情況,查詢速度慢。
所有我們便將多個臨時表透過聚合任務,將所有的臨時表 join 到一張標籤大寬表中,進行固化,這張表是一個分割槽表,可以每天儲存一份全量使用者標籤資訊,當然可以自行設定該表的更新週期與儲存多少個分割槽。
這樣,業務人員進行圈群和分析就可以一張表查詢資料,查詢效率大大提升。透過標籤跑批時間的消耗換取業務的查詢速度。
但會遇到有些企業標籤數量在 500-1000 個之間,使用者量在千萬、億級別,這樣的話,用一張表去存所有的標籤會遇到標籤大寬表跑批時間過長或跑不出來的情況,所以便需要分表,可以根據標籤數量分表。
綜上,以上加工儲存方式,有缺點的地方便是大寬表加工時,需要 join 多個臨時表,消耗記憶體,跑批時間長。
四、寫在最後的話
為解決該問題,袋鼠雲智慧標籤產品「客戶資料洞察」在引入資料湖 Iceberg 進行標籤表的儲存,其可以實現單列更新,每個標籤可以單獨更新,這樣,便不需要那些臨時表了,解決加工效率的問題。
標籤加工與落庫是標籤體系完成後重要的步驟,本篇文章向大家分享了標籤加工與落庫過程中需要關注的注意點,講述了不同標籤的加工內容以及標籤的更新與落庫等內容。
歡迎大家留言與我們討論,也可以分享下自己見到的一些好的標籤加工方式,我們共同進步。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69995740/viewspace-2914018/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 終於有人把網路爬蟲講明白了爬蟲
- 終於有人把隱私計算講明白了
- 終於有人把Web 3.0和元宇宙講明白了Web元宇宙
- 瞧!終於有人把智慧製造與工業4.0講明白了
- 終於有人把工業資料採集講明白了
- 終於有人把能把資料採集給講明白了
- ClickHouse與Hive的區別,終於有人講明白了Hive
- 終於有人把BungeeCord群組服搭建教程方法講明白了
- 終於有人把安全知識圖譜技術講明白了(上篇)
- 終於有人把MYSQL索引講清楚了MySql索引
- 終於有人把雲端計算、大資料和 AI 講明白了大資料AI
- 終於有人把雲端計算、大資料和人工智慧講明白了大資料人工智慧
- 分析即服務(AaaS)到底是什麼?終於有人講明白了
- 從洞察到決策,一文解讀標籤畫像體系建設方法論丨DTVision分析洞察篇
- 終於有人把ERP和OA的區別講清楚了!
- 資料視覺化的設計技巧,終於有人講明白了!視覺化
- 大資料基礎架構Hadoop,終於有人講明白了大資料架構Hadoop
- MPP大資料系統架構,終於有人講明白了大資料架構
- 想要精準營銷,從學習搭建一套對的標籤體系開始丨 DTVision 分析洞察篇
- 終於有人能把c#樂娛LEY介面的作用講明白了C#
- 終於有人把工資拖後腿的原因找到了,此文把平均數、中位數和眾數全講明白了
- 5000字長文分享!資料倉儲的建設與框架終於有人給講明白了框架
- 終於有人把15個JavaScript的重要陣列方法給講出來了JavaScript陣列
- 這一次終於有人把MySQL主從複製講全面了!!!MySql
- 索引失效底層原理分析,這麼多年終於有人講清楚了索引
- 五險一金終於有人給講清楚了
- 終於有人講透了使用者分析方法論
- 終於有人把Java記憶體模型說清楚了Java記憶體模型
- C#:終於有人把 ValueTask、IValueTaskSource、ManualResetValueTaskSourceCore 說清楚了!C#
- sql學習:終於把sql case語句使用講明白了,一看就懂SQL
- BI和報表等於資料分析?終於有人講清楚了它們的區別
- 花了一個星期,我終於把RPC框架整明白了!RPC框架
- 【教程】終於有人把Java記憶體模型說清楚了!Java記憶體模型
- 終於有人講清楚什麼是分析即服務(AaaS)
- 終於有人把機器學習中的文字摘要解釋清楚了!機器學習
- PbootCMS可使用的列表標籤內容tags標籤呼叫boot
- 關於LLM-as-a-judge正規化,終於有綜述講明白了
- 終於弄明白了 RocketMQ 的儲存模型MQ模型