2014年，Spark开源生态系统得到了大幅增长，已成为大数据领域最人气的开源项目之一，活跃在Hortonworks、IBM、Cloudera、MapR和Pivotal等众多知名大数据公司，更拥有Spark SQL、Spark Streaming、MLlib、GraphX等多个相关项目。同时值得一提的是，Spark贡献者中有一半左右的中国人。
短短四年时间，Spark不仅发展为Apache基金会的顶级开源项目，更通过其高性能内存计算及其丰富的生态快速赢得几乎所有大数据处理用户。日，一场基于Spark的高性能应用实践盛宴由Databricks软件工程师连城、百度高级工程师甄鹏、百度架构师孙垚光、百度美国研发中心高级架构师刘少山四位专家联手打造。
Databricks软件工程师连城&&Spark SQL 1.2的提升和新特性
谈及Spark SQL 1.2的提升和新特性，连城主要总结了4个方面&&External data source API(外部数据源API)、列式内存存储加强(Enhanced in-memory columnar storage)、Parquet支持加强(Enhanced Parquet support)和Hive支持加强(Enhanced Hive support)。
External data source API
连城表示，因为在处理很多外部数据源中出现的扩展问题，Spark在1.2版本发布了External data source API。通过External data source API，Spark将不同的外部数据源抽象成一个关系表格，从而实现更贴近无缝的操作。
External data source API在支持了多种如JSON、Avro、CSV等简单格式的同时，还实现了Parquet、ORC等的智能支持;同时，通过这个API，开发者还可以使用JDBC将HBase这样的外部系统对接到Spark中。
连城表示，在1.2版本之前，开发者其实已经实现了各种各样外部数据源的支持，因此，对比更原生的支持一些外部数据源，External data source API的意义更在于针对相应数据源进行的特殊优化，主要包括Column pruning(列剪枝)和Pushing predicates to datasources(将predicates贴近数据源)两个方面：
Column pruning。主要包括纵横的两种剪枝。在列剪枝中，Column pruning可以完全忽视无需处理的字段，从而显著地减少IO。同时，在某些条件查询中，基于Parquet、ORC等智能格式写入时记录的统计信息(比如最大值、最小值等)，扫描可以跳过大段的数据，从而省略了大量的磁盘扫描负载。
Pushing predicates to datasources。在更复杂的SQL查询中，让过滤条件维度尽可能的接近数据源，从而减少磁盘和网络IO，最终提高整体端到端的性能。
使用External data source API之前
使用External data source API之后
搭载了如Parquet和ORC这样的智能格式
连城表示，在Spark 1.2版本中，External data source API并没有实现预期中的功能，在Roadmap中，First class分片支持(First class partitioning support with partition pruning)、Data sink(insertion)API、将Hive作为外部数据源等。
Enhanced in-memory columnar storage
连城表示，不管Shark，还是Spark，内存缓存表的支持都是非常重要的一个特性。他表示，虽然在1.1和之前版本中的列式内存表的性能已然不错，但是还会出现一些问题：第一，大数据量下缓存超大体积表时(虽然不推荐，但不缺现实用例)，会出现OOM等问题;第二，在列式存储中，像Parquet、ORC这种收集统计信息然后通过这些信息做partition skipping等操作在之前版本中并没有完全实现。这些问题在1.2版本中都得到了解决，本节，连城主要介绍了语义统一、缓存实体化、基于缓存共享的查询计划、Cache大表时的OOM问题、表格统计(Table statistics)等方面。
缓存实体化。SQLContext.cacheTable(&tbl&)默认使用eager模式，缓存实体化将自动进行，不会再等到表被使用或触发时，避免手动做&SELECT COUNT(*) FROM&。同时，新增了&CACHE [LAZY] TABLE tbl [AS SELECT &]&这样的DML。
语义统一。早期时候，SchemaRDD.cache()和SQLContext.cacheTable(&tbl&)这两个语义是不同的。其中，SQLContext.cacheTable会去建立一些列式存储格式相关优化，而SchemaRDD.cache()却以一行一个对象的模式进行。在1.2版本中，这两个操作已被统一，同时各种cache操作都将得到一个统一的内存表。
基于缓存共享的查询计划。两个得到相同结果的cache语句将共享同一份缓存数据。
避免Cache大表时的OOM问题。优化内存表的建立和访问，减少开销，进一步提升性能;在缓存大表时，引入batched column buffer builder，将每一列切成多个batch，从而避免了OOM。
表格统计。Table statistics，类似Parquet、ORC使用的技术，在1.2版本中主要实现了Predicate pushdown(实现更快的表格扫描)和Auto broadcast join(实现更快的表格join)。
最后，连城还详细介绍了一些关于加强Parquet和Hive支持的实现，以及Spark未来的一些工作。
百度基础架构部高级工程师甄鹏&&Spark在百度开放云BMR中的实战分享
百度分布式计算团队从2011年开始持续关注Spark，并于2014年将Spark正式引入百度分布式计算生态系统中，在国内率先面向开发者及企业用户推出了支持Spark并兼容开源接口的大数据处理产品BMR(Baidu MapReduce)。在甄鹏的分享中，我们主要了解了百度Spark 应用现状、百度开放云BMR和Spark On BMR三个方面的内容。
Spark在百度
甄鹏表示，当前百度的Spark集群由上千台物理主机(数万Cores，上百TBMemory)组成，日提交App在数百，已应用于凤巢、大搜索、直达号、百度大数据等业务。之以选择Spark，甄鹏总结了三个原因：快速高效、API 友好易用和组件丰富。
快速高效。首先，Spark使用了线程池模式，任务调度效率很高;其次，Spark可以最大限度地利用内存，多轮迭代任务执行效率高。
API友好易用。这主要基于两个方面：第一，Spark支持多门编程语言，可以满足不同语言背景的人使用;第二，Spark的表达能力非常丰富，并且封装了大量常用操作。
组件丰富。Spark生态圈当下已比较完善，在官方组件涵盖SQL、图计算、机器学习和实时计算的同时，还有着很多第三方开发的优秀组件，足以应对日常的数据处理需求。
百度开放云BMR
在BMR介绍中，甄鹏表示，虽然BMR被称为Baidu MapReduce，但是这个名称已经不能完全表示出这个平台：BMR是百度开放云的数据分析服务产品，基于百度多年大数据处理分析经验，面向企业和开发者提供按需部署的Hadoop&Spark集群计算服务，让客户具备海量数据分析和挖掘能力，从而提升业务竞争力。
如图所示，BMR基于BCC(百度云服务器)，建立在HDFS和BOS(百度对象存储)分布式存储之上，其处理引擎包含了MapReduce和Spark，同时还使用了HBase数据库。在此之上，系统集成了Pig、Hive、SQL、Streaming、GraphX、MLLib等专有服务。在系统的最上层，BMR提供了一个基于Web的控制台，以及一个API形式的SDK。
在图片的最右边，Scheduler在BMR中起到了管理作用，使用它开发者可以编写比较复杂的作业流。
Spark On BMR
类似于通常的云服务，BMR中的Spark同样随用随起，集群空闲即销毁，帮助用户节省预算。此外，集群创建可以在3到5分钟内完成，包含了完整的Spark+HDFS+YARN堆栈。同时，BMR也提供Long Running模式，并有多种套餐可选。
完善的报表服务，全方位监控
在安全上，用户拥有虚拟的独立网络，在同一用户全部集群可互联的同时，BMR用户间网络被完全隔离。同时，BMR还支持动态扩容，节点规模可弹性伸缩。除此之外，在实现Spark全组件支持的同时，BMR可无缝对接百度的对象存储BOS服务，借力百度多年的存储研发经验，保证数据存储的高可靠性。
百度基础架构部架构师孙垚光&&百度高性能通用Shuffle服务
在2014 Sort Benchmark国际大赛上，百度成功夺冠，其幕后英雄无疑卓越的Shuffle机制，在孙垚光的分享中，我们对Shuffle的发展、细节和未来有了一次深度的接触。
Shuffle简介
孙垚光表示，简单来说，Shuffle就是按照一定的分组和规则Map一个数据，然后传入Reduce端。不管对于MapReduce还是Spark，Shuffle都是一个非常重要的阶段。然而，虽然Shuffle解决的问题相同，但是在Spark和MapReduce中，Shuffle流程(具体时间和细节)仍然存在一定的差别：
Baidu Shuffle发展历程
通过孙垚光了解到，Shuffle在百度的发展主要包括两个阶段：跟随社区和独立发展。从2008年百度的MapReduce/Hadoop起步开始，百度就开始跟随社区，使用社区版本，期间的主要工作包含Bug修复和性能优化两个方面(增加内存池、减少JVMGC，传输Server由Jetty换Netty，及批量传输、聚合数据等方面)。
分离了shuffle和Map/Reduce
在2012年开始，Baidu Shuffle开启独立发展阶段，主要源于下一代离线计算系统的开发，Shuffle被抽离为独立的ShuffleService服务，从而提高了集群资源的利用率。
截止此时，不管是社区版本(MapReduce/Spark)，还是百度研发的ShuffleService，它们都是基于磁盘的PULL模式。基于磁盘，所有Map的数据都会放到磁盘，虽然Spark号称内存计算，但是涉及到Shuffle时还是会写磁盘。基于PULL，所有数据在放到Map端的磁盘之后，Reduce在使用时还需要主动的拉出来，因此会受到两个问题影响：首先，业务数据存储在Map端的服务器上，机器宕机时会不可避免丢失数据，这一点在大规模分布式集群中非常致命;其次，更重要的是，Shuffle阶段会产生大量的磁盘寻道(随机读)和数据重算(中间数据存在本地磁盘)，举个例子，某任务有1百万个Map，1万个Reduce，如果一次磁盘寻道的时间是10毫秒，那么集群总共的磁盘寻道时间= 000 &0.01 = 1亿秒。
New Shuffle
基于这些问题，百度设计了基于内存的PUSH模式。新模式下，Map输出的数据将不落磁盘，并在内存中及时地Push给远端的Shuffle模块，从而将获得以下提升：
New Shuffle的优势
New Shuffle架构
如图所示，蓝色部分为New Shuffle部分，主要包含两个部分：数据写入和读取的API，Map端会使用这个接口来读取数据，Reduce会使用这个接口来读取数据;其次，最终重要的是，服务器端使用了典型的主从架构，用多个shuffle工作者节点来shuffle数据。同时，在系统设计中，Master非常有利于横向扩展，让shuffle不会成为整个分布式系统的瓶颈。
让New Shuffle模块专注于shuffle，不依赖于外部计算模块，从而计算模块可以专注于计算，同时还避免了磁盘IO。然而New Shuffle带来的问题也随之暴漏，其中影响比较重要的两个就是：慢节点和数据重复。
慢节点。以shuffle写入过程中出现慢节点为例，通常包含两个情况。首先，Shuffle自身慢节点，对比社区版本中只会影响到一个task，New Shuffle中常常会影响到一片集群。在这里，百度为每个Shuffle节点都配置了一个从节点，当Map检测到一个慢节点时，系统会自动切换到从节点。其次，DFS出现慢节点，这个情况下，Shuffle的从节点只能起到缓解作用。这种情况下，首先DFS系统会自动检测出慢节点，并进行替换。比如，传统的HDFS会以pipeline的形式进行写入，而DFS则转换为分发写。
在此之外，New Shuffle还需要解决更多问题，比如资源共享和隔离等。同时，基于New Shuffle的机制，New Shuffle还面临一些其他挑战，比如Reduce全启动、数据过于分散、对DFS压力过大、连接数等等。
数据重复。如上图所示，这些问题主要因为New Shuffle对上层组件缺少感知，这个问题的解决主要使用task id和block id进行去重。
New Shuffle展望
孙垚光表示，New Shuffle使用了通用的Writer和Reader接口，当下已经支持百度MR和DCE(DAG、C++)，同时即将对开源Spark提供支持。在未来，New Shuffle无疑将成为更通用的组件，支持更多的计算模型。
百度美国硅谷研发中心高级架构师刘少山&&Fast big data analytics with Spark on Tachyon
Tachyon是一个分布式的内存文件系统，可以在集群里以访问内存的速度来访问存在Tachyon里的文件。Tachyon是架构在分布式文件存储和上层各种计算框架之间的中间件，主要负责将那些不需要落到DFS里的文件，落到分布式内存文件系统中，从而达到共享内存，以提高效率。1月10日下午的最后一场分享中，刘少山带来了一场Tachyon的深入解析。
Tachyon和Spark
刘少山表示，在Spark使用过程中，用户经常困扰于3个问题：首先，两个Spark 实例通过存储系统来共享数据，这个过程中对磁盘的操作会显著降低性能;其次，因为Spark崩溃所造成的数据丢失;最后，垃圾回收机制，如果两个Spark实例需求同样的数据，那么这个数据会被缓存两次，从而造成很大的内存压力，更降低性能。
使用Tachyon，存储可以从Spark中分离处理，让其更专注于计算，从而避免了上述的3个问题。
Tachyon架构
刘少山从Spark的角度分享了Tachyon的部署。在与Spark搭配使用时，系统会建立一个Tachyon的job，通过Tachyon Client来访问同一个机器上的Tachyon Worker，也就是机器上的内存。而Tachyon Client则会与Tachyon Master交互，来清楚每个分节点所包含的数据。由此可见，在整个Tachyon 系统中，Master、Client和Worker为最重要的三个部分。
Tachyon Master。Master主要部件是Inode和Master Worker Info：Inode会负责系统的监视，Master Worker Info则存储了所有Worker的信息。
Tachyon Worker。Worker主要负责存储，其中Worker Storage是最主要的数据结构，包含Local data folder和Under File System两个部分。其中Local data folder表示存在本地的Tachyon文件，Under File System则负责从HDFS中读取Worker中未发现的数据。
Tachyon Client。Client为上层用户提供了一个透明的机制，其TachyonFS接口负责数据请求。每个Client中有多个Tachyon File，其中Block In Stream负责文件读取(Local Block In Stream负责本地机器读取，Remote Block In Stream则负责读取远程机器);Block Out Stream主要负责将文件写到本地机器上。在Client上，Master Client会与Master交互，Worker Client则与Client交互。
Tachyon在百度
为什么要使用Tachyon，刘少山指出，在百度，计算集群和存储集群往往不在同一个地理位置的数据中心，在大数据分析时，远程数据读取将带来非常高的延时，特别是ad-hoc查询。因此，将Tachyon作为一个传输缓存层，百度通常会将之部署在计算集群上。首次查询时，数据会从远程存储取出，而在以后的查询中，数据就会从本地的Tacnyon上读取，从而大幅的改善了延时。
在百度，Tachyon的部署还处于初始阶段，大约部署了50台机器，主要服务于ad-hoc查询。
实践中遭遇的挑战
通过刘少山了解到，Tachyon的使用过程并不是一帆风顺，比如：因为Tachyon需求对Block完全读取，从而可能造成Blocks并未被缓存;有时候，虽然scheduler已经确认了数据存在本地，Spark workers仍然从远程blocks读取，而缓存命中率也只有可怜的33%(如果你需要的是2号block，Tachyon会分别从1、2、3号block读取，从而将block读取了3份)。因此，刘少山表示，如果要使用好Spark与Tachyon，一定要对用例和Tachyon进行充分的了解。
分享最后，刘少山还介绍了Hierarchical Storage Feature特性以及百度未来的工作，其中包括缓存替换策略等。
24小时报不停
最新美国最佳雇主排行榜出炉，谷歌第七次折桂
Oculus：不支持苹果是因为Mac显卡不行
传腾讯将10亿美元入股搜狐视频，类似入股搜狗
微博2015年财报利好，周四股价大涨9%
80万中国人欲赴日赏樱，日本旅游局发布专属赏樱路线
亚马逊悄然移除Fire OS加密功能：或与FBI有关
Apple Pay中国上线前两天绑卡达300万张
雅虎考虑出售最多30亿美元非核心资产
世纪互联私有化细节：管理层欲追投1.22亿美元
格力电器董事长董明珠：做不做手机要问雷军
IDC：今年全球智能手机出货量增速降至5.7%
凯基证券郭明錤：苹果今年将推3款iPhone 7+1款4英寸“iPhone SE”
机票销售争端再起，国航全面整顿去哪儿票代
美国芯片制造商博通第一财季业绩超预期，宣布将裁员1900人
惠普企业第一财季净利润2.67亿美元，同比降51%
大量证据表明苹果本月将推出新版iPhone
雷军两会提案：聚焦农村互联网和鼓励创业
杨元庆两会建议利用互联网精准扶贫
苹果获柔性屏专利，或应用到未来iPhone中
科技圈好雇主：Facebook第一，谷歌第三，苹果第八，特斯拉第十一
乐视体验店LePar宣布独立，将成立O2O实体公司
它还是来了：Uber今日在印度推出摩的打车服务
雷军忽然打脸：小米不排斥IPO
在法国，父母网上“晒娃” 可能面临1年监禁
IBM起诉团购网站Groupon专利侵权
比苹果腾讯都牛，谷歌推出新支付应用，无需掏出手机即能完成
五角大楼邀数千编外黑客帮忙找漏洞，不含敏感网站
日本诞生首家独角兽公司，是一家仅推出3年的二手商品平台应用Mercari
传阿里公关干涉被投资媒体报道，声讨记者内容：我们投资了，你们怎么还能这么写
工行回应融e购涉售假事件：如属实将严罚商户
乐视云完成A轮10亿元融资，重庆战略基金领投
LinkedIn CEO将今年的1400万美元股权奖励让给公司员工
京东副总裁江川离职信流出，确认加盟河狸家
全球跨境设计师电商平台细刻获联想乐基金1500万元投资
IBM起诉团购网站Groupon专利侵权
IBM将出售1.5亿美元联想股份
360等云盘涉黄百万部遭封杀
阿里巴巴与亚马逊将在印度展开殊死搏斗
慧聪网2015年归属股东净利下滑60%，布局互联网金融和B2B
京东与板凳达成合作，潜入B2B在线票务市场
车企前两月在华召回汽车174万辆，日系车占据8成
全球“超富”人数自2008年金融危机来首次下降，股市亏损是主因
前程无忧Q4净利2190万美元，同比增长74.4%
创业板公司平均净利增长27.8%，增速创近5年新高
《琅琊榜》网游开发商朋万科技新三板挂牌上市
摩根士丹利维持百度股票评级，下调目标股价至226美元60岁的工人收养了一个双性弃婴，三年多来一直凑钱。
水北商会成立来，已累计捐资7000多万元，助家乡建设。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　正如市面上存在众多可用的流处理引擎，人们经常询问我们Spark Streaming有何独特的优势？那么首先要说的就是Apache Spark在批处理以及流处理上提供了原生支持。这与别的系统不同之处在于其他系统的处理引擎要么只专注于流处理，要么只负责批处理且仅提供需要外部实现的流处理API接口而已。Spark 凭借其执行引擎以及统一的编程模型可实现批处理与流处理，这就是与传统流处理系统相比Spark Streaming所具备独一无二的优势。尤其特别体现在以下四个重要部分：
　　能在故障报错与straggler的情况下迅速恢复状态；更好的负载均衡与资源使用；静态数据集与流数据的整合和可交互查询；内置丰富高级算法处理库（SQL、机器学习、图处理）。
　　本文，我们将描述Spark Streaming的架构并解释如何去提供上述优势。紧接着我们还会讨论一些目前正在进行令大家感兴趣的相关后续工作。
　　流处理架构-过去与现在当前分布式流处理管道执行方式如下所述：
　　接收来自数据源的流数据（比如时日志、系统遥测数据、物联网设备数据等等），处理成为数据摄取系统，比如Apache Kafka、Amazon Kinesis等等。在集群上并行处理数据。这也是设计流处理引擎的关键所在，我们将在下文中做出更细节性的讨论。输出结果存放至下游系统（例如HBase、Cassandra, Kafka等等）。
　　为了处理这些数据，大部分传统的流处理系统被设计为连续算子 模型，其工作方式如下：
　　有一系列的工作节点，每组节点运行一至多个连续算子；对于流数据，每个连续算子一次处理一条记录，并且将记录传输给管道中别的算子；源算子从摄入系统接收数据，接着沉算子输出到下游系统。
　　图1：传统流处理系统架构
　　连续算子是一种较为简单、自然的模型。然而,随着如今大数据时代下，数据规模的不断扩大以及越来越复杂的实时分析，这个传统的架构也面临着严峻的挑战。因此，我们设计Spark Streaming就是为了解决如下几点需求：
　　故障迅速恢复C数据越庞大，出现节点故障与节点运行变慢（例如straggler）情况的概率也越来越高。因此，系统要是能够实时给出结果,就必须能够自动修复故障。可惜在传统流处理系统中，在这些工作节点静态分配的连续算子要迅速完成这项工作仍然是个挑战；负载均衡C在连续算子系统中工作节点间不平衡分配加载会造成部分节点性能的bottleneck（运行瓶颈）。这些问题更常见于大规模数据与动态变化的工作量面前。为了解决这个问题，那么要求系统必须能够根据工作量动态调整节点间的资源分配；统一的流处理与批处理以及交互工作C在许多用例中，与流数据的交互是很有必要的（毕竟所有流系统都将这置于内存中）或者与静态数据集结合（例如pre-computed model）。这些都很难在连续算子系统中实现，当系统动态地添加新算子时，并没有为其设计临时查询功能，这样大大的削弱了用户与系统的交互能力。因此我们需要一个引擎能够集成批处理、流处理与交互查询；高级分析（例如机器学习、SQL查询等等）C一些更复杂的工作需要不断学习和更新数据模型，或者利用SQL查询流数据中最新的特征信息。因此，这些分析任务中需要有一个共同的集成抽象组件，让开发人员更容易地去完成他们的工作。
　　为了解决这些要求，Spark Streaming使用了一个新的结构，我们称之为discretized streams（离散化的流数据处理），它可以直接使用Spark引擎中丰富的库并且拥有优秀的故障容错机制。
　　Spark Streaming架构：离散化的流数据处理对于传统流处理中一次处理一条记录的方式而言，Spark Streaming取而代之的是将流数据离散化处理，使之能够进行秒级以下的微型批处理。同时Spark Streaming的Receiver并行接收数据，将数据缓存至Spark工作节点的内存中。经过延迟优化后Spark引擎对短任务（几十毫秒）能够进行批处理并且可将结果输出至别的系统中。值得注意的是与传统连续算子模型不同，其中传统模型是静态分配给一个节点进行计算，而Spark task可基于数据的来源以及可用资源情况动态分配给工作节点。这能够更好的完成我们在接下来所要描述的两个特性：负载均衡与快速故障恢复。
　　除此之外，每批数据我们都称之为弹性分布式数据集（RDD），这是Spark中容错数据集的一个基本抽象。正是如此，这些流数据才能处理Spark的任意指令与库。
　　图2：Spark Streaming架构
　　离散化流数据处理的优点我们来看看这个架构如何通过Spark Streaming来完成我们之前设立的目标。
　　动态负载均衡
　　Spark系统将数据划分为小批量，允许对资源进行细粒度分配。例如，考虑当输入数据流需要由一个键值来分区处理。在这种简单的情况下，别的系统里的传统静态分配task给节点方式中，如果其中一个分区计算比别的更密集，那么该节点处理将会遇到性能瓶颈，同时将会减缓管道处理。而在Spark Streaming中，作业任务将会动态地平衡分配给各个节点，一些节点会处理数量较少且耗时较长task，别的节点将会处理数量更多且耗时更短的task。
　　图3：动态负载均衡
　　快速故障恢复机制
　　在节点故障的案例中，传统系统会在别的节点上重启失败的连续算子。为了重新计算丢失的信息，还不得不重新运行一遍先前数据流处理过程。值得注意的是，此过程只有一个节点在处理重新计算，而且管道无法继续进行工作，除非新的节点信息已经恢复到故障前的状态。在Spark中，计算将被拆分成多个小的task，保证能在任何地方运行而又不影响合并后结果正确性。因此，失败的task可以同时重新在集群节点上并行处理，从而均匀的分布在所有重新计算情况下的众多节点中，这样相比于传统方法能够更快地从故障中恢复过来。
　　图4：快速故障恢复原理
　　批处理、流处理与交互式分析的一体化
　　离散数据流（DStream）作为Spark Streaming中一个关键的程序抽象。在其内部，DStream是通过一组时间序列上连续的RDD来表示的，每一个RDD都包含了特定时间间隔内的数据流。这种常用表示允许批处理和流处理进行无缝交互操作。从而用户可以对每一批流数据进行Spark相关操作。例如：利用DStream与预先创建的数据集相连接。
　　// Create data set from Hadoop file val dataset = sparkContext.hadoopFile(“file”) // Join each batch in stream with the dataset kafkaDStream.transform { batchRDD =& batchRDD.join(dataset).filter(...) }
　　正如流数据中每一批都储存于Spark节点中的内存里，我们便能根据所需进行交互查询。例如，你可以通过Spark SQL JDBC server，查询所有stream的状态，该内容我们在下节中也会展示。正因为Spark对这些工作进行一个共有的抽象，所以这种将批处理、流处理与交互式工作结合在一起的情况，在Spark中是非常容易实现的，而在那些没有共同抽象的系统中却很难。
　　高级分析-机器学习、SQL查询
　　因为Spark具有互操作性，因此延伸出丰富的库供用户使用，例如：MLlib（机器学习）、SQL、DataFrames和Graphx。下面我们来一起探索一些用例：
　　Streaming + SQL and DataFrames
　　DStream内部维护的RDD序列可以被转换成DataFrame（Spark SQL的编程接口），进而可通过SQL语句进行查询操作。例如：使用Spark SQL的JDBC server,外部程序可以通过SQL查询stream的状态。
　　val hiveContext = new HiveContext(sparkContext) ... wordCountsDStream.foreachRDD { rdd =& // Convert RDD to DataFrame and register it as a SQL table val wordCountsDataFrame = rdd.toDF(&word”, “count&) wordCountsDataFrame.registerTempTable(&word_counts&) } ... // Start the JDBC server HiveThriftServer2.startWithContext(hiveContext)
　　你可以通过JDBC server使用Spark附带的beelineclient或者tableau工具交互查询持续更新的“word_counts”表。
　　1: jdbc:hive2://localhost:10000& +--------------+--------------+ | tableName | isTemporary | +--------------+--------------+ | word_counts | true | +--------------+--------------+ 1 row selected (0.102 seconds) 1: jdbc:hive2://localhost:10000& select * from word_ +-----------+--------+ | word | count | +-----------+--------+ | 2015 | 264 | | PDT | 264 | | 21:45:41 | 27 |
　　Streaming + MLlib
　　机器学习模型可通过MLlib进行离线生成，能应用于流数据中。例如，在下面的代码用静态数据形成一个KMeans聚类模型，然后使用模型对Kafka数据流进行分类。
　　// Learn model offline val model = KMeans.train(dataset, ...) // Apply model online on stream val kafkaStream = KafkaUtils.createDStream(...) kafkaStream.map { event =& model.predict(featurize(event)) }
　　我们在Spark Summit 2014 Databricks demo上证明了这种”离线学习在线预测”的方法。自那以后，我们也在MLlib中增加关于流的机器学习算法，这样就能持续形成一些标记数据流。其他的Spark 扩展库也同样能在Spark Streaming上被轻易调用。
　　性能分析鉴于Spark Streaming独一无二的设计，那么它运行的速度有多快呢？实际上Spark Streaming的能力体现在批量处理数据以及利用Spark 引擎生成与别的流系统比相当或者更高的吞吐量。在延迟方面，Spark Streaming可以实现低至几百毫秒的延迟。开发者有时会问微批处理是否有较多的延迟。在实践中，批处理延迟只是端到端管道延迟的一小部分。无论是在Spark系统还是连续算子系统下，许多应用程序计算结果是根据一个滑动的窗口里所获得的数据流计算得到的，这个窗口的更新也是定时的（例如窗口间隔设为20秒，滑动间隔设为2秒，表示每隔2秒计算更新一次窗口前20秒的信息）。需要管道收集来自多个来源的记录并且等待一个短的时间内处理延迟或无序数据。最后，自动触发算法往往等待一段时间才触发。因此，相比于端到端的延迟，批处理延迟很少会增加很多的费用，因为批处理延迟往往很小。此外，从DStream吞吐量增益上来看一般意味着我们可以用更少的机器去处理同样的工作量，这便是性能上所带来的提升。
　　Spark Streaming的未来方向Spark Streaming是Spark中最常用的组件之一，将会有越来越多的有流处理需求的用户踏上Spark的使用之路。一些我们团队正在研究的最高优先级的项目将会在下文中被讨论到。你可以在Spark接来下几个版本中期待这些特性的出现：
　　BackpressureC在流作业中可能经常遇到爆发的数据量（例如:在奥斯卡颁奖期间激增的微博量），因此系统必须能够完美的处理好它们。在Spark 1.5版本中，Spark将会增加更好的Backpressure机制，让Spark Streming能动态地控制这种爆发的 摄入率。此功能是我们Databricks与Typesafe的工程师们共同完成的；Dynamic scaling C单单控制固定的数据读取ingestion rate不足以去处理更长时间范围的数据变化。（例如:相比于夜间，白天存在持续较高的发微博率）。基于这个处理要求 ，这些变化可以被动态地缩放集群上资源。在Spark Streaming架构中，这是很容易去实现的，因为计算已经被分成一系列小的task，如果集群模式（例如YARN, Mesos, Amazon EC2等等 ）需要更多的节点去进行计算，那么它们能动态地分配到一个更大的集群环境。为此我们将增加支持自动化的Dynamic scaling；事件时间和无序数据C实践中，用户有时会记录下无序数据信息，Spark Streaming允许用户通过自定义时间提取函数来支持事件时间排序；UI界面增强C最后，我们希望使开发人员能够轻松调试他们的Streaming applications。基于这个目的，在Spark 1.4中，我们增加新的可视化Spark Streaming UI，让开发人员能密切监视他们应用程序的性能。在Spark 1.5中，我们通过展示更多的输入信息（例如Kafka消息偏移量）进一步提高了这项功能。
　　要想了解更多Spark Streaming执行原理和容错模型等相关内容，敬请阅读 official programming guide，或者Spark Streaming research paper。
　　原文链接：Diving into Spark Streaming’s Execution Model（ 译者/丘志鹏 审校/Wendy 责编/仲浩）
　　译者简介：邱志鹏，关注大数据、机器学习。
　　本文为CSDN编译整理，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
CSDN是中国软件开发联盟（Chinese softwar...
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：}