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

在大數據和數字化轉型的背景下，OLAP（在線分析處理）系統在企業中扮演著越來越關鍵的角色。本文深入探討了面向OLAP的數據指標使用，分析了其與建模場景下數據指標的區別，并討論了這種新型數據指標系統對現有開發流程的顛覆性影響。

建模場景下的數據指標在數據管理篇【數據規劃可行嗎】中介紹過了，這里講下OLAP場景下的數據指標。

一、兩者的區別

這里在OLAP場景下的數據指標，和建模場景下的數據指標最大區別就是，這里數據指標類似于已經和數據相結合了，不單單是一個指標口徑。

在建模場景下的數據指標，原始的方式可以使用一個Excel表格，通過表格來統計、整理一些數據指標的字段。在OLAP場景下的數據指標，或者說數據指標系統，已經和底層的存儲相綁定了，已經具備了一定的物理屬性，而不僅僅像建模場景下的數據指標，僅僅是一個邏輯概念。

通常，這種OLAP的數據指標是領導重點關心的，就會在數據倉庫之上增加這么一層。而需要特別注意的一點，就是如果將所有指標都添加到面向OLAP的數據指標中，其實是對現有的整體開發模式的完全顛覆。

二、為什么說面向OLAP的數據指標系統是現有開發流程的一個顛覆

首先，我們先概略的看下現在的開發流程是什么樣的，僅展示BI報表部分。

【業務系統數據】—{導入}—【數據湖/數據倉庫】—{加工/清洗}—【數據倉庫】—{導入}—【OLAP引擎（MySQL或者HOLO等）】—{授權}—【BI系統展示】

那有了面向OLAP的數據指標系統，我們會替換哪些部分那。個人認為—{加工/清洗}—【數據倉庫】—{導入}—【OLAP引擎（MySQL或者HOLO等）】—{授權}—。這一部分都會被替換掉，其中又分為三個環節。

環節一：當有了面向OLAP的指標系統后，預期的效果是對基礎指標統一口徑，在指標系統生成之后，業務用戶能夠使用基礎指標自己進行邏輯加工，生成符合指標了，所以—{加工/清洗}—【數據倉庫】這一部分會被替換掉。

環節二：當新生成的復合指標天然在面向OLAP的指標系統中時，就不需要將原來數倉中生成的指標再導入到OLAP類型的引擎中，所以—{導入}—【OLAP引擎（MySQL或者HOLO等）】這一部分會被替換掉。

環節三：當不導入傳統的OLAP計算引擎，要使用面向OLAP數據指標系統時，對BI的授權就需要調整。這是第三部分被替換掉。

所以，如果是一個全新的數據指標系統的話，和現在的數據加工流程方式，個人認為是顛覆性的調整。

三、這種顛覆的開發形式是否能夠落地

這種面向OLAP的數據指標系統，其實是在數據倉庫和上層應用之間，增加了新的一層，相當于重構了整個鏈路。

就拿最普遍的 BI 報表系統來說，指標平臺開發的指標如何去 BI 中使用，很多廠商說我們的指標平臺支持開發指標API 服務，通過 API 對接 BI 系統。

一個指標一個 API？還是一批指標一個 API？

此外，要知道目前多數 BI 平臺，都是基于數據集進行圖表和報表開發的，指標和數據集如何融合？ 另外一個，就是權限問題，指標平臺自身有賬號和權限管控體系，BI 系統也有自己的賬號和權限體系，如何確保數據安全管控？

如果企業有實力提供端到端的數據工具，從數據上報、數據中臺、指標平臺、BI 可視化等工具都是自家的，也不是不行，總是有辦法兼容和整合指標和數據集的。

但還是需要拋棄現在的整個鏈路，是不是有這個勇氣？以及能夠帶來多少好處？也都決定是否能夠落地。

四、一種不一定對的想法

雖然，上面說這種指標系統是一個顛覆性的過程，但是個人想有一個比較折中的方案。就是將主要的指標數據，在加工好之后同步到一個OLAP系統中，成為公司級別的統一指標庫。所有，相近的指標都已這個系統內的為準。僅僅是一個想法。不知道是不是合適。

五、總結

大數據領域各種概念橫行，因為是一個實踐的學科。大家也都不追求同一個概念的統一。所以，在一些概念理解上會出現不一致的情況。還是一直說的，需要個人或者一個組織內，能夠對一些概念達成統一。