连城目前就职于DataBricks，曾工作于网易杭州研究院和百度，也是《Erlang/OTP并发编程实战》及《Erlang并发编程（第一部分）》的译者。近日，InfoQ中文站编辑跟连城进行了邮件沟通，连城在邮件中分享了自己对Spark现状的解读。 InfoQ：有专家侧重Storm，您则是侧重Spark，请简单谈谈这两者的区别和联系？ 连城：Storm是一个流处理系统，而Spark的适用范围则宽泛得多，直接涵盖批处理、流处理、SQL关系查询、图计算、即席查询，以及以机器学习为代表的迭代型计算等多种范式。所以我想这个问题的初衷可能是想问Storm和Spark的流处理组件Spark Streaming之间的区别和联系？ Spark Streaming相对于传统流处理系统的主要优势在于吞吐和容错。在吞吐方面，包括Storm在内的大部分分布式流处理框架都以单条记录为粒度来进行处理和容错，单条记录的处理代价较高，而Spark Streaming的基本思想是将数据流切成等时间间隔的小批量任务，吞吐量显著高于Storm。在容错方面，Storm等系统由于以单条记录为粒度进行容错，机制本身更加复杂，错误恢复时间较长，且难以并行恢复；Spark Streaming借助RDD形成的lineage DAG可以在无须replication的情况下通过并行恢复有效提升故障恢复速度，且可以较好地处理straggler。 除此之外，由于Spark整体建立在RDD这一统一的数据共享抽象结构之上，开发者不仅可以在单套框架上实现多种范式，而且可以在单个应用中混用多种范式。在Spark中，可以轻松融合批量计算和流计算，还可以在交互式环境下实现流数据的即席查询。Storm相对于Spark Streaming最主要的优势在于处理延迟，但百毫秒至秒级延迟已经可以覆盖相当多的用例。更详细的分析比较可以参考Matei Zaharia博士的论文An Architecture for Fast and General Data Processing on Large Clusters的第四章。 InfoQ：2014年初您加入Databricks这个数据初创公司，当时是怎样一个契机触动了您？ 连城：我于2013年六月第一次接触Spark。此前函数式语言和分布式系统一直是我最为感兴趣的两个技术方向，而Spark刚好是这二者的一个很好的融合，这可以算是最初的契机。而深入接触之后，我发现Spark可以在大幅加速现有大数据分析任务的同时大幅降低开发成本，从而使得很多原先不可能的工作成为可能，很多困难的问题也得到了简化。Spark的社区活跃度也进一步增强了我对Spark的信心。有鉴于此，去年十月份刚得知Databricks成立时便有心一试，并最终得偿所愿 :-) InfoQ：您之前翻译的图书都是跟并发和分布式相关，请您介绍一下Spark在并发和分布式上的设计？ 连城：分布式系统设计的一大难点就是分布式一致性问题。一旦涉及可变状态的分布式同步，系统的复杂性往往会陡然上升。而Spark则较好地规避了这个问题。个人认为原因主要有二：
在并发方面，和Hadoop的进程级并行不同，Spark采用的是线程级并行，从而大大降低了任务的调度延迟。借助于Akka的actor model，Spark的控制位面和数据位面并发通讯逻辑也相对精简（Akka本身也的确是跟Erlang一脉相承）。 InfoQ：Spark社区现在是空前火爆，您觉得其流行的主要原因是什么？ 连城：可能是大家受Hadoop压迫太久了吧，哈哈，开玩笑的 :-) 我觉得原因有几点：
InfoQ：Spark目前好像还没有完全大规模应用，您觉得开发者主要的顾虑在什么地方？ 连城：由于大数据本身的重量，大数据分析是一个惯性很大的技术方向，相关新技术的推广所需要的时间也更加长久。我个人接触到的案例来看，Spark用户的主要顾虑包括两点：
InfoQ：您最希望Spark下一版本能解决的技术难题是什么？ 连城：我近期的工作主要集中于Spark SQL，在1.2的roadmap中最为期待的还是正在设计当中的外部数据源API。有了这套API，用户将可以在Spark SQL中采用统一的方式注册和查询来自多种外部数据源的数据。Cassandra、HBase等系统的深度集成将更加统一和高效。 InfoQ：在部署Spark集群、设计Spark应用时有哪些方面的问题需要考量？ 连城：
本文转载自：微信公众账号 - InfoQ，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
