Apache Spark

身处大数据圈近5年了，在我的概念里一直认为大数据最牛的两个东西是Hadoop和Spark。18年下半年的时候，我突然发现身边很多大数据牛人都是研究学习Flink，甚至连Spark都大有被冷落抛弃的感觉。何以至此，Flink是个什么鬼？ Apache Flink（简称Flink）是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态计算。可部署在各种集群环境，对各种大小的数据规模进行快速计算。 大数据生态圈很庞大，优秀的框架和组件就笔者了解的不下20个，为何Flink如此受宠？那么多人而且还是薪资待遇不错的大数据技术人要痴迷于它？笔者总结一下，大概以下几个原因： 1. 从技术角度来说，目前大数据计算引擎中， 能够同时支持流处理和批处理的计算引擎，只有Spark和Flink。其中Spark的技术理念是基于批来模拟流的计算。而Flink则完全相反，它采用的是基于流计算来模拟批计算。从技术发展方向看，用批来模拟流有一定的技术局限性，并且这个局限性可能很难突破。而Flink基于流来模拟批，在技术上有更好的扩展性。 2. 从语言方面来说，虽然Flink和Spark都支持多种语言，但Flink核心语言是Java，而Spark核心语言是Scala。Java语言毫无疑问用户基础更大，无论从技术选型还是团队人员稳定方面考虑，以Java作为核心语言的Flink更受偏爱。 3.

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

Spark是新一代分布式内存计算框架， Apache 开源的顶级项目。相比于Hadoop Map-Reduce计算框架，Spark将中间计算结果保留在内存中，速度提升10~100倍；同时它还提供更丰富的算子，采用弹性分布式数据集(RDD)实现迭代计算，更好地适用于数据挖掘、机器学习算法，极大提升开发效率。 Docker是轻量级虚拟化容器技术，具有轻便性、隔离性、一致性等特点，可以极大简化开发者的部署运维流程，降低 服务器 成本。 Kubernetes是 Google 开源的容器集群管理系统，提供应用部署、维护、 扩展等功能，能够方便地管理大规模跨主机的容器应用。 相比于在物理机上部署，在Kubernetes集群上部署Spark集群，具有以下优势： 快速部署：安装1000台级别的Spark集群，在Kubernetes集群上只需设定worker副本数目replicas=1000，即可一键部署。 快速升级：升级Spark版本，只需替换Spark镜像，一键升级。 弹性伸缩：需要扩容、缩容时，自动修改worker副本数目replicas即可。 高一致性：各个Kubernetes节点上运行的Spark环境一致、版本一致 高可用性：如果Spark所在的某些node或pod死掉，Kubernetes会自动将计算任务，转移到其他node或创建新pod。 强隔离性：通过设定资源配额等方式

本文档环境基于ubuntu16.04版本，（转发请注明出处： http://www.cnblogs.com/zhangyongli2011/ 如发现有错，请留言，谢谢） 1. 基础环境搭建 基础环境搭建请参考 上一篇文档:Hadoop集群+Spark集群搭建（一篇文章就够了） . 2. 软件准备 SuperMap iObjects Java 9.x ( supermap-iobjectsjava-9.1.1-16827-70590-linux64-all-Bin.tar.gz ) SuperMap iObjects for Spark 9.x ( supermap-spark-911-20181228.zip ) 3. iObjects for Spark部署 3.1 iObjects for Spark 安装 1.下载 supermap-iobjectsjava-9.1.1-16827-70590-linux64-all-Bin.tar.gz 和相应的 supermap-spark-911-20181228.zip 组件 2.放到opt下解压，并修改名字 tar -zxvf supermap-iobjectsjava-9.1.1-16827-70590-linux64-all-Bin.tar.gz mv Bin iobjects_new 3.新建iobjects_spark目录

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

总共分为三步： 第一步安装配置hadoop： 搭建hadoop+spark+hive环境（centos全远程hadoop极速安装及配置） 第二步安装配置spark： 搭建hadoop+spark+hive环境（centos极速安装和配置spark） 第三步安装配置hive： 搭建hadoop+spark+hive环境（centos极速安装和配置hive） I、下载并解压spark #下载spark wget --no-cookies --no-check-certificate http: // apache.claz.org/spark/spark-2.4.4/spark-2.4.4-bin-hadoop2.7.tgz #解压spark tar xzf spark- 2.4 . 4 -bin-hadoop2. 7 .tgz #移动到hadoop文件夹中 mv spark-2.4.4-bin-hadoop2.7 /usr/local/hadoop/ II、配置系统环境 #编辑配置文件 vim /etc/ profile #添加下面两行 export SPARK_HOME =/usr/local/hadoop/spark- 2.4 . 4 -bin-hadoop2. 7 export PATH =/data/hadoop/spark/bin:$PATH III、修改配置文件

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来做这部分工作（这应该算是最大的改变）。至于为什么要改，我猜是出于可读性和易用性方面的考虑，当然这个仅是个人猜测。 另外，

浅谈Flink Apache Flink 是一个面向数据流处理和批量数据处理的分布式的开源计算框架，能够支持流处理和批处理两种应用类型。有着低延迟、Exactly-once 保证，而批处理需要支持高吞吐、高效处理的特点。 Flink 完全支持流处理，也就是说作为流处理看待时，输入数据流是无界的；批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。这与 Spark streaming 不同，Spark streaming 是将流处理视为无限个有界的批处理（microbatch）。 Flink 特点 有状态计算的 Exactly-once 语义。状态是指 flink 能够维护数据在时序上的聚类和聚合，同时它的 checkpoint 机制可以方便快速的做出失败重试； 支持带有事件时间（event time）语义的流处理和窗口处理。事件时间的语义使流计算的结果更加精确，尤其在事件到达无序或者延迟的情况下； 支持高度灵活的窗口（window）操作。支持基于 time、count、session，以及 data-driven 的窗口操作，能很好的对现实环境中的创建的数据进行建模； 轻量的容错处理（fault tolerance）。它使得系统既能保持高的吞吐率又能保证 exactly-once 的一致性。通过轻量的 state snapshots 实现； 支持高吞吐、低延迟

在 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRpcEnv 中，剖析了NettyRpcEnv的创建过程。 Dispatcher、NettyStreamManager、TransportContext、TransportClientFactory、TransportServer、Outbox、Inbox等等基础的知识都已经在前面剖析过了。 可以参照如下文章做进一步了解。 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRpcEnv spark 源码分析之六 -- Spark内置RPC机制剖析之二Dispatcher和Inbox、Outbox剖析 spark 源码分析之七 -- Spark内置RPC机制剖析之三RpcEndPoint和RpcEndPointRef剖析 spark 源码分析之八 -- Spark内置RPC机制剖析之四TransportContext和TransportClientFactory剖析 spark 源码分析之九 -- Spark内置RPC机制剖析之五StreamManager和RpcHandler spark 源码分析之十 -- Spark内置RPC机制剖析之六TransportResponseHandler