Dynamics AX 2012 在BI分析中創建數據倉庫的必要性

AX系統已有的BI分析架構

對於AX 的BI分析架構，相信你們都瞭解，能夠看Reinhard以前的譯文[譯]Dynamics AX 2012 R2 BI系列-分析的架構 。

AX 的BI分析架構的優點

從圖上咱們能夠看出，AX是弱化了數據倉庫的概念，直接用多維數據集做爲分析報表的數據源。得益於AX與SSAS的深度集成，而且提供了許多預先定義好的多維數據集，能夠很快地製做一個簡單的分析報表。

Dynamics 365技術架構的優點

在新出的Dynamics 365裏，提出了Common Data Model的概念，在必定程度上，從應用的底層解決了多系統數據整合的問題。Reinhard在12月初的微軟技術大會上了解到，Dynamics 365 Operations除了Online版本外，On Premise版也在12月初有了銷售版，感興趣的同窗能夠關注下。

數據倉庫

既然說到了數據倉庫，那麼咱們就來看看什麼是數據倉庫。

數據倉庫的定義

數據倉庫是一個數據庫，這種數據庫的設計，能夠支持商業智能活動：幫助用戶理解和提升組織的績效。它的設計，是用於查詢和分析，而不是事務處理，而且一般包含從交易數據中派生的歷史數據，也包含其餘數據源中的數據。數據倉庫將分析的工做負載，從事務的工做負載中分離出來，讓企業可以整合來自多個數據源的數據。

除了一個關係型數據庫外，一個數據倉庫環境還須要包含ETL解決方案、統計分析、報表、數據挖掘、客戶端分析工具。

數據倉庫須要使用從多個源收集的數據。這些源數據可能來自企業內部本身開發的系統，採購的應用程序，第三方數據提供商，和其餘源。它可能涉及交易，生產，市場，人力資源等。在今天這個大數據的時代，網站上點擊事件的數據可能超過數十億條，還有自動化機器的傳感器產生的大量數據流。

爲何不能將AX做爲數據倉庫來用？

這裏，須要說說AX系統與數據倉庫主要的區別：

環境上的不一樣

二者最大的不一樣，是AX系統實際上是一個OLTP系統，它的設計須要遵循3NF標準。而數據倉庫並不徹底遵循3NF標準。

需求上的不一樣

工做負載

數據倉庫的設計，是爲了適應即席查詢和數據分析。由於對工做負載沒法預知，因此要對大量可能的查詢和分析操做，進行性能優化。

AX系統中，執行的其實大多數都是預先定義好的操做，如更新、寫入、刪除等。

數據修改

數據倉庫通常是經過ETL更新，最終用戶不能直接更新數據倉庫。

AX系統中，最終用戶的修改會持久化到數據庫中，AX系統老是反映每一個商業交易的最新狀態。

架構設計

數據倉庫老是使用部分非規範化的架構，來優化查詢和分析的性能。

AX系統中，老是使用徹底規範的架構，來優化更新、寫入、刪除操做，來保證數據的一致性。

典型操做

數據倉庫的典型查詢，會掃描上百萬的記錄。

AX系統的典型操做，是對某一行記錄進行操做，這隻需訪問少許的記錄。

歷史數據

數據倉庫一般須要存儲幾個月甚至幾年的數據，這些數據爲歷史分析和報表提供支持。

AX系統中，反應的是每一個商業交易的最新狀態。不過有時也會爲了知足當前交易的須要，存儲一些相關的歷史數據。

創建數據倉庫的必要性

傳統BI分析

咱們知道，OLAP Cube通常而言，在性能上要比RDBMS更好。

對於傳統BI分析來講，是須要創建OLAP Cube的。在創建Cube前，通常也會在數據庫使用星型架構創建維度化的模型，將數據清洗好，填充進來，做爲Cube的數據源。這裏的星型架構和OLAP cube其實都屬於數據倉庫的一部分。

AX的BI分析

對於AX而言，是用表或視圖來建立透視，而後定義維度和測量，接着運行分析服務項目嚮導來生成、部署項目，最後對多維數據集進行處理。每次處理，Cube中的數據都會更新，實際上是沒法作歷史數據分析的。

敏捷BI分析

隨着軟件發展的突飛猛進，計算機的硬件也愈來愈先進，彷彿OLAP Cube的優點也沒那麼明顯了。近幾年流行的敏捷BI工具，如Power BI、Tableau、Qlik等，就有意弱化了分析建模的過程。它們使用了內存數據庫、列存儲數據庫等技術，來對數據進行緩存，加快了數據處理、渲染的速度，有時甚至能夠直連生產環境且對生產環境性能的影響微乎其微。那麼使用敏捷BI分析工具還須要創建數據倉庫麼？

Reinhard認爲，若是你的分析須要整合多個系統的數據，若是你要分析歷史數據，若是你的業務系統的數據庫沒法知足查詢和分析的性能需求，那麼你仍然須要創建數據倉庫。先對多個系統的數據進行整合、清洗，而後將清洗過的數據導入到企業級的數據倉庫中，才能用於數據分析和展現。