Spring XD 1.1: 简化大数据一如 Spring 之于 Java EE

Pivotal 最近发布了 Spring XD 1.1 GA 新功能包括使用 Reactor、RxJava、Spark Streaming 和 Python 进行流处理。此外，支持 Kafka 、批量处理和 RabbitMQ 压缩, 以及支持运行在 YARN 上的容器组管理的功能。Spring XD 项目为开发者提供了应用示例超过 25 个。

作为发布的一部分，Pivotal 的产品经理写到：“大数据应用的开发不应该如此耗时且复杂”。在 _Spring XD: Data-Driven Connectivity Within a Unified Platform_ 一文中，Anandan 强调可以通过命令行使用 XD 的高级 DSL 构建数据流，不再需要安装 IDE 或者构建脚本。他还提到可以使用内置的管理界面实现远程监控和管理流、批量任务和整个集群。

在宣布 Spring XD 发版后没多久，Pivotal开源了他们的大数据套件。在此前的 InfoQ 的文章中，Abel Avram 写到：

相比早期进入大数据市场的 HortonWorks、Cloudera 和 MapR，Pivotal 姗姗来迟。但是现在，为解决大数据空间的“碎片化和供应商锁定 (fragmentation and vendor lock-in)”问题，Pivotal 已经决定从大数据套件中开源数个产品，包括命名为 Greenplum Database 的平行计算数据仓库、 HAWQ –Hadoop 查询引擎上兼容 ANSI 的 SQL， GemFire -- 分布式的 NoSQL 内存数据库。

Software Development Times 高级编辑 Alex Handy 在他的文章 _Pivotal pivots to open source_ 中写到：

Spring XD 之于 Hadoop 就像 Spring 之于 Java EE。

他接着说：

简而言之，这意味着 Spring XD 简化了配置和构建 Map/Reduce 和其他 YARN 查询的样板工作。曾经 Spring 为 Java EE 做了同样的事情，Spring 简化了折磨企业应用的开发者十余年的、无尽的配置和 XML 文件。

Cameron Purdy 在 Pivotal 的大数据套件和商业模式的开源许可上评论到：

根据 EMC/VMWare 的公开文件和评论，Pivotal 一直以不可思议的速度亏损。以这样的烧钱速度和 EMC/VMWare 和 GE 的最初投资金额来说，Pivotal 很可能在一年之内完蛋。Pivotal 的商业模式是行不通的，而且似乎没有人胆敢公开指出这是多么糟糕的商业模式（以及 VMware 的收购者是多么的逗比）。

Purdy 还提到：

我认为 Groovy 的撤资只是冰山一角。

为了了解关于这次发布的更多信息，InfoQ 采访了 Spring XD 的共同领导 Mark Pollack 和 Mark Fisher，以及产品经理 Sabby Anandan。

InfoQ: Spring XD 是如何简化大数据应用开发的？

DSL vs. API 开发

Spring 一直受到 Alan Kay 思想的鼓舞：“简单事情简单办，复杂事情合理办”，而 Spring XD 将这一思想上升到了一个全新的水平。它提供了多个分布式运行时选项，并且无需编码即可支持宽泛的使用场景。使用 Spring XD，无论通过 HTTP 还是 HDFS 采集数据都明显地“简单”，甚至对于可能会变得复杂的定制流处理的情况，开发者只专注于代码并将其放入文件夹，Spring XD 模型会动态地将其添加到模块的注册表。随即这部分就会在 DSL 中可用，就像任何开箱即用模块一样。Spring XD 对处理逻辑和基础结构的分离做得非常好。

InfoQ: 可以用代码举个现实生活中的例子吗？

就拿刚说的数据采集为例吧，用户只需通过 XD shell、REST API 或者 web 界面提交“http | hdfs”。对于自定义模块一些例子，会涉及到代码，可以从 Spring XD 示例库： https://github.com/spring-projects/spring-xd-samples 上查看。

InfoQ: 1.1 GA 版本的主题是流。是什么促使增加了对 Reactor、RxJava 和 Spark 支持？

我们想提供一种使用这些项目中提供的函数式 API 执行流处理的方式。现在，使用我们的模块化架构，这些 API 就可以与流内的任何可用的或者将来可用的数据源或数据汇连接。

InfoQ: 对于刚刚提到的流处理库来说，哪个是最容易集成的？哪个是最困难的？

首先要明确的是，我们的主要目标是确保开发者使用这些流处理库的体验尽可能简单而且尽量保持一致。所以，对于 Spring XD 的内部实现，其本身与那些库的集成就要努力地采用这样的方式，以达到我们这里讨论的这一目标。与 Reactor 和 RxJava 的集成比 Spark 更容易。后者的集成超出了 API 层级，因为我们所委托的 Spark 集群的工作负载，涉及到还在不断演进的自定义序列化机制和生命周期管理模型。因此，我们曾经一度放弃多个对 Spark 项目的分支合并请求 (pull request) 的提交，我们为所做的贡献感到自豪。与 RxJava 和 Reactor 集成的一个有趣的地方是如何将收到的消息分配给特定的流实例。我们可以跨处理线程，将所有传入的事件分配到单流实例，这样你就可以计算出全局状态，也可以分配事件到多流实例，每实例一处理线程，因为流实例不是线程安全的。可以进一步将其拆分到更细粒度的流示例中，例如将流实例与 Kafka 分区 ID 匹配。在 Kafka 这个场景下，我们可以确保对于给定的分区中的所有事件使用相同的线程来处理，因此，会保证执行的顺序。

InfoQ: 根据最近的 Typesafe 报告，Scala 社区对 Apache Spark 表现出浓厚的兴趣（Spark 的用户有 88％使用 Scala，44％使用 Java，22％使用 Python）。我们有 Scala 的 API，是否有大量的开发者在使用呢？

我们在 Spring XD 中提供了对 Spark 的 processor 或 sink 的支持。可以用于 Java 或 Scala 中，并且在这两种情况下实现的是同一接口，以 DStream 作为输入、(可选地，比如 sink) 产生的 DStream 作为输出。换言之，不存在对任何其他 API 的侵入，纯粹针对 Spark。1.1 版本开始支持 Spark，对于这些模块，预计大多数开发者会选择 Scala，因为正如你在问题中所指出的，这是 Spark 用户最常见的选择。我们还为 Spring 集成和自定义模块提供了 Scala 的 DSL。考虑到支持 Java 8 的 DSL 也是基于 lambda 的，从而相当简洁，因此会是一个留住用户不去转用 Scala 的因素。即便如此，实现自定义模块的生产和消费消息的代码是完全隔离的，这对希望使用 Scala 的开发者来说很方便，相比总体不是基于 Scala 开发的其他系统而言，具有定义良好的扩展点。

InfoQ: Spring XD 的未来有哪些规划？

虽然我们相信更短的迭代和增量交付，但我们在 2015 年度有更远大的目标。Spring XD 是 Pivotal Cloud Foundry 上非常活跃的在制品，我们想通过开发者和 devops 的直接经验拉近大数据和云计算之间的距离。有了 Spring XD 作为 Pivotal Cloud Foundry 的服务，可以建立特定领域的 PaaS 解决方案–“电信即服务”、“医疗保健即服务”等等。我们也在建立一个基于 HTML5 的画布用户界面，通过拖拽来支持开箱即用的模块进一步简化开发者体验，比如要增加度量和监控能力。Srping XD 的 Apache Ambari 插件是我们排期中的另一个短期目标。

InfoQ: Spring XD 入门的最佳实践是什么？

Spring XD 的入门花不了 5 分钟时间。操作系统的不同选择项会不同。OSX 用户可以使用 homebrew 安装 Spring XD。红帽 / CentOS 用户可以使用 yum 仓库安装 Spring XD。如果你喜欢直接下载二进制，你可以选择手动设置环境变量。入门指南涵盖了这些步骤和其他的一般要求。

想了解更多关于 Spring XD 的信息，可以参考 Charles Humbles 的这篇文章 Introducing Spring XD, a Runtime Environment for Big Data Applications。

查看英文原文： Spring XD 1.1: Simplifying Big Data like Spring Did for Java EE

感谢丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。