何時使用三角洲湖與關係數據庫作為BI報告的來源?

[prasadvaze]

承擔你所有的數據存在於三角洲表和SQL server,這樣你有一個選擇的報告。有人可以分享想法“在什麼情況下你不會希望報告從三角洲創建表,而使用傳統的關係數據庫源和為什麼”。現在可以創建報告三角洲表使用BI工具(Qlik、SSRS、表等)

例如交互式查詢/報告更好的關係數據庫與三角洲湖因為性能等。(這可能並不一定是正確的),業務用戶不理解所涉及的步驟設置火花集群和連接三角洲從BI工具表,這是一個麻煩(或培訓問題?)。我感興趣是什麼技術和非技術原因人認為不是指向BI工具為報告三角洲湖

[Ryan_Chynoweth]

雖然這可能沒有直接回答你的問題,我認為這是重要的考慮總體擁有成本的存儲和維護兩套數據。

作為一個例子,假設我們攝取數據雲存儲並使用磚過程通過三角洲湖。此時數據“報告準備好了”,然後我們寫數據到SQL服務器。從這個意義上說你有額外的計算成本寫數據,SQL Server的額外的存儲成本,和總管道會跑得更遠,因為有額外的/不必要的步驟。所以在大多數情況下,它讀取數據有意義使用BI工具直接從三角洲湖。

在大多數情況下,我們容易集成BI工具。例如,用戶可以輕鬆地使用表連接到一個磚的SQL端點消費數據直接從磚使用內置的連接器。這個連接都可以使用UI的BI工具。SQL端點是很容易管理,用戶隻需要選擇一個大小(小、中、大等)並單擊create。

與磚SQL是更常見的以來關係數據庫數據磚滿足必要的需求。

我想說,如果你采購一個web應用程序的數據可能更有意義數據在關係數據庫中。但是你特別提到了BI工具。

[prasadvaze]

@Ryan Chynoweth你為什麼不推薦使用三角洲湖作為web應用程序的後端?這是OLAP和OLTP應用程序,對嗎?

所以如果我們想解決分析報告才會消除關係數據庫或MPP db(像雪花,突觸,紅移)代替三角洲湖嗎?這一戰略的挑戰你預見嗎?類似的數據安全,細粒度訪問控製,缺乏外鍵約束,任何東西嗎?

三角洲的表查詢性能降低版本數量的增長與每筆交易在桌上,它創建新版本的表(並保持,直到吸塵是慣例)

[Ryan_Chynoweth]

是的三角洲主要用於OLAP應用程序類型。Web應用程序通常會使用一個高並發性即OLTP事務數據庫。這就是為什麼你可能想要一個事務性的數據庫。

如果你正在尋找一個分析係統然後使用磚+δ湖。這是一個平台,你所有的BI和ML的Beplay体育安卓版本需要。與傳統的數據倉庫(雪花,突觸,紅移)你隻是看著BI類型的工作負載。三角洲允許所有DW特性但湖上的數據。我建議與數據倉庫,因為它將不會減少你的總擁有成本和使你的團隊。與一個Lakehouse具有更好的支持更先進的數據用例。

三角洲性能不降低隨著版本的增長,因為我們保持特定的事務以及數據的快照。看看這個博客詳細描述三角洲是如何工作的。

你在找一個新的分析堆棧為你的團隊呢?

[werners1]

有什麼值得:

我們做所有數據處理在磚和最後我們策劃的數據複製到一個dwh(曆史原因),我們大部分的BI上運行。

這在我看來是一種反模式與直接在我們的數據報告湖(三角洲湖+拚花)消除了數據複製。你獲得時間(複製),少維護和一個複雜的架構。

當然你必須評估如果你BI工具能夠消耗三角洲湖,拚花。或使用SQL端點的磚(或其他SQL引擎)。

我想擺脫我們的數據倉庫盡快。