从RDB DB DDB DW到DC的几篇文章学习

从RDBDBDDBDW到DC的几篇文章学习2012-07-2910:16:50分类：IT职场从RDBDBDDBDW到DC

实时数据库

数据库文档数据库数据仓库数据中心

--

数据仓库的建设是一个巨大的工程，按照仓库的理论思想和我自己实际的仓库建设过程，我觉得数据仓库最好分为六层的设计思想来构建和实施：

一，源数据层

源数据层的目的是为数据仓库提供数据来源，它的数据来自于仓库外部，如企业各应用系统，各部门的源数据，企业的外围数据，如行业标准等。这些数据的特点是：

1，它们是动态的，数据可能随时间变化。

2，它们是面向应用，面向业务的。

3，它们是明细的，数据粒度是最低的。

4，它们是固定的，在仓库建设过程中，不允许干系人更改它们。

5，它们是形式多样化的，可能以多种新式出现（如file,dbtable,dataset,xml,sap,xls等)。

6，它们的物理位置的多样性，数据可能在一台机器上，也可能在一个局域网类，也可能在internet上。

7，它们生成的多样性，我们可能每天都到一个固定的地方获取它们，也可能是临时的，跟政策相关的，经协商后产生并提供给仓库用的。

源数据层中数据的生命周期：在数据仓库建设过程中，我们只要向它们取数就行，不用考虑其生命周期。

在数据从本层到ODS层加工的过程中，我想强调的有一下几点：

1，etl工具的使用：

具体情况具体对待，如果源数据层的构成比较简单，数据量也比较少，加工的时间窗口充足，则为了节省成本，可以用一些免费的工具，或者自己开发工具。如果构成比较复杂，数据量也很大，为了保证加工的时间窗口，在资金充足的情况下，建议使用datastage,informatic之类的工具，因为它们在异构数据环境下的数据搬运能力不容小觑。

2，工作内容分析：

本阶段的工作是ETL的E部分，即数据的抽取。当然也包括部分为了更好的抽取而进行的必要数据清洗过程。这部分的工作量依赖于源数据层的构成，源数据层中数据的规整程度以及数据量的大小。如果源数据层构成比较复杂，再加上它数据的规整程度很低，数据量又很大，则本层的工作量是相当的大。否则，则工作量如其它各层的相当。

举例说明，在某银行的数据仓库建设过程中，一个19GB的数据文件入库时报错，经漫长的分析后，发现是数据中的某个中文汉字的编码中包含了作为分隔符的‘|’。再如某银行的数据仓库建设过程中发现，某上级单位下发的非开放式标准的xml类型的数据，需要经过单独开发工具加工处理后才能入ODS层的库。

二，ODS层

数据从源数据层经过简单的清洗后，或者不经过清洗直接搬运后就到了ODS。

ODS层的功能是：

1，为S_DW层提供数据

2，为查询分析层提供明细数据查询

3，隔离了分析系统与业务系统，保证了业务系统的安全性，减轻了业务系统的压力。

ODS层数据的特点是：

1，数据内容与源数据层完全一样或基本一致。

2，数据是明细的，粒度最低的。

3，数据是面向主题存储的。

4，数据是反映历史变化的

5，数据是稳定的。

ODS层数据的生命周期：一天

数据从ODS层加工到S_DW层过程中：

1，etl工具的使用：

建议用procedure,function,UDF等来完成。

1，优点是：效率高，软件费用低，无需额外第三方etl工具的技术支持。

2，缺点是：不便于开发，维护；调度，运行的可监控性较差。

2，工作内容分析：

本阶段的目的是清洗，整合，加工数据。对应于ETL的T，即加工。由于ODS层的每个表数据量都相对较小，故本层中适合做加工处理，多表的关联等。在建好模型的基础上，本部分的开发工作量不是太大。本层的数据依赖于源数据层的数据，而且加工处理较多。故数据加工时间可能比较大。

三，S_DW层

ODS层的数据经过清洗，加工，整合后就到了S_DW层，S_DW层其实是从ODS层分解出来的，它是ODS层和DW层之间的一个中间层，它不是必须的，如果数据仓库比较大，比较复杂，那么建议使用本层，以提高效率。本层的存在相当于用空间来交换时间。

S_DW层的功能是：它为数据从ODS层到DW层提供了一个缓冲，相当于一个临时空间，节省了FACT表和DIM表生成的时间。

S_DW层数据的特点：

1，数据的规整程度较高。

2，数据的粒度较低。

3，数据是面向主题的。

4，数据是反映历史变化的。

5，数据是稳定的。

S_DW层数据的生命周期：一天

数据从S_DW层加工到DW层过程中：

1，ETL工具的使用：

同ODS层。

2，工作内容分析：

本阶段的目的是把整合后的业务数据表加工成符合入仓库规则的FACT表和DIM表。然后数据以FACT表和DIM表的形式入仓库。对应于ETL过程的L，即入仓库。在建好模型的基础上，本部分的开发工作量不是太大。本层的数据依赖于ODS层的数据，加工处理，整合较少。故数据加工时间也较少。四，DW层

当FACT表，DIM表生成后，就可以利用它们按照主题来建CUBE了。CUBE建成后，数据仓库就基本建成了。后继所需的工作就是每天（增量或全量）刷新CUBE，或者按照需求往仓库中新增主题，新增CUBE来充实仓库了。

DW层的功能是：为后继的基于仓库的应用提供基础。

DW层数据的特点：

1，面向主题

2，稳定的

3，反映历史变化的。

4，集成的。

DW层数据的生命周期：仓库的数据规划保留期。

数据仓库中的cube加工注意事项：

CUBE的刷新方式：最好使用日增量方式，不然时间会特别慢。CUBE的模型也特别影响CUBE的刷新时间，当CUBE的模型发生变化时，CUBE必须要全量刷新。另外有个细节问题须强调的是，在纬度表中，要有条“未知”记录来描述一些不太规整的事实。

五，查询分析层

就我接触的，知道的，基于仓库的应用：

1，多维分析层

经营统计分析，风险分析，绩效考核，客户分析，产品分析等。

它们向cube取数。

2，二维报表层

提供上级部门必须的报表，如银监局，人行，外管局所必须的报表。

它们可以从dw层取数

3，信息查询层

比如某些特殊的报表，需要知道最n的m条记录的信息，例如想知道今天交易的最大的10比贷款的客户资料。

准确的说，他们应该是从dw或s_dw,或ods层取数据。

4，数据挖掘层

我没有具体做过挖掘，仅仅是知道他们是基于仓库的应用而已。

六，应用层

经过前面的建设，我们就可以从信息系统获取信息了。但是经过对DW中信息的分析得出了某些知识后，我们怎么样去使用这些知识呢？这就是DW信息系统建设的目的和意义所在。

我参与建设的银行信息系统中，较少有涉及到这一层的。下面就以我个人的理解来做表述。

1，应用层体现了基于DW的信息系统建设的目的。

譬如说，我们用多维分析能够分析出什么样的结论？这些结论能够帮我们解决什么样的问题？我们是否在用这些结论在解决这些问题？数据挖掘挖掘出来的知识的正确性有多大？可用程度有多大？它是否在为决策支持等提供服务？信息查询中查询处的信息，我们是怎样在用它们呢？等等。总之这些信息，知识，结论是否能够在节省成本，增加利润，提高绩效，规避或降低风险，优化企业业务结构，组织结构，客户构成等方面发挥作用呢？

2，应用层应为企业发展的战略，战术目标以及领导决策提供支持服务。

譬如说，经营统计分析告诉了我们企业利润的组成及发展趋势。产品分析告诉了我们，客户分析告诉我们。风险分析告诉我们

通过种种分析方法，我们可以知道，企业应该通过开发什么样属性的产品来吸引什么样的客户，以以最小的风险来谋取最大的利润。

风险分析分析结论的使用是否真正的了规避了风险?绩效考核是否找到绩效低下的原因，是否可以找到提高绩效的方法？

3，应用层应为应用，业务系统提供服务。

譬如说，在银行业务中，通过查询分析，我们知道了某客户是当月存款最大的客户，那么当此客户到银行来办理业务的时候，应用层程序就应该告诉客户经理可以为该客户提供的产品。

总结：

从上面的描述中可以看出，DW的建设是一个长期的连续的过程。它是由业务驱动的，也应该是驱动业务的，而后者在银行中的应用体现却不是很充分。

思考：

新应用，新业务，新产品产生后，仓库要做哪些变化。

怎样才能使仓库的可扩展性强，怎样使仓库的架构稳固。

怎样使仓库随着应用数据量的增大，应用数的增多，而效率变化不大。

高效实现数据仓库的七个步骤

数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。

在处理一个数据仓库项目时需要注意的问题很多，但同时也有很多有建设性的参考可以帮助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。

1.配备一个全职的项目经理或你自己全面负责项目管理

在通常情况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大帮助。

2.将项目管理职责推给别的项目经理

由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。

3.与用户进行沟通

这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户自己也不清楚他们到底需要数据仓库为他们做什么。他们在不断的探索和发现自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。

既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你也许需要（和你的用户一起）采用一种新的方法观察数据，而不是直接处理数据。你可以尝试从中找出隐藏的信息，比如在一段时期内的数字涨落等。不要试图追寻项目需求的答案，而是要让答案找上门来。

4.以技术/信息库作为领导

由于数据仓库实施的各个阶段都有很大不同，因此你需要有人能起到维持整个项目的连续进行的作用，不过这个职责并不需要那种全职性。项目实施有三个重要方面：架构、技术和业务。将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会受到良好的维护。而我们应该将技术作为重点，因为开发团队和关键用户都在使用他们以前从未用过的工具，必须有人监督开发过程以及工具使用的一致性。

最后，在数据仓库的应用过程中浮现出来的业务需求必须被详细分析和记录，以促机开发过程持续下去。如果用户不能很好的开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必须有人关注业务方面的开发，推动开发进入更高级别。

5.跳出反复修改程序的陷阱

第一次实现的数据仓库肯定不会是最终交付的版本。为什么呢？实际上在真正见到产品前，你无法确定的知道自己的目标是什么。或者说，最终用户只有在使用数据仓库产品一段时间后，才能明确告诉你这个产品是不是他所希望的。与你以往处理的项目不同，业务智能还处于发展的初期，每个公司对业务智能都有不同的解释，因此你的项目决不会一次成功。

为了以正确的格式获得数据，你需要在不断变化的状况中摸索前进。BI具有很强的个性，不同的环境、不同的市场以及不同的企业都有不同的BI。这又代表什么呢？这表示你需要把数据库管理员放在一个消息相对封闭的环境中，不要让他知道数据仓库的数据结构以及ETL程序在不断的改变。对此没有别的办法。这样可以减轻你和DBA所承受的压力。

6.对大量的前端资源进行数据源分析

在数据仓库实现过程中，你不得不在旧有的数据中艰难跋涉，这些数据来自老的数据库、老的磁带机以及远程的数据。它们中的大部分都凌乱不堪，并且难以获取。你要对这些数据进行大量处理，并且还要设计ETL程序来寻找其中的有用信息。如果你希望整个项目做起来比较顺利，并且找到一种方法能够一次成功，那就需要你的开发人员必须花费足够的时间来充分研究这些旧有数据，将凌乱的数据规则化，并尽力设计和实现强壮的数据采集和转换过程。数据仓库的ETL部分会占用整个项目资源的百分之八十，所以一定要确定你的资源都用在刀刃上了。

将人际关系处理放在首位

在数据仓库实现过程中真正的地狱不是来自技术或者开发方面，而是来自你周围的人。你也许会遇到一个对项目并不乐观而又没时间听你陈述的领导。你也许会遇到一些开发人员将进度拖延太长时间还抱怨为什么不能用老方法实施。你也许还会遇到一些抱有不切实际的幻想的用户，他们希望轻点鼠标就能实现想象中的功能，但却不愿在他们那边多做些智力投资，更好的培训他们自己的员工。而你也已经疲惫不堪，鼓励投资，以及在开发团队和用户（甚至老板）中推广新的开发技巧。

总之你要保持微笑。当一切搞定，你的烦恼也就一扫而空了，笑到最后才笑得最轻松。

数据仓库开发过程中的七个禁忌

过去我们一直使用的OLTP技术也许隐藏着许多严重的缺陷。数据仓库的实现并不是一个简单的任务，你会发现以前积累下来的丰富经验，并不适合处理每个数据仓库的独特需求。

下面列出的条款是你在实现数据仓库过程中一定会面对的问题，其中一些看起来并没有想象中那么严重，但是你还是应该尽量避免出现类似问题。数据仓库并不是一个事务处理系统，它没有一定的标准也不会实现某个特定的应用，但它本质上是非常有组织性的。总之，每个公司所建立的数据仓库都是唯一的，并且每一次数据仓库的实现方法都不是一成不变的。在实现数据仓库时需要注意的不单是"应该如何作"，更要注意"不该如何做"。下面就是我们总结的七点"不该如何作"。

1.不要编写自己无法快速修改的代码

你所要编写的程序主要用于数据分析，而不是处理事务。而你的用户也并不真正知道他们自己真正想要一个什么样的程序。因此你不得不反复修改代码好几次，才会明白用户到底需要一个什么样的程序。如果你编写的程序具有良好的结构和灵活性，就算需要修改也不会太浪费力气。反之，你会被自己累死。

2.不要使用无法修改的数据库访问API

在过去，你的数据库可以为大量的客户提供稳定的数据查询服务。而如今，你的程序必须能够应付更多的数据查询。这使得重新改写程序以使得每个查询请求能得到最大的数据量成为势在必行的工作，而一般来说这种代码修改都不会一次成功，所以只有选择合适的可以修改的API，才能使程序尽快适应新的需求。

不要设计任何无法扩展的东西

在联机处理过程（OLTP）应用中，数据分析并不是一个真正的应用程序。实际上，数据分析的关键是获取大量旧的数据，从中提取数据模型，并以此模型推断出新的信息。而你所编写的访问潜在信息的代码应该具有可扩展性，可以附加新的数据。千万别在支持数据分析的代码中假定数据都是固定格式的。

不要附加不必要的功能

一个仓库要做的是恰到好处的服务，用户走进仓库，从货架上取得自己所需得信息，仅此而已。由于业务智能、分析以及规律性的问题都有各自的处理程序，因此你的客户唯一的需要就是获取信息。他们需要一种应用环境，可以让他们快速的从数据仓库中取得分析过程所需的数据，而不论这个数据是什么样子的。也许你想帮助他们精炼一下获得的数据，但最好不要这么做。一定要记住，不要给客户的数据分析程序添加任何会影响数据访问性能的功能。

5.不要简化数据清除和数据源分析的步骤

在实现数据仓库过程中最应该注意的地方就是为Extract-Transform-Load机制分析数据源，以及为优化负载而清除数据。安全的做法是假设项目经理在这个阶段会需要整个项目资源的一半以上。相反，如果你在这方面进行了简化，稍后肯定会后悔。所以就算系统工作缓慢，也不要简化清理旧的数据的过程。

6.不要避免颗粒度和分区问题

在数据仓库设计过程中有两个最大的数据存储问题，第一是如何给转换数据定位一个恰当的颗粒度等级，第二是如何将数据绝对的分区。为什么这两点问题如此重要呢？因为整个数据仓库的响应能力受颗粒度影响，并且数据访问的效率直接与数据分区性能有关。因此这是具有关键性的工作，不要试图避免面对这些问题。

7.不要在没考虑业务问题前就使用OLAP

用户在亲眼见到程序前通常都不知道自己到底想要个什么样的程序。因此他们的观点有不少错误，比如他们希望分析结果会忠实反应性能度量，或者希望程序会使他们部门或公司的业务工作有所不同。而你必须跳出自己的职责范围，从IT管理者的角度考虑用户部门直至整个企业的运行方式，才能在开发过程中避免这类问题。在通常的OLTP开发中，你可以比较方便的理解业务流程。而在联机分析处理（OLAP）领域，任何事情都需要亲自考察，而在你周围工作的人也许并不会发现你对业务方面存在的误解。因此，不要自以为已经了解了足够的信息。不断的询问才能使你真正了解"业务智能"中的"业务"到底是什么样子的

顺利开发数据仓库的七种思路

对于大多数IT顾问来说，实现一个数据仓库的难度比以前做过的任何项目难度都要大。考虑到不同的数据结构、用途以及应用程序开发方法，以前所积累的经验和技巧大部分都无用武之地了。但是只要在你的前进道路上稍加修正，你就会发现实现一个数据仓库并不是难事，就算你是第一次实现数据仓库也没问题。

下面列出了数据仓库实施过程需要考虑的步骤，有一些你可能从来没有意识到，而另一些可能已经在实施过程中使用到了，但是重新思考一番也许你会有更多的领悟。开放思维，不断尝试新的途径，找到一种可行的数据仓库实现方法。

1.再三考虑应用程序的实现方法

数据仓库并不涉及事务处理，并且在报表方面也仅占一小部分。而数据仓库应用程序的本质是分析，尤其是针对业务智能的分析。BI并不是通常所说的数据：它是一种从旧有数据中,模型化得到的新的数据。那么如何才能从旧有数据中挖出这些新数据呢？事实上，这个工作不是让你来完成的，而是你的客户所要完成的。从项目主管的角度看，应该有一个经验丰富的数据表格设计师与你合作，进而决定如何将各类程序融合在一起。其中所遇到的最主要的挑战将是如何用新的方法观察数据，这也是你的客户正在试图使用的方法。

创建抽象的、良好部署的数据库访问组件

在过去你接触过的数据库项目和现在的数据仓库之间，有一点绝对不同，那就是：在OnlineTransactionProcessing（OLTP）环境中，用户数量非常大，但使用到的数据却比较少；而在OnlineAnalyticalProcessing（OLAP）环境中情况却正好相反，少量的用户在使用大量的数据。而你的工作就是编写一个应用程序来优化这种不同。这里有一个线索：在你所有的分析程序中，都要能抓取连续的数据项，这样在以后建立和访问的数据结构中才能存放与原数据物理结构类似的数据。具体如何实现呢？首先不要规格化数据。第二将其放入数组中最小化读取请求数。按照这种方法，DBA会很乐意与你合作。

3.保持松散

现在回头看看第一步，你应该可以理解定义一个分析程序不是件简单事了，而且一般情况下，很难在第一次就实现符合要求的最终产品。而在你将要进行分析的数据结构上同样存在这种问题。一句话，实现过程会有很多变数，你需要不断的改动你的程序。通常我们都希望将改动次数降到最低。在一个数据仓库实现过程中，本质是要分析过程毫无差错，这也需要DB