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

当然人家互联可以用专用的BYNET，磁盘挂的是EMC的阵列。貌似exadata也用的是Xeon，效率就没人家Teradata高，感觉还是软件的体系结构起决定性因素？

Teredata的性能有一半是依赖于PC集群，说是专用的硬件，机柜里面实际上就是一块块的PC主机板，再装上SUSE LINUX，然后就买出几千万去，要不然大家觉得它贵呢。

不过它这种架构与数据仓库的任务有很大关系。数据仓库的应用和OLTP不一样，OLTP要求完成实时更新，要求事务完整性，并发的任务之间有关联的，而一个任务之内，再分解最终都会需要有一个总控来做事务的完结，也就是说任务发起和结束都必须是集中式的。

而数据仓库则主要是查询任务，可以把一个任务分散到多台机器上，并不需要最终有一台机器来汇总，因此，数据仓库软件可以采用PC群技术，但是OLTP却仍然是要求一台机器，即使是双机，真正起作用的也只是一台机器。

PC机和小型机的区别就在于单机的并行处理能力上。在并发数量上，一台小型机可以支持上百到千个并发进程，而PC机在这方面的能力要远低于小型机。而在单任务的计算上，小型机并不比PC机强多少。

感觉他最牛的地方在于把数据均分到各个节点上了以后，能尽量减少节点间的通信开销。

我怎么觉得OLTP更适合分布式？更新数据量通常都不大，但需要集中控制事务的完整性？是不是更像master/slaves 的模式？

倒是数据仓库业务，如果join多了以后，免不了有跨节点的数据需要join，最后还得汇总到一个节点上做？

并尽量减少节点间交互的极至理论，就是share-nothing架构。只是这种架构对于应用有很大的限制。

OLTP单个交易更改数据量都很少，但是关键的问题还是在事务里面，有多条SQL语句，这些SQL语句所影响的数据可能分布在各个区域里，而这些SQL语句之间又有上下文关系。在下一条SQL发过来之间，数据库也不会知道它会影响哪儿的数据，所以分布式是很难处理的。

而数据仓库应用，不存在多条SQL之间的事务关联性，而单条SQL语句，无论多复杂，都意味着数据库程序是可以预先解析它，知道它如何工作，就可以在各个机器间进行分配，即使是有交互，也将交互做到最小。所以数据仓库应用更适合分布式，而OLTP则很不适合。

我的理解，如果数据库不做UPDATE操作，而只有delete、insert和select ,那么模式会简化很多。

数据仓库应用和一般的事务型数据库应用有很大的差别。OLTP和OLAP两种需求的区别不仅仅体现在底层支撑平台上，系统设计理念也是大不一样的。所以专用的数据仓库或分析类的系统不支持传统的SQL并不奇怪。毕竟SQL主要还是用在关系模型上比较得力。而关系模型在分析系统中并不见得是一种有效的架构。比如同样叫“表”用于分析的维度表更倾向于稀疏矩阵，而不是一般数据库的平衡树。

所谓数据仓库并不是仅仅作为仓库使用，其应用价值在于分析模型。因此我觉得你不应该将重点放在数据表操作上，而是应该考察其内核模型是否能满足你的分析需求。至于你提到的几个指标基本上都属于分析前的数据导入动作。某些特殊的导入需求不能用SQL实现实在不能算什么大问题。不能用SQL，用其他方式实现只要在性能上没问题，就不是问题。具体的解决方法让程序员考虑就可以了。

数据仓库系列软件，数据仓库存储工具（比如teredata)、多维数据库（比如Hyperion OLAP server)、前端信息展现工具（比如BO、Brio、Cognos)、数据仓库ETL工具（比如DataStageXe、infomatic)。这些软件，各有各的用处，但是都是工具级的。

而你说的分析模型，我想这是属于应用级的东西，是应用产品里面带的，比如客户关系管理、绩效考核等等。虽然很多咨询专家喜欢将工具和应用混到一起去谈数据仓库，但是这确实是两个层面的东西。

我这里说的是数据仓库存储工具（如teredata、greenplum)的测试，也许是我了解不深，真不知道这些工具内部有什么分析模型（但如果有的话，我想他们的宣传里面应该也会说呀），而且似乎DB2、oracle之类的传统数据库也不带分析模型什么的吧。

一个数据仓库软件上千万的投资，也许美国的分析很发达，所以需要那些东西，但是中国的客户需要它的，首先是海量历史数据存储和检索功能，至于玄而又玄的一些东西，如果客户连相关的业务需求都没有，你拿来也没用。不要只从数据仓库技术人员的角度去考虑问题，要考虑的是客户的实际需要。什么分析模型，也许很值钱，但是客户用不上，所以它就不值一分钱，而检索和插入的效率（何况这也是数据仓库的基本性能要求），客户需要，这就是体现价值的地方。产品商去自说自话，孤芳自赏这没用，要的是去满足客户的需要。起码teredata，这个数据仓库就是在10年的折腾中，把自己变得越来越象传统数据库了。

而数据仓库是不是应该支持传统SQL，这个倒是仁者见仁，智者见智。毕竟现在的应用开发体系（比如WEB/JAVA）什么的，完全可以在一套系统中同时存取两个不同型数据库中的数据。但是，如果想用单一数据库做复杂的应用，那么数据仓库存储不能完全支持SQL，这个就很致命了。

其实我觉得你少考虑了一个因素，传统数据库基本上是单点，只能scale up的， 基于这种模式的数据仓库产品，不过避免的会出现性能瓶颈，如果你的规模估算没用足够余量的话。

teredata这种基于机群的方案也未必会真正在数据库存储方面进行大量改良。

我建议你考虑一下非传统的解决方案，比如列数据库，在提供高效压缩的基础上可以充分利用单机的运算能力，还可以做基于列数据库的集群。map reduce也是一种可能。

现行的商业产品基本都有很多限制，要是决心大，还是要基于开源方案自己搞。

嵌入式数据库不可能处理海量数据，如果你通过大量分区来做，最后不值得怎么死的。

海量数据的数据仓库确实不应该做实时的更新，最好还是采取类似sql load这样的批量装载，要不怎么叫ETL而不是ETI。

真正到了海量数据SSD一点用都没用，数据量太大，用不起。

oracle这种传统数据结构的玩意，很难做到海量数据，中等规模（5亿-20亿左右）的数据通过分区支持还可以。

有些想法值得商榷

1. 不支持update其实不奇怪，因为传统的update往往就是先delete再insert。对于海量数据，这样整未必好。

2. 海量数据应该有海量数据的处理方式，传统标准的sql未必是好的。

其实千万到10亿这个级别还谈不上海量数据库。 我觉得要在50-100亿以上这个数量级才是挑战了。 现在online的web 2.0系统，很多一天需要处理数t的日志，传统基于数据库的做法都不行。

能谈谈你们实际对gleenplum的测试么？

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

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

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

还不承认自己在往share-nothting的架构上靠，其实它底层的storage server已经是按照SN思路来进行数据切分了，但上层的database server还是share disk的老路。

Exadata一个很大缺陷是存储用多个PC替代磁盘阵列，用软RAID,速度和散热都是问题。

我在国内TD干过四年，进公司的时候还叫NCR。Teradata一直倡导的一个理念就是adhoc，即灵活查询、即席查询或者随机查询。在国内实施DW仓库项目的时候，TD上很少建索引，因为无法预知用户提交的查询是什么样，所以没办法提前优化。

至于数据在各节点间的重新分布，在实际应用中是不可避免的。最常见的情况就是在两个table做join的时候，如果两个表都是按照同一个键值做的分布，那么性能最好，一个大join就变为多个节点上local的小join；如果分布是不一样的，一般情况下稍小的那个表就会按照其参与join的字段做重新分布，这样就有变成节点内部的小join了。

这个过程必然伴随着节点间数据的迁移，但是Teradata有一个特有的节点间互联技术BYNET。这是一个点对点的网络，不是和以太网一样共享带宽的，因此加入新节点后不会影响节点间数据传输的带宽。所以TD一直标榜的斜率为1的线性性能增长，依赖的2个绝活就是数据均匀分布+BYNET。

至于Update，数据仓库里是一定有的。举个例子，对于账户表，会那源系统给的增量数据去update仓库内昨天的表，以获取最新的状态。

ICBC：Teradata

CCB：Teradata

BOC：未建数据仓库。信用卡中心的datamart是Teradata

ABC：未建数据仓库，目前用Sybase IQ实现一些统计分析和报送的功能

交行：Teradata

招商: DB2

邮储：Teradata

中信：未建数据仓库，目前用DB2建的ODS

民生：Teradata

光大：Teradata

华夏：未建数据仓库

浦发：Tearata

广发：未建数据仓库，目前用DB2建的ODS

深发：GreenPlum

兴业：Teradata

北京银行:未建数据仓库，目前用GreenPlum建的ODS

上海银行：Tearata

剩下的城商行，以Oracle（非Exadata）居多

数据仓库发展的终极阶段，国外有案例但是还非常少。这种形态下的数据仓库就不只是几十、几百个后台分析人员再用了，它已经融入到运营流程中了，很多callcenter、柜员做业务的时候就会用它，比如实时营销和实时风险监控，这些信息在交易系统里往往不存，要到后台分析型系统里拿。

这样对数据仓库混合负载管理能力的要求也非常高了，访问量高了不止一个数量级，而且复杂查询和简单查询并存，中间还夹杂着准实时的数据更新。

Teradata、DB2的BCU、Exadata、Netezza，GreenPlum。

数据仓库的CPU、IO配置均衡非常重要，现在一般不会单卖软件然后用户自己攒机器了、选操作系统。