Spark：大数据时代的电光火石-开源技术
Spark：大数据时代的电光火石-开源技术
Spark是起源于美国加州大学伯克利分校AMPLab的集群计算平台。它立足于内存计算，从多迭代批量处置出发，兼收并蓄数据仓库、流处置和图计算等多种计算范式，是罕有的万能选手。
Spark是起源于美国加州大学伯克利分校AMPLab的集群计算平台。它立足于内存计算，从多迭代批量处置出发，兼收并蓄数据仓库、流处置和图计算等多种计算范式，是罕有的万能选手。
Spark已正式申请加入Apache孵化器，从灵机一闪的实验室&电火花&成长为大数据技术平台中异军突起的新锐。本文主要讲述Spark的设计思想。Spark如其名，展现了大数据不常见的&电光石火&。具体特点归纳为&轻、快、灵和巧&。
轻：Spark 0.6焦点代码有2万行，Hadoop 1.0为9万行，2.0为22万行。一方面，感谢Scala语言的简练和丰硕表达力；另一方面，Spark很好地利用了Hadoop和Mesos（伯克利 另一个进入孵化器的项目，主攻集群的动态资源治理）的基础设施。虽然很轻，但在容错设计上不打折扣。主创人Matei声称：&不把错误当特例处置。&言下 之意，容错是基础设施的一部分。
快：Spark对小数据集能到达亚秒级的延迟，这对于Hadoop MapReduce（以下简称MapReduce）是无法想象的（由于&心跳&间隔机制，仅任务启动就有数秒的延迟）。就大数据集而言，对典型的迭代机器 学习、即席查询（ad-hoc query）、图计算等应用，Spark版本比基于MapReduce、Hive和Pregel的实现快上十倍到百倍。其中内存计算、数据当地性 （locality）和传输优化、调剂优化等该居首功，也与设计伊始即秉持的轻量理念不无关系。
灵：Spark提供了不同层面的灵活性。在实现层，它完美演绎了Scala trait动态混入（mixin）计谋（如可替换的集群调剂器、序列化库）；在原语（Primitive）层，它允许扩展新的数据算子 （operator）、新的数据源（如HDFS之外支持DynamoDB）、新的language bindings（Java和Python）；在范式（Paradigm）层，Spark支持内存计算、多迭代批量处置、即席查询、流处置和图计算等多种 范式。
巧：巧在借势和借力。Spark借Hadoop之势，与Hadoop无缝结合；接着Shark（Spark上的数据仓库实现）借了Hive的势；图计算借 用Pregel和PowerGraph的API以及PowerGraph的点支解思想。一切的一切，都借助了Scala（被广泛誉为Java的未来取代 者）之势：Spark编程的Look'n'Feel就是原汁原味的Scala，无论是语法还是API。在实现上，又能灵巧借力。为支持交互式编 程，Spark只需对Scala的Shell小做修改（相比之下，微软为支持JavaScript Console对MapReduce交互式编程，不仅要跨越Java和JavaScript的思维屏障，在实现上还要大动干戈）。
说了一大堆利益，还是要指出Spark未臻完美。它有先天的限制，不能很好地支持细粒度、异步的数据处置；也有后天的原由，纵然有很棒的基因，毕竟还刚刚起步，在性能、稳定性和范式的可扩展性上另有很大的空间。
计算范式和抽象
Spark首先是一种粗粒度数据并行（data parallel）的计算范式。
数据并行跟任务并行（task parallel）的区别体现在以下两方面。
计算的主体是数据集合，而非个别数据。集合的长度视实现而定，如SIMD（单指令多数据）向量指令通常是4到64，GPU的SIMT（单指令多线程）通常 是32，SPMD（单程序多数据）可以更宽。Spark处置的是大数据，因此接纳了粒度很粗的集合，叫做Resilient Distributed Datasets（RDD）。
集合内的所有数据都经过同样的算子序列。数据并行可编程性好，易于获得高并行性（与数据规模相关，而非与程序逻辑的并行性相关），也易于高效地映射到底层 的并行或分布式硬件上。传统的array/vector编程语言、SSE/AVX intrinsics、CUDA/OpenCL、Ct（C++ for throughput），都属于此类。差别点在于，Spark的视野是整个集群，而非单个节点或并行处置器。
数据并行的范式决议了 Spark无法完美支持细粒度、异步更新的操作。图计算就有此类操作，所以此时Spark不如GraphLab（一个大规模图计算框架）；另有一些应用， 需要细粒度的日志更新和数据检查点，它也不如RAMCloud（斯坦福的内存存储和计算研究项目）和Percolator（Google增量计算技术）。 反过来，这也使Spark能够经心耕作它善于的应用领域，试图粗细通吃的Dryad（微软早期的大数据平台）反而不甚成功。
Spark的RDD，接纳了Scala集合类型的编程风格。它同样接纳了函数式语义（functional semantics）：一是闭包，二是RDD的不行修改性。逻辑上，每一个RDD算子都生成新的RDD，没有副作用，所以算子又被称为是确定性的；由于所 有算子都是幂等的，出现错误时只需把算子序列重新执行即可。
Spark的计算抽象是数据流，而且是带有工作集（working set）的数据流。流处置是一种数据流模型，MapReduce也是，区别在于MapReduce需要在多次迭代中维护工作集。工作集的抽象很普遍，如多 迭代、交互式数据挖掘和图计算。为保证容错，MapReduce接纳了稳定存储（如HDFS）来承载工作集，代价是速度慢。HaLoop接纳循环 敏感的调剂器，保证上次迭代的Reduce输出和本次迭代的Map输入数据集在统一台物理机上，这样可以减少网络开销，但无法制止磁盘I/O的瓶颈。
Spark的突破在于，在保证容错的前提下，用内存来承载工作集。内存的存取速度快于磁盘多个数量级，从而可以极大提升性能。关键是实现容错，传统上有两种方法：日 志和检查点。考虑到检查点有数据冗余和网络通讯的开销，Spark接纳日志数据更新。细粒度的日志更新并不便宜，而且前面讲过，Spark也不善于。 Spark记录的是粗粒度的RDD更新，这样开销可以忽略不计。鉴于Spark的函数式语义和幂等特性，通过重放日志更新来容错，也不会有副作用。
来看一段代码：textFile算子从HDFS读取日志文件，返回&file&（RDD）；filter算子筛出带&ERROR&的行，赋给 &errors&（新RDD）；cache算子把它缓存下来以备未来使用；count算子返回&errors&的行数。RDD看起来与Scala集合类型 没有太大差异，但它们的数据和运行模型大相迥异。
图1给出了RDD数据模型，并将上例中用到的四个算子映射到四种算子类型。Spark程序工作在两个空间中：Spark RDD空间和Scala原生数据空间。在原生数据空间里，数据表现为标量（scalar，即Scala基本类型，用橘色小方块表示）、集合类型（蓝色虚线 框）和持久存储（红色圆柱）。
图1 两个空间的切换，四类差别的RDD算子
输入算子（橘色箭头）将Scala集合类型或存储中的数据吸入RDD空间，转为RDD（蓝色实线框_）。输入算子的输入大致有两类：一类针对Scala集合类型，如parallelize；另一类针对存储数据，如上例中的textFile。输入算子的输出就是Spark空间的RDD。
由于函数语义，RDD经过变换（transformation）算子（蓝色箭头）生成新的RDD。变换算子的输入和输出都是RDD。RDD会被划分成许多的分区 （partition）分布到集群的多个节点中，图1用蓝色小方块代表分区。注意，分区是个逻辑概念，变换前后的新旧分区在物理上可能是统一块内存或存 储。这是很主要的优化，以防止函数式不变性导致的内存需求无限扩张。有些RDD是计算的中间结果，其分区并不一定有相应的内存或存储与之对应，如若需要 （如以备未来使用），可以调用缓存算子（例子中的cache算子，灰色箭头表示）将分区物化（materialize）存下来（灰色方块）。
一部分变换算子视RDD的元素为简单元素，分为如下几类：
输入输出一对一（element-wise）的算子，且结果RDD的分区结构不变，主要是map、flatMap（map后展平为一维RDD）；
输入输出一对一，但结果RDD的分区结构发生了变化，如union（两个RDD合为一个）、coalesce（分区减少）；
从输入中选择部分元素的算子，如filter、distinct（去除冗余元素）、subtract（本RDD有、它RDD无的元素留下来）和sample（采样）。
另一部分变换算子针对Key-Value集合，又分为：
对单个RDD做element-wise运算，如mapValues（保持源RDD的分区方式，这与map差别）；
对单个RDD重排，如sort、partitionBy（实现一致性的分区划分，这个对数据当地性优化很主要，后面会讲）；
对单个RDD基于key进行重组和reduce，如groupByKey、reduceByKey；
对两个RDD基于key进行join和重组，如join、cogroup。
后三类操作都涉及重排，称为shuffle类操作。
从RDD到RDD的变换算子序列，一直在RDD空间发生。这里很主要的设计是lazy evaluation：计算并不实际发生，只是不停地记录到。的结构是DAG（有向无环图），其中每一个&极点&是RDD（包括生产该RDD 的算子），从父RDD到子RDD有&边&，表示RDD间的依赖性。Spark给元数据DAG取了个很酷的名字，Lineage（世系）。这个 Lineage也是前面容错设计中所说的日志更新。
Lineage一直增长，直到遇上行动（action）算子（图1中的绿色箭头），这时 就要evaluate了，把刚刚累积的所有算子一次性执行。行动算子的输入是RDD（以及该RDD在Lineage上依赖的所有RDD），输出是执行后生 成的原生数据，可能是Scala标量、集合类型的数据或存储。当一个算子的输出是上述类型时，该算子一定是行动算子，其效果则是从RDD空间返回原生数据 空间。
行动算子有如下几类：生成标量，如count（返回RDD中元素的个数）、reduce、fold/aggregate（见 Scala同名算子文档）；返回几个标量，如take（返回前几个元素）；生成Scala集合类型，如collect（把RDD中的所有元素倒入 Scala集合类型）、lookup（查找对应key的所有值）；写入存储，如与前文textFile对应的saveAsText-File。另有一个检 查点算子checkpoint。当Lineage特别长时（这在图计算中时常发生），犯错时重新执行整个序列要很长时间，可以主动调用 checkpoint把当前数据写入稳定存储，作为检查点。
这里有两个设计要点。首先是lazy evaluation。熟悉编译的都知道，编译器能看到的scope越大，优化的机会就越多。Spark虽然没有编译，但调剂器实际上对DAG做了线性复 杂度的优化。尤其是当Spark上面有多种计算范式混适时，调剂器可以打破差别范式代码的界限进行全局调剂和优化。下面的例子中把Shark的SQL代码 和Spark的机器学习代码混在了一起。各部分代码翻译到底层RDD后，融合成一个大的DAG，这样可以获得更多的全局优化机会。
另一个要点是一旦行动算子形成原生数据，就必须退出RDD空间。由于现在Spark只能够跟踪RDD的计算，原生数据的计算对它来说是不行见的（除非以后 Spark会提供原生数据类型操作的重载、wrapper或implicit conversion）。这部分不行见的代码可能引入前后RDD之间的依赖，如下面的代码：
第三行filter对errors.count()的依赖是由(cnt-1)这个原生数据运算形成的，但调剂器看不到这个运算，那就会出问题了。
由于Spark并不提供控制流，在计算逻辑需要条件分支时，也必须回退到Scala的空间。由于Scala语言对自定义控制流的支持很强，不破除未来Spark也会支持。
Spark 另有两个很实用的功能。一个是广播（broadcast）变量。有些数据，如lookup表，可能会在多个作业间重复用到；这些数据比RDD要小得多，不 宜像RDD那样在节点之间划分。解决之道是提供一个新的语言结构&&广播变量，来修饰此类数据。Spark运行时把广播变量修饰的内容发到各个节点，并保 存下来，未来再用时无需再送。相比Hadoop的distributed cache，广播内容可以跨作业共享。Spark提交者Mosharaf师从P2P的老法师Ion Stoica，接纳了BitTorrent（没错，就是下载电影的那个BT）的简化实现。有兴趣的读者可以参考SIGCOMM'11的论文 Orchestra。另一个功能是Accumulator（源于MapReduce的counter）：允许Spark代码中加入一些全局变量做 bookkeeping，如记录当前的运行指标。
运行和调剂
图2显示了Spark程序的运行场景。它由客户端启动，分两个阶段：第一阶段记录变换算子序列、增量构建DAG图；第二阶段由行动算子触 发，DAGScheduler把DAG图转化为作业及其任务集。Spark支持当地单节点运行（开发调试有用）或集群运行。对于后者，客户端运行于 master节点上，通过Cluster manager把划分好分区的任务集发送到集群的worker/slave节点上执行。
图2 Spark程序运行过程
Spark 传统上与Mesos&焦不离孟&，也可支持Amazon EC2和YARN。底层任务调剂器的基类是个trait，它的差别实现可以混入实际的执行。例如，在Mesos上有两种调剂器实现，一种把每个节点的所有 资源分给Spark，另一种允许Spark作业与其他作业一起调剂、共享集群资源。worker节点上有任务线程（task thread）真正运行DAGScheduler生成的任务；另有块治理器（block manager）负责与master上的block manager master通讯（完美使用了Scala的Actor模式），为任务线程提供数据块。
最有趣的部分是DAGScheduler。下面详解它的工作过程。RDD的数据结构里很主要的一个域是对父RDD的依赖。如图3所示，有两类依赖：窄（Narrow）依赖和宽（Wide）依赖。
图3 窄依赖和宽依赖
窄依赖指父RDD的每一个分区最多被一个子RDD的分区所用，表现为一个父RDD的分区对应于一个子RDD的分区，和两个父RDD的分区对应于一个子RDD 的分区。图3中，map/filter和union属于第一类，对输入进行协同划分（co-partitioned）的join属于第二类。
宽依赖指子RDD的分区依赖于父RDD的所有分区，这是由于shuffle类操作，如图3中的groupByKey和未经协同划分的join。
窄依赖对优化很有利。逻辑上，每个RDD的算子都是一个fork/join（此join非上文的join算子，而是指同步多个并行任务的barrier）： 把计算fork到每个分区，算完后join，然后fork/join下一个RDD的算子。如若直接翻译到物理实现，是很不经济的：一是每一个RDD（纵然 是中间结果）都需要物化到内存或存储中，费时费空间；二是join作为全局的barrier，是很昂贵的，会被最慢的那个节点拖死。如若子RDD的分区到 父RDD的分区是窄依赖，就可以实行经典的fusion优化，把两个fork/join合为一个；如若连续的变换算子序列都是窄依赖，就可以把许多个 fork/join并为一个，不但减少了大量的全局barrier，而且无需物化许多中间结果RDD，这将极大地提升性能。Spark把这个叫做流水线 （pipeline）优化。
变换算子序列一碰上shuffle类操作，宽依赖就发生了，流水线优化终止。在具体实现 中，DAGScheduler从当前算子往前回溯依赖图，一碰着宽依赖，就生成一个stage来容纳已遍历的算子序列。在这个stage里，可以安全地实 施流水线优化。然后，又从那个宽依赖开始继续回溯，生成下一个stage。
要深究两个问题：一，分区怎样划分；二，分区该放到集群内哪个节点。这正好对应于RDD结构中另外两个域：分区划分器（partitioner）和首选位置（preferred locations）。
分区划分对于shuffle类操作很关键，它决议了该操作的父RDD和子RDD之间的依赖类型。上文提到，统一个join算子，如若协同划分的话，两个父 RDD之间、父RDD与子RDD之间能形成一致的分区安置，即统一个key保证被映射到统一个分区，这样就能形成窄依赖。反之，如若没有协同划分，导致宽 依赖。
所谓协同划分，就是指定分区划分器以形成前后一致的分区安置。Pregel和HaLoop把这个作为系统内置的一部分；而Spark 默认提供两种划分器：HashPartitioner和RangePartitioner，允许程序通过partitionBy算子指定。注意，HashPartitioner能够发挥作用，要求key的hashCode是有效的，即同样内容的key形成同样的hashCode。这对 String是建立的，但对数组就不建立（由于数组的hashCode是由它的标识，而非内容，生成）。这种情况下，Spark允许用户自定义 ArrayHashPartitioner。
第二个问题是分区放置的节点，这关乎数据当地性：当地性好，网络通讯就少。有些RDD形成时就 有首选位置，如HadoopRDD分区的首选位置就是HDFS块所在的节点。有些RDD或分区被缓存了，那计算就应该送到缓存分区所在的节点进行。再不 然，就回溯RDD的lineage一直找到具有首选位置属性的父RDD，并据此决议子RDD的放置。
宽/窄依赖的概念不止用在调剂中，对容错也很有用。如若一个节点宕机了，而且运算是窄依赖，那只要把丢失的父RDD分区重算即可，跟其他节点没有依赖。而宽依赖需要父RDD的所有分区都存在， 重算就很昂贵了。所以如若使用checkpoint算子来做检查点，不仅要考虑lineage是否足够长，也要考虑是否有宽依赖，对宽依赖加检查点是最物 有所值的。
由于篇幅所限，本文只能介绍Spark的基本概念和设计思想，内容来自Spark的多篇论文（以NSDI'12 &Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing&为主），也有我和同事研究Spark的心得，以及多年来从事并行/分布式系统研究的感悟。Spark焦点成员/Shark主创者辛湜 对本文作了审阅和修改，特此致谢！
(责任编辑：admin)
转载请注明链接：
------分隔线----------------------------
网页标题：
以下是网友对的评论:你的位置：
> 内存时代 开源Spark赋予Hadoop实时分析能力
发表于( 00:00) 本文标签：
浏览量：333次
&&&&值班编辑QQ：
自5月30日Apache软件基金会宣布发布开源平台Spark 1.0以来，Spark就屡登头条，备受数据专家关注。但是，Spark的企业应用时代真的来了吗？
从近期举办的美国Spark峰会上来看，大家对Spark技术还是充满信心的。Spark通常被认为是实时处理环境，应用于Hadoop、NoSQL数据库、AWS和关系型数据库上，可作为应用程序接口API来使用，程序员通过共同的程序处理数据。Spark的功能包括SQL查询引擎、机器学习算法、图处理引擎和流数据处理引擎。
很多Hadoop供应商都将Spark加入到了自己的Hadoop发行版里，比如Hortonworks、Cloudera、IBM、MapR和Pivotal。Hortonworks的技术咨询师、前创始人兼CTO Eric Baldeschwieler认为，Spark很可能成为大数据通用的技术。
很多支持者认为Spark是Hadoop的必要补充，也承担起一部分文件系统的功能。Spark倡导者认为，Spark的价值在于，没有任何一个平台能像Spark一样将这些各自独立的技术和功能综合集成起来。
另一家Hadoop发行商MapR的CTO，同时也是联合创始人M.C. Srivas则对Spark与Hadoop的结合充满信心。他认为Hadoop常用的MapReduce语言很难入门，对技术人员不够友好，Spark恰能替换MapReduce语言。另外，Spark既然是内存数据处理系统，那么Hadoop的实时分析也就成为了可能。
Srivas说道：“Spark和Hadoop简直是绝配，应用程序接口（API）堪称完美。另外值得一提的就是内存处理。MapReduce必须运行在传统硬盘上，但Spark可以再内存中运行。内存处理赋予了Hadoop实时分析的能力，这一切都要归功于Spark。”
、以往，人们对Spark的关注点主要集中在数据集成和提供简单的唯一界面上。但对于数据科学家来说，数据管理并不是他们的兴趣所在。因此，Spark逐渐增加了更多数据分析的功能。
Spark技术供应商Databricks的软件工程师Patrick Wendell表示，Spark 1.0版本的机器学习库（MLlib）中包含15个预定义的机器学习工具包，1.1版本中有望达到30个。开发人员正在为R语言开发界面，可能会在1.3版本中和大家见面。虽然Spark作为数据管理工具已经名声在外，但Wendell认为，Spark最核心的是这些数据分析代码库的发展。
Wendell说道：“代码库是Spark的未来。它是开源社区的兴趣所在，也是创新的源泉。我们把宝都压在代码库上了。”
十全九美 美中不足
这是否意味着企业应该着手计划自己的Spark部署了？企业还是要三思而后行。虽然Spark有种种优势，比如单独API交互、流数据和批量数据的处理能力、能够同时运行高级分析和简单报表等，但Spark仍然有缺陷。
Srivas认为内存计算面临稳定性问题。Spark已经宣布通过Resilient Distributed Dataset解决这个问题，Resilient Distributed Dataset可以通过并行数据处理提供自动防故障装置。
Baldeschwieler认为，Spark需要增加数据存储的数量，提供更强大的代码分享路径，提高最佳实践分享的速度，开发代码的可移植层。这样程序员就可以一次写完一个任务以后，可以在多个数据存储中执行，最后产生R语言界面。
Baldeschwieler总结道：“虽然Spark目前还有诸多缺陷，但我仍然认为，Apache Spark是大数据时代最让人兴奋的技术。”
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
热点资讯[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&[]&&&&
猎豹傅盛：AlphaGo 2.0没实质突破 AI革命任重道远
浙大“赤兔”机器人:能小跑、奔跑、爬楼梯
强大技术做支撑 谷歌输入法背后的机器智能
从肉体变机器，我们这代人或能见证人类进化加速
程序员陷传销组织写代码求救：同事秒懂
智能织物摊在桌上直接能当巨型触控板
在各大投行、对冲基金押注机器将在金融业战胜人类之际，Doubleline基金创始人、拥有新一代债王之称的Jeffrey Gundlach却为人类投上了宝贵的一票。 周四，Gundlach在固定收益分析师协会(Fixed Income Analysts Society)的名人堂前接受媒体采访时坦言：我根本
据新加坡《联合早报》6月22日报道，随着人工智能(AI)的普及，有人担心AI会替代人类工作，失业者将会增多。但人力资源服务巨头Adecco公司的调查显示，日本民间企业88.7%的管理层对AI效果表示期待，认为其有利于缩短劳动时间和提高业务效率等优势。 资料图 该
我准备把手上的无人机卖了，但网上挂4到5折还是没人买在北京正式公布机场净空区后，专业无人机玩家王磊(化名)就很少有机会使用他的无人机了，他选择了变卖身家，没办法，没法玩了。 王磊得到的消息是，目前北京市公安局禁飞协议包括了整个北京行政区域。南都
LG 刚刚发布了全球首款77英寸的柔性、透明 OLED 显示屏，而且高度比阿汤哥（Tom Cruise）还略胜一筹。当然，这是在不穿鞋的情况下。Google 搜索结果表明，汤姆克鲁斯的净身高为5英尺7英寸，约合170公分。相比之下，LG 这款77英寸16:9显示屏的高度为 170.5 CM
6月20日，印度政府承认比特币合法地位，并决定成立特别工作组制定比特币监管规范。比特币本周以来上涨33%，重回2700美元。有分析指出，印度比特币交易比重正在迅速上涨。印度三大交易所包揽了全球约11%的以美元计价的比特币交易，且该地区的交易量一直在上升
2032年，我刚毕业，就失业了。近日，一篇题为《你在教育链上鄙视别人家孩子，它站在食物链顶端鄙视你》的文章在微信朋友圈疯传，文章以科幻的笔法虚构了一位妈妈千辛万苦、竭尽全力培养我，上各种兴趣班，从高中起就出国留学，读到美国排名前50的大学然而毕
当你收到一条短信，上面说，京东智能机器人正在把货物运过来，然后你下楼一看，木有见到快递小哥，只看到一台无人机。你会不会有一点小惊喜？ 今天早上，有几个人大的童鞋收到了京东的无人车送的快递，有的表示很神奇，有的表示很惊喜。 36氪到现场围观了一【图片】H4V-SPARK 小轴距H4轴 可调矢量推力 多旋翼的新时代来临【fpv吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：4,509贴子：
H4V-SPARK 小轴距H4轴 可调矢量推力 多旋翼的新时代来临收藏
前段时间看了国外开发的可变电机倾角四轴，受到启发，我自己也搞了一套，从设计到打样再修改，来来回回，花了差不多2个月时间。经过几次打样测试，现在设计已经收尾，各种铝合金件加起来空机重量为220g，我自己测试的时候，不带电池的装机重量为452g，轴距为300mm时，可以支持的最大桨尺寸为6寸。也可以更换更长的机臂，最大可以支持7寸桨。采用KV电机，12A电调，为了适应更多规格的电池，采用了大面积的电池安装板，内部空间还是比较充足。可变电机倾斜角度的设计，可以让机架既能适应普通四轴的飞行模式，也能使四轴以类似V22鱼鹰的前倾螺旋桨状态飞行，当改变角度时，机身不同于一般四轴那样靠改变整体的俯仰角度来获取前进推力，而是直接利用改变电机的角度从而改变推力方向，在四轴前进的过程中，始终保持最小的风阻面积。另一特点是由于不改变机身的俯仰倾角度，对于固定安装的摄像机，就不需要加装上仰角，因为当电机前倾时，机架的状态都是水平的。在操作手感上和普通结构的四轴没有太大区别，唯一不同的地方就是以前的俯仰控制，现在变成了电机角度控制。废话不多说，开始上图吧试飞机架配置及参数：轴距：300mm整机重量（不含电池）：452g电机：KV电调：银燕12A桨：6045电池：2200MAH遥控器：福斯I6接下来就是视频了，用手机拍的，但是传到优酷上的时候清晰度打了折扣：手机拍摄正常播放速度视频（俯仰通道摇杆控制）：视频来自：再发几个高清大图H4V-SPARK
政府办学,免学费入读大专+高级工双证教育,选择医药行业,成就辉煌未来.
慢动作视频视频来自：
飞控是自己写的？
屌屌屌，开卖了吗
这样想法很很好，把机身设计成单轴云台，fpv画面会稳定很多，不过价格要上去了点，舵机的价格快赶上两个电机了
登录百度帐号推荐应用深圳市广道高新技术股份有限公司. 保留所有权利。
深圳市广道高新技术股份有限公司是基于信息安全设备的互联网运营商，主要从事网络内容与行为审计产品、容灾备份系统、情报分析系统等信息安全设备的研发、生产、销售，并以所售设备为站点进行互联网运营。
友情链接：