从0开始学大数据总结笔记：2、大数据生态体系主要产品原理与架构

我们常常意识不到问题的存在，直到有人解决了这些问题。

上面所有这些技术在实际部署的时候，通常会部署在同一个集群中，某台服务器可能运行着 HDFS 的 DataNode 进程，负责 HDFS 的数据存储；同时也运行着 Yarn 的 NodeManager，负责计算资源的调度管理；而 MapReduce、Spark、Storm、Flink 这些批处理或者流处理大数据计算引擎则通过 Yarn 的调度，运行在 NodeManager 的容器（container）里面。至于 Hive、Spark SQL 这些运行在 MapReduce 或者 Spark 基础上的大数据仓库引擎，在经过自身的执行引擎将 SQL 语句解析成 MapReduce 或者 Spark 的执行计划以后，一样提交给 Yarn 去调度执行。

MapReduce过程：
1、Hadoop 大数据仓库sql引擎Hive
能够直接处理我们输入的 SQL 语句（Hive 的 SQL 语法和数据库标准 SQL 略有不同），调用 MapReduce 计算框架完成数据分析操作：

Hive 的 Client（Hive 的命令行工具，JDBC 等）向 Hive 提交 SQL 命令。如果是创建数据表的 DDL（数据定义语言），Hive 就会通过执行引擎 Driver 将数据表的信息记录在 Metastore 元数据组件中，这个组件通常用一个关系数据库实现，记录表名、字段名、字段类型、关联 HDFS 文件路径等这些数据库的 Meta 信息（元信息）。如果我们提交的是查询分析数据的 DQL（数据查询语句），Driver 就会将该语句提交给自己的编译器 Compiler 进行语法分析、语法解析、语法优化等一系列操作，最后生成一个 MapReduce 执行计划。然后根据执行计划生成一个 MapReduce 的作业，提交给 Hadoop MapReduce 计算框架处理。
join操作，用两层 for 循环，对来自两张表的记录进行连接操作：

大数据 SQL 的应用场景也多样化起来，于是又开发了各种大数据 SQL 引擎：

Impala：
Cloudera 开发了 Impala，这是一种运行在 HDFS 上的 MPP 架构的 SQL 引擎。和 MapReduce 启动 Map 和 Reduce 两种执行进程，将计算过程分成两个阶段进行计算不同，Impala 在所有 DataNode 服务器上部署相同的 Impalad 进程，多个 Impalad 进程相互协作，共同完成 SQL 计算。在一些统计场景中，Impala 可以做到毫秒级的计算速度。impala的简介和Hive的比较详见：https://blog.csdn.net/qililong88/article/details/105128437

Spark的 SQL 引擎 Shark：也就是后来的 Spark SQL，Spark 比 MapReduce 快很多，Spark SQL 也相应比 Hive 快很多

NoSQL的：Phoenix：一个执行在 HBase 上的 SQL 引擎。

2、Spark
RDD 是 Spark 的核心概念，是弹性数据集（Resilient Distributed Datasets）的缩写。RDD 既是 Spark 面向开发者的编程模型，又是 Spark 自身架构的核心元素。
MapReduce 针对输入数据，将计算过程分为两个阶段，一个 Map 阶段，一个 Reduce 阶段，可以理解成是面向过程的大数据计算
Spark 直接针对数据进行编程，将大规模数据集合抽象成一个 RDD 对象，然后在这个 RDD 上进行各种计算处理，得到一个新的 RDD，继续计算处理，直到得到最后的结果数据。所以 Spark 可以理解成是面向对象的大数据计算
作为编程模型：RDD 上定义的函数分两种，一种是转换（transformation）函数，这种函数的返回值还是 RDD；另一种是执行（action）函数，这种函数不再返回 RDD。RDD 定义了很多转换操作函数，比如有计算 map(func)、过滤 filter(func)、（map、filter不会出现新的分片，叫惰性计算）合并数据集 union(otherDataset)、根据 Key 聚合 reduceByKey(func, [numPartitions])、连接数据集 join(otherDataset, [numPartitions])、分组 groupByKey([numPartitions]) 等十几个函数。
另一种是执行（action）函数，这种函数不再返回 RDD。

作为架构核心元素：Spark 分布式计算的数据分片、任务调度都是以 RDD 为单位展开的，每个 RDD 分片都会分配到一个执行进程去处理。
Spark 应用程序代码中的 RDD 和 Spark 执行过程中生成的物理 RDD 不是一一对应的

Spark 的架构原理
Spark 任务调度器可以根据 DAG 的依赖关系执行计算阶段：DAG 也就是有向无环图
Spark 作业调度执行的核心： DAG，有了 DAG，整个应用就被切分成哪些阶段，每个阶段的依赖关系也就清楚了。再根据每个阶段要处理的数据量生成相应的任务集合（TaskSet），每个任务都分配一个任务进程去处理，Spark 就实现了大数据的分布式计算。
DAG 生成和管理的组件是 DAGScheduler
Spark 也需要通过 shuffle 将数据进行重新组合，计算阶段划分的依据是 shuffle，不是转换函数的类型。
不需要进行 shuffle 的依赖，在 Spark 里被称作窄依赖；需要进行 shuffle 的依赖，被称作宽依赖。

为什么spark更快？
Spark 可以算作是一种 MapReduce 计算模型的不同实现。Hadoop MapReduce 简单粗暴地根据 shuffle 将大数据计算分成 Map 和 Reduce 两个阶段，然后就算完事了。而 Spark 更细腻一点，将前一个的 Reduce 和后一个的 Map 连接起来，当作一个阶段持续计算，形成一个更加优雅、高效地计算模型，虽然其本质依然是 Map 和 Reduce。但是这种多个计算阶段依赖执行的方案可以有效减少对 HDFS 的访问，减少作业的调度执行次数，因此执行速度也更快。**Spark 有三个主要特性：RDD 的编程模型更简单，DAG 切分的多阶段计算过程更快速，使用内存存储中间计算结果更高效。**这三个特性使得 Spark 相对 Hadoop MapReduce 可以有更快的执行速度，以及更简单的编程实现。

Spark 的运行流程，
首先，Spark 应用程序启动在自己的 JVM 进程里，即 Driver 进程，启动后调用 SparkContext 初始化执行配置和输入数据。SparkContext 启动 DAGScheduler 构造执行的 DAG 图，切分成最小的执行单位也就是计算任务。
然后 Driver 向 Cluster Manager 请求计算资源，用于 DAG 的分布式计算。Cluster Manager 收到请求以后，将 Driver 的主机地址等信息通知给集群的所有计算节点 Worker。
Worker 收到信息以后，根据 Driver 的主机地址，跟 Driver 通信并注册，然后根据自己的空闲资源向 Driver 通报自己可以领用的任务数。Driver 根据 DAG 图开始向注册的 Worker 分配任务。
Worker 收到任务后，启动 Executor 进程开始执行任务。Executor 先检查自己是否有 Driver 的执行代码，如果没有，从 Driver 下载执行代码，通过 Java 反射加载后开始执行。

3、BigTable 对应的 NoSQL 系统 HBase
HBase 作为 Google BigTable 的开源实现，完整地继承了 BigTable 的优良设计。架构上通过数据分片的设计配合 HDFS，实现了数据的分布式海量存储（HBase是基于HDFS存储的，每个DataNode安装多个hregion，hfile是一个hdfs文件，本身就分片后多个备份存储，不需要迁移。）；数据结构上通过列族的设计，实现了数据表结构可以在运行期自定义；存储上通过 LSM 树的方式，使数据可以通过连续写磁盘的方式保存数据，极大地提高了数据写入性能。
NoSQL，主要指非关系的、分布式的、支持海量数据存储的数据库设计模式。

可伸缩：
数据以 HRegion 为单位进行管理
HRegionServer 是物理服务器，每个 HRegionServer 上可以启动多个 HRegion 实例。 HRegion 中写入的数据太多，达到配置的阈值时，分裂成两个 HRegion，并在整个集群中迁移，使 HRegionServer 的负载均衡。HRegion 存 Key 值区间[key1, key2) ，HBase 会启动多个 HMaster，并通过 ZooKeeper 选举出一个主服务器，通过HMaster获取HRegionServer的地址。
可扩展数据模型
HBase：支持列族结构的 NoSQL 数据库，在创建表的时候，只需要指定列族的名字，无需指定字段（Column）。那什么时候指定字段呢？可以在数据写入时再指定。通过这种方式，数据表可以包含数百万的字段，这样就可以随意扩展应用程序的数据结构了。并且这种数据库在查询时也很方便，可以通过指定任意字段名称和值进行查询。
高性能存储
HBase 使用 LSM 树的数据结构进行数据存储（Log Structed Merge Tree）Log 结构合并树：数据写入的时候以 Log 方式连续写入，异步对磁盘上的多个 LSM 树进行合并，数据写操作（i，u，d）都在内存中进行（也是一颗排序树），超过内存阈值，与磁盘上最新的LSM树合并

4、流计算框架有 Storm、Spark Streaming、Flink

流式架构本质上是事件驱动（event-Driven）架构，流由段（segment）组成，段由事件（event）组成，事件由字节（bytes）组成，事件大小有限，而字节流大小无限

storm模仿消息队列，把消息队列中与业务逻辑无关的过程部分抽象出来形成标准框架，实现复用。
Spark Streaming 主要负责将流数据转换成小的批数据，剩下的就可以交给 Spark 去做了。
Flink 既可以流处理又可以批处理，
如果要进行流计算，Flink 会初始化一个流执行环境 StreamExecutionEnvironment，然后利用这个执行环境构建数据流 DataStream。
如果要进行批处理计算，Flink 会初始化一个批处理执行环境 ExecutionEnvironment，然后利用这个环境构建数据集 DataSet。
执行引擎是相同的，只是数据源不同。

5、分布式系统一致性与 ZooKeeper 的架构
CAP 原理：
一致性，每次读取的数据都应该是最近写入的数据或者返回一个错误（Every read receives the most recent write or an error），而不是过期数据，也就是说，数据是一致的。
可用性，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。
分区耐受性，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。
当网络分区失效（往往必定发生）发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性就得不到保证。

ZooKeeper 主要提供数据的一致性服务，实现分布式系统的状态一致性依赖 Paxos 的算法。Paxos 算法在多台服务器通过内部的投票表决机制决定一个数据的更新与写入。
ZooKeeper 通过一种树状结构记录数据。
大数据系统依赖 ZooKeeper 提供的一致性数据服务，选举集群当前工作的主服务器。一台主服务器启动后向 ZooKeeper 注册自己为当前工作的主服务器，因此另一台服务器就只能注册为热备主服务器，应用程序运行期都和当前工作的主服务器通信。

《Effective Java》
《敏捷软件开发：原则、模式与实践》
《企业应用架构模式》