storm

目录 前言： 1、连续事件处理的目标 2、流处理技术的演变 Lambda 架构概述：优势和局限性 3、初探Flink 批处理与流处理 4、为什么选择Flink 前言： 我们渴望按照流的方式处理数据，但要做好很困难；随着大规模数据在各行各业中出现，难度越来越大。这是一个属于物理学范畴的难题：在大型 分布式系统中，数据一致性和对事件发生顺序的理解必然都是有限的。伴随着方法和技术的演化，我们尽可能使这种局限性不危及商业目标和运营目标。 在这样的背景下， Apache Flink （以下简称 Flink ）应运而生。作为在公共社 区中诞生的开源软件，Flink 为大容量数据提供流处理，并用同一种技术实现批处理。 1、连续事件处理的目标 能够以非常低的延迟处理数据，这并不是流处理的唯一优势。人们希望流 处理不仅做到低延迟和高吞吐，还可以处理中断。优秀的流处理技术应该 能使系统在崩溃之后重新启动，并且产出准确的结果；换句话说，优秀的 流处理技术可以容错，而且能保证 exactly-once 2 。 与此同时，获得这种程度的容错性所采用的技术还需要在没有数据错误的 情况下不产生太大的开销。这种技术需要能够基于事件发生的时间（而不是随意地设置处理间隔）来保证按照正确的顺序跟踪事件。对于开发人员而言，不论是写代码还是修正错误，系统都要容易操作和维护。同样重要的是

Twitter将Storm正式开源了，这是一个分布式的、容错的实时计算系统，它被托管在 GitHub 上，遵循 Eclipse Public License 1.0 。Storm是由BackType开发的实时处理系统，BackType现在已在Twitter麾下。GitHub上的最新版本是 Storm 0.5.2 ，基本是用Clojure写的。 Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。 Storm也可被用于“连续计算”（continuous computation），对数据流做连续查询，在计算时就将结果以流的形式输出给用户。它还可被用于“分布式RPC”，以并行的方式运行昂贵的运算。 Storm的主工程师Nathan Marz表示： Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程语言来做开发。 Storm的主要特点如下： 简单的编程模型。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。 可以使用各种编程语言。你可以在Storm之上使用各种编程语言

问题信息 Unable to get offset lags for kafka. Reason: java.lang.NullPointerException at org.apache.storm.kafka.monitor.KafkaOffsetLagUtil.getOffsetLags (KafkaOffsetLagUtil.java:272) at org.apache.storm.kafka.monitor.KafkaOffsetLagUtil.main (KafkaOffsetLagUtil.java:124) 我的情况 当数据量慢慢上来的时候，这个问题就会自动解决，不知道原因，网上有如下的解决方案，请参考 问题描述: storm 起动 topology 的在 stormui 中可以看到类似错误 storm 的 KafkaSpout 接收 kafka 消息时报错，错误如下 Unable to get offset lags ``for` `kafka. Reason: java.lang.IllegalArgumentException: zk-node``'/kafka_storm/webTraceId'``dose not exists. at org.apache.storm.kafka.monitor.KafkaOffsetLagUtil

1、数据处理主要技术 Sqoop ：（发音：skup）作为一款开源的离线数据传输工具，主要用于Hadoop(Hive) 与传统数据库（MySql,PostgreSQL）间的数据传递。它可以将一个关系数据库中数据导入Hadoop的HDFS中， 也可以将HDFS中的数据导入关系型数据库中。 Flume： 实时数据采集的一个开源框架，它是Cloudera提供的一个高可用用的、高可靠、分布式的海量日志采集、聚合和传输的系统。目前已经是Apache的顶级子项目。使用Flume可以收集诸如日志、时间等数据 并将这些数据集中存储起来供下游使用（尤其是数据流框架，例如Storm）。和Flume类似的另一个框架是Scribe（FaceBook开源的日志收集系统，它为日志的分布式收集、统一处理提供一个可扩展的、高容错的简单方案） 　Kafka： 通常来说Flume采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲，而这方面最为流行和应用最为广泛的无疑是Kafka。它是由LinkedIn开发的一个分布式消息系统， 以其可以水平扩展和高吞吐率而被广泛使用。目前主流的开源分布式处理系统（如Storm和Spark等）都支持与Kafka 集成。 Kafka是一个基于分布式的消息发布-订阅系统，特点是速度快、可扩展且持久。与其他消息发布-订阅系统类似

本文主要记录一些关于Flink与storm,spark的区别, 优势, 劣势, 以及为什么这么多公司都转向Flink. What Is Flink 一个通俗易懂的概念: Apache Flink 是近年来越来越流行的一款开源大数据计算引擎，它同时支持了批处理和流处理. 这是对Flink最简单的认识, 也最容易引起疑惑, 它和storm和spark的区别在哪里? storm是基于流计算的, 但是也可以模拟批处理, spark streaming也可以进行微批处理, 虽说在性能延迟上处于亚秒级别, 但也不足以说明Flink崛起如此迅速(毕竟从spark迁移到Flink是要成本的). 最显而易见的原因 网上最热的两个原因: Flink灵活的窗口 Exactly once语义保证 这两个原因可以大大的解放程序员, 加快编程效率, 把本来需要程序员花大力气手动完成的工作交给框架, 下面简单介绍一下这两个特征. 1.什么是 Window 在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。 窗口可以是时间驱动的(Time Window, 例如: 每30秒钟

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 参考资料来源： http://blog.csdn.net/asbz123456/article/details/43153743 1 、下载 storm-start 源代码 # 下载 storm 源代码 git clone git://github.com/apache/storm.git # 下载 storm 源代码并进入 storm-start 目录 git clone git://github.com/apache/storm.git && cd storm/examples/storm-starter 2 、新建任意 eclipse 项目 1 ）、创建 eclipse 项目 storm-start 2 ）、导入 storm-start 源代码 3 、添加 jar 包 1 ）、导入 storm 源代码 lib 文件夹中所有 jar 文件 将 storm 项目所有 jar 包导入我们新建的 eclipse 项目 storm-start 中。 2 ）、导入 twitter4j.jar storm-start 项目导入成功，查看项目列表分布情况。 4 、运行 ExclamationTopology.java 文件 运行 ExclamationTopology.java 文件，查看 storm 运行结果。 5

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 storm并行的基本概念 一个运行中的拓扑是由什么构成的：工作进程（worker processes），执行器（executors）和任务（tasks） 在一个 Storm 集群中，Storm 主要通过以下三个部件来运行拓扑： 工作进程（worker processes）（进程数） 执行器（executors）（线程数） 任务（tasks）（实例组件数） storm集群中的一个机器可以运行一个或者多个worker,对应于一个或者多个topologies.1个worker进程运行1个或多个excutor线程。每个worker从属于一个topology.executor是单线程。每1个executor运行着相同的组件(spout或bolt)的1个或多个task。1个task执行着实际的数据处理。 下面是他们之间相互关系的简单图示。 2 是否需要提高workers数目 (1) 最好 一台机器上的一个topology只使用一个worker,主要原因时减少了worker之间的数据传输 (2) 有更多的worker可能会有更好的表现，这取决于你的瓶颈所在。每个worker都有通过一个线程将元组转移到其他的worker，所以如果你的瓶颈在CPU和每个worker正在处理大量的元组，更多的worker可能会提高你的吞吐量。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 storm并行的基本概念 一个运行中的拓扑是由什么构成的：工作进程（worker processes），执行器（executors）和任务（tasks） 在一个 Storm 集群中，Storm 主要通过以下三个部件来运行拓扑： 工作进程（worker processes）（进程数） 执行器（executors）（线程数） 任务（tasks）（实例组件数） storm集群中的一个机器可以运行一个或者多个worker,对应于一个或者多个topologies.1个worker进程运行1个或多个 excutor线程。每个worker从属于一个topology.executor是单线程。每1个executor运行着相同的组件(spout或 bolt)的1个或多个task。1个task执行着实际的数据处理。 下面是他们之间相互关系的简单图示。 2 是否需要提高workers数目 (1) 最好 一台机器上的一个topology只使用一个worker,主要原因时减少了worker之间的数据传输 (2) 有更多的worker可能会有更好的表现，这取决于你的瓶颈所在。每个worker都有通过一个线程将元组转移到其他的worker，所以如果你的瓶颈在CPU和每个worker正在处理大量的元组

　　今天跟一个朋友在讨论hadoop体系架构，从当下流行的Hadoop+HDFS+MapReduce+Hbase+Pig+Hive+Spark+Storm开始一直讲到HDFS的底层实现，MapReduce的模型计算，到一个云盘如何实现，再到Google分布式史上那最伟大的三篇文章。 　　这几个名词刚问到初学者的时候肯定会一脸懵逼包括我自己，整个Hadoop家族成员很多，“势力”很庞大，下面画个图，简单概括下。 到这里本文内容已结束，下文是摘自网络上一些比较经典或者浅显易懂的相关文字，有兴趣的继续往下看。对初学者来说，如果上图能大概看懂，那下面的内容能更有利于你理解。 Google的分布式计算三驾马车： Hadoop的创始源头在于当年Google发布的3篇文章，被称为Google的分布式计算三驾马车。 Google File System（ 中文 ， 英文 ）用来解决数据存储的问题，采用N多台廉价的电脑，使用冗余（也就是一份文件保存多份在不同的电脑之上）的方式，来取得读写速度与数据安全并存的结果。 Map-Reduce说穿了就是函数式编程，把所有的操作都分成两类，map与reduce，map用来将数据分成多份，分开处理，reduce将处理后的结果进行归并，得到最终的结果。但是在其中解决了容错性的问题。 BigTable是在分布式系统上存储结构化数据的一个解决方案

Storm是一个分布式的、高容错的实时计算系统。Storm适用的场景： Storm可以用来用来处理源源不断的消息，并将处理之后的结果保存到持久化介质中。 由于Storm的处理组件都是分布式的，而且处理延迟都极低，所以可以Storm可以做为一个通用的分布式RPC框架来使用。(实时计算？) Storm集群架构 Storm集群采用主从架构方式，主节点是Nimbus，从节点是Supervisor，有关调度相关的信息存储到ZooKeeper集群中，架构如下图所示 Nimbus：Storm集群的Master节点，负责分发用户代码，指派给具体的Supervisor节点上的Worker节点，去运行Topology对应的组件（Spout/Bolt）的Task。 Supervisor：Storm集群的从节点，负责管理运行在Supervisor节点上的每一个Worker进程的启动和终止。 ZooKeeper： 存储客户端提供的topology任务信息，nimbus负责将任务分配信息写入Zookeeper，supervisor从Zookeeper上读取任务分配信息 存储supervisor和worker的心跳（包括它们的状态），使得nimbus可以监控整个集群的状态， 从而重启一些挂掉的worker 存储整个集群的所有状态信息和配置信息。 组件抽象 我们先看一下