我在公司的数据部门工作，每天的订单类数据处理流程大致如下：
- 删除分析数据库的历史订单数据
- 全量更新订单数据到分析数据库。（由于订单核心数据不大，所以经受得起这么折腾）
- 将数据简单清洗，并生成数据集市层
- 分析处理，产出报表。当然还有其他的数据也是这么处理的（比如产品的数据、景区的数据、票种的数据、供应商的数据等等）
还有日志类的数据，这里不是重点，就不介绍了！这么干了一年，发现有如下问题：
- 业务变化很快，比如业务数据表经常变化字段含义、增加各种逻辑数据等
- 业务数据源越来越多，随着品类越来越多，新部门逐步成立，数据源也就越来越多样化
- 需求越来越多，越来越复杂，以前只有大佬想我们要战略数据，可是现在所有的产品和运营都向我们要各种各样的用户行为数据、订单分析数据和竞对优势数据
- 数据的实时行要求越来越高，这到不是说秒级别就看见结果，而是早晨提出个新业务数据需求，晚上就要！
数据毕竟是为了市场服务的，所以需求我们要跟上它的节奏，这就对数据系统提出了很大的挑战，导致数据质量下降、生产效率下降！该怎么解决哪？在解决这个问题的过程中，逐步发现了一点苗头：发现我们建立的数据仓库与它的定义不太符合。下面是数据仓库的定义：
数据仓库（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和数据仓库各做各的，形成优势互补！可以解决现在互联网公司遇到的快速变化、快速开发等特点！特别是对于那些刚刚创建数据团队，数据开发人员紧缺的公司，可以尝试使用这个数据架构解决问题！
参考资料：
http://wenku.baidu.com/view/c620146c7e21af45b307a86e?fr=prin
http://blog.csdn.net/hero_hegang/article/details/8691912
http://www.cnblogs.com/liqiu/p/4947801.html
