在ETL架构中，源数据很少会直接抽取加载到数据仓库EDW，二者之间往往会设置一个源数据的临时存储区域，存储数据在清洗转换前的原始形态，通常被大家称做操作型数据存储，简称ODS，在Kimball维度建模理论中，将其称之为Staging Area（意为部队从一个战场转往另一个战场的集结地），翻译过来称之为数据登台区，如图所示：
上图摘自Ralph Kimball的《数据仓库生命周期工具箱》
为什么需要ODS？
ODS在整个数据中心体系架构中的具有非常重要的作用，体现在以下几点：
统一源数据的数据格式，降低数据清洗转换的复杂性
一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事，比如有时源和目标不能直接连通，数据可能会用文件方式上传上来，这就需要将原始数据先落地到ODS中。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。各种原始数据以统一的格式存放在一个数据库中，更加便于后续的数据清洗与转换。
保留原始数据当时时点的快照，便于数据转换后的校验排错和批次重跑
业务系统中的数据是会发生增删改变化的，尤其是像客户、产品、机构这样的维度数据，其状态和属性都会随着时间不断改变，而数据仓库是需要记录并分析其历史状态的，如缓慢变化维（拉链表）和快照型事实表，在得到最终的统计分析结果之前，数据会经过一层一层的转换加工，期间会有大量的计算和处理逻辑，在ETL开发和运维过程中，经常会发现某些公式或处理逻辑有误，修改之后不得不重跑之前一系列的批次数据，如果之前没有保留这些时点上的原始数据，则很多数据重跑将变得不可能，因为源系统中的部分数据已经发生了变化，另外将数据快照下来也便于和前端统计查询结果进行校验核对，以便找出出错原因。
转移一部分业务系统细节查询的功能，并可以支持实时数据的查询统计
在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、 组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。另外由于从源数据到最终的分析结果，需要经历较长时间的ETL转换，所以一些对实时性要求比较高的查询分析是可以直接从ODS中取数的，比如风控预警和实时仪表盘。
ODS表长什么样？
ODS通常采用数据库进行存储，只存储对数据分析有价值的源数据，数据结构通常和源非常相似，在源表结构基础上会扩充字段以表示数据来源、数据日期、导入时间等审计信息。一个ODS表的例子：
这个表存储每天按时间戳增量抽取的血糖检测记录，名称用O_前缀进行标识。红色区域的字段基本上和源表结构保持一致，也可以只存后期数仓中需要的字段，去掉一些没有必要的字段，另外一些字段类型也可以做简单的改变，但要确保可以记录原始数据的原貌。开头的两个字段是ODS表新增的审计字段，其中ETLBATCHID表示数据的批次号，用于表示是哪个时期（点）的数据，如果数据每天一个批次的话，这里将会存一个数字型日期如20190301（YYYYMMDD），如果是每小时一个批次的话，这里可能会存一个带小时的数字型时间如2019030108（YYYYMMDDHH），之所以存成数字型，是因为数字型占的空间更小，检索更快，另外在书写SQL是也比较简便。当然也可根据需要设为字符型或日期型。PROCESSTIME字段用来表示数据被抽取加载到ODS表的系统时间，该字段也可以省略。另外如果ODS表中的数据来自于多个数据源，则可以增加一个审计字段来表示数据的来源。