轉自：http://www.itpub.net/viewthread.php?tid=355437&extra=&page=1
shwenwen 发表于 2005-4-28 17:27
如果我们不透过表面这些工具的简单使用去看它背后蕴涵的思想，最终我们作出来的东西也就是一个个独立的job，将他们整合起来仍然有巨大的工作量。大家都知道“理论与实践相结合”，如果在一个领域有所超越，必须要在理论水平上达到一定的高度
ruihuapeng 发表于 2005-4-28 23:01
的确需要在艰苦、冥思、快乐的煎熬之余，思考、总结一下关于ETL的东东。
ETL看似朴实无华，默默无闻（往往后台运行），但却是实实在在、来不得半点马虎、虚伪。
它起点可以很低，但同时也可高得让人无法控制、难以逾越！
从简单复制到增量抽取，从转换规则到元数据维护，在每一点上究其根源及细节，都可以上升到极深得理论。
为什么看似如此简单的东西，却可以演化得如此复杂？
原因其实很简单：因为我们都想达到更多的自动、智能，而更少人的手工。
innovate511 发表于 2005-4-29 13:52
数据仓库是很繁复的项目，现在大公司做这种项目都是使用ETL工具的，目的就是为了减少细节过程，让更多时间放在业务研究和数据挖掘上。
个人意见，仅供参考，呵呵。
ami 发表于 2005-4-30 15:54
经典！
我也来谈一下对于ETL工具的使用：
曾经短暂的用过ETL工具，速度慢的难于接受，也许是我还没有掌握方法，但始终不敢相信拖拉出来的东西，在性能上可以跟自己多方优化过的代码，以及SQL LOADER等数据库提供的专门工具相提并论。
我们在ETL这一块的做法是：把ETL任务细分成很多小任务，对每个小任务可以选择SQL LOADER，或是C程序，或是存储过程来实现，然后自己编写了带监控界面的工作流程序进行控制；每个月150多G的数据，完成比较复杂的ETL流程，花费2天时间。
也请大家来交流一下，谢谢！
ligengocp 发表于 2005-5-7 22:30
我和ami的意见比较相近~~
有些复杂的ETL，用工具实现起来很麻烦。让人感觉是思路被ETL工具牵着走
innovate511 发表于 2005-5-8 11:59
有的时候不是你能决定的了的，比如大公司做项目时，你公司已经决定用工具去做ETL了，你总不会非要自己编写方案和程序吧，除非你不想干了。
happysboy 发表于 2005-5-10 13:21
使用一种工具，开始总会觉得束手束脚，受制于它，过于依赖。但也有好处，就是有工具帮你做事，不必从零开始，把自己的精力花在适当的事情上。
有些朋友刚开始有些瞧不起这些工具，认为就那点玩意儿，自己一个月就能搞定（我也曾经这样想的）。但别忘了，这些工具都是花费大价钱、一堆人，作出来，并且经过多年的实践使用、改良过来的，你就那么自信比他做的好？
可能大家会说，自己设计可以更加贴近实际的需要，而省去研究工具的工夫，况且它还未必可以实现，那只是逃避“学习曲线”的做法。一种工具的诞生，必然有需求推动，它必然或多或少能够满足这些需求，需求的升级也在导致工具的升级，这些工作都是工具开发商们在致力解决的事情。国内的应用水平客观来说比国外低一些，需求通常也是不会有中国特色的，然而通常人们又会自然而然认为自己遇到的情况是和别人不同的，需要特殊的手段去对付。这种想法恐怕得改改了。
因此如果大家要标新立异，要发挥创造性，要赚取利润，就不要去做哪些别人已经做过的，并且做到一定规模的事情了，说的时髦一些，岂不就是寻找企业或是个人的“核心竞争力”。
是使用工具还是不用工具，这个选择存在太多地方，眼前就有，只不过不是ETL工具而已。遇到这样的问题，其实已经不再是个人喜好问题，而是公司的战略考虑，是依赖工具生存，有些冒险。而自己从底层构建，无非是花费一些人力而已，但其实这些人力肯定是白费，因为我们以后肯定是不会去买工具的，况且这个东西怎么样，是否能够满足以后需求的演进，都是疑问。唯一的好处就是，现在看来成本不高，没什么风险，其实只是将大风险转嫁到以后去而已。
gemini2000 发表于 2005-6-28 22:18
趁着还有精力胡乱说两句
ETL的工作本质是简单的，但只是由于环境复杂，导致了工作的复杂性。
大多数时候大家的争论的ETL，ELT，ETL的定义等等，实际上已经将注意力转到其他方面，对ETL的本质反而复杂化了，其实很简单，就是数据的迁移。 至于你用工具并不重要，你迁移的步骤野不重要，只要达到效果就行。
所以你用shell C编程 ，还是Datastage Informatica ，还是使用SQL都可以，没有好坏，重要的能满足要求，再这里尤其重要的是，能满足你的要求。再好的工具，如果你对其掌握的程度不够，对实际的需求不方面实现，工具的意义也是不大。
所以好的ETL工程师应该在项目实施前，对其将要使用的工具进行评估，将需求评估，规矩本身的实际情况，来适当的调整ETL的策略，从而达到ETL工作的优化。
（好像上面是废话啊）
其实重要的不在这里，有两个方面加重了ETL工作的复杂化
数据本身的信息
数据转换逻辑规则的信息
数据本身的信息 又包括
数据本身反应的业务信息
数据＆数据之间的规则信息
业务信息（指源数据＆目标数据）应如何体现，一般应通过某种工具来体现，如Erwin Powerdesiner 或者你用Excel也可以.一般情况下，往往容易忽略的，也容易受到限制就是源数据的业务信息。试问如果源数据的业务逻辑信息都不能清楚的表达，ETL做的再好，也是意义不大的。
所以，好的ETL工程师应该对源数据＆目标数据的业务信息，业务逻辑，数据属性也有相应的了解，ETl框架设计师更是应该对此有深刻的认知，才可以确保优质的ETL任务。缺乏对源数据的认识，没有清晰的框架结构，必然会给随后的ETL工作加大难度＆复杂性
（说句大白话，如果对数据仓库的数据要求一张报表，能否对源数据的接口数据也同样出一张报表，看看两者之间有he差异，就可以看出ETL的工作质量了)
先到这里吧，敲字很麻烦的。待续
innovate511 发表于 2005-9-25 23:34
但是有没考虑清楚整体架构呢，老实说，国内ETL设计，有几个项目是考虑到客户的需求变化和未来项目的扩展需求呢？我觉得我接触到的国内项目都没有怎么考虑，只是满足当前的客户需求，拿到客户的初验好交差，没太多的经验和技术沉淀。
happysboy 发表于 2005-9-26 17:48
这些量的积累是在平时形成的，并非一个项目之后，大家开个总结会，回忆回忆出现了那些问题，再在架构中考虑解决这些问题的办法（这还算好的）。这些问题是要在项目过程中不断暴露出来，并且做好这些问题的管理、跟踪，对问题进行归类、统计，同样的错误尽量不要发生，这才是理性的做法。如果一味赶进度而不去考虑设计，唯一的结果就是不断地重复劳动，枯燥的人工检查、麻木地执行ETL程序。
但是ETL的主要问题并不是出在语言级别上，而是在方法上，在性能和易维护的平衡上。我记得你的另一篇帖子上也提到ETL工作是经常容易改动的，难以维护的（大意如此吧），我非常认同这一点。目前BI项目的ETL工作，很多都是人工操作，肉眼检查，虽然很多项目中使用了专门的ETL工具，有时却宁愿相信自己的处理，编写c、perl或是存储过程的程序，有时是一种捷径，却难以保证他们的质量，更加难以维护扩展。
dwg 发表于 2005-10-19 17:46
innovate511 发表于 2005-10-27 15:15
经过ETL设计成多维后的数据魔快(CUBES)容易进行分析，分析速度十倍，百倍的增加。
innovate511 发表于 2006-1-8 12:20
最初由 stillthere2 发布
经过ETL设计成多维后的数据魔快(CUBES)容易进行分析，分析速度十倍，百倍的增加。
这是OLAP，10多年前就出现的技术，现在已经比较成熟了。数据仓库是个系统及软件工程，每一步都很重要。无论是否使用工具，但是核心的东西始终不变，从Architecture, data mode，meta. datal到ETL，再到各种前端应用（Adhoc,report,OLAP,DM）；从项目管理，再到开发、测试流程，以及和客户、生产系统厂商的交流，每一步都关系到项目的质量。
从项目设计这块讲，根据客户具体要求和实际情况，又可以分为Inmon式设计和Kimball式设计。就目前国内客户多数急于上项目以及厂商人手有限的实际情况，比较适合Kimball式设计，及根据客户需求设计数据集市，然后围绕数据集市设计对应的数据仓库。这种设计的特点是设计快，见效快。
但是没有足够设计经验的设计师往往会造成数据仓库和数据集市脱节，甚至觉得没有必要有数据仓库，思路混乱，扩展性差，数据质量难以得到保证，这正式很多项目的写照。要知道ODS完成数据整合、清洗等过程，DW完成ETL，DM面向前端应用，俗话说麻雀虽小，五脏俱全，每一步逻辑层都有自己的作用。有的项目还有个特点，就是喜欢直来直去，然而随着数据量以及业务的复杂程度的增加，往往需要过渡层staging area去分担和细化工作，增加效率，而不是我把逻辑层都设计好了后，就可以把源表直接ETL到目标表了。
而有的项目是请国外公司先设计好中心数据仓库（Inmon式），然后在国内招一批初学者去维护和开发数据集市以及前端。这样的好处就在于，数据仓库系统以及设计好了，剩下的数据集市以及前端对工程师要求不高。但是缺点也是明显的，首先不利于自己培养人才，而且一旦公司有新需求或者需求变化以及数据仓库优化需求，公司自己员工没有实力去修改中心数据仓库，显得很被动。
所以这篇文章说的很有道理，不要迷失在工具中，抓住本质的东西，首先保证项目质量，才能谈发展和创新。
stillthere2 发表于 2006-1-8 23:16
最初由 innovate511 发布
从项目设计这块讲，根据客户具体要求和实际情况，又可以分为Inmon式设计和Kimball式设计。
所以这篇文章说的很有道理，不要迷失在工具中，抓住本质的东西，首先保证项目质量，才能谈发展和创新。
谢谢 innovate511君!
SQL SERVER 2005 引进UDM (The Unified Dimensional Model )。
请问 innovate511君, UDM 是否是Inmon式设计和Kimball式设计概念的结合？
innovate511 发表于 2006-1-8 23:58
我看了下介绍，感觉它更像MS自己提供的开发和管理工具，而不是项目设计，具体逻辑上的数据仓库和集市，还得做项目的人自己设计。
请问 innovate511君是否接触过缓慢变化维(The Slowly Changing Dimension transformation)？
很明显， MS 在cath up, 但愿它的普及商务智能(BI FOR MASSES)成功！
see all the book titles from his website at
http://www.kimballuniversity.com/html/books.html
SSIS 2005 now deals with it, Cognos DecisionStream and its PowerPlay Transformer also deals with it.
The Slowly Changing Dimension transformation is an important concept many businesses run into and the tools have to deal with it.
But in my 6 years of DW/BI technical supporting work, I only run into it once or twice, so no wonder you did not see it before.
Anyhow, thank you very much, innovate511, for all your feedback. It was a great pleasure to read all your entries at itpub.net... I'd like to present you some roses;-)
26 or more years ago there was a song titled Dalian Hao that was composed by Wang Liping (大连好 by 王立平). I wonder if nowadays people are still singing it?
I think you began to support DW/BI in 2000, right?
举例：COGNOS的 DecisionStream, Impromptu Catalog 和COGNOS BI ARCHITECT以及ReportNet FRAMEWORK MANAGER就是用来管理元数据的。
纲举目张：运用元数据建立了后端DW的数据模型，前端的BI应用(报表，建立数据魔方，数据挖掘)就几乎是水到渠成。
在国外一些经典书籍里边，实施项目的顺序，他们已经离好了，但是我们到现在才开始慢慢走这条路。
但是目前我们常常会碰到如下几个比较大的问题：
（1）自己设计、开发的情况下，设计者经验不足，往往设计的架构扩展性差，模型需要经常改动等弱点；
（2）花钱请国外大公司设计DW的情况下，自己设计的DM和DW有点青黄不接；
（3）开发、测试流程不规范，比较随便；
（4）文档和代码管理还不够好，开发和测试文档应该统一管理，最新的文档应该立即刷新，其他人审阅代码或者继承这个模块开发的人能找到最新的开发文档和代码。
whzhouyong 发表于 2007-2-7 10:43
将源数据导入成标准数据格式，加载到目标库
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8203880/viewspace-324626/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/8203880/viewspace-324626/
扫一扫
2904
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
