Week_12 总结

大数据技术发展史

• 2004 年 google 的三篇论文

• 分布式文件系统 GFS

• 大数据分布式计算框架 mapreduce

• Nosql 数据库系统 BigTable

这三部分组成了大数据的“三驾马车”。他们是为了解决当时搜索引擎进行网页抓取后，大量数据的存储和计算问题。

• 2006 年 lucene 的创始人 Doug Cutting 根据论文原理实现了类似的 GFS 和 mapreduce 功能，然后从启动了一个独立的项目专门开发维护大数据技术，这就是 hadoop（分布式文件系统 hdfs 和大数据计算引擎 MapReduce）

• 2007 之后，随着更多的公司使用 hadoop 进行大数据存储于计算，hadoop 随之在软件开发领域壮大

• 在 MapReduce 的使用过程，Yahoo 开发了 Pig 脚本语言，简化 MapReduce 对大数据集合的操作复杂度

• Facebook 开发了 Hive，通过 Sql 语法来进行大数据计算，进一步降低 Hadoop 使用难度

• Hive 的出现催动了大数据生态体系的发展，Hadoop 周边产品陆续出现，生态体系逐渐形成：

• 专门将关系数据库中的数据导入导出到 Hadoop 平台的 Sqoop；

• 针对大规模日志进行分布式收集、聚合和传输的 Flume；

• MapReduce 工作流调度引擎 Oozie 。

大数据技术体系

早期，hadoop 的大数据计算引擎 MapReduce，即是一个执行引擎，又是一个资源调度框架。职责不单一，不利于资源复用，因此出现了 Yarn，将资源调度系统独立出来。

与此同时，由于 MapReduce 进行多次迭代计算，尤其是进行机器学习时，性能很差，再加上硬件技术的进步，由 Spark 取代了 MapReduce 的地位。

MapReduce 与 Spark 这样的大数据计算框架，是以历史数据为处理对象，进行离线计算的，计算周期以“天”为单位。在大数据领域还有一类应用场景是针对实时数据进行大规模即时计算，通常称为大数据流计算或者大数据实时计算。

HBase 是从 Hadoop 中分离出来，基于 HDFS 的 NoSql 系统，用于大规模的数据存储与访问

整个大数据技术体系，底层是 HDFS 构成的存储层，之上承载着大数据批处理和流处理，以及相应的大数据存储的接入层（各种 NoSql 数据库）。在此之上，有用于大数据分析的 Hive 和 Spark SQl，数据挖掘和机器学习的 Mahout,MLib,TensorFlow 等应用，所有这些构成了整个大数据技术体系。

大数据技术发展史

大数据应用的搜索引擎时代

大数据技术源于 Google 搜索引擎技术的发展，由于搜索引擎需要对获取到的网页进行词频统计，网页排名等计算，而这些网页的数据规模达到万亿级规模，因此，对数万块磁盘上文件进行处理计算的需求，催生了大数据技术。

大数据应用的数据仓库时代

早期的数据分析与统计，仅限于数据库。在有限的数据量和计算能力下，只对重要的数据进行统计与分析（即做专门的程序用于处理相应逻辑），这些数据通常用于决策层决策或了解。

大数据的仓库时代，只要有数据分析的需求，通过低廉的代价（Hive 的 Sql 操作），任何人都可以对自己所关心的数据进行分析，获取到所要的结果

大数据应用的数据挖掘时代

在大数据技术的使用过程中，通过分析深挖事物之间的关系，找到规律，为将来提供决策支持。

数据挖掘涉及六类常见的任务：

• 异常检测（异常/变化/偏差检测）– 识别不寻常的数据记录，错误数据需要进一步调查。

• 关联规则学习（依赖建模）– 搜索变量之间的关系。例如，一个超市可能会收集顾客购买习惯的数据。运用关联规则学习，超市可以确定哪些产品经常一起买，并利用这些信息帮助营销。这有时被称为市场购物篮分析。

• 聚类 – 是在未知数据的结构下，发现数据的类别与结构。

• 分类 – 是对新的数据推广已知的结构的任务。例如，一个电子邮件程序可能试图将一个电子邮件分类为“合法的”或“垃圾邮件”。

• 回归 – 试图找到能够以最小误差对该数据建模的函数。

• 汇总 – 提供了一个更紧凑的数据集表示，包括生成可视化和报表。

大数据应用的机器学习时代

人们很早就发现，数据中蕴藏着规律，这个规律是所有数据都遵循的，过去发生的事情

遵循这个规律，将来要发生的事情也遵循这个规律。一旦找到了这个规律，对于正在发

生的事情，就可以按照这个规律进行预测。

通过计算过往的历史数据和经验，获取其统计规律，从而有能力预测将来要发生的事情

大数据技术应用领域

• 医学影像智能识别

• 病历大数据智能诊疗

• AI 外语老师

• 智能解题

• 舆情监控与分析

• 大数据风控

• 新零售

• 无人驾驶

HDFS

hdfs 架构

• hdfs 是整个大数据体系的基础

• namenode 节点存储所有 datanodes 的元信息

1. 文件系统的目录结构，相应元信息（如文件名，文件目录结构，生成时间,副本数,文件权限）

2. 文件与数据块以及块位置的映射关系

3. 周期性地从集群中的每个 DataNode 接收心跳信号和块状态报告(该 datanode 上所有数据块的列表)

4. 元信息的高可用：日志文件和镜像文件，通过这两个文件进行元数据的恢复。

5. 空间回收

• datanode 在本地文件系统存储文件块数据，以及块数据的校验和。可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容。默认块大小是 64M。

• 数据本身

• 数据块长度，校验和，时间戳

• 启动后向 namenode 注册，周期性汇报块信息

• 每 3 秒心跳一次，结果中带有 namenode 的命令，如复制命令和删除命令

hdfs 数据存储组织结构

hdfs 中数据节点以下列方式进行组织，所有这些 datanode 周期性的向 namenode 上报自己的信息

hdfs 数据写入过程

写入文件 two.txt：

1. namenode 检查是否已存在和是否有权限

2. 检查通过后，创建该文件，返回可写 datanode 列表

3. 客户端通过 sdk 找列表中第一个 datanode，建立连接，切分数据，发起写

4. 第一个 datanode 写数据时，根据副本数向另一个 datanode 复制副本，复制完毕，继续向下一个 datanode 建立连接进行副本复制，直到满足副本数。之后发送确认信息，沿管道返回到客户端，表明这个分片写完毕

hdfs 数据读取过程

namenode 存储的信息如下

文件路径，副本数，副本在哪些 datanodes 上

一块在 BlockA,一块在 BlockB。副本数是 3，BlockA 放到 2,5,7，BlockB 放到 3,9,11。

读取数据：

1. 向 namenode 发起文件查询请求

2. namenode 返回块位置列表

3. client 通过 sdk 连接到最近的 datanode 节点获取数据（如果读的时候发生错误，会去其他副本上读）

4. client 收到各个块的数据后，进行 merge 操作，获取到所有文件数据

hdfs 设计目标

以流式数据访问模式存储超大文件，运行于商用硬件集群上。

• 流式访问：一次写入多次读取

• 超大文件

• 商用硬件

不适合 hdfs 场景

• 大量小文件：会使 namenode 负载加重，甚至 down 机

• 要求较低延迟的数据访问

• 有大量文件随机写入的场景

hdfs 高可用

• namenode 高可用

• datanode 上磁盘坏了

• datanode 节点 down 了

• client 高可用

hdfs 数据一致性模型

• 文件创建以后，不保证在 NameNode 立即可见，即使文件刷新并存储，文件长度依

然可能为 0；

• 当写入数据超过一个块后，新的 reader 可以看见第一个块，reader 不能看见当前正

在写入的块；

• HDFS 提供 sync() 方法强制缓存与数据节点同步，sync() 调用成功后，当前写入数据

对所有 reader 可见且一致;

• 调用 sync() 会导致额外的开销.

MapReduce

• 处理海量数据，数据规模大于 1TB

• 成百上千 CPU 并发处理

• 自动实现分布式并行计算：根据在多节点上运行多程序实例处理各子任务，然后归并处理

• 容错

• 易用

MapReduce 处理流程

对数据进行分片后，map 程序在不同的节点进行 map 计算，结果以 key 为索引进行合并排序，最后汇总到 reduce 节点，有 reduce 程序进行流式的计算，得出最终结果

Mapreduce 架构

MapReduce 中，计算的对象是存入 hdfs 的数据，这些数据分布在不同的 datanode 上。相比较起通过移动数据来进行分类汇总而言，更好的方式是将计算逻辑分布到有数据的节点上。MapReduce 就是以这样的思路来进行设计的。

在进行大数据计算时，数据分布在不同的位置，那么首先要考虑的是如何将提交进来的作业处理，进而分配到不同的数据节点上？

由于提交作业的用户端可能有多个，而参与计算的资源又是有限的，因此需要排队，让系统逐一处理。MapReduce 中 JobScheduler 就负责排队调度的事情，当系统有资源进行计算时，jobScheduler 会调度一个作业进入 JobInProcess 处理。JobInProcess 会根据作业中待处理文件对应的块分布的位置，将作业分为多个任务 TaskInProcess，每个任务包含了要处理的目标数据块和相应的处理逻辑。

JobInProcess 与 TaskInProcess 共同构成了一棵任务树，所有的任务树+JobScheduler 构成了 JobTracker 进程的逻辑，而每个 datanode 中同时还对应的 TaskTracker 这样的处理进程，TaskTracker 在有计算资源的情况下，会通过心跳请求，向 JobTracker 进程请求任务。

请求任务时，JobTracker 查看该节点的是否有可分配的任务，找到后分配给 TaskTracker 中 TaskRunner 一个任务，这个任务可能是 Map 处理逻辑，也可能是 Reduce 处理逻辑。

收到任务后，Map 或者 reduce 进程通过读取本地相应的数据块进行计算，最终得到 MapReduce 计算结果，完成大数据的处理。

适合 MapReduce 的计算类型

• TopK

• K-means

• Bayes

• SQL

不适合 MapReduce 的计算类型

• Fibonacci

MapReduce 适用于适合分片的数据。斐波那契数列数据不适合分片，因此 MapReduce 不适合计算这类型的问题

MapReduce 的调度

• 单队列调度：FIFO，先来先服务

• 容量调度：多队列，每个队列设置一定系统容量，多作业可并行执行，根据队列负载情况，动态调整资源分配，同时支持作业的优先级，不足之处队列的设置与选择对用户不透明

• 公平调度：作业分组，每组平均分配相应的资源

JobTracker 结构

• 作业控制

• 作业监控层

• 任务控制层

• 任务执行层

• 资源管理

根据 TaskTracker 上报的状态信息，进行任务的分配。

Yarn

yarn 是一个独立的资源调度框架,将资源管理与作业管理进行解耦。

yarn 由两个组件构成，一个是全局的资源管理组件(RM)和每个作业相关的 ApplicationMaster(AM)。

应用程序提交作业到 RM，RM 分配计算资源给该作业，应用程序拿到计算节点后，在该节点上启动 AM，由 AM 计算该作业需要的资源数量，然后由 AM 向 RM 申请计算资源。

AM 获取资源后，根据作业情况分配相应任务到不同的节点上执行。这种方式将资源管理和作业管理解耦，提高了资源的利用率，也可以同时使用不同的计算引擎在整个数据集群上进行计算，释放了计算能力。

Hive

以 Sql 的方式进行 mapreduce 编程，然后进行数据计算处理

client 提交 Sql 到 driver，driver 通过 metastor 获取元信息，然后将 sql 提交到 compiler。由 compiler 将 Sql 进行词法语义解析，进而生成执行计划。最终执行计划提交到 hadoop 进行数据计算，获取结果