大数据必知必会系列_开源组件总结（3）：数据计算层

数据经过采集和存储之后就是计算了，数仓开发、数据分析、数据挖掘都需要通过计算获得结果。

1、基础概念

计算框架：解决分布式系统如何计算数据的问题。它提供了编程模型、API和运行时环境，使开发者能够编写、提交和执行分布式计算任务。核心功能：

• 编程模型: 提供简化的数据处理和计算的编程接口，如 MapReduce、DAG（有向无环图）等。

• 数据处理: 提供高效的数据处理能力，包括批处理、流处理、交互式查询等。

• 容错机制: 提供数据冗余和任务重试机制，保证任务的可靠性和容错性。

资源调度：在分布式计算环境中，管理和分配计算资源（如CPU、内存、存储和网络带宽）的过程。资源调度系统负责监控集群资源的使用情况，并根据任务的需求动态分配资源。核心功能：

• 资源分配: 根据任务的需求和集群资源的可用性，动态分配和调度资源。

• 资源监控: 实时监控集群资源的使用情况，包括CPU、内存、存储和网络带宽等。

• 资源隔离: 确保不同任务之间的资源隔离，防止资源争用和冲突。

• 资源回收: 回收和释放不再使用的资源，提高资源利用率。

任务调度：在分布式计算环境中，管理和调度计算任务的过程。任务调度系统负责将计算任务分解为多个子任务，并在集群中调度这些子任务的执行。核心功能：

• 任务分解: 将计算任务分解为多个子任务，以便在集群中并行执行。

• 任务分配: 将子任务分配给集群中的计算节点，确保任务负载均衡。

• 任务监控: 实时监控任务的执行状态，包括任务的进度、资源使用情况和错误信息等。

• 任务重试: 在任务执行失败时，自动重试任务，保证任务的可靠性和容错性。

• 任务依赖管理: 管理任务之间的依赖关系，确保任务按正确的顺序执行。

2、三大计算框架比较

计算框架	MapReduce	Spark	Flink
计算模型	- 基于 Map 和 Reduce 两阶段的批处理模型。 - 数据以键值对形式在两阶段流动，处理大规模离线数据。	- 基于 RDD，通过 DAG 优化计算顺序。 - 统一编程模型，支持批处理、流处理、交互式查询、机器学习和图计算等多种模式。	- 流批一体，DataStream API 用于流处理，DataSet API 用于批处理。 - 基于事件时间处理流数据，处理乱序数据。
性能	- 处理大规模数据吞吐量高，但基于磁盘计算，数据读写慢。 - 延迟高，不适用于实时处理。	- 内存计算提高速度，吞吐量高，内存不足影响性能。 - 延迟低于 MapReduce，内存满足时处理速度快，但实时流处理延迟高于 Flink。	- 高吞吐量，动态资源分配提高资源利用率。 - 实时处理低延迟，处理乱序数据也能保证。
资源管理	- JobTracker 简单分配资源，缺乏细粒度控制，易资源浪费。 - 与 Hadoop 生态紧密结合，依赖 HDFS，资源利用效率低。	- 可与多种资源管理器集成（Standalone、YARN、Mesos）。 - 内存计算依赖内存资源，集成时需根据资源管理器特性配置。	- 支持动态资源分配，适应不同负载。 - 对内存和计算资源要求高，资源紧张时需规划优化。
编程模型	- 编程模型复杂，需写 Map 和 Reduce 函数，处理多种数据问题。 - 开发难度大，代码可读性和维护性差，灵活性低。	- 多种编程语言 API，基于 RDD 操作编程简单。 - 可灵活组合 RDD 操作，功能库丰富，灵活性高。	- 编程模型较复杂，需掌握流处理概念。 - 掌握后可构建复杂程序，流批一体编程方便，灵活性高。
容错性	- 数据冗余和任务重试机制容错。 - 任务失败重新执行可能需重新读大量数据，恢复效率低。	- 基于 RDD 依赖关系容错，支持不同存储级别。 - 只需重新计算部分数据分区，恢复效率较高，复杂依赖增加恢复复杂性。	- 状态管理和检查点机制容错，保存任务状态并定期创建检查点。 - 可精确恢复任务状态，只需处理检查点后的数据，恢复效率高。
生态系统	- 是 Hadoop 生态重要部分，与其他组件集成紧密。 - 生态系统单一，主要用于批处理，其他计算模式功能欠缺。 - 社区支持较稳定但活跃度随新框架出现有所下降。	- 生态系统丰富，涵盖多领域功能库（Spark SQL、Spark Streaming、MLlib、GraphX 等）。 - 社区活跃，提供大量文档教程。	- 生态系统相对较小但在发展，主要专注流处理和批处理。 - 社区支持相对较弱但在不断提高。

总结：

• Hadoop /Spark 基于批处理模型，数据由批组成，数据集有界、存储持久且适用于大规模数据，多用于离线任务如 ETL、分析和机器学习。
• Flink 采用流处理模型，数据为流，数据流无界且实时处理，多应用于实时场景如实时分析、监控和 ETL。

这里不得不提一下，大数据处理技术的演进，Lambda架构和Kappa架构。

Lambda架构通过批处理和流处理的结合，解决了实时性和大规模数据处理的问题，但增加了系统的复杂性。

Kappa架构通过统一的流处理引擎，简化了架构，降低了开发和运维的复杂性，同时利用流处理技术的进步，提供了一种更为简洁和高效的解决方案。

Lambda架构和Kappa架构对比如下：

特性/架构	Lambda架构	Kappa架构
引擎数量	两套（批处理引擎和流处理引擎）	一套（流处理引擎）
代码数量	两套代码	一套代码
数据处理模型	批处理和流处理相结合	统一的流处理模型
复杂性	高	低
一致性	需要额外逻辑处理	容易保证
数据延迟	批处理有延迟，流处理实时	实时处理
维护成本	高（需要维护两套系统）	低（只需维护一套系统）
适用场景	需要同时处理实时和离线数据的场景	以流处理为主的场景
数据存储	批处理层和速度层可能使用不同的存储系统	统一的数据存储系统
开发效率	低（需要开发和维护两套代码）	高（只需开发和维护一套代码）
架构灵活性	高（可以分别优化批处理和流处理）	中（主要依赖流处理引擎的能力）
典型技术栈	批处理：Hadoop、Spark；流处理：Storm、Flink	流处理：Flink、Kafka Streams
数据处理能力	批处理适合大规模数据处理，流处理适合实时数据处理	统一处理大规模和实时数据

关于Lambda架构和Kappa架构更详细的分析，后续通过专题进行讨论。

3、资源调度组件

大数据系统中，往往有大量任务（万~百万级），资源调度为每个任务分配合理的CPU和内存资源。

资源调度	YARN（Yet Another Resource Negotiator）	Mesos	Kubernetes（K8S）
架构设计	- 主从架构，由 ResourceManager（RM）、NodeManager（NM）等核心组件构成。RM 负责资源的总体管理和调度，NM 负责单个节点的资源管理与任务执行。 - 针对 Hadoop 生态系统设计，与 Hadoop 组件紧密集成。	- 双层调度架构，包含 Mesos Master 和 Mesos Slave。Master 负责资源分配，Slave 负责执行任务。 - 采用插件式的架构，可支持多种不同类型的框架（如 Hadoop、Spark 等）。	- 主从架构，主要组件有 Master（kube - master）和 Node（kube - node）。Master 控制集群，Node 运行容器化的应用程序。 - 以容器为核心的架构，用于容器编排。
资源调度模型	- 基于资源队列进行调度。不同用户或应用可以被分配到不同的队列，队列内部再进行资源分配。 - 支持内存、CPU 等资源的调度，可设置资源的最小和最大限制。	- 采用资源分配的双层模型，Mesos Master 将资源分配给框架，框架再将资源分配给内部的任务。 - 支持细粒度的资源分配，可以精确到 CPU 核心、内存大小等。	- 通过 Pod 来管理资源，Pod 内可以包含一个或多个容器。 - 支持对 CPU、内存、存储、网络等多种资源的调度，资源分配可以基于请求（request）和限制（limit）进行设置。
资源分配策略	- 多种调度策略，如 FIFO（先进先出）、Fair Scheduler（公平调度器）等。公平调度器可根据不同规则在多个用户或队列间公平分配资源。	- 提供了多种资源分配算法，如 Dominant Resource Fairness（DRF）算法，旨在根据任务的主要资源需求进行公平分配。	- 支持多种调度策略，如基于资源请求量、Pod 优先级等进行调度。还可以使用自定义调度器扩展功能。
对不同类型任务的支持	- 主要针对大数据处理任务，在 Hadoop 生态中对 MapReduce、Spark 等任务进行资源调度。 - 对批处理任务有很好的支持，也能处理一些流处理任务，但在容器化应用方面支持相对较弱。	- 支持多种类型的计算框架任务，包括大数据任务和传统的分布式计算任务。 - 可以较好地处理不同类型的分布式计算任务，在与多种框架集成方面表现较好。	- 专注于容器化应用的调度，适用于微服务架构下的各种应用部署。 - 可以处理无状态和有状态的容器化应用，包括 Web 服务、数据库等多种类型。
可扩展性	- 具有较好的可扩展性，可以通过增加节点来扩展集群规模，并且能够适应大规模的数据处理需求。 - 在 Hadoop 生态中，随着集群规模增大，YARN 可以有效地管理资源。	- 可扩展性强，支持大规模集群的资源管理。 - 能够高效地管理大量的计算节点和任务，其插件式架构便于扩展新的框架和功能。	- 具有高度的可扩展性，通过添加节点可以轻松扩展集群。 - 被广泛应用于大规模的容器编排场景，能够处理海量的容器实例。
容错性	- 具备一定的容错能力。ResourceManager 和 NodeManager 有相应的容错机制，如 ResourceManager 的主备切换，NodeManager 的任务重试等。 - 在 Hadoop 集群中，如果某个节点出现故障，YARN 可以重新调度任务到其他节点。	- 具有较好的容错性，Mesos Master 可以检测到 Slave 节点的故障并重新分配资源。 - 框架本身可以处理任务失败和节点故障情况，保证任务的持续执行。	- 拥有强大的容错机制。Kubernetes 可以自动检测容器和节点的故障，并根据设定的策略进行恢复，如重新启动容器、重新调度 Pod 等。
社区支持与生态系统	- 作为 Hadoop 生态的一部分，有广泛的社区支持，与 Hadoop 相关的工具和技术集成良好。 - 社区提供丰富的文档、教程和插件等资源，方便用户使用和定制。	- 有活跃的社区支持，被许多大数据和分布式计算项目采用。 - 与多种计算框架有良好的集成，社区不断推动新功能的开发和优化。	- 拥有庞大而活跃的社区，是容器编排领域的事实标准。 - 生态系统丰富，有众多的工具、扩展和云服务提供商支持。
管理粒度	- 队列和节点级别。可以对资源队列设置整体资源限制，在节点层面管理每个节点上的任务执行资源分配。 - 相对较粗，侧重于队列内资源的分配和节点资源管理，对单个任务的资源精细管理能力有限。	- 框架和任务级别。Mesos Master 将资源分配到框架，框架再细分到任务，能够较好地在框架和任务层面控制资源分配。 - 对于框架内部任务的资源分配管理较为细致，但对于跨框架资源管理可能存在一定复杂性。	- Pod 和容器级别。可以精确到 Pod 的资源请求和限制，在 Pod 内对容器进行资源分配管理。 - 能够实现细粒度的容器资源管理，满足不同容器对资源的差异化需求。
优点	- 与 Hadoop 生态深度集成，对大数据任务调度有天然优势。 - 资源队列的概念方便对不同用户或应用进行资源隔离和管理。 - 公平调度器等策略有助于资源的公平分配。	- 插件式架构使其具有良好的通用性，能支持多种计算框架。 - 双层调度模型可灵活分配资源，DRF 算法能有效实现资源公平分配。 - 适用于多种分布式计算场景。	- 以容器为中心的资源管理，适合现代微服务架构。 - 强大的可扩展性和容错性，适用于大规模容器编排。 - 丰富的生态系统提供大量工具和支持。
缺点	- 对容器化应用支持不够完善，在新兴的容器编排场景下适用性有限。 - 资源管理粒度相对较粗，难以满足对单个任务的精细化资源管理需求。	- 架构相对复杂，双层调度模型对于初学者理解和使用有一定难度。 - 跨框架资源管理可能存在资源竞争等问题，需要精心配置。	- 学习曲线较陡，涉及的概念和组件较多。 - 资源管理的复杂性在小型应用场景下可能显得冗余。
应用场景	- 大数据处理场景，如数据仓库的构建、大规模数据挖掘、批处理和部分流处理任务。 - 在 Hadoop 生态系统内部，用于管理 MapReduce、Spark 等大数据任务的资源调度。	- 混合计算框架的环境，如同时存在 Hadoop、Spark 等不同框架的分布式计算场景。 - 适用于对资源分配公平性有较高要求的多框架分布式计算任务。	- 容器化应用的部署和管理，包括微服务架构下的 Web 服务、数据库等各类应用。 - 云原生应用开发和部署，需要高度可扩展和容错的资源管理场景。

总结：

• Hadoop生态 ，选YARN
• 多框架混合环境，选Meso或YARN
• 容器编排领域，选Kubernetes

4、任务调度组件

任务调度负责将计算任务分解为多个子任务，并在集群中调度这些子任务的执行。同时按照任务间的依赖关系及任务执行（如定时）策略调度任务

任务调度	Airflow	Oozie	Azkaban
工作流定义	- 使用 Python 代码定义工作流，通过创建 DAG（有向无环图）来描述任务之间的依赖关系和执行顺序。 - 代码灵活性高，可以方便地集成自定义逻辑和操作。	- 使用 XML 文件定义工作流，在 XML 中描述任务、任务类型（如 Hive 查询、MapReduce 作业等）以及任务之间的依赖关系。 - 配置相对较为繁琐，但对于熟悉 XML 的用户来说比较直观。	- 使用文本文件（.job 和.properties 文件）定义工作流。 - 以简单的键值对形式描述任务和依赖关系，相对简洁，但灵活性略逊一筹。
调度能力	- 具有强大的调度功能，支持基于时间（如定时任务）、事件（如外部事件触发）等多种调度策略。 - 可以精确设置任务的执行时间、重复周期等。	- 支持时间和数据可用性等触发机制的调度。 - 能够根据文件的存在性、特定数据的到达等条件触发工作流。	- 支持简单的基于时间的调度，如设置任务在特定时间执行或按固定周期执行。 - 调度功能相对较弱，在复杂的调度场景下可能不够灵活。
用户界面	- 提供了相对直观、现代化的 Web 界面。 - 可以方便地查看工作流状态、任务执行历史、日志等信息，便于监控和管理。	- Web 界面相对简陋，功能主要集中在工作流的提交、查看状态等基本操作上。 - 用户体验一般，但能满足基本需求。	- 提供 Web 界面用于查看工作流和任务状态。 - 界面简洁，侧重于展示工作流的执行情况，功能不是非常丰富。
与其他工具集成	- 与多种大数据工具和平台有较好的集成能力，如可以与 Hadoop、Spark 等无缝协作。 - 由于其 Python - based 的特性，易于与其他 Python 库和工具集成，方便扩展功能。	- 紧密集成于 Hadoop 生态系统，特别适合与 Hive、MapReduce 等 Hadoop 组件配合使用。 - 主要针对 Hadoop 相关的工作流管理，对其他非 Hadoop 工具的集成相对有限。	- 与 Hadoop 生态集成良好，能有效管理 Hadoop 中的任务流。 - 在与非 Hadoop 工具集成方面存在一定局限性。
可扩展性	- 具有较好的可扩展性，通过 Python 代码可以方便地添加新的任务类型、操作符等。 - 社区活跃，不断有新的插件和扩展开发出来。	- 可扩展性相对较差，由于基于 XML 的配置方式，添加新功能需要对 XML 结构和相关代码进行修改。 - 依赖于 Hadoop 生态系统的发展，自身扩展能力有限。	- 可扩展性一般，虽然可以自定义任务类型，但相比 Airflow 不够灵活。 - 社区规模较小，可获取的扩展资源相对较少。
容错性	- 提供了一定的容错机制，如任务重试、依赖关系管理等。 - 如果某个任务失败，可以根据配置进行重试或根据依赖关系决定后续任务的执行。	- 具有容错能力，能够在任务失败时进行重试或按照预定义的流程处理失败情况。 - 在 Hadoop 环境中，可以利用 Hadoop 的容错特性来保证工作流的稳定运行。	- 支持任务失败时的重试机制。 - 容错功能相对基础，在复杂的容错场景下可能需要更多的手动配置。
管理最细粒度	- 任务和操作符级别。 - 可以精确到单个任务设置执行逻辑、依赖关系、资源分配、重试策略等；操作符层面可设置特定属性如函数输入参数、运行环境等。	- 动作级别。 - 在 XML 文件中的动作标签内设置如 Hive 查询语句、MapReduce 输入输出路径等具体参数，也可设置动作失败时的重试相关属性。	- 作业级别。 - 在.job 文件中设置作业的执行命令、依赖关系、执行环境、失败重试次数等参数。
使用场景	- 数据工程与分析：适用于各种数据处理流程，如数据抽取、转换、加载（ETL），从多个数据源（如关系型数据库、文件系统、API 等）获取数据，经过清洗、转换后加载到数据仓库或数据湖中。 - 机器学习工作流：管理机器学习模型的训练、评估和部署流程。可以安排数据预处理、模型训练（使用不同算法和参数）、模型评估（如交叉验证）以及模型部署到生产环境等任务的顺序和调度。 - 混合环境任务编排：在包含多种技术栈（如既有大数据组件又有传统数据库操作）的环境中，协调不同任务的执行顺序和依赖关系。例如，先在传统数据库中执行查询获取初始数据，然后将数据传递给 Spark 进行复杂分析。	- Hadoop 生态系统内的工作流管理：主要用于 Hadoop 相关的任务编排，如在 Hive 中执行复杂的数据分析查询，然后使用 MapReduce 进行数据处理，再将结果存储到 HDFS 中。 - 数据仓库构建与维护：在基于 Hadoop 的数据仓库项目中，协调 ETL 流程，包括从数据源将数据抽取到 Hadoop 集群，使用 Hive 进行数据转换和清洗，最后将处理好的数据加载到数据仓库的相应表中。	- Hadoop 任务流管理：适用于简单的 Hadoop 任务流程，如定期执行 MapReduce 作业、Hive 查询等。 - 数据处理自动化：对于一些基本的数据处理任务，如数据备份、文件格式转换等，在 Hadoop 环境下进行自动化管理。

总结：

• 复杂业务，海量数据，首选Oozie
• 需要轻量级、易于上手的工具，选Azkaban
• Python环境，选Airflow