在做指標(biāo)管理時，我們需要保證數(shù)據(jù)的一致性，后續(xù)思考相關(guān)問題時，我們也可以基于這一準(zhǔn)則做出解答。這篇文章里，作者就針對“數(shù)倉分層后，原子指標(biāo)如何指定來源事實表”這一問題做出解答，一起來看看吧。

開門見山，直接來個提問：

背景1：數(shù)倉已經(jīng)分層，現(xiàn)有兩張表，一張是天粒度的表dwd.order_d（放在了DWD層），一張是周粒度的表dws.order_w（放在了DWS層），兩張表里面都有指標(biāo)訂單金額。

背景2：你現(xiàn)在負責(zé)建設(shè)或管理指標(biāo)管理系統(tǒng)，當(dāng)中有個模塊叫原子指標(biāo)管理。界面和功能類似下圖的華為產(chǎn)品（DataArts Studio_新建原子指標(biāo))

提問：新增「訂單金額」這個原子指標(biāo)的時候，應(yīng)該設(shè)置哪個表為原子指標(biāo)的來源表？指標(biāo)后續(xù)要統(tǒng)一從哪一層出呢？比如，要匯總月訂單指標(biāo)的時候，應(yīng)該從哪個表來匯總呢

來，思考3秒，3…2…1，給出你的答案。這個問題，很容易陷入當(dāng)中給出的兩個選項：天粒度 or 周粒度？

我先提醒你牢記，做指標(biāo)管理有一個核心關(guān)注點：保證數(shù)據(jù)的一致性。我的答案是：原子指標(biāo)要基于最原始、粒度最細的數(shù)據(jù)來定義，當(dāng)然，這是理想的做法。

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

對于訂單這個動作來說，什么是最原始、粒度最細的數(shù)據(jù)呢？

下訂單就增加一條記錄的那張表，不管下單是最終成功還是失敗，系統(tǒng)都會記錄，這張表就是最細粒度的表。這個最原始的銷售訂單事實表，里面通常包含每一筆訂單的詳細信息，如交易時間、金額、客戶信息等。而且基于這張表進行多種聚合計算，如按天、周、月等不同時間粒度或者其他維度（如商品類別、地區(qū)等）來匯總數(shù)據(jù)。

而在實踐中，就如提問的背景說的那樣，你進入某新公司，數(shù)倉已經(jīng)建好了，表也建好了，就等利用管理系統(tǒng)來科學(xué)管理指標(biāo)了，這時候，可能會根據(jù)使用場景的不同選擇不同的表來作為指標(biāo)計算的基礎(chǔ)。

場景：嚴(yán)格遵照定義管理

如果是為了保持最大的靈活性和精確度，你應(yīng)當(dāng)找到那張最細粒度的銷售訂單事實表去定義原子指標(biāo)。這保證了指標(biāo)的靈活性和準(zhǔn)確性，因為原子指標(biāo)應(yīng)該代表最基礎(chǔ)的事實，允許在此基礎(chǔ)上構(gòu)建更加復(fù)雜的計算和分析。

場景：從實際業(yè)務(wù)需求出發(fā)

如果業(yè)務(wù)需求明確主要關(guān)注天或周的銷售趨勢，分析場景里沒有比天更細的粒度，且這些聚合表是可靠的數(shù)據(jù)來源，可以直接使用這些聚合表作為指標(biāo)的數(shù)據(jù)來源。

• 天粒度的表：是對原始事實表中的數(shù)據(jù)按照天來進行預(yù)先聚合的結(jié)果。如果業(yè)務(wù)需求主要關(guān)注日常運營分析，以天作為標(biāo)準(zhǔn)時間單位，則天粒度表能夠快速提供所需數(shù)據(jù)。
• 周粒度的表：則更進一步將數(shù)據(jù)聚合到周級別，適用于那些關(guān)注周趨勢的分析場景。

不管是哪種場景，我們的目標(biāo)重點是保持清晰的指標(biāo)定義和一致的取數(shù)口徑，即使在不同的聚合層級之間，銷售金額指標(biāo)的計算規(guī)則也應(yīng)該是一致的，比如都包括或排除退貨、折扣等因素。

寫在最后

無論是從事實表還是某個聚合表中取數(shù)，結(jié)果都應(yīng)該是相互驗證且一致的。

之前寫了事實表里沒有原子指標(biāo)，結(jié)果實際在系統(tǒng)里管理原子指標(biāo)的時候，又要指定它的來源表，這是咋回事呢？

原子指標(biāo)定義的是取數(shù)的邏輯和部分計算表達式（完全SQL取數(shù)里面的計算表達式部分），后續(xù)再來講講~