关于数据仓库的概念、原理、建设方法论，网上已经有很多内容了，也有很多的经典书籍，本文更想聊聊企业数据仓库项目上的架构和组件工具问题。
先来谈谈架构。
企业数据仓库架构
关于数据仓库，有一种简单粗暴的说法，就是“任何数据仓库都是通过数据集成工具连接一端的原始数据和另一端的分析界面的数据库”。
数据仓库用来管理企业庞大的数据集，提供转换数据、移动数据并将其呈现给终端用户的存储机制。许多架构方法以这样或那样的方式扩展数据仓库的能力，我们讲集中讨论最本质的问题，在不考虑过多技术细节的情况下，整个层次架构可以被划分为4层：
单层架构（直连）
大多数情况下，数据仓库是一个关系型数据库，包含了允许多维数据的模块，或者分为多个易于访问的多主题信息域，最简单的数据仓库只有一层架构。
单层架构就以为着数据仓库与分析接口直接连接（直连），终端用户可以直接查询。但简单有其弊端和适用性：
传统上数据仓库的存储从 100GB 起，直连可能会导致数据查询处理速度慢，因为要直接从数据仓库查询准确的数据，或者是准确的输入，过程中要过滤掉很多非必要数据，这对数据库以及前端BI工具的性能要求相当高，基本性能不会太高。
另外，在处理复杂维度分析时性能也受限，由于其缓慢性和不可预测性，很少应用在大型数据平台。要执行高级数据查询，数据仓库应该在低级实例下被扩展从而简化数据查询。
两层数据架构（数据集市层）
两层架构就是在前端应用层和 EDW 层增加了数据集市层。数据集市是包含特定主题域信息的低级别存储库。简而言之，它是一个在特定主题（例如销售、运营、市场等）下延伸了 EDW 的较小数据库。
这种方式解决了部门级数据查询和分析的问题，每个部门都更容易访问到所需数据，因为每个集市仅包含给定域信息，另外，数据集市限制了终端用户对数据的访问范围，设置了一道数据权限。但是创建数据集市层需要额外的硬件资源，并集成它与数据平台其他的数据库。
三层架构（OLAP）
在数据集市层之上，我们通常会使用联机分析（OLAP）处理多维数据集（cube）。OLAP 数据集是一类从多维度描述数据的特定数据库。关系型数据库只能表示二维数据，而 OLAP 允许在多维度下编译数据并且在维度之间移动。
OLAP专用于维度建模数据的分析，然后通过BI将OLAP的结果以图表的方式展现出来。
OLAP 的业务价值在于允许对数据进行切片、切片以多维度分析，以提供对所有企业数据或特定数据集市的访问，现在基本已成为主流的架构应用。以下这张架构图使用最广泛的体系结构，它由顶层、中层和底层组成。
底层：数据仓库服务器的数据库作为底层，通常是一个关系数据库系统，使用后端工具将数据清理、转换并加载到该层。中间层：数据仓库中的中间层是使用ROLAP或MOLAP模型实现的OLAP服务器。对于用户，此应用程序层显示数据库的抽象视图，这一层还充当最终用户和数据库之间的中介。顶层：顶层是前端应用层，连接数据仓库并从数据仓库获取数据或者API，通常的应用包括数据查询、报表制作、BI数据分析、数据挖掘还有一些其他的应用开发。从功能应用和技术架构来展开，以下是一张中大型企业的很详细的数据仓库架构图了。 数据仓库的4层核心组件：底层源数据库（数据存储方案）、ETL、前端应用、还有OLAP服务。底层的数据仓库服务器通常是一个关系数据库系统(各种表关联的sql统计会更方便一些，非关系型数据库目前在这方面还是有所区别)。常用的方案有Oracle、db2、sqlserve 还有essbase、greenplum、teredata等数据仓库专业解决方案。1、采用传统关系型数据库，或经过功能扩展的MPP数据库① 传统的关系型数据库有：oracle、mysql、DB2② 大规模并行处理数据库：Vertica、Teradata(商业)、Greenplum (开源)Teradata老江湖了，银行业使用较多，但成本也是真的贵，目前我们做项目较多的是用Greenplum，算是业界最快和最高性价比的高端数据仓库解决方案，Greenplum是基于PostgreSQL的，于2015年开源。我知道的国内四大行有3家在用，5大物流公司有4家在用，不少公司在从Teradata 迁移到 GP。这套方案有多通用不用多说了，通常是这样的组合：TB级数据用PG，百TB级数据用GP，PB级i上数据用Hadoop。下面整理了一张传统数据仓库架构、GP还有Hadoop大数据平台的对比图。数据来源、转换和迁移工具用于执行将数据转换为数据仓库中的统一格式所需的所有转换、摘要和所有更改，它们也称为提取、转换和加载工具。其功能包括:全量抽取：适用于数据量小且不容易判断其数据发生改变的诸如关系表，维度表，配置表等增量抽取：适用于数据量大，为了节省抽取时间而采用的抽取策略规范数据格式：比如把所有日期都规范成YYYY-MM-DD的格式数据转码：把一个源数据中用编码表示的字段通过关联编码表转换成代表其真实意义的值数据标准统一：比如在源数据中表示男女的方式有很多种，在抽取的时候直接根据模型中定义的值做转化。转换：用ODS中的增量或者全量数据来刷新DW中的表加载：每insert数据到一张表都可以称为数据加载关于ETL工具的选型，这里罗列了一张对比表，基本囊括常用的ETL工具。数据仓库平台的搭建，最终是为了梳理出有用数据、提供有价值信息，帮助业务做出正确决策。前端应用工具主要就是和数据仓库不同环节的数据交互，这些应用一般可以分为4类：其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。通常用来生成一些固定类报表，自动化报表，支持打印和计算等大批量批处理作业。流行的报表工具，在旧数据仓库时代主要是IBM的BO、Oracle的BIEE、还有微软和cognos，整体打包在数据仓库解决方案里，报表作为一个组件存在。但是随着传统型数仓，架构重成本贵，很多公司在项目上会自己考虑设计架构，而不是直接强套昂贵的解决方案，包括很多开源组件/平台的使用。有关报表工具，现在项目上用的比较多的是帆软FineReport，针对不同企业数仓架构以及报表需求的适用性较广。比如对接各种数据库直接生成报表；对采集整理后的数据进行多维报表展现，支撑业务分析报表；对接集团性数据仓库，构建数据中心平台，形成决策分析平台。
FineReport功能架构
BI一般都集成了OLAP服务器和报表展示功能。分析型BI基于多维数据库的概念，能多维视角分析数据，通常是从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端BI分析工具读取。BI在前端通过拖拽数据字段，多维度实施展现数据，最终生成各种分析报告。常用的BI工具有PowerBI、Tableau、FineBI，还有开源的superset。个人使用多用前两者，企业项目上选型多用FineBI，因为要考虑性能、服务方案等。剩余就是自研或者开源，superset算是比较公认的开源BI。
BI工具做什么的不多说了，在项目选型的时候主要考虑上手难度（考虑没技术基础的业务用），数据处理性能，其他就是技术选型的事，还有成本。OLAP是将数据多维视角呈现分析，数据挖掘则是应用的算法来揭示数据的规律性，比如相关性、模式和趋势等。数据挖掘工具就是做这个的，它能让一些算法和过程自动化。举个例子，比如银行里数据仓库以面向“客户”为主题进行数据的存储，OLAP可以实现数据按照客户的基本信息、储蓄账户信息、历史余额信息、银行交易日志等，以报表或者可视化的方式呈现分析，多方面掌握客户动态，发现数据的问题，更好的针对不同类型用户进行特定性营销。而数据挖掘则是通过历史数据建立模型，在拟合历史的基础上，分析未来趋势，判断哪些因素的改变将很可能意味着客户的最终流失，进而避免其发生。 常用的数据挖掘工具，R、Python还有SPSS，基本都是开源个人可用的。和BI和报表不同，市面上少有为客户提供定制化数据分析和挖掘的商业工具或者项目服务，因为行业性太强，需要非常熟悉业务、数据、平台，所以我见过基本都是自己养数据分析团队或者挖这类的人才。以上报表型、分析型的数据产品，但也会有延申出来的各种特定业务的数据决策系统，比如银行业基于管理层监控的的行长驾驶舱、零售业基于门店数据经营的决策系统，以及电商平台的营销参谋（输入营销目标及参数，比如要开展双十一母婴市场的促销活动，系统可以基于以往海量数据计算出应该选择什么品类的商品，在什么用户群中，以什么形式开展活动效果会更佳），都是基于这样的逻辑——基于业务深度应用。此时数仓就是提供一个服务平台的角色，比如现在很火的数据中台也大体是这个逻辑，将数据服务化，具体不懂就不班门弄斧了。在这三层之间其实还有中间层OLAP服务器，典型实现为ROLAP模型或MOLAP模型。现在很多成熟的BI工具都是集成了OLAP服务器的，所以通常我们只需要选择ETL工具以及存储方案和可视化BI方案即可，所以OLAP本文也就不多讲了。
【END】
扩展阅读：【实时数仓资料解决方案、案例】已为读者朋友准备好了，下方公众号“数据仓库与Python大数据”后台回复“实时数仓”，转发即可下载。
感谢阅读，本次分享的内容就结束了。本公众号致力于建设数仓领域知识技术人文共享平台，目前保持日更，每天08:16发文，为你提供优秀的数据领域的分享。加群可加v：iom1128，备注：数据。