大数据基础处理框架

Apache Hadoop

Apache Hadoop 是一种专用于批处理的处理框架。Hadoop 是首个在开源社区获得极大关注的大数据框架。基于谷歌有关海量数据处理所发表的多篇论文与经验的 Hadoop 重新实现了相关算法和组件堆栈，让大规模批处理技术变得更易用。新版 Hadoop 包含多个组件，即多个层，通过配合使用可处理批数据。

| 组件名称 | 说明 |

| --- | --- |

| HDFS | HDFS 是一种分布式文件系统层，可对集群节点间的存储和复制进行协调。HDFS 确保了无法避免的节点故障发生后数据依然可用，可将其用作数据来源，可用于存储中间态的处理结果，并可存储计算的最终结果。 |

| YARN | YARN 是 Yet Another Resource Negotiator(另一个资源管理器)的缩写，可充当 Hadoop 堆栈的集群协调组件。该组件负责协调并管理底层资源和调度作业的运行。通过充当集群资源的接口，YARN 使得用户能在 Hadoop 集群中使用比以往的迭代方式运行更多类型的工作负载。 |

| MapReduce | MapReduce 是 Hadoop 的原生批处理引擎。 |

Hadoop 的处理功能来自 MapReduce 引擎。MapReduce 的处理技术符合使用键值对的 map、shuffle、reduce 算法要求。

• 基本处理过程包括：

1. 从 HDFS 文件系统读取数据集

2. 将数据集拆分成小块并分配给所有可用节点

3. 针对每个节点上的数据子集进行计算(计算的中间态结果会重新写入 HDFS)

4. 重新分配中间态结果并按照键进行分组

5. 通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”

6. 将计算而来的最终结果重新写入 HDFS

• 优势和局限

1. 由于这种方法严重依赖持久存储，每个任务需要多次执行读取和写入操作，因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源，这意味着 MapReduce 可以处理非常海量的数据集。同时也意味着相比其他类似技术，Hadoop 的 MapReduce 通常可以在廉价硬件上运行，因为该技术并不需要将一切都存储在内存中。MapReduce 具备极高的缩放潜力，生产环境中曾经出现过包含数万个节点的应用。

2. MapReduce 的学习曲线较为陡峭，虽然 Hadoop 生态系统的其他周边技术可以大幅降低这一问题的影响，但通过 Hadoop 集群快速实现某些应用时依然需要注意这个问题。

3. 围绕 Hadoop 已经形成了辽阔的生态系统，Hadoop 集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与 Hadoop 集成也可以使用 HDFS 和 YARN 资源管理器。

• 总结

Apache Hadoop 及其 MapReduce 处理引擎提供了一套久经考验的批处理模型，* 最适合处理对时间要求不高的非常大规模数据集。* 通过非常低成本的组件即可搭建完整功能的 Hadoop 集群，使得这一廉价且高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使得 Hadoop 可以成为使用不同技术的多种工作负载处理平台的底层基础。

2.2 流处理系统

流处理系统会对随时进入系统的数据进行计算。相比批处理模式，这是一种截然不同的处理方式。流处理方式无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作。

流处理中的数据集是“无边界”的，这就产生了几个重要的影响：

完整数据集只能代表截至目前已经进入到系统中的数据总量。

工作数据集也许更相关，在特定时间只能代表某个单一数据项。

处理工作是基于事件的，除非明确停止否则没有“尽头”。

处理结果立刻可用，并会随着新数据的抵达继续更新。

流处理系统可以处理几乎无限量的数据，但同一时间只能处理一条(真正的流处理)或很少量(微批处理，Micro-batch Processing)数据，不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法，但流处理主要针对副作用更少，更加功能性的处理(Functional processing)进行优化。

功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果，此类处理非常适合流处理，因为不同项的状态通常是某些困难、限制，以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的，但这些框架通常在不具备状态管理机制时更简单也更高效。

此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志，以及其他基于时间的衡量指标是最适合的类型，因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。

Apache Storm

Apache Storm 是一种 侧重于极低延迟的流处理框架，也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据，通过比其他解决方案更低的延迟提供结果。

Storm 的流处理可对框架中名为 Topology(拓扑)的 DAG(Directed Acyclic Graph，有向无环图)进行编排。这些拓扑描述了当数据片段进入系统后，需要对每个传入的片段执行的不同转换或步骤。

• 拓扑包含：

1. Stream：普通的数据流，这是一种会持续抵达系统的无边界数据。

2. Spout：位于拓扑边缘的数据流来源，例如可以是 API 或查询等，从这里可以产生待处理的数据。

3. Bolt：Bolt 代表需要消耗流数据，对其应用操作，并将结果以流的形式进行输出的处理步骤。Bolt 需要与每个 Spout 建立连接，随后相互连接以组成所有必要的处理。在拓扑的尾部，可以使用最终的 Bolt 输出作为相互连接的其他系统的输入。

Storm 背后的想法是使用上述组件定义大量小型的离散操作，随后将多个组件组成所需拓扑。默认情况下 Storm 提供了“至少一次”的处理保证，这意味着可以确保每条消息至少可以被处理一次，但某些情况下如果遇到失败可能会处理多次。Storm 无法确保可以按照特定顺序处理消息。

为了实现严格的一次处理，即有状态处理，可以使用一种名为 Trident 的抽象。严格来说不使用 Trident 的 Storm 通常可称之为 Core Storm。Trident 会对 Storm 的处理能力产生极大影响，会增加延迟，为处理提供状态，使用微批模式代替逐项处理的纯粹流处理模式。

为避免这些问题，通常建议 Storm 用户尽可能使用 Core Storm。然而也要注意，Trident 对内容严格的一次处理保证在某些情况下也比较有用，例如系统无法智能地处理重复消息时。如果需要在项之间维持状态，例如想要计算一个小时内有多少用户点击了某个链接，此时 Trident 将是你唯一的选择。尽管不能充分发挥框架与生俱来的优势，但 Trident 提高了 Storm 的灵活性。

• Trident 拓扑包含：

1. 流批(Stream batch)：这是指流数据的微批，可通过分块提供批处理语义。

2. 操作(Operation)：是指可以对数据执行的批处理过程。

• 优势和局限

1. 目前来说 Storm 可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据，可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，例如需要将处理结果直接提供给访客打开的网站页面，此时 Storm 将会是一个很好的选择。

2. Storm 与 Trident 配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具，但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此，但多一种流处理方式总是好的。

3. Core Storm 无法保证消息的处理顺序。Core Storm 为消息提供了“至少一次”的处理保证，这意味着可以保证每条消息都能被处理，但也可能发生重复。Trident 提供了严格的一次处理保证，可以在不同批之间提供顺序处理，但无法在一个批内部实现顺序处理。

4. 在互操作性方面，Storm 可与 Hadoop 的 YARN 资源管理器进行集成，因此可以很方便地融入现有 Hadoop 部署。除了支持大部分处理框架，Storm 还可支持多种语言，为用户的拓扑定义提供了更多选择。

• 总结

对于延迟需求很高的纯粹的流处理工作负载，Storm 可能是最适合的技术。该技术可以保证每条消息都被处理，可配合多种编程语言使用。由于 Storm 无法进行批处理，如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求，此时可考虑使用 Trident。不过这种情况下其他流处理框架也许更适合

Apache Samza

Apache Samza 是一种与 Apache Kafka 消息系统紧密绑定的流处理框架。虽然 Kafka 可用于很多流处理系统，但按照设计，Samza 可以更好地发挥 Kafka 独特的架构优势和保障。该技术可通过 Kafka 提供容错、缓冲，以及状态存储。

Samza 可使用 YARN 作为资源管理器。这意味着默认情况下需要具备 Hadoop 集群(至少具备 HDFS 和 YARN)，但同时也意味着 Samza 可以直接使用 YARN 丰富的内建功能。

：Samza 依赖 Kafka 的语义定义流的处理方式。

• Kafka 在处理数据时涉及下列概念：

1. Topic(话题)：进入 Kafka 系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的，由相关信息组成的数据流。

2. Partition(分区)：为了将一个话题分散至多个节点，Kafka 会将传入的消息划分为多个分区。分区的划分将基于键(Key)进行，这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。

3. Broker(代理)：组成 Kafka 集群的每个节点也叫做代理。

4. Producer(生成方)：任何向 Kafka 话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。

5. Consumer(消耗方)：任何从 Kafka 读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息，这样即可在失败后知道哪些记录已经被处理过了。

由于 Kafka 相当于永恒不变的日志，Samza 也需要处理永恒不变的数据流。这意味着任何转换创建的新数据流都可被其他组件所使用，而不会对最初的数据流产生影响。

• 优势和局限

1. 乍看之下，Samza 对 Kafka 类查询系统的依赖似乎是一种限制，然而这也可以为系统提供一些独特的保证和功能，这些内容也是其他流处理系统不具备的。

2. Kafka 已经提供了可以通过低延迟方式访问的数据存储副本，此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容，包括中间态的结果都可写入到 Kafka，并可被下游步骤独立使用。

3. 这种对 Kafka 的紧密依赖在很多方面类似于 MapReduce 引擎对 HDFS 的依赖。虽然在批处理的每个计算之间对 HDFS 的依赖导致了一些严重的性能问题，但也避免了流处理遇到的很多其他问题。

4. Samza 与 Kafka 之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调，即可在输出的任何步骤中增加任意数量的订阅者，对于有多个团队需要访问类似数据的组织，这一特性非常有用。多个团队可以全部订阅进入系统的数据话题，或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基 Java 开源项目【ali1024.coding.net/pub 《一线大厂 Java 面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》开源 lic/P7/Java/git】 础架构造成额外的压力。

5. 直接写入 Kafka 还可避免回压(Backpressure)问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况，这种情况可能导致处理工作停顿并可能丢失数据。按照设计，Kafka 可以将数据保存很长时间，这意味着组件可以在方便的时候继续进行处理，并可直接重启动而无需担心造成任何后果。

6. Samza 可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样 Samza 即可获得“至少一次”的交付保障，但面对由于数据可能多次交付造成的失败，该技术无法对汇总后状态(例如计数)提供精确恢复。

7. Samza 提供的高级抽象使其在很多方面比 Storm 等系统提供的基元(Primitive)更易于配合使用。目前 Samza 只支持 JVM 语言，这意味着它在语言支持方面不如 Storm 灵活。

• 总结

对于已经具备或易于实现 Hadoop 和 Kafka 的环境，Apache Samza 是流处理工作负载一个很好的选择。Samza 本身很适合有多个团队需要使用(但相互之间并不一定紧密协调)不同处理阶段的多个数据流的组织。Samza 可大幅简化很多流处理工作，可实现低延迟的性能。如果部署需求与当前系统不兼容，也许并不适合使用，但如果需要极低延迟的处理，或对严格的一次处理语义有较高需求，此时依然适合考虑。

2.3 混合处理系统

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

最新整理面试题

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料 &最新 2021 收集的一些大厂的面试真题

最新整理电子书

最新整理大厂面试文档

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。