盘点管理大数据存储的十大技巧
在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环境中存在多年。不同的是基于开源应用的出现,以及数据库表单和社交媒体,非结构化数据资源(比如,维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力,有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。
- 大数据遇见大视频
大数据存储问题已经让人有些焦头烂额了,现在还出现了大视频现象。比如,企业为了安全以及操作和工业效率逐渐趋于使用视频监控,简化流量管理,支持法规遵从性和几个其它的使用案例。很短时间内这些资源将产生大量的内容,大量必须要处理的内容。如果没有专业的存储解决方案很可能会导致视频丢失和质量降低的问题。
10.没有绝对的赢家
Hadoop的确取得了一些进展。那么随着大数据存储遍地开花,它是否会成为赢家,力压其它方案,其实不然。
比如,基于SAN的传统架构在短期内不可取代,因为它们拥有OLTP,100%可用性需求的内在优势。所以最理想的办法是将超融合平台与分布式文件系统和分析软件整合在一起。而成功的最主要因素则是存储的可扩展性因素。
原文发布时间为:2016年10月10日
本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SPDK,软件定义存储的催化剂
去年第四季度开始,XSKY团队[3]开始研究英特尔向社区开源的SPDK。福叔在学习之中发现,就像软件定义网络(SDN)和网络功能虚拟化(NFV)中的性能利器DPDK,SPDK也极有机会给SDS领域带来革命性的影响。如果朋友们不知道DPDK是干什么的,没有关系,我将在以后抽时间给大家分享下DPDK的学习心得,以及我们把它用在存储领域的一些想法,今天先看看SPDK。(这篇文章的图和大部分内容来自英特尔官方网站公开的技术资料[1][2],加上自己的理解,原英文部分内容的著作权归英特尔公司所有……) 技术背景 固态硬盘正在迅速扩展它在数据中心中的份额,相较于传统存储介质,新的闪存介质具有性能,耗电,机架空间等等方面的优势。随着更新的闪存介质投入市场(如3D NAND),这些优势还在不断扩大。 用户在集成新一代的NVMe设备,如英特尔®P3700这样的“性能怪兽”时,会碰到很大的挑战。因为NVMe硬盘的吞吐量和时延表现太好了(2GB/s左右的读写带宽,45万的每秒随机读和17万的每秒随机写,20μm级别的时延)——就IOPS而言,比传统SAS或SATA温氏磁盘快上千倍,也比之前的SATA SSD...
- 下一篇
在N多气象服务构成的"疯狂数据城" AS8000挑起大梁
知道仅仅是简单的"明天有雨"的预报,气象部门要处理多少数据么?几十G,几千G?NO,气象部门告诉我们,真实处理数据量往往达到了TB甚至PB的级别!这就不难理解西安市气象局为啥把对高性能存储看的很重了。西安市气象局采用了浪潮AS8000-M2虚拟化存储系统,构建了高性能存储系统平台,让气象预测更加靠谱。 西安市气象局中的"疯狂数据城" 西安市气象局的业务包括天气预报、气候预测、农业气象预报服务、空气质量预报、人工影响天气等等,给西安市的经济与社会运行作出了巨大的贡献。在为西安市提供气象信息的过程中,西安市气象局发现,社会经济运行对于气象信息的要求正在以惊人速度成长着:农业生产需要预知降雨温度,环境预测需要了解风向变化,防洪防涝需要宏观信息预测……这些开脑洞的服务带来的大量数据,足以构成一个气象界的"疯狂数据城"了。要满足这些需求,就必须升级现有存储基础设施,把气象信息预测的速度与准确度再提高一个level。 大量气象服务带来"疯狂数据城" 在新存储系统建设之前,西安市气象局已经有一套配置容量为48T的存储系统,听起来这个数字虽然很庞大,但是一旦与气象预测所产生的数据量比起来,这点容量就小...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7,CentOS8安装Elasticsearch6.8.6