你可能不知道大数据开发的10个技巧

前言

“当你不创造东西时,你只会根据自己的感觉而不是能力去看待问题。” – WhyTheLuckyStiff

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%可用性需求的内在优势。所以最理想的办法是将超融合平台与分布式文件系统和分析软件整合在一起。而成功的最主要因素则是存储的可扩展性因素。

推荐下我自己创建的大数据学习交流Qun531629188

无论是大牛还是想转行想学习的大学生

小编我都挺欢迎,晚上20:10都有一节【免费的】大数据直播课程,专注大数据分析方法,大数据编程,大数据仓库,大数据案例,人工智能,数据挖掘都是纯干货分享,

包括我自己整理的一份最新的适合2018年学习的大数据教程,欢迎初学和进阶中的小伙伴。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PPV课数据科学社区

【平台】[Kafka系列]Kafka在大数据生态系统中的价值

? 作者 Jun Rao 为ODBMS撰写文章的转载。译者 Brian Ling,专注于三高(高性能,高稳定性,高可用性)的码农。 近几年, Apache K...

41014
来自专栏技巅

系统架构和代码实现的高可控性

2224
来自专栏魏琼东

DotNET企业架构应用实践-系统架构与性能-理论依据及相关技术

性能优化介绍       在企业应用开发领域,企业架构与性能将会是一个恒久的话题,如何提高性能、性能优化也将是一个长期和不断改进的过程,有人在硬件投入上下功夫、...

2006
来自专栏JAVA高级架构

对软件架构的一些思维脑图整理

4512
来自专栏云计算D1net

通过直接连接提高公共云的可靠性

企业可以采用直接连接,如来自AWS和Azure的直接连接,可以把数据放到公共云的快速轨道,但企业应该准备为此付出一些代价。 公共云服务需要访问网络,并且通常是通...

38110
来自专栏云计算D1net

正确估算而非过度配置公共云资源

一般来说,企业用户都希望为使用云做好准备,也就是他们不必为没有使用过的资源支付费用。本文所介绍的这些小贴士可以有助于用户正确估算他们的云实例并避免云资源的过度配...

3485
来自专栏Cloud Native - 产品级敏捷

精益敏捷开发: 轻量级度量

2016, 深圳, Ken Fang  前言:    精益敏捷开发以轻量级的文档与团队协作, 提高开发的效率。另一方面, 许多人对于精益敏捷开发在轻量级的文档下...

2098
来自专栏大数据文摘

Google停用MapReduce,高调发布Cloud Dataflow

2636
来自专栏大数据挖掘DT机器学习

大数据架构和模式(三)——理解大数据解决方案的架构层

作者:Divakar Mysore等 来源:DeveloperWorks 摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用...

3554
来自专栏云计算D1net

更快的网络+成本更低的消息=>微服务=>函数=>边缘计算

在德国柏林举办的microXchg 2017大会上,亚马逊公司技术专家Adrian Cockroft发表了一个前瞻性的演讲。Adrian Cockroft是Cl...

3674

扫码关注云+社区

领取腾讯云代金券