主题：【原创】数据仓库软件的评测心得 -- 河蚌
- 复 【原创】
家园 UPDATE不一是这样的 对于堆表类型（比如pgsql）来说，MVCC实现UPDATE是先插入一条新记录然后改写版本指针指向新记录。即新老记录都物理存在，由版本指针决定哪条是最新记录。对于老记录可通过命令清理（比如pgsql的vacuum）。
对于索引表类型（比如mysql，ora不知道是否也是）也差不多。
- 复 【原创】
家园 数据量上的考虑是和省级银行的数据规模相一致的。 银行应用不单是海量数据的问题，对于银行而言，单独一两个分析功能是没有意义的，要的是一个完整的应用系统，比如客户经理营销管理、绩效考核、风险管理。这都是分析与操作混和在一起的。其实，我们要求的模式，就是海量数据分析上的优秀表现，以及对于传统数据库操作的功能支持（也就是说，性能可以低点，但是不能不支持）。
金融业是个很特殊的行业，就是这个行业不存在实物流，它玩的钱现在就是数字（要不然怎么叫虚拟经济）。因此，金融业的业务复杂度要比其它行业高的多，这个行业的特色就是无中生有，靠想象力造出各种各样的金融产品来。而有实物流的行业，脱不出进销存这个框架。
如果一个数据仓库软件只是针对海量数据，而不能支持简单的SQL操作，比如UPDATE，那么一种解决方案就是架两个数据库，数据仓库软件用于海量数据分析，复杂的应用用传统数据库（比如Oracle、DB2），这里面涉及到重复投资的问题，也涉及到两种数据库间的数据交互的问题。另外一种，就是基于数据仓库软件，然后将其中不支持的SQL操作全都用变通的方法来解决。比如UPDATE不能用，就改成DELETE/INSERT,MERGE不能用就改成update/insert。
但金融业的BI系统，涉及海量数据分析只是其中一块，最主要的反而是各种分析模型的建立，以及参数之类的维护，这些都属于传统数据库的范畴，用到UPDATE的地方多了去了。一套成型的系统，如果为UPDATE去改，那就是把系统整个翻一遍。
GreenPlum的实测真是一言难尽，在所有数据仓库相关的性能测试上，它都是很优秀的。比如导入、导出、批量insert都是十分快。它的问题是功能上面的局限，主要包括：
1）完全不支持NOT EXISTS，NOT IN的where子句操作
2）不支持非分区键字的IN和EXISTS
3）不支持对于分区键字进行更改的UPDATE操作。
这些局限都和share nothing(就是分布式、完全无共享）的架构有关。其实teredata也是分布式架构，只是上述的功能短腿，在这十年的实际应用中，都已经在技术上解决了。
总体来说，这个数据库比较适合象google那样的检索服务（即输入固定键字进行检索，几十亿条数据应该不是问题），而不适合企业组织架构内的应用检索（比如找某一机构的所有下属机构的账户）。
而UPDATE的问题，则更可以说是Greenplum出来时间太短，没有太多应用造成的，因为无论是teredata,还是传统数据库的分区表，都是允许这种操作的，只是效率上会很慢。而且，一个完整的应用系统里面，海量数据表的个数也就那么几个，大量的还是汇总表以及参数表。对这些表做update，应该是很正常的功能。
家园 NOT IN不支持那支持EXCEPT/MINUS么？ 就效率上说NOT IN不走索引是非常差的，尽量避免使用。而EXCEPT/MINUS可走索引，性能很高。
另外pgsql 9.1支持UNLOGGED表即非日志表，速度接近内存表。非常不错。
家园 为啥不能以teredata为参照系？ 现在美国有很多大银行在用teredata，和netezza.
netezza的设计思路比teredata还要激进，是 data warehouse only, 我和netezza的developer聊过，在netezza里面没有cursor,用户甚至不能创建 index.
他有自己独特的硬件优化技术。软件再怎么优化也不如专用硬件快，IMB虽然有DB2,今年还是把Netezza 收购了，这是一个DW未来的方向
oracle 推出 Exadata 也是受了这种思路的影响
“Netezza was part of the inspiration for Exadata. Teradata was part of the inspiration for Exadata,”
“We’d like to thank them for forcing our hand and forcing us to go into the hardware business.”
--acknowledged Larry Ellison on 27th January 2010.
家园 Exadata可惜还在遮遮掩掩 还不承认自己在往share-nothting的架构上靠，其实它底层的storage server已经是按照SN思路来进行数据切分了，但上层的database server还是share disk的老路。
Exadata一个很大缺陷是存储用多个PC替代磁盘阵列，用软RAID,速度和散热都是问题。
家园 这个是他的关键技术 在存储平民化上有战略性的意义 用工业标准的刀片服务器 把昂贵的企业级存储阵列拉下了马，性能更好，价格更低，走的是PC集群替代高性能UNIX服务器的一样的路。
只要市场认可，技术上可以逐步完善。
家园 是说在价格上不以teredata为参照系。 因为太贵了，差不多要2千万以上，这个价格对于省级规模的银行，基本上不可接受。俺曾经和客户说teredata和Oracle的PK案例，5亿条数据的汇总，teredata几分钟出来了，oracle运行8个小时最后强制中断了。但是任你口吐莲花，客户依然不接收，首要原因就是大家的共识，那是国有大行们用来烧钱的玩意，不是我们这种行用的。而且，更大的问题是，teredata到现在为止在中国也没有什么拿得出手的应用来（或者说是从来没有给银行带来与它的价格相应的价值），这个当然和NCR那帮做实施的人有很大的关系，但是也无疑让大多数客户对他没什么好印象。
Teredata只是到今年，才将价格降到600万左右，但是对于银行客户来说，仍然是太贵了。teredata最需要做的是，给客户一个成功的并且成熟的案例应用来，而现在teredata拿得出手似乎很少，很多项目看上去很大，最后明确一下，实际上也就是100张报表而已。而且将来也难，因为NCR本来就不强大的实施团队去年还发生了分裂，有很多人去了另一家公司。
说买数据仓库软件不要以teredata为参照系，就是说不要认为300万的价格就是超低价了，其实现在市面上的大多数所谓数据仓库软件，就是一招鲜，真正用起来就是短腿，论起来功能的全面，比之Oracle、db2差出去很远，而db2、oracle之类的也就是200万左右。
而在技术层面，我做测试时，反而是是以teredata为参照系的，你不是说这个功能是数据仓库不应该有的嘛，那我就去看一下teredata有没有，人家有，你这个也应该有。性能上要与teredata相似，功能上得向teredata看齐，价格嘛，你自己看着办，反正钱在客户那儿。你说客户笨也好，落后也好，最后不还得让人家出钱不是。
其实没有cursor并不是最重要的，理论上cursor所能实现的，都可以由多条SQL组合来实现，综合效率的考虑，其实还是能接受的。
但是如果数据仓库软件不支持update,这个就是致命的，你要知道，一个应用系统，包括很多参数表的，无论是做CRM还是绩效考核或者风险管理，你能想象一个系统中没有维表维护吗？所有的参数表都不能更改主键的值，这样的平台能够支撑得了复杂的应用吗？
当然，也可以说数据仓库平台由数据仓库软件支撑，之上再以传统数据库建立管理应用。其实这是所谓的理想模式，问题是，客户不答应，人家会说，你这玩意原来就只能做这么点东西。赶情复杂的东西还得用我们以前的数据库，那我买你这东西干什么，我用传统数据库做分区表，不也能支持到1亿条数据吗？
说一千，道一万，自己说好，那没用，甚至客户说好也没用，能让客户掏钱购买才是王道。
家园 你的说法有失偏颇 DW不等于应用。传统上Teradata并不是一个提供端到端解决方案的厂商，它只是专注于DW，只是提供一个平台，它的数据模型本身对应用是中立的，只是对数据进行了整合和存储。基于DW上的应用，相当一部分都不是TD做的。此外支持的应用再多，DW充其量也就是个数据加工的工具，没有业务人员主动来DW找自己需要的东西，DW永远都是死的。
在DW建设这块，科技比业务是要超前一点的。系统建起来，暂时没业务来访问，可以一遍积累数据一边慢慢培养业务人员。但是如果业务有很多应用的需求查询的需求，科技说没系统没数据，满足不了，那就杯具了。
用户对于DW的认识和态度，也是一个螺旋上升的情况。从厂商的灌输开始，由最初的期待，到质疑，再到重新认识并且接受DW，这才是一个符合规律的过程。
影响应用规划的因素非常多，很多客户都认识到DW重要性（当然意识到重要性不代表就能正确的使用DW），掌握了DW就掌握了未来很多话语权，这其中科技和业务部门之间，科技部门内部的争执非常多。比如科技主导建了DW，有的业务部门需求明明可以从DW走，但是非要自己另起炉灶；再比如找一个咨询公司做了应用规划，但是换了领导之后又推翻重来。所以应用没做好就说实施的人不行，是非常片面的。
NCR的“并不强大的”实施团队在国内已经是出类拔萃了，其他的提供数据仓库产品的厂家，基本不做实施。DW项目不是技术主导型的，实施非常复杂。上游往往有上百个源系统，其中的模型客户化、变更管理、版本管理、部门间协调、系统优化、测试问题管理等等，这里面的门道非常多。从业界声誉、经验和专业性角度，没有比这伙人更好的了，否则也不会被到处挖。
- 复 你的说法有失偏颇
家园 这么说可以吧 teradata在项目前期给了客户这样的期望：teradata是行业解决方案专家，有成熟的实施经验，把项目给我们没问题的。
要说teradata的软硬件dw平台，最近10年来已然是落后了，而且最近还有新老型号连续性的问题。实际上客户使用teradata的产品,很大程度就是基于上述对“行业知识”和“实施经验”的期望。teradata打这个牌成功地把机器卖进了各大行。
但是实施下来，效果确实不怎么样。这个时候再说teradata “只是专注于DW，只是提供一个平台” “实施不好有客观原因”，帐都结了，客户只能接受，而且以后还要忍受非标准硬件带来的升级维护成本飙升，运行维护人员缺乏的问题。
家园 DW的ROI是一个很值得讨论的话题 很多客户建DW就是政绩工程，尤其是政府部门，或者烟草电力等垄断企业，电信稍好但是业务太简单，这里面情况最好就是银行。
上亿的投资进去了，DW建完能带来什么价值？DW发展也是有其内在规律的，开始时候出一些统计报表，再往后可以给一些下游数据集市加工数据，目前国内大多数DW的应用价值也就限于此，大部分客户对DW的认识也就限于此了。这种对DW的使用是被动式的。
但是DW价值的发挥是依赖于它的使用者的成熟程度的，国外很多银行比如巴克莱、美洲银行，他们的业务人员都能自主的利用SQL直接访问DW中的基础数据，实现自己的需求，如果按照传统模式，业务提需求，IT实现、测试、上线，这个周期太长了。我共事过一个苏格兰银行的搞业务的老外，SQL写的比大多数搞IT的人都好，他都是自己从底层数据汇总，不用加工好的。
让大量的数据静静的躺在DW里是一种巨大的浪费，然而业务人员的成熟也是需要培养的，毕竟DW这个东西在国内还算比较新的东西，尤其是对于非IT人士。一般而言，灵活查询培养的好的话这个时间在DW建成3到4年左右，业务人员对仓库的直接查询会有爆发性增长，说明业务人员开始认可这个东西了，ICBC和CEB都是例子。
家园 确实和用户的水平有很大关系 我现在在做交易系统的开发和用户支持，发现不少trader对IT都很熟悉，自己写VBA之类的根本不在话下，很多人甚至本来就是IT出身业务熟悉了后再去干trader的。
家园 这是质的不同 但是DW价值的发挥是依赖于它的使用者的成熟程度的，国外很多银行比如巴克莱、美洲银行，他们的业务人员都能自主的利用SQL直接访问DW中的基础数据，实现自己的需求，如果按照传统模式，业务提需求，IT实现、测试、上线，这个周期太长了。我共事过一个苏格兰银行的搞业务的老外，SQL写的比大多数搞 IT的人都好，他都是自己从底层数据汇总，不用加工好的。让大量的数据静静的躺在DW里是一种巨大的浪费，然而业务人员的成熟也是需要培养的，毕竟DW这个东西在国内还算比较新的东西，尤其是对于非IT人士。一般而言，灵活查询培养的好的话这个时间在DW建成3到4年左右，业务人员对仓库的直接查询会有爆发性增长，说明业务人员开始认可这个东西了，ICBC和 CEB都是例子。
家园 技术和业务是个先有蛋还是先有鸡的问题 我们可以说技术是蛋，业务是鸡。但是首先，这个蛋不能是金蛋，因为大家卖不起，或者说在一颗蛋能不能变成鸡之前，这个蛋的价格不能太贵。其实从世纪初，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应用不成熟“就把客户否定了，更不能说”我把数据放这儿了，分析工具也放这儿了，然后下面分析什么东西就是业务人员的事了“，这不是解决问题的办法。问题是，怎么才能让应用成熟起来，怎么样才能让业务人员去分析数据。这才是我们这些技术负责人的责任。
很多公司都招聘了国外回来的海龟。恕我直言，这批人，现在在国内的影响并不好，假大空的东西太多。干事情的态度，就是那个笑话里面说的，“不是我写错了悼词，是你们家死错了人”。一谈目标，就是一个天堂设计，一谈实践，就是欧美的经历，然后再以布道的精神来谈技术问题，不是设身处地的根据现有客户的情况去解决问题，而是让银行去按照国外的标准去做全面改造（这包括改造整个流程，还包括象国外那样去花钱买设备）。