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

近期，工作上需要一款专业级数据仓库软件，现在市面上号称能进行海量存储并且面向分析的产品很多，传统的如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、产品目前的成功案例。

这个和第一点是一样的，虽然第一个应用某产品是很拉风的事情，但是私底下流泪的辛苦只有我们自己知道。所以，还是让别人在前面摔跟头，然后我们踩着他们的身体前进吧。