我正在做一套ETL的工具，针对Teradata数据库。

[objectman]

能自动生成Perl脚本，负责源数据文件处理、分析、Load等。
Mapping工作流程的管理，自动生成Mapping脚本，比如说表的打横和打竖。
呵呵，做完了之后我再做数据仓库就轻松多了。
用MFC.net做。

[chump]

好，支持！

[justin0470]

支持，能否谈思路？

[hellaslubo]

对啊，楼主透露一下思路嘛。

[objectman]

这两天没来。忙啊。
思路其实不复杂。
Teradata做数据仓库ETL的时候没有类似DataStage这样的工具，所有需要大量的人工制作编写数据加载、清洗、mapping等工作的脚本。其实这些工作很多都是低级重复的，完全可以通过自动工具完成。
我在数据仓库实施的过程中不断总积累经验，保存创意，也做出了很多非常好用的小工具。
总得来说我这个工具做分为三个组成部分，一个是数据文件分析器，用来分析需要加载数据文件，比如判断记录长度，截取记录，搜索记录，EBCDIC转码，合并拆分，自动生成Fastload脚本等等（原来写过一个，再完善一下即可）。第二个是数据文件管理器，主要负责对需要加载的文件的下载、保存、备份、预处理、移动、重命名等操作，支持插件（这个也写过，再完善中）。第三个就是比较复杂的数据mapping管理，针对ERWin生成的模型，在源表和目标表之间建立起对应的关系，捎带流程管理、统计等，这个是最需要的，也是功能最复杂。
反正总体思路就是这样，大家有什么好的想法建议也提一提。

[tacf]

这些工具，其实Teradata已经早就有了，只是你们不知道。

[objectman]

ｔｏ　 tacf(tacf) ：
是么，那你给我说说都叫什么名字啊？我去搞来用用。

[tacf]

objectman(码熊) ;
如果你是teradata的，我想你应该很容易得到这些东西，同事，网上都可以拿到。
如果你不是teradata的，我不知道这些东西能不能告诉你，真的，抱歉。

不过我看得出来，你以前使用过Teradata的ETL Automation这个工具。你也可以按照自己的方式写一些东西，说不定有好的收获也可以share你的想法，让大家受益。

[objectman]

to tacf(tacf) ：
好，我先去查查吧．
不过既然有这么多工具，为什么每个项目组都各自为战的吭哧吭哧写脚本，或者做工具．
光ＦＴＰ文件管理的程序我就做两个了．
是同事，但是对此有些疑惑．

[tacf]

objectman(码熊):
这我就不知道了，其实ETL本来就是非常繁琐的工作，也没有一个固定的标准，有的只是一些方法论，在实际的工作中需要根据不能的项目进行本地化。所以才造成目前的情况。
不过我觉得奇怪，为什么会象你说的这样呢？

算了，有些问题还是发mail给我，如果可以，和你仔细讨论一下。

[lvcheng606717]

有兴趣,希望进一步探讨
msn:[e-mail]

[tacf]

to freddy2003() :
那玩意儿，对sql server还可以，别的数据库不好。

[freddy2003]

SQL Server自带的DTS工具不是很好吗！！

[tacf]

to lvcheng606717(旅程) :
其实不是说通过的ETL工具不好，每个工具都有他自己的一些特征和优势。只是每个厂家或者客户在选择的时候，主要看工具能否满足自己需要。其实整个ETL过程不是选择一个工具那么简单，每个人选择的时候，主要考虑的是自己的ETL的方法论是否能在工具中得以体现或者通过它来实现。
不同的厂家或者是SI，他们都有自己的做事方法，ETL工具在整个过程中扮演的角色也不同，所以会使得不同的人看不同的面，我们也是。编码是必然，但是能够把手工编码降低到最小，是大家努力追求的。这就是为什么我们很多ETL工具需要本地化的原因。你也正是说了，工具不是万能的。

[lvcheng606717]

to tacf(tacf) ：
没有什么工具是万能的，teradata公司确实会为一些大客户开发专用ETL工具，但一般来说通用的ETL工具还是占主导（我们用的是informatica），对一些复杂的处理程序，编写代码是必然的。

[pgh]

有没有具体的实施案例？