【大数据处理技术】第三篇 大数据处理与分析（持续更新）

---

第7章 MapReduce

7.1 概述

7.1.1 分布式并行编程

7.1.2 MapReduce 模型简介

7.1.3 Map 和 Reduce 函数

7.2 Mapreduce的工作流程

7.2.1 工作流程概述

7.2.2 MapReduce 的各个执行阶段

7.2.3 Shuffle 过程详解

7.3 实例分析：WordCount

7.4 MapReduce的具体应用

7.5 MapReduce编程实践

---

第8章 Hadoop再探讨

8.1 Hadoop的优化与发展

8.1.1 Hadoop 的局限与不足

8.1.2 针对Hadoop 的改进与提升

8.2 HDFS 2.0 的新特性

8.2.1 HDFS HA

8.2.2 HDFS 联邦

8.3 新一代资源管理调度框架YARN

8.3.1 MapReduce 1.0 缺陷

8.3.2 YARN 设计思路

8.3.3 YARN 体系结构

8.3.4 YARN 工作流程

8.3.5 YARN框架 与 MapReduce1.0框架 对比分析

8.3.6 YARN 的发展目标

8.4 Hadoop生态系统中具有代表性的功能组件8.4.1

8.4.1 Pig

8.4.2 Tez

8.4.2 Kafka

---

第9章 数据仓库Hive

9.1 概述

9.1.1 数据仓库概念

9.1.2 传统数据仓库面临的挑战

9.1.3 Hive 简介

9.1.4 Hive 与 Hadoop生态系统中其他组件的关系

9.1.5 Hive 与传统数据库的对比分析

9.1.6 Hive 在企业中的部署和应用

9.2 Hive系统框架

9.3 Hive工作原理

9.3.1 SQL语句

9.3.2 SQL查询

9.4 Hive HA基本原理

9.5 Impala

9.5.1 Impala 简介

9.5.2 Impala 系统架构

9.5.3 Impala 查询执行过程

9.5.4 Impala 与 Hive 比较

9.6 Hive编程实践

---

第10章 Spark

10.1 概述

10.1.1 Spark 简介

10.1.2 Scala 简介

10.1.3 Spark 与 Hadoop 对比

10.2 Spark生态系统

10.3 Spark运行架构

10.3.1 基本概念

10.3.2 架构设计

10.3.3 Spark 运行基本流程

10.3.4 RDD 设计与运行原理

10.4 Spark的部署和应用方式

10.4.1 Spark 部署方式

10.4.2 “Hadoop + Storm”架构 转向 Spark架构

10.4.3 Hadoop 和 Spark 的统一部署

10.5 Spark编程实践

---

第11章 流计算

11.1 流计算概述

11.1.1 静态数据 和 流数据

11.1.2 批量计算 和 实时计算

11.1.3 流计算的概念

11.1.4 流计算 与 Hadoop

11.1.5 流计算框架

11.2 流计算的处理流程

11.2.1 概述

11.2.2 数据实时采集

11.2.3 数据实时计算

11.2.4 实时查询服务

11.3 流计算的应用

11.4 开源流计算框架Storm

11.4.1 Storm 简介

11.4.2 Storm 特点

11.4.3 Storm 设计思想

11.4.4 Storm 框架设计

11.4.5 Storm 实例

11.5 Spark Streaming

11.5.1 Spark Streaming 设计

11.5.2 Spark Streaming 与 Storm 对比

---

第12章 Flink

12.1 Flink简介

• Flink是Apache软件基金会的一个顶级项目，是为分布式、高性能、随时可用和准确的流处理应用程序打造的开源流处理框架，可以同时支持实时计算和批量计算。
• Flink是一种具有代表性的开源流处理架构，具有十分强大的功能，可以支持不同类型的应用程序。
• Flink实现了Google Dataflow流计算模型，是一种兼具高吞吐、低延迟、高性能的实时流计算框架，同时支持批处理和流处理。
• Flink的 主要特性包括：
  • 批流一体化
  • 精密的状态管理
  • 事件时间支持以及精确一次的状态一致性保障。
• Flink 不仅可以运行在包括 YARN、 Mesos、Kubernetes等在内的多种资源管理框架上，还支持在裸机集群上独立部署。
• 在启用高可用选项的情况下，它不存在单点失效问题。

12.2 为什么选择Flink

数据架构领域由传统数据处理架构、大数据Lambda架构向流处理架构演变，在这种全新的架构中，给予流的数据处理流程被视为整个架构设计的核心。

12.2.1 传统数据处理架构

• 传统数据处理架构的一个显著特点就是采用一个 中心化的数据库系统，用于存储事务性数据。
  

12.2.2 大数据Lambda架构

• 大数据Lambda架构主要包含两层，即批处理层和实时处理层
• 在批处理层中，采用MapReduce、Spark等技术进行批量数据处理
• 在实时处理层中，则采用Storm、Spark Streaming等技术进行数据的实时处理。
  

12.2.3 流处理架构

• 为了高效地实现流处理架构，一般需要设置消息传输层和流处理层 （如图所示）。
  • 消息传输层从各种数据源采集连续事件产生的数据， 并传输给订阅了这些数据的应用程序
  • 流处理层会持续地将数据在 应用程序和系统间移动，聚合并处理事件，并在本地维持应用程序 的状态。
    
• 流处理架构的核心是使各种应用程序互连在一起的消息队列，消息队列连接应用程序，并作为新的共享数据源，这些消息队列取代了从前的大型集中式数据库。
• 如图所示，流处理器从消息队列中订阅数据并加以处理，处理后的数据可以流向另一个消息队列， 其他应用程序都可以共享流数据。
• 在一些情况下，处理后的数据会被存放到本地数据库中。
  
• 流处理架构正在逐步取代传统数据处理架构和Lambda架构，成为大数据处理架构的一种新趋势。
• 一方面，由于流处理架构中不存在一个大型集中式数据库，因此， 避免了传统数据处理架构中存在的“数据库不堪重负”的问题。
• 另一方面，在流处理架构中，批处理被看成是流处理的一个子集， 因此，就可以用面向流处理的框架进行批处理，这样就可以用一 个流处理框架来统一处理流计算和批量计算，避免了Lambda架构 中存在的“多个框架难管理”的问题。

12.2.4 Flink是理想的流计算框架

• 流处理架构需要具备低延迟、高吞吐和高性能的特性，而目前从 市场上已有的产品来看，只有Flink可以满足要求。
• Storm虽然可以做到低延迟，但是无法实现高吞吐，也不能在故 障发生时准确地处理计算状态。
• Spark Streaming通过采用微批处理方法实现了高吞吐和容错性， 但是牺牲了低延迟和实时处理能力。
• Flink实现了Google Dataflow流计算模型，是一种兼具高吞吐、 低延迟和高性能的实时流计算框架，并且同时支持批处理和流处理。此外，Flink支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现丢失。因此，Flink就成为了能够满足流处理架构要求的理想的流计算框架。
  

12.2.5 Flink的优势

• 同时支持高吞吐、低延迟、高性能
• 同时支持流处理和批处理
• 高度灵活的流式窗口
• 支持有状态计算
• 具有良好的容错性
• 具有独立的内存管理
• 支持迭代和增量迭代

12.3 Flink应用场景

12.3.1 事件驱动型应用

12.3.2 数据分析应用

12.3.3 数据流水线应用

12.4 Flink技术栈

12.5 Flink体系架构

• Flink系统主要由两个组件组成，分别为JobManager和TaskManager
• Flink 架构遵循Master-Slave架构设计原则：JobManager为Master 节点，TaskManager为Slave节点。
  

12.6 Flink编程模型

• Flink 提供了不同级别的抽象（如图所示），以开发流或批处理作业。
  
  【Flink 的应用程序结构】
• 一个完整的Flink应用程序结构包含如下三个部分：
  • 数据源（Source）：Flink 在流处理和批处理上的数据源大概有4类：基于 本地集合的数据源、基于文件的数据源、基于网络套接字的数据源、自定义的数 据源。常见的自定义数据源包括Apache kafka、Amazon Kinesis Streams、 RabbitMQ、Twitter Streaming API、Apache NiFi等，当然用户也可以定义自己 的数据源。
  • 数据转换（Transformation）：数据转换的各种操作包括map、 flatMap、 filter、keyBy、reduce、aggregation、window、windowAll、union、select等， 可以将原始数据转换成满足要求的数据。
  • 数据输出（Sink）：数据输出是指Flink将转换计算后的数据发送的目的地。 常见的数据输出包括写入文件、打印到屏幕、写入Socket 、自定义Sink等 。常 见的自定义Sink有Apache kafka、RabbitMQ、MySQL、ElasticSearch、 Apache Cassandra、Hadoop FileSystem 等。
    

【Flink中的数据一致性】

• 对于分布式流处理系统而言，高吞吐、低延迟往往是最主 要的需求。与此同时，数据一致性在分布式系统中也很重 要，对于正确性要求较高的场景，“精确一次”一致性的 实现往往也非常重要。如何保证分布式系统有状态计算的 一致性，是Flink作为一个分布式流计算框架必须要解决的 问题。
• Flink通过异步屏障快照机制来实现“精确一次”一致性的 保证，当任务中途崩溃或者取消之后，可以通过检查点或 者保存点来进行恢复，实现数据流的重放，从而让任务达 到一致性的效果，同时，这种机制不会牺牲系统的性能。

【有状态计算】

• 流计算分为无状态和有状态两种情况。无状态计算观察每个独立的事 件，每一条消息来了以后和前后其他消息都没有关系，比如一个应用 程序实时接收温度传感器的数据，当温度超过40度时就报警，这就是 无状态的数据。
• 有状态计算则会基于多个事件输出结果，比如，计算 过去1个小时的平均温度，就属于有状态计算。
  
  【数据一致性】
• 当在分布式系统中引入状态时，自然也引入了一致性问题。根据正确性级别 的不同，一致性可以分为如下三种形式：
  • 最多一次（at-most-once）：尽可能正确，但不保证一定正确。也就是 说，当故障发生时，什么都不做，既不恢复丢失状态，也不重播丢失的数据。 这就意味着，在系统发生故障以后，聚合结果可能会出错。
  • 至少一次（at-least-once）：在系统发生故障以后，聚合计算不会漏掉 故障恢复之前窗口内的事件，但可能会重复计算某些事件，这通常用于实时 性较高但准确性要求不高的场合。该模式意味着系统将以一种更加简单的方 式来对算子的状态进行快照处理，系统崩溃后恢复时，算子的状态中有一些 记录可能会被重放多次。例如，失败后恢复时，统计值将等于或者大于流中 元素的真实值。
  • 精确一次（exactly-once）：在系统发生故障后，聚合结果与假定 没有发生故障情况时一致。该模式意味着系统在进行恢复时，每条记录 将在算子状态中只被重播一次。例如在一段数据流中，不管该系统崩溃 或者重启了多少次，该统计结果将总是跟流中的元素的真实个数一致。 这种语义加大了高吞吐和低延迟的实现难度。与“至少一次”模式相比， “精确一次”模式整体的处理速度会相对比较慢，因为在开启“精确一 次”模式后，为了保证一致性，就会开启数据对齐，从而会影响系统的 一些性能。

12.7 Flink编程实践

【大数据处理技术】实验9: Flink编程实践

12.7.1 安装Flink

12.7.2 编程实现WordCount程序

---

第13章 图计算

13.1 图计算 简介

13.1.1 传统图计算解决方案的不足

13.1.2 通用图计算软件

13.2 Pregel 简介

13.3 Pregel 图计算模型

13.3.1 有向图和顶点

13.3.2 顶点之间的消息传递

13.3.3 Pregel 计算过程

13.4 Pregel 的C++API

13.4.1 消息传递机制

13.4.2 Combiner

13.4.3 Aggregator

13.4.4 拓扑改变

13.4.5 输入和输出

13.5 Pregel 的体系结构

13.5.1 Pregel 执行过程

13.5.2 容错性

13.5.3 Worker

13.5.4 Master

13.5.5 Aggregator

13.6 Pregel 的应用实例

13.6.1 单源最短路径

13.6.2 二分匹配

13.7 Pregel 和 MapReduce实现PageRank算法的对比

13.7.1 PageRank 算法

13.7.2 PageRank 算法在 Pregel 中的实现

13.7.3 PageRank 算法在 MapReduce 中的实现

13.7.4 PageRank 算法在 Pregel 和 MapReduce 中实现的比较

---

第14章 数据可视化

14.1 可视化概述

14.1.1 什么是 数据可视化

14.1.2 可视化的发展历程

14.1.3 可视化的重要作用

14.2 可视化工具

14.2.1 入门级工具

14.2.2 信息图表工具

14.2.3 地图工具

14.2.4 时间线工具

14.2.5 高级分析工具

14.3 可视化经典案例

14.3.1 全球黑客活动

14.3.2 互联网地图

14.3.3 编程语言之间的影响力关系

14.3.4 世界国家健康与财富之间的关系

14.3.5 3D可视化互联网地图App

---