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 带来的停顿问题

采访者简介

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