主题:【原创】数据仓库软件的评测心得 -- 河蚌
很多客户建DW就是政绩工程,尤其是政府部门,或者烟草电力等垄断企业,电信稍好但是业务太简单,这里面情况最好就是银行。
上亿的投资进去了,DW建完能带来什么价值?DW发展也是有其内在规律的,开始时候出一些统计报表,再往后可以给一些下游数据集市加工数据,目前国内大多数DW的应用价值也就限于此,大部分客户对DW的认识也就限于此了。这种对DW的使用是被动式的。
但是DW价值的发挥是依赖于它的使用者的成熟程度的,国外很多银行比如巴克莱、美洲银行,他们的业务人员都能自主的利用SQL直接访问DW中的基础数据,实现自己的需求,如果按照传统模式,业务提需求,IT实现、测试、上线,这个周期太长了。我共事过一个苏格兰银行的搞业务的老外,SQL写的比大多数搞IT的人都好,他都是自己从底层数据汇总,不用加工好的。
让大量的数据静静的躺在DW里是一种巨大的浪费,然而业务人员的成熟也是需要培养的,毕竟DW这个东西在国内还算比较新的东西,尤其是对于非IT人士。一般而言,灵活查询培养的好的话这个时间在DW建成3到4年左右,业务人员对仓库的直接查询会有爆发性增长,说明业务人员开始认可这个东西了,ICBC和CEB都是例子。
Teradata是彻底的sharenothing架构,节点只负责计算,数据存储在外接磁盘阵列中。数据分布机制和BYNET节点间互联保证了其性能基本可以达到斜率为1的线性增长。在sharenothing和sharedisk两种视角下的数据库,是完全不一样的。
此外,列数据库代表就是SYbase IQ,但是IQ对于非预定义的随机查询支持的不好。
DW不等于应用。传统上Teradata并不是一个提供端到端解决方案的厂商,它只是专注于DW,只是提供一个平台,它的数据模型本身对应用是中立的,只是对数据进行了整合和存储。基于DW上的应用,相当一部分都不是TD做的。此外支持的应用再多,DW充其量也就是个数据加工的工具,没有业务人员主动来DW找自己需要的东西,DW永远都是死的。
在DW建设这块,科技比业务是要超前一点的。系统建起来,暂时没业务来访问,可以一遍积累数据一边慢慢培养业务人员。但是如果业务有很多应用的需求查询的需求,科技说没系统没数据,满足不了,那就杯具了。
用户对于DW的认识和态度,也是一个螺旋上升的情况。从厂商的灌输开始,由最初的期待,到质疑,再到重新认识并且接受DW,这才是一个符合规律的过程。
影响应用规划的因素非常多,很多客户都认识到DW重要性(当然意识到重要性不代表就能正确的使用DW),掌握了DW就掌握了未来很多话语权,这其中科技和业务部门之间,科技部门内部的争执非常多。比如科技主导建了DW,有的业务部门需求明明可以从DW走,但是非要自己另起炉灶;再比如找一个咨询公司做了应用规划,但是换了领导之后又推翻重来。所以应用没做好就说实施的人不行,是非常片面的。
NCR的“并不强大的”实施团队在国内已经是出类拔萃了,其他的提供数据仓库产品的厂家,基本不做实施。DW项目不是技术主导型的,实施非常复杂。上游往往有上百个源系统,其中的模型客户化、变更管理、版本管理、部门间协调、系统优化、测试问题管理等等,这里面的门道非常多。从业界声誉、经验和专业性角度,没有比这伙人更好的了,否则也不会被到处挖。
我们可以说技术是蛋,业务是鸡。但是首先,这个蛋不能是金蛋,因为大家卖不起,或者说在一颗蛋能不能变成鸡之前,这个蛋的价格不能太贵。其实从世纪初,DW的建设就一直在宣称,这是一个长时间的过程,这是一个烧钱的过程,这是一个需要领导魄力的过程。但是这样的宣传,我想对客户的吓阻作用也许更大一些,外国人怎么想我不知道,反正中国稍微正常点的人,都知道当有人说你要有”魄力“时,那么后面的结果一定是”破财“。
技术上的投入必须和应用上的产出挂钩,比如上海某银行做反洗钱系统,上了全套的数据仓库工具,价格是3000多万。然后那个做反洗钱公司的销售自嘲地说,我们真没有那么贵,这个项目,3000万是数据仓库的,我们的价格就是那个“多”。反洗钱尚且是有用处的,而所谓的报表,那就更是一言难尽。如果都是这样的性能价格比,你让银行如何做出决策来。
而你说的”上亿“的投资,先做出报表,那么,你实际上已经明确地把DW限制在四大行和某些具有央企性质的全国股份制银行。这样的银行在中国不超过10家。就这样的规模而言,DW就不能叫新兴市场了,而应该叫过度饱和了。
业务人员去查库,这个培养的时间倒是其次,而首先是组织体系的问题。就象你说的那个搞业务的老外,他的职责是什么,这个是国内首先需要明确的,因为诸如”业务分析员“这样的职位在中国是不存在的。而基于安全考虑,业务人员恰恰是不能查数据库的,对于他们来说,如果学会查数据库(并且能够让他们查的话),那么任何的数据都是可以卖钱的(别的不说,把银行的一百大户找出来,卖给其它银行就可以)。
所以,我觉得,做DW的,千万不能想当然,认为我先在这儿弄个金蛋,然后慢慢地就会变成金鸡来。就象”DW建成3到4年左右,业务人员对仓库的查询会有爆发性的增长“,这话,我在十年前就听过,不过就那些在五年甚至更长的时间前花了几千万甚至上亿建设数据仓库的银行来看,这个预言似乎忽悠的成分更多一些。
我倒觉得交行某位处长的评论也许更经典一些,”我知道你们这是个仓库,我也知道这里面有很多东西,但是,我觉得你们总应该把东西放到货架上吧“。这个意思是说,数据堆在那儿是没用的,你不能把每个人(特别是业务人员)变成库管员,你应该做许多面向管理领域的应用出来,通过界面把各种分析结果展现给用户。
很多客户都只是建了DW,但是对DW的使用还远称不上成熟。应用建设是很重要,立DW项目就是为了支撑一些应用。但应用建设也只是DW使用模式中的一种,业务人员对数据的直接分析才是建DW的初衷,刚出DW概念的时候哪有这么多花样繁多的应用。
业务分析人员这个角色在国内不但有,而且增长还很迅猛,”DW建成3到4年左右,业务人员对仓库的查询会有爆发性的增长“这个可不是预言,举的就是ICBC和ceb的例子。ICBC是07年开始建,ceb是06年,现在业务部门的查询需求多的都要加班做。
至于安全因素,即使做应用也会面临数据泄露的问题。签保密协议呗,出了问题公事公办,不能像防贼一样防业务人员,这些数据本来就是属于他们的,虽然这些数据是存储在DW里的。
交行不是一个好案例,项目做来做去人都做没了。
这个现象不单存在于ICBC和CEB,而是存在于所有的银行。所以,你可不能把这个作为DW建设所造成的后果。以我的经验来看,这个现象和数据仓库建设没有因果关系,倒是和银行运营支撑系统大规模的电子化有关系。可以这么说吧,几乎每一家银行的科技人员都在加班做这些零碎工作,所以俺现在和银行谈起为什么要上数据仓库,第一点就会说这个现象。
专职的业务数据分析人员,也许很久没到四大行看看了,不知道他们是不是有,但次一级的行,确实很少见。即使在建行和中行,那些上了Teredata的行里,应用都很差,中行更是做了五年也没有什么东西,更别说有专职的业务分析人员在上面鼓捣东西了。
其实,关键的问题是,不要只站在技术人员的角度去考虑问题,而要设身处地的去想。不能一句话,”DW应用不成熟“就把客户否定了,更不能说”我把数据放这儿了,分析工具也放这儿了,然后下面分析什么东西就是业务人员的事了“,这不是解决问题的办法。问题是,怎么才能让应用成熟起来,怎么样才能让业务人员去分析数据。这才是我们这些技术负责人的责任。
很多公司都招聘了国外回来的海龟。恕我直言,这批人,现在在国内的影响并不好,假大空的东西太多。干事情的态度,就是那个笑话里面说的,“不是我写错了悼词,是你们家死错了人”。一谈目标,就是一个天堂设计,一谈实践,就是欧美的经历,然后再以布道的精神来谈技术问题,不是设身处地的根据现有客户的情况去解决问题,而是让银行去按照国外的标准去做全面改造(这包括改造整个流程,还包括象国外那样去花钱买设备)。
你也说过很久没去四大行了,应该去了解一下现在的情况再下结论不迟。其实说是四大行,但每家都情况不一样。
ICBC是坚持应用建设和业务人员灵活查询两条腿一起走,应用支持的不如建行多,但是从今年开始灵活查询做的非常好,不但业务自己能通过客户端去DW找自己想要的数据,而且“真正摸索出来一条接着灵活查询,扭转BI类项目应用系统需求不明确的问题”,基于灵活查询的数据探索之后提出应用需求(不一定是数据集市建设),做出来效果都非常好,这也是用户自己说的。
CCB一贯的思路是DW就是为了下游应用集市加工数据,仓库没有对业务人员开放。现在给下游四十多个集市提供数据。CCB的应用基本上不是TD在做,三四家其他公司一起做的。你说CCB应用差,可以具体的说是哪块做的不行。
中行没有DW,只是在信用卡中心建了数据集市。由于是业务部门主导建立的数据集市,而且和苏格兰银行是合作伙伴,有很多老外也在这一起工作,所以业务人员的理念、对需求的把握都比较成熟。它的灵活查询是国内开展最早也是效果最好的,从04年开始培养大一批既有业务知识又有一定IT素养的业务分析人员,但流失的也不少。
ABC也没建DW,它有一个SybaseIQ的基础数据平台,而且还是总分架构的,数据不全。业务人员很多需求都非常难实现,科技的人只能手工从各个系统里凑结果。
TD从国内老板到下面干活的,都是纯土鳖,没招过什么海龟。从2000年到如今一直都在实施第一线,相反很多其他DW厂商倒是只卖产品不管实施。DW从来不是一个技术主导型的系统,只有产品服务跟不上肯定没有市场。
至于应用的建设,TD传统上也不是做应用规划的咨询公司,基本还只是关注在DW建设本身。你可以具体说说什么样应用算是做好了,光一个很差没啥说服力。
CCB的TD应用在厦开有,在北京也有,现在主要是在厦开了。去年在那里呆过两个月,不过似乎这个号称的DW组并没有太多的工作(当然人也不是太多),他们的工作基本上被ODS组基本上给抢去了。厦开做管理项目的很多,不过用TD并被称为DW组的好象就那一个。
当时厦开对DW组的评价就是,那是一帮依靠TD的一招鲜混饭吃的家伙。
如果把买了TD作为有无DW的话,那么中行肯定是有的。NCR一直在中行有个4、50人的项目组。只是他们做的活儿是以那个FNS的新系统为数据源来做的,但FNS系统一直没上线,所以他们做的东西就更连上线日期都确定不了。
ABC还有过直接接触,对ICBC那就真是不了解了,不过,当看到“真正摸索出来一条接着灵活查询,扭转BI类项目应用系统需求不明确的问题”这句话时,不由得就笑了。这又是一句从2002年以来就在不断重复的老生常谈。
关于查询的事情,我想你还是站在技术角度去考虑问题了。你怎么知道银行的查询需求和你说的查询是两回事儿。实际上作为一个业务人员,提出的需求就是业务数据查询(包括指标查询),至于是不是灵活查询,这是技术人员的视角。而实际上,最近几年交流中,被问起最多的就是,你们有没有这个灵活查询(或者灵活报表)的工具,甚至很多二线城商行也都会问起这个事来。而他们问这个,其实就是因为让业务人员那些繁杂的查询和报表要求给弄烦了。
至于海龟嘛,这个倒不一定是指NCR(业界对它的评价,这是一家披着外国皮的国内公司)。而是指游荡在各个金融IT公司里面以咨询为谋生手段的大神们,很多挂着某某研究院博士,某某银行十余年金融分析经验的神人们。
去年,曾经和TD合作去银行做交流,整体的感觉是TD员工的自我感觉真是很好,不过,也就是那次之后,我们决定放弃与TD继续合作,而想找一个替代产品。技术人员有一种优越感很正常(只有偏执狂才能生存嘛)。但是,不去听业务人员的述求,而总是陶醉在自己的技术世界里就没有意思了。
还是那句话,如果站在技术的角度去考虑问题,那就会永远在灵活查询怎么和应用需求对接这个问题上打转转。但是,如果从业务入手,将银行的管理领域按业务条线来划分,分出诸如历史数据管理、内部报表、绩效考核、CRM、风险管理、资产负债管理、财务预算、经济资本计量等领域,再在这些业务领域里总结需求,形成应用系统,那么你自然会发现,这里面有多少个业务功能是多么迫切地需要灵活查询这一技术平台来实现了。
CCB的ODS其实就是一个数据交换的平台,里面没database什么事,都是文件操作,也没法基于这个ODS做应用,它只管数据分发,它和DW是上下游关系,构不成竞争。
中行买TD但是卡中心买的,总行肯定没买。怎么可能会有4,50人团队在中行,TD北京做金融行业加一起也就是50人。
至于ICBC,02年的时候哪有什么BI的概念,认知不能总停留在02年吧。那话不是厂商的宣传语也不是客户领导讲的客套话,是DW支持团队说的。业务人员对DW态度的变化他们是最有发言权的。
我并没有排斥做应用系统,应用和灵活查询都是DW体现价值的重要方面。
刚才了解一下BOC的情况,还真如你所言,而且已经上线了。
如果俺对NCR和TD有什么不太恭敬的言论,还请谅解,咱的几位前同事都在那里,熟悉了自然就会拿它来举例。论起来,TD仍然是综合性能最好的数据仓库,最近的数据测试,俺就是以TD为标杆的。
现在国内的数据仓库的产品领域,主要还是TD、GP以及IBM的DB2在争。不过IBM收购Netezza后,这款产品应该很快会被集成进IBM的BI产品线里面。
这两天在测试国内的一款分析数据库软件GBASE,就性能和功能而言,还是不错的,只是不知道稳定性如何。
和IBM有合作,IBM居然又在推主机数据仓库,而且还是高端的主打产品。前2年风风火火的neoview,HP也基本放弃了。不是剑走偏锋就是急功近利,哪像大厂商的作风。
对外宣称的数据仓库产品DB2 DWE,实际上就是在DB2数据库基础上加了十几个软件组成的产品系列。弄得俺说IBM没有数据仓库存储软件,只有DB2,还得和人解释老半天。
而且就是这套数据仓库产品,如果和十年前比,也是关键部件不断给替成收购来的产品了。
让大量的数据静静的躺在DW里是一种巨大的浪费,然而业务人员的成熟也是需要培养的,毕竟DW这个东西在国内还算比较新的东西,尤其是对于非IT人士。一般而言,灵活查询培养的好的话这个时间在DW建成3到4年左右,业务人员对仓库的直接查询会有爆发性增长,说明业务人员开始认可这个东西了,ICBC和 CEB都是例子。
国内在ETL方面很少采用现成的工具,比如informatic,datastage,大多数都是直接写SQL脚本或用存储过程。原因主要有两个:
1.目前的ETL其实是ELT为主,先loading进来再转换,最大限度利用数据库的资源。而不是在一个独立的ETL服务器上做好转换再加载到仓库里,这样效率低而且对ETL服务器性能要求太高
2.仓库并不产生数据,只是进行一个数据组织方式上的转换,从业务源模型到仓库模型。因为源系统比较多,转换逻辑可能会比较复杂,所以很难用datastage这样的图形化工具准确的表达出来,不如直接写SQL方便,开发效率高。这种图形化的ETL工具拖拖拽拽的做演示还行,但是不适合大规模的工程化开发。比如100多张源表加载到一个数据仓库中的表,用ETL工具挨个拖拽到话,屏幕已经乱的没法看了。
报表目前是cognos占大多数,少部分用brio或其他工具的