重生之我是敲代码的，已获万赞

最新推荐文章于 2024-05-30 17:08:46 发布

2401_84166236

最新推荐文章于 2024-05-30 17:08:46 发布

阅读量1k

点赞数 28

分类专栏： 2024年程序员学习文章标签： linq c#

本文链接：https://blog.csdn.net/2401_84166236/article/details/137528362

版权

2024年程序员学习专栏收录该内容

85 篇文章 0 订阅

订阅专栏

HBase采用了BigTable的数据模型：增强的稀疏排序映射表（Key/Value），其中，键由行关键字、列关键字和时间戳构成。

HBase提供了对大规模数据的随机、实时读写访问，同时，HBase中保存的数据可以使用MapReduce来处理，它将数据存储和并行计算完美地结合在一起。

10、Flume（日志收集工具）
Flume是一个可扩展、适合复杂环境的海量日志收集系统。它将数据从产生、传输、处理并最终写入目标的路径的过程抽象为数据流，在具体的数据流中，数据源支持在Flume中定制数据发送方，从而支持收集各种不同协议数据。

同时，Flume数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume还具有能够将日志写往各种数据目标（可定制）的能力。

Flume以Agent为最小的独立运行单位，一个Agent就是一个JVM。单个Agent由Source、Sink和Channel三大组件构成

Source：从客户端收集数据，并传递给Channel。

Channel：缓存区，将Source传输的数据暂时存放。

Sink：从Channel收集数据，并写入到指定地址。

Event：日志文件、avro对象等源文件。

11、Kafka（分布式消息队列）
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。实现了主题、分区及其队列模式以及生产者、消费者架构模式。

生产者组件和消费者组件均可以连接到KafKa集群，而KafKa被认为是组件通信之间所使用的一种消息中间件。KafKa内部氛围很多Topic（一种高度抽象的数据结构），每个Topic又被分为很多分区（partition），每个分区中的数据按队列模式进行编号存储。被编号的日志数据称为此日志数据块在队列中的偏移量（offest），偏移量越大的数据块越新，即越靠近当前时间。生产环境中的最佳实践架构是Flume+KafKa+Spark Streaming。

12、Oozie（工作流调度器）
Oozie是一个可扩展的工作体系，集成于Hadoop的堆栈，用于协调多个MapReduce作业的执行。它能够管理一个复杂的系统，基于外部事件来执行，外部事件包括数据的定时和数据的出现。

Oozie工作流是放置在控制依赖DAG（有向无环图 Direct Acyclic Graph）中的一组动作（例如，Hadoop的Map/Reduce作业、Pig作业等），其中指定了动作执行的顺序。

Oozie使用hPDL（一种XML流程定义语言）来描述这个图。

spark的生态圈

1、Spark Core
Spark Core 是整个Spark生态系统的核心组件，是一个分布式大数据处理框架。Spark Core提供了多种资源调度管理，通过内存计算、有向无环图（DAG）等机制保证分布式计算的快速，并引入了RDD 的抽象保证数据的高容错性，其重要特性描述如下：

Spark Core提供了多种运行模式，不仅可以使用自身运行模式处理任务，如本地模式、Standalone，而且可以使用第三方资源调度框架来处理任务，如YARN、MESOS等。相比较而言，第三方资源调度框架能够更细粒度管理资源。
Spark Core提供了有向无环图（DAG）的分布式并行计算框架，并提供内存机制来支持多次迭代计算或者数据共享，大大减少迭代计算之间读取数据的开销，这对于需要进行多次迭代的数据挖掘和分析性能有极大提升。另外在任务处理过程中移动计算而非移动数据（数据本地性），RDDPartition 可以就近读取分布式文件系统中的数据块到各个节点内存中进行计算。
在Spark 中引入了RDD的抽象，它是分布在一组节点中的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可以根据“血统”对它们进行重建，保证了数据的高容错性。
2、Spark SQL
Spark SQL 的前身是Shark，它发布时Hive 可以说是SQL on Hadoop 的唯一选择（Hive 负责将SQL 编译成可扩展的MapReduce 作业），鉴于Hive 的性能以及与Spark 的兼容，Shark 由此而生。
Shark 即Hive on Spark，本质上是通过Hive 的HQL 进行解析，把HQL 翻译成Spark 上对应的RDD 操作，然后通过Hive 的Metadata 获取数据库里的表信息，实际为HDFS 上的数据和文件，最后由Shark 获取并放到Spark 上运算。Shark 的最大特性就是速度快，能与Hive 的完全兼容，并且可以在Shell 模式下使用rdd2sql 这样的API，把HQL 得到的结果集继续在Scala环境下运算，支持用户编写简单的机器学习或简单分析处理函数，对HQL 结果进一步分析计算。
在2014 年7 月1 日的Spark Summit 上，Databricks 宣布终止对Shark 的开发，将重点放到Spark SQL 上。在此次会议上，Databricks 表示，Shark 更多是对Hive 的改造，替换了Hive 的物理执行引擎，使之有一个较快的处理速度。然而，不容忽视的是，Shark 继承了大量的Hive代码，因此给优化和维护带来大量的麻烦。随着性能优化和先进分析整合的进一步加深，基于MapReduce 设计的部分无疑成为了整个项目的瓶颈。因此，为了更好的发展，给用户提供一个更好的体验，Databricks 宣布终止Shark 项目，从而将更多的精力放到Spark SQL 上。
Spark SQL 允许开发人员直接处理RDD，同时也可查询在 Hive 上存在的外部数据。SparkSQL 的一个重要特点是能够统一处理关系表和RDD，使得开发人员可以轻松地使用SQL 命令进行外部查询，同时进行更复杂的数据分析。其特点如下：

引入了新的RDD 类型SchemaRDD，可以像传统数据库定义表一样来定义SchemaRDD。 SchemaRDD由定义了列数据类型的行对象构成。SchemaRDD 既可以从RDD 转换过来，也可以从Parquet 文件读入，还可以使用HiveQL从Hive 中获取。
内嵌了Catalyst 查询优化框架，在把SQL 解析成逻辑执行计划之后，利用Catalyst 包里的一些类和接口，执行了一些简单的执行计划优化，最后变成RDD 的计算。
为什么Spark SQL 的性能会得到这么大的提升呢？主要是Spark SQL 在以下几点做了优化。

字节码生成技术（Bytecode Generation）：Spark 1.1.0 在Catalyst 模块的Expressions
增加了Codegen 模块，使用动态字节码生成技术，对匹配的表达式采用特定的代码动态编译。另外对SQL 表达式都做了CG 优化。CG优化的实现主要还是依靠Scala 2.10运行时的反射机制（Runtime Reflection）。
Scala 代码优化：Spark SQL 在使用Scala编写代码的时候，尽量避免低效的、容易GC的代码；尽管增加了编写代码的难度，但对于用户来说接口统一。
内存列存储（In-Memory Columnar Storage）：Spark SQL 的表数据在内存中存储不是采用原生态的JVM对象存储方式，而是采用内存列存储。
3、Spark Streaming
Spark Streaming 是一个对实时数据流进行高吞吐、高容错的流式处理系统，可以对多种数据源（如Kafka、Flume、Twitter 和ZeroMQ 等）进行类似Map、Reduce 和Join 等复杂操作，并将结果保存到外部文件系统、数据库或应用到实时仪表盘，如下图：

相比其他的处理引擎要么只专注于流处理，要么只负责批处理（仅提供需要外部实现的流处理API 接口），而Spark Streaming 最大的优势是提供的处理引擎和RDD 编程模型可以同时进行批处理与流处理。
对于传统流处理中一次处理一条记录的方式而言，Spark Streaming 使用的是将流数据离散化处理（Discretized Streams），通过该处理方式能够进行秒级以下的数据批处理。在SparkStreaming 处理过程中，Receiver 并行接收数据，并将数据缓存至Spark 工作节点的内存中。经过延迟优化后，Spark 引擎对短任务（几十毫秒）能够进行批处理，并且可将结果输出至其他系统中。与传统连续算子模型不同，其模型是静态分配给一个节点进行计算，而Spark 可基于数据的来源以及可用资源情况动态分配给工作节点。

spark的特点

运行速度快：Spark基于内存计算，相对于Hadoop性能提高了几十倍，而其主要原因正是因为Spark基于内存计算和引入DAG执行引擎。
易用性好：Spark不仅支持Scala编写应用程序，而且支持Java和Python等语言进行编写。（Scala是一种高效、可扩展的语言，能够用简介的代码处理较为复杂的工作。）
通用性强：Spark生态圈中的组件：Spark Core提供内存计算框架，Spark SQL的即席查询，Spark Streaming的实时处理，MLlib的机器学习和GraphX的图处理。它们都是有AMP实验室提供，能够无缝地集成，并提供一站式解决平台。
随处运行：Spark具有很强的适应性，能够读取HDFS，HBase，S3和Tachyon为持久层读写原生数据；能够以Mesos，YARN和自身携带的Standalone作为资源管理器调度作业来完成Spark应用程序的计算。

mapreduce的运行框架

写好MapReduce程序打成jar包交给client端，client把jar包提交到JobTracker。JobTracker把这个作业拆分成很多份，然后分配给TaskTracker去执行。JobTracker和TaskTracker是主从关系，通过心跳机制管理。TaskTracker并不是随机分配任务的，这里有个概念叫：数据本地化。意思是：将map task分配给含有该map处理的数据块(block)的TaskTracker上，运算向数据移动。在分配reduce任务时并不考虑数据本地化。

MR和Spark的对比

针对这两款计算框架从下边几个方面进行对比

1.通用性
1.1Spark
一栈式，主要说的是，Spark不仅仅可以进行离线计算(SparkCore)，同时还可以进行流式处理(SparkStreaming)、交互式计算(SparkShell,SparkSQL，StructStreaming，
图计算(SparkGraphx),机器学习(SparkMLLib),也就是说我们可以在一个项目中，同时可以使用上述所有的框架，这是Spark相比较于其它框架最大的优势。可以使用多中语言进行编程

1.2MR
mapreduce主要是擅长离线的计算,不擅长实时计算

2.内存和磁盘的使用情况
2.1Spark
Spark是基于RDD,主要使用内存进行储存计算的源数据及过程的数据,避免了写磁盘的IO操作,速度自然比较快

2.2MR
mapreduce基于磁盘的计算,计算的过程中需要大量的溢写磁盘的操作,IO瓶颈比较明显,速度自然不好

3.API
3.1Spark
Spark编程过程中系统提供了大量的算子,transformation和action算子,功能之强大是MR无法比拟的,编程自由度比较高

3.2MR
MR的编程API只是提供了 map和reduce的操作,编程局限性比较大,什么操作都需要往规定好的模式上去套,死板

4.系统自由度
4.1Spark
Spark给用户提供了诸多的参数进行设置,适应不同场景的应用,比如sort,系统并没有强制进行sort,如果需要可以进行相应参数的设置,去掉自动排序的功能之后提高效率

4.2 MR
maoreduce的shuffle的过程中相当的复杂,虽然shuffle的过程是奇迹发生的地方,但是这里边做的事太多了,很多没有法子去掉,也就是说有可能对于场景无用的操作也做了,比如排序,本身其实我们有可能不需要sort,但是基于MR的特性,它必须依靠sort,这样白白浪费了性能

5.系统容错性
5.1Spark
Spark中有个血缘关系,在计算过程中如果出现问题造成数据丢失,系统不用重新计算,只需要根据血缘关系找到最近的中间过程数据进行计算,而且基于内存的中间数据存储增加了再次使用的读取的速度

5.2MR
MR的过程中的中间文件溢写磁盘,如计算过程中出现数据的丢失,只能重新来过.严重影响时效性。