首页 文章 精选 留言 我的

精选列表

搜索[基础搭建]，共10000篇文章
优秀的个人博客,低调大师

docker 容器查看命令的基础使用方法一

使用docker inspect命令查看container的volume信息， 使用命令如下： sudo docker inspect --format "{{.Volumes}}" 94609848bfb5 一直报错： Template parsing error: template: :1:2: executing "" at <.Volumes>: map has no entry for key "Volumes" 一开始怀疑是命令格式不对，后来干脆去掉--format选项，直接查看所有内容，显示Volume在Config信息数组下一级，但上面的命令是书上的，应该没错。后来google一遍，发现其他人也有这个问题，修改命令如下： sudo docker inspect --format "{{.Config.Volumes}}" 显示结果正常: map[/data:{}] 此处显示的信息只有docker 容器本地数据卷的信息，与其关联的物理主机的挂载目录位置信息，要使用如下信息查看： docker inspect -f "{{.Mounts}}" 94609848bfb5 #显示结果 [{volume 0127e45aaf6fbe5a726003c87cbbdd0ba2e3ee90d12df7475f1dcb6f9c79c056 /var/lib/docker/volumes/0127e45aaf6fbe5a726003c87cbbdd0ba2e3ee90d12df7475f1dcb6f9c79c056/_data /data local true }] #对应的 docker inspect 信息数组格式如下： "Mounts": [ { "Type": "volume", "Name": "0127e45aaf6fbe5a726003c87cbbdd0ba2e3ee90d12df7475f1dcb6f9c79c056", "Source": "/var/lib/docker/volumes/0127e45aaf6fbe5a726003c87cbbdd0ba2e3ee90d12df7475f1dcb6f9c79c056/_data", "Destination": "/data", "Driver": "local", "Mode": "", "RW": true, "Propagation": "" } ],
2017-01-29
优秀的个人博客,低调大师

这些是你需要知道的Android内存基础

背景介绍 Java优势之一就是其具有垃圾回收机制。在大部分情况下，JVM的GC(垃圾回收器)能够帮助我们回那些不可到达的对象(就是未被引用的对象)。 当然，在一些情况下，我们仍然需要自己去释放内存(就是把对象引用置null，把容器、数组清空)，否则就会引起内存泄漏，内存泄漏严重时将容易引发OutOfMemoryError，详情见内存泄漏。 此外，由于GC会停止所有的线程，包括UI线程，所以频繁的GC必然会导致画面卡顿(Android中每16ms为一帧)，因此还应避免GC的频繁发生。一个导致GC频繁发生的原因就是内存抖动，点击链接看详情。 GC时线程被停止示意图 所以，理解Java的内存机制，有助于帮助我们在写代码的过程中避免内存泄漏。 走进内存模型 Java内存层级 JVM运行时内存划分 ; JVM运行时内存划分-详细 ; 程序计数器 程序计数器是线程私有的内存区域，这个区域是Java虚拟机中唯一一个没有限制OutOfMemoryError的内存区域。之所以需要它是因为Java的多线程机制是通过轮流切换分配处理器执行时间来实现的，所以会涉及到线程的暂停和重启，而在一个线程中如果正在执行Java方法的话，这个计数器就回去记录当前正在执行的虚拟机字节码，一旦被暂停，恢复只需要从程序计数器记录的为止继续执行就可以。 但是，如果线程中执行的是一个Native方法，那么程序计数器是不会去记录的，所以此时的程序计数器为空。 虚拟机栈Stack Java虚拟机栈也是线程私有的。一条线程启动就会为它建立一个虚拟机栈。 在线程中每有一个Java方法被调用就会创建一个 “栈帧” 。每个 “栈帧” 会保存执行该方法所需的局部变量表（一般Java程序员喜欢用这个部分来代表栈）、操作数栈、动态链接以及方法出口等信息。 如果一个线程中有过多的 “栈帧” 要入到虚拟机栈中，即短时间内调用了过多的方法，就会造成 -- 栈益处 -- ，即 StackOverflowError 错误。 在这个内存区域中，如果虚拟机需要扩展内存，但没有申请到足够的内存，就会抛出 OutOfMemoryError 错误。 本地方法栈 和虚拟机栈有些类似，但它是为Native方法提供服务的。 Java堆Heap Java的堆内存是Java虚拟机所管理的内存中最大的一块。它是所有线程所共享的，用于存放对象实例和数组，Java虚拟机的GC主要就发生在这个地方。因此这块区域也叫做"GC堆"。 Java堆的内存可以按照垃圾回收算法【分代回收】分为【新生代区】和【老年区】，进一步的，【新生代区】可以分为【Eden区】、【From Survivor区】和【To Survivor区】。 从内存角度来说，Java堆内存又被划分为线程共享的内存区域和每个线程私有的内存区域。 在Java堆区域中，如果没有内存分配给要创建的实例，并且堆也不能够再扩展，就会抛出OutOfMemoryError错误。 回收算法 在Java8之后，Heap Segment真正意义上的是由Young Generiation和Old Generiation组成的。对象在其中是标记复制算法来判定一个对象是否应该被清理掉。Heap Segment中发生的GC称为Major GC，只会影响Heap Segment区。 内存图 Young Generiation中的GC变化 — 复制算法 这个区域发生的GC称为Minor GC。 当对象被创建后，首先会被加入eden区。当eden区满了之后，就会触发一次GC，存活下来的对象会被复制到survivor区。 当不为空的Survivor区满了，同样会触发一次GC。 当短时间内有大量对象创建和释放同样会造成内存抖动，会触发CG。 如图所示，survivor有两个区域，其中一个总是保持为空。 现假设两个Survivor区分别为S0，S1，并且首次GC时，eden区中存活的对象被复制到S0中。当再次发生GC时，S0和eden中仍然存活的对象就会被复制到空的S1中，此时S0为空；再次发生GC时，S1和eden中存活的对象将被复制到S0中，此时S1为空；再次发生GC...就是这样进行的。当一个对象被来回复制转移的次数达到阀值(默认为15次，可以通过使用-XX:MaxTenuringThreshold该命令来调整阀值)时，这个对象将被复制到Old Generiation区中，此时该对象将会变的相对安全，因为Old Segment区的GC频率相对较低。 Old Segment中的GC变化 这个区域发送的GC成为Full GC。 该区域满了之后会触发一次GC，在该次GC中，一些年龄较大的对象会被清理掉。 若多次触发GC后，该区域仍然处于满的状态，则会抛出OutOfMemoryError。 以两种情况下，新建对象会被直接复制到该区域中: 当新建对象所需要的内存大于1/2的单个survivor区内存时。比如一些很长的对象； 当新建对象被该区中的对象引用时，或者引用了该区域中的对象。 方法区 Java的方法区和Java的堆内存一样是被线程所共有的。它主要存放虚拟机加载的类信息、常量、静态变量、即时编译产生的代码等。 一些地方会将方法区合并到Java堆中一起去说。把它作为“永久代”。这在Hot-Spot虚拟机而言成立，但是一般来说是不成立的。 Java的方法区如果内存不够分配的话，也是会抛出OutOfMemoryError错误的。也就是如果加载过多类到方法区的话，可能会造成方法区内存益处。 对象的可到达性 在GC检查对象的是否可以回收时，是根据对象是否可到达引用练顶端的GC Roots对象来判断的。GC Roots对象一般是虚拟机栈中变量表中引用的对象、类静态属性引用的对象、常量对象、JNI传到底层的对象。就是说，一个对象如果溯源不到这几种类型的对象的话，就认为它是无法到达的，那么它将会在GC时被回收。 新的引用类型 在JDK 1.2之后，Java扩充了4种引用类型定义： 强应用类型 即我们平时通过new关键字创建出来的的对象的引用，只要强引用还存在，那么这些对象就一定不回被回收，即使时抛出OutOfMemoryError。什么时候强引用会不存在呢？当一个方法执行完，栈帧中的变量表将会被清理，在该方法中创建使用的临时强引用就会被清理掉，之后，原本它指向的对象就被变的不可到达。 软引用类型 用来描述一些有用但不是必须的对象，即通过SoftReference创建的对象，它们将会在原本确定要发生内存溢出前的一次GC中被回收，如果回收完内存还是不够，Java堆就会抛出OutOfMemoryError错误。就是说，在触发内存溢出发生前，这些对象是和强引用一样，只要引用还在，就不会被回收。 弱引用类型 用来描述一些不必须的对象，即通过WeakReference创建的对象。弱引用对象的生命周期只有一次GC。 虚引用类型 一个对象的存在与否完全不受虚引用的影响，它唯一的用处就是可以用来监测一个对象是否被回收。 方法区中的-运行时常量池 运行时常量池主要存放类中编译时期生成的常量，当然也可以动态的往里面添加。 比如： "abc".intern(); 这个方法首先会检查运行时常量池中是否有这个字符串，有的话取出来用，没有的话生成一个并存到常量池中。 再比如，运行过程中生成通过static修饰的String时，也会加入到常量池中。对于String而言，常量 + 常量 生成的也是常量，但是常量 + 变量 生成的就是变量了。 关于Dalvik虚拟机 Dalvik虚拟机是Google按照JVM虚拟机规范定制的虚拟机，它更符合移动设备的环境要求。与标准虚拟机不同： Dalvik编译生成的是.dex文件，这种格式的文件体积更小。而JVM规范的是.class文件。 Dalvik虚拟机是基于寄存器的，而JVM规范是基于栈的，所以速度方面会有优势。比如上面的说的标准Java虚拟机中，它的虚拟机栈就为线程的运行提供了服务。而Dalvik虚拟机中，使用寄存器去储存运行指令，同时寄存器也提供了程序计数器。寄存器是处理器的一部分哦！ Dalvik虚拟机允许在内存中创建都个实例，以隔离不同的应用程序。这样，当一个应用程序在自己的进程中崩溃后，不会影响其它进程的运行。 关于ART虚拟机 ART虚拟机在Android 5.0以后是被默认开启的，此时Dalvik已经被Google放弃维护了。它与Dalvik虚拟机的不同： ART虚拟机在应用程序安装时就会把字节码通过dex2oat工具直接转成机器码储存，这个过程叫做AOT（Ahead-Of-Time）。而Dalvik是在每次启动应用程序时，通过传统的JIT（JUST IN TIME）模式将字节码转成机器码。显然，这样速度会慢不少。当然，ART虚拟机的占用内存也会更大些。 ART虚拟机在进行GC时采用了并法的模式。 在传统的GC模式下，当虚拟机触发一次GC，会先暂停所有线程，然后检查所有对象，将符合回收条件的对象进行标记，然后进行回收，最后再恢复线程，这样的话gc速度会快些，但是遇到内存抖动，就会卡顿了。同时，传统的GC算法导致了【内存碎片化】严重，在一次回收后，很多内存块都会出现不连续的情况，这样会导致寻址变得困难，从而拖慢程序运行速度。 而ART虚拟的垃圾回收算法允许GC时对对象的标记和一些对象的清理工作并发进行。同时，ART引入了【移动垃圾回收器】技术，使得碎片化内存能够被对齐，从而能稍微节约一些内存空间。 总结 Heap Segment被划分为两块：Young Generiation和Old Generiation。 Young Genertiation中又被划分为Eden区和两个Survivor区，对象在其中采用标记复制算法来判定一个对象是应该清理还是移到Old Generiation中。该内存区域发生GC的频率较高。 Old Generiation发生GC的频率相对较低。当有大对象被创建，或者和该区域有关的对象被创建时，它将会被直接移动到该区域中。 看到这里的童鞋快奖励自己一口辣条吧！ 想要看CoorChice更多的文章，可以加个关注哦！
2016-10-27
优秀的个人博客,低调大师

Spark-基础-Spark及其生态圈简介

1、简介 1.1Spark简介 Spark是加州大学伯克利分校AMP实验室（Algorithms, Machines, and People Lab）开发通用内存并行计算框架。Spark在2013年6月进入Apache成为孵化项目，8个月后成为Apache顶级项目，速度之快足见过人之处，Spark以其先进的设计理念，迅速成为社区的热门项目，围绕着Spark推出了Spark SQL、Spark Streaming、MLLib和GraphX等组件，也就是BDAS（伯克利数据分析栈），这些组件逐渐形成大数据处理一站式解决平台。从各方面报道来看Spark抱负并非池鱼，而是希望替代Hadoop在大数据中的地位，成为大数据处理的主流标准，不过Spark还没有太多大项目的检验，离这个目标还有很大路要走。 Spark使用Scala语言进行实现，它是一种面向对象、函数式编程语言，能够像操作本地集合对象一样轻松地操作分布式数据集（Scala提供一个称为Actor的并行模型，其中Actor通过它的收件箱来发送和接收非同步信息而不是共享数据，该方式被称为：Shared Nothing模型）。在Spark官网上介绍，它具有运行速度快、易用性好、通用性强和随处运行等特点。 l运行速度快 Spark拥有DAG执行引擎，支持在内存中对数据进行迭代计算。官方提供的数据表明，如果数据由磁盘读取，速度是Hadoop MapReduce的10倍以上，如果数据从内存中读取，速度可以高达100多倍。 l易用性好 Spark不仅支持Scala编写应用程序，而且支持Java和Python等语言进行编写，特别是Scala是一种高效、可拓展的语言，能够用简洁的代码处理较为复杂的处理工作。 l通用性强 Spark生态圈即BDAS（伯克利数据分析栈）包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等组件，这些组件分别处理Spark Core提供内存计算框架、SparkStreaming的实时处理应用、Spark SQL的即席查询、MLlib或MLbase的机器学习和GraphX的图处理，它们都是由AMP实验室提供，能够无缝的集成并提供一站式解决平台。 l随处运行 Spark具有很强的适应性，能够读取HDFS、Cassandra、HBase、S3和Techyon为持久层读写原生数据，能够以Mesos、YARN和自身携带的Standalone作为资源管理器调度job，来完成Spark应用程序的计算。 1.2Spark与Hadoop差异 Spark是在借鉴了MapReduce之上发展而来的，继承了其分布式并行计算的优点并改进了MapReduce明显的缺陷，具体如下： 首先，Spark把中间数据放到内存中，迭代运算效率高。MapReduce中计算结果需要落地，保存到磁盘上，这样势必会影响整体速度，而Spark支持DAG图的分布式并行计算的编程框架，减少了迭代过程中数据的落地，提高了处理效率。 其次，Spark容错性高。Spark引进了弹性分布式数据集RDD (Resilient Distributed Dataset)的抽象，它是分布在一组节点中的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可以根据“血统”（即充许基于数据衍生过程）对它们进行重建。另外在RDD计算时可以通过CheckPoint来实现容错，而CheckPoint有两种方式：CheckPoint Data，和Logging The Updates，用户可以控制采用哪种方式来实现容错。 最后，Spark更加通用。不像Hadoop只提供了Map和Reduce两种操作，Spark提供的数据集操作类型有很多种，大致分为：Transformations和Actions两大类。Transformations包括Map、Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、Join、Cogroup、MapValues、Sort和PartionBy等多种操作类型，同时还提供Count, Actions包括Collect、Reduce、Lookup和Save等操作。另外各个处理节点之间的通信模型不再像Hadoop只有Shuffle一种模式，用户可以命名、物化，控制中间结果的存储、分区等。 1.3Spark的适用场景 目前大数据处理场景有以下几个类型： 1.复杂的批量处理（Batch Data Processing），偏重点在于处理海量数据的能力，至于处理速度可忍受，通常的时间可能是在数十分钟到数小时； 2.基于历史数据的交互式查询（Interactive Query），通常的时间在数十秒到数十分钟之间 3.基于实时数据流的数据处理（Streaming Data Processing），通常在数百毫秒到数秒之间 目前对以上三种场景需求都有比较成熟的处理框架，第一种情况可以用Hadoop的MapReduce来进行批量海量数据处理，第二种情况可以Impala进行交互式查询，对于第三中情况可以用Storm分布式处理框架处理实时流式数据。以上三者都是比较独立，各自一套维护成本比较高，而Spark的出现能够一站式平台满意以上需求。 通过以上分析，总结Spark场景有以下几个： lSpark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小 l由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合 l数据量不是特别大，但是要求实时统计分析需求 1.4Spark演进时间表 演进时间表： l2009年由Berkeley's AMPLab开始编写最初的源代码 l2010年开放源代码 l2013年6月进入Apache孵化器项目 l2014年2月成为Apache的顶级项目（8个月时间） l2014年5月底Spark1.0.0发布 l2014年9月Spark1.1.0发布 l2014年12月Spark1.2.0发布 目前情况： l目前已经有30+公司100+开发者在提交代码 lHadoop最大的厂商Cloudera宣称加大Spark框架的投入来取代Mapreduce lHortonworks lHadoop厂商MapR投入Spark阵营 lApache Mahout放弃MapReduce，将使用Spark作为后续算子的计算平台 1.5Spark成功案例 目前大数据在互联网公司主要应用在广告、报表、推荐系统等业务上。在广告业务方面需要大数据做应用分析、效果分析、定向优化等，在推荐系统方面则需要大数据优化相关排名、个性化推荐以及热点点击分析等。这些应用场景的普遍特点是计算量大、效率要求高。Spark恰恰满足了这些要求，该项目一经推出便受到开源社区的广泛关注和好评。并在近两年内发展成为大数据处理领域最炙手可热的开源项目。 本章将列举国内外应用Spark的成功案例。 1.腾讯 广点通是最早使用Spark的应用之一。腾讯大数据精准推荐借助Spark快速迭代的优势，围绕“数据+算法+系统”这套技术方案，实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法，最终成功应用于广点通pCTR投放系统上，支持每天上百亿的请求量。 基于日志数据的快速查询系统业务构建于Spark之上的Shark，利用其快速查询以及内存表等优势，承担了日志数据的即席查询工作。在性能方面，普遍比Hive高2-10倍，如果使用内存表的功能，性能将会比Hive快百倍。 2. Yahoo Yahoo将Spark用在Audience Expansion中的应用。Audience Expansion是广告中寻找目标用户的一种方法：首先广告者提供一些观看了广告并且购买产品的样本客户，据此进行学习，寻找更多可能转化的用户，对他们定向广告。Yahoo采用的算法是logistic regression。同时由于有些SQL负载需要更高的服务质量，又加入了专门跑Shark的大内存集群，用于取代商业BI/OLAP工具，承担报表/仪表盘和交互式/即席查询，同时与桌面BI工具对接。目前在Yahoo部署的Spark集群有112台节点，9.2TB内存。 3.淘宝 阿里搜索和广告业务，最初使用Mahout或者自己写的MR来解决复杂的机器学习，导致效率低而且代码不易维护。淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。将Spark运用于淘宝的推荐相关算法上,同时还利用Graphx解决了许多生产问题，包括以下计算场景：基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。 4.优酷土豆 优酷土豆在使用Hadoop集群的突出问题主要包括：第一是商业智能BI方面，分析师提交任务之后需要等待很久才得到结果；第二就是大数据量计算，比如进行一些模拟广告投放之时，计算量非常大的同时对效率要求也比较高，最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。 最终发现这些应用场景并不适合在MapReduce里面去处理。通过对比，发现Spark性能比MapReduce提升很多。首先，交互查询响应快，性能比Hadoop提高若干倍；模拟广告投放计算效率高、延迟小（同hadoop比延迟至少降低一个数量级）；机器学习、图计算等迭代计算，大大减少了网络传输、数据落地等，极大的提高的计算性能。目前Spark已经广泛使用在优酷土豆的视频推荐（图计算）、广告业务等。 1.6Spark术语 1.6.1Spark运行模式 运行环境 模式 描述 Local 本地模式 常用于本地开发测试，本地还分为local单线程和local-cluster多线程; Standalone 集群模式 典型的Mater/slave模式，不过也能看出Master是有单点故障的；Spark支持ZooKeeper来实现HA On yarn 集群模式 运行在yarn资源管理器框架之上，由yarn负责资源管理，Spark负责任务调度和计算 On mesos 集群模式 运行在mesos资源管理器框架之上，由mesos负责资源管理，Spark负责任务调度和计算 On cloud 集群模式 比如AWS的EC2，使用这个模式能很方便的访问Amazon的S3; Spark支持多种分布式存储系统：HDFS和S3 1.6.2Spark常用术语 术语 描述 Application Spark的应用程序，包含一个Driver program和若干Executor SparkContext Spark应用程序的入口，负责调度各个运算资源，协调各个Worker Node上的Executor Driver Program 运行Application的main()函数并且创建SparkContext Executor 是为Application运行在Worker node上的一个进程，该进程负责运行Task，并且负责将数据存在内存或者磁盘上。 每个Application都会申请各自的Executor来处理任务 Cluster Manager 在集群上获取资源的外部服务 (例如：Standalone、Mesos、Yarn) Worker Node 集群中任何可以运行Application代码的节点，运行一个或多个Executor进程 Task 运行在Executor上的工作单元 Job SparkContext提交的具体Action操作，常和Action对应 Stage 每个Job会被拆分很多组task，每组任务被称为Stage，也称TaskSet RDD 是Resilient distributed datasets的简称，中文为弹性分布式数据集;是Spark最核心的模块和类 DAGScheduler 根据Job构建基于Stage的DAG，并提交Stage给TaskScheduler TaskScheduler 将Taskset提交给Worker node集群运行并返回结果 Transformations 是Spark API的一种类型，Transformation返回值还是一个RDD， 所有的Transformation采用的都是懒策略，如果只是将Transformation提交是不会执行计算的 Action 是Spark API的一种类型，Action返回值不是一个RDD，而是一个scala集合；计算只有在Action被提交的时候计算才被触发。 2、生态系统 Spark生态圈也称为BDAS（伯克利数据分析栈），是伯克利APMLab实验室打造的，力图在算法（Algorithms）、机器（Machines）、人（People）之间通过大规模集成来展现大数据应用的一个平台。伯克利AMPLab运用大数据、云计算、通信等各种资源以及各种灵活的技术方案，对海量不透明的数据进行甄别并转化为有用的信息，以供人们更好的理解世界。该生态圈已经涉及到机器学习、数据挖掘、数据库、信息检索、自然语言处理和语音识别等多个领域。 Spark生态圈以Spark Core为核心，从HDFS、Amazon S3和HBase等持久层读取数据，以MESS、YARN和自身携带的Standalone为资源管理器调度Job完成Spark应用程序的计算。 这些应用程序可以来自于不同的组件，如Spark Shell/Spark Submit的批处理、Spark Streaming的实时处理应用、Spark SQL的即席查询、BlinkDB的权衡查询、MLlib/MLbase的机器学习、GraphX的图处理和SparkR的数学计算等等。 2.1Spark Core 前面介绍了Spark Core的基本情况，以下总结一下Spark内核架构： l提供了有向无环图（DAG）的分布式并行计算框架，并提供Cache机制来支持多次迭代计算或者数据共享，大大减少迭代计算之间读取数据局的开销，这对于需要进行多次迭代的数据挖掘和分析性能有很大提升 l在Spark中引入了RDD (Resilient Distributed Dataset)的抽象，它是分布在一组节点中的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可以根据“血统”对它们进行重建，保证了数据的高容错性； l移动计算而非移动数据，RDD Partition可以就近读取分布式文件系统中的数据块到各个节点内存中进行计算 l使用多线程池模型来减少task启动开稍 l采用容错的、高可伸缩性的akka作为通讯框架 2.2SparkStreaming SparkStreaming是一个对实时数据流进行高通量、容错处理的流式处理系统，可以对多种数据源（如Kdfka、Flume、Twitter、Zero和TCP套接字）进行类似Map、Reduce和Join等复杂操作，并将结果保存到外部文件系统、数据库或应用到实时仪表盘。 Spark Streaming构架 l计算流程：Spark Streaming是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark Core，也就是把Spark Streaming的输入数据按照batch size（如1秒）分成一段一段的数据（Discretized Stream），每一段数据都转换成Spark中的RDD（Resilient Distributed Dataset），然后将Spark Streaming中对DStream的Transformation操作变为针对Spark中对RDD的Transformation操作，将RDD经过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行叠加或者存储到外部设备。下图显示了Spark Streaming的整个流程。 图Spark Streaming构架 l容错性：对于流式计算来说，容错性至关重要。首先我们要明确一下Spark中RDD的容错机制。每一个RDD都是一个不可变的分布式可重算的数据集，其记录着确定性的操作继承关系（lineage），所以只要输入数据是可容错的，那么任意一个RDD的分区（Partition）出错或不可用，都是可以利用原始输入数据通过转换操作而重新算出的。 对于Spark Streaming来说，其RDD的传承关系如下图所示，图中的每一个椭圆形表示一个RDD，椭圆形中的每个圆形代表一个RDD中的一个Partition，图中的每一列的多个RDD表示一个DStream（图中有三个DStream），而每一行最后一个RDD则表示每一个Batch Size所产生的中间结果RDD。我们可以看到图中的每一个RDD都是通过lineage相连接的，由于Spark Streaming输入数据可以来自于磁盘，例如HDFS（多份拷贝）或是来自于网络的数据流（Spark Streaming会将网络输入数据的每一个数据流拷贝两份到其他的机器）都能保证容错性，所以RDD中任意的Partition出错，都可以并行地在其他机器上将缺失的Partition计算出来。这个容错恢复方式比连续计算模型（如Storm）的效率更高。 Spark Streaming中RDD的lineage关系图 l实时性：对于实时性的讨论，会牵涉到流式处理框架的应用场景。Spark Streaming将流式计算分解成多个Spark Job，对于每一段数据的处理都会经过Spark DAG图分解以及Spark的任务集的调度过程。对于目前版本的Spark Streaming而言，其最小的Batch Size的选取在0.5~2秒钟之间（Storm目前最小的延迟是100ms左右），所以Spark Streaming能够满足除对实时性要求非常高（如高频实时交易）之外的所有流式准实时计算场景。 l扩展性与吞吐量：Spark目前在EC2上已能够线性扩展到100个节点（每个节点4Core），可以以数秒的延迟处理6GB/s的数据量（60M records/s），其吞吐量也比流行的Storm高2～5倍，图4是Berkeley利用WordCount和Grep两个用例所做的测试，在Grep这个测试中，Spark Streaming中的每个节点的吞吐量是670k records/s，而Storm是115k records/s。 Spark Streaming与Storm吞吐量比较图 2.3Spark SQL Shark是SparkSQL的前身，它发布于3年前，那个时候Hive可以说是SQL on Hadoop的唯一选择，负责将SQL编译成可扩展的MapReduce作业，鉴于Hive的性能以及与Spark的兼容，Shark项目由此而生。 Shark即Hive on Spark，本质上是通过Hive的HQL解析，把HQL翻译成Spark上的RDD操作，然后通过Hive的metadata获取数据库里的表信息，实际HDFS上的数据和文件，会由Shark获取并放到Spark上运算。Shark的最大特性就是快和与Hive的完全兼容，且可以在shell模式下使用rdd2sql()这样的API，把HQL得到的结果集，继续在scala环境下运算，支持自己编写简单的机器学习或简单分析处理函数，对HQL结果进一步分析计算。 在2014年7月1日的Spark Summit上，Databricks宣布终止对Shark的开发，将重点放到Spark SQL上。Databricks表示，Spark SQL将涵盖Shark的所有特性，用户可以从Shark 0.9进行无缝的升级。在会议上，Databricks表示，Shark更多是对Hive的改造，替换了Hive的物理执行引擎，因此会有一个很快的速度。然而，不容忽视的是，Shark继承了大量的Hive代码，因此给优化和维护带来了大量的麻烦。随着性能优化和先进分析整合的进一步加深，基于MapReduce设计的部分无疑成为了整个项目的瓶颈。因此，为了更好的发展，给用户提供一个更好的体验，Databricks宣布终止Shark项目，从而将更多的精力放到Spark SQL上。 Spark SQL允许开发人员直接处理RDD，同时也可查询例如在Apache Hive上存在的外部数据。Spark SQL的一个重要特点是其能够统一处理关系表和RDD，使得开发人员可以轻松地使用SQL命令进行外部查询，同时进行更复杂的数据分析。除了Spark SQL外，Michael还谈到Catalyst优化框架，它允许Spark SQL自动修改查询方案，使SQL更有效地执行。 还有Shark的作者是来自中国的博士生辛湜（Reynold Xin），也是Spark的核心成员，具体信息可以看他的专访http://www.csdn.net/article/2013-04-26/2815057-Spark-Reynold Spark SQL的特点: l引入了新的RDD类型SchemaRDD，可以象传统数据库定义表一样来定义SchemaRDD，SchemaRDD由定义了列数据类型的行对象构成。SchemaRDD可以从RDD转换过来，也可以从Parquet文件读入，也可以使用HiveQL从Hive中获取。 l内嵌了Catalyst查询优化框架，在把SQL解析成逻辑执行计划之后，利用Catalyst包里的一些类和接口，执行了一些简单的执行计划优化，最后变成RDD的计算 l在应用程序中可以混合使用不同来源的数据，如可以将来自HiveQL的数据和来自SQL的数据进行Join操作。 Shark的出现使得SQL-on-Hadoop的性能比Hive有了10-100倍的提高，那么，摆脱了Hive的限制，SparkSQL的性能又有怎么样的表现呢？虽然没有Shark相对于Hive那样瞩目地性能提升，但也表现得非常优异，如下图所示： 为什么sparkSQL的性能会得到怎么大的提升呢？主要sparkSQL在下面几点做了优化： 1.内存列存储（In-Memory Columnar Storage）sparkSQL的表数据在内存中存储不是采用原生态的JVM对象存储方式，而是采用内存列存储； 2.字节码生成技术（Bytecode Generation）Spark1.1.0在Catalyst模块的expressions增加了codegen模块，使用动态字节码生成技术，对匹配的表达式采用特定的代码动态编译。另外对SQL表达式都作了CG优化，CG优化的实现主要还是依靠Scala2.10的运行时放射机制（runtime reflection）； 3.Scala代码优化SparkSQL在使用Scala编写代码的时候，尽量避免低效的、容易GC的代码；尽管增加了编写代码的难度，但对于用户来说接口统一。 2.4BlinkDB BlinkDB是一个用于在海量数据上运行交互式SQL查询的大规模并行查询引擎，它允许用户通过权衡数据精度来提升查询响应时间，其数据的精度被控制在允许的误差范围内。为了达到这个目标，BlinkDB使用两个核心思想: l一个自适应优化框架，从原始数据随着时间的推移建立并维护一组多维样本； l一个动态样本选择策略，选择一个适当大小的示例基于查询的准确性和（或）响应时间需求。 和传统关系型数据库不同，BlinkDB是一个很有意思的交互式查询系统，就像一个跷跷板，用户需要在查询精度和查询时间上做一权衡；如果用户想更快地获取查询结果，那么将牺牲查询结果的精度；同样的，用户如果想获取更高精度的查询结果，就需要牺牲查询响应时间。用户可以在查询的时候定义一个失误边界。 2.5MLBase/MLlib MLBase是Spark生态圈的一部分专注于机器学习，让机器学习的门槛更低，让一些可能并不了解机器学习的用户也能方便地使用MLbase。MLBase分为四部分：MLlib、MLI、ML Optimizer和MLRuntime。 lML Optimizer会选择它认为最适合的已经在内部实现好了的机器学习算法和相关参数，来处理用户输入的数据，并返回模型或别的帮助分析的结果； lMLI是一个进行特征抽取和高级ML编程抽象的算法实现的API或平台； lMLlib是Spark实现一些常见的机器学习算法和实用程序，包括分类、回归、聚类、协同过滤、降维以及底层优化，该算法可以进行可扩充；MLRuntime基于Spark计算框架，将Spark的分布式计算应用到机器学习领域。 总的来说，MLBase的核心是他的优化器，把声明式的Task转化成复杂的学习计划，产出最优的模型和计算结果。与其他机器学习Weka和Mahout不同的是： lMLBase是分布式的，Weka是一个单机的系统； lMLBase是自动化的，Weka和Mahout都需要使用者具备机器学习技能，来选择自己想要的算法和参数来做处理； lMLBase提供了不同抽象程度的接口，让算法可以扩充 lMLBase基于Spark这个平台 2.6GraphX GraphX是Spark中用于图(e.g., Web-Graphs and Social Networks)和图并行计算(e.g., PageRank and Collaborative Filtering)的API,可以认为是GraphLab(C++)和Pregel(C++)在Spark(Scala)上的重写及优化，跟其他分布式图计算框架相比，GraphX最大的贡献是，在Spark之上提供一栈式数据解决方案，可以方便且高效地完成图计算的一整套流水作业。GraphX最先是伯克利AMPLAB的一个分布式图计算框架项目，后来整合到Spark中成为一个核心组件。 GraphX的核心抽象是Resilient Distributed Property Graph，一种点和边都带属性的有向多重图。它扩展了Spark RDD的抽象，有Table和Graph两种视图，而只需要一份物理存储。两种视图都有自己独有的操作符，从而获得了灵活操作和执行效率。如同Spark，GraphX的代码非常简洁。GraphX的核心代码只有3千多行，而在此之上实现的Pregel模型，只要短短的20多行。GraphX的代码结构整体下图所示，其中大部分的实现，都是围绕Partition的优化进行的。这在某种程度上说明了点分割的存储和相应的计算优化的确是图计算框架的重点和难点。 GraphX的底层设计有以下几个关键点。 1.对Graph视图的所有操作，最终都会转换成其关联的Table视图的RDD操作来完成。这样对一个图的计算，最终在逻辑上，等价于一系列RDD的转换过程。因此，Graph最终具备了RDD的3个关键特性：Immutable、Distributed和Fault-Tolerant。其中最关键的是Immutable（不变性）。逻辑上，所有图的转换和操作都产生了一个新图；物理上，GraphX会有一定程度的不变顶点和边的复用优化，对用户透明。 2.两种视图底层共用的物理数据，由RDD[Vertex-Partition]和RDD[EdgePartition]这两个RDD组成。点和边实际都不是以表Collection[tuple]的形式存储的，而是由VertexPartition/EdgePartition在内部存储一个带索引结构的分片数据块，以加速不同视图下的遍历速度。不变的索引结构在RDD转换过程中是共用的，降低了计算和存储开销。 3.图的分布式存储采用点分割模式，而且使用partitionBy方法，由用户指定不同的划分策略（PartitionStrategy）。划分策略会将边分配到各个EdgePartition，顶点Master分配到各个VertexPartition，EdgePartition也会缓存本地边关联点的Ghost副本。划分策略的不同会影响到所需要缓存的Ghost副本数量，以及每个EdgePartition分配的边的均衡程度，需要根据图的结构特征选取最佳策略。目前有EdgePartition2d、EdgePartition1d、RandomVertexCut和CanonicalRandomVertexCut这四种策略。在淘宝大部分场景下，EdgePartition2d效果最好。 2.7SparkR SparkR是AMPLab发布的一个R开发包，使得R摆脱单机运行的命运，可以作为Spark的job运行在集群上，极大得扩展了R的数据处理能力。 SparkR的几个特性： l提供了Spark中弹性分布式数据集（RDD）的API，用户可以在集群上通过R shell交互性的运行Spark job。 l支持序化闭包功能，可以将用户定义函数中所引用到的变量自动序化发送到集群中其他的机器上。 lSparkR还可以很容易地调用R开发包，只需要在集群上执行操作前用includePackage读取R开发包就可以了，当然集群上要安装R开发包。 2.8Tachyon Tachyon是一个高容错的分布式文件系统，允许文件以内存的速度在集群框架中进行可靠的共享，就像Spark和MapReduce那样。通过利用信息继承，内存侵入，Tachyon获得了高性能。Tachyon工作集文件缓存在内存中，并且让不同的Jobs/Queries以及框架都能内存的速度来访问缓存文件”。因此，Tachyon可以减少那些需要经常使用的数据集通过访问磁盘来获得的次数。Tachyon兼容Hadoop，现有的Spark和MR程序不需要任何修改而运行。 在2013年4月，AMPLab共享了其Tachyon 0.2.0 Alpha版本的Tachyon，其宣称性能为HDFS的300倍，继而受到了极大的关注。Tachyon的几个特性如下： lJAVA-Like File API Tachyon提供类似JAVA File类的API, l兼容性 Tachyon实现了HDFS接口，所以Spark和MR程序不需要任何修改即可运行。 l可插拔的底层文件系统 Tachyon是一个可插拔的底层文件系统，提供容错功能。tachyon将内存数据记录在底层文件系统。它有一个通用的接口，使得可以很容易的插入到不同的底层文件系统。目前支持HDFS，S3，GlusterFS和单节点的本地文件系统，以后将支持更多的文件系统。 参考资料： （1）Spark官网http://spark.apache.org （2）Spark生态圈参考《Spark1.0.0生态圈一览》http://blog.csdn.net/book_mmicky/article/details/29362405 （3）Spark应用案例参考《大数据计算新贵Spark在腾讯雅虎优酷成功应用解析》http://www.csdn.net/article/2014-06-05/2820089 （4）Spark Streming介绍参考《Spark Streaming：大规模流式数据处理的新贵》http://www.csdn.net/article/2014-01-28/2818282-Spark-Streaming-big-data （5）Spark SQL介绍《sparkSQL1.1入门》http://blog.csdn.net/bluejoe2000/article/details/41247857 （6）GraphX参考《快刀初试：Spark GraphX在淘宝的实践》http://www.csdn.net/article/2014-08-07/2821097 （7）GraphX参考《基于Spark的图计算框架GraphX入门介绍》http://suanfazu.com/t/ji-yu-sparkde-tu-ji-suan-kuang-jia-graphx-ru-men-jie-shao/244 （8）【Spark专刊】Spark最佳学习路径（作者：黄忠）
2016-05-24
优秀的个人博客,低调大师

Spark-基础-Spark编译与部署--Spark编译安装

1、编译Spark（1.1版本） Spark可以通过SBT和Maven两种方式进行编译，再通过make-distribution.sh脚本生成部署包。SBT编译需要安装git工具，而Maven安装则需要maven工具，两种方式均需要在联网下进行，通过比较发现SBT编译速度较慢（原因有可能是1、时间不一样，SBT是白天编译，Maven是深夜进行的，获取依赖包速度不同2、maven下载大文件是多线程进行，而SBT是单进程），Maven编译成功前后花了3、4个小时。 1.1编译Spark（SBT） 1.1.1安装git并编译安装 1.从如下地址下载git安装包 http://www.onlinedown.net/softdown/169333_2.htm https://www.kernel.org/pub/software/scm/git/ 如果linux是CentOS操作系统可以通过：yum install git直接进行安装 由于从https获取内容，需要安装curl-devel，可以从如下地址获取 http://rpmfind.net/linux/rpm2html/search.php?query=curl-devel 如果linux是CentOS操作系统可以通过：yum install curl-devel直接进行安装 2.上传git并解压缩 把git-1.7.6.tar.gz安装包上传到/home/hadoop/upload目录中，解压缩然后放到/app目录下 $cd /home/hadoop/upload/ $tar -xzf git-1.7.6.tar.gz $mv git-1.7.6 /app $ll /app 3.编译安装git 以root用户进行在git所在路径编译安装git #yum install curl-devel #cd /app/git-1.7.6 #./configure #make #make install 4.把git加入到PATH路径中 打开/etc/profile把git所在路径加入到PATH参数中 export GIT_HOME=/app/git-1.7.6 export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$GIT_HOME/bin 重新登录或者使用source /etc/profile使参数生效，然后使用git命令查看配置是否正确 1.1.2下载Spark源代码并上传 1.可以从如下地址下载到spark源代码： http://spark.apache.org/downloads.html http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0.tgz git clone https://github.com/apache/spark.git 把下载好的spark-1.1.0.tgz源代码包使用1.1.3.1介绍的工具上传到/home/hadoop/upload目录下 2.在主节点上解压缩 $cd /home/hadoop/upload/ $tar -xzf spark-1.1.0.tgz 3.把spark-1.1.0改名并移动到/app/complied目录下 $mv spark-1.1.0 /app/complied/spark-1.1.0-sbt $ls /app/complied 1.1.3编译代码 编译spark源代码的时候，需要从网上下载依赖包，所以整个编译过程机器必须保证在联网状态。编译执行如下脚本： $cd /app/complied/spark-1.1.0-sbt $sbt/sbt assembly -Pyarn -Phadoop-2.2 -Pspark-ganglia-lgpl -Pkinesis-asl -Phive 整个编译过程编译了约十几个任务，重新编译N次，需要几个甚至十几个小时才能编译完成（主要看下载依赖包的速度）。 1.2编译Spark（Maven） 1.2.1安装Maven并配置参数 在编译前最好安装3.0以上版本的Maven，在/etc/profile配置文件中加入如下设置： export MAVEN_HOME=/app/apache-maven-3.0.5 export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$GIT_HOME/bin 1.2.2下载Spark源代码并上传 1.可以从如下地址下载到spark源代码： http://spark.apache.org/downloads.html http://d3kbcqa49mib13.cloudfront.net/spark-1.1.0.tgz git clone https://github.com/apache/spark.git 把下载好的spark-1.1.0.tgz源代码包使用1.1.3.1介绍的工具上传到/home/hadoop/upload目录下 2.在主节点上解压缩 $cd /home/hadoop/upload/ $tar -xzf spark-1.1.0.tgz 3.把spark-1.1.0改名并移动到/app/complied目录下 $mv spark-1.1.0 /app/complied/spark-1.1.0-mvn $ls /app/complied 1.2.3编译代码 编译spark源代码的时候，需要从网上下载依赖包，所以整个编译过程机器必须保证在联网状态。编译执行如下脚本： $cd /app/complied/spark-1.1.0-mvn $export MAVEN_OPTS="-Xmx2g -XX:MaxPermSize=512M -XX:ReservedCodeCacheSize=512m" $mvn -Pyarn -Phadoop-2.2 -Pspark-ganglia-lgpl -Pkinesis-asl -Phive -DskipTests clean package 整个编译过程编译了约24个任务，整个过程耗时1小时45分钟。 1.3生成Spark部署包 在Spark源码根目录下有一个生成部署包的脚本make-distribution.sh，可以通过执行如下命令进行打包./make-distribution.sh [--name] [--tgz] [--with-tachyon] <maven build options> l--name NAME和--tgz结合可以生成spark-$VERSION-bin-$NAME.tgz的部署包，不加此参数时NAME为hadoop的版本号 l--tgz在根目录下生成spark-$VERSION-bin.tgz，不加此参数时不生成tgz文件，只生成/dist目录 l--with-tachyon是否支持内存文件系统Tachyon，不加此参数时不支持tachyon 例子： 1.生成支持yarn、hadoop2.2.0、hive的部署包： ./make-distribution.sh --tgz --name 2.2.0 -Pyarn -Phadoop-2.2 -Phive 2.生成支持yarn、hadoop2.2.0、hive、ganglia的部署包： ./make-distribution.sh --tgz --name 2.2.0 -Pyarn -Phadoop-2.2 -Pspark-ganglia-lgpl -P hive 1.3.1生成部署包 使用如下命令生成Spark部署包，由于该脚本默认在JDK1.6进行，在开始时会进行询问是否继续，只要选择Y即可 $cd /app/complied/spark-1.1.0-mvn/ $./make-distribution.sh --tgz --name 2.2.0 -Pyarn -Phadoop-2.2 -Pspark-ganglia-lgpl -P hive 生成Spark部署包编译了约24个任务，用时大概1小时38分钟。 1.3.2查看生成结果 生成在部署包位于根目录下，文件名类似于spark-1.1.0-bin-2.2.0.tgz。 2、安装Spark 2.1上传并解压Spark安装包 1.我们使用上一步骤编译好的spark-1.1.0-bin-2.2.0.tgz文件作为安装包（也可以从网上下载native文件夹或者打包好的64位hadoop安装包），使用"Spark编译与部署（上）"中1. 3.1介绍的工具上传到/home/hadoop/upload目录下 2.在主节点上解压缩 $cd /home/hadoop/upload/ $tar -xzf spark-1.1.0-bin-2.2.0.tgz 3.把spark改名并移动到/app/hadoop目录下 $mv spark-1.1.0-bin-2.2.0 /app/hadoop/spark-1.1.0 $ll /app/hadoop 2.2配置/etc/profile 1.打开配置文件/etc/profile $sudo vi /etc/profile 2.定义SPARK_HOME并把spark路径加入到PATH参数中 SPARK_HOME=/app/hadoop/spark-1.1.0 PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin 2.3配置conf/slaves 1.打开配置文件conf/slaves $cd /app/hadoop/spark-1.1.0/conf $sudo vi slaves 2.加入slave配置节点 hadoop1 hadoop2 hadoop3 2.4配置conf/spark-env.sh 1.打开配置文件conf/spark-env.sh $cd /app/hadoop/spark-1.1.0/conf $cp spark-env.sh.template spark-env.sh $sudo vi spark-env.sh 2.加入Spark环境配置内容，设置hadoop1为Master节点 export SPARK_MASTER_IP=hadoop1 export SPARK_MASTER_PORT=7077 export SPARK_WORKER_CORES=1 export SPARK_WORKER_INSTANCES=1 export SPARK_WORKER_MEMORY=512M 2.5向各节点分发Spark程序 1.进入hadoop1机器/app/hadoop目录，使用如下命令把spark文件夹复制到hadoop2和hadoop3机器 $cd /app/hadoop $scp -r spark-1.1.0 hadoop@hadoop2:/app/hadoop/ $scp -r spark-1.1.0 hadoop@hadoop3:/app/hadoop/ 2.在从节点查看是否复制成功 2.6启动Spark $cd /app/hadoop/spark-1.1.0/sbin $./start-all.sh 2.7验证启动 此时在hadoop1上面运行的进程有：Worker和Master 此时在hadoop2和hadoop3上面运行的进程有只有Worker 通过netstat -nlt命令查看hadoop1节点网络情况 在浏览器中输入http://hadoop1:8080（需要注意的是要在网络设置中把hadoop*除外，否则会到外网DNS解析，出现无法访问的情况） 既可以进入Spark集群状态页面 2.8验证客户端连接 进入hadoop1节点，进入spark的bin目录，使用spark-shell连接集群 $cd /app/hadoop/spark-1.1.0/bin $spark-shell --master spark://hadoop1:7077 --executor-memory 500m 在命令中只指定了内存大小并没有指定核数，所以该客户端将占用该集群所有核并在每个节点分配500M内存 3、Spark测试 3.1使用Spark-shell测试 这里我们测试一下在Hadoop中大家都知道的WordCout程序，在MapReduce实现WordCout需要Map、Reduce和Job三个部分，而在Spark中甚至一行就能够搞定。下面就看一下是如何实现的： 3.1.1启动HDFS $cd /app/hadoop/hadoop-2.2.0/sbin $./start-dfs.sh 通过jps观察启动情况，在hadoop1上面运行的进程有：NameNode、SecondaryNameNode和DataNode hadoop2和hadoop3上面运行的进程有：NameNode和DataNode 3.1.2上传数据到HDFS中 把hadoop配置文件core-site.xml文件作为测试文件上传到HDFS中 $hadoop fs -mkdir -p /user/hadoop/testdata $hadoop fs -put /app/hadoop/hadoop-2.2.0/etc/hadoop/core-site.xml /user/hadoop/testdata 3.1.3启动Spark $cd /app/hadoop/spark-1.1.0/sbin $./start-all.sh 3.1.4启动Spark-shell 在spark客户端（这里在hadoop1节点)，使用spark-shell连接集群 $cd /app/hadoop/spark-1.1.0/bin $./spark-shell --master spark://hadoop1:7077 --executor-memory 512m --driver-memory 500m 3.1.5运行WordCount脚本 下面就是WordCount的执行脚本，该脚本是scala编写，以下为一行实现： scala>sc.textFile("hdfs://hadoop1:9000/user/hadoop/testdata/core-site.xml").flatMap(_.split(" ")).map(x=>(x,1)).reduceByKey(_+_).map(x=>(x._2,x._1)).sortByKey(false).map(x=>(x._2,x._1)).take(10) 为了更好看到实现过程，下面将逐行进行实现： scala>val rdd=sc.textFile("hdfs://hadoop1:9000/user/hadoop/testdata/core-site.xml") scala>rdd.cache() scala>val wordcount=rdd.flatMap(_.split(" ")).map(x=>(x,1)).reduceByKey(_+_) scala>wordcount.take(10) scala>val wordsort=wordcount.map(x=>(x._2,x._1)).sortByKey(false).map(x=>(x._2,x._1)) scala>wordsort.take(10) 词频统计结果如下： Array[(String, Int)] = Array(("",100), (the,7), (</property>,6), (<property>,6), (under,3), (in,3), (License,3), (this,2), (-->,2), (file.,2)) 3.1.6观察运行情况 通过http://hadoop1:8080查看Spark运行情况，可以看到Spark为3个节点，每个节点各为1个内核/512M内存，客户端分配3个核，每个核有512M内存。 通过点击客户端运行任务ID，可以看到该任务在hadoop2和hadoop3节点上运行，在hadoop1上并没有运行，主要是由于hadoop1为NameNode和Spark客户端造成内存占用过大造成 3.2使用Spark-submit测试 从Spark1.0.0开始，Spark提供了一个易用的应用程序部署工具bin/spark-submit，可以完成Spark应用程序在local、Standalone、YARN、Mesos上的快捷部署。该工具语法及参数说明如下： Usage: spark-submit [options] <app jar | python file> [app options] Options: --master MASTER_URLspark://host:port, mesos://host:port, yarn, or local. --deploy-mode DEPLOY_MODEdriver运行之处，client运行在本机，cluster运行在集群 --class CLASS_NAME应用程序包的要运行的class --name NAME应用程序名称 --jars JARS用逗号隔开的driver本地jar包列表以及executor类路径 --py-files PY_FILES用逗号隔开的放置在Python应用程序 PYTHONPATH上的.zip, .egg, .py文件列表 --files FILES用逗号隔开的要放置在每个executor工作目录的文件列表 --properties-file FILE设置应用程序属性的文件放置位置，默认是conf/spark-defaults.conf --driver-memory MEMdriver内存大小，默认512M --driver-java-optionsdriver的java选项 --driver-library-pathdriver的库路径Extra library path entries to pass to the driver --driver-class-pathdriver的类路径，用--jars添加的jar包会自动包含在类路径里 --executor-memory MEMexecutor内存大小，默认1G Spark standalone with cluster deploy mode only: --driver-cores NUMdriver使用内核数，默认为1 --supervise如果设置了该参数，driver失败是会重启 Spark standalone and Mesos only: --total-executor-cores NUMexecutor使用的总核数 YARN-only: --executor-cores NUM每个executor使用的内核数，默认为1 --queue QUEUE_NAME提交应用程序给哪个YARN的队列，默认是default队列 --num-executors NUM启动的executor数量，默认是2个 --archives ARCHIVES被每个executor提取到工作目录的档案列表，用逗号隔开 3.2.1运行脚本1 该脚本为Spark自带例子，在该例子中个计算了圆周率π的值，以下为执行脚本： $cd /app/hadoop/spark-1.1.0/bin $./spark-submit --master spark://hadoop1:7077 --class org.apache.spark.examples.SparkPi --executor-memory 512m ../lib/spark-examples-1.1.0-hadoop2.2.0.jar 200 参数说明（详细可以参考上面的参数说明）： l--masterMaster所在地址，可以有Mesos、Spark、YARN和Local四种，在这里为Spark Standalone集群，地址为spark://hadoop1:7077 l--class应用程序调用的类名，这里为org.apache.spark.examples.SparkPi l--executor-memory每个executor所分配的内存大小，这里为512M l执行jar包这里是../lib/spark-examples-1.1.0-hadoop2.2.0.jar l分片数目这里数目为200 3.2.2观察运行情况 通过观察Spark集群有3个Worker节点和正在运行的1个应用程序，每个Worker节点为1内核/512M内存。由于没有指定应用程序所占内核数目，则该应用程序占用该集群所有3个内核，并且每个节点分配512M内存。 根据每个节点负载情况，每个节点运行executor并不相同，其中hadoop1的executor数目为0。而hadoop3执行executor数为10个，其中5个EXITED状态，5个KILLED状态。 3.2.3运行脚本2 该脚本为Spark自带例子，在该例子中个计算了圆周率π的值，区别脚本1这里指定了每个executor内核数据，以下为执行脚本： $cd /app/hadoop/spark-1.1.0/bin $./spark-submit --master spark://hadoop1:7077 --class org.apache.spark.examples.SparkPi --executor-memory 512m --total-executor-cores 2 ../lib/spark-examples-1.1.0-hadoop2.2.0.jar 200 参数说明（详细可以参考上面的参数说明）： l--masterMaster所在地址，可以有Mesos、Spark、YARN和Local四种，在这里为Spark Standalone集群，地址为spark://hadoop1:7077 l--class应用程序调用的类名，这里为org.apache.spark.examples.SparkPi l--executor-memory每个executor所分配的内存大小，这里为512M l--total-executor-cores 2每个executor分配的内核数 l执行jar包这里是../lib/spark-examples-1.1.0-hadoop2.2.0.jar l分片数目这里数目为200 3.2.4观察运行情况 通过观察Spark集群有3个Worker节点和正在运行的1个应用程序，每个Worker节点为1内核/512M内存。由于指定应用程序所占内核数目为2，则该应用程序使用该集群所有2个内核。
2016-05-24
优秀的个人博客,低调大师

HBase基础和伪分布式安装配置

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq1010885678/article/details/43796441 一、HBase(NoSQL)的数据模型 1.1 表(table)，是存储管理数据的。 1.2 行键(row key)，类似于MySQL中的主键，行键是HBase表天然自带的，创建表时不需要指定 1.3 列族(column family)，列的集合。 一张表中有多个行健，一个行健读取出来的是一条记录，列族和MySQL中的列差不多，但是它是列的集合 HBase中列族是需要在定义表时指定的，列是在插入记录时动态增加的。 HBase表中的数据存储在本地磁盘上的时候，每个列族单独一个作为文件存储。 上图表示HBase中表的一行 和关系型数据库不同的是 关系型数据库一行中每一个列的值只能是一个，如： UserId UserName 1 JChubby 而在NoSql中，一行里面某一个列的值可能是多个的，如上图，或者： UserId UserName 1 JChubby Looky 其中省略了timestamp时间戳这一列，但是在NoSql中读取这一行数据的出来时，数据应该是和关系型数据库读出来的是差不多的 时间戳列起到了标识列数据版本的作用，当没有指定时间戳的时候默认取的是最新的列数据，具体请参照上图 1.4 存储的数据都是字节数组。 二、HBase的物理模型 2.1 HBase是适合海量数据(如20PB)的秒级简单查询的数据库。 2.2 HBase表中的记录，按照行键进行拆分， 拆分成一个个的region。 如：在一个有1W行健的表中，每2K个行健拆分成一个region分别存储在不同的节点中，每个region记录着行健的起始位置和最终位置[startkey,endkey] 许多个region存储在region server(单独的物理机器)中的。 这样，对表的操作转化为对多台region server的并行查询。 HBase中有两种特殊的表，分别是-ROOT和.META .META中记录着各个region的起止行健，当.META中的记录很大时，又会按照相同的规则拆分成不同的region记录中-ROOT表中 如上图所示，当要查询数据时，先找-ROOT表中记录的region信息，找到对应的.META表中的region，在到实际的节点上的region查询数据 三、HBase的体系结构 3.1 HBase是主从式结构，HMaster、HRegionServer 四、HBase伪分布安装 HBase的安装是是建立在hadoop和zookeeper集群之上的 安装时确保hadoop和zookeeper集群已安装成功并启动 4.1 解压缩、重命名、设置环境变量 把hbase-0.94.2-security.tar.gz复制到/home/hadoop 解压hbase-0.94.2-security.tar.gz与重命名 #cd /home/hadoop #tar -zxvf hbase-0.94.2-security.tar.gz #mv hbase-0.94.2-security hbase 修改/etc/profile文件。 #vi /etc/profile 增加 export HBASE_HOME=/home/hadoop/hbase 修改 export PATH=$JAVA_HOME/bin:$PATH:$HADOOP_HOME/bin:$HBASE_HOME/bin 保存退出 #source /etc/profile 4.2 修改$HBASE_HOME/conf/hbase-env.sh，修改内容如下： export JAVA_HOME=/usr/java/jdk1.6.0_45 export HBASE_MANAGES_ZK=true 第一个配置java环境变量 第二个配置在本机器上的HBase可以自己启动zookeeper和使用 4.2 修改$HBASE_HOME/conf/hbase-site.xml，修改内容如下： <property> <name>hbase.rootdir</name> <value>hdfs://master:9000/hbase</value> </property> <property> <name>hbase.cluster.distributed</name> <value>true</value> </property> <property> <name>hbase.zookeeper.quorum</name> <value>master</value> </property> <property> <name>dfs.replication</name> <value>1</value> </property> hbase.rootdir配置在hdfs文件系统上hbase存储的路径 hbase.cluster.distributed配置是否是分布式的 hbase.zookeeper.quorum配置zookeeper在哪个节点上 dfs.replication配置副本个数 注意：hbase.rootdir的主机和端口号与hadoop的配置文件core-site.xml的fs.default.name的主机和端口号一致 4.3 (可选)文件regionservers的内容为master，该文件记录regionserver的各个节点的主机名，因为是伪分布式安装，所只写一个，localhost或者主机名都可以 4.4 启动hbase，在bin目录下执行命令start-hbase.sh ******启动hbase之前，确保hadoop是运行正常的，并且可以写入文件******* 4.5 验证是否安装成功： (1)执行jps，发现新增加了3个java进程，分别是HMaster、HRegionServer、HQuorumPeer (2)使用浏览器访问http://master:60010，可以进入和hadoop类似的web管理页面
2015-02-13

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-01-27 大小: 1MB 下载: 5次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-01-03 大小: 1.42GB 下载: 2次
热门标签
DeepSeek Kubernetes HarmonyOS6 SpringBoot4 Docker Gemini3 OpenAi Rocky Jdk25 Redis SpringCloud Service Mesh Nacos3

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册