蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  商業(yè)智能BI直連業(yè)務(wù)數(shù)據(jù)庫做報表的延遲風險

發(fā)布日期：2022/5/27 9:37:25      瀏覽量：

商業(yè)智能BI直連業(yè)務(wù)數(shù)據(jù)庫做數(shù)據(jù)可視化分析、做報表到底行不行，從技術(shù)的角度沒有問題，從架構(gòu)的角度不可行。這種做法就像在沙漠上建房子一樣，建一層平房可能沒有問題，建幾層樓房一定會出問題。

什么是商業(yè)智能BI直連數(shù)據(jù)庫

大家一定要注意一下，我們通常講到的商業(yè)智能BI直連數(shù)據(jù)庫，不是指的直連原始業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源數(shù)據(jù)庫，而是數(shù)據(jù)倉庫的數(shù)據(jù)庫。在原始業(yè)務(wù)系統(tǒng)和商業(yè)智能BI前端數(shù)據(jù)可視化之間是有一層數(shù)據(jù)倉庫來做隔離的。

商業(yè)智能BI架構(gòu) - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

我們有的企業(yè)一看商業(yè)智能BI工具可以直接連接到底層業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫數(shù)據(jù)表，就感覺這種方式很好，很便捷啊，直接可以讀取表結(jié)構(gòu)，然后簡單的左關(guān)聯(lián)、右關(guān)聯(lián)，就可以快速的拖拉拽出報表。反而覺得商業(yè)智能BI和底層業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫中間弄個數(shù)據(jù)倉庫很麻煩，又是建模、又是ETL，又看不到底層原始表結(jié)構(gòu)，還是沒有直連業(yè)務(wù)系統(tǒng)數(shù)據(jù)源方便。

這種理解是錯誤的，這種想通過商業(yè)智能BI和底層業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫直連避免掉ETL、SQL的想法也是完全錯誤的，一個典型的想走捷徑的想法。到最后這種商業(yè)智能BI架構(gòu)實現(xiàn)方式未來一定會有很大的風險，失敗的可能性非常高，我們把它叫做延遲風險。

什么是商業(yè)智能BI直連數(shù)據(jù)庫延遲風險

什么叫延遲風險，就是當前可能不會有太大的問題，延遲一段時間風險就會出現(xiàn)。

為什么商業(yè)智能BI和底層業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫直連，這種做法會存在延遲風險呢，主要有以下幾個方面的原因：

第一，企業(yè)底層的業(yè)務(wù)系統(tǒng)會在未來某一個時間節(jié)點會出現(xiàn)升級、迭代甚至替換的可能。

第二，企業(yè)的業(yè)務(wù)會不斷的發(fā)生變化和調(diào)整，帶來的就是一些業(yè)務(wù)計算規(guī)則發(fā)生變化，業(yè)務(wù)規(guī)則的變化就會導(dǎo)致指標計算邏輯發(fā)生調(diào)整。

上面這兩個點都會引起原有報表SQL取數(shù)邏輯對底層數(shù)據(jù)庫表的依賴關(guān)系發(fā)生變化，底層數(shù)據(jù)和結(jié)構(gòu)改變了，就得動報表，商業(yè)智能BI就有可能出現(xiàn)問題。 因為公共業(yè)務(wù)邏輯的計算沒有下沉到數(shù)據(jù)倉庫，不具備復(fù)用性。

可視化大屏 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

比如商業(yè)智能BI中一個指標在這個數(shù)據(jù)可視化頁面有一套計算邏輯寫了一遍，到了另外一個數(shù)據(jù)可視化頁面使用到了同樣的指標，這個指標可能又要寫一邊邏輯。當邏輯發(fā)生變化，就得一個一個數(shù)據(jù)可視化頁面打開去修改。并且是大量的、反復(fù)的修改。為什么？這是因為在這種商業(yè)智能BI架構(gòu)下，數(shù)據(jù)可視化頁面和底層業(yè)務(wù)數(shù)據(jù)表的耦合程度太高太深了。

正確的商業(yè)智能BI架構(gòu)是什么，數(shù)據(jù)可視化頁面應(yīng)該綁定的是指標，而不是指標的計算邏輯，不是SQL計算邏輯。指標的SQL計算邏輯下沉到底層數(shù)據(jù)倉庫，這樣即使要做調(diào)整，也不是數(shù)據(jù)可視化頁面做調(diào)整，而是底層數(shù)據(jù)倉庫的取數(shù)邏輯做調(diào)整。

第三，直連業(yè)務(wù)系統(tǒng)數(shù)據(jù)源，商業(yè)智能BI數(shù)據(jù)可視化頁面大量的并發(fā)查詢是直接訪問到業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫，這種操作對業(yè)務(wù)系統(tǒng)IO資源消耗非常的高。查詢多了會壓垮業(yè)務(wù)系統(tǒng)，影響到業(yè)務(wù)系統(tǒng)的使用。

第四，有些計算邏輯不是一個簡單的SQL關(guān)聯(lián)就能解決，可能會非常的復(fù)雜，這種直連的方式中間的邏輯計算就沒有任何緩沖的可能，沒有辦法做邏輯優(yōu)化，查詢效率和性能會非常低。

數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

所以，商業(yè)智能BI直連業(yè)務(wù)系統(tǒng)數(shù)據(jù)源是讓企業(yè)能夠一眼看明白的架構(gòu)方式，但同時它也是一種很不專業(yè)、非常糟糕的開發(fā)方式。我碰到過不少的企業(yè)最開始上商業(yè)智能BI，因為對商業(yè)智能BI不了解不熟悉，就是這么去實現(xiàn)的，后面根本推不動，沒有辦法重新再開發(fā)一遍，投入更大。

商業(yè)智能BI直連數(shù)據(jù)倉庫數(shù)據(jù)庫

如果把商業(yè)智能BI直連業(yè)務(wù)數(shù)據(jù)源數(shù)據(jù)變成商業(yè)智能BI直連數(shù)據(jù)倉庫數(shù)據(jù)庫，有什么好處呢？

第一，底層業(yè)務(wù)系統(tǒng)怎么更換、迭代，數(shù)據(jù)倉庫在中間做了隔離，盡可能不會影響到上層的報表，也就是商業(yè)智能BI，只是往下更換了從新業(yè)務(wù)系統(tǒng)取數(shù)的ETL業(yè)務(wù)計算邏輯，整體模型架構(gòu)還是穩(wěn)健的。

第二，業(yè)務(wù)邏輯調(diào)整也是如此，在數(shù)據(jù)倉庫模型中，只是局部的邏輯調(diào)整，復(fù)用性比較高。建數(shù)據(jù)倉庫的目的之一就是公共指標下沉、計算邏輯下沉，在報表端只綁定指標，而非業(yè)務(wù)邏輯，采用后端建模的方式。所以，即使某個報表的指標有問題，商業(yè)智能BI中數(shù)據(jù)可視化頁面也不用修改，而是在數(shù)據(jù)倉庫中修改ETL取數(shù)邏輯，對整體數(shù)據(jù)可視化頁面報表沒有大的影響。

數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

第三，商業(yè)智能BI的查詢是基于數(shù)據(jù)倉庫的，跟業(yè)務(wù)系統(tǒng)沒有關(guān)系，查詢壓力只會落在數(shù)據(jù)倉庫上，而不是傳遞到業(yè)務(wù)系統(tǒng)本身。

第四，通過數(shù)據(jù)倉庫的分層解決建模、模型優(yōu)化、查詢性能優(yōu)化，以空間換時間來提升前端商業(yè)智能BI可視化訪問數(shù)據(jù)倉庫數(shù)據(jù)的查詢效率。

所以，商業(yè)智能BI的直連連的是什么，連的是數(shù)據(jù)倉庫，而不是業(yè)務(wù)系統(tǒng)數(shù)據(jù)源。

也有一些企業(yè)因為對數(shù)據(jù)倉庫不了解，所以在業(yè)務(wù)系統(tǒng)和商業(yè)智能BI前端之間建了一個中間庫做隔離，這樣是不是會好一些。確實如此，只要有隔離就會好一些，中間庫也是一個數(shù)據(jù)庫，跟數(shù)據(jù)倉庫一樣能做一些緩沖。

但數(shù)據(jù)倉庫與中間庫的差異就在于，數(shù)據(jù)倉庫不僅僅只考慮系統(tǒng)之間的松耦合、隔離的問題，更加考慮了從業(yè)務(wù)系統(tǒng)數(shù)據(jù)傳遞到前端商業(yè)智能BI數(shù)據(jù)可視化之間的數(shù)據(jù)模型、數(shù)據(jù)分層、數(shù)據(jù)之間的松耦合等一系列復(fù)雜問題。所以一個是系統(tǒng)的松耦合，一個是除了系統(tǒng)松耦合之外，更加考慮到了數(shù)據(jù)、邏輯處理、分析模型的松耦合關(guān)系。