Categories
程式開發

有贊指標庫實踐


一、概述

1.1 遇到的挑戰

不知道大家在日常工作中是否會經常遇到如下類似的問題:

  1. 商家:為什麼 A 頁面上的數據和 B 頁面上的數據對不上?開發:我去看看(一段時間後),A 是來自 a 表,B 是來自 b 表,一個包含 XXX 狀態的訂單,一個不包含 XXX 狀態的訂單。
  2. 數據開發:同樣的指標在不同的項目裡被用到,開發 A 同學從 a 表裡取了數據,開發 B 同學從 b 表裡取了數據,我應該從哪裡取數據?指標的邏輯變了2張表都需要做對應的修改?
  3. 數據開發和 BI 工程師:沒有現成的指標,我要的指標數據怎麼來?問數倉同學然後口口相傳?

如果大家遇到過上述類似的問題,說明需要指標庫這樣的一套指標管理工具來規範指標的定義與維護。

問題1體現的可能的一種情況是指標定義不夠清晰明確,兩個頁面上的指標定義其實是不同的,但是展示給商家看到的可能是同一個中文名稱。又或者同樣一個含義的指標在不同的界面上展示的名稱卻不相同,讓人產生歧義。

問題2體現的問題是同一個指標因為由不同的數據開發同學來製作,可能會被重複開發,不但造成資源浪費,還會造成維護困難。

問題3體現的問題是對於需要新開發的指標,不僅缺少開發工具簡化開發流程,甚至該使用哪些表,不該使用哪些表很大程度上都要憑藉數據開發同學與數倉同學的經驗。如果稍微馬虎一點或者缺乏經驗,比如使用了某些業務域下特有的表或者不是由數倉提供的統一中間層的表就可能會使用錯誤的數據,造成後期返工等情況。

隨著數據需求越來越多,數據中台提供的指標也日益豐富。

  • 但是各種指標定義混亂,描述不清。同樣的指標存在於多張物理表內,造成取數混亂。誰也不知道我們到底有多少個指標,更沒有沉澱出指標資產。
  • 製作指標需要人工諮詢數倉開發,口口相傳,沒有工具提供支撐。
  • BI 分析師在傳統 BI 系統上分析數據,製作圖表也僅僅局限在表,字段的層次,而不是維度,指標的層次。

為了解決上述問題,指標庫應運而生。

1.2 名詞術語

有贊指標庫實踐 1

1.3 產品定位與功能

指標庫給予每個指標一個精確且唯一的定義。通過指標庫可以快速且規範的查詢,開發和使用指標。

指標庫主要提供如下服務:

  • 通過設置指標的組成要素來唯一精確定義每個指標(派生指標)。
  • 通過指標在業務域內唯一的性質,解決指標重複定義,重複開發,部分數據對不上的問題。
  • 通過將數倉中間層錄入指標庫為新製作指標提供指導性的 SQL 或庫表推薦。
  • 打通其他各數據平台:
    • 打通數據開發平台和統一數據服務平台,為指標的定義,調度,在線使用提供一條龍服務,簡化開發流程。
    • 打通數據資產管理平台,沉澱指標的資產價值。
    • 打通 BI 平台,提供拖拽維度,指標生成報表的功能。

主要功能和參與用戶

有贊指標庫實踐 1

1.4 開發流程

有贊指標庫實踐 3

第一步:數倉先確定業務域並導入 DW 庫統一中間層的表。

要錄入的維度指標屬於哪個域先確定下來,例如店鋪屬於店鋪域,訂單支付金額屬於交易域。只要數倉內部自己有統一的規劃即可。然後就可以導入中間層的表到指標庫。

第二步:數倉定義原子指標,維度,修飾詞。

如果之前沒有定義過,就新建維度指標等,並關聯到正確的表字段上,在第一步導入表的過程中也可以快速關聯到已經存在的維度指標。

第三步:生成派生指標。

有了維度,原子指標等元數據​​,就可以定義派生指標了。利用指標庫的 SQL 生成功能可以快速生成技術口徑。同時在指標庫上可以快速創建單個派生指標的數據開發平台調度任務。

第四步:應用派生指標 選擇需要的多個派生指標後可以通過指標庫快速創建多個派生指標的數據開發平台調度任務和統一數據服務的在線 API。至此就可以在線上查詢一批指標的數據了。當然指標庫上也支持臨時查詢指標的數據。

二、主要功能

2.1 數據源同步

指標庫中指標數據的來源一般都是從 DW 庫,數倉統一中間層的表中通過計算得來。不是所有的庫表都可以進入指標庫。試想一下,如果任意業務方 DM 庫下的庫表都允許添加進指標庫,如何保證指標的口徑是正確的?甚至各業務方可能會在任意時間修改自己的庫表結構。所以指標庫最基礎的元數據,比如維度信息,原子指標信息等都是使用數倉統一中間層。

數倉可以通過指標庫快速添加某一張表,同時將表上的字段關聯到指標庫推薦的維度和原子指標,這也有助於數倉規範庫表字段的命名。 (如下圖,導入一張庫表以後檢測庫表字段,推薦關聯到已經定義過的原子指標和維度上,當然也可以在維度和原子指標界面上去關聯表的字段)。

有贊指標庫實踐 4

2.2 維度管理

維度是觀察事物的角度,比如店鋪維度下近90天支付金額中,店舖是一個維度。在 SQL 中一般是 group by 的部分。數倉定義好維度以後需要設置維度的維度主表和關聯的事實表。

有贊指標庫實踐 5

2.2.1 維度主表

一般來說每個維度都會有一張主表。維度主表上一般會有三種類型的字段:

  • 維度主表主鍵:一般都是 ID 這種,比如店舖的 ID 。有些情況下會有多個字段做聯合主鍵。在維度主表上有1-N個。
  • 維度主表值鍵:一般都是名稱,比如店鋪名稱。在維度主表上有1個。
  • 維度主表屬性:一些其他的輔助信息。查詢的時候也可以查詢出來,用於提示。比如店舖的負責人是誰,店鋪 URL 是什麼,類似這些信息。在維度主表上有0-N個。

2.2.2 關聯的事實表

維度需要關聯事實表(存在指標字段的表)。關聯事實表的操作其實就是在標記當前這個維度出現在哪些事實表上(可以和哪些指標組合)。事實表上一般會有維度的兩種字段:

  • 外鍵:一般字段名字和維度主表的主鍵一致,是事實表的外鍵。用於事實表和維度表做 join 操作。在事實表上有1-N個,數量和維度主表主鍵一致。
  • 值鍵:有些情況維度表在事實表上會有值鍵的冗餘,這種情況下事實表可以不需要和維度表做 join 就能取出維度信息。在事實表上有0-1個。

2.3 原子指標管理

原子指標和度量含義相同,基於某一業務事件行為下的度量,是業務定義中不可再拆分的指標,具有明確業務含義的名詞 ,如支付金額。原子指標描述的其實是一種指標的類型,比如訂單支付金額,支付訂單數,下單訂單數,PV,UV 等等。但是僅僅一個原子指標是不能直接取數的。

比如訪客數是多少?這個問題就回答不了。因為這個問題沒有指定具體的維度(是店鋪維度下的訪客數,還是商品維度下的訪客數)和修飾詞( 是最近1天的訪客數還是最近90天)等信息。

有贊指標庫實踐 6

2.3.1 關聯表

原子指標需要關聯到具體的事實表和字段。如上圖配置了數倉統一中間層 DW 層的4張表。這意味著當前這個指標的數據可以從這4張表裡取。為什麼會有4張表而不是1張表?因為這4張表可能是不同維度的,適用於不同維度情況下的當前指標的取數。原子指標關聯事實表只需要指定事實表上的指標字段即可。每張事實表都是等價的,不需要設置主表。

2.3.2 聚合方式

聚合方式描述的是當前事實表上的指標如果需要做聚合運算,可以使用的聚合方式。默認聚合方式就是按維度做聚合的時候如果沒有指定聚合方式時採用的聚合函數。比如數倉中間層表提供的表裡有店鋪,用戶,支付金額3個字段。如果業務需要看店鋪維度下的支付金額。那就需要對店鋪做 group by ,對支付金額做 sum。這裡的 sum 就是配置的默認聚合方式。

2.4 修飾詞管理

修飾詞是維度的某一些特殊的值。對應 SQL 中的 where 過濾條件。比如業務方想看店鋪維度下的 weapp 的支付金額。製作出來的表結構可能是如下圖這樣的結構。

有贊指標庫實踐 7

weapp 可能只是渠道下某一個值。因為業務方的需求僅僅只是查看 weapp 渠道,不需要查看其他比如 H5, web 等渠道,所以表結構可以沒有渠道這個維度,而把 weapp 修飾詞直接做在事實字段上。

SQL 大致是這樣的形式:

select sum(支付金额) from table group by 店铺 where 渠道 = 'weapp'

從中我們可以看出,維度和修飾詞有一定的相互替代的作用。什麼時候用維度什麼時候用修飾詞目前並沒有嚴格的定論。只是能用維度來解決的問題盡量用維度,而不是修飾詞,因為維度是一種更加通用的形式。業務方可以在自己的 mysql 庫再根據自己的需要對維度做過濾。

2.5 派生指標

維度和原子指標更多的是站在數倉和 BI 的角角度設計的,符合數倉的星型模型。每張事實表上存在多個指標,每張事實表含有多張維度表的外鍵。但是業務方更關心的指標,是有實際業務含義,可以直接取數據的指標。比如店鋪近1天訂單支付金額就是一個派生指標,會被直接在產品上展示給商家看。

但是這個指標卻不能直接從數倉的統一中間層裡取數(因為沒有現成的事實字段,數倉提供的一般都是大寬表)。需要有一個橋樑連接數倉中間層和業務方的指標需求,於是便有了派生指標。

從上述的例子中可以看出派生指標=維度+原子指標+修飾詞。當維度,原子指標,修飾詞都確定的時候就可以唯一確定一個派生指標,同時給出具體數值。店鋪近1天訂單支付金額中店舖是維度,近1天是一個時間類型的修飾詞,支付金額是一個原子指標。業務方製作每一個派生指標都是通過選擇維度,原子指標,修飾詞三種元數據來定義的,相對於使用名稱來區別不同指標,更可以保證指標的唯一性。如果2個派生指標是不同的,那他們的組成部分一定會有區別,或是不同維度,或是不同原子指標,修飾詞。

有贊指標庫實踐 8

通過這種方式創建派生指標。因為維度和原子指標的在信息指標庫裡已經被標記,指標庫可以生成取數的 SQL(通過數倉 DW 中間層聚合而來)。簡化指標的開發。免除數據開發同學因為缺乏經驗或者不了解數倉中間層帶來的困擾。生成的 SQL(數據同學可以基於這個 SQL 做修改,有些時候需要 SQL 優化)也做為派生指標的技術口徑。

當後續項目需要用到這個派生指標的時候,可以來指標庫裡檢索,並查看使用這部分取數邏輯。避免指標重複開發(就算不檢索直接新建派生指標也會失敗,三要素唯一確定一個派生指標,重複創建可以被檢測出來),消除歧義。

2.6 指標購物車與我的 API

單個指標的技術口徑確定以後,仍然有一些問題需要解決:

  • 需要對單個派生指標進行調度定時產生數據。
  • 因為業務方一般一個 SQL 會查詢出多個相同維度下的指標,所以需要對多個派生指標進行合併,放到一張表上。
  • 業務方一般使用 mysql 等其他組件,需要把數據從 hive 寫入 mysql。
  • 取數的時候通過統一的 API 操作,而不是為每個指標都寫一個 dubbo 接口。因為這樣會有很多重複開發接口的工作量。

指標庫通過集成有贊數據開發平台解決1,2,3問題,通過集成統一數據服務平台解決問題4。

有贊指標庫實踐 9

無論是單個派生指標還是多個派生指標,添加到指標購物車內以後可以創建在線服務的API,指標庫會自動在數據開發平台上新建對應選擇的工作流下的任務節點,在統一數據服務平台上新建API。開發者只要稍加完善便可以快速將指標應用到在線服務。

有贊指標庫實踐 10

通過這種方式也可以將指標,數據開發平台的調度任務,導出任務,在線服務 API 關聯在一起。指標庫打通各內部平台,提供指標從定義到調度生產,到在線查詢的一條龍服務來簡化開發流程。

三、小結與展望

指標庫是從傳統的垂直數據產品開發到數據中台能力復用的過程中出現的項目。指標庫在有讚的實踐體現了我們對指標數據定義、生產、使用等過程的流程規範化與平台化的一種嘗試。當然,指標庫在有贊還剛剛起步,還有眾多挑戰與困難等待著我們去克服。

本文轉載自公眾號有贊coder(ID:youzan_coder)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760639&idx=1&sn=7f8289a8d63be6d75dee13343ec31b12&chksm=8c6868dabb1fe1ccc3c9280d1845cd3fc4359307a80a17ec6f70750758372d252ac3a8fa0577&scene=27#wechat_redirect