数据仓库ETL工具箱——架构

本来这一篇是要详细写写ETL的需求部分，比如业务需求、合规需求等。但是码了一百多字发现大部分内容和上一篇都是重复的，因此决定本篇详细讲讲数据仓库的架构。架构中关于元数据、质量控制等我们不多做介绍了，还是详细说说后台和前台。

先来看一张图

 

数据后台主要是负责数据管理的，也是ETL工具集的工作空间。数据后台是不允许用户访问的，所有的抽取、清洗、规格化和提交的动作都是在数据后台进行的；而数据前台是数据的展示区，是提供给最终用户访问的。数据前台中有一个非常重要的部分——数据集市。 数据集市是为了满足业务流程而建立的维表集合。许多数据仓库的学者、专家记忆从业者都将数据集市作为主题区的数据聚集，也就意味着他们把数据集市当作最终用户（BI、数据展示、数据分析等）的业务库。而我个人更喜欢本书中作者所定义的数据集市，它的含义和马爸爸提出的也是现在非常火的数据中台的概念如出一辙。本书中定义的数据集市包括以下几个内容：

1.数据集市是基于数据来源而非最终用户的应用的，比如BI系统、数据分析师所需处理的不同业务的相同维度问题应该是在数据集市中获取的统一的、一致的数据来源。

2.数据集市不仅仅有聚合数据，还包含原子级粒度的数据，并且可以通过数据的血缘关系向下钻取到最低级的数据。

3.数据集市既可以集中式管理又可以分布式管理，以往数仓的建设都是将EDW部署在一台服务器上，而数据集市要等到所需数据到达后才建立，进行独立开发。而随着大数据技术的发展，数据集市和EDW中维表和事实表不同步的问题已经得到了解决。

怎么样？是不是感觉数据集市+交互问题=数据中台，业务层面上解决的是同样的问题，而由于新技术的引入和对历史遗留错误的修复而变成了一个全能并且高大上的新概念。

以往人们都觉得数据仓库只是一个多源的、多维的、聚合的大型数据库，其实数据仓库也有计算、也有数据治理（元数据治理、主数据治理）、也有前后端的区分和管理，而这些被弱化的概念和能力，如今衍生出了新的产品——数据中台。也许杠精们会说，数据中台不是某个产品，我这么说是不对的。的确，数据中台是很好的理论概念，它强化了数仓中被人们弱化和以往的部分，但是看看现在的时长上，动不动就拿个产品出来说我们是做数据中台的，我们可以帮助你的企业提升200%的利润，帮助你的企业将数据流动起来。概念是好的，应该作为发展的指导和完善，而不应用来做欺骗的噱头，虽然商场的确这般真实和残酷，但这种初中往往使真正做技术的人所不耻！

正如中台一样，对于数据仓库来说，它不是一个产品，不是一个项目，不是一个数据模型，更不是一个交易数据库的备份，数据仓库是一个将源系统数据抽取、清洗、规格化、提交到维度数据存储的系统，它是为决策的制定提供查询和分析功能的支撑与实现。

由此可见，ETL的任务就更加重要了。我一直认为，直到现在也同样认为，正如一条SQL语句可以贯穿一个关系型数据库的工作流程一样，一个ETL工具也同样贯穿整个数仓的工作流，更准确的说，ETL就是数仓的工作流。ETL的任务包括但不限于：

•  将数据更有效的提交到最终用户工具
• 通过清洗和转换步骤增加数据的价值
• 保护数据沿袭并进行文档化
• 从原始数据源抽取数据
• 保证数据质量，清洗数据
• 保证来自于各个数据源的数据一致性
• 为查询工具，报表和仪表盘提交物理格式的数据

以上就是本篇介绍的全部内容，下一篇我们将介绍ETL中的数据结构。