主题：【原创】数据仓库软件的评测心得 -- 河蚌
家园 我们说的查询不是一回事 你也说过很久没去四大行了，应该去了解一下现在的情况再下结论不迟。其实说是四大行，但每家都情况不一样。
ICBC是坚持应用建设和业务人员灵活查询两条腿一起走，应用支持的不如建行多，但是从今年开始灵活查询做的非常好，不但业务自己能通过客户端去DW找自己想要的数据，而且“真正摸索出来一条接着灵活查询，扭转BI类项目应用系统需求不明确的问题”，基于灵活查询的数据探索之后提出应用需求（不一定是数据集市建设），做出来效果都非常好，这也是用户自己说的。
CCB一贯的思路是DW就是为了下游应用集市加工数据，仓库没有对业务人员开放。现在给下游四十多个集市提供数据。CCB的应用基本上不是TD在做，三四家其他公司一起做的。你说CCB应用差，可以具体的说是哪块做的不行。
中行没有DW，只是在信用卡中心建了数据集市。由于是业务部门主导建立的数据集市，而且和苏格兰银行是合作伙伴，有很多老外也在这一起工作，所以业务人员的理念、对需求的把握都比较成熟。它的灵活查询是国内开展最早也是效果最好的，从04年开始培养大一批既有业务知识又有一定IT素养的业务分析人员，但流失的也不少。
ABC也没建DW，它有一个SybaseIQ的基础数据平台，而且还是总分架构的，数据不全。业务人员很多需求都非常难实现，科技的人只能手工从各个系统里凑结果。
TD从国内老板到下面干活的，都是纯土鳖，没招过什么海龟。从2000年到如今一直都在实施第一线，相反很多其他DW厂商倒是只卖产品不管实施。DW从来不是一个技术主导型的系统，只有产品服务跟不上肯定没有市场。
至于应用的建设，TD传统上也不是做应用规划的咨询公司，基本还只是关注在DW建设本身。你可以具体说说什么样应用算是做好了，光一个很差没啥说服力。
家园 大行还真不如你这么熟悉 CCB的TD应用在厦开有，在北京也有，现在主要是在厦开了。去年在那里呆过两个月，不过似乎这个号称的ＤＷ组并没有太多的工作（当然人也不是太多），他们的工作基本上被ODS组基本上给抢去了。厦开做管理项目的很多，不过用ＴＤ并被称为ＤＷ组的好象就那一个。
当时厦开对ＤＷ组的评价就是，那是一帮依靠ＴＤ的一招鲜混饭吃的家伙。
如果把买了TD作为有无DW的话，那么中行肯定是有的。ＮＣＲ一直在中行有个４、５０人的项目组。只是他们做的活儿是以那个FNS的新系统为数据源来做的，但ＦＮＳ系统一直没上线，所以他们做的东西就更连上线日期都确定不了。
ABC还有过直接接触，对ICBC那就真是不了解了，不过，当看到“真正摸索出来一条接着灵活查询，扭转BI类项目应用系统需求不明确的问题”这句话时，不由得就笑了。这又是一句从2002年以来就在不断重复的老生常谈。
关于查询的事情，我想你还是站在技术角度去考虑问题了。你怎么知道银行的查询需求和你说的查询是两回事儿。实际上作为一个业务人员，提出的需求就是业务数据查询（包括指标查询），至于是不是灵活查询，这是技术人员的视角。而实际上，最近几年交流中，被问起最多的就是，你们有没有这个灵活查询（或者灵活报表）的工具，甚至很多二线城商行也都会问起这个事来。而他们问这个，其实就是因为让业务人员那些繁杂的查询和报表要求给弄烦了。
至于海龟嘛，这个倒不一定是指ＮＣＲ（业界对它的评价，这是一家披着外国皮的国内公司）。而是指游荡在各个金融ＩＴ公司里面以咨询为谋生手段的大神们，很多挂着某某研究院博士，某某银行十余年金融分析经验的神人们。
去年，曾经和TD合作去银行做交流，整体的感觉是TD员工的自我感觉真是很好，不过，也就是那次之后，我们决定放弃与TD继续合作，而想找一个替代产品。技术人员有一种优越感很正常（只有偏执狂才能生存嘛）。但是，不去听业务人员的述求，而总是陶醉在自己的技术世界里就没有意思了。
还是那句话，如果站在技术的角度去考虑问题，那就会永远在灵活查询怎么和应用需求对接这个问题上打转转。但是，如果从业务入手，将银行的管理领域按业务条线来划分，分出诸如历史数据管理、内部报表、绩效考核、CRM、风险管理、资产负债管理、财务预算、经济资本计量等领域，再在这些业务领域里总结需求，形成应用系统，那么你自然会发现，这里面有多少个业务功能是多么迫切地需要灵活查询这一技术平台来实现了。
家园 CCB的ODS可不是传统上的ODS CCB的ODS其实就是一个数据交换的平台，里面没database什么事，都是文件操作，也没法基于这个ODS做应用，它只管数据分发，它和DW是上下游关系，构不成竞争。
中行买TD但是卡中心买的，总行肯定没买。怎么可能会有4，50人团队在中行，TD北京做金融行业加一起也就是50人。
至于ICBC，02年的时候哪有什么BI的概念，认知不能总停留在02年吧。那话不是厂商的宣传语也不是客户领导讲的客套话，是DW支持团队说的。业务人员对DW态度的变化他们是最有发言权的。
我并没有排斥做应用系统，应用和灵活查询都是DW体现价值的重要方面。
家园 【原创】 其实我觉得你少考虑了一个因素，传统数据库基本上是单点，只能scale up的， 基于这种模式的数据仓库产品，不过避免的会出现性能瓶颈，如果你的规模估算没用足够余量的话。
teredata这种基于机群的方案也未必会真正在数据库存储方面进行大量改良。
我建议你考虑一下非传统的解决方案，比如列数据库，在提供高效压缩的基础上可以充分利用单机的运算能力，还可以做基于列数据库的集群。map reduce也是一种可能。
现行的商业产品基本都有很多限制，要是决心大，还是要基于开源方案自己搞。
家园 谢谢，价格的问题的确如此 感觉国外人的成本比较高，比较起来，对软硬件价格不是很敏感。
国内价格因素比较重要，更重要的是高端应用也用不起来
家园 您的目标很激进，那么对于艰辛的过程和暗淡的前景要淡定 放弃并发更新和事务，嵌入式数据库可以获得很拉风的速度。
放弃实时更新，数据仓库才能搞定海量数据的查询。
您要求大象打地洞蚂蚁举起大树，虽说一切皆有可能，但是概率基本为零。用辐射用转基因促使变异然后在后代中选择，除非您的团队集体祖坟冒青烟以致三代以内获得期望的变异，最大的可能性还是一无所获。所以我说对暗淡的前景要淡定。
我也有和您类似的需求。起因是我希望一个论坛在海量历史数据和高并发更新时候简化编程和部署。
说实话您的数据量还没有到变态的地步，在我看来数据内存比1比1在硬件上经常不是问题，何况现在还有SSD硬盘。问题在于网络带宽和延迟。上InfiniBand300Gbit/s加上使用提供集群和数据挖掘功能的传统数据库如ORACLE或许能够解决问题。
如果前台交易使用传统数据库，按天甚至按小时将变化数据导入数据仓库，应该可以让所有人都活得容易些。
佛祖 上帝 安拉 与你同在！
家园 这是active datawarehouse实时数据仓库 如果前台交易使用传统数据库，按天甚至按小时将变化数据导入数据仓库，应该可以让所有人都活得容易些。数据仓库发展的终极阶段，国外有案例但是还非常少。这种形态下的数据仓库就不只是几十、几百个后台分析人员再用了，它已经融入到运营流程中了，很多callcenter、柜员做业务的时候就会用它，比如实时营销和实时风险监控，这些信息在交易系统里往往不存，要到后台分析型系统里拿。
这样对数据仓库混合负载管理能力的要求也非常高了，访问量高了不止一个数量级，而且复杂查询和简单查询并存，中间还夹杂着准实时的数据更新。
家园 【原创】 嵌入式数据库不可能处理海量数据，如果你通过大量分区来做，最后不值得怎么死的。
海量数据的数据仓库确实不应该做实时的更新，最好还是采取类似sql load这样的批量装载，要不怎么叫ETL而不是ETI。
真正到了海量数据SSD一点用都没用，数据量太大，用不起。
oracle这种传统数据结构的玩意，很难做到海量数据，中等规模（5亿-20亿左右）的数据通过分区支持还可以。
家园 数据仓库当然不要求并发的实时更新处理能力。 我想你没有看清楚我要的东西。俺可没有希望既满足海量数据处理，又有高并发性请求。实际上，大家都知道并发更新（OLTP）和海量数据处理（OLAP）的两者的高性能是不可能同时存在的。所以没有人会这样变态的要求。
即使是银行的业务运营支撑系统，往往也是日常交易处理和日终批量处理分成两个库，同一种数据库也会按分析型和交易型的不同参数来配置。
俺要的是，数据仓库软件在满足海量数据处理的高性能的同时，在功能上（而不是性能上），要支持所有数据库该有的功能，特别是对标准SQL的支持。而某些数据仓库软件连UPDATE这一基本的SQL功能
都不支持了，这就有些过分了。在这种情况下，即使有再好的所谓海量数据处理和检索性能，实际上也是不太适合的，除非企业钱多，就是想用数据仓库来处理海量数据这一范围很窄的领域。
银行的数据量当然没有象电信那么变态（当然四大全国性银行的数据量还是很变态的）。对于数据分析而言，网络设备根本不是问题，数据仓库的各个机器之间都可以千兆网络，而且如果有可能的话，上光纤也不是什么难事，毕竟相对于数据仓库及硬件设备的价格而言，这些外围设备根本就不算钱。
银行的前台系统当然是传统数据库，现在的模式一般都是按天来抽数的。当然ODS（即所谓实时数据仓库里的操作型数据区）是希望按小时来更新的，不过在大多数银行是不会这么做的，因为以天为频度就够了。
家园 不是我没看清您的需求 俺可没有希望既满足海量数据处理，又有高并发性请求。是我的一个需求。俺要的是，数据仓库软件在满足海量数据处理的高性能的同时，在功能上（而不是性能上），要支持所有数据库该有的功能，特别是对标准SQL的支持。而某些数据仓库软件连UPDATE这一基本的SQL功能都不支持了，这就有些过分了。我感觉不提供是正常的，提供了当然更好。我碰到的一个类似数据仓库软件是用下面方式处理的。首先这个系统为了追求查询速度采用了特殊的索引，这种索引更新很慢。在这个系统以前版本中的每次UPDATE都触发索引的更新，性能惨不忍睹基本不可用。在新版本中，将UPDATE的数据存储在内部一个特殊区域中，等积攒够多了之后才更新索引。在更新索引之前的查询是分别对老索引和缓冲区进行查询再合并结果集。因此用户感觉UPDATE很快，系统也无须频繁重建索引。（当然有可能某次UPDATE导致必须重建索引而变慢）。
在我看来UPDATE可用当然更好，是能大大方便使用。
数据仓库的各个机器之间都可以千兆网络，而且如果有可能的话，上光纤也不是什么难事千兆是最低档的连接方式，带宽小也罢了，主要是延迟太大。我想如果您查询过InfiniBand的价格就不会说
这些外围设备根本就不算钱家园 InfiniBand InfiniBand价格当然是够可以的，但是也不是不能接受，我们这儿用了不少，可管理起来挺讨厌的，要是停个电，恢复起来麻烦，和之相比，以太网的路由器真是智能呀。
家园 呵呵，只能说你的要求很变态。 对于我们来说，希望操作的记录数大概是3亿条左右，也就是中国的省级规模的银行的水平。系统要求海量数据的处理运行效率，要求有很好的并发查询性能，不要求并发更新性能。
这种目标，千兆网络就够了。其实对于我们来说，关键是以最合适的价格满足应用，所以那种高精尖的技术架构不在我们的考虑范围之内。花几千万，买来的东西最后只用来出报表，这样的情况在中国很常见，不过也是为什么商业智能和数据仓库无法普及的原因。
家园 止不住的落泪 不知道楼主能不能将测试结果发上来。虽然不懂数据仓库，但是还是很关注这些新的产品和技术。
- 复 止不住的落泪
家园 这个是说如果有数据仓库软件的话，就测试这些方面 传统的数据库软件，包括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操作无法做，那就只能说是功能缺失了。
通宝推：响马,