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 的大作中提到】
: 以前的data warehouse老师就说，他根本不屑于用ssis,ssas,ssrs,他自己是ibm的，用
: db2自己写sql来做data warehouse.
|
y****w
发帖数: 3747 | 4 自己写的其实才不灵活。 人力有穷尽。
【在 c*****d 的大作中提到】
: 当然可以自己写了
: 现成软件肯定没有自己写的软件灵活
|
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 的大作中提到】
: 那天听一讲座，授课者说：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 的大作中提到】
: 自己写的其实才不灵活。 人力有穷尽。
|
c*****d
发帖数: 6045 | 8 呵呵，如果是其他数据源
我的方法是先转成csv再说
【在 c*********e 的大作中提到】
: "一旦碰到其他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 的大作中提到】
: JOIN JOIN JOIN GROUP BY会慢死吧
|
y****w
发帖数: 3747 | 11 你说得和我说的矛盾么？
你说的也还都在ETL部分，确切地说是E和T。 非标准数据源的抽取转换是一定需要定制
的。对大部分bi项目来说，类似你说的数据整理规范甚至是非标数据处理就是ETL的最
大工作内容/挑战。
DW不光ETL，虽然ETL一般要占去大部分工作量。但如果考虑到reporting，考虑到并行
工作引擎，这些东西要自己做能累死人，你项目失败的可能性不知道要大多少倍---可
是这个风险没啥意义.
【在 c*****d 的大作中提到】
: 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 的大作中提到】
: JOIN JOIN JOIN GROUP BY会慢死吧
|
c*****d
发帖数: 6045 | 13 矛盾呀
例子1里面数据根本不用ETL，全部是database format
最后就是什么算法能提高精度
结果没有一种现有算法合适，att bell lab的人竟然用115种算法加权
【在 y****w 的大作中提到】
: 你说得和我说的矛盾么？
: 你说的也还都在ETL部分，确切地说是E和T。 非标准数据源的抽取转换是一定需要定制
: 的。对大部分bi项目来说，类似你说的数据整理规范甚至是非标数据处理就是ETL的最
: 大工作内容/挑战。
: DW不光ETL，虽然ETL一般要占去大部分工作量。但如果考虑到reporting，考虑到并行
: 工作引擎，这些东西要自己做能累死人，你项目失败的可能性不知道要大多少倍---可
: 是这个风险没啥意义.
|
y****w
发帖数: 3747 | 14 你这是data mining,挖掘，不是建设DW.
【在 c*****d 的大作中提到】
: 矛盾呀
: 例子1里面数据根本不用ETL，全部是database format
: 最后就是什么算法能提高精度
: 结果没有一种现有算法合适，att bell lab的人竟然用115种算法加权
|
