科研大数据最新技术探讨

上传人:艾力 文档编号:36565079 上传时间:2018-03-30 格式:PDF 页数:60 大小:4.74MB
返回 下载 相关 举报
科研大数据最新技术探讨_第1页
第1页 / 共60页
科研大数据最新技术探讨_第2页
第2页 / 共60页
科研大数据最新技术探讨_第3页
第3页 / 共60页
科研大数据最新技术探讨_第4页
第4页 / 共60页
科研大数据最新技术探讨_第5页
第5页 / 共60页
点击查看更多>>
资源描述

《科研大数据最新技术探讨》由会员分享,可在线阅读,更多相关《科研大数据最新技术探讨(60页珍藏版)》请在金锄头文库上搜索。

1、科研大数据最新技术探讨曙光信息产业股份有限公司 高级存储方案工程师 刘冠川目录大数据时代科研领域的 大数据挑战Hadoop带 来的机遇相关技术发 展趋势探讨曙光大数据 解决之道科研领域大 数据应用大数据时代什么是大数据速度数据量稳定,增长丌快持续产生数据,每年增加约60%数据量GBTB级别TBPB级别以上价值统计和报表数据挖掘,探索式分析多样化结构化数据为主半结构,非结构,多维数据4V传统数据大数据大数据是指数据集的大小超过了现有典型的数据库软件和工具处理能力,不 此同时,及时捕捉,存储,聚合,管理这些大数据以及对数据深度分析的新 技术和新能力,正在快速增长,正像预测芯片增长的摩尔定律一样。

2、-McKinsey Global Institute大数据技术驱劢力:数据爆炸性增长0.490.81.21.8200.20.40.60.811.21.41.61.822008年2009年2010年2011年近几年全球数据增长量(近几年全球数据增长量(ZB)2020年,全世界所产生的数据规模将达到今天的44倍 35ZB。大数据技术驱劢力:数据爆炸性增长加载 导入海量数据处理 数据抽取不集成深度挖掘信息交易数据行为记录数据融合数据结构化数据非结构化数据半结构化数据数据加工分析 形成决策移劢互联网物联网互联网通信网 智能终端云计算大数据大数据技术驱劢力:应用科研领域的大数据挑战科学研究范式第四范式:

3、密 集数据分析 第三范式: 仿真模拟 第二范式: 模型推演 第一范式: 实验归纳从科学范式谈起科研领域的大数据10卫星遥感、气象、天文观测、生物信息、高能物理人才缺失4V的挑战标准丌统一传统商业方案价格昂贵应用生态单薄数据共享壁垒科研界的大数据挑战Hadoop带来的机遇云计算和大数据传统信息系统三层架构PC机服务器数据库现代信息系统三层架构APP Loa dsAP P Loa dsAP P Lo adsPrivate CloudsPublic Clouds智能终端云大数据面向面向大数据大数据 数千万的文件 文件大小一般在GB至TB流式流式数据访问数据访问 写一次读多次的数据访问模式 文件创建,

4、写,关闭之后不再 修改通用通用硬件平台硬件平台 容错,快速恢复是其设计目标HDFS的设计原则HDFS基本组成 管理整个文件系统的命名空间 通过心跳维护datanode的状态元数据节点 Datablock存储池,默认有3个副本, 块大小默认64M,根据计算粒度优化 周期性将datablock的信息发给 namenode(3s)数据节点HDFS逻辑架构命令行接 口Java 原生 接口Thrift C语言FuseHttpFTPHDFS接口Mapreduce工作流程列存储的Key-Value的NoSQL数据管理系统,提供高可靠、高 性能、可伸缩和实时读写 横向扩展。通过不断增加廉价的商用服务器,来增加

5、计算 和存储能力 和HDFS、MapReduce高度集成,向上支持SQL操作 成熟的社区支持BigTable的 开源版本海量数据,没有严格的事务性要求 数据结构灵活的应用。非结构化和半结构化的松散数据 复杂处理适合的场 景HBase 为为Region server分配分配region,并负责,并负责region server负载均衡负载均衡 发现失效的发现失效的region server并重新分配其上的并重新分配其上的region GFS上的垃圾文件回收上的垃圾文件回收 处理处理schema更新请求更新请求Hmaster 维护维护Master分配给它的分配给它的region,处理,处理regi

6、on的的IO请求请求 Region server负责切分在运行过程中变得过大的负责切分在运行过程中变得过大的regionRegionServer 保证任何时候,集群中只有一个保证任何时候,集群中只有一个master 存贮所有存贮所有Region的寻址入口的寻址入口-_ROOT_和和HBase元数据元数据 实时监控实时监控Region Server的状态,将的状态,将Region server的上线和下线信息实时通知的上线和下线信息实时通知 给给MasterZooKeeper hbase访问接口访问接口 client端端cache,如,如regione的位置信息的位置信息ClientHBase基

7、本组件不符合数据库第一范式。列族包含个数可动态增加的列 唯一行关键字 无明确列名和类型数据模型支持单行批量操作的事务性语义原生的并行架构 基于关键字字典排序的统一表格实现仅能通过主键(row key)和主键的range来检索数据 单一表格,无Join操作操作方法HBase区别于RDBMS技术发展趋势探讨元数据服务器HDFSHDFS是大数是大数 据唯一选择?据唯一选择?替代方案(一): DataStax CassandraFS25CassandraFS 并 非一个完全意 义上的文件系 统,而是一个 开 源 、 NoSQL 键 值 ( key- value)商店。 元数据保持在 Cassandra

8、中, 解决HDFS元数 据单点故障问 题。扩展性更 好。替代方案(二):Ceph26分布式的元数 据服务器通过 CRUSH算法分 配文件分布。 避免元数据单 点故障和扩展 性问题。替代方案(三):Cleversafe27融 合 Hadoop 并行编程技 术。把整个 元数据分布 在集群中, 据称比HDFS 更快、更稳 定、更具扩 展性。同时 通过纠删码 技术提高存 储利用率。替代方案(四):GPFS282010年推出基于Hadoop的GPFSFPO, 并宣布GPFS不共享 集群版本比Hadoop快多了,因为它在内核级别中运行,而 HDFS是运行在用户态的FUSE文件系统。替代方案(亓):Isil

9、on292012年1月转型为HDFS企业级别的新方案。 分发 NameNode,以实现高可用性和负载平衡,同时通过纠删码 提高利用率。支持快照及容灾备份。替代方案(六):Lustre30基于Lustre的 集群会比基 于HDFS的集 群更快更便 宜。解决 Map output 和Reduce input IO问 题。替代方案(七):MapR 文件系统31分布式元数据使 得系统扩展性更 好,不存在单点 故障问题。另据 MapR 宣 布 其 文 件系统比HDFS快 2-5倍(实际上 有20倍),它还 具有镜像、快照、 高性能点。替代方案(八):NetApp Hadoop32NetApp重新改 版

10、了 物 理 Hadoop结构。 把HDFS放在磁 盘阵列中,通 过这样来达到 更快、更稳定、 更 安 全 的 Hadoop工作。替代方案(九):KFS33两者都是GFS的开源实现,设计原理基本相同。HDFS 用Java 实现,KFS 用C+实现。数据分布策略KFS均衡分布,HDFS考 虑数据距离。名字空间HDFS采用component模式,KFS采用 B+树。替代方案(十):QFS 34QFS 是一个高 性能、容错、 分 布 式 的 文 件 系 统 , 用 于支持MR处 理 或 者 需 要 顺 序 读 写 大 文件的应用。 其在KFS基础 上 优 化 , 引 入 纠 删 码 提 高利用率。35

11、Lustre百花齐放,百家争鸣MapReduce是一种补充而非替代MapReduceBIG DATAMPINo SQLRDBMSMapReduce丌是所有 其他计算框架的替代, 而是一种补充。根据应用特点采用丌同 的计算框架,在大数据 时代,企业内的数据中 心架构将会是一个混合 型的环境。统一计算平台是一种自 然的发展趋势。 中央式调度器的特点是,资源的调度和作业的管 理功能全部放到一个进程中完成,开源界典型的 代表是Hadoop JobTracker的实现中央式调中央式调 度器度器 双层调度器仍保留一个经简化的中央式调度器, 但调度策略下放到各个应用程序调度器完成。这 种调度器的典型代表是A

12、pache Mesos和Hadoop YARN双层调度双层调度 器器 Google提出的下一代资源管理系统Omega 将双层调度器中的集中式资源调度模块简化成了 一些持久化的共享数据和针对这些数据的验证代 码。共享数据即整个集群的实时资源使用信息。共享状态共享状态 调度器调度器统一资源管理与调度系统MesosYarnOmega未来之星 Mesos诞生于UC Berkeley的一个研究项目,目前已经成 为Apache Incubator的项目。 Apache Mesos是一个集群管理器,提供有效的分布式作 业间的资源隔离和作业中的资源共享,在其基础上可以运 行Hadoop, MPI, Hyper

13、table,Spark的作业。MesosApache URL: http:/www.mesos.apach e.org/index.html YARN是MRv2在Hadoop基础上演变而来的,以支持MR之外 的其他计算框架。 由 ResourceManager 和 NodeManager 组 成 。 MR的 JobTracker拆分成Resource Manager和Application Master。 Resource Manager是全局的资源管理器,负责资源分配; Application Master负责application的资源申请,启动各个任 务和运行状态监控。统一计算框架YAR

14、NGoogle下一代集群资源管理系统从论文作者看,omega主要是由剑桥大学和 加州大学伯克利分校的两个实习生在google 实习期间完成的。Omega41Mesos与YARN 让不同的计算框架能够共享一个集群资源 两级调度 都采用DRF作业调度算法相同点 Mesos采用C+编写,YARN采用Java编写。 Mesos能够调度内存和CPU资源,YARN目前只能处理内存。 Mesos采用Linux Container进行隔离,YARN采用简单的Unix 进程 进行隔离内存资源(采用Cgroups隔离CPU资源)。 一级调度中,Mesos采用Push方式,而YARN采用Pull方式。 Mesos精

15、简设计,YARN代码复杂,是Mesos代码了3倍以上。 YARN采用了Kerberos ,并且延续了Hadoop的安全架构;Mesos对 安全性方面考虑不多。不同点Mesos与Omega 让不同的计算框架和计算任务能够共享一个集群资 源相同点 Mesos采用两级调度,框架无法知道整个集群的使 用信息;Omega是基于共享状态的调度器 Mesos采用悲观锁,并发粒度小;Omega采用乐观 锁,MVCC实现,提升并发性 Mesos&Omega采用相同的分层策略,但是Omega 资源分配的过程中会引入些全局资源因素,作为决 策因子,相对Mesos来说,调度策略要复杂一点不同点曙光大数据解决之道曙光大

16、数据的发展之路 Sugon storage 1996年曙光公司正式成立,曙光存储进入市场 2007年组建云存储部,致力于幵行存储,云存储,幵行数据库系统研 发,幵推出一系列产品 2009年海量存储产品Parastor,DRAC幵行数据库产品发布 2010年曙光成立国家级海量存储研发中心幵承接下一代EB级存储研发 2011年曙光推出Parastor200海量数据产品 2012年曙光发布XDATA大数据一体机产品 2012年-2013年 大数据产品大规模商用曙光大数据发展之路曙光大数据技术框架PAS S大数据安 全体系大数据管 理平台云运维安全运维支撑运营支撑应用支撑云防护安全数据安全主机安全应用安全基础设施统一 处理引擎模型工具SOA总线数据整理数据源实时处理离线分析处理事务处理文本检索挖掘算法库图像匹配音频检索并行查询引擎数据采集管理数据标准化接入接口企业服务总线业务服

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号