关于数据仓库中数据分层，每个企业根据自己的业务需求可以有不同的划分。但一般会分为四个层：数据运营层、数据仓库层、数据服务层、数据集市。
1. 数据运营层（ODS - Operational Data Store）
- 数据运营层，也称数据准备区或者贴源层。它是指数据仓库源头系统的数据表通常会原封不动的存储一份，从而作为后续数据仓库加工数据的来源。ODS层数据的来源方式包括业务数据库、应用的埋点数据、消息队列等。
2. 数据仓库层（DW - Data Warehouse）：数据仓库层由下到上为细节数据层（DWD - Data Warehouse Details），数据基础层（DWB - Data Warehouse Base）和数据服务层（DWS - Data Warehouse Service）三层。
- 细节数据层是业务层与数据仓库的隔离层，主要对数据运营层做一些数据清洗和规范化的操作，包括去除空值、脏数据等等。
- 数据基础层里存储的是客观数据，一般用于中间层，可以认为是大量指标的数据层。
- 数据服务层基于数据基础层上的基础数据，整合汇总成分析某一个主题域的服务数据层，一般是宽表。用于提供后续的业务查询，OLAP分析，数据分发等。
3. 数据服务层/应用层（ADS - Application Data Service）
- 应用数据服务主要是提供数据产品和数据分析使用的数据，一般供线上系统使用。通常来说，报表数据或者大宽表就放在这里。
4. 数据集市（DM - Data Mart）
- 数据集市是为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（Subject Area）。
早期的数仓建设主要是把企业的业务数据库（比如ERP、CRM、SCM）等数据按照决策分析的要求建模并汇总到数据仓库引擎中。其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。随着企业信息化的发展，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求。同时，互联网的在线特性也对实时性提出了要求，比如用户反欺诈、用户审核等随着用户的暴涨，只靠人工干预是远远不够的。随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这就是 Lambda 架构。随着实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，便出现了以实时事件处理为核心的 Kappa 架构。
二者的区别主要如下：
可以看出，两种架构都有明显的缺陷和不足。偶数科技解决的思路是将实时数仓和离线数仓统一在一个云原生的数仓平台上。
它具有以下几个优点：
- 高容错：对于分布式系统而言，机器宕机是很普遍的情况，因此架构的设计需要是非常健壮的。
- 低延迟：实时计算对于延迟的要求很高，对应的系统读操作和写操作应该是低延迟的，对系统数据的查询响应也应该是低延迟的。
- 可扩展：当数据量或负载突然增加时，系统也应该通过增加更多的机器来维持架构性能。
从数据仓库中数据分层来看，偶数的数据云平台在各层有如下的变化：
- ODS：批流一体统一了数据源，而且ODS原本就不对原始数据做处理，因此可以无需再建表，直接用数据源即可。
- DW：离线/实时业务均需要构建事实明细表。区别在于，离线方案中，我们为了提高明细表的使用便捷程度，往往会把一些常用的维度退化到事实表；而实时方案出于时效性的考虑，倾向于不退化或者只退化不会变的维度这一层根据业务情况的不同。通常情况下，离线建设DWS，是针对比较成熟的业务，将维度逐级上卷。这样做能够将逻辑进行收口，提高下游使用的复用率。汇总层的目的在于预计算、提升效率和保证指标的一致性，实时链路太长，容易造成高的延迟和比较大的资源消耗。
- ADS：功能和用途不变。
- DM: 功能和用途不变。
