Databricks连城谈Spark的现状

连城目前就职于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则较好地规避了这个问题。个人认为原因主要有二：

1. Spark是一个大数据分析框架，其本身并不包含任何（持久）存储引擎实现，而是兼容并包现有的各种存储引擎和存储格式，所以规避了分布式存储系统中的分布式数据一致性问题。
2. 虽然函数式语言还远未成为主流，但在大数据领域，以不可变性（immutability）为主要特征之一的函数式编程却已经深入骨髓。扎根于函数式编程的MapReduce固然是一大原因，但我猜想另一方面可能是因为在大数据场景下，单一节点出错概率较高，容错代价偏大，因此早期工程实践中一般不会在计算任务中就地修改输入数据，而是以新增和/或追加文件内容的方式记录中间结果和最终结果，以此简化容错和计算任务的重试。这种对不可变性的强调，大大削减了大数据分析场景下的数据一致性问题的难度。上层框架也因此得以将注意力集中在容错、调度等更为高层的抽象上。

在并发方面，和Hadoop的进程级并行不同，Spark采用的是线程级并行，从而大大降低了任务的调度延迟。借助于Akka的actor model，Spark的控制位面和数据位面并发通讯逻辑也相对精简（Akka本身也的确是跟Erlang一脉相承）。

InfoQ：Spark社区现在是空前火爆，您觉得其流行的主要原因是什么？

连城：可能是大家受Hadoop压迫太久了吧，哈哈，开玩笑的 :-) 我觉得原因有几点：

1. Spark在大大提升大数据分析效率的同时也大大降低了开发成本，切实解决了大数据分析中的痛点
2. 通过RDD这一抽象解决了大数据分析中的数据共享这一重要问题，从而使得开发者得以在单一应用栈上混合使用多种计算范式打造一体化大数据分析流水线，这大大简化了应用的开发成本和部署成本。
3. 简洁明了的接口。我曾经碰到这么一个真实案例，一位Spark contributor用Spark来做数据分析，但他的数据量其实很小，单机完全可以处理，他用Spark的主要理由就是接口简洁明了，写起来代码来“幸福指数”高 :-) 当然另一个重要理由是今后数据量大起来之后可以很方便地scale out。
4. 对兼容性的极致追求。面对资产丰富的Hadoop生态，Spark的选择是全面兼容，互惠共赢。用户无须经历痛苦的ETL过程即可直接部署Spark。这也是Cloudera、MapR、Pivotal、Hortonworks等Hadoop大厂商全面拥抱Spark的重要原因之一。

InfoQ：Spark目前好像还没有完全大规模应用，您觉得开发者主要的顾虑在什么地方？

连城：由于大数据本身的重量，大数据分析是一个惯性很大的技术方向，相关新技术的推广所需要的时间也更加长久。我个人接触到的案例来看，Spark用户的主要顾虑包括两点：

1. Scala相对小众，认为相关人才培养和招聘上会比较吃力。这个问题我认为正在缓解，而且有加速的趋势。
2. 对数百、上千节点的大规模集群的稳定性的顾虑。实际上一千节点以上Spark集群的用例已经出现多个，其中eBay的Spark集群节点数已超过两千。

InfoQ：您最希望Spark下一版本能解决的技术难题是什么？

连城：我近期的工作主要集中于Spark SQL，在1.2的roadmap中最为期待的还是正在设计当中的外部数据源API。有了这套API，用户将可以在Spark SQL中采用统一的方式注册和查询来自多种外部数据源的数据。Cassandra、HBase等系统的深度集成将更加统一和高效。

InfoQ：在部署Spark集群、设计Spark应用时有哪些方面的问题需要考量？

连城：

• 集群部署方式，standalone、Mesos和YARN各有千秋，需要按需选用。
• 在单集群规模上，也可以按需调整。Yahoo和腾讯采用的是多个小规模卫星集群的部署模式，每个集群都有专用的目的，这种模式故障隔离更好，可以保证更好的QoS。同时业内也不乏eBay这样的单体大集群案例，其主要点在于更高的集群资源利用率以及对大规模计算的应对能力
• 与现存数据分析系统的对接。对于常见系统如Kafka、Flume、Hive、支持JDBC的传统数据库，可以利用Spark提供的现成接口；对于Spark项目本身尚未涵盖的，或是私有系统的对接，可以考虑开发自定义数据源RDD。在1.2版本以后，也可以考虑通过Spark SQL的外部数据源API来对接现有结构化、半结构化数据
• 合理挑选、组织需要cache的数据，最大限度地发挥Spark内存计算的优势
• 熟悉并合理选用恰当的组件。Spark提供了多个可以互操作的组件，可以极方便的搭建一体化的多范式数据流水线。
• 和所有其他基于JVM的大数据分析系统一样，规避full GC带来的停顿问题

采访者简介

张天雷（@小猴机器人），清华大学计算机系博士，熟悉知识挖掘，机器学习， 社交网络舆情监控，时间序列预测等应用。目前主要从事国产无人车相关的研发工作。