中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

當你面對“原子指標需要支持開窗函數嗎”這個問題時，你會如何回答？這篇文章里，作者結合案例和過往經驗，對開窗、指標管理、原子指標等概念及相關問題做了解讀，不妨來看一下。

開局一個靈魂提問：原子指標需要支持開窗函數嗎？

假如，你服務的企業在做數倉重構，給你機會嘗試One Data指標管理的落地。你還是參照競品，設計了指標管理，能對指標進行各種計算邏輯的定義。 提問：原子指標的口徑定義里，能不能也支持支持開窗函數。

這個問題，你又怎么看？來，思考3秒，3…2…1，給出你的答案。你是不是又開始想，「什么是原子指標」這個問題了？如果對技術不熟悉，可能還會問，什么是開窗函數？接下來的內容，將會圍繞這主題展開。

1. 問題起源什么是開窗？
2. 為什么要開窗？
3. 回看：到底要不要支持開窗
4. 問題的本質：理解指標、表、以及指標和表的關系

本文將會結合生動的案例和深入的自我思考，帶你從一個小問題深入理解指標管理，希望你能看到最后~

一、問題起源

當時公司在做數倉重構，正好給我機會機嘗試One Data的落地。但我也沒經驗，于是參考了很多資料和競品，然后對照著競品照貓畫虎弄了指標管理的設計，就像華為 DataArtsStudio 的指標管理這樣：

數倉開發同事看了這個原子指標管理的界面，然后問了上文提到的問題：原子指標能不能支持開窗函數。我反問了下，為啥要支持開窗？同事當時說的原話我不太記得了，大概說的是：某些指標是要開窗統計排名。比如（假設），教育場景里，某個報表里有這兩個指標。

銷售金額TOP1課程，很像是用來修飾指標的前綴（修飾詞），但又是基于對指標的排序而來的。

已知，原子指標要定義指標取數的邏輯，開窗函數是一種計算方式，那么，原子指標的定義里面，是否要囊括對開窗函數的定義呢？我轉身看競品（DataArts Studio_新建原子指標）找答案，但是競品沒支持。

不僅僅華為不支持，其他好幾個大廠競品都沒涉及到這點。完蛋，我好像進入一個沒人涉足的無人區了，咋搞？當然，我可以很簡單做個決策：相信大廠，照抄。并且以此說服同事，我可以說，大廠的好多的競品沒做，肯定是有道理。但是到底為什么競品不支持開窗呢？我始終不明白。

我了解了實際情況，管理、推薦的場景里，確實有些指標是排名性質的，看似這個訴求也合理。而且，排名方面，還可以繼續演化，以直播場景為例。比如按照多個指標排名后，最終分出來主播的級別，然后日常要看S、A、B級主播帶貨金額占總體GMV的比例。

在企業里，你可能會看到兩種狀態的表格，描述的業務結果是一樣的，但是表頭、行數、列數有一些差異（差異就在于，修飾詞是否單獨列出來作為維度，以后有機會再講）到底要不要支持呢？要不要探究下呢？理解開窗，才能知道到底要不要。

二、什么是開窗，為什么要開窗？

我們人眼所看到的內容，都是光照到物體上的反射，打開窗戶，外面的光才能照進來。

開窗的大小，決定了進入到窗內的光的多少，也影響了窗內人獲取信息的量。

人所看到的內容，取決于看的視角，從不同的角度看，信息也不同。

還記得小學課文里的楊桃嗎？有的角度看楊桃，像個五角星。再比如，蘇軾在《題西林壁》中寫道：橫看成嶺側成峰，遠近高低各不同。不識廬山真面目，只緣身在此山中”。

假如，我們待在一個房間內，我們認為窗是相對靜止的。調整我們的視角，能看到不同的內容，可以理解為從不同的角度（維度）去分析事物。除此以外，也有移動的窗。

就如圖片所示，當我們坐在火車上，視角固定，窗戶常開，雖然你人不動，但是你會看到不斷變化的內容，不同物體的光會透過窗戶（信息）不斷映入你的眼睛。有了這個基礎，我們再去理解數據世界的開窗函數。

開窗函數是一種在數據庫查詢中使用的強大工具，它能夠在一個數據集上進行復雜的序列比較和計算。

在SQL中，開窗函數可以用于各種計算，包括聚合運算、排名、移動平均等，而不改變返回行的數量。以下是一個簡單的例子：假設我們有一張名為sales的表格，其中包含了每天的銷售數據，該表具有以下結構：

• sale_date：銷售日期
• amount：當日銷售金額

如果我們想計算過去7天的滾動平均銷售額，則可以用如下SQL查詢：

SELECT sale_date, amount, AVG(amount) OVER (ORDER BY sale_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS rolling_avg_sales FROM sales;

這個查詢中的關鍵部分是開窗函數AVG(amount) OVER (…)：

• OVER子句定義了窗口的規則。
• ORDER BY sale_date表示窗口以sale_date進行排序。
• ROWS BETWEEN 6 PRECEDING AND CURRENT ROW指定了窗口的范圍是當前行以及之前的6行，總共覆蓋了7天的數據。

執行這個查詢后，每一行都會新增一個rolling_avg_sales字段，表示從當前行開始往前數7天內（包括當前行）的平均銷售額。備注：

不同的SQL數據庫管理系統在處理邊界情況（例如，當沒有足夠的數據計算七天平均時）的默認行為可能略有不同。

然后，我們結合案例來看看開窗函數定義的指標。

假如，我們是一家網店的店主，本月新上了一個品類，然后系統記錄了該品類1-20號的當天銷售金額，也統計了環比昨天的指標。如下左邊。我們也基于這兩個指標制作對應的業績變化圖。

而當我們感受到2次比較大的業績下滑，在第3次業績下滑的時候，要不要進行調整銷售策略呢？調整的依據是什么呢？尤其14號的業績剛剛有突破，而15號又猛烈下滑。

這個時候，我們就可以用開窗函數來看平均的銷售情況，而不是被某一天或兩天的異常高低銷售額所影響，我們可以使用7天滾動平均銷售金額這個指標（如下圖）

結合7天滾動平均銷售金額來看，雖然業績有起伏波動，尤其是紅色框中的部分，滾動平均銷售金額的波動并沒有那么大，且在小幅下降后便逐步上升如果在原子指標定義中需要考慮時間序列分析、累積計算或者比較不同時期的數據，那么開窗函數就非常有必要。

當然，在真實的應用場景中，我們還需要考慮到特殊情況，比如業務調整、節假日或者其他非營業日沒有銷售數據的情況。

三、回看，到底要不要支持開窗？

開窗有意義嗎？有。那系統層面能支持開窗嗎？能。要支持開窗嗎？等等，再想想，其實還有一個問題。

為什么看到很多競品系統，在定義原子指標計算邏輯時，都要求先指定對應的來源表呢？而且一般都是事實表，這當中有什么關系嗎？

正好，在上篇文章里講到過這個問題：數倉分層后，原子指標如何指定來源事實表。

當中說道：我們的目標重點是保持清晰的指標定義和一致的取數口徑，即使在不同的聚合層級之間，銷售金額指標的計算規則也應該是一致的。

等等，如果有兩個表，一個原始表，一個開窗的結果表，那是不是可以基于開窗處理后的結果表來定義指標呢？嗯，把這種開窗的計算邏輯前置到表的ETL腳本里去，原子指標這層，屏蔽掉這個邏輯。

我們再看看開窗函數，到底是在做什么操作？

在上面的案例里，你也看到了，在某些日期內做開窗計算，是沒有結果的。

當數據缺漏時，就像開的窗戶對著一塊黑洞。

因為窗戶設定的范圍很大，但是數據的范圍沒那么大（就好像，開的窗戶里有一部分對著黑洞，光壓根從黑洞里跑不出來，那肯定看不到。

而且，案例中開窗是要按照設定的窗口范圍取一些歷史數據計算的，無意間就利用時間修飾了指標。時間是什么？可以理解是維度，比如日期，也可以理解是時間周期，近1天、近7天。

其實環比昨日也涉及到了時間周期。還記得之前文章指標管理必知的真相：訂單事實表里沒有原子指標引用的公式嗎？派生指標 = 原子指標 + 時間周期 + 修飾詞

再問問自己：開窗函數定義的指標是原子指標嗎？誒，好像不是。

這時候，我們再回看定義，在指標管理中，原子指標通常指的是最基本、不可再分的數據點，這些數據點用來構建更復雜的計算指標或衍生指標。

例如，日銷售額、用戶訪問量等都可以被看作是原子指標。開窗的指標，相當于是借用有時間含義的指標進行了口徑定義，且只能是在時間往前推移的情況下(也就是有了時間周期的情況下），才能有正確的計算結果。

故而，開窗函數修飾的指標，不是原子指標。原子指標，不應該支持開窗函數。

四、問題的本質：理解指標、表、以及指標和表的關系

1）深入理解不可再分

“不可再分”的原子指標，指的是在特定的業務情境下，該指標已經是最簡單、最基礎的數據度量，無法被進一步分解為更小的單位或子指標。窗口這個詞，其實不能完全表達含義，時間列車在滾滾向前，我們哪怕只從固定的視角看數據，但是這個數據也一直在變化。

例如，在銷售分析中，“日銷售金額”可以看作是一個原子指標。它由當天所有銷售交易的金額總和組成，自身并不會進一步分解為更細的指標。當然，“日銷售金額”可能來源于多個“單筆交易金額”，但在日銷售額這個層面上，我們通常把它視為一個整體，作為分析的基點。

2）深入理解粒度

分析的基點，這就是為什么數據倉庫在選定業務過程后，接下來就是聲明粒度的原因?？梢曰乜催@篇文章：數倉避坑-整明白懂粒度如果一個公司想要分析產品銷售數據，那么“單個產品的銷售數量”也可以被認為是一個原子指標，因為它代表了最基本的銷售單位計數，不涉及到更深層次的拆分。

這樣的原子指標有助于建立一個清晰、簡潔的數據體系，它們是構建復雜報告、儀表板和高級分析（如預測模型）所依賴的基石。通過對多個原子指標進行組合和運算，可以創建復雜的衍生指標，如銷售增長率、用戶留存率等。

3）脫離具體的表談論指標，是沒有意義的

指標是為了衡量、跟蹤或比較特定現象或結果而設定的具體數值或標準。離開具體的表定義指標和取數口徑，一個指標可能就會失去其原有的明確含義和測量價值。

如果沒有了明確的定義和取數口徑，就很難保證數據的一致性和準確性，進而影響數據分析和決策的有效性。

4）指標定義的問題，可以通過增加分層表來解決

當我們要依賴其他指標進行計算，我們可以先定義好事實表，加工好對應的指標，然后從定義好的事實表里面取值。

這樣也有個好處：利用表對指標的依賴邏輯進行一個解耦。不至于讓指標的計算口徑定義太過于復雜，比如，我們看某個指標，能知道這個指標是從某個表的某個字段基于什么方式進行計算，就可以了。至于說，依賴的表是怎么加工出來，數據是否準確，那是上一層定義的事情了。

5）表分層之后數據的一致性問題，需要質量監測來解決

緊接問題4，開窗是要開的，我們在指標所依賴的表的ETL里定義好，算好即可。如果粒度有很多，最粗粒度的指標肯定是有多種方式來匯聚出來的。比如，年度收入，可以從小時收入、天收入、周收入、月收入匯總出來。

以終為始來看，咱也不管是咋匯聚的了，咱就只要求：最終出來的結果是對的，多種方式產出的結果是一致的（都對?。?。這，就是數據質量里的準確性、一致性。

以上，感謝閱讀~