文 / 洪小坚 整理 / LiveVideoStack 大家好，今天分享的主题是可编程的流式计算框架。大家可能都比较关心音视频领域，我们YoMo面对的场景比较偏向工业、IoT等领域。 熹乐科技专注于工业互联网和边缘计算，打造了YoMo开源计算框架和YCloud云服务。我们从2015年开始将人工智能技术应用于工业制造领域，例如计算机视觉对于地板的质量检测。 回过头看看目前业内一些主流的技术，说到实时流式计算就会联想到像Flink这种、消息队列会想到Kafka。 gRPC是一个很主流的微服务RPC框架。gRPC for IoT就是希望在边缘端可以实现全链路的QUIC Transport。 针对这样的场景，我们做了Geo-Distributed的分布式解决方案，将传统的中心化架构拆分成多个靠近用户的边缘节点。 最后一个案例是分布式的爬虫。我们服务了一个海外提供物流查询的SaaS公司。
Storm 第一章 是什么 一 介绍 二 拓扑流程 流式处理 实时处理 三 性能对比 Storm 与MapReduce的关系 Storm 与 Spark Streaming 的关系 四 计算模型 第六章 Flume-Kafka-Storm整合案例实现 一 架构设计 二 过程描述 三 具体步骤 四 项目应用架构 第一章 是什么 一 介绍 Storm是Twitter开源的分布式实时大数据处理框架 流式处理 流式处理（异步 与 同步） 客户端提交数据进行结算，并不会等待数据计算结果 逐条处理 例：ETL（数据清洗）extracted transform load 统计分析 例： MapReduce：为TB、PB级别数据设计的批处理计算框架。 ? 例如，在计算全局计数时，计算分为两个部分： 计算批次的部分计数 使用部分计数更新数据库中的全局计数 ＃2的计算需要在批之间进行严格排序，但是没有理由您不应该通过为多个批并行计算＃1 来流水线化批的计算。
Vite学习指南，基于腾讯云Webify部署项目。
所谓实时流计算，就是近几年由于数据得到广泛应用之后，在数据持久性建模不满足现状的情况下，急需数据流的瞬时建模或者计算处理。 但是，这些数据以大量、快速、时变（可能是不可预知）的数据流持续到达，由此产生了一些基础性的新的研究问题——实时计算。实时计算的一个重要方向就是实时流计算。 基本原理： Spark Streaming：构建在Spark上处理Stream数据的框架，基本的原理是将Stream数据分成小的时间片断（几秒），以类似batch批量处理的方式来处理这小部分数据 Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+），虽然比不上专门的流式数据处理软件，也可以用于实时计算，另一方面相比基于Record的其它处理框架 实时计算处理流程 互联网上海量数据（一般为日志流）的实时计算过程可以划分为 3 个阶段: 数据的产生与收集阶段、传输与分析处理阶段、存储对对外提供服务阶段。 ?
storm jar topologyDemo.jar com.baxiang.topologyTest topologyDemo 核心概念 Topologies 计算拓扑,由spout和bolt组成的 Streams 消息流，抽象概念，没有边界的tuple构成 Spouts 消息流的源头，Topology的消息生产者 Bolts 消息处理单元，可以做过滤、聚合、查询、写数据库的操作 Tuple spout发出去的tuple的DAG ack/fail tuple:message id ack/fail/nextTuple是在同一个线程中执行的，所以不需要要考虑线程安全方面 核心方法 初始化方式
为了满足美团业务方的超大规模图计算需求，需要选出一款图计算框架，作为图计算平台的底层引擎。 分布式架构，具备良好的可扩展性。 能够服务 OLAP 场景，高性能产出图分析结果。 通用的图计算系统，能提供多种流行的图算法，且能方便地定制开发新算法，以应对多种业务应用场景。 经过广泛的调研后，我们列举一些有代表性的图计算框架如下： Neo4j-APOC ：在图数据库的基础上，支持一些基本图算法，分布式版本不开源。 KnightKing：针对 Walker 游走类算法专门设计的图计算框架，不具有通用性。 GraphX：Apache 基金会基于 Spark 实现的图计算框架，社区活跃度较高。 Plato 的块式切分、双引擎通信模式、优化的底层存储结构设计使其不论执行效率还是内存开销都远优于另外两个框架，能高效地完成对大数据集的算法执行。
MapReduce优点在于可以将海量的数据进行离线处理，并且MapReduce也易于开发，因为MapReduce框架帮我们封装好了分布式计算的开发。而且对硬件设施要求不高，可以运行在廉价的机器上。 MapReduce也有缺点，它最主要的缺点就是无法完成实时流式计算，只能离线处理。 MapReduce属于一种编程模型，用于大规模数据集（大于1TB）的并行运算。 ：HDFS伪分布式环境搭建 以及 分布式资源调度——YARN框架 ---- 从WordCount案例说起MapReduce编程模型 在安装Hadoop时，它就自带有一个WordCount的案例，这个案例是统计文件中每个单词出现的次数 不仅架构变了，功能也变了，2.x之后新引入了YARN，在YARN之上我们可以运行不同的计算框架，不再是1.x那样只能运行MapReduce了： ? 关于MapReduce2.x的架构之前已经在分布式资源调度——YARN框架一文中说明过了，这里就不再赘述了。
概述 源自2014年12月的Google发表的MapReduce论文，它是一个编程模型，用于大数据量的计算，MapReduce是分布式计算框架。具有海量数据离线处理。 对于大数据量的计算，通常采用的处理方式就是并行计算，MapReduce就是一种简化并行计算的编程模型，它使得并没有并行计算经验的开发人员也可以计算并行应用程序 设计目标 MapReduce采用的是分而治之的思想 ，即把大规模数据集的操作，分发给一个主节点管理下的各个子节点共同完成，然后整合各个子节点的中间结果，从而得到最终的计算结果。 用户只需要编写map()和reduce两个函数，即可完成简单的分布式程序的设计 map()函数以key/value对作为输入，产生另外一系列key/value对作为中间输出写入本地磁盘，MapReduc 框架会自动将这些中间数据按照key值进行聚集，且key值相同（用户可设定聚集策略，默认情况下是对key值进行哈希取模）的数据被统一交给reduce()函数处理。
分布式计算框架MapReduce 什么是MapReduce？ 它是一个面向批处理的分布式计算框架；在分布式环境中，MapReduce程序被分为Map（映射）阶段和Reduce（化简）阶段。 它的第一个核心思想，移动计算而非移动数据。 各个节点的计算任务，因为使用的是部分数据，所以计算得到的结果，一定是部分结果；那就需要对这些部分结果进行汇总，这个汇总阶段称为Reduce。 整个的运算流程，是拆分到不同节点进行的，所以这也是它第二个核心思想的体现：分而治之，并行计算。 基本特点 首先作为分布式的计算框架，和其它大数据组件一样，拥有良好的扩展性和高容错的特性。 其次，计算跟着数据走，这是大数据计算引擎常见的设计方式
当然了，远程操作涉及网络和磁盘IO，有一定代价，所以计算框架会尝试优先处理本地存储的数据。但是在“degraded”场景下，推测执行可以有效缓解性能下降问题，这在MPP中是完全不可能的。 下图是对云计算中推测执行的一个调研结果 ? 这张图片测试的是wordcount，可以看出，推测执行可以在云环境下提升2.5倍的性能，而云环境则是以解决“straggler”问题得名。 这是因为HDFS对同一block默认有三个副本，这样计算框架可以在至少3个节点上启动任务处理本地数据，而不存在需要通过网络读取远程数据的情况发生. 不管查询是大是小，都是按照MPP的方式完成的，即一个进程只能处理本地数据，并且中间结果不写磁盘。但是虚拟segment则可以让executor在任何节点执行。 在两个stage之间，实时的把数据从一个executor传递到另外一个（独立的查询依然是MPP的流程，而不是批处理的流程），所以不需要把中间结果写磁盘，这样查询速度就会非常接近MPP系统。
从spark 说起，谈谈“流式”计算的理解 spark是一个大数据分布式的计算框架，有一些并行计算的基础会更容易理解分布式计算框架的概念。 此时，还需要提供资源管理的应用，包括计算资源和内存资源的。 我们采用YARN作为spark资源管理系统，Mesos是另一个资源管理框架。 ? 如果数据源比较大，有几十亿条，用MySQL做数据分析，可能要一天的时间，spark可能几十分钟就能给出结果（因为采用分布式计算，分布式数据集）。 传统的web服务，属于online业务。 Spark streaming 解决秒级响应，即流式计算 spark streaming 将spark 批处理应用，缩小为一个微批micro batch，把microbatch作为一个计算单元。 ? 总结 本文是关于spark streaming流式计算理解的介绍文章。 希望读者能通过10分钟的阅读，理解spark streaming 及流式计算的原理。
背景 Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。 进行了一系列实验测试 Flink 框架的性能，计算 Flink 作为确保“至少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框架选择、性能调优等决策及 Flink 平台的建设提出建议并提供数据支持 因此，我们测试了在不同消息投递语义下两个框架的性能，希望为精确计算场景的资源规划提供数据参考。 框架参数 ? 测试方法 测试流程 ? 参考内容 分布式流处理框架——功能对比和性能评估. intel-hadoop/HiBench: HiBench is a big data benchmark suite.
数据时代，从数据中获取业务需要的信息才能创造价值，这类工作就需要计算框架来完成。传统的数据处理流程中，总是先收集数据，然后将数据放到DB中。 常用的离线计算框架包括有： Hadoop，适用于离线大批量数据处理，不需要多次迭代。 Spark，适用于离线快速的处理，不能用于处理需要长期保存的数据；适用于多次迭代的计算模型。 Storm Storm是一个分布式的、容错的实时计算系统，做作为最早的一个实时计算框架，早期应用于各大互联网公司。 ，所以出现了Lambda架构，同时运行两个系统：一个流式，一个批量，用批量计算的精确性来弥补流式计算的不足，但是这个架构存在一个问题就是需要同时维护两套系统，代价比较大。 就框架本身与应用场景来说，Flink 更相似与 Storm。 ?
背景 Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。 ，进行了一系列实验测试 Flink 框架的性能，计算 Flink 作为确保“至少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框架选择、性能调优等决策及 Flink 检查点机制 ：通过分布式一致性快照机制，对数据流和算子状态进行保存。在发生错误时，使系统能够进行回滚。 因此，我们测试了在不同消息投递语义下两个框架的性能，希望为精确计算场景的资源规划提供数据参考。 参考内容 分布式流处理框架——功能对比和性能评估： intel-hadoop/HiBench: HiBench is a big data benchmark suite.
背景 Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。 为深入熟悉了解 Flink 框架，验证其稳定性和可靠性，评估其实时处理性能，识别该体系中的缺点，找到其性能瓶颈并进行优化，给用户提供最适合的实时计算引擎，我们以实践经验丰富的 Storm 框架作为对照， 进行了一系列实验测试 Flink 框架的性能，计算 Flink 作为确保“至少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框架选择、性能调优等决策及 Flink 平台的建设提出建议并提供数据支持 因此，我们测试了在不同消息投递语义下两个框架的性能，希望为精确计算场景的资源规划提供数据参考。 框架参数 ? 测试方法 测试流程 ?
在Spark框架当中，提起流计算，那么主要就是Spark Streaming组件来负责。 在大数据的发展历程当中，流计算正在成为越来越受到重视的趋势，而Spark Streaming流计算也在基于实际需求不断调整。今天的大数据学习分享，我们就主要来讲讲Spark 实时流计算。 Spark的Spark Streaming是早期的流计算框代表，同时还有Storm，也是针对于流计算，但是随着技术发展的趋势，Storm被逐渐抛弃。 Spark Streaming Spark Streaming，本质上来说，是一个基于批的流式计算框架，支持Kafka、Flume及简单的TCP套接字等多种数据输入源，输入流接收器（Reciever）负责接入数据 关于大数据学习，Spark生态实时流计算，以上就为大家做了简单的介绍了。流计算正在成为大数据技术越来越普及的趋势，而基于Spark生态的流计算一直提供着重要的技术支持。
Storm带着流式计算的标签华丽丽滴出场了，看看它的一些卖点： 分布式系统：可横向拓展,现在的项目不带个分布式特性都不好意思开源。 运维简单：Storm的部署的确简单。 无数据丢失：Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能够满足很多级别的数据处理需求。不过，越高的数据处理需求，性能下降越严重。 认 识 Storm是一个免费开源、分布式、高容错的实时计算系统。Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。 Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm的部署管理非常简单，而且，在同类的流式计算工具，Storm的性能也是非常出众的。 Spark Streaming：作为UC Berkeley云计算software stack的一部分，Spark Streaming是建立在Spark上的应用框架，利用Spark的底层框架作为其执行基础
许多分布式计算系统都可以实时或接近实时地处理大数据流。本文将对三种Apache框架分别进行简单介绍，然后尝试快速、高度概述其异同。 一个拓扑中包括spout和bolt两种角色，其中spout发送消息，负责将数据流以tuple元组的形式发送出去；而bolt则负责转换这些数据流，在bolt中可以完成计算、过滤等操作，bolt自身也可以随机将数据发送给其他 共同之处 以上三种实时计算系统都是开源的分布式系统，具有低延迟、可扩展和容错性诸多优点，它们的共同特色在于：允许你在运行数据流代码时，将任务分配到一系列具有容错能力的计算机上并行运行。 三种框架的术语名词不同，但是其代表的概念十分相似： 对比图 下面表格总结了一些不同之处： 数据传递形式分为三大类： 1. 如果你想要的是一个允许增量计算的高速事件处理系统，Storm会是最佳选择。它可以应对你在客户端等待结果的同时，进一步进行分布式计算的需求，使用开箱即用的分布式RPC（DRPC）就可以了。
Gearman提供了一个通用的应用程序框架，用于将工作转移到更适合于工作的其他机器或流程。它允许你并行工作，负载平衡处理，并在语言间调用函数。它可用于从高可用性网站到传输数据库复制事件的各种应用程序。 灵活 - 您不受限于任何特定的设计模式。您可以使用您选择的任何模型快速组合分布式应用程序，这些选项之一是Map / Reduce。 分布式 gearman是分布式的任务分发框架，worker与job server，client与job server通信基于tcp的socket连接。 而且memcached应该为两个相互独立实例，防止其上述的gearman框架中的问题。 邮件短信发送 异步log 跨语言相互调用（对于密集型计算的需求，可以用C实现，PHP直接调用） 其他耗时脚本 Gearman安装（unbuntu） 下载 $>wget https:
流计算 Oceanus 是基于Flink构建的云上全托管的实时计算服务。您无须关注基础设施运维，通过云端一站式开发环境，轻松构建点击流分析、电商精准推荐、金融风控、物联网 IoT 等应用。
扫码关注云+社区
领取腾讯云代金券
云服务器
测试服务 WeTest
文件存储
命令行工具
SSL 证书