西西河

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

共:💬58 🌺197
全看树展主题 · 分页首页 上页
/ 4
下页 末页
家园 不过Teradata可是run在intel体系下的

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

家园 Teredata的硬件与数据仓库应用是相适应的

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

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

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

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

家园 Teradata性能好,说明他软件上还是有一套的

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

我怎么觉得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,应该是很正常的功能。

家园 Exadata可惜还在遮遮掩掩

还不承认自己在往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仓库内昨天的表,以获取最新的状态。

家园 列一下国内一些银行DW产品采用的情况吧

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)居多

家园 这是active datawarehouse实时数据仓库

如果前台交易使用传统数据库,按天甚至按小时将变化数据导入数据仓库,应该可以让所有人都活得容易些。

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

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

家园 软硬件一体现在是大势所趋了

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

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

全看树展主题 · 分页首页 上页
/ 4
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河