如果你身职数据库一职，面对数据处理流程无非是删除分析数据库的历史订单数据，全量更新订单数据到分析数据库，将数据简单清洗，并生成数据集市层，分析处理，产出报表。当然还有其他的数据也是这么处理的，还有日志类的数据，这里不是重点，今天要讲的是数据仓库与ODS的区别。

　　数据仓库与ODS分别指的是什么?

　　数据毕竟是为了市场服务的，所以需求我们要跟上它的节奏，这就对数据系统提出了很大的挑战，导致数据质量下降、生产效率下降!该怎么解决哪?在解决这个问题的过程中，逐步发现了一点苗头：发现我们建立的数据仓库与它的定义不太符合。下面是数据仓库的定义：

　　数据仓库(Data Warehouse)：是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合，用于支持管理决策(Decision Making Support)。

　　很明显我们并不符合相对稳定的和反应历史变化的两个条件，因为类似订单类数据，每天全量更新。这就明显不符合想对稳定这一概念了，更别说反应历史变化了!经过最近的思考，发现自己搭建的系统更符合ODS的定义：

　　ODS：是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。

　　数据仓库与ODS两者有何区别呢?

　　ods是短期的实时的数据，供产品或者运营人员日常使用，而数据仓库是供战略决策使用的数据;ods是可以更新的数据，数据仓库是基本不更新的反应历史变化的数据，还有很多，这里就不一一列举了。讲到这里问题就明晰了，如何能搭建一个体系，既能支持战略决策使用的数据仓库数据，又能兼容业务快速的变化和运营产品人员日常需求的ODS数据哪?

　　数据仓库和ODS并存方案

　　经过调研，发现大体上有三种解法：

　　1、业务数据 - ODS - 数据仓库

　　优点：这样做的好处是ODS的数据与数据仓库的数据高度统一;开发成本低，至少开发一次并应用到ODS即可;可见ODS是发挥承上启下的作用，调研阿里巴巴的数据部门也是这么实现的。

　　缺点：数据仓库需要的所有数据都需要走ODS，那么ODS的灵活性必然受到影响，甚至不利于扩展、系统的灵活性差

　　2、OB - ODS

　　优点：结构简单。一般的初创数据分析团队都是类似的结构，比如我们部门就应该归结到这一范畴

　　缺点：这样所有数据都归结到ODS，长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差

　　3、数据仓库和ODS并行

　　可见这个模型兼顾了上面提高的各自优点，且便于扩展，ODS和数据仓库各做各的，形成优势互补!可以解决现在互联网公司遇到的快速变化、快速开发等特点!特别是对于那些刚刚创建数据团队，数据开发人员紧缺的公司，可以尝试使用这个数据架构解决问题!