JStorm分布式计算

2016-06-14 11:23:27   0  举报





仅支持查看

JStorm是一个开源的分布式计算系统，它基于Apache Storm流式处理框架。它能够处理大量的实时数据流，支持多种数据源和数据格式，包括Kafka、Flume、Hadoop等。JStorm提供了丰富的数据处理和分析功能，包括窗口操作、聚合函数、状态管理等，能够帮助用户快速构建实时数据处理应用。此外，JStorm还具有高可靠性和可扩展性，能够适应大规模的数据处理需求。总之，JStorm是一个功能强大、易于使用的分布式计算系统，适用于各种实时数据处理场景。

作者其他创作

大纲/内容

App 3

Spout

Bolt

数据筛选中心集群

第三方应用

Cluster 2

数据推送系统和 JStorm模式对比

Cluster 1

中转队列(Kafaka)集群

分为Spout/Bolt两个部分，Spout负责取数据，Bolt负责处理数据。它将数据处理流程化，将分布式集群服务器的能力组合在一起，设定统一的数据处理模型。使用者只需要按照它的模型，取数据，然后处理数据即可，就好像是在同一台服务器上操作一样，不需要关心多服务器、集群的问题。对比我们的数据推送系统，JStorm的模型，貌似有些类似，但是仔细考虑，JStorm的模型还是不太适合。首先，我们的系统分为filter、中转kafka、push三个部分，外加一个monitor。filter类似于Spout，push类似于Bolt，但是我们还多了一层：中转kafka，可以缓存一下数据，并且数据是分类好的（按app、topic、partition三个维度存放）。而JStorm的Spout取数据回来，是将数据放在内存里面，然后Bolt再从内存去取，如果Spout塞数据的速度大于Bolt取数据的速度，内存中的数据就会有积压，既然有积压，一旦服务器挂掉，那么内存中的数据就会丢失。还有一个问题，因为我们的filter专注于从GDCP Kafka取数据，一个线程消费所有app、所有topic，在这种机制下面，如果内存中数据有一定积压就暂停filter取数据，那么一个app的某个topic数据量大，势必会影响到所有app的所有topic，拖累整个系统。使用Kafka做中转队列的好处在于，数据可以尽情积压，不会对系统性能有较大影响，更不会因为某个app的某个topic数据量大而影响到其他app的数据推送。【引申问题：要不要给app下每个topic建一个推送线程？如果一个线程推送所有topic，那么一旦某个topic数据量大，则会加重其他topic的数据推送延迟】如果将JStrom取代Push，从中转Kafka取数据，感觉也不合适，我们的Push的一个关键设计是，取数据和推送数据的同步进行，推送得快就取得快，推送得慢就取得慢，取出来的数据是直接HTTP POST推送。如果使用JStorm的Spout/Bolt两层结构，就多此一举，本来简单的过程变得复杂，内部消耗也大，线程数使用会多很多。

Cluster 3

App 2

Cluster

Kafka

关于JStorm 分布式计算，数据处理引擎。

数据推送中心集群

App 1

数据中心Kafka集群