我得到A 数据流（不管是基于文件或数据库），A包含field1 ， field2 ， field3 字段，然后我还有一个B数据流，B包含field4 ， field5 ， field6 ， 我现在想把它们 ‘加’ 起来， 应该怎么样做.
这是新手最容易犯错的一个地方，A数据流跟B数据流能够Join，肯定是它们包含join key ，join key 可以是一个字段也可以是多个字段。如果两个数据流没有join key ，那么它们就是在做笛卡尔积，一般很少会这样。比如你现在需要列出一个员工的姓名和他所在部门的姓名，如果这是在同一个数据库，大家都知道会在一个sql 里面加上where
限定条件，但是如果员工表和部门表在两个不同的数据流里面，尤其是数据源的来源是多个数据库的情况，我们一般是要使用Database Join 操作，然后用两个database table input 来表示输入流，一个输入是部门表的姓名，另一个是员工表的姓名，然后我们认为这两个表就可以 ”Join”
了，我们需要的输出的确是这两个字段，但是这两个字段的输出并不代表只需要这两个字段的输入，它们之间肯定是需要一个约束关系存在的。另外，无论是在做Join ， Merge ， Update ， Delete 这些常规操作的时候，都是先需要做一个compare 操作的，这个compare 操作都是针对compare key 的，无论两个表结构是不是一样的，比如employee
表和department 表，它们比较的依据就是employee 的外键department_id ， 没有这个compare key 这两个表是不可能连接的起来的.. 对于两个表可能还有人知道是直接sql 来做连接，如果是多个输入数据源，然后是三个表，有人就开始迷茫了，A表一个字段，B表一个字段，C表一个字段，然后就连Join操作都没有，直接database table output
， 然后开始报错，报完错就到处找高手问，他们的数据库原理老师已经在吐血了。如果是三个表连接，一个sql 不能搞定，就需要先两个表两个表的连接，通过两次compare key 连接之后得到你的输出，记住，你的输出并不能代表你的输入. 下面总结一下:
1. 单数据源输入，直接用sql 做连接
2. 多数据源输入，（可能是文本或是两个以上源数据库），用database join 操作.
3. 三个表以上的多字段输出.
Kettle的数据库连接是一个步骤里面控制一个单数据库连接，所以kettle的连接有数据库连接池，你可以在指定的数据库连接里面指定一开始连接池里面放多少个数据库连接，在创建数据库连接的时候就有Pooling 选项卡，里面可以指定最大连接数和初始连接数，这可以一定程度上提高速度.
我想在步骤A执行一个操作（更新或者插入），然后在经过若干个步骤之后，如果我发现某一个条件成立，我就提交所有的操作，如果失败，我就回滚，kettle提供这种事务性的操作吗？
Kettle里面是没有所谓事务的概念的，每个步骤都是自己管理自己的连接的，在这个步骤开始的时候打开数据库连接，在结束的时候关闭数据库连接，一个步骤是肯定不会跨session的（数据库里面的session），
另外，由于kettle是并行执行的，所以不可能把一个数据库连接打开很长时间不放，这样可能会造成锁出现，虽然不一定是死锁，但是对性能还是影响太大了。ETL中的事务对性能影响也很大，所以不应该设计一种依赖与事务方式的ETL执行顺序，毕竟这不是OLTP，因为你可能一次需要提交的数据量是几百GB都有可能，任何一种数据库维持一个几百GB的回滚段性能都是会不大幅下降的.
4. 我真的需要transaction 但又不想要一个很复杂的设计，能不能提供一个简单一点的方式
由于是使用的单数据库连接，所以可以有错误的时候回滚事务，不过要提醒一点是这种方式是以牺牲非常大的性能为前提条件的，对于太大的数据量是不适合的(个人仍然不建议使用这种方式)
我要在ETL过程中创建一个中间表，当某个条件成立的时候，我要把中间表的数据进行转换，当另一条件成立的时候我要对中间表进行另一个操作，我想使用数据库的临时表来操作，应该用什么步骤。
首先从temp 表的生命周期来分，temp分为 事务临时表和会话临时表，前面已经解释过了，kettle是没有所谓事务的概念的，所以自然也没有所谓的事务临时表。Kettle的每个步骤管理自己的数据库连接，连接一结束，kettle也就自然丢掉了这个连接的session 的handler ， 没有办法可以在其他步骤拿回这个session 的handler ，
所以也就不能使用所谓的会话临时表，当你尝试再开一个连接的时候，你可以连上这个临时表，但是你想要的临时表里面的数据都已经是空的(数据不一定被清除了，但是你连不上了)，所以不要设计一个需要使用临时表的转换
之所以会使用临时表，其实跟需要 ”事务” 特性有一点类似，都是希望在ETL过程中提供一种缓冲。临时表很多时候都不是某一个源表的全部数据的镜像，很多时候临时表都是很小一部分结果集，可能经过了某种计算过程，你需要临时表无非是基于下面三个特性：
1. 表结构固定，用一个固定的表来接受一部分数据。
2. 每次连接的时候里面没有数据。你希望它接受数据，但是不保存，每次都好像执行了truncate table 操作一样
3. 不同的时候连接临时表用同一个名字，你不想使用多个连接的时候用类似与temp1 ， temp2 ， temp3 ， temp4 这种名字，应为它们表结构一样。
既然临时表不能用，应该如何设计ETL过程呢？（可以用某种诡异的操作搞出临时表，不过不建议这样做罢了）
如果你的ETL过程比较的单线程性，也就是你清楚的知道同一时间只有一个这样的表需要，你可以创建一个普通的表，每次连接的时候都执行truncate 操作，不论是通过table output 的truncate table 选项，还是通过手工执行truncate table sql 语句（在execute sql script 步骤）都可以达到目的（基于上面的1，2 特性）
如果你的ETL操作比较的多线程性，同一时间可能需要多个表结构一样并且里面都是为空的表（基于上面1，2，3特性），你可以创建一个 “字符串+序列”的模式，每次需要的时候，就创建这样的表，用完之后就删除，因为你自己不一定知道你需要多少个这种类型的表，所以删除会比truncate 好一些。
下面举个例子怎么创建这种表：
在表的名字上加参数，前面接受一个sequence 或类似的输入操作.
需要注意的是这种参数表名包括database table input 或者execute sql script ，只要是参数作为表名的情况前面的输入不能是从数据库来的，应为没有办法执行这种preparedStatement语句，从数据库来的值后面的操作是 “值操作” ，而不是字符串替换，只有argument 或者sequence 操作当作参数才是字符串替换.
执行update table 操作是比较慢的，它会一条一条基于compare key 对比数据，然后决定是不是要执行update sql ， 如果你知道你要怎么更新数据尽可能的使用execute sql script 操作，在里面手写update sql （注意源数据库和目标数据库在哪），这种多行执行方式（update sql）肯定比单行执行方式（update table
操作）快的多。
另一个区别是execute sql script 操作是可以接受参数的输入的。它前面可以是一个跟它完全不关的表一个sql :
后面执行另一个表的更新操作：
kettle本身的性能绝对是能够应对大型应用的，一般的基于平均行长150的一条记录，假设源数据库，目标数据库以及kettle都分别在几台机器上（最常见的桌面工作模式，双核，1G内存），速度大概都可以到5000 行每秒左右，如果把硬件提高一些，性能还可以提升 ， 但是ETL 过程中难免遇到性能问题，下面一些通用的步骤也许能给你一些帮助.
尽量使用数据库连接池
尽量使用缓存，缓存尽量大一些（主要是文本文件和数据流）
可以使用sql 来做的一些操作尽量用sql
插入大量数据的时候尽量把索引删掉
合理的分区
如果删除操作是基于某一个分区的，就不要使用delete row 这种方式（不管是delete sql 还是delete 步骤），直接把分区drop 掉，再重新创建
尽量缩小输入的数据集的大小（增量更新也是为了这个目的）
要知道你的性能瓶颈在哪，可能有时候你使用了不恰当的方式，导致整个操作都变慢，观察kettle log 生成的方式来了解你的ETL操作最慢的地方。
远程数据库用文件+FTP 的方式来传数据 ，文件要压缩。（只要不是局域网都可以认为是远程连接）
源数据库的，硬件环境，是单数据源还是多数据源，数据库怎么分布的，做ETL的那台机器放在哪，操作系统和硬件环境是什么，目标数据仓库的数据库是什么，操作系统，硬件环境，数据库的字符集怎么选，数据传输方式是什么，开发环境，测试环境和实际的生产环境有什么区别，是不是需要一个中间数据库(staging 数据库)
，源数据库的数据库版本号是多少，测试数据库的版本号是多少，真正的目标数据库的版本号是多少……. 这些信息也许很零散，但是都需要一份专门的文档来描述这些信息，无论是你遇到问题需要别人帮助的时候描述问题本身，还是发现测试环境跟目标数据库的版本号不一致，这份专门的文档都能提供一些基本的信息
这个问题在官方FAQ里面也有提到，触发procedure 和 http client 都需要一个类似与触发器的条件，你可以使用generate row 步骤产生一个空的row ，然后把这条记录连上procedure 步骤，这样就会使这条没有记录的空行触发这个procedure (如果你打算使用无条件的单次触发) ，当然procedure 也可以象table input
里面的步骤那样传参数并且多次执行.
另外一个建议是不要使用复杂的procedure 来完成本该ETL任务完成的任务，比如创建表，填充数据，创建物化视图等等.
Kettle使用Java 通常使用的UTF8 来传输字符集，所以无论你使用何种数据库，任何数据库种类的字符集，kettle 都是支持的，如果你遇到了字符集问题，也许下面这些提示可以帮助你：
1. 单数据库到单数据库是绝对不会出现乱码问题的，不管原数据库和目标数据库是何种种类，何种字符集
2. 多种不同字符集的原数据库到一个目标数据库，你首先需要确定多种源数据库的字符集的最大兼容字符集是什么，如果你不清楚，最好的办法就是使用UTF8来创建数据库.
3. 不要以你工作的环境来判断字符集：现在某一个测试人员手上有一个oracle 的基于xxx 字符集的已经存在的数据库，并且非常不幸的是xxx 字符集不是utf8 类型的，于是他把另一个基于yyy字符集的oracle 数据库要经过某一个ETL过程转换到oracle ， 后来他发现无论怎么样设置都会出现乱码，这是因为你的数据库本身的字符集不支持，无论你怎么设置都是没用的.
测试的数据库不代表最后产品运行的数据库，尤其是有时候为了省事把多个不同的项目的不相关的数据库装在同一台机器上，测试的时候又没有分析清楚这种环境，所以也再次强调描述物理环境的重要性.
4. 你所看到的不一定代表实际储存的：mysql 处理字符集的时候是要在jdbc 连接的参数里面加上字符集参数的，而oracle 则是需要服务器端和客户端使用同一种字符集才能正确显示，所以你要明确你所看到的字符集乱码不一定代表真的就是字符集乱码，这需要你检查在转换之前的字符集是否会出现乱码和转换之后是否出现乱码，你的桌面环境可能需要变动一些参数来适应这种变动
5. 不要在一个转换中使用多个字符集做为数据源.
options usage ， 点击这个按钮会把你带到对应各个数据库的连接参数的官方的一个参数列表页面，通过查询这个列表页面你就可以知道那种数据库可以使用何种参数了.
对于SQL 选项卡就是在你一连接这个Connection 之后，Kettle 会立刻执行的sql 语句，个人比较推荐的一个sql 是执行把所有日期格式统一成同一格式的sql ，比如在oracle 里面就是:
这样可以避免你在转换的时候大量使用to_date() ， to_char 函数而仅仅只是为了统一日期格式，对于增量更新的时候尤其适用.
等私有的解决方法，如果你确定你的需求不是数据集成这方面的，那么也许kettle 并不是一个很好的首选方案，你应该咨询一下专业的DBA人士也会会更好.
转换成文本文件保存，然后用svn 或cvs 或任意你熟悉的版本控制系统将其保存，kettle 将在下一个版本加入版本控制的功能（做的更易用）.
当ETL转换出现不可预知的问题时，或是你不清楚某个步骤的功能是什么的情况下，你可能需要创建一个模拟环境来调适程序，下面一些建议可能会有所帮助：
尽量使用generate row 步骤或者固定的一个文本文件来创建一个模拟的数据源
模拟的数据源一定要有代表性，数据集一定尽量小（为了性能考虑）但是数据本身要足够分散.
创建了模拟的数据集后你应该清楚的知道你所要转换之后的数据时什么样的.
在ETL任务中由于数据问题出现转换错误是一件非常正常的事情，你不应该设计一个依赖于临时表或者拥有事务特点的ETL过程，面对数据源质量问题的巨大挑战，错误处理是并不可少的，kettle同样提供非常方便的错误处理方式，在你可能会出错的步骤点击右键选择Define Error handing ， 它会要求你指定一个处理error
的步骤，你可以使用文本文件或者数据库的表来储存这些错误信息，这些错误信息会包含一个id 和一个出错的字段，当你得到这些错误信息之后就需要你自己分析出错的原因了，比如违反主键约束可能是你生成主键的方式有错误或者本身的数据有重复，而违反外键约束则可能是你依赖的一些表里面的数据还没有转换或者外键表本身过滤掉了这些数据. 当你调整了这些错误之后，确定所有依赖的数据都被正确的处理了.kettle
user guide 里面有更详细的解释，里面还附带了一个使用javascript 来处理错误的示例，这种方式可以作为处理简单数据质量的方式.
Kettle 提供了丰富的文档和使用手册，小到一个数据库连接怎么连，大到一个功能怎么实现，所有的参数列表，对话框的每一个输入输出代表什么意思都有解释，所以当你遇到问题你应该第一时间翻阅这些文档，也许上面已经告诉你怎么做了. 另外kettle
还有一个非常活跃的社区，你可以到上面提问，但是记住在你提问之前先搜索一下论坛看有没有类似的问题已经问过了，如果没有记得描述清楚你的问题
ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程。它是构建数据仓库的重要环节。数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合，用以支持经营管理中的决策制定过程。数据仓库系统中有可能存在着大量的噪声数据,引起的主要原因有：滥用缩写词、惯用语、数据输入错误、重复记录、丢失值、拼写变化等。即便是一个设计和规划良好的数据库系统，如果其中存在着大量的噪声数据，那么这个系统也是没有任何意义的，因为“垃圾进，垃圾出”（garbage
out），系统根本就不可能为决策分析系统提供任何支持。为了清除噪声数据，必须在数据库系统中进行数据清洗。目前有不少数据清洗研究和ETL研究，但是如何在ETL过程中进行有效的数据清洗并使这个过程可视化，此方面研究不多。本文主要从两个方面阐述ETL和数据清洗的实现过程：ETL的处理方式和数据清洗的实现方法。
本文所采用的ETL方法是数据库段区域中的ETL处理方式，它不使用外部引擎而是使用数据库作为唯一的控制点。由于源系统SQLserver2000是关系数据库，它的段表也是典型的关系型表。成功地将外部未修改数据载入数据库后，再在数据库内部进行转换。数据库段区域中的ETL处理方式执行的步骤是提取、装载、转换，即通常所说的ELT。这种方式的优点是为抽取出的数据首先提供一个缓冲以便于进行复杂的转换，减轻了ETL进程的复杂度。
首先，在理解源数据的基础上实现数据表属性一致化。为解决源数据的同义异名和同名异义的问题，可通过元数据管理子系统，在理解源数据的同时，对不同表的属性名根据其含义重新定义其在数据挖掘库中的名字，并以转换规则的形式存放在元数据库中，在数据集成的时候，系统自动根据这些转换规则将源数据中的字段名转换成新定义的字段名，从而实现数据挖掘库中的同名同义。
其次，通过数据缩减，大幅度缩小数据量。由于源数据量很大，处理起来非常耗时，所以可以优先进行数据缩减，以提高后续数据处理分析效率。
最后，通过预先设定数据处理的可视化功能节点，达到可视化的进行数据清洗和数据转换的目的。针对缩减并集成后的数据，通过组合预处理子系统提供各种数据处理功能节点，能够以可视化的方式快速有效完成数据清洗和数据转换过程。
现在是一个Google的时代，而对于开发者，开源已成为最重要的参考书。对于某课题，不管你是深入研究还是初窥门径。估且google一把，勾一勾同行的成就，你必会获益良多。
说到ETL开源项目，Kettle当属翘首，项目名称很有意思，水壶。按项目负责人Matt的说法：把各种数据放到一个壶里，然后呢，以一种你希望的格式流出。呵呵，外国人都很有联想力。
看了提供的文档，然后对发布程序的简单试用后，可以很清楚得看到Kettle的四大块：
这是一个GUI工具，操作方式主要通过拖拖拉拉，勿庸多言，一看就会。
何谓工作？多个作业项，按特定的工作流串联起来，开成一项工作。正如：我的工作是软件开发。我的作业项是：设计、编码、测试！先设计，如果成功，则编码，否则继续设计，编码完成则开始设计，周而复始，作业完成。
转换：指定更细的转换任务，通过Spoon生成。通过Field来输入参数；
执行shell脚本：如dos命令。
批处理：(注意：windows批处理不能有输出到控制台)。
Job包：作为嵌套作业使用。
JavaScript执行：这个比较有意思，我看了一下源码，如果你有自已的Script引擎，可以很方便的替换成自定义Script，来扩充其功能；
SFTP：安全的Ftp协议传输；
HTTP方式的上/下传。
如上文所述，工作流是作业项的连接方式。分为三种：无条件，成功，失败，为了方便工作流使用，KETTLE提供了几个辅助结点单元(也可将其作为简单的作业项)：
Start单元：任务必须由此开始。设计作业时，以此为起点。
OK单元：可以编制做为中间任务单元，且进行脚本编制，用来控制流程。
ERROR单元：用途同上。
DUMMY单元：什么都不做，主要是用来支持多分支的情况，文档中有例子。
支持XML存储，或存储到指定数据库中。
一些默认的配置(如数据库存储位置……)，在系统的用户目录下，单独建立了一个.Kettle目录，用来保存用户的这些设置。
是一个作业执行引擎，用来执行作业。这是一个命令行执行工具，没啥可讲的，就把它的参数说明列一下。
嗯，居然不支持调度。看了一下文档，建议使用操作系统提供的调度器来实现调度，比如：Windows可以使用它的任务计划工具。
GUI工作，用来设计数据转换过程，创建的转换可以由Pan来执行，也可以被Chef所包含，作为作业中的一个作业项。
可以支持多文件合并，有不少参数，基本一看参数名就能明白其意图。
实际上是视图方式输入，因为输入的是sql语句。当然，需要指定数据源(数据源的定制方式在后面讲一下)
就是取一些固定的系统环境值，如本月最后一天的时间，本机的IP地址之类。
这个需要匹配使用，主要用于生成多行的数据输入，比如配合Add sequence可以生成一个指定序号的数据列。
这三个没啥可讲的，看看参数就明了。
对输入的行记录数据的字段进行更改 (更改数据类型，更改字段名或删除) 数据类型变更时，数据的转换有固定规则，可简单定制参数。可用来进行数据表的改装。
对输入的行记录进行指定复杂条件的过滤。用途可扩充sql语句现有的过滤功能。但现有提供逻辑功能超出标准sql的不多。
对指定的列以升序或降序排序，当排序的行数超过5000时需要临时表。
为数据流增加一个序列，这个配合其它Step(Generate rows, rows join)，可以生成序列表，如日期维度表(年、月、日)。
不做任何处理，主要用来作为分支节点。
对所有输入流做笛卡儿乘积。
分组，用途可扩充sql语句现有的分组，聚合函数。但我想可能会有其它方式的sql语句能实现。
使用mozilla的rhino作为脚本语言，并提供了很多函数，用户可以在脚本中使用这些函数。
该步骤可以从透视表中还原数据到事实表，通过指定维度字段及其分类值，度量字段，最终还原出事实表数据。
去掉输入流中的重复行，在使用该节点前要先排序，否则只能删除连续的重复行。
提供了一组函数对列值进行运算，用该方式比用户自定义JAVA SCRIPT脚本速度更快。
用于比较两组输入数据，一般用于更新后的数据重新导入到数据仓库中。
表扁平化处理，指定需处理的字段和扃平化后的新字段，将其它字段做为组合Key进行扃平化处理。
命令行执行方式，可以执行由Spoon生成的转换任务。同样，不支持调度。参数与Kitchen类似，可参见Pan的文档。
可以配置多个数据源，在Job或是Trans中使用，这意味着可以实现跨数据库的任务。支持大多数市面上流行的数据库。
1、 转换功能全，使用简洁。作业项丰富，流程合理。但缺少调度。
2、 java代码，支持的数据源范围广，所以，跨平台性较好。
3、 从实际项目的角度看，和其它开源项目类似，主要还是程序员的思维，缺少与实际应用项目(专业领域)的更多接轨，当然，项目实施者的专注点可能在于一个平台框架，而非实际应用(实际应用需要二次开发)。
4、 看过了大多数源码，发现源码的可重用性不是太好(缺少大粒度封装)，有些关键部分好像有Bug。比如：个别class过于臃肿，线程实现的同步有问题。
5、 提供的工具有些小错，如参数的容错处理。
做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。回忆一下工作这么些年来，处理数据迁移、转换的工作倒还真的不少。但是那些工作基本上是一次性工作或者很小数据量，使用access、
DTS或是自己编个小程序搞定。可是在数据仓库系统中，ETL上升到了一定的理论高度，和原来小打小闹的工具使用不同了。究竟什么不同，从名字上就可以看到，人家已经将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。
其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。
等，且不说他们的好坏。从应用角度来说，ETL的过程其实不是非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的便利。但另一方面，开发人员容易迷失在这些工具中。举个例子，VB是一种非常简单的语言并且也是非常易用的编程工具，上手特别快，但是真正VB的高手有多少？微软设计的产品通常有个原则是“将使用者当作傻瓜”，在这个原则下，微软的东西确实非常好用，但是对于开发者，如果你自己也将自己当作傻瓜，那就真的傻了。
ETL工具也是一样，这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开发效率。从使用效果来说，确实使用这些工具能够非常快速地构建一个job来处理某个数据，不过从整体来看，并不见得他的整体效率会高多少。问题主要不是出在工具上，而是在设计、开发人员上。他们迷失在工具中，没有去探求ETL的本质。
可以说这些工具应用了这么长时间，在这么多项目、环境中应用，它必然有它成功之处，它必定体现了ETL的本质。如果我们不透过表面这些工具的简单使用去看它背后蕴涵的思想，最终我们作出来的东西也就是一个个独立的job，将他们整合起来仍然有巨大的工作量。大家都知道“理论与实践相结合”，如果在一个领域有所超越，必须要在理论水平上达到一定的高度
ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据。其间，数据的抽取、清洗、转换和装载形成串行或并行的过程。ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。和OLTP系统中不同，那里充满这单条记录的insert、update和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般都是DBMS系统自身附带的工具，例如Oracle
ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来说。
1、静态的ETL单元和动态的ETL单元实例；一次转换指明了某种格式的数据如何格式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以在运行时，当这个ETL单元创建一个实例时才指定。对于静态和动态的ETL单元，Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multiple
instances，而且还不是默认选项。Powermart中将这两个概念加以区分，静态的叫做Mapping，动态运行时叫做Session。
2、ETL元数据；元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数据。主要包括每次转换前后的数据结构和转换的规则。ETL元数据还包括形式参数的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数，实参不在元数据管理范围之内。
3、数据流程的控制；要有可视化的流程编辑工具，提供流程定义和流程监控功能。流程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和转换只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操作。当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有找到很好的细分策略。比如，我们可以规定将装载一个表的功能作为一个ETL单元，但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个Hash表，要将这个Hash表装入内存两次。
4、转换规则的定义方法；提供函数集提供常用规则方法，提供规则定义语言描述规则。
5、对数据的快速索引；一般都是利用Hash技术，将参照关系表提前装入内存，在转换时查找这个hash表。Datastage中有Hash文件技术，Powermart也有类似的Lookup功能。
昨在IT-Director上阅读一篇报告，关于ETL产品分类的。一般来说，我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。它们包括：
1、交互式运行环境，你可以指定数据源、目标数据，指定规则，立马ETL。这种交互式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。还有数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要牺牲一定的性能为代价。所以如果要处理海量数据的话，每次读取一条记录，每次对规则进行解释执行，每次在写入一条记录，这对性能影响是非常大的。
2、专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放在一些周边的功能上，例如读文件功能、写数据库的功能，而将精力主要放在规则的实现上面。这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关（这也是不可忽视的因素之一）。对于处理大数据量，处理复杂转换逻辑，这种方式的ETL实现是非常直观的。
3、代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要运行这个ETL过程，必须要编译才行。Datastage就是类似这样的产品，设计好的job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是什么。以前我设计的ETL工具大挪移其实也是归属于这一类，它提供了界面让用户编写规则，最后生成C++语言，编译后即可运行。这类工具的特点就是要在界面上下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完成读、写和转换函数。大挪移在这方面就太弱了，规则必须手写，而且要写成标准c++语法，这未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。另外一点，这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还有提供特定语言来实现高级功能。例如Datastage提供一种类Basic的语言，不过他的Job的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。
4、最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub一样地工作。将这种类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的方法，此类主要从数据处理角度。目前有一些产品属于EAI（Enterprise Application
Integration），它的数据集成主要是一种准实时性。所以这类产品就像Hub一样，不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中去。
虽然，这些类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。
ETL探求之一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？
从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：
1、大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。
2、大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left
Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。
3、站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对
Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。
4、聚集。数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特定字段（维度），对度量字段再使用某种聚集函数。但是对于大数据量情况下，聚集算法的优化仍是探究的一个课题。例如是直接使用SQL的 Group by，还是先排序，在处理。
从数据的转换的微观细节分，可以分成下面的几个基本类型，当然还有一些复杂的组合情况，例如先运算，在参照转换的规则，这种基于基本类型组合的情况就不在此列了。ETL的规则是依赖目标数据的，目标数据有多少字段，就有多少条规则。
1、直接映射，原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算；
2、字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般对数值型字段而言；
3、参照转换，在转换中通常要用数据源的一个或多个字段作为Key。
“不要绝对的数据准确，但要知道为什么不准确。”这是我们在构建BI系统是对数据准确性的要求。确实，对绝对的数据准确谁也没有把握，不仅是系统集成商，包括客户也是无法确定。准确的东西需要一个标准，但首先要保证这个标准是准确的，至少现在还没有这样一个标准。客户会提出一个相对标准，例如将你的OLAP数据结果和报表结果对比。虽然这是一种不太公平的比较，你也只好认了吧。
首先在数据源那里，已经很难保证数据质量了，这一点也是事实。在这一层有哪些可能原因导致数据质量问题？可以分为下面几类：
1、数据格式错误，例如缺失数据、数据值超出范围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。
2、数据一致性，同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在帐务表中会出现一个用户表中没有的用户ID，在例如有些代码在代码表中找不到等。
3、业务逻辑的合理性，这一点很难说对与错。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。对这种情况，有什么办法吗？
构建一个BI系统，要做到完全理解数据源系统根本就是不可能的。特别是数据源系统在交付后，有更多维护人员的即兴发挥，那更是要花大量的时间去寻找原因。以前曾经争辩过设计人员对规则描述的问题，有人提出要在ETL开始之前务必将所有的规则弄得一清二楚。我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生重大影响。
1、规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在探求之三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去很多手工操作了。
2、ETL开发错误。即时规则很明确，ETL开发的过程中也会发生一些错误，例如逻辑错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常开发人员没注意，一个大于等于号写成大于号就导致数据错误。
3、人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。
上回提到ETL数据质量问题，这是无法根治的，只能采取特定的手段去尽量避免，而且必须要定义出度量方法来衡量数据的质量是好还是坏。对于数据源的质量，客户对此应该更加关心，如果在这个源头不能保证比较干净的数据，那么后面的分析功能的可信度也都成问题。数据源系统也在不断进化过程中，客户的操作也在逐渐规范中，BI系统也同样如此。本文探讨一下对数据源质量和ETL处理质量的应对方法。
如何应对数据源的质量问题？记得在onteldatastage列表中也讨论过一个话题－"-1的处理"，在数据仓库模型维表中，通常有一条-1记录，表示“未知”，这个未知含义可广了，任何可能出错的数据，NULL数据甚至是规则没有涵盖到的数据，都转成-1。这是一种处理脏数据的方法，但这也是一种掩盖事实的方法。就好像写一个函数FileOpen(filename)，返回一个错误码，当然，你可以只返回一种错误码，如-1，但这是一种不好的设计，对于调用者来说，他需要依据这个错误码进行某些判断，例如是文件不存在，还是读取权限不够，都有相应的处理逻辑。数据仓库中也是一样，所以，建议将不同的数据质量类型处理结果分别转换成不同的值，譬如，在转换后，-1表示参照不上，-2表示NULL数据等。不过这仅仅对付了上回提到的第一类错误，数据格式错误。对于数据一致性和业务逻辑合理性问题，这仍有待探求。但这里有一个原则就是“必须在数据仓库中反应数据源的质量”。
对于ETL过程中产生的质量问题，必须有保障手段。从以往的经验看，没有保障手段给实施人员带来麻烦重重。实施人员对于反复装载数据一定不会陌生，甚至是最后数据留到最后的Cube，才发现了第一步ETL其实已经错了。这个保障手段就是数据验证机制，当然，它的目的是能够在ETL过程中监控数据质量，产生报警。这个模块要将实施人员当作是最终用户，可以说他们是数据验证机制的直接收益者。
首先，必须有一个对质量的度量方法，什么是高质什么是低质，不能靠感官感觉，但这却是在没有度量方法条件下通常的做法。那经营分析系统来说，联通总部曾提出测试规范，这其实就是一种度量方法，例如指标的误差范围不能高于5%等，对系统本身来说其实必须要有这样的度量方法，先不要说这个度量方法是否科学。对于ETL数据处理质量，他的度量方法应该比联通总部测试规范定义的方法更要严格，因为他更多将BI系统看作一个黑盒子，从数据源到展现的数据误差允许一定的误差。而ETL数据处理质量度量是一种白盒的度量，要注重每一步过程。因此理论上，要求输入输出的指标应该完全一致。但是我们必须正面完全一致只是理想，对于有误差的数据，必须找到原因。
在质量度量方法的前提下，就可以建立一个数据验证框架。此框架依据总量、分量数据稽核方法，该方法在高的《数据仓库中的数据稽核技术》一文中已经指出。作为补充，下面提出几点功能上的建议：
1、提供前端。将开发实施人员当作用户，同样也要为之提供友好的用户界面。《稽核技术》一文中指出测试报告的形式，这种形式还是要依赖人为判断，在一堆数据中去找规律。到不如用OLAP的方式提供界面，不光是加上测试统计出来的指标结果，并且配合度量方法的计算。例如误差率，对于误差率为大于0的指标，就要好好查一下原因了。
2、提供框架。数据验证不是一次性工作，而是每次ETL过程中都必须做的。因此，必须有一个框架，自动化验证过程，并提供扩展手段，让实施人员能够增加验证范围。有了这样一个框架，其实它起到规范化操作的作用，开发实施人员可以将主要精力放在验证脚本的编写上，而不必过多关注验证如何融合到流程中，如何展现等工作。为此，要设计一套表，类似于DM表，每次验证结果数据都记录其中，并且自动触发多维分析的数据装载、发布等。这样，实施人员可以在每次装载，甚至在流程过程中就可以观察数据的误差率。特别是，如果数据仓库的模型能够统一起来，甚至数据验证脚本都可以确定下来，剩下的就是规范流程了。
3、规范流程。上回提到有一种ETL数据质量问题是由于人工处理导致的，其中最主要原因还是流程不规范。开发实施人员运行单独一个ETL单元是很方便的，虽然以前曾建议一个ETL单元必须是“可重入”的，这能够解决误删数据，重复装载数据问题。但要记住数据验证也是在流程当中，要让数据验证能够日常运作，就不要让实施者感觉到他的存在。总的来说，规范流程是提高实施效率的关键工作，这也是以后要继续探求的。
对于元数据（Metadata）的定义到目前为止没有什么特别精彩的，这个概念非常广，一般都是这样定义，“元数据是描述数据的数据（Data about
Data）”，这造成一种递归定义，就像问小强住在哪里，答，在旺财隔壁。按照这样的定义，元数据所描述的数据是什么呢？还是元数据。这样就可能有元元元...元数据。我还听说过一种对元数据，如果说数据是一抽屉档案，那么元数据就是分类标签。那它和索引有什么区别？
元数据体现是一种抽象，哲学家从古至今都在抽象这个世界，力图找到世界的本质。抽象不是一层关系，它是一种逐步由具体到一般的过程。例如我->男人->人->哺乳动物->生物这就是一个抽象过程，你要是在软件业混会发现这个例子很常见，面向对象方法就是这样一种抽象过程。它对世界中的事物、过程进行抽象，使用面向对象方法，构建一套对象模型。同样在面向对象方法中，类是对象的抽象，接口又是对类的抽象。因此，我认为可以将“元”和“抽象”换一下，叫抽象数据是不是好理解一些。
常听到这样的话，“xx领导的讲话高屋建瓴，给我们后面的工作指引的清晰的方向”，这个成语“高屋建瓴”，站在10楼往下到水，居高临下，能砸死人，这是指站在一定的高度看待事物，这个一定的高度就是指他有够“元”。在设计模式中，强调要对接口编程，就是说你不要处理这类对象和那类对象的交互，而要处理这个接口和那个接口的交互，先别管他们内部是怎么干的。
元数据存在的意义也在于此，虽然上面说了一通都撤到哲学上去，但这个词必须还是要结合软件设计中看，我不知道在别的领域是不是存在Metadata这样的叫法，虽然我相信别的领域必然有类似的东东。元数据的存在就是要做到在更高抽象一层设计软件。这肯定有好处，什么灵活性啊，扩展性啊，可维护性啊，都能得到提高，而且架构清晰，只是弯弯太多，要是从下往上看，太复杂了。很早以前，我曾看过
backorifice的代码，我靠，一个简单的功能，从这个类转到父类，又转到父类，很不理解，为什么一个简单的功能不在一个类的方法中实现就拉到了呢？现在想想，还真不能这样，这虽然使代码容易看懂了，但是结构确实混乱的，那他只能干现在的事，如果有什么功能扩展，这些代码就废了。
我从98年刚工作时就开始接触元数据的概念，当时叫做元数据驱动的系统架构，后来在
QiDSS中也用到这个概念构建QiNavigator，但是现在觉得元数据也没啥，不就是建一堆表描述界面的元素，再利用这些数据自动生成界面吗。到了数据仓库系统中，这个概念更强了，是数据仓库中一个重要的部分。但是至今，我还是认为这个概念过于玄乎，看不到实际的东西，市面上有一些元数据管理的东西，但是从应用情况就得知，用的不多。之所以玄乎，就是因为抽象层次没有分清楚，关键就是对于元数据的分类（这种分类就是一种抽象过程）和元数据的使用。你可以将元数据抽象成0和1，但是那样对你的业务有用吗？必须还得抽象到适合的程度，最后问题还是“度”。
数据仓库系统的元数据作用如何？还不就是使系统自动运转，易于管理吗？要做到这一步，可没必要将系统抽象到太极、两仪、八卦之类的，业界也曾定义过一些元数据规范，向CWM、XMI等等，可以借鉴，不过俺对此也是不精通的说，以后再说。
JAVA的脚步编写功能，可以灵活地自定义ETL过程，使自行定制、批量处理等成为可能，这才是一个程序员需要做的工作，而不仅是象使用word一样操作
