定量分析的成败在很大程度上取决于采集,存储和处理数据的能力。若能及时地向业务决策者提供深刻并可靠的数据解读,大数据项目就会有更多机会取得成功。
如今,为数据处理设计合适的架构需要下很大工夫。数据处理主要包括 3 个方面:
大数据项目的工程非常耗时,并且要利用合适的技能来解决数据采集和处理的问题,因为这些问题的解决对大多数方案来说都是必不可少的。Pivotal 曾推出了 Spring XD 和 Spring Cloud Dataflow 来减少大数据工程的开销。本文将简要介绍 Spring XD,以及该技术的最新版本,即 Spring Cloud Data Flow 的各方面细节。
Spring XD 是第一轮技术创新的产物。它为一些常见的与数据处理有关的任务提供了一种易用的解决方案。Spring XD 建立在了历经考验的 Spring 技术之上,并为数据摄入、移动、处理、深度分析、流处理和批处理提供了支持。
Spring XD 为实时处理以及批处理提供了一个精巧、稳定,且可扩展的框架。用 Spring XD 来采集数据,并将数据从各种数据源移到目标会更加容易。
Spring XD 架构在传统企业级 ETL(数据抽取、转换与加载的流程),实时分析和数据科学项目工作台的创建中得到了广泛应用。
下图描述了基于 Spring XD 的架构。在下图这些模块的帮助下,我们可以创建、运行、部署并销毁数据管道,并对管道中的数据进行各种各样的处理。
Spring XD 的主要组件是 Admin 和 Container。
以下是 Spring XD 体系结构中的一些关键模块。
应用方面的需求总是在变化。这逐渐揭示了 Spring XD 的缺陷和对新一轮的技术创新的需求。以下是一些对新型框架最重要的需求:
作为第二轮技术创新,Pivotal 推出了 Spring Cloud Data Flow 来替代原来的 Spring XD。Spring Cloud Data Flow 继承了 Spring XD 的优势,并通过利用云原生(cloud native)方法提供了更具可扩展性的解决方案。Spring Cloud Data Flow 是一个混合的计算模型,可以将流处理和批处理统一起来。开发人员可以利用 Spring Cloud Data Flow 来创建并操作数据管道来进行处理数据摄入、实时分析和批处理等常见流程。Spring Cloud Data Flow 只会提供一个管理服务模型,旨在精简数据项目的工程量,并让开发人员将精力集中在具体问题及对问题的分析上。
从 Spring XD 到 Spring Cloud Data Flow,对功能的结构以及利用云原生架构扩展应用程序方法发生了从根本上的改变。
Spring Cloud Data Flow 从传统的基于组件的架构转向了采用更适合云原生应用的,由消息驱动的微服务架构。现在 Spring XD 模块已经被部署在云端上的微服务取代了。
具体地说,Spring Cloud Data Flow 在以下方面有着一些重大变化:
Spring Cloud Data Flow 的组件:
零件 | 目的 |
---|---|
核心领域模块(Core domain Modules) | 核心领域模块是任何数据流的主要构建模块。它包括诸如数据源,数据接收器,数据流和用于批处理作业和实时处理的任务的模块。所有这些模块都是 Spring Boot Data 微服务应用程序。 |
模块注册表(Module Registry) | 它使用 Maven 来维护可用的模块。 |
模块部署者 SPI(Module Deployer SPI) | 作为抽象层,它被用于在不同的运行环境(如 Lattice,Cloud Foundry,Yarn 还有本地环境)里部署模块。 |
Admin | Admin 是一个 Spring Boot 应用。它提供了一套 REST API 和 UI。 |
Shell | 使用 Shell,我们可以连接到 Admin 的 REST API 来运行 DSL 命令以创建、处理和销毁这些数据流,并执行其他简单任务。 |
上图描绘了使用 Spring Cloud Data Flow 模型创建的一个典型数据流。
作为 Spring Boot 微服务,数据源,作业,数据接收器和数据处理器都可以部署在 Cloud Foundry, Lattice 或 Yarn 集群上。通过使用部署在云原生平台上的这些微服务,我们可以创建数据管道并将其输入到 Yarn,Lattice 或基于 Cloud Foundry 的目标中。平台特定的 SPI(服务提供者接口)会被用于发现和绑定微服务,以及绑定基于开发平台的渠道(channel)。
使用 Spring Cloud Data Flow 的真正好处是能够使用一个统一的框架来快速完成构建和配置工作,并建立数据摄入和处理流程,从而使开发人员能更好地关注具体问题。
我们不妨构建这样一个用例来在高层面上见识一下 Spring Cloud Data Flow 的改变:在没有自带数据源模块的情况下构造一个完整的数据流,比如对 Facebook 的数据造一个数据流来分析 Facebook 的帖子。 在这种情况下,我们不能用在 Spring Cloud Data Flow 模块里能随便用的 Facebook 数据源模块,因此我们需要为 Facebook 数据源创建自定义模块。创建一个数据流需要三个主要的微服务:数据源,数据处理器和数据接收器。这三个微服务都有相应的接口类。
Facebook 数据管道的数据源和数据接收器的微服务示例代码片段:
Facebook 数据源:
@SpringBootApplication
@ComponentScan(.class)
public class SourceApplication {
public static void main(String[] args) {
SpringApplication.run(SourceApplication.class, args);
}
}
@Configuration
@EnableBinding(Source.class)
public class FBSource {
@Value("${format}")
private String format;
@Bean
@InboundChannelAdapter(value = Source.OUTPUT, poller = @Poller(fixedDelay = "${fixedDelay}", maxMessagesPerPoll = "1"))
public PostSource<String> FBPostSource() {
// 一些从 Facebook 获取帖子的逻辑
return // Facebook 帖子列表
}
}
@EnableBindings(Source.class)
注解会检查相应的作为可绑定组件的接口类的实现是否存在(要在应用的 classpath 中设置,参考 Redis),然后这一组件会构建相应的渠道适配器(channel adapters)。所有微服务都会被转变为 Spring Boot 应用程序来实现更简单的依赖管理。
Facebook 数据接收器:
@SpringBootApplication
@EnableBinding(Sink.class)
@ComponentScan(.class)
public class SinkApplication {
public static void main(String[] args) {
SpringApplication.run(SinkApplication.class, args);
}
}
@Configuration
public class FBSink {
private static Logger logger = LoggerFactory.getLogger(LogSink.class);
@ServiceActivator(Source.INPUT)
public void loggerSink(Object payload) {
logger.info("Received: " + payload);
}
}
上述代码会接收来自 Facebook 数据流的数据并将其写入控制台。Sink.class
在此会作为参数传递给 @EnableBinding
注解。另外 @ServiceActivator
会将数据输入模块连接到上例中的终端(endpoint)控制台。
一些作为数据处理器的微服务将根据输入的 SPEL 表达式过滤来自 FBSource 微服务的 Facebook 帖子,而数据处理器微服务的输出就会是 FBSink 微服务的输入。
Spring Cloud Data Flow 使用了 Spring Cloud stream 模块。我们可以用后者来创建和运行以 Spring Boot 应用为形式的消息传递微服务,以便它们可以部署在不同的平台上,独立运行并相互交互。在使用 Spring Cloud stream 模块创建数据管道时,Spring Cloud Data Flow 可以充当类似胶水的角色。
目前有许多用于管理数据摄入,实时分析和数据加载的,独立的开源项目。Spring Cloud Data Flow 则为数据摄入,实时分析,批处理还有数据输出提供了一个统一的,可扩展的分布式服务。