在数据仓库实际构建过程中，往往都是快猛糙地直接接入业务系统，订制ETL开发，然后简单进行维度建模，满足业务方的报表分析需求，到这里就建立了数据仓库1.0版本。但是这时候的数据仓库很脆弱，业务方的任何需求变更、以及任何环节的数据质量问题，都会导致整个流程发生剧烈的变动，这时候就需要进行数据分层。数据分层的好处如下：
- 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
- 数据血缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
- 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
- 屏蔽原始数据的异常。
- 屏蔽业务的影响，不必改一次业务就需要重新接入数据。
数据仓库分层架构
逻辑上以把数据仓库分为下面三个层：数据运营层(ODS)、数据仓库层(DW)和数据产品层(APP)
ODS数据运营层
数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪（例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理）、去重（例如在个人资料表中，同一 ID 却有两条重复数据，在接入的时候需要做一步去重）、字段命名规范等一系列操作。
DW数据层库层
在这里，从 ODS 层中获得的数据按照主题基于维度建模理论建立各种数据模型，DW层的数据是ODS层的数据通过ETL清洗、转换、加载生成的。此外，基于性能、重复计算和使用便捷性考虑， DW层除了保存基于维度建模的最细粒度的事实表和维度表，还会基于它们生成一层汇总数据(DW汇总层)。
APP数据应用层
在DW层的基础上，各个业务方可以建立自己的数据集市，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、Mysql 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。原则上不允许应用层直接访问ODS层。
