E工具对比参考.docx
《E工具对比参考.docx》由会员分享，可在线阅读，更多相关《E工具对比参考.docx（22页珍藏版）》请在冰豆网上搜索。
E工具对比参考
参考1：
ETL厂商
Reiking
IBMinformationserver（datastage）
informatic
OnceDI
beeload
ODI（oracledataintegrate
基本架构
支持运行平台
windows/unix/Linux
windows/unix/linux
windows/unix/linux
windows
windows/linux
windows/linux
数据访问模式支持
绝大部分支持
绝大部分支持
绝大部分支持
绝大部分支持
绝大部分支持
绝大部分支持
有局限性，与oracle数据库耦合太深。
数据抽取方式
支持生成文件（落地）再导入;直接导入;消息协议
直接导入；导入方式,数据导入支持批量加载（SQLloader方式）、insert模式、行删除模式
其中insert模式是插入到临时表，然后更新,需要手工写update语句，配置比较复杂,
行删除模式这种方式不考虑，性能肯定会非常差。
批量加载模式，是对方工程师推荐的测试方案，其性能应该是最快的.以下测试是基于批量加载模式
直接导入;数据导入目的库有两种加载方式
normal和bulk，即普通插入和批量加载。
批量加载需要先将索引drop掉，在加载完成后重新创建，但是这种方式在对付
大数据量时很慢，例如下文测试hisdeliver1个月的数据抽取,286万记录，需要4分47秒，比普通插入
要慢很多。
下面的测试结果由informatic的工程师，其基于normal模式
只支持落地方式
直接导入
直接导入也可以使用dblink（oracle->oracle）,透明网关（sql->oracle））
实时增量ETL支持
递增字段实现，触发器模式,支持OracleCDC
CDC,实现秒级别的增量
CDC,实现秒级别的增量，另外付费购买
触发器模式/递增字段实现
触发器模式/递增字段实现
触发器模式/递增字段实现/stream（cdc）
性能
单表hisdeliver抽取,记录数124810，耗时比较
1分16秒
17秒
15秒
3分42秒
2分7秒
19S
单表hisdeliver抽取,记录数2859999，耗时比较
22分12秒
6分12秒
2分58秒
30分钟以上
未测试
3分49S
采集sqlserver数据;采集表zygd（记录数:
597872）
测试报错
41秒
16秒
未测试
3分17秒
19S
流程中是否支持并行加载
支持
支持
支持
不支持,只能手工同时发起多个流程来实现并行加载
支持
支持（流程中串行异步模式）
并行加载性能
client730279行
5分钟
1分14秒
2分02秒
14分33秒
无法对并行流程进行更新的监控，只有整体运行完成时间,7分12秒
2分13秒
clientinfo739278行
7分钟
2分18秒
1分50秒
14分07秒
1分29秒
stockholder1083789
11分钟
2分59秒
3分01秒
14分50秒
3分23秒
hisdeliver124810行
未加载
48秒
20秒
4分31秒
2分44秒
异常处理
支持邮件通知
支持邮件通知
支持邮件通知
不支持
支持邮件通知
支持邮件通知
ETL管理
权限管理
支持
支持
支持
支持
支持
ETL工作流
支持顺序、并行工作流、支持时间、事件触发
支持顺序、并行工作流、支持时间、文件到达触发
支持顺序、并行工作流、支持时间、事件、文件到达触发
支持顺序工作流、支持时间触发
支持顺序、并行工作流、支持时间。
在工作流支持循环
支持顺序、并行工作流、支持时间
流程触发
定时、事件
只能定时（支持到天级别），比较弱
定时（支持到分钟级别）、事件触发
定时、事件触发
定时、事件触发
运行监控
较弱
较强
较强
较弱
较弱
有专门的WEB工具来展示
ETL日志与报告
详细,但是出错信息需要查bad数据文件
很详细,能够看到所有的操作
很详细,能够看到所有的操作
不是很详细
比较详细
比较详细
部署
强，采用SOA架构,可以任意发布服务
较强
较强
可以任意发布
可以任意发布，按机器进行收费
可以任意发布，按CPU进行收费
流程调度
可以按日定时调度；可以支持到秒级别的轮询调度（实现实时采集）；无法支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程；支持变量模式,支持变量从某个表读取然后替换相应的变量，必须通过外部shell调用替换
可以按日定时调度；无法支持到秒级别的轮询调度（实现实时采集）；无法支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程;支持变量模式,无法支持变量从某个表读取然后替换相应的变量，必须通过外部shell调用替换
可以按日定时调度；可以支持到秒级别的轮询调度（实现实时采集）；无法支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程;支持变量模式,支持变量从某个表读取然后替换相应的变量，必须通过外部shell调用替换
可以按日定时调度；可以支持到秒级别的轮询调度（实现实时采集）；无法支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程
可以按日定时调度；可以支持到秒级别的轮询调度（实现实时采集）；支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程
可以按日定时调度；可以支持到秒级别的轮询调度（实现实时采集）；支持事件触发（例如清算完成）调度,必须编写调度程序，通过API调用流程;支持变量模式,支持变量从某个表读取然后替换相应的变量，必须通过外部shell调用替换
其他印象（可操作性，易用性,界面友好性）
在都采用批量加载时，大量数据时的性能
hisdeliver2859999行
6分12秒
5分27秒
hisdeliver4350338行
10分53秒
6分51秒（5分钟导数据，1分51秒建索引
hisdeliver
29分56秒（25分钟导数据,4分56秒）
18分4秒（13分24秒导数据,4分40秒建索引）
hisoperationtotal
27分21秒（20分2秒导数据;7分19秒建索引）
26分56秒（17分10秒导数据,9分46秒导数据）
在都采用批量加载时，大量数据时的性能（不带索引）
hisdeliver8276997行
19分40秒
bulk:
10分23秒
normal:
10分31秒
hisoperationtotal
5分24秒
4分18秒
在都采用批量加载时，大量数据时的性能（不带索引）
hisdeliver在上述里已有8276997行数据后，再次追加3945469行
8分47秒
6分钟
在都采用批量加载时，大量数据时的性能（不带索引）
hisdeliver加载3945469行
7分52秒
6分10秒
0
参考2：
对比项
InformaticaPowerCenter
IBMDatastage
产品完整性对比
Ø数据整合部分：
PowerCenter，是业界公认领导者
Ø数据质量管理：
DataQuality，成熟稳定技术，在中国有大规模应用的成功案例。
Ø实时数据捕获：
PowerExchange，业界领先实时采集技术，支持广泛数据源的CDC和Realtime，与PowerCenter无缝集成。
Ø元数据管理：
MetadataManager，是业界领先的企业级元数据管理平台，可做到字段级的元数据各项分析，有广泛的元数据采集接口，图形化无需编程，并可自动维护变更。
Ø数据整合部分：
Datastage，属于业界一类产品
Ø数据质量管理：
QualityStage，收购的技术，不是主要其主要产品组成
Ø实时数据捕获：
MQ和DataMirror的技术，技术复杂，与DataStage是不同风格产品，产品的耦合度极差。
Ø元数据管理：
MetaStage，几乎免费的产品，应用性极差，并不能管理企业级的元数据。
而新推出的产品与旧有产品线耦合度差，并未经过市场的考验。
开发人员的使用效率
ØInformatica是全图形化的开发模式，不需要编码，工具易使用，界面友好、直观。
Ø专业的三天培训，可使开发人员快速入门，进行开发设计。
Ø开发人员只要懂得数据库知识，即可。
ØInformatica产品是以元数据为核心的，其开发过程中，所有的元数据，包括规则和过程，均是可复用，共享的。
Ø经过简单配置即可支持大数据量的处理。
ØInformatica是完全基于引擎级别的，所有功能模块化，扩展性强，维护成本低。
Ø虽然也是图形化的界面，但复杂的转换过程，里面嵌入了很多类Basic脚本的成份。
Ø要求开发人员，有编程语言基础。
Ø在处理大数据量，必须使用Datastage企业版。
但如果客户原先使用的Datastage标准版，其作业的版本移植问题很大。
这两个版本的工作平台、机制完全不同。
作业移植，大概要有70%左右需要重新开发定义。
ØDatastage是基于脚本级的，底层基于PICKBASIC和COBOL（MainFrame上）内核开发，要求不同的平台需要不同的系统环境变量配置。
应用需求的改变和拓展的支持
ØInformatica是以元数据为核心的平台，现在完全支持SOA的思想，其最大特点就是完全支持松耦合．可拆分成Service进行调用．这样需求变化，其需改动的部分，其影响会很小。
Ø开发转换过程，均为共享的、可复用的。
Ø元数据发生变化，可通过ViewDependencies功能，生成所有相关对象的报表，方便跟踪、校验，以应对需求的变化。
Ø应用需求变化，调整作业后，直接可以运行，不需要重新编译。
Ø作业移植等，也不需要重新编译。
与平台和数据库无关。
Ø支持跨操作系统的集群技术，可方便的进行平台级的扩展。
Ø需求发生变化，需调整相应的作业。
如果是复杂需求，改动已有的脚本，其维护成本相对比较高。
Ø每次作业变化调整，均需重新编译，才可执行。
ØDatastage企业版与Datastage标准版，其作业的版本移植问题很大。
这两个版本的工作平台、机制完全不同。
作业移植，大概要有70%左右需要重新开发定义。
一旦新的需求，需要企业版，其移植和再次开发，工作量要增加很多。
Ø也因为两个版本的不兼容和脚本编译的开发模式，使之产品面对变化和扩展上，均有一定的限制。
项目实施的支持
ØInformatica结合15多年的数据集成领域的经验，总结出一套针对Informatica产品实施数据仓库、数据管理等项目的最佳方法论Velocity2008。
该成熟的开发方法论，是指导客户实现快速、高质量项目实施的最佳武器。
Ø现在全国拥有众多的名高级技术专家与顾问，与国内如大唐，联创、神州数码、东软，中软等多家知名集成商成立战略合作伙伴，Informatica产品开发人员全国上千人规模。
ØInformatica支持服务中心是有非常熟练的技术支持工程师充当的，这些工程师具备你需要的、成功的专家知识。
在中国有专门的售后服务工程师。
Ø无专业/成熟，基于产品的项目最佳开发方法论
Ø很难找到熟悉类Basic开发语言的Datastage开发工程师
ØIBM是以服务为主的公司，如果客户采用了其DataStage产品，将要支付大笔的IBM咨询服务费。
产品安装
完全图形化安装，无需额外安装平台软件，且不需修改系统内核参数
Ø需耗用时间安装和准备C编译环境，不同平台软件安装的C编译器也不尽相同
Ø需修改系统内核参数，对其他应用影响较大，有潜在的危险。
产品升级
Ø平滑升级，完全图形化，不需修改已设计完作业。
Ø主要是升级资料库，工作量很小。
Ø需重新编译已有作业
Ø大版本之间以及跨平台的升级，很多作业需重新编写/编译代码，重复操作和维护工作量大。
产品移植
ØPowerCenter支持逻辑和物理设计分离的开发模式，有一个Mapping（逻辑的）和Session（物理的或者可运行）的概念，Mapping是逻辑上的ETL规则，而Session才是真正可以实例化运行的任务。
Ø可以跨平台、跨不同数据库进行作业的单个、整体移植。
不需改变作业设计等，原有的任务可以直接在新环境下运行，并且只要更改Session的数据库联接串，则使用原有的Session任务访问不同的数据库类型数据，大大简化项目移植的工作。
Ø如果数据源，目标类型变化了，得修改以前所有的Job。
Ø必须在新平台上编译所有作业，此移植的工作量较大。
元数据开放性
Ø元数据资料库可基于所有主流系统平台的关系型数据库（Oracle、DB2、SybaseASE，MicrosoftSQLServer）
Ø用户可通过Informatica提供的MetadataExchange视图读取元数据，Informatica提供详细文档描述其元数据视图的结构和含义。
Ø可通过CMW标准跟其它BI工具共享元数据。
Ø提供Global元数据库，Local资料库可共享Gloal资料库的元数据。
Ø元数据对象可以快速导出/导入为XML文件，快速在多个项目中共享元数据
Ø通过PowerCenter的AdministrationConsole，PowerCenter元数据库可快速的导出为Informatica能识别的二进制文件，该元数据内容可再快速移植到其他关系型数据库中。
ØDataStage的元数据DB是基于Universe7的，Universe不是一个开放型的数据库，（Universe目前最新版本是Universe10），IBM采用的元数据库技术上已明显落后。
虽然有计划要将之实现DB2的支持，但从本质上改动产品，不是短期内可以实现的。
Ø元数据库没有log备份恢复机制，如果知识库损坏后很难修复，易导致整个项目丢失。
Ø元数据库需要特定的Client才可以查看，所有DataStage在Universe中的元数据没有相关的描述，
Ø难与其它元数据库交互共享元数据，跨不同环境的元数据共享，必须重新编译该对象。
Ø无Global元数据库
元数据管理
ØMetadataManager可整合包括模型工具、数据集成、数据库、报表工具的各环节元数据的综合平台，支持各种主流UNIX平台和window平台。
Ø元数据管理可跨不同工具平台进行血缘分析，在表级和字段级均可自动匹配。
生成血缘分析和影响分析报告。
ØMetadataManager提供跨各种工具的元数据血统分析；提供自定义元数据接口。
ØMetadataManager支持OMG的CWM标准，其XConnects的接口非常广泛，扩展性高。
ØMetaStage是其元数据管理工具，仅能运行在NT平台上.
Ø可进行简单的元数据分析报告。
且元数据分析只在表级，不能进行字段级元数据分析。
Ø不能跨工具进行元数据跟踪，无法完成整体连贯的血缘分析和影响分析。
操作便捷性
Ø全图化开发，无编码，操作性强
Ø被TDWI连续10年评为“数据仓库最佳实践”奖
Ø脚本式工具，需要学习类Basic语言
Ø需要写大量的类Basic脚本，不便于快速开发以及后期维护。
Ø增加了开发周期和投资成本
健壮的安全性
Ø多范围的用户角色和操作权限（只读、操作和设计等）
Ø提供基于Folder的权限管理
Ø权限可以分到用户或组
Ø使用细致的锁（Lock）机制，提供了完善的安全，便于多用户的协作开发
Ø可基于LDAP认证模式
Ø只提供少量角色：
ProductManager，Developer和Operator
Ø只提供基于数据库的权限
Ø没有基于Folder的权限管理，开发者只要有Developer的权限即可访问所有的Folder。
Ø元数据的安全性和完整性没有很好的保障措施
并行处理
Ø可并行多个Session提高性能
ØSession支持多线程和管道技术（pipeline）
Ø支持Session分区功能，性能跟CPU数据可达到基于线性的增长。
Ø可将Session的分区任务分发到多个节点上（SessiononGrid功能），性能可随着节点的增加而增长。
ØInformatica支持跨不同操作系统的GRID。
Ø不能很好的多个Job的并行
Ø并行组件（Torrent）需另付费购买，在Window平台上，无法使用Torrent的并行技术。
ØIBMDataStage企业版中才提供TorrentOrchestrate并行功能，由于在ETL设计时需要考虑很多TorrentOrchestrate的技术因素，并且没有具体的技术文档，开发难度较大。
单个任务的并行能力
Ø提供多种Session分区（Partition）功能
⏹Round-Robin
⏹HashAuto-Keys
⏹HashUserKeys
⏹KeyRange
⏹Pass-Through
⏹DatabasePartitioning
Ø可将单个Session分配给Grid，PowerCenter会根据系统资源和用户配置，将单个Session任务拆分为多个子任务，以达到多并行任务的负载均衡。
并且随着Grid中的可用资源（Node）的增加，该Session的性能理论上会得到不断的提高。
Ø必须使用Datastage企业版才可以实现单个任务并行功能
Ø若想实现并行，必须要在源和目标数据库上各安装一套Datastage企业版，增加了企业的投资成本。
Ø而且标准版与企业版兼容性极差，作业需要重新开发。
运行灵活性
Ø可在mapping环节点上，执行Presql和postsql；可执行SQL语句块
Ø在session的点上，执行pre-sessioncmd、Post-sessionsuccesscmd、Post-sessionfailurecmd、OnsuccessE-mail、OnfailureE-mail等命令
Ø对于非连接lookup，可实现动态调用
ØMapping的源/目标可通过参数控制。
Ø无presql、postsql和sessioncmd的功能
ØLookup方法一：
使用ODBC来做一行行的搜索，速度很慢
ØLookup方法二：
使用自定义的hashfile来索引要Lookup的表，该文件存放在Universe数据库中。
ØLookup操作的hashfile需要维护和调优，其性能也不稳定，经常在没有提示的情况下崩溃。
读取文件列表（FileList）功能
Ø可灵活读取多个同结构/非同目录的多个文本文件。
Ø可快速读取大数据量的FileList
Ø无内置的读取文件列表（FileList）的功能，开发和维护量较大。
大数据量操作的性能
Ø有多种任务并行以及Session分区的技术
Ø有官方TPC-H性能测试报告，PowerCenter8.1在64位Linux平台上的性能达到了7.7MB/sec/CPU。
Ø大数据量处理性能稳定。
ØETL性能可跟硬件资源（CPU为主，内存为辅）达到近线性增长！
Ø无官方性能测试报告
Ø大数据量的汇总、排序、关联，Lookup效率差且不稳定，作业会莫名其妙的死掉。
跨广域网/防火墙的安全数据传输
ØPowerChannel可实现跨广域网和防火墙，实现加密/压缩的安全数据库传输。
Ø没有产品和方案实现该功能
对异常数据的处理
Ø提供Session级别的“RowErrorLogging”功能，可自动捕获异常数据，能将所有出错的记录写到关系型数据库表中，包括如下主要信息：
⏹出错记录的RowID
⏹出错时记录的当前值
⏹出错记录的原始值
⏹出错代码和信息
Ø无内置捕获错误记录的功能
Ø必须写大量的脚本，读取其log来得到错误记录信息。
任务的自动恢复（Recovery）
Ø自动WorkflowRecovery功能（需要HA选项）：
短暂的异常（如网络故障）会暂时停止Workflow的运行，故障被修复后，Informatica可从Workflow的断点处继续执行任务。
Ø自动SessionRecovery功能：
Informatica能保存Session失败前的断点信息，可从断点处继续运行任务。
Ø没有断点恢复的能力
Mapping
开发模板
ØInformatica提供了PowerCenterMappingArchitectforVisio功能，能在VISIO中开发Mapping模板，快速产生多个Mapping，大大提高多个类似任务的开发和维护。
在数据迁移，数据仓库的项目当中非常有用。
Ø提供了MappingWizards，内置了很多的Mapping开发模板，如数据仓库中经常用到的SlowlyChangingDimensions3种类型的模板，从而可提高开发效率。
Ø无缓慢变化维向导，需自行开发，开发效率低。
ETL任务调度
Ø提供WorkflowSchedule功能，可连续调度任务
Ø可基于时间/自定义事件/支持文件来触发任务
Ø可实现实时的数据抽取
Ø不支持连续运行（continuously）和频率执行调度，无法实现数据达到即时抽取的能力，频率执行需通过自编译内部代码或循环工作流人工逻辑实现，开发难度和维护难度较高。
这是DataStage设计开发中一个比较棘手的问题。
参考3：
1、Informatica属于商业软件，而Kettle是开源软件；Informatica的收费方式是软件一次性购买，但技术支持按项目收费。
具体怎么界定项目不清楚。
2、风险和成本方面自然就不用说了，从某些方面来说的话，风险总是与成本成反比的；
3、易用性方面，Informatica和Kettle都有GUI图形界面，操作步骤都比较简单易用；主要取决于开发人员的对工具的熟悉情况，没有太大的可比性；
4、Kettle是基于Java开发的ETL工具，在使用过程中需要借助JVM，在数据抽取速度以及大数据处理能力方面远远不如Informatica；（Kettle在异构数据库的处理能力比同构数据库的处理能力要弱很多，特别是夸服务器之间就更弱了）
5、Informatica将客户端和服务端进行分离，而Kettle则没有但需要基于JVM；因此Kettle的部署比较简易；
6、稳定性方面，Informatica也有较大的优势；
7、Informatica将元数据及一些配置信息存储于配置的数据库，也就是说Informatica需要借助其他数据库才能运行；
8、Kettle的数据转换过程相对比较灵活，可以是手工编写的SQL语句、Java代码、正则表达式等；Informatica则由DataQuality组件来保证数据的质量，当然也支持SQL语句，两者没有明显的差异；
9、Informatica和Kettle均有监控日志功能，这也是ETL工具必须具备的，Informatica的监控日志相对要详细一些，但在实际应用中，大多数情况下不需要这么详细；
10、数据源方面，二者没有明显区别，Kettle支持广泛
升级会员 