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认为，若是你的分析须要整合多个系统的数据，若是你要分析历史数据，若是你的业务系统的数据库没法知足查询和分析的性能需求，那么你仍然须要创建数据仓库。先对多个系统的数据进行整合、清洗，而后将清洗过的数据导入到企业级的数据仓库中，才能用于数据分析和展现。