数据仓库，数据集市，ODS，主数据

Sat, 16 Apr 2016 23:18:27 +0800

数据仓库和数据集市的区别与联系, http://blog.csdn.net/vertour/article/details/8508148

数据仓库和数据集市的区别与联系, http://blog.csdn.net/map_lixiupeng/article/details/41131549

ODS、数据集市、数据仓库的异同点是, https://www.zhihu.com/question/21502959

ODS：操作型数据仓库，最早的数据仓库模型。特点是数据模型采取了贴源设计，业务系统数据库数据结构是怎样的，ODS数据库的结构就是怎样的。所不同的是ODS数据库可以提供数据变化的历史，所以ODS数据库中每张表都会增加一个日期类型，表示数据的时点，将每天数据的变化情况都存下来，这样有利于数据的分析。数据仓库：简称EDW，企业级数据仓库，现在大家都在说的就是这个。所不同的是每个行业的EDW都有一个通用的数据模型，结构精简，扩展性强，应用性强，数据模型不像ODS乃样会有很大的冗余。数据集市：简称DM，以某个应用为出发点而建设的局部DW，为什么这么说，DM只关心自己需要的数据。不会全盘考虑企业整体的数据架构和应用，每个应用都有自己的DM。所以DM可以基于仓库建设也可以独立建设。

作者：RobinMa 链接：https://www.zhihu.com/question/21502959/answer/18793987 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

主数据相比较数据仓库，到底有什么不同， https://www.zhihu.com/question/22288816

用下面这个图来回答下吧 1.MDM只是跨多系统共享的静态数据，不包括动态数据。 2.MDM本身还是属于OLTP应用范畴，ODS和DW属于OLAP范畴。 3.没有MDM前ODS需要从多个业务系统同时抽取静态数据和动态数据，有了MDM系统后，ODS只需要从MDM抽取共享静态数据，这些静态数据已经经过了清理和数据质量管理。 4.MDM有ETL能力，BI系统里面也有ETL能力，ETL只是抽取转换工具而已。

作者：何明璐链接：https://www.zhihu.com/question/22288816/answer/23081823 来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

数据库与数据仓库的本质区别是什么？, https://www.zhihu.com/question/20623931,

10 个回答

37 赞同反对，不会显示你的姓名明说，Sybase，Oracle，MSSQL实际使用经验，24… 灼灼其华之、Best丶Candy、drink629 等人赞同有两个层面/角度来回答这个有趣的问题： 1，逻辑层面/概念层面：数据库和数据仓库其实是一样的或者及其相似的，都是通过某个数据库软件，基于某种数据模型来组织、管理数据。但是，数据库通常更关注业务交易处理（OLTP），而数据仓库更关注数据分析层面（OLAP），由此产生的数据库模型上也会有很大的差异。数据库通常追求交易的速度，交易完整性，数据的一致性，等等，在数据库模型上主要遵从范式模型（1NF，2NF，3NF，等等），从而尽可能减少数据冗余，保证引用完整性；而数据仓库强调数据分析的效率，复杂查询的速度，数据之间的相关性分析，所以在数据库模型上，数据仓库喜欢使用多维模型，从而提高数据分析的效率。 2，产品实现层面：数据库和数据仓库软件是有些不同的，数据库通常使用行式存储，如SAP ASE，Oracle, Microsoft SQL Server，而数据仓库倾向使用列式存储，如SAP IQ，SAP HANA 发布于 2014-02-05 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

10 赞同反对，不会显示你的姓名孙一，专注于电商/零售行业CRM/O2O/精准化营销。 Aven、杨艾森、nipi guan 等人赞同其实技术上数据仓库也是数据库。准备的说，传统系统（OLTP）是面向业务存储，比如ERP，OA等，但由于数据分析的需求，出现"面向分析存储“（OLAP），被称作数据仓库。传统数据库的技术面向trans下的数据一致性，数据仓库面向的是查询性能的优化。但目前随着互联网的发展，No-SQL等技术面向非结构化存储的出现，基本上来说是数据库和数据仓库的中间或衍生状态，在”一致性“相对不重要的情况下解决海量数据的查询和存储问题。发布于 2012-11-28 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

9 赞同反对，不会显示你的姓名 wangye，仓储 kj chen、喻灿、iris 等人赞同简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的 ID 。单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录… 简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢? 让我们先看看关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

欢迎登录长风网获取最新物流资讯。发布于 2015-07-28 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

13 赞同反对，不会显示你的姓名 Greg LI，Data Warehouse Manager @Allianz Global… Rhino、杨大青、Sail Gao 等人赞同数据库向左, 数据仓库向右. 【传统观念,随着大数据概念的介入,应该会有所不同】本来想OLAP啊反范式化啊位图索引啊螺旋式开发啊啥啥的好好回答一下这个问题。看了一下我2003年写的东西，如果不是我失忆了，那就是：“尽管很多东西你早就知道了，却在多年的实践中才不同程度地有所理解。” 所以我不成熟地希望大家还是多多实践吧，尽量少花些时间在这些诸如本质啊区别啊啥啥的问题上面。当然,如果你精通ORACLE,我支持你去了解ORACLE, DB2, MS SQL, MYSQL之间有什么区别【希望大家能正面理解我的这番话】。

编辑于 2012-12-12 3 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

1 赞同反对，不会显示你的姓名夏天，A competent programmer 小白菜815 赞同数据库：面向业务，保存事务型数据数据仓库：面向主题（数据分析的需求目的），保存分析型数据发布于 2014-07-23 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

6 赞同反对，不会显示你的姓名郑云云，学生 Rain Zz、昌霖、刘志等人赞同数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

所谓的（1）面向主题：指数据仓库中的数据是按照一定的主题域进行组织。（2）集成：指对原有分散的数据库数据经过系统加工, 整理得到的消除源数据中的不一致性。（3）相对稳定：指一旦某个数据进入数据仓库以后只需要定期的加载、刷新。（4）反映历史变化：指通过这些信息，对企业的发展历程和未来趋势做出定量分析预测。数据仓库建设是一个工程，是一个过程，而不是一种可以购买的产品。企业数据处理方式是以联机事务处理形式信息，并利用信息进行决策；在信息应用过程中管理信息。数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。数据仓库与数据库的主要区别在于：（1）数据库是面向事务的设计，数据仓库是面向主题设计的。（2）数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。（3）数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余。

（4）数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。编辑于 2015-07-24 1 条评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

3 赞同反对，不会显示你的姓名小白阿狸威、robin、阿加门农赞同 1、oltp面对业务，一个是对业务分析 2、oltp是3NF设计，olap是星形模型设计.最近一个新同事问我统计的时候为什么不能直接走ods，要做一些数据仓库的模型，我觉得很重要的一点就是生产库业务复杂，3nf的设计，一般人光理解这个业务都需要花很多时间，更别说使用了。因此需要能抽象出一个简单易懂的模型 3、oltp，涉及到增删改查，都是小数据量的操作，olap查询为主，分析的基数很大 4、使用者也不同，一个是面对业务人员，一个是决策人员 5、oltp强调并发性，olap查询 6、oltp针对当天的数据进行操作，olap针对当前和历史数据做处理编辑于 2015-08-13 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

3 赞同反对，不会显示你的姓名匿名用户名字不愿将就、小白菜815、小白赞同一个用于处理业务数据, 一个基于业务数据进行行业分析发布于 2014-03-21 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

2 赞同反对，不会显示你的姓名周毓菲，大学时光余额只剩一年多了…… 账套君、小白菜815 赞同概括而言：数据库内的资料是是面向业务的，即所谓的OLTP（联机事务处理） ,数据仓库里的东东呢是用来支持决策的，也就是OLAP（联机事物分析）。

往细里说：数据库里存放的是细节化的信息，而且是二维信息（所谓二维的数据结构，最简单的一种理解就是数据以表的形式组织），有很多基本资料和交易数据。数据仓库是里存储的是摘要化的信息，并且是多维的信息（至于多维的数据结构理解起来可能比较抽象，可以想象成很多张表以一定顺序摞成一堆，这一堆又以另一种顺序放成一堆，以此类推），数据仓库里这些多维的信息是数据挖掘的原材料（注意是数据仓库里的数据而不是数据库）。

一句话：数据仓库是由许多的数据库组成，也就是数据仓库相当于一个宫殿，而数据库是宫殿里的房间噜^_^ 编辑于 2015-10-19 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

0 赞同反对，不会显示你的姓名 Ryan Kung，大道三千，皆说欢喜。 A Data warehouse is a repository of information collected form multiple source, stored under a unified schema, and that usually resides at a single site. 发布于 2015-05-23 添加评论感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利

ODS与EDW区别, http://www.cognoschina.net/home/space.php?uid=10270&do=blog&id=4443

我们项目的定性分析：首先，我们经常提到的操作数据存储（ODS）与数据仓库（DW）的区别： ODS是介于DB和DW 之间的一种数据存储技术，和原来面向应用的分散的DB相比，ODS中的数据组织方式和数据仓库（DW）一样也是面向主题的和集成的，所以对进入ODS的数据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据，如果需要的话还可以对ODS中的数据进行增、删和更新等操作，虽然DW中的数据也是面向主题和集成的，但这些数据一般不进行修改，所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。简单说ODS只是业务数据库的一个备份或者映像，ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致，目的是为了使数据仓库的处理和决策支持要求OLAP（联机分析处理）与OLTP（联机事务处理）系统相隔离，减少决策支持要求对OLTP系统的影响。为什么需要有一个ODS系统呢？一般在带有ODS的系统体系结构中，ODS都具备如下几个作用： 1）在业务系统和数据仓库之间形成一个隔离层； 2）转移一部分业务系统细节查询的功能： ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力； 3）完成数据仓库中不能完成的一些功能：数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。经过上面对一些概念的描述，我一直在想，我们当前的电子银行项目或给其他行开发的基于ODSB开发的项目是DW吗？我们面对的是客户提出的几十甚至上百张的报表需求，项目完成的是以几个业务主题建设的数据仓库吗？如果是数据仓库，那提供用户灵活的多维立方体、OLAP（联机分析处理）分析中那里？这些问题经过思考过后，我总结得出：虽然提供给用户的是一大堆各种各样的报表，但是数据仓库的架构是存在的，首先在数据准备区（数据平台）中建立一致性维度、建立一致性事实的计算方法；其次在一致性维度、一致性事实的基础上逐步建立数据集市，这个为电子银行部提供的其实就是一个数据集市，我们在这个数据集市上产生了业务报表，如果客户需要，完全可以创建几个如“渠道签约分析”、“渠道交易分析”等业务主题，再通过Cognos工具产生对应的多维立方体，提供管理层用户上卷、下钻等数据分析。这样我们以后为其他部门每次增加数据集市，都会在数据准备区整合一致性维度，并将整合好的一致性维度同步更新到所有的数据集市。这样，建立的所有数据集市合在一起就是一个整合好的数据仓库。这种数据仓库架构（自下而上）具有逐步建设的特点，它的开发周期比其他架构（自上而下）方式的开发周期要短，风险和相应的成本也要低。其实数据仓库的建设还有一种“企业信息工厂”（自上而下）的实现方式是，首先进行全企业的数据整合，建立企业信息模型，即EDW。对于各种分析需求再建立相应的数据集市或者探索仓库，其数据来源于EDW，原子层给建立OLAP带来一定的复杂性，但是对于建立更复杂的应用，如挖掘仓库、探索仓库提供了更好的支持。这类架构的建设周期比较长，相应的成本也比较高。用户在短时间看不到想要的结果。另外，基于ODSB的报表开发类项目，在项目管理中也与一般的应用系统有所不同，这里就不详细说明了。

数据仓库之 ETL漫谈, http://superlxw1234.iteye.com/blog/1666960

ETL，Extraction-Transformation-Loading的缩写，中文名称为数据抽取、转换和加载。大多数据仓库的数据架构可以概括为：数据源–>ODS(操作型数据存储)–>DW–>DM(data mart) ETL贯穿其各个环节。一、数据抽取：可以理解为是把源数据的数据抽取到ODS或者DW中。 1. 源数据类型：关系型数据库，如Oracle,Mysql,Sqlserver等; 文本文件，如用户浏览网站产生的日志文件，业务系统以文件形式提供的数据等；其他外部数据，如手工录入的数据等； 2. 抽取的频率：大多是每天抽取一次，也可以根据业务需求每小时甚至每分钟抽取，当然得考虑源数据库系统能否承受； 3. 抽取策略：个人感觉这是数据抽取中最重要的部分，可分为全量抽取和增量抽取。全量抽取适用于那些数据量比较小，并且不容易判断其数据发生改变的诸如关系表，维度表，配置表等；增量抽取，一般是由于数据量大，不可能采用全量抽取，或者为了节省抽取时间而采用的抽取策略；如何判断增量，这是增量抽取中最难的部分，一般包括以下几种情况： a) 通过时间标识字段抽取增量；源数据表中有明确的可以标识当天数据的字段的流水表，如createtime，updatetime等； b) 根据上次抽取结束时候记录的自增长ID来抽取增量；无createtime,但有自增长类型字段的流水表，如自增长的ID，抽取完之后记录下最大的ID，下次抽取可根据上次记录的ID来抽取； c) 通过分析数据库日志获取增量数据，无时间标识字段，无自增长ID的关系型数据库中的表； d) 通过与前一天数据的Hash比较，比较出发生变化的数据，这种策略比较复杂，在这里描述一下，比如一张会员表，它的主键是memberID,而会员的状态是有可能每天都更新的，我们在第一次抽取之后，生成一张备用表A，包含两个字段，第一个是memberID, 第二个是除了memberID之外其他所有字段拼接起来，再做个Hash生成的字段，在下一次抽取的时候，将源表同样的处理,生成表B,将B和A左关联，Hash字段不相等的为发生变化的记录，另外还有一部分新增的记录，根据这两部分记录的memberID去源表中抽取对应的记录； e) 由源系统主动推送增量数据；例如订单表，交易表，有些业务系统在设计的时候，当一个订单状态发生变化的时候，是去源表中做update，而我们在数据仓库中需要把一个订单的所有状态都记录下来，这时候就需要在源系统上做文章，数据库触发器一般不可取。我能想到的方法是在业务系统上做些变动，当订单状态发生变化时候，记一张流水表，可以是写进数据库，也可以是记录日志文件。当然肯定还有其他抽取策略，至于采取哪种策略，需要考虑源数据系统情况，抽取过来的数据在数据仓库中的存储和处理逻辑，抽取的时间窗口等等因素。二、数据清洗：顾名思义，就是把不需要的，和不符合规范的数据进行处理。数据清洗最好放在抽取的环节进行，这样可以节约后续的计算和存储成本；当源数据为数据库时候，其他抽取数据的SQL中就可以进行很多数据清洗的工作了。数据清洗主要包括以下几个方面： 1. 空值处理；根据业务需要，可以将空值替换为特定的值或者直接过滤掉； 2. 验证数据正确性；主要是把不符合业务含义的数据做一处理，比如，把一个表示数量的字段中的字符串替换为0，把一个日期字段的非日期字符串过滤掉等等； 3. 规范数据格式；比如，把所有的日期都格式化成YYYY-MM-DD的格式等； 4. 数据转码；把一个源数据中用编码表示的字段，通过关联编码表，转换成代表其真实意义的值等等； 5. 数据标准，统一；比如在源数据中表示男女的方式有很多种，在抽取的时候，直接根据模型中定义的值做转化，统一表示男女； 6. 其他业务规则定义的数据清洗。。。三、数据转换和加载：很多人理解的ETL是在经过前两个部分之后，加载到数据仓库的数据库中就完事了。数据转换和加载不仅仅是在源数据–>ODS这一步，ODS–>DW, DW–>DM包含更为重要和复杂的ETL过程。 1. 什么是ODS？ ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分， ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。—摘自百度百科其实大多时候，ODS只是充当了一个数据临时存储，数据缓冲的角色。一般来说，数据由源数据加载到ODS之后，会保留一段时间，当后面的数据处理逻辑有问题，需要重新计算的时候，可以直接从ODS这一步获取，而不用再从源数据再抽取一次，减少对源系统的压力。另外，ODS还会直接给DM或者前端报表提供数据，比如一些维表或者不需要经过计算和处理的数据；还有，ODS会完成一些其他事情，比如，存储一些明细数据以备不时之需等等； 2. 数据转换(刷新)：数据转换，更多的人把它叫做数据刷新，就是用ODS中的增量或者全量数据来刷新DW中的表。 DW中的表基本都是按照事先设计好的模型创建的，如事实表，维度表，汇总表等，每天都需要把新的数据更新到这些表中。更新这些表的过程(程序)都是刚开始的时候开发好的，每天只需要传一些参数,如日期，来运行这些程序即可。 3. 数据加载：个人认为，每insert数据到一张表，都可以称为数据加载，至于是delete+insert、truncate+insert、还是merge，这个是由业务规则决定的，这些操作也都是嵌入到数据抽取、转换的程序中的。四、ETL工具：在传统行业的数据仓库项目中，大多会采用一些现成的ETL工具，如Informatica、Datastage、微软SSIS等。这三种工具我都使用过，优点有：图形界面，开发简单，数据流向清晰；缺点：局限性，不够灵活，处理大数据量比较吃力，查错困难，昂贵的费用；选择ETL工具需要充分考虑源系统和数据仓库的环境，当然还有成本，如果源数据系统和数据仓库都采用 ORACLE，那么我觉得所有的ETL，都可以用存储过程来完成了。。在大一点的互联网公司，由于数据量大，需求特殊，ETL工具大多为自己开发，或者在开源工具上再进行一些二次开发，在实际工作中，一个存储过程，一个shell/perl脚本，一个java程序等等，都可以作为ETL工具。五、ETL过程中的元数据：试想一下，你作为一个新人接手别人的工作，没有文档，程序没有注释，数据库中的表和字段也没有任何comment，你是不是会骂娘了？业务系统发生改变，删除了一个字段，需要数据仓库也做出相应调整的时候，你如何知道改这个字段会对哪些程序产生影响？。。。。源系统表的字段及其含义，源系统数据库的IP、接口人，数据仓库表的字段及其含义，源表和目标表的对应关系，一个任务对应的源表和目标表，任务之间的依赖关系，任务每次执行情况等等等等，这些元数据如果都能严格的管控起来，上面的问题肯定不会是问题了。。。

★★★★★ 数据仓库原理<3>：数据仓库与ODS， http://www.cnblogs.com/hbsygfz/p/4759680.html

1. 引言本篇主要讲述操作数据存储（ODS）系统产生的背景、定义、特点，以及它与数据仓库的区别。在前两篇，笔者介绍了什么是数据仓库？为什么需要数据仓库？数据仓库系统的体系结构是什么？因此可能在读者心里已经形成了企业数据存储的DB~~DW两层体系结构的概念，但在实际应用中，并不总是这样，有时候我们可能需要ODS这一系统来搭建DB~~ODS~DW三层数据体系，那么什么是ODS？为什么需要ODS？ODS与DW的区别又是什么？下面将在第2-6节介绍ODS的理论知识，在第7节以电信运营商为例介绍ODS的实际应用。由于是学习心得，如有错误或者不严谨的地方，希望读者批评指正。

2. ODS产生的背景人们对数据的处理行为可以划分为操作型数据处理和分析型数据处理，操作型数据处理一般放在传统的数据库(Database,DB)中进行，分析型数据处理则需要在数据仓库(Data Warehouse,DW)中进行。但是并不是所有的数据处理都可以这样划分，换句话说，人们对数据的处理需求并不只有这两类，比如，有些操作型处理并不适合放在传统的数据库上完成，也有些分析型处理不适合在数据仓库中进行。这时候就需要第三种数据存储体系，操作数据存储(Operational Data Store,ODS)系统就因此产生。它的出现，也将DB~~DW两层数据架构转变成DB~~ODS~DW三层数据架构。

那么，什么是ODS? ODS是用于支持企业日常的、全局应用的数据集合。 (PS：这样定义，可能还是不清楚，看完下面3、4节应该就能明白~)

3. ODS数据的基本特征 ODS中的数据具有以下4个基本特征： ① 面向主题的：进入ODS的数据是来源于各个操作型数据库以及其他外部数据源，数据进入ODS前必须经过 ETL过程（抽取、清洗、转换、加载等）。 ② 集成的：ODS的数据来源于各个操作型数据库，同时也会在数据清理加工后进行一定程度的综合。 ③ 可更新的：可以联机修改。这一点区别于数据仓库。 ④ 当前或接近当前的：“当前”是指数据在存取时刻是最新的，“接近当前”是指存取的数据是最近一段时间得到的。

4. ODS的功能（1）实现企业级的OLTP操作：传统的操作型数据库往往只存放企业某一类业务或者某一个部门的数据，因此无法面向企业全局数据的OLTP，而ODS可以实现。因为ODS的数据是面向整个企业进行集成汇总的，克服了原来面向应用的操作型数据库数据分散的缺陷。（2）实现即时的OLAP操作：在数据仓库上进行OALP，往往由于数据量十分庞大而需要较长的时间。而在企业实际应用中，对于一些较低层次的决策，往往并不需要太多的历史数据，可能只需要参考当前的或者接近当前的数据就可以完成，并且要求具有较快的响应时间，因此数据仓库显然无法满足这样的要求，但是ODS可以实现。ODS中不仅有面向企业全局的细节数据和汇总数据，而且规模比数据仓库小，具有较强的实时响应能力。

小结：通过3、4节的介绍，可以这样解释ODS的概念： ODS是这样一种数据存储系统，它将来自不同数据源的数据（各种操作型数据库、外部数据源等）通过ETL过程汇聚整合成面向主题的、集成的、企业全局的、一致的数据集合（主要是最新的或者最近的细节数据以及可能需要的汇总数据），用于满足企业准实时的OLAP操作和企业全局的OLTP操作，并为数据仓库提供集成后的数据，将数据仓库系统中的ETL过程下沉到ODS中完成以减轻数据仓库的压力。

5. DB~~ODS~~DW三层体系结构 DB~~ODS~~DW三层体系结构 ODS和DW面向不同的用户，为不同的需求产生，因此都有不可替代的作用，两者相互结合、相互补充。 ODS在三层体系结构中扮演着承上启下的作用。一方面，ODS在原来独立的各个DB的基础上建立了一个一致的、企业全局的、面向主题的数据环境，使原有的DB系统得到改造。另一方面，ODS使DW卸去了数据集成、结构转换等一系列负担，对DW的数据追加通过ODS完成，大大简化的DW的数据传输接口和DW管理数据的复杂度。 ODS系统的建设，弥补了DB~~DW两层体系结构的不足，但是ODS并不是必需的，当企业并不需要操作型集成信息时，基于DB~~DW两层体系结构是较优的，如果需要，那么DB~~ODS~~DW三层体系结构则是较优的。

6. ODS与DW的区别 ODS在DB~~ODS~~DW三层体系结构中起到一个承上启下的作用。 ODS中的数据虽然具有DW中的数据的面向主题的、集成的特点，但是也有很多区别。（1）存放的数据内容不同： ODS中主要存放当前或接近当前的数据、细节数据，可以进行联机更新。 DW中主要存放细节数据和历史数据，以及各种程度的综合数据，不能进行联机更新。 ODS中也可以存放综合数据，但只在需要的时候生成。（2）数据规模不同：由于存放的数据内容不同，因此DW的数据规模远远超过ODS。（3）技术支持不同： ODS需要支持面向记录的联机更新，并随时保证其数据与数据源中的数据一致。 DW则需要支持ETL技术和数据快速存取技术等。（4）面向的需求不同： ODS主要面向两个需求：一是用于满足企业进行全局应用的需要，即企业级的OLTP和即时的OLAP；二是向数据仓库提供一致的数据环境用于数据抽取。 DW主要用于高层战略决策，供挖掘分析使用。（5）使用者不同： ODS主要使用者是企业中层管理人员，他们使用ODS进行企业日常管理和控制。 DW主要使用者是企业高层和数据分析人员。

7. ODS在电信行业的具体应用（1）运营商为什么要建ODS？随着市场的不断变化，电信运营商需要以“产品”为中心向以“客户”为中心转型，而这种转型需要建立客户统一视图信息，并实现信息在各渠道、前后端的共享，但是目前这些数据分布在各个生产系统中，并存在各种数据不一致的现象。因此，提出了以ODS系统来解决这一问题。具体地说，希望通过ODS系统来满足以下三种需求： ① 建立企业全局的客户统一视图信息，指导客户品牌经营和精确管理； ② 建立统一的数据共享平台，快速支撑跨系统应用，促进企业数据模型的落地，形成企业标准数据； ③ 提升企业数据质量，解决生产系统之间数据不一致、数据质量差的问题。（2）ODS的系统定位： ODS系统是一个跨系统的数据共享平台，承接操作环境和分析环境。电信运营商EDA域企业数据架构建立在统一的数据模型的基础上，由生产系统自有数据库、操作数据存储（ODS）、企业数据仓库（EDW）三个层面组成。其中，ODS存储按主题分类的面向运营的准实时数据，提供统一的企业数据视图；生产系统自有数据库存储该生产系统内部实时交易数据；EDW存储面向经营决策分析的历史数据和综合数据。 ODS对生产系统产生的数据进行清洗、过滤、转换、整合，是提供给EDW高质量数据的重要来源之一，同时为各个生产系统提供准实时的运营报表等跨系统共享数据服务。另外，在企业运营层，对于需要同时利用跨系统的操作型数据和相关分析结果数据的协作性应用需求，ODS也起到关键支撑作用。（3）ODS的业务目标： ① 统一准实时的数据共享 ② 生产经营数据质量检查 ③ 统一客户视图的提供与展示 ④ 生产经营报表统一的提供与展示 ⑤ 关键生产经营绩效指标与经营风险的监控 ⑥ 跨系统的批量计算（4）ODS与生产系统的比较：相同点： ① 均包含当前的细粒度运营数据； ② 使用者都是一线的生产和管理人员； ③ 都是数据质量管理闭环流程中的一个环节（ODS对所存储的数据进行一致性、完整性、正确性的校验，形成数据校验结果并返回给源系统进行修正）；不同点： ① ODS不产生运营数据，运营数据由各个生产系统产生； ② 在数据质量管理闭环流程中，ODS负责发现数据质量问题，生产系统负责解决数据质量问题； ③ ODS为其他系统提供准实时的数据共享服务，生产系统提供实时的数据共享服务； ④ ODS提供基于跨系统数据的查询应用，生产系统通过与ODS合作提供跨系统的准实时查询应用； ⑤ ODS系统提供基于跨系统数据的固定或者动态报表，生产系统提供基于单系统的、实时性要求高的固定或动态报表； ⑥ ODS负责批量数据的计算，生产系统负责事务驱动的数据计算。（5）ODS与EDW的比较：相同点： ① ODS和EDW都不是运营数据的产生系统，都是通过ETL等过程从各种数据源中加载数据； ② ODS和EDW的数据都是分层存储，既有细节数据，又有根据不同维度汇总的综合数据； ③ ODS和EDW都可以提供基于跨系统整合后数据的报表类应用。不同点： ① ODS中的细节数据时效性高，并提供给其他系统共享，而EDW中的细节数据时效性低，不提供给其他系统共享，只供自身挖掘分析使用； ② ODS中的数据汇总维度较少，EDW中数据汇总维度多。 ③ ODS提供的报表内容主要是面向生产运营过程中数据的统计与监控，不做进一步分析和挖掘，而EDW中的报表内容主要是针对跨系统的数据进行深度分析和挖掘，着重趋势分析并提供评估和决策功能； ④ ODS面向一线生产的管理人员，EDW面向专业分析人员和企业中高层管理人员； ⑤ ODS中的运用数据来源是生产系统，EDW运营数据主要从ODS中获取，ODS中没有的才从生产系统中获取； ⑥ ODS中的数据保存期限短于EDW中的数据保存期限。

8. 参考文献 [1] 数据仓库(原书第4版)，William H.Inmon著，王志海等译，机械工业出版社，2006.8 [2] 数据仓库与数据分析教程，王珊等编著，高等教育出版社，2012.8 [3] 百度文库：电信ODS规范 [4] 百度文库：中国电信ODS规范培训

【回源页面可以展开系列文章】1 背景知识：数据仓库技术简介， http://www.tianshouzhi.com/api/tutorials/hive

Hive是一种数据仓库。数据仓库不同于数据库。因此在介绍Hive之前，我们有必要介绍一下数据仓库的背景知识。

数据仓库与数据库的区别

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的 “大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

数据仓库的定义

面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea），因为每一次做决策分析时，可能并不需要数据仓库中的所有数据，可能只是其中部分数据。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

对于一些比较小的企业应用来说，可能是没有数据仓库的，因为所有的数据可能都存储在同一个数据库中，因此这个数据库本身就包含了所有的信息。但是对于一些大型的系统来说，可能是由多个模块组成，每个模块都有着自己的数据库，意味着数据是分散存储在不同的数据库中，因此当我们需要获取所有的数据时，必须要从各个数据库中获取信息，存储在一个公共的地方，这个地方就是数据仓库，因此数据仓库在大型的系统中更为常见。

数据仓库实现方式

数据仓库是一个过程而不是一个项目。

数据仓库系统是一个信息提供平台，他从业务处理系统获得数据，主要以星型模型和雪花模型进行数据组织，并为用户提供各种手段从数据中获取信息和知识。

从功能结构划分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。

企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。

ETL

ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。

实际上我们可以将ETL看做建立一个数据仓库的的三个步骤，extract就是从各个子系统或者模块的数据库中提取数据，trasfrom实际上就是对提取出来的数据进行清洗，加载就是清洗好的数据再放入数据仓库中。

实际我们可以把实现一个数据仓库的数据获取（Data Acquisition)部分看成ETL。

为了能更好地实现ETL，笔者建议用户在实施ETL过程中应注意以下几点：

第一，如果条件允许，可利用数据中转区对运营数据进行预处理，证集成与加载的高效性；

第二，如果ETL的过程是主动“拉取”，而不是从内部“推送”，其可控性将大为增强；如果采取的是拉取的策略，只要我们的数据仓库是从去连接各个子模块的数据库获取数据即可，即只需要在数据库仓库应用中实现一个拉取模块即可，如果采取的是推送机制，那么每个子模块都要单独实现各自的推送。

第三，ETL之前应制定流程化的配置管理和标准协议；

第四，关键数据标准至关重要。ETL面临的最大挑战是当接收数据时其各源数据的异构性和低质量。以电信为例，A系统按照统计代码管理数据，B系统按照账目数字管理，C系统按照语音ID管理。当ETL需要对这三个系统进行集成以获得对客户的全面视角时，这一过程需要复杂的匹配规则、名称/地址正常化与标准化。而ETL在处理过程中会定义一个关键数据标准，并在此基础上，制定相应的数据接口标准。

补充：主动拉取，意味着我们要对数据仓库的技术元数据进行管理。

数据仓库的元数据分为：技术元数据和商业元数据。

技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库使用的数据。包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等。

商业元数据从商业业务的角度描述了数据仓库中的数据。包括：业务主题的描述，包含的数据、查询、报表；

OLTP和OLAP

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果.

OLTP:

也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。

这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由数据库引擎负责完成的。

OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。

OLAP:

简写为OLAP,随着数据库技术的发展和应用，数据库存储的数据量从20世纪80年代的兆（M）字节及千兆（G）字节过渡到现在的兆兆（T）字节和千兆兆（P）字节，同时，用户的查询需求也越来越复杂，涉及的已不仅是查询或操纵一张关系表中的一条或几条记录，而且要对多张表中千万条记录的数据进行数据分析和信息综合，关系数据库系统已不能全部满足这一要求。在国外，不少软件厂商采取了发展其前端产品来弥补关系数据库管理系统支持的不足，力图统一分散的公共应用逻辑，在短时间内响应非数据处理专业人员的复杂查询要求。

联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持，可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。

Hive是一种数据仓库技术，因此Hive主要处理的是OLAP。

Hive

Hive是基于Hadoop的一个数据仓库工具。“工具”这意味着Hive并不是一个成型的数据仓库系统，它只是一个工具，来帮助我们实现数据仓库。

从之前的分析中，我们知道实现一个数据仓库有三个关键的部分：数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）。

Hive作为一个数据仓库工具，对于这个三个部分的实现都提供了相应的支持：

1、数据获取（Data Acquisition）：我们可以像操作关系型数据库那样直接往hive中插入数据，不过大部分情况下，是使用类似于sqoop、datax这样的数据迁移工具，从其他数据库中将数据导入到hive中。

2、数据存储：hive可以帮助我们将数据存储在HDFS上

3、数据访问（Data Access）： Hive可以将结构化的数据文件映射为一张数据库表, 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。

数据仓库 on ZRJ | 学习笔记

hive 分区的使用

数据仓库，数据集市，ODS，主数据