主题：【原创】数据仓库软件的评测心得 -- 河蚌

银行应用不单是海量数据的问题，对于银行而言，单独一两个分析功能是没有意义的，要的是一个完整的应用系统，比如客户经理营销管理、绩效考核、风险管理。这都是分析与操作混和在一起的。其实，我们要求的模式，就是海量数据分析上的优秀表现，以及对于传统数据库操作的功能支持（也就是说，性能可以低点，但是不能不支持）。

金融业是个很特殊的行业，就是这个行业不存在实物流，它玩的钱现在就是数字（要不然怎么叫虚拟经济）。因此，金融业的业务复杂度要比其它行业高的多，这个行业的特色就是无中生有，靠想象力造出各种各样的金融产品来。而有实物流的行业，脱不出进销存这个框架。

如果一个数据仓库软件只是针对海量数据，而不能支持简单的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，应该是很正常的功能。