这篇文章主要介绍”PaaStorm是如何从源到目的做数据的实时转换”,在日常操作中,相信很多人在PaaStorm是如何从源到目的做数据的实时转换问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答“PaaStorm是如何从源到目的做数据的实时转换”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
<强>这名字中有什么含义?
PaaStorm的名字其实是PaaSTA和风暴的组合。那PaaStorm到底是干什么的呢?要回答这个问题,咱们先看看数据管道的基本架构:
主要看看“变压器”那一步,就会知道大多数存储在卡夫卡中的消息都并不能直接被导入目标系统。设想有一套红移集群是用来存储广告推送数据的。广告推送集群想存储的只是上游系统的某一个字段(比如某个业务的平均权重),否则它就要保存原始数据并对其进行聚合计算。如果Redhift广告推送集群要存储所有上游数据的话,就会浪费存储空间,导致系统性能降低。
在过去,各个服务都会写复杂的MapReduce任务,在把数据写到目标数据存储之前先进行数据处理。可是,这些MapReduce任务都碰到了上文所述的性能和扩展问题。数据管道给大家提供的好处之一是消费者程序可以拿到它所需要的数据的形式,不管上游数据本来是什么样。
<>强减少示例代码
本来我们是可以让每个消费者程序自己按自己需要的方式做数据转换的。比如,广告推送系统可以自己写一个转换服务,从卡夫卡中的业务数据中提取出查看统计量,并自己维护这个转换服务的。这种办法最初工作得很好,但最终系统上规模时我们就碰上问题了。
我们想提供一个转换框架是基于以下考虑:
很多转换逻辑是通用的,可以在多个团队之间共享。比如把标志位转换成有意义的字段。
<李>这样的转换逻辑通常会需要很多示例代码,比如连接数据源或数据目的,保存状态,监控吞吐量,故障恢复等。这样的代码本来并不需要在各种服务之间拷来拷去。
<李>要保证能对数据进行实时处理的话,数据转换操作要尽可能地快,要基于流。
<李>减少示例代码最自然的方式就是提供一个转换接口。大家的服务实现接口中完成一次转换操作的具体逻辑,然后,剩下的工作就由我们的流处理框架完成。
<强>把卡夫卡作为消息总线
最初PaaStorm是一个Kafka-to-Kafka的转换框架,慢慢地才演进成也支持了其他类型的终端节点。把卡夫卡做为PaaStorm的终端节点简化了很多东西:每个对数据感兴趣的服务都可以注册到主题上,关注任意转换过的数据或者原始数据,有新消息到来就处理就好了,完全不必在意是谁创建了这个话题。转换过的数据按卡夫卡的保留策略持久化。因为卡夫卡是一个发布-订阅系统、下游系统也可以在任何它想的时候消费数据。
<强>用风暴处理一切
当采用了PaaStorm之后,我们该怎样把我们的卡夫卡,主题之间的关系可视化呢?因为有些话题中的数据会按照源到端的方式流向别的话题,我们可以把我们的拓扑结构当成一个有向无环图:
每个节点都是一个卡夫卡,话题,箭头表示PaaStorm提供的转换操作。这时候“PaaStorm”这个名字就变得更有意义了:象风暴一样,PaaStorm通过转换模块(象螺栓一样)提供对数据流的源(象壶嘴一样)的实时转换。
<强> PaaStorm内部机制
PaaStorm的核心抽象叫做Spolt(壶嘴和螺栓的结合物)。象名字表示的一样,Spolt接口也定义了两个重要的东西:一个输入数据源,一种对那个源的消息数据进行的某种处理。
<强>下面例子定义了一个最简单的Spolt:
这个Spolt会处理“refresh_primary.business.abc123efg456”这个话题中的每一条消息,增加一个字段,保存原始消息中的,只要name&,字段的大写的值,然后再把这条处理过的新版本的消息发送出去。
值得一提的是数据管道中的所有消息都是不可修改的。要得到一条修改过的消息,就要创建一个新的对象,而且,因为我们在为消息体中增加一个新字段(就是那个增加的“大写字母的名字“字段),新消息的模式已经改变了。在生产环境中,消息的模式ID是从来都不能写死的。我们要依靠系统化服务来为一条修改过的消息注册并提供合适的模式。
