数据仓库更新的新策略工作流Word文件下载.docx
《数据仓库更新的新策略工作流Word文件下载.docx》由会员分享，可在线阅读，更多相关《数据仓库更新的新策略工作流Word文件下载.docx（14页珍藏版）》请在冰点文库上搜索。
本文的目的之一就是指出数据
图1数据仓库的体系结构
仓库的更新要比数据视图的维护问题要复杂的多，也不同于数据导入过程。
我们把数据更新过程定义为一个工作流，组成工作流的具体活动类型取决于数据抽取和数据清洗所应用的产品。
与其配套的触发事件则与应用的范围和对数据刷新频率的要求相关。
以下几节将分别描述数据更新过程的任务，并阐明在工作流中如何组织这些任务。
第2节主要讨论数据更新过程与数据导入及视图维护的不同。
第3节定义了工作流的标准形式并结合一个工作流的例子逻辑展现了数据仓库更新过程。
第4节按照工作流的设计模式定义了数据仓库更新过程的语义。
第5节归纳了本文的主要思想，并涉及到一些实现方面的观点
2．视图维护，数据导入和数据刷新
数据仓库中的数据更新过程通常容易和数据仓库初始阶段所作的数据导入或对数据仓库中具体视图的更新相混淆。
这两种想法都是错误的。
下面几段详细阐述数据更新和数据导入，数据更新和视图维护之间的区别和不同。
数据导入和数据更新
数据仓库的数据导入过程存在于数据仓库建立初期，是数据仓库建立的关键阶段，它主要完成对数据仓库中内容的初始计算。
数据导入过程是一个全局过程，这个过程分为四个步骤（如图2所示）：
1，准备；
2，集成；
3，高度聚合；
4，定制。
第一步由各个数据源完成，它主要包括数据抽取，数据清洗，可能还包括数据归档（在数据清洗前后）等阶段。
对历史数据进行归档，其作用在两个方面：
一，在具用不同刷新频率的数据源之间进行同步；
二，用于一些特定的临时查询。
第二步由数据的一致性处理和数据的集成处理组成。
它包括对从异构数据源中提取的数据进行一致性处理（多数据源清洗）和对从ODS（操作型数据库）的基表（基视图）中获取的数据进行清洗等两个部分。
第三步由一些对派生于基视图的聚合视的计算构成。
在操作型数据库（ODS）中的数据是一些基本数据，他们具有程度很低的聚合程度，而企业级数据仓库（CDW）中存放的数据通常是用聚合函数统计过的高度聚合的数据。
第四步由对用户视进行派生和定制活动组成，最后生成数据集市。
数据定制指的是根据用户的需求形成不同的立方体，并向用户展示不同的侧面。
图2数据导入过程
数据导入阶段的主要特点是它处于数据仓库设计项目的最开始阶段。
在数据导入之前，对用户来说，数据仓库是不存在的。
因此，在反映时间上就不存在什么限制。
但是，相反，对数据源来说数据导入阶段要求数据源一直可用。
描述数据导入阶段的数据流是定义数据更新过程的基础，但是与之相对应的工作流却是不同的。
数据更新的工作流是动态的，能够跟踪用户的需求和检测数据源的变化，而数据导入过程的工作流是静态的，由用户的当前要求和当前数据源的状况所定义的。
数据更新过程和数据导入过程的主要区别有以下几点：
首先，对数据更新过程来说，组成其的各个活动（准备，集成，聚集和定制）之间完全是异步进行的，第二，就准备活动本身来说，其过程也可以是高度并行的，每个数据源都有自己的可用窗口和抽取策略。
同步由数据集成活动来做。
另外的一个不同之处在于数据源的可用性上。
数据导入阶段要求数据源长期可用，而数据更新阶段对使用数据源的操作应用程序的负载要求比较轻。
它要求每一个数据源具有确定的存取频率和一个严格限制的持续期。
最后，对数据更新过程来说，对数据的存取有严格的反映时间限制，而对数据导入过程来说，要求就没有那么严格。
确实，对用户来说，在初始数据导入前，数据仓库是不存在的。
因此，其计算时间则被包含在项目的设计期间内。
而在初始数据导入后，数据就变成可以看见的，应当满足用户对数据的使用，存取和刷新的要求。
视图维护和数据更新
在数据更新过程期间，对数据变化的传播是通过一系列独立的活动来完成的。
这些活动包含对存储在ODS和CDW中的视图的维护。
视图维护阶段是指由于给定的数据源的改变而引起存储在ODS和CDW中的一系列视图的改变，这些改变导致视图的更新。
这个阶段（视图维护阶段）是一个经典的具体视图维护问题，但是，在数据仓库中，扩展到聚合视中的改变在数据源中并不一定发生，但是予处理结果是通过其他更新活动像数据清洗和多数据源数据一致性处理等来执行的。
在数据库界，对数据视图维护的问题已经进行了大量的研究。
这个领域所做的主要工作被收集在[2]和[6]中。
大部分的工作都集中到对一套具体的视图的维护工作上，这套视图派生于一套基本的关系表，当基本关系被修改时便引起视图的改变。
视图维护所涉及到的工作主要有：
●自我维护性：
自我维护性是针对这样一套视图集的：
视图集V对于基本关系的改变是自我维护的，指的是不需要查询基本关系就可完成V中视图的改变。
（也就是说通过存储在具体视中的信息和变化的实例就足以完成视图的维护）
●一致性和有效性更新转换：
对于每个单独的视图都有相应的算法来调度更新转换过程，但是，考虑到视图间的相互依赖关系，及视图间会导致可能的矛盾。
出于这个目的，导入一些辅助视图来促进更新转换和加强自我维护性。
数据仓库主要关注的是视图集的自我维护性。
存储在数据仓库中的视图集必须是全局可自我维护的，这一点是大家都认同的。
这样做的原因是避免对操作型数据源中的常规活动负载过重。
像上节描述的一样，对数据仓库更新的研究主要集中在对具体视图的更新转换上。
关于这个题目，已经发表了很多文章。
但是，很少有人致力于将数据更新过程作为一个整体（像前面定义的）来研究。
我们认为视图维护问题只是整个数据更新过程的一步，其它几步包括数据清洗，数据一致，数据定制，如果需要的话还有数据归档。
另一方面，抽取和清洗策略对不同数据源来说是不一样的，就像数据更新转换过程对不同的用户视是不同的一样。
所以，数据仓库更新过程不能仅限于视图维护过程。
综上所述。
我们认为数据更新过程是一个复杂的系统，它由一系列异步和并发活动构成，当然，这些活动必须是可监控的。
另外，数据更新过程也是一个基于事件驱动的系统，是不断跟踪变化，动态反映数据源和用户要求演变的系统。
用户，数据仓库管理员和数据源管理员可以施加一些限制，例如，数据的刷新率，ODS和CDW的空间限制，对数据源的存取频率等。
对所有数据仓库应用，所有的数据仓库用户或整个数据仓库生命周期来说，不存在简单和同一的数据更新策略。
3．数据更新过程是一个工作流
工作流是一套相关活动的集合，这些活动既可是手动的，也可以是自动的。
工作流的概念已经在不同的领域得到应用，像商业过程模型，企业操作模型和数据库事物模型等。
根据应用的领域，活动和活动间的联系可以使用相应的说明语言来描述，像状态图，Petrinets或活动规则等。
尽管对工作流的应用和表示方式多种多样，但是，大部分工作流用户却或多或少地倾向于接受WorkflowCoalition对工作流所做的概念和说明。
工作流系统一般具有高度的灵活性，有可递归分解和合成的活动，和对工作流过程进行动态重组等特性。
对数据仓库来说，这些特点是非常有用的。
因为，不同的数据仓库厂商所提供的产品是不同的，也就是说，组成数据仓库的活动的功能和范围由于产品的不同其差别是很大的，而这正是工作流所擅长的。
在下面几小节，我们将展示数据仓库是如何被定义为工作流的。
根据用户的需求，数据源和数据仓库的限制等要求，我们将提出不同的方案，并以此来说明将工作流引入数据仓库的优点。
同时，我们将说明这些方案能够全程跟踪和监控用户需求和限制的任何变化，并完成相应的更新操作。
3.1数据更新过程的工作流
数据更新的目标是反映数据源的变化，并将这些变化导入到数据仓库中。
这个导入和转换行为可以通过一系列独立的活动来完成（抽取，清洗，集成等）。
按照用户对数据更新过程的语义以及他对所获取的数据的要求，这些活动可以以不同的方式进行组织。
同时，这些活动的顺序和它们执行的上下文环境也定义了语义并影响质量。
顺序和上下文环境来源于对视图的分析，数据源的限制和用户在质量方面的要求三个方面。
在下面几节中，我们将阐述数据更新活动和他们是如何被组织成工作流的。
然后，我们给出不同的工作流方案，并进一步说明数据更新是一个动态和演变的过程。
最后，我们将概括不同的想法，并提出一个合理的数据更新方案。
数据更新活动
就数据流来说，数据更新过程类似数据导入过程。
但是，数据导入过程是数据仓库的大规模的数据导入，而数据更新只是捕获数据源所发生的改变并将这些改变转换到数据仓库的各个存储层次中。
在准备阶段，从每个数据源中抽取数据，这些数据是自上次抽取以来，数据源所发生变化的数据。
至于导入，数据应在集成前被清洗和归档（可能的话）。
数据集成阶段主要是完成对来自多数据源的改变数据进行一致性处理，并将其导入到ODS中。
聚合阶段主要是利用这些数据变化重新对各层次聚合视进行增量计算。
定制阶段主要是将这些经过概括的数据装载到数据集市中。
和数据导入阶段一样，这是一个逻辑的分解过程，其具体实现对不同的数据仓库产品来说是不同的。
这种逻辑视图具有对数据更新过程的跟踪能力。
图3显示了数据更新过程的活动和相应事件的一个样例。
图3数据更新过程的一般工作流
活动协调
在工作流系统中，活动是由控制流调配的，这些控制流可能是过程提交提示，代理发布的电子邮件，临时事件或其它触发事件等。
在数据更新过程中，活动的协调工作是通过一个范围广泛的事件类型来做的。
我们能够定义几种不同的事件类型，这些事件类型可以触发和同步数据更新活动。
它们可以是临时事件，末端事件或其它用户定义的事件。
根据不同的更新策略，可以选取合适的事件类型集以取得正确的同步级别。
数据更新工作流的活动只有在它们被触发时才可以执行，触发的条件依据输入数据源的当前状况。
例如，如果数据抽取是周期性触发的，那么它实际上只有在数据源日志发生有效变化的时候才执行。
如果清洗过程是在数据抽取后立即触发的，那么它实际上只在抽取过程已经收集了数据源的变化数据后才执行。
因此，我们认为每个活动的输入数据源的状态是有效执行这个活动的必须要考虑的条件之一。
在数据更新过程的工作流中，不同活动可能具有不同的起源和不同的语义，因此，数据更新策略和活动的实际行为是相互独立的。
然而，在操作级别，一些活动是可以合并的（例如，数据抽取和数据清洗）另外一些是可以分解的（如集成）。
工作流系统的灵活性允许动态地裁剪数据更新活动和相关的协调事件。
另外，还有一种方式描述工作流和其触发策略。
确实，如果不考虑外部事件像临时事件或不同活动的末端事件的话，我们可以把数据改变作为事件。
因此，数据更新工作流的每一个输入存储源都可以考虑成一个事件队列，由它来触发相应的活动。
然而，为了能够描述不同的更新策略，这种方法需要一种参数化的同步机制，以便在正确的时机触发相应的活动。
有两种方法可以作这个工作。
一种是引入复合事件，例如可以将数据改变事件和临时事件进行组合。
另外一种是给数据存储单元加锁，并在一个活动或活动集决定提交后去锁。
但是，对某些需要长期同步机制的数据仓库来说，后一种方式显然是无效的。
工作流的角色
在数据更新工作流中主要涉及两个角色：
人为角色，主要定义要求，限制和策略；
另外一种是计算机，主要处理活动。
我们把人为角色分为用户，数据仓库管理员，和数据源管理员。
把计算机分为数据源管理系统，用于数据仓库和数据集市的数据库管理系统，封装和媒介等。
对于只关注活动及其相关联系的数据更新工作流来说，是不必需要角色的。
3.2定义数据更新策略
为了阐明不同的工作流策略，我们考虑使用下面这个例子。
这个例子涉及三个国家的电信单据分别用S1，S2，S3三个关系表示。
每个关系都有相同的模式定义：
（#PC,date,duration,cost）。
聚合视V的模式为（avg-duration,avg-cost,country）。
V在数据仓库中定义。
视图V提取最近6个月和上述三个关系相关的三个国家中每一个电话的平均通话时间和花费。
我们假定视图V的构造遵循以前的解释。
在数据准备期间，包含在每个数据源中的最近6个月的数据被清洗（例如，所有的收费单元被转换为欧元）。
然后，在数据集成阶段，通过联合每个数据源的数据和产生附加的属性（country）来建造基本关系R，R的模式为（date,duration,cost,country）。
最后，通过聚合计算产生视图（图4）。
图4：
更新策略的第一个案例
我们也能够用同样的数据源和类似的视图定义另一个更新策略。
这个策略镜像的是每天的平均通话时间和花费而不是6个月的。
这导致数据抽取，数据清洗，集成和转换的频率的改变。
图5给出了这样一个可能的策略。
数据源抽取的频率是由数据源管理员指定的。
数据源3是长期可用的。
图5：
更新策略的第二个案例
当更新活动是一个长期活动或DWA想要在活动间加入校验过程时，临时事件或活动终止可以被用来对整个更新过程进行同步控制。
通常，质量要求也可施加一定的同步策略。
例如，如果用户想要最新的数据，这意味着数据源的每一次更新都应当尽可能的反映到视图中。
因此，这就决定了同步的策略：
数据源的每一次改变都触发抽取，当语义相关时触发集成，在每个数据源提交后，转换活动立即在集成活动后将相应变化导入到视图中，并且在数据集市中定制用户视图。
更新模式
数据更新过程存在不同的处理模式，主要模式类型有：
●客户驱动的数据更新
客户驱动的数据更新模式指的是以用户需求为条件所触发的数据更新过程。
它主要关注的是如何将数据从ODS转换到数据仓库中的聚合视图中去。
这种基于需求的策略既可以适用于所有的聚合视，也可以仅用于和日期查询相关的数据刷新中。
●数据源驱动的数据更新
数据源驱动的数据更新描述的是由于数据源发生变化而触发的数据更新。
这种更新主要涉及到数据准备阶段。
就数据源来说，我们可以利用数据源之间的独立性来制定不同的准备策略。
例如，一些数据源和清洗过程相关，而另外一些却不是这样。
一些数据源需要抽取数据的历史记录，而其它的没有这个要求。
对某些数据源来说，清洗过程可以在抽取期间的空闲时间做，对另外一些则可能在抽取后或基于这些变化的历史来做。
对不同的数据源来说，触发抽取的事件也是不同的。
可以定义不同的事件，像临时事件（定期或固定时间），在检测数据源发生改变后或基于集成过程的要求等。
●ODS驱动的数据更新
ODS驱动的数据更新指的是由数据仓库系统自动监控的数据更新过程。
这部分主要涉及数据集成阶段。
它在一个同步点被触发，这个同步点定义在准备阶段结束后。
数据集成通常被考虑成一个整体，涉及到同一时刻所有的数据源改变。
在这种情况下，它只能被一个外部事件触发，这个事件可以是临时事件或最后一个数据源的准备阶段结束事件。
和每个数据源的准备阶段的结束一起考虑的话，那么数据集成也可以被序列化，也就是说，一个数据源的清洗完成后就对其抽取进行集成。
ODS也能监控准备阶段和聚合阶段，主要是通过产生相关的事件，由这些事件触发这些阶段的活动。
在很简单的情况下，前两个方式中的任一个均可作为一种单独的策略。
在复杂的情况下，就需要有和数据源的数量或高级聚合视图数量同样多的策略。
介于两者之间，对于前面所说的四个阶段，可能有与之相对应的四个不同的策略。
对于某些给定的用户视图，可能使用客户驱动的策略（拉策略），而对于其它视图则可能使用ODS驱动策略（推策略）。
类似，一些数据源要求用拉策略，而其它的用推测略。
策略的选取既和语义参数有关，也决定于执行数据更新活动（抽取，清洗，集成）所能使用的工具。
一些抽取工具也能在空闲时做清洗工作，而一些集成器也能立即将变化一直转换到高级视图中。
在图3所示的是数据更新的一个逻辑视图，它显示了主要的活动和触发它们的潜在的事件类型。
4、数据更新过程的语义
正像我们在以前说明的方案中所展示的那样，视图的定义并不能有效地解决数据更新的语义问题。
确实，用来定义视图的查询不能够说明这个视图是否建立在历史数据上，这个历史数据是如何采样的，对于给定的数据源的变化是每小时还是每周进行集成。
以及当集成不同数据源的变化时，应当采用什么样的数据时间戳。
另外，视图定义不包括定义在清洗过程中的具体的过滤条件，例如为特定属性选取同样的措施，对一些属性值四舍五入，或删除一些隐秘数据等。
因此，即使基于相同的视图定义，数据更新过程也会产生不同的结果，而这和外部参数有关，这些参数必须独立确定，和定义视图的查询无关。
视图V在t时刻的查询结果取决于两个主要的参数，这两个参数和数据仓库的数据更新策略有关。
第一个参数是每个数据源的抽取性能。
例如，数据源s1在发生改变时可以立即进行抽取，而s2的改变只在每个月的最后一个晚上被捕获。
这就决定了数据源变化的实效性,因此影响到数据的刷新率。
另外，它也影响了数据的一致性，因为在视图中可能产生时间差：
计算的平均数可能将s1的最新刷新数据和s2的旧数据进行集成。
第二个参数是计算视图变化所需要的时间。
实际上，这两个参数可以被重复多次，就像在数据源和数据视图之间存在许多中间存储器一样。
例如，考虑存储准备阶段结果的情况，则第一个参数刻画了数据集成过程存取数据准备阶段结果的时刻。
因此，如果数据准备阶段的每个结果只能在月末才可用的话，那么数据集成过程也只能在月末执行，结果视图将只在每个月末作出对数据源变化的反映。
另外一个参数则影响了视图V的查询结果。
定义了包容在每个数据源中的数据的实现。
例如，数据源s1可以在每个周末更新，而数据郓s2在每个月末的前两天更新。
如果视图V的一个查询在一个月的第二个周末触发的话，从这个月开始到现在与数据源s2有关的国家的电话的情况将不可能在视图V中得到反映。
所以，第二个参数的值决定了数据仓库所反映的视图状态和现实世界中视图状态存在不同之处。
因为这个参数是固定的，处于数据仓库应用程序的控制之外（它实际上是数据源操作应用程序的一部分），我们将不会对它加以考虑。
上述讨论已经揭示了数据更新过程是如何依靠某些参数，具体视图选取的独立性和这些参数是怎样影响数据更新过程的语义的。
它也揭示了建立一个与应用要求（例如，数据刷新，查询和视图的计算时间，数据精度）相关的有效的更新策略所倚赖的不同参数，这些参数和下列因数有关：
●数据源的限制（例如，可用的窗口数，变化频率）
●数据仓库系统的限制（例如，存储空间限制，功能限制）
综上所述，基于以上的样例和讨论，我门可以得出如下结论：
数据更新过程的操作语义可以被定义成为一个全部设计考虑的集合，这些考虑用来向用户提供相关联的数据，并履行质量控制的要求。
其中，这些考虑中一些来源于数据导入，其它则和数据更新本身相关。
来源于数据导入的第一个设计考虑集中在视图的定义和数据源和数据集市之间的数据流的构成。
第二个考虑是导入活动的语义即清洗规则，集成规则等。
和数据更新语义相关的的设计考虑是这样一些因素，它们决定以下信息：
●整个过程中每一个更新任务发生的时刻
●不同更新任务的同步方式
●与相应任务相关的共享数据的可视化方式
这些考虑是通过以下定义来说明的：
●按元任务进行的数据更新过程的分解（例如，某些确定数据源的清洗，来源于两个不同数据源的两个给定变化的局部集成和在一个统一任务中对另外一个数据源的检测和清洗）
●任务排序
●触发任务的事件，这些事件用来调整更新过程的频率，不同的频率，数据的刷新和精度的差别是相当大的。
5、关于实现的几点想法
就实现的问题来说，可以考虑不同的解决方案。
数据更新过程依据工作流的概念性定义，自然导致采用在市面上通用的工作流系统的控制下的实现方式，如果这些系统提供各种事件类型和更新方案所需的所有的特点的话。
另一个解决方案，我们在描述组成在一定操作语义下执行的活动规则时已经提到。
我们选择的基本原则是灵活性和活动规则的动态演化性。
确实，更新策略不可能一下定义所有的东西，它需要不断跟踪用户需求，这些需求可以导致具体视图定义的改变或具体的品质方面的改变。
当品质方面的实际价值为了适应数据仓库反馈信息的变化或实现这种变化的技术而有所减慢时，这种活动规则也必须能够对此进行演化。
因此为了掌握数据仓库的复杂性和演化性，提供一种灵活的技术，它能够满足复杂性和演化性的要求，是非常重要的。
而这正是活动规则所要提供的。
在欧洲数据仓库研究项目的DWG[5]的相关研究中已经开发并发布了一个协议。
但是，活动规则并不能用来替代工作流。
工作流是更新过程的基本逻辑结构，而活动规则是工作流思想的具体操作实现。
6、结论
本文分析了数据仓库应用中的更新过程。
阐明了数据更新过程不只局限于视图维护过程，也不是数据导入古成。
通过一个简单的。
例子，我们已经说明数据更新过程能够基本上被看作是一个工作流。
我们定义了工作流的不同任务阶段，展现了它们在不同更新方案中的组织方式，这些不同的更新方案导致不同的更新语义。
我们也着重强调了不同的设计考虑对更新语义的影响。
我们也说明了这些考虑是怎样和一些品质因素像数据刷新率和一些限制像数据源的可用性和可存取性相关的。
升级会员 