MapReduce

作者: seriouszyx 首发地址： https://seriouszyx.top/ 代码均可在 Github 上找到（求Star） 最近想要了解一些前沿技术，不能一门心思眼中只有 web，因为我目前对 Java 语言及其生态相对熟悉，所以在网上搜集了 Hadoop 相关文章，并做了整合。 本篇文章在于对大数据以及 Hadoop 有一个直观的概念，并上手简单体验。 Hadoop 基础概念 Hadoop 是一个用 Java 实现的开源框架，是一个分布式的解决方案，将大量的信息处理所带来的压力分摊到其他服务器上。 在了解各个名词之前，我们必须掌握一组概念。 结构化数据 vs 非结构化数据 结构化数据 即行数据，存储在数据库里，可以用二维表结构来表达，例如：名字、电话、家庭住址等。 常见的结构化数据库为 mysql、sqlserver。 非结构化数据库 是指其字段长度可变，并且每个字段的记录又可以由可重复或不可重复的子字段构成的数据库。无法用结构化的数据模型表示，例如：文档、图片、声音、视频等。在大数据时代，对非关系型数据库的需求日益增加，数据库技术相应地进入了“后关系数据库时代”。 非结构化数据库代表为 HBase、mongodb。 可以大致归纳，结构化数据是先有结构、再有数据；非结构化数据是先有数据、再有结构。 Hadoop 是大数据存储和计算的开山鼻祖

大数据概述 物联网、云计算和大数据，是第三次信息化浪潮的产物。 技术支撑：存储设备容量的不断增加、CPU处理能力大幅提升、网络带宽不断增加。 数据产生方式：经历了运营式系统、用户原创阶段，进入了感知式系统阶段，物联网技术，可穿戴设备、各种传感器之类的使数据量更大、更密集。 大数据的4V说法 数据量大（Volume）：web2.0时代以及物联网技术的发展，数据爆炸。2020年，全球数据量约有35ZB（ZB、EB、PB、TB) 数据类型繁多:90%的数据都是非结构化的，而且包括视屏、邮件、微信、微博、定位等等各种各样的数据。数据种类复杂，对数据的存储和处理提出了新的挑战。存储方面从传统的RDBMS向NoSQl迁移，数据处理上，传统的联机分析处理（On-Line Analytical Processing OLAP）和商业智能工具（BI)大都面向结构化数据，新的支持非结构化数据分析的解决方案正在迅速发展。 处理速度快：很多应用需要数据处理和分析具有秒级响应（这一点与传统的数据挖掘技术有着本质不同）。以谷歌Dremel为例，这个系统能够在几秒内完成PB级数据的查询。这取决于它的分布式集群处理和独特的内部设计。 价值密度低：大量非结构化数据，价值密度显然低于传统的关系型数据中的数据。 大数据的影响 思维上 大数据使得人类研究经历了实验、理论、计算后，进入了第四种思维范式——数据密集型科学

目录结构 1.Hadoop概述 1.1 Hadoop简介 1.2 Hadoop发展史 1.3 Hadoop特点 2.Hadoop核心 2.1 分布式文件系统——HDFS 2.2 分布式计算框架——MapReduce 2.3 集群资源管理器——YARN 3.Hadoop生态系统 4.Hadoop应用场景 5.小结 一、Hadoop介绍 1.Hadoop概述 两大核心 ：HDFS和MapReduce 用于资源与任务调度的框架 ：YARN 1.1 Hadoop简介 Hadoop是一个由Apache基金会所开发的 分布式系统基础架构 。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。它的目的是从单一的服务器扩展到成千上万的机器，将集群部署在多台机器，每个机器提供本地计算和存储，并且将存储的数据备份在多个节点，由此提高集群的可用性，而不是通过硬件的提升，当一台机器宕机时，其他节点仍可以提供备份数据和计算服务，Hadoop框架最核心的设计是HDFS和MapReduce。 1.2 Hadoop发展史（转自百度百科） Hadoop原本来自于谷歌一款名为MapReduce的编程模型包。谷歌的MapReduce框架可以把一个应用程序分解为许多并行计算指令，跨大量的计算节点运行非常巨大的数据集。使用该框架的一个典型例子就是在网络数据上运行的搜索算法

“不管国内或全球“新冠”疫情有多严重、还得持续多久，我只想先保住我的工作，如果降薪，我也能在短时间找到待遇更好的下一个东家”。 ——《大数据就业特训营》23期学员李斌 2014年做大数据培训至今，已有5年之多，可以说大数据技术的发展变化速度之快，用“突飞猛进”来说毫不夸张。就单从计算引擎领域的发展来说，2014年之前，想必都还在使用MapReduce来做离线计算，速度虽然慢，但能处理TB级别的数据规模，还是相当兴奋的。2014-2018，Spark以其基于内存计算，速度更快等优势强势入场，大部分大数据人员又一窝蜂的转向Spark及其生态体系的开发。2017至今，随着实时应用场景的需求扩大，Flink以其真正的实时计算终于在沉默中爆发，人们又开始转向Flink及其生态体系的开发。那么，数据人下一步可能转向的领域在哪里？是什么呢？大批往期学员是这样说的 “我不想只做Hadoop、Spark、Flink层面的技术开发，我想深入到数仓体系构建、数据资产管理等核心领域”。我也在想，随着Hadoop、Spark、Flink开发人员越来越多，企业对数据资产管理的重视程度越来越高、企业数据化转型的要求越来越迫切，围绕数据资产管理的大数据开发将注定会成为一个新的方向，这个方向也将会发展更持久、能力要求更高、薪资待遇更好、发展前景更优。 借此机会，结合企业真实应用场景为大家梳理出“5大体系11步流程

Hive与HBase的区别与联系 二者区别 Hive：Hive是基于Hadoop的一个 数据仓库工具 ，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能。 Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。 hive需要用到hdfs存储文件，需要用到MapReduce计算框架。 hive可以认为是map-reduce的一个包装。hive的意义就是把好写的hive的sql转换为复杂难写的map-reduce程序。 HBase：HBase是Hadoop的 数据库 ，一个分布式、可扩展、大数据的存储。 hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作 hbase可以认为是hdfs的一个包装。他的本质是数据存储，是个NoSql数据库；hbase部署于hdfs之上，并且克服了hdfs在随机读写方面的缺点。 二者联系 Hbase和Hive在大数据架构中处在不同位置，Hbase主要解决实时数据查询问题，Hive主要解决数据处理和计算问题，一般是配合使用。 在大数据架构中，Hive和HBase是协作关系，数据流一般如下图： 通过ETL工具将数据源抽取到HDFS存储； 通过Hive清洗、处理和计算原始数据； HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase

CDA数据分析师 出品 Shuffle 的本义是洗牌、 混洗， 把一组有一定规则的数据尽量转换成一组无规则的数据，越随机越好。 MapReduce 中的 Shuffle 更像是洗牌的逆过程， 把一组无规则的数据尽量转换成一组具有一定规则的数据。 为什么 MapReduce 计算模型需要 Shuffle 过程？ 我们都知道 MapReduce 计算模型一般包括两个重要的阶段： Map 是映射， 负责数据的过滤分发； Reduce 是规约， 负责数据的计算归并。 Reduce 的数据来源于 Map， Map 的输出即是 Reduce 的输入， Reduce 需要通过 Shuffle 来获取数据。从 Map 输出到 Reduce 输入的整个过程可以广义地称为 Shuffle。 Shuffle 横跨 Map 端和 Reduce 端， 在 Map 端包括 Spill 过程， 在 Reduce 端包括 copy 和 sort 过程， 如图所示： ​Spill 过程 Spill 过程包括输出、 排序、 溢写、 合并等步骤， 如图所示： Collect 每个 Map 任务不断地以对的形式把数据输出到在内存中构造的一个环形数据结构中。使用环形数据结构是为了更有效地使用内存空间， 在内存中放置尽可能多的数据。这个数据结构其实就是个字节数组， 叫 Kvbuffer， 名如其义， 但是这里面不光放置了数据

CDA数据分析师 出品 1、 YARN的产生 在之前文章中介绍过hadoop1与hadoop2架构的区别是hadoop2将资源管理功能从MapReduce框架中独立出来，也就是现在的YARN模块。 在没有 YARN 之前，是一个集群一个计算框架。比如：MapReduce 一个集群、Spark 一个集群、HBase 一个集群等。 造成各个集群管理复杂，资源的利用率很低；比如：在某个时间段内 Hadoop 集群忙而Spark 集群闲着，反之亦然，各个集群之间不能共享资源造成集群间资源并不能充分利用。 并且采用"一个框架一个集群"的模式，也需要多个管理员管理这些集群， 进而增加运维成本；而共享集群模式通常需要少数管理员即可完成多个框架的统一管理; 随着数据量的暴增，跨集群间的数据移动不仅需要花费更长的时间，且硬件成本也会大大增加；而共享集群模式可让多种框架共享数据和硬件资源,将大大减少数据移动带来的成本。 解决办法： 将所有的计算框架运行在一个集群中，共享一个集群的资源，按需分配；Hadoop 需要资源就将资源分配给 Hadoop，Spark 需要资源就将资源分配给 Spark，进而整个集群中的资源利用率就高于多个小集群的资源利用率； 2、 YARN的基本构成 Master/Slave 结构，1 个ResourceManager（RM）对应多个 NodeManager(NM)；YARN

Spark SQL模块，主要就是处理跟SQL解析相关的一些内容，说得更通俗点就是怎么把一个SQL语句解析成Dataframe或者说RDD的任务。以Spark 2.4.3为例，Spark SQL这个大模块分为三个子模块，如下图所示 其中Catalyst可以说是Spark内部专门用来解析SQL的一个框架 ，在Hive中类似的框架是Calcite（将SQL解析成MapReduce任务）。Catalyst将SQL解析任务分成好几个阶段，这个在对应的论文中讲述得比较清楚，本系列很多内容也会参考论文，有兴趣阅读原论文的可以到这里看： Spark SQL: Relational Data Processing in Spark 。 而Core模块其实就是Spark SQL主要解析的流程，当然这个过程中会去调用Catalyst的一些内容。这模块里面比较常用的类包括SparkSession，DataSet等。 至于hive模块，这个不用说，肯定跟hive有关的。这个模块在本系列基本不会涉及到，就不多介绍了。 值得一提的是，论文发表的时候还是在Spark1.x阶段，那个时候SQL解析成词法树用的是scala写的一个解析工具，到2.x阶段改为使用antlr4来做这部分工作（这应该算是最大的改变）。至于为什么要改，我猜是出于可读性和易用性方面的考虑，当然这个仅是个人猜测。 另外，

Spark SQL模块，主要就是处理跟SQL解析相关的一些内容，说得更通俗点就是怎么把一个SQL语句解析成Dataframe或者说RDD的任务。以Spark 2.4.3为例，Spark SQL这个大模块分为三个子模块，如下图所示 其中Catalyst可以说是Spark内部专门用来解析SQL的一个框架 ，在Hive中类似的框架是Calcite（将SQL解析成MapReduce任务）。Catalyst将SQL解析任务分成好几个阶段，这个在对应的论文中讲述得比较清楚，本系列很多内容也会参考论文，有兴趣阅读原论文的可以到这里看： Spark SQL: Relational Data Processing in Spark 。 而Core模块其实就是Spark SQL主要解析的流程，当然这个过程中会去调用Catalyst的一些内容。这模块里面比较常用的类包括SparkSession，DataSet等。 至于hive模块，这个不用说，肯定跟hive有关的。这个模块在本系列基本不会涉及到，就不多介绍了。 值得一提的是，论文发表的时候还是在Spark1.x阶段，那个时候SQL解析成词法树用的是scala写的一个解析工具，到2.x阶段改为使用antlr4来做这部分工作（这应该算是最大的改变）。至于为什么要改，我猜是出于可读性和易用性方面的考虑，当然这个仅是个人猜测。 另外，

1.Spark 消费Kafka,分布式的情况下，如何保证消息的顺序？ Kafka分布式的单位是Partition，如何保证消息有序，需要分一下几个条件讨论。 同一个Partition用一个 write ahead log 组织，所以可以保证FIFO的顺序。 不同Partition之间不能保证顺序但是绝大多数用户可以通过 message key 来定义，因为同一个key的 message 可以保证只发送到同一个Partition。如果说key是user id， table row id 等等，所以同一个user 或者同一个 record 的消息永远只会发送到同一个 Partition 上，保证了同一个 user 或 record 的顺序。 当然，如果你有 key skewnes就有些麻烦，需要谨慎处理。 实际情况中，(1)不关注顺序的业务大量存在，队列无序不代表消息无序。(2)我们不保证队列的全局有序，但可以保证消息的局部有序，举个例子:保证来自同一个order id 的消息，是有序的。Kafka中发送1条消息的时候,可以指定(topic,partition,key) 3个参数。partition和key是可选的，如果你指partition，那就是所有消息发往同一个partition，就是有序的，而且在消费端,Kafka保证，1个partition只能被一个consumer消费