随着 IT 互联网信息技术的飞速发展和进步. 目前大数据行业也越来越火爆, 从而导致国内大数据人才也极度缺乏, 下面介绍一下关于 Hadoop 环境中管理大数据存储技巧.
在现如今, 随着 IT 互联网信息技术的飞速发展和进步. 目前大数据行业也越来越火爆, 从而导致国内大数据人才也极度缺乏, 下面介绍一下关于 Hadoop 环境中管理大数据存储技巧.
1, 分布式存储
传统化集中式存储存在已有一段时间. 但大数据并非真的适合集中式存储架构. Hadoop 设计用于将计算更接近数据节点, 同时采用了 HDFS 文件系统的大规模横向扩展功能.
虽然, 通常解决 Hadoop 管理自身数据低效性的方案是将 Hadoop 数据存储在 SAN 上. 但这也造成了它自身性能与规模的瓶颈. 现在, 如果你把所有的数据都通过集中式 SAN 处理器进行处理, 与 Hadoop 的分布式和并行化特性相悖. 你要么针对不同的数据节点管理多个 SAN, 要么将所有的数据节点都集中到一个 SAN.
但 Hadoop 是一个分布式应用, 就应该运行在分布式存储上, 这样存储就保留了与 Hadoop 本身同样的灵活性, 不过它也要求拥抱一个软件定义存储方案, 并在商用服务器上运行, 这相比瓶颈化的 Hadoop 自然更为高效.
在这里还是要推荐下我自己建的大数据学习交流群: 529867072, 群里都是学大数据开发的, 如果你正在学习大数据 , 小编欢迎你加入, 大家都是软件开发党, 不定期分享干货(只有大数据软件开发相关的), 包括我自己整理的一份最新的大数据进阶资料和高级开发教程, 欢迎进阶中和进想深入大数据的小伙伴加入.
?2, 超融合 VS 分布式
注意, 不要混淆超融合与分布式. 某些超融合方案是分布式存储, 但通常这个术语意味着你的应用和存储都保存在同一计算节点上. 这是在试图解决数据本地化的问题, 但它会造成太多资源争用. 这个 Hadoop 应用和存储平台会争用相同的内存和 CPU.Hadoop 运行在专有应用层, 分布式存储运行在专有存储层这样会更好. 之后, 利用缓存和分层来解决数据本地化并补偿网络性能损失.
3, 避免控制器瓶颈(ControllerChokePoint)
实现目标的一个重要方面就是 -- 避免通过单个点例如一个传统控制器来处理数据. 反之, 要确保存储平台并行化, 性能可以得到显著提升.
此外, 这个方案提供了增量扩展性. 为数据湖添加功能跟往里面扔 x86 服务器一样简单. 一个分布式存储平台如有需要将自动添加功能并重新调整数据.
4, 删重和压缩
掌握大数据的关键是删重和压缩技术. 通常大数据集内会有 70% 到 90% 的数据简化. 以 PB 容量计, 能节约数万美元的磁盘成本. 现代平台提供内联 (对比后期处理) 删重和压缩, 大大降低了存储数据所需能力.
?5, 合并 Hadoop 发行版
很多大型企业拥有多个 Hadoop 发行版本. 可能是开发者需要或是企业部门已经适应了不同版本. 无论如何最终往往要对这些集群的维护与运营. 一旦海量数据真正开始影响一家企业时, 多个 Hadoop 发行版存储就会导致低效性. 我们可以通过创建一个单一, 可删重和压缩的数据湖获取数据效率
?6, 虚拟化 Hadoop
虚拟化已经席卷企业级市场. 很多地区超过 80% 的物理服务器现在是虚拟化的. 但也仍有很多企业因为性能和数据本地化问题对虚拟化 Hadoop 避而不谈.
7, 创建弹性数据湖
创建数据湖并不容易, 但大数据存储可能会有需求. 我们有很多种方法来做这件事, 但哪一种是正确的? 这个正确的架构应该是一个动态, 弹性的数据湖, 可以以多种格式 (架构化, 非结构化, 半结构化) 存储所有资源的数据. 更重要的是, 它必须支持应用不在远程资源上而是在本地数据资源上执行.
不幸的是, 传统架构和应用 (也就是非分布式) 并不尽如人意. 随着数据集越来越大, 将应用迁移到数据不可避免, 而因为延迟太长也无法倒置.
理想的数据湖基础架构会实现数据单一副本的存储, 而且有应用在单一数据资源上执行, 无需迁移数据或制作副本.
8, 整合分析
分析并不是一个新功能, 它已经在传统 RDBMS 环境中存在多年. 不同的是基于开源应用的出现, 以及数据库表单和社交媒体, 非结构化数据资源 (比如, 维基百科) 的整合能力. 关键在于将多个数据类型和格式整合成一个标准的能力, 有利于更轻松和一致地实现可视化与报告制作. 合适的工具也对分析 / 商业智能项目的成功至关重要.
来源: http://www.bubuko.com/infodetail-3092753.html