转载

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插件是我们排期中的另一个短期目标。