1.3查询所有数据
- Mapreduce看似用蛮力
- 每个査询需处理整个数据集或至少一个数据集的绝大部分
- Mapreduce是一个批量査询处理器
- 能在合理时间内处理针对整个数据集的动态査询。
- 它改变我们对数据的传统看法,
- 解放了以前只存在磁带和硬盘上的数据
- 要很长时间处理才能获得结果的问题,
- 现在顷刻之间就迎刃而解,
- 邮件部门用Hadoop处理邮件日志
- 他们写一条特别的査询找出用户的地理分布。
- 他们是这么描述的:“
- 每月运行一次 Mapreduce任务来帮助我们
- 决定扩容时将新的邮件服务器放在哪些 Rackspace数据中心
- 通过整合几百G数据,用工具来分析这些数据,
- 工程师能对以往没有注意到的数据有所理解,
- 甚至还运用这些信息来改善现有的服务。
1.4不仅仅是批处理
- Mapreduce基本上是批处理系统,不适合交互式分析。
- 一条査询并在几秒内或更短得到结果。
- 要几分钟或更多。
- Mapreduce适合
- 没有用户在现场等待査询结果的离线场景
- 从最初的原型出现以来, Hadoop的发展已超越批处理本身
- “ Hadoop”指代一个更大的、多个项目组成的生态系统,
- 不仅是HDFS和Mapreduce
- 这些项目都属分布式计算和大规模数据处理范畴
- 这些项目许多都是由Apache软件基金会管理,
- 该基金会为开源软件项目社区提供支持,
- 包括最初的HTTPserver项目(基金会的名称也来源这项目)
- 第一个提供在线访问的组件是Hbase,一种使用HDFS做底层存储的键值存储模型。
- Hbase不仅提供对单行的在线读/写访问,还提供对数据块读/写的批操作,这对于在 Hbase上构建应用来说是一种很好的解决方案。
- Hadoop2中(Yet Another Resource Negotiator)意味Hadoop有了新处理模型。
- 一个集群资源管理系统,
- 允许任何一个分布式程序(不仅是Mapreduce)
- 基于 Hadoop集群的数据运行
- 过去几年中,出现许多不同的、能与 Hadoop协同工作的处理模式。
- 以下是些例子。
- 交互式SQL
- 利用Mapreduce进行分发并使用一个分布式査询引擎,使得在 Hadoop上获得SQL査询低延迟响应的同时还能保持对大数据集规模的可扩展性。
- 这个引擎使用指定的“总是开启( always on)”守护进程(如同 impala)或容器重用(如同Tez上的
Hive)。
- 迭代处理
- 许多算法具有迭代性
- 和那种每次迭代都从硬盘加载的方式相比,
- 这种在内存中保存每次中间结果集的方式更高效
- Mapreduce架构不允许这样,
- 但如果使用 Spark就会比较直接,
- 它在使用数据集方面展现高度探究
- 流处理
- 流系统,如 Storm, Spark Streaming或 Hamza使得在无边界数据流上运行实时、分布式的计算,
- 并向 Hadoop存储系统或外部系统发布结果成为可能
扫描二维码关注公众号，回复：
10751665 查看本文章
- 搜索
- Solr搜索平台能够在 Hadoop集群上运行,当文档加入HDFS后就可对其进行索引,且根据HDFS中存储的索引为搜索査询提供服务。
- 无论Hadoop上出现多少不同的处理框架,
- 就批处理而言, Mapreduce仍然一席之地。
- Mapreduce提出的一些概念更具有通用性(例如,输入格式、数据集分
片等),最好能了解Mapreduce的工作机制。
1.5相较于其他系统的优势
- Hadoop不是第一个用于数据存储和分析的分布式系统,
- 但Hadoop的一些特性将它和其他那些看上去类似的系统区别开来。
1.5.1关系型数据库管理系统
- 不能用配有大量硬盘的数据库来大规模数据分析?
- 硬盘发展趋势:
- 寻址时间的提升远不敌传输速率的提升
- 寻址是将磁头移动到特定硬盘位置进行读/写
- 是导致硬盘操作延迟的主要原因,传输速率取决硬盘带宽
- 如果数据访问含大量的硬盘寻址,那读取大量数据集必然花更长时间
- (流读取主要取决于传输速率)
- 如果数据库只更新小部分记录
- 那传统B树(关系型数据库中用的一种数据结构,受限于寻址的速率)就更有优势。
- 但如果大量数据更新,B树效率落后Mapreduce
- 因为需用“排序/合并”来重建数据库。
- Mapreduce视为关系型数据的补充
- 差异如表1-1。
- Mapreduce适合解决需要以批处理方式分析整个数据集的问题,
- 尤其是一些特定目的的分析
- RDBMS适用于索引后数据集的点査询和更新,
- 建立索引的数据库系统能提供对小规模数据的低延迟数据检索和快速更新
- Mapreduce适合一次写入、多次读取数据
- 关系型数据库:持续更新的数据集 。
- 区别模糊。
- 关系型数据库开始吸收 Hadoop的一些思想,
- 诸如Hive这样的 Hadoop系统不仅变得更具交互性(通过从 Mapreduce中脱离出来),
- 且增加了索引和事务,
- 使其看上去更像传统的关系型数据库。
- 另一个区别在于它们所操作的数据集的结构化程度。
- 结构化数据具有既定格式的实体化数据
- 如XML文档或满足特定预定义格式的数据库表。
- RDBMS包括的内容。
- 半结构化数据松散,有格式,但经常被忽略,
- 它只能作为对数据结构的一般性指导
- 例如电子表格,它在结构上是由单元格组成的网格,但每个单元格内可以保存任何形式的数据。
- 非结构化数据没有什么特别的内部结构,如纯文本或图像数据
- Hadoop对非结构化或半结构化数据非常有效,
- 因为它是在处理数据时才对数据解释(读时模式)
- 这种模式在提供灵活性的同时避免RDBMS数据加载阶段带来的高开销,因为在 Hadoop中仅仅是一个文件拷贝
- 关系型数据往往是规范的,以保持其数据完整性且不含冗余。
- 规范给Hadoop处理带来问题,
- 它使记录读取成为非本地操作,
- Hadoop的核心假设之一就是可进行(高速的)流读/写
- Web服务器日志是典型的非规范化数据记录(每次都需记录客户端主机全名,这导致同一客户端的全名可能多次出现),这也是 Hadoop非常适用于分析各种日志文件的原因
- Hadoop也能做连接(join),不过这种操作没有在关系型数据库中用的多。
- Mapreduce及Hadoop中其他处理模型是可随着数据规模线性伸缩
- 对数据分区后,函数原语(如map和reduce)能在各个分区上并行作
- 这意味如果输入的数据量是原来的两倍,
- 那么作业时间也需两倍
- 如果集群规模扩展为原来两倍,
- 那么作业的运行速度却仍然与原来一样快。
- SQL査询一般不具备该特性。
1.5.2网格计算
