c*********e 发帖数: 16335 | 1 以前的data warehouse老师就说,他根本不屑于用ssis,ssas,ssrs,他自己是ibm的,用
db2自己写sql来做data warehouse. |
c*****d 发帖数: 6045 | 2 当然可以自己写了
现成软件肯定没有自己写的软件灵活 |
y****w 发帖数: 3747 | 3 吹牛,哪里有这么简单。 一般自己写也就是弄弄etl那部分,有谁吃饱了撑的去弄etl
调度引擎和reporting service?不想花钱有免费好用的。
【在 c*********e 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 以前的data warehouse老师就说,他根本不屑于用ssis,ssas,ssrs,他自己是ibm的,用 : db2自己写sql来做data warehouse.
|
y****w 发帖数: 3747 | 4 自己写的其实才不灵活。 人力有穷尽。
【在 c*****d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 当然可以自己写了 : 现成软件肯定没有自己写的软件灵活
|
p***c 发帖数: 5202 | 5 那天听一讲座,授课者说:some older engineers。。。。底下一片:ouch。。。就是
说的这种顽固不化的人
哈哈哈
你们老师是瞎吹,就楼上说的,他最多用用sql写
etl dataflow 那部分,我这个同意,很多时候sql很强,但是一旦碰到其他source,比
方xml,json,csv什么的,他用sql写?累死他
report data modeling 那部分
cube不用ssas或者类似ssas的东西比方ibm买的cognos,他用sql怎么写?写死他啊 |
c*********e 发帖数: 16335 | 6 "一旦碰到其他source,比方xml,json,csv什么的,他用sql写?累死他"
这个也是我想问他的地方,可惜当时没问。
【在 p***c 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 那天听一讲座,授课者说:some older engineers。。。。底下一片:ouch。。。就是 : 说的这种顽固不化的人 : 哈哈哈 : 你们老师是瞎吹,就楼上说的,他最多用用sql写 : etl dataflow 那部分,我这个同意,很多时候sql很强,但是一旦碰到其他source,比 : 方xml,json,csv什么的,他用sql写?累死他 : report data modeling 那部分 : cube不用ssas或者类似ssas的东西比方ibm买的cognos,他用sql怎么写?写死他啊
|
c*****d 发帖数: 6045 | 7 yhang,我不同意你的观点,我有现成的两个例子
1.我几年前参加的recommendation system for $1M netflix prize
(具体内容可以google)
数据包含500,000用户对17,000个电影的评价
共计100M对
这个数据量,数据特点,data mining算法
没有一个DM的商用软件可以很好的handle
2.LP做的医院病例notes,
虽然全部都是text,有类似的格式
但是每个医生都有自己的特定写法
只能自己写程序做ETL
当然,大部分时候能用现成软件当然没必要自己写
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 自己写的其实才不灵活。 人力有穷尽。
|
c*****d 发帖数: 6045 | 8 呵呵,如果是其他数据源
我的方法是先转成csv再说
【在 c*********e 的大作中提到】![](/moin_static193/solenoid/img/up.png) : "一旦碰到其他source,比方xml,json,csv什么的,他用sql写?累死他" : 这个也是我想问他的地方,可惜当时没问。
|
s**********o 发帖数: 14359 | 9 JOIN JOIN JOIN GROUP BY会慢死吧 |
c*********e 发帖数: 16335 | 10 en,join确实是非常慢的一个地方,这就是为什么要生成fact table.一次性生成以后,
就用fact table的数据。
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : JOIN JOIN JOIN GROUP BY会慢死吧
|
y****w 发帖数: 3747 | 11 你说得和我说的矛盾么?
你说的也还都在ETL部分,确切地说是E和T。 非标准数据源的抽取转换是一定需要定制
的。对大部分bi项目来说,类似你说的数据整理规范甚至是非标数据处理就是ETL的最
大工作内容/挑战。
DW不光ETL,虽然ETL一般要占去大部分工作量。但如果考虑到reporting,考虑到并行
工作引擎,这些东西要自己做能累死人,你项目失败的可能性不知道要大多少倍---可
是这个风险没啥意义.
【在 c*****d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : yhang,我不同意你的观点,我有现成的两个例子 : 1.我几年前参加的recommendation system for $1M netflix prize : (具体内容可以google) : 数据包含500,000用户对17,000个电影的评价 : 共计100M对 : 这个数据量,数据特点,data mining算法 : 没有一个DM的商用软件可以很好的handle : 2.LP做的医院病例notes, : 虽然全部都是text,有类似的格式 : 但是每个医生都有自己的特定写法
|
y****w 发帖数: 3747 | 12 说个情况在dw里不适用star schema join吧。我的意见和你是反的,在一个设计良好的
库里,良好实现的复杂sql效率比放到应用端要好不少。
【在 s**********o 的大作中提到】![](/moin_static193/solenoid/img/up.png) : JOIN JOIN JOIN GROUP BY会慢死吧
|
c*****d 发帖数: 6045 | 13 矛盾呀
例子1里面数据根本不用ETL,全部是database format
最后就是什么算法能提高精度
结果没有一种现有算法合适,att bell lab的人竟然用115种算法加权
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 你说得和我说的矛盾么? : 你说的也还都在ETL部分,确切地说是E和T。 非标准数据源的抽取转换是一定需要定制 : 的。对大部分bi项目来说,类似你说的数据整理规范甚至是非标数据处理就是ETL的最 : 大工作内容/挑战。 : DW不光ETL,虽然ETL一般要占去大部分工作量。但如果考虑到reporting,考虑到并行 : 工作引擎,这些东西要自己做能累死人,你项目失败的可能性不知道要大多少倍---可 : 是这个风险没啥意义.
|
y****w 发帖数: 3747 | 14 你这是data mining,挖掘,不是建设DW.
【在 c*****d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 矛盾呀 : 例子1里面数据根本不用ETL,全部是database format : 最后就是什么算法能提高精度 : 结果没有一种现有算法合适,att bell lab的人竟然用115种算法加权
|