实时的ETL系统

搜狐博客 > 数据仓库（data warehouse） > 日志

2007-08-02 | 实时的ETL系统

实时ETL系统

1. CRM的趋势

收集数据仓库里所有的客户信息，智能的选择和使用商业数据，持续从数据仓库收集客户信息，并且实现企业级数据的共享和同步。

2. 纬度管理员的角色

对数据集市里纬度表的定义、维护、确认纬度属性的作用。

实时的数据仓库系统要为所有的用户最新和最有意义的数据，快速的向事实表加载数据，实时系统的巨大优势在于对关键纬度的同步更新，例如，客户、产品纬。

纬度管理员不仅要为数据集市提供确认的数据，而且要使用一些方法对系统内的数据进行同步的更新。、

3. 对需求的分类

1) 对新数据和历史数据的需求

考虑使用实时系统的情况

Ø 小于五分钟的响应时间

公司确切要五分钟以内的更新的数据就要操作系统中直接运行出报表。

EII可以满足以上的需求。、

Ø 单一的数据源对历史数据需求几乎没有

这种报表不需要由数据仓库来提供集成的历史的数据，而且最好从操作型数据系统中直接提取。最好，为这种需求提供数据接口，这样就觉得数据是从数据仓库而来。

Ø 和数据仓库毫不相关的报表

Ø 还没有搭建好数据仓库的公司

2) 只是事实和纬度变化吗

类型1、2、3都不会在数据的抽取时检测到纬度的变化。

3) 触发器、连续的探查、事件的响应

数据仓库对前台和后台有明显的界限，实时的系统就没有明确的界限。有三种的方式end-end的方式：触发器、连续的探查、事件的响应

实时ETL和最终应用用户的连接，不是推就是拉的方式。

4) 数据的集成还是应用的集成

Ø 数据的集成

一般的，把数据从各个数据库里数据汇集就是数据的集成。通常，这些解决方案是点对点的。本质上，数据共享在后台是分开应用的，逻辑上是一个整体。

Ø 应用的集成

就是建立一个新的解决方案，把所有的应用通过中间件集成起来。

5) 点对点和HUB的方式

这种方式有一个应用中的数据发生变化，就需要大量的数据的变化的接口。

优点，可以不用使用复杂的EAI中间件、可以部分的应用到数据集成CTF工具上。

这种方式可以减少数据的接口。但是需要EAI中间件,这个组件很贵。

每个应用需要Adapter把特殊的事务转化成通用的消息以在各个应用解释执行。从长远的角度讲，选择hub-and-spoke的方式。

6) 对数据的清洗的考虑

4. 实时ETL系统的几种方式

1) 微批处理

微批处理的方式和我们通常的ETL处理方式很相似，但是处理的时间间隔要短，例如间隔一个小时处理一次，这些频繁运行的微批处理又另外一个传统的ETL过程运行并且将数据直接插入到数据集市的实时分区里。每天实时分区把数据copy到静态的数据集市里，并清空。

由于纬度的属性值一天变化很多次，这样就不能采用类型2、类型3的形式。

有种方式，就是忽略一天中纬度的变化，为新的实例产生新的记录，其他的都使用默认值，这可以满足实时ETL系统的需求，但弱化了实时的优势。

最好的方式，采用微型纬度，把经常变化的纬度属性拆分出来。

折中的方法，在一天中的变化采用类型1 的方式，一天结束后，采用类型2 的方式加载数据。

几种鉴定数据变化的方法：

Ø 时间戳：这个方法为所有在操作型系统的任何变化打时间戳，来区分变化的数据，这样就会频繁的对数据进行更新和插入的操作。

Ø ETL的日志表：在OLTP环境中创建触发器，当有数据新增或变化时产生一个唯一的标识插入ETL的日志记录表中。这种方法有局限性，因为在OLTP的系统中使用触发器不适当的。

Ø DBMS日志

Ø 网络探查器

2) Enterprise Application Integration

Adapters用来将系统中所有的逻辑的需要转化可执行的消息

Brokers用来适当的传输消息。

使用EAI的方式来处理大量的数据效率会很低，因为每个事务都要转化为EAI的消息。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7724693/viewspace-940264/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7724693/viewspace-940264/