IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签：Stream Processing

共 4 篇相关文章

IT 累计浏览 1,375

Yahoo的流计算引擎基准测试

这篇来自雅虎工程博客的文章，对他们团队开源的流计算基准测试（streaming-benchmarks）进行了详细解读。测试背景是雅虎生产环境中大规模使用Storm，但面对Flink、Spark Streaming等新兴框架的竞争，需要一份更贴近真实世界场景的性能对比报告。 基准测试设计了一个典型用例：从Kafka读取JSON事件，处理后写入Redis时间窗口计数。核心对比聚焦于三大主流引擎：Apache Storm、Apache Flink 和 Apache Spark Streaming。 测试的关键结论非常明确：Storm 0.10.0 和 Flink 0.10.1 均展现出亚秒级的低延迟特性，其中Storm在99%的百分位数上取得了最低的延迟表现，体现了其在实时性上的传统优势。Flink在保持低延迟的同时，也提供了较高的吞吐量。相比之下，Spark Streaming 1.5.1 能够支持很高的吞吐量，但代价是其端到端延迟明显高于前两者。 文章也坦诚地指出，早期版本的Flink基准测试代码存在一个调试残留问题，这提醒读者在参考任何性能数据时，都需要关注其测试条件与代码版本的严谨性。整个测试的价值在于，它并非空谈理论，而是基于一个与雅虎内部使用场景高度相似的开源基准，为不同流处理技术在延迟与吞吐量这对核心指标上的权衡，提供了直接的参考依据。

IT 累计浏览 7,464

Storm：最火的流式处理框架

这篇讲的是Storm这个实时流处理框架为何能走红，以及它到底能解决什么问题。作者从Hadoop批处理延迟大的痛点切入，引出了Storm诞生的背景——专为低延迟的实时计算而生。文章拆解了Storm的核心卖点：它是一个分布式、高容错的系统，通过Topology（由Spout和Bolt构成）来处理数据流，并依赖Zookeeper进行状态管理，部署和横向扩展都相对简单。 摘要还梳理了Storm的实际应用情况，比如被淘宝、百度、Twitter等大公司用于实时用户画像分析或网站性能监控，以及它如何在迭代中加入Trident等新特性来解决重复计数等实际问题。最后，文章将Storm与Spark Streaming、HStreaming等竞争对手做了简单对比，并指出Storm虽然不是一个“开箱即用”的完整方案，但一旦解决好消息队列和状态管理等前置问题，其简单可扩展的架构优势就会显现出来。

IT 累计浏览 4,242

Storm入门教程 第二章 构建Topology

这篇讲的是Storm分布式计算框架的核心概念与Topology构建入门。文章从集群架构切入，清晰地对比了Storm与Hadoop的关键区别：Hadoop运行MapReduce作业会结束，而Storm的Topology一旦部署将持续运行。接着，它系统梳理了构成Storm处理逻辑的核心组件，包括作为数据生产者的Spout、执行具体业务逻辑的Bolt，以及定义数据流向与分发规则的Stream Grouping，并详细解释了Shuffle、Fields等七种分组模式的应用场景。 文章的重点在于演示如何将概念付诸实践。它通过一个经典的单词频率统计案例，手把手地展示了构建一个简单Topology的全过程：从设计数据流（KestrelSpout -> SplitSentence -> WordCount）开始，到代码实现与部署。这个过程不仅让读者理解Topology由Spout和Bolt通过流分组连接而成的本质，也直观呈现了Storm如何将一个分布式实时计算任务拆解并运行在多个工作进程上。对于刚接触流式计算的开发者，这是一种从抽象概念到具体实现的有效学习路径。

IT 累计浏览 2,605

即时流式数据 MapReduce

作者从传统 MapReduce（如 Hadoop）的批处理模式出发，指出了其固有的延迟问题：任务需要等待数据收集完毕后才能提交和执行。而现实中的某些统计场景要求“即时性”——数据一旦产生，就必须立刻被处理，并将结果实时推送给接收者。 为了解决这个背景问题，文章介绍了“即时流式数据 MapReduce”的方案。其核心在于将静态的批处理任务转变为一个持续运行的统计任务，实现了“数据驱动”的处理范式：新数据不再是等待被收集的“原料”，而是作为事件被“推送”到任务中进行实时计算。 这种架构改变了结果交付的方式，从传统的“拉取”模式变为结果的主动“推送”。它特别适合那些对数据新鲜度要求极高的业务场景，例如实时监控、动态仪表盘或即时推荐系统，能够为决策提供近实时的数据支持，避免了因批处理延迟而造成的业务滞后。