storm

版权声明：藏经阁 | 玄苦 | 陈国林 https://blog.csdn.net/cgl1079743846/article/details/90636723 一. 概述 storm metric类似于hadoop的counter，用于收集应用程序中的特定指标，输出到外部。在storm中是存储到各个机器logs目录下的metric.log文件中。有时我们想保存一些计算的中间变量，当达到一定状态时，统一在一个位置输出，或者统计整个应用的一些指标，metric是个很好的选择。 二. 使用 ① 在bolt的prepare注册metric metric都定义为了transient。因为这些Metric实现都没有实现Serializable，而在storm的spout/bolt中，所有非transient的变量都必须Serializable 三个参数为metric名称，metric对象，以及时间间隔。时间间隔表示多久一次metric将数据发送给metric consumer。 在bolt的execute方法中更新metric 在topo中指定将metric consumer，这里使用了storm自带的consumer将其输出到日志文件中，也可以自定义consumer。 三. 详细说明 metric和metric consumer storm中关于metric的API主要有2部分

Storm的分发策略 Storm当中的分组策略，一共有八种： 所谓的grouping策略就是在Spout与Bolt、Bolt与Bolt之间传递Tuple的方式。总共有八种方式： 1）shuffleGrouping （随机分组）随机分组；将tuple随机分配到bolt中，能够保证各task中处理的数据均衡； （按照字段分组，在这里即是同一个单词只能发送给一个Bolt） 按字段分组； 根据设定的字段相同值得tuple被分配到同一个bolt进行处理； 举例：builder.setBolt("mybolt", new MyStoreBolt(),5).fieldsGrouping("checkBolt",new Fields("uid")); 说明：该bolt由5个任务task执行，相同uid的元组tuple被分配到同一个task进行处理；该task接收的元祖字段是mybolt发射出的字段信息，不受uid分组的影响。 （广播发送，即每一个Tuple，每一个Bolt都会收到）广播发送：所有bolt都可以收到该tuple （全局分组，将Tuple分配到task id值最低的task里面）全局分组：tuple被发送给bolt的同一个并且最小task_id的任务处理，实现事务性的topology （随机分派）不分组：效果等同于shuffle Grouping. （直接分组

作者：jiangzz 电话：15652034180 微信：jiangzz_wx 微信公众账号：jiangzz_wy 2019年6月份，Apache Storm PMC宣布发布Storm 2.0.0。此版本的主要亮点是Storm已经在纯Java中重新构建。以前，Storm的核心功能很大一部分是在Clojure中实现的。此版本还包括在性能，新流API，窗口增强和Kafka集成更改方面的重大改进。 用Java实现的新架构 在此版本中，Storm已经重新构建，其核心功能在纯Java中实现。这种新的实现显着改善了其性能，并使内部API更易于维护和扩展。以前的语言Clojure经常为进入新贡献者提供障碍。现在，对于那些不想学习Clojure以便贡献的开发人员来说，Storm的代码库现在更容易被访问。 新的高性能核心 Storm 2.0.0拥有一个新的核心，具有更精简的线程模型，超快的消息传递子系统和轻量级的背压模型。这旨在突破吞吐量，延迟和能耗的边界，同时保持向后兼容性。此外，这使得Storm 2.0成为第一款打破1微秒延迟障碍的流媒体引擎。 新Streams API 这个版本有一个新的类型API，它将使用功能样式操作更容易地表达流式计算。它建立在Storm的核心喷口和螺栓API之上，并自动将多个操作融合在一起。这将有助于优化管道。 窗口增强功能 Storm 2.0

配置项 配置说明 storm.zookeeper.servers ZooKeeper服务器列表 storm.zookeeper.port ZooKeeper连接端口 storm.local.dir storm使用的本地文件系统目录(必须存在并且storm进程可读写) storm.cluster.mode Storm集群运行模式([distributed|local]) storm.local.mode.zmq Local模式下是否使用ZeroMQ作消息系统，如果设置为false则使用java消息系统。默认为false storm.zookeeper.root ZooKeeper中Storm的根目录位置 storm.zookeeper.session.timeout 客户端连接ZooKeeper超时时间 storm.id 运行中拓扑的id,由storm name和一个唯一随机数组成。 nimbus.host nimbus服务器地址 nimbus.thrift.port nimbus的thrift监听端口 nimbus.childopts 通过storm-deploy项目部署时指定给nimbus进程的jvm选项 nimbus.task.timeout.secs 心跳超时时间，超时后nimbus会认为task死掉并重分配给另一个地址。 nimbus.monitor.freq.secs

2.1 Storm 基本概念 在运行一个Storm任务之前，需要了解一些概念： Topologies Streams Spouts Bolts Stream groupings Reliability Tasks Workers Configuration Storm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReduce jobs，而在Storm上运行的是拓扑（topology），这两者之间是非常不一样的。一个关键的区别是： 一个MapReduce job最终会结束， 而一个topology永远会运行（除非你手动kill掉）。 在Storm的集群里面有两种节点： 控制节点（master node）和工作节点（worker node）。控制节点上面运行一个叫Nimbus后台程序，它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码，分配计算任务给机器， 并且监控状态。 每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集；一个运行的topology由运行在很多机器上的很多工作进程组成。 Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成。另外

作者Michael G. Noll是瑞士的一位工程师和研究员，效力于Verisign，是Verisign实验室的大规模数据分析基础设施（基础Hadoop）的技术主管。本文，Michael详细的演示了如何将Kafka整合到Spark Streaming中。 期间， Michael还提到了将Kafka整合到 Spark Streaming中的一些现状，非常值得阅读，虽然有一些信息在Spark 1.2版本中已发生了一些变化，比如HA策略： 通过Spark Contributor、Spark布道者陈超我们了解到 ，在Spark 1.2版本中，Spark Streaming开始支持fully HA模式（选择使用），通过添加一层WAL（Write Ahead Log），每次收到数据后都会存在HDFS上，从而避免了以前版本中的数据丢失情况，但是不可避免的造成了一定的开销，需要开发者自行衡量。 以下为译文 作为一个实时大数据处理工具， Spark Sreaming 近日一直被广泛关注，与 Apache Storm 的对比也经常出现。但是依我说，缺少与Kafka整合，任何实时大数据处理工具都是不完整的，因此我将一个示例Spark Streaming应用程序添加到 kafka-storm-starter ，并且示范如何从Kafka读取，以及如何写入到Kafka。在这个过程中

1、大数据流程图 2、大数据各个环节主要技术 在这里还是要推荐下我自己建的 大数据学习交流群:9437**91324 ，群里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入,大家都是软件开发党，不定期分享干货（只有大数据软件开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴加入。 2.1、数据处理主要技术 Sqoop ：（发音：skup）作为一款开源的离线数据传输工具，主要用于Hadoop(Hive) 与传统数据库（MySql,PostgreSQL）间的数据传递。它可以将一个关系数据库中数据导入Hadoop的HDFS中， 也可以将HDFS中的数据导入关系型数据库中。 Flume： 实时数据采集的一个开源框架，它是Cloudera提供的一个高可用用的、高可靠、分布式的海量日志采集、聚合和传输的系统。目前已经是Apache的顶级子项目。使用Flume可以收集诸如日志、时间等数据 并将这些数据集中存储起来供下游使用（尤其是数据流框架，例如Storm）。和Flume类似的另一个框架是Scribe（FaceBook开源的日志收集系统，它为日志的分布式收集、统一处理提供一个可扩展的、高容错的简单方案） 　Kafka： 通常来说Flume采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲

1. 简介 是一个分布式, 高容错的 实时计算框架 Storm进程常驻内存, 永久运行 Storm数据不经过磁盘, 在内存中流转, 通过网络直接发送给下游 流式处理(streaming) 与 批处理(batch) 批处理(batch): MapReduce 微批处理(MircroBatch): Spark (性能上近似 Streaming, 但是还是有所不及) 流(streaming): Storm, Flink(其实Flink也可以做批处理) Storm MapReduce 流式处理 批处理 毫秒级 分钟级 DAG模型 Map+Reduce模型 常驻运行 反复启停 Storm 计算模型 Topology - DAG 有向无环图 例图: (Spout: 喷嘴) 对Storm实时计算逻辑进行封装 由一系列通过数据流相互关联的Spout、Bolt锁组成的拓扑结构 生命周期: 此拓扑只要启动就会一直在集群中运行, 直到手动将其kill, 否则不会终止 (与MapReduce中的Job的区别: MR中的Job在计算机执行完成就会终止) Tuple - 元组 Stream中最小的数据组成单元(熟悉python的一定不会陌生) Stream - 数据流 从Spout 中源源不断传递数据给Bolt、以及上一个Bolt传递数据给下一个Bolt, 所形成的的数据通道为Stream

1. 前言 计算机的基本工作就是处理数据，包括磁盘文件中的数据，通过网络传输的数据流或数据包，数据库中的结构化数据等。随着互联网、物联网等技术得到越来越广泛的应用，数据规模不断增加，TB、PB量级成为常态，对数据的处理已无法由单台计算机完成，而只能由多台机器共同承担计算任务。而在分布式环境中进行大数据处理，除了与存储系统打交道外，还涉及计算任务的分工，计算负荷的分配，计算机之间的数据迁移等工作，并且要考虑计算机或网络发生故障时的 数据安全 ，情况要复杂得多。 举一个简单的例子，假设我们要从销售记录中统计各种商品销售额。在单机环境中，我们只需把销售记录扫描一遍，对各商品的销售额进行累加即可。如果销售记录存放在关系数据库中，则更省事，执行一个SQL语句就可以了。现在假定销售记录实在太多，需要设计出由多台计算机来统计销售额的方案。为保证计算的正确、可靠、高效及方便，这个方案需要考虑下列问题： 如何为每台机器分配任务，是先按商品种类对销售记录分组，不同机器处理不同商品种类的销售记录，还是随机向各台机器分发一部分销售记录进行统计，最后把各台机器的统计结果按商品种类合并？ 上述两种方式都涉及数据的排序问题，应选择哪种排序算法？应该在哪台机器上执行排序过程？ 如何定义每台机器处理的数据从哪里来，处理结果到哪里去？数据是主动发送，还是接收方申请时才发送？如果是主动发送，接收方处理不过来怎么办

基本概念的解析 对于Storm，有一个相对比较重要的概念就是 "Guarantee no data loss" -- 可靠性 很明显,要做到这个特性，必须要tracker 每一个data的去向和结果，Storm是如何做到的 -》 那就是我们接下来要说的 Ack er 机制，先概括下Acker所参与的工作流程 1 Spout 创建一个新的Tuple时候，会发射一个消息通知acker去跟踪； 2 Bolt 在处理Tuple成功或者失败的时候，也会发送一个消息通知Acker 3 Acker会好到发射该Tuple的Spout，回掉其Ack ，fail方法 一个tuple被完全处理的意思是： 这个tuple以及由这个tuple后续所导致的所有tuple 都被成功的处理， 而一个tuple会被认为处理失败了，如果这个 消息在timeout所指定的时间内没有成功处理 也就是说对于任何一个Spout-tuple以及它的子孙，到底处理成功失败与否，我们都会得到通知 由一个tuple产生一个新的tuple称为：anchoring，你发射一个tuple的同时也就完成了一次 anchoring Storm 里面有一类特殊的task称为：acker，请注意，Acker也是属于一种task，如果您对Task还不够熟悉，请参考另外的一篇文档：有关Storm-executor-task的关系