主题：【原创】数据仓库软件的评测心得 -- 河蚌
近期，工作上需要一款专业级数据仓库软件，现在市面上号称能进行海量存储并且面向分析的产品很多，传统的如Teredata,新锐的如 GreenPlum,当然还有一些国产的软件，专门针对中国某些保密领域的。乱花迷人眼，未选已彷徨，有时候不单光听宣传是不够的，即使自己做过一些性能测试也是不够的，很多东西都是看上去很美，但是真正的爱上它们并作为工作中的依靠却不是件容易的事情。
在吃过无数苍蝇之后，咱还是总结一下经验教训吧，因为只有这样才能真正的吃一堑长一智，才能透过别人的忽悠，扒下某些软件美丽的外衣，看清楚这软件是天生丰满还是垫出来的。
首先要明确目的，我们采用专业级数据仓库软件，不是说现在的数据库用腻了，要换一个新鲜玩意，而是它们能比经典的数据库（DB2、Oracle、 Sybase、Informix再加上SQLserver)在海量数据（这个是指千万条到十亿条记录这个区间）上有着更佳的性能。我们希望用数据仓库软件的强项去完成更复杂的分析应用，做到以前的数据库软件无法做到的应用功能，这一点是我们选用数据仓库的关键。
其次，我们选用数据仓库软件，就是希望在数据分析领域（让它替换交易系统是不可能的），能够替代原来的数据库软件的平台，保证整个企业的这部分应用可以基于新的平台来做，而不是说引入这玩意，只是存储数据，而做应用还得再用以前的数据库平台。
如果说第一个目标是大家都公认的，这第二个，则是各有各的说法。因为这第二个目标会要求数据仓库软件除了上述的亮点外，同时在功能上（性能上可以低一点）还要具有传统数据库所具有的基本功能，比如对于标准SQL的全面支持。这一点很容易被我们忽略，因为一般大家都会觉得，既然是数据仓库，就不该连这样基本的功能就不支持吧。但是，有些事情总是会让人很意外。
明确了目标，那么我们下面就要谈谈怎么选型测试了，总结一下，数据仓库软件的选型，主要是从三个方面去考虑，即运行效率、应用接口、商务。当然，俺这个标准主要是金融业的标准，如果是电信什么的，大概就需要以几十亿条为基准来测了。
一、运行效率方面主要包括如下内容：
1、数据文件导入的速度。即约30个字段的表，分别导入3000万条、8000万条、1.5亿条、3亿、5亿、10亿条记录数据的运行时间。
我不喜欢用好多软件商提供的标准，即所谓多长时间导入多少G的数据，因为，3个字段的3000万条记录和30个字段的300万条记录，这个数据量其实是一样的，但是无论是导入还是检索，实际上时间都会有很大的区别。对于大多数数据库而言，3个字段和50个字段的检索效率上并没有显著的区别，因此运行测试的指标，应该是以30个字段的表为依据，验证不同的数据记录条数的导入速度。很多数据库，当记录数突破某个数量时，导入速度就会进入明显的下降曲线，因此我们通过上述不同样本的测试，就可以基本了解其上限值是多少，并在应用中尽量避免。
2、insert的运行。即由一个表向另一个同结构的空表插入，样本的记录数同上。
基本上所有的数据库软件都提供外部工具来对付文本数据导入，这种外部工具其实不是走SQL的，因此其用途也就是个专用工具。而insert的测试则是对其SQL解析器的基本测试，也是对于日志等各项指标的测试。
3、在上述样本下，进行两个非关键字段的数值汇总（即sum和count)的运行时间。
对非键字的汇总功能是应用中经常用到的，其实我们不必测试太复杂的SQL功能，因为复杂的SQL可以通过这种基本的功能进行推算。
4、关键字段单条查询运行时间，即以关键字为搜索条件查询单条记录的运行时间。
关键字段单条检索，是应用中最普遍采用的SQL语句，也是验证数据库在索引等机制上是否完善的指标。
5、组合搜索查询运行时间，即以三个非关键字字段的组合条件查询多条记录的运行时间。
非关键字段组合搜索，同样是应用中获取记录集合的主要手段。
6、三表关键字关联查询，即以三个海量数据表进行关键字关联查询记录的运行时间。
其实所有的数据仓库软件都号称可以进行16个表到32个表的关联查询，并且运行速度很快，但是对于应用来说，这么复杂的应用模型无疑说明设计有问题，但是三表关联还是非常常见的。
二、应用接口支持方式主要包括如下内容：
1、是否支持SQL-merge语句，即update/insert操作方式，这条SQL在分析应用中已经广泛使用。
Merge语句的推出绝对是SQL对于数据分析和批量处理上的一大贡献，到目前为止，所有的传统数据库都支持这个SQL。如果你测试的数据仓库软件能够支持这个，那真是你的大幸。当然如果不支持，那也没办法，毕竟这条语句出现的时间不长。我们可以写一个MERGE自动解析程序，将其转换成 UPDATE/INSERT语句
2、是否支持全部的标准SQL操作。
其实提出这个问题有点NC的意味，既然是数据仓库软件，怎么能在SQL上出问题呢。但是，俺们吐血就在这个地方，我们曾经抱以很在希望的一款数据仓库软件最后被放弃，恰恰出在这个方面，它在运行效率上的表现无疑是十分优秀的，但是等到我们下定决心将我们的应用搬上去时，却发现一些基本的SQL操作，它竟然不支持，比如对于关键字的UPDATE操作，还有非分区键字不能出现在IN、EXISTS中，并且不支持NOT IN，NOT EXISTS的操作。
当然，人家数据仓库软件公司的解释是，这些语句我们都有替代的办法，替代的办法嘛，比如UPDATE，你可以建立一个新表呀，如果要做那种UPDATE，你可以先关联之后生成到新表里，然后再把新表数据覆盖到原来的表里呀。我们的数据仓库软件，INSERT速度是非常快的，绝不会因此影响效率的，OK？！！而我只能无言，然后吐血斗升。
3、是否支持快速清空命令。即truncate.
其实这个不用说了，都2010年了，现在的数据仓库或者数据库都支持。
4、是否支持无日志方式运行。
这个不一定要，但是如果有的话，就更好了，因为我要导10亿条数据进去，确实不希望这个操作记什么鬼日志，如果失败，咱更愿意清空了重新做一遍。不过现在数据库好象都不能支持到指定某条SQL无日志运行，真希望啥时候能够提供这种机制。
5、是否支持分阶段事务提交模式。
这个，其实和上一点是一样的，我要插入几亿条数据，如果是一条条变换，一条条插入，当然不希望这个在一个事务中，而是希望隔多少条提交一次，保证日志不会满，当然，如果上一点的要求能实现，那就更好了。
6、是否支持滑动游标（SCROLL CURSOR）的读取方式。
介个嘛，其实和数据分析没太大关系，只是如果游标能支持滑动，我们就可以在应用中更方便地操作了。
7、JDBC驱动库的支持。
现在大家都是用WEB/JAVA来写查询了，你有数据仓库软件自然就应该提供JDBC驱动吧，这个如果不提供真是无话可说。
三、在商务报价上面
1、产品的报价方式，以及基础版本的报价。
其实我们要明白，市面上不是只有一家产品，还有，就是，不要以teredata为参照系，毕竟，现在推出的数据仓库产品，都是没多少积累的，而且基本上，我们用了，会是最前面几个吃螃蟹的人（说不定还是第一个），这种风险其实蛮大的。如果以每个CPU70万（基本上全价就是300万）买回来一个数据仓库软件，却实际上却是在给产品厂商当试验品，去给别人做一个代价高昂的测试的话，这就有些很不花算了。
2、产品目前的成功案例。
这个和第一点是一样的，虽然第一个应用某产品是很拉风的事情，但是私底下流泪的辛苦只有我们自己知道。所以，还是让别人在前面摔跟头，然后我们踩着他们的身体前进吧。
不知道楼主能不能将测试结果发上来。虽然不懂数据仓库，但是还是很关注这些新的产品和技术。
传统的数据库软件，包括DB2、Oracle、Sybase、Informix，是支持各种平台（主要是UNIX和WIN），SQLServer只支持WIN平台，所以不列进来。这些数据库，因为要支持并发交易，要保证事务的完整性，因此大规模数据处理的速度就比较低，一般到亿级就达到瓶颈了，使用再好的硬件也没有（比如RS/6000 595），而数据仓库则是放弃了并发交易需要的那些机制，因此速度可以快很多。
我们测试的数据仓库软件，3000万数据导入一般在2分钟左右，8000万在7分钟，1.5亿条要24分钟，3亿条要55分钟左右。硬件是3台PC服务，一台是主机，两台数据机，服务器都是32G内存，硬盘是4T。
这个比传统数据库在RS/6000 595上的测试性能还要高很多（用传统数据库的快速导数工具）。而且这只是导入，如果是检索和汇总，那差别就更明显了。
其实性能测试是蛮好的，可惜问题出在对SQL的支持。
数据仓库一般都会采用分布式数据库架构，采用share nothing的理念，即一条SQL放进去，主机再发给各数据机，然后各数据机不需要任何交互，各做各的，然后将结果返回来就行。
这种理念对于向google这样的固定关键字检索是一点问题也没有，但是share nothing的理念对于复杂应用是很有问题的。这种架构肯定不能支持NOT IN，NOT EXIST，而且限制WHERE子句中IN操作的字段必须是用来做数据分区的键字。
可这就是问题所在，应用上不用not in ,not exist这个可以忍受，但是非分区键字的in这个应用中太广泛，不可能不用。其实除非是某一个专业领域，比如文档检索，象企业的商业智能应用，里面汇总、钻取、检索之类的应用多了去了，而且大多数表并不是海量的，比如参数表，其实就是几条或者几十条数据，但是数据仓库如果说连这种小表也是分布结构，因此造成普通的SQL操作无法做，那就只能说是功能缺失了。
放弃并发更新和事务，嵌入式数据库可以获得很拉风的速度。
放弃实时更新，数据仓库才能搞定海量数据的查询。
您要求大象打地洞蚂蚁举起大树，虽说一切皆有可能，但是概率基本为零。用辐射用转基因促使变异然后在后代中选择，除非您的团队集体祖坟冒青烟以致三代以内获得期望的变异，最大的可能性还是一无所获。所以我说对暗淡的前景要淡定。
我也有和您类似的需求。起因是我希望一个论坛在海量历史数据和高并发更新时候简化编程和部署。
说实话您的数据量还没有到变态的地步，在我看来数据内存比1比1在硬件上经常不是问题，何况现在还有SSD硬盘。问题在于网络带宽和延迟。上InfiniBand300Gbit/s加上使用提供集群和数据挖掘功能的传统数据库如ORACLE或许能够解决问题。
如果前台交易使用传统数据库，按天甚至按小时将变化数据导入数据仓库，应该可以让所有人都活得容易些。
佛祖 上帝 安拉 与你同在！
我想你没有看清楚我要的东西。俺可没有希望既满足海量数据处理，又有高并发性请求。实际上，大家都知道并发更新（OLTP）和海量数据处理（OLAP）的两者的高性能是不可能同时存在的。所以没有人会这样变态的要求。
即使是银行的业务运营支撑系统，往往也是日常交易处理和日终批量处理分成两个库，同一种数据库也会按分析型和交易型的不同参数来配置。
俺要的是，数据仓库软件在满足海量数据处理的高性能的同时，在功能上（而不是性能上），要支持所有数据库该有的功能，特别是对标准SQL的支持。而某些数据仓库软件连UPDATE这一基本的SQL功能
都不支持了，这就有些过分了。在这种情况下，即使有再好的所谓海量数据处理和检索性能，实际上也是不太适合的，除非企业钱多，就是想用数据仓库来处理海量数据这一范围很窄的领域。
银行的数据量当然没有象电信那么变态（当然四大全国性银行的数据量还是很变态的）。对于数据分析而言，网络设备根本不是问题，数据仓库的各个机器之间都可以千兆网络，而且如果有可能的话，上光纤也不是什么难事，毕竟相对于数据仓库及硬件设备的价格而言，这些外围设备根本就不算钱。
银行的前台系统当然是传统数据库，现在的模式一般都是按天来抽数的。当然ODS（即所谓实时数据仓库里的操作型数据区）是希望按小时来更新的，不过在大多数银行是不会这么做的，因为以天为频度就够了。
我感觉不提供是正常的，提供了当然更好。我碰到的一个类似数据仓库软件是用下面方式处理的。首先这个系统为了追求查询速度采用了特殊的索引，这种索引更新很慢。在这个系统以前版本中的每次UPDATE都触发索引的更新，性能惨不忍睹基本不可用。在新版本中，将UPDATE的数据存储在内部一个特殊区域中，等积攒够多了之后才更新索引。在更新索引之前的查询是分别对老索引和缓冲区进行查询再合并结果集。因此用户感觉UPDATE很快，系统也无须频繁重建索引。（当然有可能某次UPDATE导致必须重建索引而变慢）。
在我看来UPDATE可用当然更好，是能大大方便使用。
千兆是最低档的连接方式，带宽小也罢了，主要是延迟太大。我想如果您查询过InfiniBand的价格就不会说
对于我们来说，希望操作的记录数大概是3亿条左右，也就是中国的省级规模的银行的水平。系统要求海量数据的处理运行效率，要求有很好的并发查询性能，不要求并发更新性能。
这种目标，千兆网络就够了。其实对于我们来说，关键是以最合适的价格满足应用，所以那种高精尖的技术架构不在我们的考虑范围之内。花几千万，买来的东西最后只用来出报表，这样的情况在中国很常见，不过也是为什么商业智能和数据仓库无法普及的原因。
InfiniBand价格当然是够可以的，但是也不是不能接受，我们这儿用了不少，可管理起来挺讨厌的，要是停个电，恢复起来麻烦，和之相比，以太网的路由器真是智能呀。
有些好奇，过去的那些小型机，RS/6000 和现在的这些服务器比起来到底怎么样.
现在的，哪怕是windows服务器能够轻松上几十个GB的内存，硬盘SSD的也不贵了，如果不是特别的可靠性要求，几年前的这种小型机是不是已经没有什么优势了
其实现在服务器、小、中型机的界限已经很不明白了，RS/6000一开始时就是被定义为服务器的，但是现在的RS/6000，从520到595，性能差别极大，可以说涵盖了从服务器到中型机（甚至可以说大型机）的领域，只是体系架构上保持一致，
它们和PC服务器来比，从CPU体系架构到IO能力差别很大的。不过低档的RS/6000和PC服务器的处理能力，相差确实已经不大了（当然价格也相差不大）。
小型机和PC服务器，差别主要还是在于并行处理能力，如果只是单跑一个任务，这个差别不大。但是，小机是用来做中心主机的，象一个省级的金融系统（再大规模的就得用ES9000了），要求同时支持并发上万个交易。这个再强的PC都是做不到的。
象内存和硬盘，现在这个已经不能作为衡量大、中、小机的指标。比如现在想给PC机配个1T的硬盘，16G的内存，根本不是什么问题，但是要真说处理能力，还真不一定比得上5年前出产的RS6000 520。
主要卡在总线带宽和IO带宽？
现在美国有很多大银行在用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.
因为太贵了，差不多要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亿条数据吗？
说一千，道一万，自己说好，那没用，甚至客户说好也没用，能让客户掏钱购买才是王道。
PC和RS/6000在总线好象是完全不同的架构。
CPU也不一样，RS/6000用的是POWER芯片。
硬盘不一样，SCSI/SAS硬盘的速度好象比IDE/SATA要快不少，SSD就不太知道了。
这方面研究的不多。可以查一下专业资料吧。
感觉国外人的成本比较高，比较起来，对软硬件价格不是很敏感。
国内价格因素比较重要，更重要的是高端应用也用不起来