运行 spark-shell
本地模式运行spark-shell非常简单，只要运行以下命令即可，假设当前目录是$SPARK_HOME
$ MASTER=local $ bin/spark-shell
MASTER=local就是表明当前运行在单机模式。如果一切顺利，将看到下面的提示信息：
Created spark context
Spark context available as sc
这表明spark-shell中已经内置了Spark context的变量，名称为sc，我们可以直接使用该变量进行后续的 *** 作。
spark-shell 后面设置 master 参数，可以支持更多的模式，
我们在sparkshell中运行一下最简单的例子，统计在READMEmd中含有Spark的行数有多少，在spark-shell中输入如下代码：
scala>sctextFile("READMEmd")filter(_contains("Spark"))count
如果你觉得输出的日志太多，你可以从模板文件创建 conf/log4jproperties ：
$ mv conf/log4jpropertiestemplate conf/log4jproperties
然后修改日志输出级别为WARN：
log4jrootCategory=WARN, console
如果你设置的 log4j 日志等级为 INFO，则你可以看到这样的一行日志 INFO SparkUI: Started SparkUI at >通过前面的介绍我们知道，Spark的客户端（Driver）有两种：Spark Submit和Spark Shell。这两种客户端相同点都是维护一个Spark Context对象，来向Spark集群提交任务；不同点是Spark Submit只能提交任务，不能交互，而Spark Shell是一个命令行工具，即可以提交任务，还可以人机交互。本节先来介绍Spark Submit客户端的使用。
例子：使用蒙特卡罗方法计算圆周率。
如图所示，蒙特卡罗方法求圆周率，使用的是概率的思想：往正方形区域随机撒点，总点数记为P2，落在单位圆区域内的点数记为P1，单位圆的面积为π，正方形的面子为4，π = P1 / P2 4。这里的P1和P2均由随机实验中得到，实验的次数（P2）越多，得到的结果就越精确。
Spark提供的测试用例$SPARK_HOME/examples/jars/spark-examples_211-210jar中就有蒙特卡罗求圆周率的例子SparkPI，我们就使用它来介绍Spark Submit的使用。
(1)如果配置了基于Zookeeper的Spark HA，需要先启动Zookeeper服务器
(2)启动Spark集群
使用Spark Submit的命令格式如下：
(1)提交SparkPI任务，随机实验次数为100：
(2)提交SparkPI任务，随机实验次数为1000：
(3)提交SparkPI任务，随机实验次数为10000：
可以看到上面三次实验的结果分别是：
一般对于随机实验来说，试验次数越多结果越精确。但是不免存在误差。如果想要获取更精确的圆周率，你可以输入更多的次数进行测试。但这不是本文介绍的重点。
至此，使用Spark Submit客户端提交Spark任务的方法已经介绍完毕，祝你玩的愉快！
一、hadoop、Storm该选哪一个？
为了区别hadoop和Storm，该部分将回答如下问题：
1hadoop、Storm各是什么运算
2Storm为什么被称之为流式计算系统
3hadoop适合什么场景，什么情况下使用hadoop
4什么是吞吐量
首先整体认识：Hadoop是级计算，进行计算时，数据在磁盘上，需要读写磁盘；Storm是内存级计算，数据直接通过网络导入内存。读写内存比读写磁盘速度快n个数量级。根据Harvard CS61课件，磁盘访问延迟约为内存访问延迟的75000倍。所以Storm更快。
注释：
1 延时 ， 指数据从产生到运算产生结果的时间，“快”应该主要指这个。
2 吞吐， 指系统单位时间处理的数据量。
storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。
从原理角度来讲：
Hadoop M/R基于HDFS，需要切分输入数据、产生中间数据文件、排序、数据压缩、多份复制等，效率较低。
Storm 基于ZeroMQ这个高性能的消息通讯库，不持久化数据。
为什么storm比hadoop快，下面举一个应用场景
说一个典型的场景，几千个日志生产方产生日志文件，需要进行一些ETL *** 作存入一个数据库。
假设利用hadoop，则需要先存入hdfs，按每一分钟切一个文件的粒度来算（这个粒度已经极端的细了，再小的话hdfs上会一堆小文件），hadoop开始计算时，1分钟已经过去了，然后再开始调度任务又花了一分钟，然后作业运行起来，假设机器特别多，几钞钟就算完了，然后写数据库假设也花了很少的时间，这样，从数据产生到最后可以使用已经过去了至少两分多钟。
而流式计算则是数据产生时，则有一个程序去一直监控日志的产生，产生一行就通过一个传输系统发给流式计算系统，然后流式计算系统直接处理，处理完之后直接写入，每条数据从产生到写入数据库，在资源充足时可以在毫秒级别完成。
同时说一下另外一个场景：
如果一个大文件的wordcount，把它放到storm上进行流式的处理，等所有已有数据处理完才让storm输出结果，这时候，你再把它和hadoop比较快慢，这时，其实比较的不是时延，而是比较的吞吐了。
--------------------------------------------------------------------------------------------------------------------------------
最主要的方面：Hadoop使用作为中间交换的介质，而storm的数据是一直在内存中流转的。
两者面向的领域也不完全相同，一个是批量处理，基于任务调度的；另外一个是实时处理，基于流。
以水为例，Hadoop可以看作是纯净水，一桶桶地搬；而Storm是用水管，预先接好（Topology），然后打开水龙头，水就源源不断地流出来了。
--------------------------------------------------------------------------------------------------------------------------------
Storm的主工程师Nathan Marz表示： Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程语言来做开发。
Storm的主要特点如下：
1简单的模型。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。
2可以使用各种。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。
3容错性。Storm会管理工作进程和节点的故障。
4水平扩展。计算是在多个线程、进程和服务器之间并行进行的。
5可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。
6快速。系统的设计保证了消息能得到快速的处理，使用MQ作为其底层消息队列。
7本地模式。Storm有一个“本地模式”，可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。
--------------------------------------------------------------------------------------------------------------------------------
在消耗资源相同的情况下，一般来说storm的延时低于mapreduce。但是吞吐也低于mapreduce。storm是典型的流计算系统，mapreduce是典型的批处理系统。下面对流计算和批处理系统流程
这个个数据处理流程来说大致可以分三个阶段：
1 数据采集与准备
2 数据计算（涉及计算中的中间存储）， 题主中的“那些方面决定”应该主要是指这个阶段处理方式。
3 数据结果展现（反馈）
1）阶段，目前典型的处理处理策略：数据的产生系统一般出自页面打点和解析DB的log，流计算将数据采集中消息队列（比如kafaka,metaQ,timetunle）等。批处理系统一般将数据采集进分布式文件系统（比如HDFS），当然也有使用消息队列的。我们暂且把消息队列和文件系统称为预处理存储。二者在延时和吞吐上没太大区别，接下来从这个预处理存储进入到数据计算阶段有很大的区别，流计算一般在实时的读取消息队列进入流计算系统（storm）的数据进行运算，批处理一系统一般会攒一大批后批量导入到计算系统（hadoop），这里就有了延时的区别。
2）数据计算阶段，流计算系统（storm）的延时低主要有一下几个方面（针对题主的问题）
A： storm 进程是常驻的，有数据就可以进行实时的处理
mapreduce 数据攒一批后由作业管理系统启动任务，Jobtracker计算任务分配，tasktacker启动相关的运算进程
B： stom每个计算单元之间数据之间通过网络（zeromq）直接传输。
mapreduce map任务运算的结果要写入到HDFS，在于reduce任务通过网络拖过去运算。相对来说多了读写，比较慢
C： 对于复杂运算
storm的运算模型直接支持DAG（有向无环图）
mapreduce 需要肯多个MR过程组成，有些map *** 作没有意义的
3）数据结果展现
流计算一般运算结果直接反馈到最终结果集中（展示页面，，搜索引擎的索引）。而mapreduce一般需要整个运算结束后将结果批量导入到结果集中。
实际流计算和批处理系统没有本质的区别，像storm的trident也有批概念，而mapreduce可以将每次运算的数据集缩小（比如几分钟启动一次），facebook的puma就是基于hadoop做的流计算系统。
二、高性能并行计算引擎Storm和Spark比较
Spark基于这样的理念，当数据庞大时，把计算过程传递给数据要比把数据传递给计算过程要更富效率。每个节点存储（或缓存）它的数据集，然后任务被提交给节点。
所以这是把过程传递给数据。这和Hadoop map/reduce非常相似，除了积极使用内存来避免I/O *** 作，以使得迭代算法（前一步计算输出是下一步计算的输入）性能更高。
Shark只是一个基于Spark的查询引擎（支持ad-hoc临时性的分析查询）
而Storm的架构和Spark截然相反。Storm是一个分布式流计算引擎。每个节点实现一个基本的计算过程，而数据项在互相连接的网络节点中流进流出。和Spark相反，这个是把数据传递给过程。
两个框架都用于处理大量数据的并行计算。
Storm在动态处理大量生成的“小数据块”上要更好（比如在Twitter数据流上实时计算一些汇聚功能或分析）。
Spark工作于现有的数据全集（如Hadoop数据）已经被导入Spark集群，Spark基于in-memory管理可以进行快讯扫描，并最小化迭代算法的全局I/O *** 作。
不过Spark流模块（Streaming Module）倒是和Storm相类似（都是流计算引擎），尽管并非完全一样。
Spark流模块先汇聚批量数据然后进行数据块分发（视作不可变数据进行处理），而Storm是只要接收到数据就实时处理并分发。
不确定哪种方式在数据吞吐量上要具优势，不过Storm计算时间延迟要小。
总结下，Spark和Storm设计相反，而Spark Steaming才和Storm类似，前者有数据平滑窗口（sliding window），而后者需要自己去维护这个窗口。
完全分布式HA服务器规划
技术栈包含
hdfs
hive on spark
presto
doris
superset
azkaban
kafka
fluent\flume
sqoop\kettle\flink-cdc
atlas
禁用swap/selinux
修改 IP/修改主机名/及主机名和 IP 地址的映射
时间同步/设置时区/自动时间同步
关闭防火墙
关闭SELINUX
新建用户
免密登录（先升级openssh）
发送密钥（dw01上执行）
授权
Tencent Kona v808-GA
腾讯开源的konaJDK，针对大数据场景下优化
解压并重命名至安装地址：/usr/local/java/
zookeeper-359
解压并重命名至安装地址：/usr/local/zookeeper
apache-hadoop-313 解压至安装地址：/usr/local/hadoop
修改环境变量
/usr/local/zookeeper/conf
启动zookeeper集群（每台执行）
三台服务器启动
格式化namenode（dw01执行）
启动namenode(dw01上执行)
在[nn2]和[nn3]上分别执行，同步 nn1 的元数据信息
启动nn2 nn3，分别执行
所有节点上启动datanode
将[nn1]切换为 Active
查看状态
配置yarn-sitexml
配置mapred-sitexml
分发配置文件，启动yarn(dw03 启动)
dw03节点
dw01节点
dw01执行
dw03执行
测试样例
启动脚本
HA切换namenode手动
修改yarn显示log的bug
但在过去的几年中，Hadoop似乎并没有出现过任何衰退的迹象。在2015年Atscale的调查报告中显示：“在未来3个月内，已经有超过 76%的人使用Hadoop来做更多的工作。”这些受访者中大约有一半声称他们利用Hadoop工作中获得了一定的价值。Hadoop作为一个十多年的老品牌，在产品的采用方面并没有减缓下降的趋势，Spark也并没有做到真正取代Hadoop。空口无凭，下面我们从以下几个方面来分析一下Spark在未来的几年之内到底能不能真正的取代Hadoop。
由雅虎为工程师和数据科学家打造的Apache Hadoop曾因巨大的潜力而备受称赞，但如今它却受到了更快的产品的影响，而这些产品往往来自于它本身的生态系统——Spark就是其中之一。今年早些，H20ai的创始人Sri Ambati对Datanami 曾说：“Spark将会使Hadoop处于绝地”。
毫无疑问，为专家设计的产品一般都会停留在原来的轨道上，在其他方面不会有所涉及。但Spark在各个行业都存在一些有意义的分布，这可能要归功于各种市场上的大数据的泛滥。所以，虽然Spark可能有更广泛的应用，但Hadoop仍然支配着原本预期的用户群。在全球范围内，我们可以看到Informatica处于中心位置——在欧洲和美洲整体市场份额占比达32%。
在两年半的时间里，我们跟踪了Informatica在云市场和工业领域的增长，结果显示达到了50%的增长，而且在高等教育领域也处于领先地位。上周， Informatica被Gartner评为主数据管理解决方案2017年魔力象限的领导者。而Hadoop仍然停留于过去成功的地理市场中。在企业客户中Spark也没有大范围的涉及。我们注意到世界上大多数公司规模较小，一般都为1-50名员工，所以Spark似乎并不是任何规模公司的唯一选择。
对于那些已经使用Hadoop的人来说，这个产品也对企业和公司起到了一定的作用，而且 Hadoop并不仅限于一种用户。而Hadoop无论在何种规模的公司中，使用率相对于Spark还是非常高的。此外，在调查的过程中，传统的科技公司像eBay、Verizon、惠普和亚马逊等主流厂商已经开始使用Spark，但是Hadoop还没有被大规模的抛弃。相反，用户使用Spark作为系统的介绍，利用这个程序来突破Hadoop的障碍，两者的结合，使得工作更高效地完成。
Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着你不需要购买和维护昂贵的服务器硬件。同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。Spark，则是那么一个专门用来对那些分布式存储的大数据进行处理的工具，它并不会进行分布式数据的存储。
其次，还有一点也值得注意——这两者的灾难恢复方式迥异。因为Hadoop将每次处理后的数据都写入到磁盘上，所以其天生就能很有d性的对系统错误进行处理。Hadoop和Apache Spark两者都是大数据框架，但是各自存在的目的不尽相同。Hadoop实质上更多是一个分布式数据基础设施: 它将巨大的数据集分派到一个由普通计算机组成的集群中的多个节点进行存储，意味着你不需要购买和维护昂贵的服务器硬件。同时，Hadoop还会索引和跟踪这些数据，让大数据处理和分析效率达到前所未有的高度。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）