发帖
雷达卡
距离考试还有10天，面对这19页的大纲内容感到有些力不从心，但还是要系统梳理一遍重点知识。以下是根据课本内容整理的核心知识点精要。
第1章 大数据技术概述
大数据的处理流程通常包括多个关键环节：首先是数据采集，获取来自不同源的数据；接着是数据的存储与管理，确保数据安全且可访问；然后进行数据的处理与分析，挖掘其中的价值；最后通过可视化等方式将结果呈现出来。
在大数据领域中，存在多种计算模式，每种模式都有其对应的代表性产品：
- 批处理计算：适用于大规模离线数据处理，典型代表有MapReduce和Spark。
- 流计算：用于实时数据处理，常见框架包括Flink、Storm、Spark Streaming以及S4。
- 图计算：针对图结构数据进行高效运算，如Pregel、GraphX和Giraph。
- 查询分析计算：支持快速查询与即席分析，代表工具有Dremel、Hive和Cassandra等。
Hadoop生态系统由多个组件构成，各司其职，共同支撑起分布式大数据处理能力。这些组件协同工作，形成一个完整的数据处理平台。
在HDFS（Hadoop分布式文件系统）中，名称节点（NameNode）作为主控服务器，负责管理整个文件系统的命名空间，并控制客户端对文件的访问权限。而数据节点（DataNode）则承担实际的数据读写任务，在名称节点的调度下完成数据块的创建、删除和复制操作。
MapReduce的设计思想强调“计算向数据靠拢”，即尽量将计算任务调度到数据所在的位置执行，以减少网络传输开销，提高整体效率。
YARN作为资源调度管理框架，主要功能是统一管理和分配集群中的计算资源。它的引入提升了集群利用率，避免了因数据跨集群移动带来的额外成本，同时降低了企业的运维负担。
Hive是一个构建在Hadoop之上的数据仓库工具，能够对存储于Hadoop文件系统中的数据集进行整理、查询和分析，尤其适合处理结构化数据的批处理任务。
尽管Hadoop应用广泛，但也存在一些缺陷：例如表达能力受限、磁盘I/O开销较大、处理延迟较高等问题。相比之下，Spark展现出更多优势：具备更强的表达能力、更高的迭代计算效率，并采用基于DAG的任务调度机制，显著提升了性能表现。
为了实现Spark与Hadoop的统一部署，可以通过共享底层HDFS存储并利用YARN进行资源调度，从而在一个集群内同时运行两种框架，提升资源利用率和系统灵活性。
Flink与Spark在实现机制上有本质区别：Flink将所有任务都视为流处理，无论是有界还是无界数据；而Spark本质上是以批处理为基础，即使是流处理也是通过微批次方式模拟实现。
Apache Beam的设计目标是为开发者提供一个统一、强大且易用的数据并行处理模型，既能支持流处理也能支持批处理，并能兼容多种执行引擎（如Flink、Spark、Dataflow）。其优点在于开源、架构统一，有助于降低开发和维护成本。
第2章 Flink的设计与运行原理
传统数据处理架构存在明显局限性：一旦系统出现异常，影响范围广，恢复困难，难以保障服务的持续性和稳定性。
Lambda架构虽然在一定程度上简化了系统构建过程，并解决了批流异构的问题，但带来了平台复杂度高、多框架并存导致运维难度加大的弊端。
相较之下，流处理架构具有显著优势：它既避免了传统架构中数据库负载过重的问题，也解决了Lambda架构中多个框架难以统一管理的困境，实现了更高效的资源整合与运维简化。
Flink在企业中有广泛应用场景：
- 事件驱动型应用：如反欺诈系统、异常行为检测、基于规则的实时报警、业务流程监控及Web应用响应等。
- 数据分析应用：涵盖电信网络质量监控、移动应用版本更新与A/B测试评估、消费者技术领域的实时数据即席分析等。
- 数据流水线应用：例如电商环境中实时构建搜索索引、持续进行ETL（抽取、转换、加载）流程等。
Flink的核心组件栈分为多个层次，每一层专注于不同的功能模块，从底层运行时到顶层API，形成了完整的编程与执行体系。
在Flink集群中，JobManager负责全局任务的调度与资源协调，是整个系统的控制中心；TaskManager则是工作节点，负责具体任务的执行，并在各自节点上申请和管理计算资源。
对主流大数据处理框架进行对比分析如下：
| 对比维度 | Storm | Flink | Spark |
|---|---|---|---|
| 核心定位 | 原生流处理（仅支持无界流） | 原生流处理（批流统一） | 原生批处理（微批流） |
| 处理模型 | 单事件驱动 | 事件驱动+Pipeline | 微批模拟 |
| 延迟级别 | 亚毫秒~毫秒级 | 毫秒级 | 秒级（依赖微批） |
| 吞吐量 | 低 | 高（兼顾延迟） | 高（批处理优化） |
| 时间语义 | 仅处理时间（基础版） | 支持处理/事件/摄入时间 + Watermark | 1.6+支持事件时间（功能较弱） |
| 状态管理 | 无原生支持（需第三方） | 原生支持Keyed/Operator State | 无原生支持（依赖缓存或外部系统） |
| 容错机制 | Acker机制 | 分布式快照（异步增量） | Lineage + 全量Checkpoint |
| 容错语义 | At-Least-Once | 原生Exactly-Once | 默认At-Least-Once |
| 适用场景 | 超低延迟实时场景 | 低延迟+有状态流处理 | 批处理+近实时流处理 |
在分布式系统中，数据一致性的实现通常遵循三种基本模式：最多一次、至少一次以及精确一次。这三种模式描述了消息传递或状态更新过程中对一致性保障的不同级别。
“最多一次”模式确保消息或操作最多被处理一次，但不保证一定成功送达或执行，可能存在丢失的情况，适用于对性能要求高而对可靠性容忍度较高的场景。
“至少一次”模式则保证消息或操作会被处理一次或多次，系统会通过重试机制来确保不丢失，但可能引发重复处理的问题，因此需要配合幂等性设计来避免副作用。
“精确一次”模式是最高级别的保障，它确保每个消息或操作仅被处理一次且不会丢失，实现了既无遗漏也无重复的理想状态，常用于对数据准确性要求极高的应用场景。
Flink采用的异步屏障快照机制（Asynchronous Barrier Snapshotting）是一种高效的状态备份方法，专为DAG（有向无环图）或DCG（有向循环图）结构的流式计算作业设计。
该机制通过插入轻量级的同步屏障（barrier）到数据流中，逐步触发各算子状态的异步快照，从而在几乎不影响正常计算流程的前提下完成全局状态的一致性检查点（checkpoint）创建。
由于快照过程与计算任务并行执行，并利用了异步写入和状态增量保存技术，因此能够以较低的资源开销实现高频次的状态持久化，极大提升了容错能力而不牺牲吞吐性能。
第三章 大数据实验环境搭建
京公网安备 11010802022788号
