对一个问题有很好的理解或描述是找到解决方案的先决条件。在这个博客中，我想介绍一个用于分析目的的数据平台的问题描述。传统上，这被称为数据仓库（DW），但标签，如数据集市、大数据平台和数据集线器也在这种情况下使用。我把这个问题描述命名为数据仓库象限。从那以后，我在与客户、合作伙伴、分析师、同事和学生的许多会议上都使用了它。它有一个很好的效果，那就是当人们试图定位自己的位置和目的地时，会考虑自己的数据平台（问题）。这是非常有用的，因为它触发了正确的对话框。只有在正确的问题上努力，你才能找到正确的答案。或者换个角度？如果你从错误的问题开始—这种情况比你预期的要频繁得多—那么你就不可能找到正确的答案。

数据仓库象限（图1）有两个相互独立的问题维度：

图1:DW象限。

现在，这两个维度创建了一个可分为四个（子）象限的空间。

左下角：数据集市

在这里，典型的场景是：

部门数据集市（如营销部门）建立了一个小型的，甚至可能是一个基于开源的RDBMS系统，并创建了一些有助于跟踪营销活动的表。这些表保存了被接触的客户的数据、他们对问卷的反应或回答、地址等。SQL或其他视图允许进行一些基本的评估。几周后，市场营销活动结束，几乎没有任何或没有数据被添加，数据、底层表和视图随着不再使用而慢慢"消亡"。可能，一两个同事就足以处理系统，包括设置系统和创建表和视图。他们非常了解数据模型，数据量是可管理的，更改管理几乎不相关，因为数据模型要么简单（因此更改很简单），淘客推广，要么寿命有限（≈营销活动的持续时间）。一个可操作的数据集市。这也可以是通过特定的操作应用程序管理的数据，就像在ERP、CRM或SRM系统中一样。在这里，表、数据被给出，数据一致性由相关的应用程序管理。由于分析的性质仅限于系统中的数据，因此不需要涉及其他来源的额外数据。通常情况下，数据量和相关表的数量是有限的，企业软件正版化，并不构成真正的挑战。

左上角：超大数据仓库（VLDW）

在这里，一个典型的情况是，有少量的业务流程，每个流程都通过一个可操作的RDBMS来支持，其中至少有一个流程生成大量数据。试想一下，通过亚马逊网站提交的销售订单本文引用了2013年网络星期一每秒426件商品的订单。现在，模型的复杂性相当简单，因为只涉及少数业务流程，因此涉及表（描述这些流程）。然而，主要的挑战来自于这些过程中至少有一个过程产生的大量数据。因此，诸如数据库分区、索引、其他调整、横向扩展、并行处理等主题占主导地位，而管理数据模型或其生命周期则相当简单。

右下角：企业数据仓库（EDW）

当我们谈论企业时，我们会看到一大堆底层业务流程：财务、人力资源、，客户关系管理、供应链、订单、交货、帐单等等。这些过程中的每一个通常都由某个操作系统支持，信息大数据，该操作系统有一个相关的数据库，其中存储描述各个过程中正在进行的活动的数据。因为这些流程之间存在自然的依赖关系和关系（在交付或计费之前必须有一个订单），所以业务分析人员不仅要以孤立的方式探索和分析这些业务流程，而且还要查看这些依赖关系和重叠。每个人都明白，如果供应链运作不好，订单可能会受到阻碍。为了用事实来强调这一点，来自供应链和订单系统的数据需要相互关联和组合，以查看相互影响。

覆盖企业内大量业务流程的数据仓库因此被称为企业数据仓库（EDW）。它们的特点是大量的数据源（反映业务流程），而这些数据源又转化为大量的（关系）表。清理和协调这些表中的数据需要做大量的工作。此外，业务流程及其底层数据之间的依赖关系反映在这些表顶部的语义建模中。总的来说，建立EDW需要大量的知识和IP。这使得它有时很昂贵，但也非常有价值。它得到改变，调整，新的来源得到增加，一些模型得到完善。日常业务的变化（如公司组织结构的变化）转化为EDW的变化。顺便说一下，这也适用于上面提到的其他数据仓库。然而，EDWs的生命周期比其他情况下更为突出。换句话说：在这里，模型复杂性维度的挑战主宰了EDW的生命。

右上角：大数据仓库（BDW）

最后，右上角象限开始与大数据的出现相关。请注意，"大数据"不仅指数据量，还包括迄今为止尚未使用过的数据类型。例如

视频+图像来自电子邮件或社交网络的免费文本复杂的日志和传感器数据