处理数据对多数企业来说充满挑战，快速和准确的应对数据处理是当今企业的核心竞争力，可以帮助企业从竞争中脱颖而出。因此，越来越多的企业意识数据处理的战略价值。数据仓库是企业着手数据系统建设时绕不开的概念。
本篇文章将重点介绍数据仓库及其组成部分，以及建立数据仓库必须考虑的问题和知识点。
数据仓库的基本概念
数据仓库（简称数仓）是一个决策支持系统。和企业经营中的业务系统（如CRM或人力资源系统）不同的是，数据仓库主要通过企业内部的可用数据来支持决策。而业务系统主要专注于运营需求，例如薪酬和资源分配。
数仓实施确保数据安全
数据安全怎么强调都不为过，同时数据安全又是多方面的，例如数据泄露等。数据仓库落地的每个阶段都需要考虑靠谱的安全策略。其中权限的设置又是重中之重，合理的权限设置可以让使用者在获得有效数据的同时又不至于修改和访问越级的内容。
数仓搭建初衷的灵魂拷问
了解了数据仓库的基础，我们再定义谁是数仓的用户，通过什么样的方法建模以及涵盖哪些主题。
在数据仓库开发的早期阶段需要调研不同部门的负责人，他们会清楚谁负责哪些业务的哪些关键指标。所以，相关部门负责人会帮助数仓项目负责人理清一些问题，如 "我在哪里可以找到有用的数据？"、 "我们要用什么数据进行分析？"
选用哪种数仓建模方法？
数仓建模是业务和技术的平衡术，真正考验了设计者的智慧。所以，选择合适的数仓建模方法很重要，最常见的是Inmon方法和Kimball方法：
Inmon方法，又称为“范式建模”，其历史悠久。在数据库早期发展阶段“范式建模”和Oracle、Teradata一同成熟。范式建模最大的特点就是数据不冗余，这既和Oracle、Teradata等事务型数据库的特点紧密相关，同时也由于早期存储成本较高，通过数据不冗余自然也会能够节省IT成本。 Kimball方法，又称作“维度建模”，Ralph Kimball也被认为是数据仓库之父。维度建模与范式建模相比，尽管存在数据冗余，但是维度数仓可以被分析系统直接访问。维度建模方法伴随着大数据平台的不断普及，被更多行业同仁实践。
这两种架构有很多相似之处：1）都是假设操作型系统和分析型系统是分离的；2）数据源众多；3）ETL整合了多种操作型系统的信息集中到一个企业数据仓库上。
对于数据仓库的建模方法始终存在许多不同的看法，甚至有人把Inmon和Kimball之争称之为数据仓库界的“宗教战争”。当然，也有很多人认为二者都存在一定的问题，因此近些年提出了“降范建模”，将范式建模和维度建模相结合，这也存在一些数据冗余。
如果你从事的是广告行业数据管理，也可以考虑下CDP/DMP。但是客户数据平台（CDP）其实并不是数据仓库架构，倒是可以作为湖仓一体的方案。关于湖仓一体，我们会在接下来的文章进一步讨论。
为数据仓库分层
接下来我们一起看看数据是如何从应用程序流向数据仓库的，整体可以分为贴源层、整合模型层、汇总层、应用集市层。
贴源层：尽量保持源系统数据原貌，提供基于业务数据原貌的访问。 整合模型层：长期、细致、整合的数据存储，为各类业务需求提供支持。 汇总层：提供相对中性，具有业务意义的初级数据加工，支持上层应用的数据加工，或供业务人员访问。 应用集市层：按需设计，提供特定应用支持。
关于Cube：什么时候需要Cube的支持？例如，当查找一个零售商的地址时，可以使用特定的值进行查找（商店地址）。但是，如果你想了解在某个城市有多少家商店时，Cube就有了用武之地。当下，也有新的类似Cube的方法出现，比如指标系统，通过预加工企业需要的指标快速进行业务分析和监测。
在云上搭建基础设施
早期的数据多为结构化格式（大部分来自关系型数据库）或来自网络服务的半结构化格式（旧SOA服务的XML格式），人们通过正则表达式来提取单个字段的数据。随着时间的推移数据正呈指数增长，这就需要投资大量基础设施来存储数据。
如今，公有云的出现让基础设施建设成本大幅降低。包括AWS和Azure在等云厂商正在不断的为数据云存储解布道。云服务为很多企业打开了基础设施新的大门，当然，新的服务配置和管理也会为用户带来新的挑战。
因此，在云上迁移和重建现有的数据系统还应保持谨慎，可以尝试将数据仓库分阶段向云端迁移。
小结
正确设计数据仓库本身就是一个挑战。即使是经验丰富的数据架构师也会遇到需求不明确、开发过程复杂等层出不穷的问题，最终企业的大数据处理愿景可能会渐行渐远。
找到合适的数仓产品
OushuDB 是新一代极速云数仓，可以帮助企业轻松构建核心数仓、数据集市、实时数仓以及湖仓一体数据平台。
