关于数据仓库的架构及3大类组件工具选型

编辑导语：数据分析的前期工作一定要确保无误，才能保证后期在进行数据运用和构建时不出错。当你拿到一个数据分析的任务时，你可以先到数据仓库进行获取。本文作者介绍了企业数据仓库项目上的架构和组件工具管理问题，我们一起来看一下。

关于数据仓库的概念、原理、建设方法论，网上已经有很多内容了，也有很多的经典书籍，本文更想聊聊企业数据仓库项目上的架构和组件工具问题。

先来谈谈架构。

01 企业数据仓库架构

关于数据仓库，有一种简单粗暴的说法，就是“任何数据仓库都是通过数据集成工具连接一端的原始数据和另一端的分析界面的数据库”。

数据仓库用来管理企业庞大的数据集，提供转换数据、移动数据并将其呈现给终端用户的存储机制。许多架构方法以这样或那样的方式扩展数据仓库的能力，我们讲集中讨论最本质的问题，在不考虑过多技术细节的情况下，整个层次架构可以被划分为4层：

原始数据层（数据源）

数据仓库架构形态

数据的采集、收集、清洗和转换

应用分析层

1. 单层架构（直连）

大多数情况下，数据仓库是一个关系型数据库，包含了允许多维数据的模块，或者分为多个易于访问的多主题信息域，最简单的数据仓库只有一层架构。

单层架构就以为着数据仓库与分析接口直接连接（直连），终端用户可以直接查询。但简单有其弊端和适用性：

传统上数据仓库的存储从 100GB 起，直连可能会导致数据查询处理速度慢，因为要直接从数据仓库查询准确的数据，或者是准确的输入，过程中要过滤掉很多非必要数据，这对数据库以及前端BI工具的性能要求相当高，基本性能不会太高。

另外，在处理复杂维度分析时性能也受限，由于其缓慢性和不可预测性，很少应用在大型数据平台。要执行高级数据查询，数据仓库应该在低级实例下被扩展从而简化数据查询。

2. 两层数据架构（数据集市层）

两层架构就是在前端应用层和 EDW 层增加了数据集市层。数据集市是包含特定主题域信息的低级别存储库。简而言之，它是一个在特定主题（例如销售、运营、市场等）下延伸了 EDW 的较小数据库。

这种方式解决了部门级数据查询和分析的问题，每个部门都更容易访问到所需数据，因为每个集市仅包含给定域信息，另外，数据集市限制了终端用户对数据的访问范围，设置了一道数据权限。但是创建数据集市层需要额外的硬件资源，并集成它与数据平台其他的数据库。

3. 三层架构（OLAP）

在数据集市层之上，我们通常会使用联机分析（OLAP）处理多维数据集（cube）。OLAP 数据集是一类从多维度描述数据的特定数据库。关系型数据库只能表示二维数据，而 OLAP 允许在多维度下编译数据并且在维度之间移动。

OLAP专用于维度建模数据的分析，然后通过BI将OLAP的结果以图表的方式展现出来。

OLAP 的业务价值在于允许对数据进行切片、切片以多维度分析，以提供对所有企业数据或特定数据集市的访问，现在基本已成为主流的架构应用。

以下这张架构图使用最广泛的体系结构，它由顶层、中层和底层组成。

底层：数据仓库服务器的数据库作为底层，通常是一个关系数据库系统，使用后端工具将数据清理、转换并加载到该层。

中间层：数据仓库中的中间层是使用ROLAP或MOLAP模型实现的OLAP服务器。对于用户，此应用程序层显示数据库的抽象视图，这一层还充当最终用户和数据库之间的中介。

顶层：顶层是前端应用层，连接数据仓库并从数据仓库获取数据或者API，通常的应用包括数据查询、报表制作、BI数据分析、数据挖掘还有一些其他的应用开发。

从功能应用和技术架构来展开，以下是一张中大型企业的很详细的数据仓库架构图了。

数据仓库的4层核心组件：底层源数据库（数据存储方案）、ETL、前端应用、还有OLAP服务。

02 数据仓库数据库

底层的数据仓库服务器通常是一个关系数据库系统(各种表关联的sql统计会更方便一些，非关系型数据库目前在这方面还是有所区别)。常用的方案有Oracle、db2、sqlserve 还有essbase、greenplum、teredata等数据仓库专业解决方案。

1. 采用传统关系型数据库，或经过功能扩展的MPP数据库

① 传统的关系型数据库有：oracle、mysql、DB2

② 大规模并行处理数据库：Vertica、Teradata(商业)、Greenplum (开源)