为什么很多公司的大数据相关业务都基于 Hadoop 方案？
【曹坤的回答(16票)】:
选择的原因最重要的就是这三点：1，可以解决问题； 2，成本低 ； 3，成熟的生态圈。
一，Hadoop帮助我们解决了什么问题
无论国内还是国外的大公司对于数据都有着无穷无尽的渴望，都会想尽一切办法收集一切数据，
因为通过信息的不对称性可以不断变现，而大量的信息是可以通过数据分析得到的。
数据的来源途径非常的多，数据的格式也越来越多越来越复杂，随着时间的推移数据量也越来越大。
因此在数据的存储和基于数据之上的计算上传统数据库很快趋于瓶颈。
而Hadoop正是为了解决了这样的问题而诞生的。其底层的分布式文件系统具有高拓展性，通过数据冗余保证数据不丢失和提交计算效率，同时可以存储各种格式的数据。
同时其还支持多种计算框架，既可以进行离线计算也可以进行在线实时计算。
二，为什么成本可以控制的低
确定可以解决我们遇到的问题之后，那就必须考虑下成本问题了。
1， 硬件成本
Hadoop是架构在廉价的硬件服务器上，不需要非常昂贵的硬件做支撑
2， 软件成本
开源的产品，免费的，基于开源协议，可以自由修改，可控性更大
3，开发成本
因为属于二次开发，同时因为有非常活跃的社区讨论，对开发人员的能力要求相对不高，工程师的学习成本也并不高
4，维护成本
当集群规模非常大时，开发成本和维护成本会凸显出来。但是相对于自研系统来说的话，还是便宜的很多。
某司自研同类系统几百名工程师近4年的投入，烧钱亿计，都尚未替换掉Hadoop。
5，其他成本
如系统的安全性，社区版本升级频繁而现实是无法同步进行升级所引入的其他隐形成本。
三， 成熟的生态圈有什么好处
成熟的生态圈代表的未来的发展方向，代表着美好的市场前景，代表着更有钱途的一份工作(好吧，“三个代表”).
看图(引自：）
部分系统归类：
部署，配置和监控 Ambari，Whirr
监控管理工具 Hue, karmasphere, eclipse plugin, cacti, ganglia
数据序列化处理与任务调度 Avro, Zookeeper
数据收集 Fuse,Webdav, Chukwa, Flume, Scribe ， Nutch
数据存储 HDFS
类SQL查询数据仓库 Hive
流式数据处理 Pig
并行计算框架 MapReduce， Tez
数据挖掘和机器学习 Mahout
列式存储在线数据库 HBase
元数据中心 HCatalog （可以和Pig，Hive ,MapReduce等结合使用）
工作流控制 Oozie，Cascading
数据导入导出到关系数据库 Sqoop，Flume， Hiho
数据可视化 drilldown，Intellicus
使用到的公司也非常的多
（引自： ）
【王思宽的回答(5票)】:
首先，选择Hadoop，其实是选择的的MapReduce，把大块的任务切分为若干份小任务，由集群的每台服务器来计算，最后把结果合并。
这个思想是解决的最直接的方案，一台机器放不下的数据，我用多台机器来解决。这和分治算法的思路是一致的。
那么，为什么选择Hadoop？
因为开源，免费，上万开发者维护了很多年了，资料也很多，使用起来比较容易，出了问题一般之前也有人给你踩过坑写过资料了。
当然了，国内一些实力强的大公司，喜欢自己开发一套MapReduce，其实思想都摆在那里，就是实现而已，有些公司不喜欢用Java，所以就用C、C++自己做。比如腾讯，从Google挖了一批人，来了就先搞一套自己的GFS和MapReduce，实际效果如何呢？开发了一年多，bug很多，只是靠内部关系在推，当初如果直接用Hadoop，也许没这么曲折，据了解搜搜拆分之后，也转到HBase和Hadoop了。
Apache在分布式领域除了Hadoop，还有HBase和Zookeeper这两大杀器。HBase我不太熟，Zookeeper基本是目前分布式一致协作算法里的头牌了，大公司有自己搞MapReduce的，但是自己搞分布式协作算法的不多，基本都直接用zookeeper了，为什么？因为实现起来太难太复杂。
【张宇昆的回答(2票)】:
hadoop的服务器为社区服务器，成本比较低，几乎所有人都可以使用
能够处理PB级别的杂乱无章的数据，在处理失败的储存数据后，可以使用个人认为最好的分布式计算处理，另外个人最看重的hadoop的高扩展性：计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到各类型的节点中。
高效性，能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快 （基本，可靠的一点）
高容错性，能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。脱离落后的人工处理系统，拜托复杂的环境和不确定性。
【谢美龙的回答(2票)】:
大数据方面，Google是技术标杆。Mapreduce的思想就是从Google那里传出来的，Hadoop是其开源实现。既然Google都用这种技术，而且Hadoop是Apache 下的项目，正所谓大树底下好乘凉，所以大家也就放心使用了。这是它被广泛使用的真正起因。
之后使用起来确实能解决问题，社区环境也不错，其他优点上面张宇昆已经说了，于是使用的就越来越广。但现在像spark，storm等一些实时性更好的方案也发展的不错，但大多数数据分析任务对实时性要求并不是很高，所以Mapreduce的形式就足够了，而且难度不是太高，很多应届生也能参与其中。
【张十七的回答(1票)】:
首先从应用场景方面，数据积累越来越多的不限于传统数据库，而包括了文本、多媒体等资源，这些数据形式的处理是基于数据库的数据仓库或者传统分析软件的弱项。
再者从应对数据量的增长带来的压力方面，HADOOP的存储与计算能力可水平扩张，能力边界不明显（实际上因为具体的技术原因是有规模限制的，但是比起传统方案来已经好过太多）。
第三从应用环境搭建维护的成本方面，其对硬件要求较低，不需要为其配置传统高端计算、存储，且因为可水平扩展的原因，规模成本可随着需求逐步增加，避免一次性投资风险。
第四从技术成熟度方面，HADOOP社区活跃，软件进化较快，从业人员供应相对较多，且有相对较多的真实应用案例，这使得应用风险相对较低。
基于以上这些原因，在做软件选型的时候，HADOOP无疑是目前相对最经济可靠的方案。
【猪猪的回答(1票)】:
谢邀！这是个好问题，试着通俗易懂地说说，欢迎讨论。hadoop现在很红火，大数据也是，现在是个公司只要有点能号称“大数据”的数据量，都紧跟时代要搞大数据分析，怎么搞呢，首先想到的就是hadoop了。如果说为什么现在很多公司都基于hadoop方案搞大数据业务，是因为它太有名了，太流行，大家都用，至少都去尝试。
如果问hadoop是怎么红火起来的，这就要说说历史了。08年我们开始搞hadoop，那时候互联网还在oracle，对于hadoop这玩意到底行不行，我们心里说实话没有底。google是当时我们几乎唯一的信心来源，想想自己用的gmail、google搜索、google地图等大数据业务还不错，google号称有多少多少节点的大集群，而hadoop就是模仿google做的，这条路应该还是可行的。
后来互联网开始尝试hadoop，越来越多的国内外案例涌来，信心来源也越来越丰富，问题已经不是hadoop能不能用，而是是否适合用hadoop了。很快，大家不满足于只是hadoop，一系列衍生项目提出来，满足各种附加需求。同时，大家也很快发现了mapreduce不能解决所有问题，只适合离线批量处理场景，各种解决其他oracle解决不了的问题的方案应运而生。
从传统数据库数据仓库这边看，一方面吃着现有的蛋糕，另一方面也一直在尝试数据量更大、扩展性更好的解决方案，从share-everything到share-storage到share-nothing，比如现在的MPP解决方案，也在大数据业务中分了一杯羹。不过数据库基因的解决方案，还是要面临扩展性的问题，我们的经验是大概百节点级别，远远不如hadoop的扩展性。
hadoop最伟大的地方，严格说是google的伟大，就是在扩展性瓶颈方面的突破了。扩展性一直是所谓大数据（以前叫海量数据）处理的瓶颈，扩展性上去了，有更多机器来干活，那同时能干的活也就多了嘛。以前处理海量数据的思路，是搞一台超级牛的机器，比如高性能计算机，比如大型机、小型机；后来一台机器怎么也不够用了，就搞个几台连起来一起用，比如网格，比如分布式数据库数据仓库，不过这扩展性也就是几台十几台级别的，再多也无法提高了；而hadoop，放弃磁盘阵列而使用本地硬盘作为存储，使得网络连接方式大大简化，从软件层面来解决很多硬件问题，比如硬盘故障，减少对硬件的依赖，这些保证了hadoop甩出其他方案几个量级的扩展性能，人类看到了处理大数据的曙光。
随着web2.0、web3.0、移动互联网、物联网等等事物的兴起，人们创造了更多的数据，收集更多数据成为可能，业务的需求也促进了大数据技术包括hadoop的发展。毕竟，得数据能被很好的收集、整理，才有被进一步融合、分析、应用、创造价值的可能。
hadoop以及大数据技术发展到现在，最重要的是怎么用好这些技术，如何选择合适的技术方案来解决需要的问题，有必要时，如何混搭多种技术方案，以及，对于某个技术方案，如何优化使得针对特定应用场景的效果最佳。这需要广大从业者不断摸索、积累。
【吴昊的回答(0票)】:
从领导的角度，跟上大数据时代潮流，广泛认可的可线性扩展的技术架构，产品更有亮点；实际上它确实一定程度解决了IO瓶颈且已入手，但是领导必须认识到学习曲线先缓后陡，且维持一个强大的团队非常重要
从技术的角度，健壮的分布式实现，易于上手的MR原语，丰富的接口框架衔接只擅长SQL等上层语言的同学进入这个领域；况且前景很好~
从成本的角度，入手确实门槛很低~后续成本仁者见仁智者见智
【fw7777的回答(0票)】:
很多选择，看着别人选择hadoop，可能选择hadoop，而且使用起来还凑合，就用hadoop了。
【王晓华的回答(0票)】:
免费，简单，不需要学习额外知识。
【知乎用户的回答(0票)】:
开源，免费，成名早，让人充满挫败感的bug少。
曾经比较过一些类似的产品，在安装阶段就被挫败了。安装成功能使用，但是名声又没有hadoop大，为了跳槽考虑，还是随大流吧。
【卢东明的回答(0票)】:
理性地说，很多大数据的业务涉及大量非结构化数据，传统的关系型数据库无法有效解决，利用Hadoop的方案至少可以解决存储的问题。
但同时有很多非理性的原因，比如大家盲目的追捧类似Google，Facebook等公司的一些解决方案。实际上Hadoop在解决大量的非结构化数据存储的问题上是有优越性的，但同时在数据的深度挖掘、灵活分析、灵活查询的角度上是有很多不足的。请大家根据具体情况审慎选择数据库工具，现在很多数据应用都已经不再是单一数据库产品可以圆满的解决了，通常需要多种数据库产品混合配合使用。
【马骏的回答(0票)】:
1. 可处理的数据量大。大型互联网公司，单个集群每天要处理的数据量在几十T以上，总容量几百P。这样的数据规模，关系型数据库完全没有能力做。而Hadoop只要机器资源足够就行了，性能基本上线性扩展。集群管理也比较容易。
2. 生态圈完整，海量免费工具。感谢google,facebook等公司的贡献，Hadoop有非常多简单好用的组件。Hive可以让稍微有点数据库经验的人，很快上手开发。FlumeJava让M/R编写和优化也简单了很多。其他不一一列举了。总之就是国外公司已经搞好了一大堆简单好用的东西，免费拿过来用很爽。
3 集群搭建成本低。这个要感谢Cloudera的贡献，想当年搭个hadoop集群还是挺困难的，搞过的同学都懂，无数坑，坑爆卵。而现在搭个几十台的CDH集群，比较容易了，国内大多数集群规模不大的公司，都用的CDH。硬件成本也低，4万1台的服务器，搭个50台的集群，处理能力和容量已经相当不错了，200万如果去买Oracle能买个毛呢。。不过如果要搭上千台的集群，开发成本还是挺高的，国内人也不好招，全被大公司包了。
【casazhang的回答(0票)】:
现在也有公司开始用spark，比如intel和淘宝
【billlee的回答(0票)】:
首先先说两个常识。
任何技术的产生都是为了解决问题。
任何技术的产生都不是凭空的，都是以其他技术或者思想为基础的。
其次，不要过度夸大某些技术和神话某些技术。
接着说题主的问题。
提到Hadoop就要提到Goolge，不但要提到Google，还要提到IBM。
在那个没有Hadoop的时代，大家是怎么处理大量数据的呢？IBM的大型机是一个很不错的解决方案。
中国的银行系统目前很大一部分还在大型机上。但是大型机太贵了，实在是太贵了。
于是Google这个颠覆者来到了这个世界上，其实分布式计算的思想早就有了，Google只不过是把它简化了而已。
没错，是简化了。
以前的分布式计算很大力气都花费在每个节点的计算同步和节点间数据交换上面。
建立这样一个系统实在是太复杂了，于是很多人放弃了。即便是有些人成功的建立起了一个小型的系统，但是将其搬到大量节点上也是有很多的问题。
于是分布式计算实际上还是处于实验环境中，或者小范围的使用。
于是Google来了，经过谨慎的思考，Google的工程师们发现实际上使用一个简单得分布式计算模型MapReduce就能完成他们的需求。
毕竟他们当时的需求还很简单。
而且那个时候的Google毕竟还不像现在这么有钱，能省一点是一点，能用PC的就别上大型机了。
反正存的也就是一些网页，又不是用户的真金白银。
然后他们就搞了一个MapReduce。然后就写了一篇关于这种计算方法的论文。
有了思想，而且有了Google这么大数据量的数据验证，copy技术就easy了。于是大家就开始搞，然后大家就搞出来一个Hadoop。
然后发现这玩意还真不错，几台机器就能搞，几十台也能用，公司大了，几百台，几千台也OK。
其实这个玩意那个时候还真没前面几位回答的那么复杂和神秘，我知道有个小公司就是自己的系统。
其实腾讯等公司也有自己存储系统。只是不叫这个而且没有开源而已。
我现在公司有个team做云计算的，自己也用C++弄了一个出来。
真的没有那么神秘。
既然说到没那么复杂了，为啥大家还对Hadoop趋之若鹜呢，以至于做大数据的没写过MR代码，你都不好意思和人打招呼。
最大的原因我觉得就是Hadoop是一个正确的时间出生，然后形成了一个事实的标准。
既然有人做了轮子，自己又何必再搞一套。
不要高看我们码农，大部分码农其实是很懒的，能搞过来直接用，谁还吃多了编一套。
有那空多看两个岛国妹子，追求一下唯美的艺术比啥不强。
于是乎Hadoop就有了社区，然后就有了生态，然后就有了一群人摇旗呐喊。
然后Hadoop就慢慢成了大数据分布式计算领域的No1.
既然都是事实标准了，那么接下来的一切就顺理成章了。
他也就成了大多数公司的解决方案。
【陆星光的回答(0票)】:
谢邀，个人觉得主要有以下几方面原因：
1. 成本低， hadoop开源，对机器要求低，所以成本低。
2. 有完善的生态环境，有良好的社区支持，也形成了良好的生态环境，各种周边的工作如pig, hive oozie等都很完善。
3. 相较于其他的大数据系统，hadoop的从业人员最多，会有马太效应的成分在里面。
【tonykong的回答(0票)】:
hadoop在互联网领域应用广泛起来个人认为主要以下几点：
1. hadoop处理大数据量确实存在优势,易应用,成本低。
2. 互联网的数据不是特别的敏感。
3. 国内外互联网公司有成熟的应用案例，一定程度上促进了国内的互联网公司的应用。
【谭卫国的回答(0票)】:
这是技术趋势，Hadoop实际上已经没有前两年那么热了，现在热的是Spark和Dremel的开源实现。
归根到底是Hadoop确实解决了实际问题，包括廉价的海量数据存储HDFS、扩展性好的MR分布式计算框架，都是解决了工业界的具体问题。
另外Hadoop的生态环境确实比较好，很多衍生项目如Hive、Pig、Mahout等，社区活跃，不火才怪。
但需要说明的是Hadoop不是万能的，也有它合适的应用场景，所以才有了Spark这些新开源项目的存在。
【王茂军的回答(0票)】:
Hadoop可以做什么？
1 离线数据分析，例如互联网用户行为日志分析、金融行业的信用评估与风险控制；
2 可扩展的数据存储，可以看成是EMC存储的一种替代方案。
Hadoop做不了什么？
1 速度比较低，不适合做实时查询，比如在一些网站中取代 OracleMysql等传统的关系型数据库。即便是 Hbase也不行，速度依然很低。话说Storm可以吗？不行。Storm是做实时流计算的，用于取代 OracleMysql等传统的关系型数据库依然不行。
当前如火如荼的大数据能够替代 OracleMysql等传统的关系型数据库吗？
1 淘宝的OceanBase（开源、免费）也许可以。
2 Apache Spark（开源、免费、基于内存）也许也可以。
3 国内也有结合传统关系型数据库优势与大数据理论优势的产品（引跑的DBOne, 一款商业产品，类似OceanBase,我们正在使用。比较担心其在事物方面的苍白）
Hadoop为什么这么火？
1 开源、免费、实用、省钱。
2 追风、炒作。
【xavierduan的回答(0票)】:
Hadoop入手相对容易，支撑资源多~
【武佳斌的回答(0票)】:
hadoop是一个生态系统, 里面有非常多的资源可以使用, hadoop本身提供了分布式系统中最重要的两个东西: 分布式存储(HDFS)和分布式计算(MapReduce). 简单易用, 成本也比较低, 容错容灾也做得很不错, 生态系统现在发展得已经非常成熟了.
hadoop目前已经是被业内验证过的可靠的一种分布式解决方案, 配合hive, hbase等可以提供大数据计算和存储. 而且开源的大数据解决方案也不止这一种, hadoop是目前业界普遍使用的一个系统, 用户多, 遇到问题的时候解决起来方便, 采用什么大数据处理方式都好, 都是满足各自的业务需求, hadoop可以非常好地满足对于实时性要求不是很高的系统, 比如日志存储和处理, 业务报表的产出等. 对于实时性较高的系统可以考虑impala等.
hadoop作为成熟的开源解决方案, 成本也是相对较低的, 通过hive等可以实现ad-hoc查询.
大数据在很多情况有这样的特点, 就是本身结构简单, 但是数据量很大, 比如日志, 用普通的关系型数据库很难保存如此大量的数据, hadoop就是解决这类问题的.
小公司很多时候都不需要用hadoop就可以解决业务问题, 可能是跟风吧, 也跟着搞, 其实本身没多大必要. 大公司的数据量确实需要hadoop来解决, 集群规模也相对较大.
无论是用什么方案, 其实解决了公司的业务需求就是好办法.
&&&&&本文固定链接:
【上一篇】
【下一篇】
您可能还会对这些文章感兴趣！
最新日志热评日志随机日志您好：[] []
DELL存储的医院数据资产“大一统”解决之道
发表于：06年05月12日 10:38 [原创]
[导读]经过对设备性能、系统稳定性、可扩展性、易管理性等各方面因素的综合考察，2004年9月，院方最终选用了戴尔的整套存储方案，具体包括2台DELL|EMC CX300光纤盘阵与1台戴尔PV160T带库，它们分别承担起存储、备份和容灾的功能，共同为院方构建了一个“分类存储、一体备份、重点容灾”的医疗数据中心。
&&&&无锡市第一人民医院应用戴尔设备建设“分类存储、一体备份、重点容灾”的医疗数据中心
&&&&客户需求：无锡市第一人民医院计划引进存储、备份和容灾设备，建设一个支撑“HIS、PACS、电子病历和社会保险”等四大核心医疗业务系统的数据中心。
&&&&解决方案：包括DELL|EMC CX300光纤盘阵和PV160T带库在内的戴尔存储设施成功入选，它们共同为医院建设了一个“分类存储、一体备份、重点容灾”的医疗数据中心。
&&&&应用效果：在上述戴尔存储设施的强有力支撑下，数据中心的建设取得了成功。
&&&&医疗业务系统全面上线
&&&&无锡市第一人民医院创办于1927年，至今已有80多年的历史。多年来，该院在泌尿外科、血液科、心血管内科等专业领域积累了非常雄厚的医疗技术力量；特别是在人工起搏、肝肾移植等一批尖端医疗项目上，该院已达到国内先进水平。在信息化建设方面，无锡市第一人民医院同样走在国内同行的前列。近年来，该院已先后建成了“医院信息系统（HIS）”、“医疗影像存储与传输系统（PACS）”、“电子病历系统”、“社会保险系统”等几大核心医疗业务系统。
&&&&其中，“医院信息系统”是医院的管理中枢，它包含财务、人事、住院、药品、门诊、医技、病程、收费等多个子系统，同时承担着“临床管理”与“行政管理”的双重使命；“医疗影像系统”是医院的影像中心，它承担着从CT、X光机等各类成像检查设备中采集影像资料、对这些资料加以处理和存储、并为一线医师提供查询服务的使命；“电子病历系统”是医院的病历中心，它详细记录了患者的治疗方案和治疗过程，既为医院积累了宝贵的治疗经验，又为处理医患纠纷提供了不可或缺的证明文件；而“社会保险系统”则连通了医院与社保部门的业务后台，它为医院接诊并服务好广大社保患者提供了支持。
&&&&数据资产管理问题凸显
&&&&HIS、PACS和电子病历等系统是在不同时期分批建成的，各系统的数据处于分散存储状态，不仅如此，每个系统所采取的存储方式与存储介质也各不相同，有些存储介质已经落后。随着上述系统应用规模的不断扩大，它们在数据管理方面的问题日益凸显出来：
&&&&首先，存储后台容量不足，数据调用不便。以PACS为例，该系统上线后，数据规模呈几何级数增长。按照原来的存储方式，这些数据被存放在系统外挂的盘阵之中。由于盘阵容量有限，因此不得不定期对盘阵进行清理，并将历史文件采取刻光盘的方式加以保存。一旦医生需查询这些历史文件，就只能到光盘库中去检索，这使他们感到非常不方便。
&&&&其次，链路结构相对落后，系统稳定堪忧。上述系统原来的存储后台多采用单独SCSI链路，这种链路方式不仅带宽较低，而且由于没有冗余，可用性也较差。仍以PACS系统为例，有些医生反映，该系统在同时调出多个大尺寸影像文件时，有时会因链路问题而发生迟滞。
&&&&最后，分散存储的模式，严重影响了数据资产的管理效率。从系统维护的角度看，每个系统的数据都要单独备份，这样的重复操作不仅费时费力，而且难以给各系统的数据资产提供同一水平的保护；从资源调配的角度看，不同系统的存储资源和备份资源无法相互调剂，因而造成了厚此薄彼、资源浪费的现象。
&&&&就上述三个问题，医院信息中心指出：“医院的信息化工作走到今天，随着各类应用系统的不断增加与日益成熟，我们越来越感到：必须对数据资产的管理有一个通盘的考虑，有一个集中管理方案。这样做，不仅有利于数据的安全和系统的稳定，而且能够为我们将来对这些数据资产进行深度挖掘、实现知识管理，奠定坚实的基础。”
&&&&“分类存储、一体备份、重点容灾”的管理方案
&&&&为了实现集中管理，医院信息中心首先对上述四个系统及其后台数据进行了整体规划。他们发现，这些数据按其自身特征可划分为“PACS数据”和“非PACS数据”等两大类，前者专指PACS系统的数据，后者包括HIS系统、电子病历系统与社会保险系统的全部数据。
&&&&这两类数据的差别很大：前者主要是多媒体文档，其并发访问量小，但文件尺寸比较大；后者包括传统文档和数据，其并发访问量大，但数据尺寸小。从系统本身的角度来看也是如此：无论是持续可用性、数据安全性，还是响应速度，其它三个系统都比PACS系统的要求高。
&&&&考虑到两类数据、两类系统的上述差别，信息中心最终制定了“分类存储、一体备份、重点容灾”的数据资源集中管理方案。具体而言，就是对“PACS数据”和“非PACS数据”分别加以存储，统一实施备份；与此同时，只对其中“重要且读写频繁”的“非PACS数据”实施异地容灾。在此基础上，建设一个涵盖上述四大系统的医疗数据中心。
&&&&该院信息中心负责人在解释这一思路时说：“数据集中管理的核心是要把各种数据资产作为一个整体给予通盘考虑，而不是简单地把它们集中存储在一起。从我们的具体情况来看，两类数据对系统I/O的要求是不同的，如果硬放在一起，在应用高峰的时候，它们可能会相互影响。正是基于这样的考虑，我们为两类数据建设了不同的存储后台。”
&&&&戴尔全面担纲硬件平台建设
&&&&上述思路确定后，无锡市第一人民医院开始了存储、备份与容灾设备的选型工作。经过对设备性能、系统稳定性、可扩展性、易管理性等各方面因素的综合考察，2004年9月，院方最终选用了戴尔的整套存储方案，具体包括2台DELL|EMC CX300光纤盘阵与1台戴尔PV160T带库，它们分别承担起存储、备份和容灾的功能，共同为院方构建了一个“分类存储、一体备份、重点容灾”的医疗数据中心。
&&&&该数据中心的四个系统（HIS、PACS、病历、社保）共使用了8台主机，其中：HIS系统采用医院原有的2台其它品牌服务器担任前端主机；PACS系统采用2台戴尔PE6650服务器担任前端主机；电子病历系统采用1台戴尔PE6650服务器与1台医院原有的其它品牌服务器共同担任前端主机；社会保险系统采用2台新引进的戴尔PE2850服务器担任前端主机。每台主机均安装了3块HBA卡，以便与存储后台连接。
&&&&存储后台的具体情况如下：
&&&&第一部分：分类存储
&&&&以1套新引进的DELL|EMC CX300光纤盘阵，外加1套医院原有的其它品牌光纤盘阵，分别担任“非PACS数据”与“PACS数据”的存储后台，这两套盘阵通过2台BROCADE 8口光纤交换机（DS-8B2）与前端的四个系统、8台主机相连接，构成全光纤的SAN结构。
&&&&其中，DELL|EMC CX300存储容量约5TB，它通过2台交换机，与前端“HIS系统”、“电子病历系统”、“社会保险系统”的6台主机构成了全冗余的连接，这3个系统的后台数据（非PACS数据）全部存储于本套CX300之中。
&&&&医院原有的1套光纤盘阵，存储容量约2TB，它通过1台交换机，与前端PACS系统的2台主机相连接，PACS数据全部存入其中。
&&&&第二部分：一体备份
&&&&以1套新引进的戴尔PV160T带库全面承担“非PASC数据”与“PACS数据”的备份任务。为了使数据的备份流程独立于其存储流程，确保链路的冗余，院方在存储SAN之外，用1台16口BROCADE光纤交换机将8台前端主机与PV160T直接连通起来，从而搭建了一个专用的备份网络。
&&&&整个备份过程由8台前端主机上安装的Veritas SAN备份软件直接加以指挥和控制。由于“非PACS数据”和“PACS数据”在增长速度、访问频度、存储介质容量上存在明显差异，院方对它们采取了不同的备份策略：
&&&&“PACS数据”：由于它的访问频度低、数据增长快、存储介质容量有限（2TB），因而对它采取了“逐日迁移、按月备份”的策略。具体而言，就是每天从PACS后台盘阵向PV160T进行数据迁移，以降低存储后台的压力；每月做一次全面备份，以确保数据的安全和完整。
&&&&数据迁移和备份均在夜间进行。每天晚上，PACS系统的两台前端主机会对存储后台进行自动扫描，一旦发现其中的数据总量已经超过总存储容量的70%，且包含有保存期超过60天的数据，就会自动发起迁移程序，将那些同时符合上述两项条件的数据迁移到PV160T之中。迁移后的数据会在原存储后台中留下指针数据，到了月末最后一天的晚上，系统会将本月的所有指针数据备份到PV160T之中。
&&&&“非PACS数据”：由于它的检索频度高、数据增长慢、存储介质容量较大（5TB），因此不需要做数据迁移；它的备份策略是：每天晚上做一次当日增量数据的备份，每周做一次全部数据的备份。
&&&&第三部分：重点容灾
&&&&鉴于“非PACS数据”不仅访问频度高，而且极为关键，院方单独为其设计了一个远程容灾备份系统，以提高这些数据的安全保护水平。该系统由1台戴尔PE2850服务器与1台DELL|EMC CX300光纤盘阵共同组成，其中，PE2850负责运行Veritas备份软件，实施备份管理，该服务器基于新一代英特尔技术的双路平台，采用了包括PCI Express I/O、DDR2内存、64位英特尔?扩展内存等一系列创新技术，更高的带宽和更强的内存寻址能力为数据密集型应用提供了更卓越的性能；CX300具体担任容灾备份的存储后台，它们处在与存储SAN不同的物理位置，通过1台BROCADE8口光纤交换机，与存储SAN相连通。
&&&&负责容灾备份的这套DELL|EMC CX300，共配载了约4个TB的存储容量。具体的备份方法是：每隔1小时，灾备系统中的PE2850服务器会自动对存储SAN进行扫描，以便对其中的“新增数据”进行文件复制和日志快照，并将复制和快照的结果保存到负责容灾备份的那台CX300之中。
&&&&整个方案拓扑图如下：
&&&&性能优异的硬件平台，贴近用户的直接服务
&&&&2004年12月，按照上述方案建设、由戴尔存储设施全面担纲的无锡市第一人民医院医疗数据中心正式上线。到目前为止，该中心已稳定运行了2个多月的时间。中心一举创造了两项第一：江苏省卫生系统内第一个采用全光纤SAN结构的医疗数据中心、国内第一个以戴尔PV160T为基础的高性能光纤通道备份系统。
&&&&从运行效果来看，该中心“分类存储、一体备份、重点容灾”的设计思路是科学的，数据中心的建设是成功的，通过对数据进行集中管理并为不同类型的数据设计不同的存储与保护方法，整个数据中心系统以最合理的投入，实现了最优化的数据处理流程与服务支持结构。
&&&&数据中心获得成功的另外一个重要因素是存储设备的正确选择。包括DELL|EMC CX300和戴尔PV160T等在内的高性能存储设备，以出色的表现为数据中心各项设计目标的最终实现，奠定了硬件方面的基础。
&&&&以担当备份重任的戴尔PV160T为例，它突出的“大容量”、“高速度”与“易管理”优势，使医院数据中心在数据备份功能方面，达到了国内领先的水平：
从容量来看，PV160T使用的LTO-2磁带，单盘不压缩可存200GB数据，压缩后可存400GB数据。无锡市第一人民医院此番引进的PV160T共有294个槽位，如果全部配满，总存储容量将高达58.8TB（不压缩）和117.6TB（压缩）。按照目前医院数据每天5GB、每年1.5TB的增长速度，这套PV160T带库在不压缩的情况下，也可供医院使用39年。
从速度来看，PV160T的磁带驱动器不仅能以每秒30MB的速度实现数据的快速备份，而且能够以极高的效率响应用户的检索请求。这种卓越的响应能力，是PV160T相比于“光盘备份”和“传统带库备份”的一个革命性进步。现在，医生如需向PV160T检索备份的PACS文件，即使在每天上午高峰时段，最多也只要1分钟就可以找到文件并将之打开。
从易管理性来看，PV160T的管理接口与管理界面都十分先进。用户可以用WEB方式对PV160T的运行状态实现远程的监控、调整和设置，而无需进入机房进行现场维护；不仅如此，PV160T还允许其内部的磁带驱动器直接连接到光纤通道交换机上，而不必使用价格昂贵的“SCSI至Fiber”通道转换器。本方案正是利用这一特征，通过连接一台16口光纤交换机，建立了一个独立、高速的备份与查询网络。 再比如分别承担着存储和容灾任务的2套DELL|EMC CX300光纤盘阵，它们不仅以强大的性能支持了数据中心的高效、稳定运行，更以卓越的可扩展性为数据中心的未来发展预留了充足的增容空间：
在处理能力上，CX300采用了800MHz的存储处理器与高达2GB的高速缓存，这样的配置为CX300快速地“处理”与“收发”数据，提供了强大的动力；在系统I/O上，CX300能够提供5万次/秒的缓冲I/O、680MB/秒的持续带宽，这两项指标对于支持HIS等OLTP型应用，具有非常重要的意义。
在优化能力上，CX300允许用户根据前端不同应用的具体需求，对系统的高速缓存进行调配，从而实现系统性能的动态优化。在本方案中，作为存储后台的CX300分别支持了3项不同的应用，医院方面非常需要在实际运行中了解不同应用的需求压力，并据此不断对CX300的缓存资源做进一步的调整。
在可扩展性上，CX300可在单一阵列中支持64台服务器，并可轻松扩容到8.8TB，这就为应用系统与数据资源的扩张奠定了基础。目前，无锡市第一人民医院已开始着手将其它一些应用系统（如医院的远程教育系统）接入本方案的SAN之中，今后本医疗数据中心将有望成为全院所有数据资产的“大一统”管理中心。
&&&&在对上述戴尔存储设备表示满意的同时，无锡市第一人民医院信息中心的刘喻主任还对戴尔的服务表示了认可，他说“此次系统集成前后经历了大约两个月的时间。为确保设备安装、调试不影响医院正常的工作秩序，我们一般选择在晚上开展工作。在整个过程中，戴尔工程师在一线为我们提供了极为认真负责的服务，这么复杂的系统一次部署成功，非常难得。”
&&&&他还指出：“部署过程中需要很多零配件，按照以往使用其它品牌的经历，要么会多出一堆，要么会漏掉几个，总之很难恰到好处。这次我们也担心会出现这种情况。然而，戴尔计算得特别精确，大到各种驱动器，小到一根连线，最后是一个不多，一个不少。更重要的是，这些零配件都是在厦门经过测试后才发送过来的，节省了我们很多时间。”
[责任编辑：DOIT]
DOIT传媒近期正式宣布，由其自主开发的全新一代会议活动社交应用“易会”于今日正式发布上线，并将在近日登录各大Android应用市场。
华为OceanStor V3系列存储系统是面向企业级应用的新一代统一存储产品。在功能、性能、效率、可靠性和易用性上都达到业界领先水平，很好的满足了大型数据库OLTP/OLAP、文件共享、云计算等各种应用下的数据存储需求。
12月15日，中国闪存联盟成立，同时IBM Flash System卓越中心正式启动
DOIT、DOSTOR、易会移动客户端播报中国存储峰会盛况。