管理大数据存储的十大技巧
在1990年,每一台应用服务器都倾向拥有直连式系统(DAS)。SAN的构建则是为了更大的规模和更高的效率提供共享的池存储。Hadoop已经逆转了这一趋势回归DAS。每一个Hadoop集群都拥有自身的——虽然是横向扩展型——直连式存储,这有助于Hadoop管理数据本地化,但也放弃了共享存储的规模和效率。如果你拥有多个实例或Hadoop发行版,那么你就将得到多个横向扩展的存储集群。
而我们所遇到的最大挑战是平衡数据本地化与规模效率,这是一个鱼与熊掌兼得的话题。
数据本地化是为了确保大数据集存储在计算节点附近便于分析。对于Hadoop,这意味着管理数据节点,向MapReduce提供存储以便充分执行分析。它实用有效但也出现了大数据存储集群的独立操作问题。以下十项是Hadoop环境中管理大数据存储技巧。
1.分布式存储
传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点,同时采用了HDFS文件系统的大规模横向扩展功能。
虽然,通常解决Hadoop管理自身数据低效性的方案是将Hadoop 数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在,如果你把所有的数据都通过集中式SAN处理器进行处理,与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN,要么将所有的数据节点都集中到一个SAN。
但Hadoop是一个分布式应用,就应该运行在分布式存储上,这样存储就保留了与Hadoop本身同样的灵活性,不过它也要求拥抱一个软件定义存储方案,并在商用服务器上运行,这相比瓶颈化的Hadoop自然更为高效。
2.超融合VS分布式
注意,不要混淆超融合与分布式。某些超融合方案是分布式存储,但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题,但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层,分布式存储运行在专有存储层这样会更好。之后,利用缓存和分层来解决数据本地化并补偿网络性能损失。
3.避免控制器瓶颈(Controller Choke Point)
实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之,要确保存储平台并行化,性能可以得到显著提升。
此外,这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。
4.删重和压缩
掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计,能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩,大大降低了存储数据所需能力。
5.合并Hadoop发行版
很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时,多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一,可删重和压缩的数据湖获取数据效率
6.虚拟化Hadoop
虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。
7.创建弹性数据湖
创建数据湖并不容易,但大数据存储可能会有需求。我们有很多种方法来做这件事,但哪一种是正确的?这个正确的架构应该是一个动态,弹性的数据湖,可以以多种格式(架构化,非结构化,半结构化)存储所有资源的数据。更重要的是,它必须支持应用不在远程资源上而是在本地数据资源上执行。
不幸的是,传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大,将应用迁移到数据不可避免,而因为延迟太长也无法倒置。
理想的数据湖基础架构会实现数据单一副本的存储,而且有应用在单一数据资源上执行,无需迁移数据或制作副本
8.整合分析
分析并不是一个新功能,它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现,以及数据库表单和社交媒体,非结构化数据资源(比如,维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力,有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。
9. 大数据遇见大视频
大数据存储问题已经让人有些焦头烂额了,现在还出现了大视频现象。比如,企业为了安全以及操作和工业效率逐渐趋于使用视频监控,简化流量管理,支持法规遵从性和几个其它的使用案例。很短时间内这些资源将产生大量的内容,大量必须要处理的内容。如果没有专业的存储解决方案很可能会导致视频丢失和质量降低的问题。
10.没有绝对的赢家
Hadoop的确取得了一些进展。那么随着大数据存储遍地开花,它是否会成为赢家,力压其它方案,其实不然。
比如,基于SAN的传统架构在短期内不可取代,因为它们拥有OLTP,100%可用性需求的内在优势。所以最理想的办法是将超融合平台与分布式文件系统和分析软件整合在一起。而成功的最主要因素则是存储的可扩展性因素。
本文作者:佚名
来源:51CTO

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
“与中国同创”支持中国成为创新的第一现场
今年三月在北京举办的"中国发展高层论坛"上,全球的各企业领导者和经济思想家们围绕中国的"十三五规划"进行了较深入的讨论,其中一个中心话题就是怎样支持中国经济在保持一定速度的前提下切换方式,实现更健康的成长。参会者有一个共识,就是中国经济的转型和长期繁荣一定要在开放与合作的国际环境下进行。特别是在全球科技新一轮革命的背景下,开放环境下的技术创新合作对于中国经济的健康成长来说,可以起到"奇兵"的作用。 这种创新合作已经在信息技术架构方案领域开花结果,成果辐射众多行业。今天,在中国,开放创新正被引入一个全新的技术发展时代。开放创新可以让各企业、政府以及组织共享知识产权、创意以及人员,并通过和本土及全球合作伙伴协作,帮助中国加速技术应用。 例如,IBM在2014年启动了"绿色地平线"计划,与北京市政府、国网冀北电力有限公司等本土合作伙伴开展了合作。"绿色地平线"采用了最前沿的认知计算、物联网以及大数据分析技术,帮助北京政府更好地管理空气质量。这个项目能帮助政府和企业领导者做出更好的环境管理决策,保障公民更健康地生活,同时,为中国得可持续发展保驾护航。 类似的科技合作在很多其他领域也在展开。在制...
- 下一篇
如何制定数据中心冗余计划?
如果想要确保虚拟基础架构的高可用性,无疑需要冗余技术,下面我们的专家顾问将会介绍企业应该如何选择最适合自己的冗余等级。 如果企业想要实现弹性机制从而确保系统高可用性,那么为虚拟基础架构选择恰当的冗余等级至关重要,但是想要完全了解企业当前需要哪种等级的冗余架构非常困难。对于部分企业来说,N+1的冗余计划足够实现系统弹性并且提供稳定的性能表现。而其他企业可能需要更高的冗余等级,也许会选择N+2或者N+1+1等方案。 那么企业应该如何确定自己的数据中心究竟需要哪种等级的冗余机制呢?为此我们联系了几位行业专家,就企业应该考虑哪些方面以及何时做出决定等方面请他们分享各自观点。 Alastair Cooke——独立分析师兼顾问 企业可以在应用和基础架构等多个层次实现冗余机制。通常,冗余机制距离应用层越近,系统的高可用性就越好。一个动态、负载均衡的web服务器集群无疑要比一台虚拟机当中的单个web服务器可用性更高。而主要问题在于每个应用都使用不同的弹性机制以及工具集。因此如果企业从更低的硬件和基础架构层提供弹性机制,那么不同应用就能够使用相同的工具集了。是否在应用层实现冗余还需要考虑管理弹性机制所需...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- MySQL8.0.19开启GTID主从同步CentOS8