第十一讲流计算图计算选编.ppt

图计算;?什么是流计算 ?流计算处理流程 ?流计算应用实例 ?流计算框架–Twitter Storm ?流计算框架汇总 ?参考资料; 大数据时代数据处理及业务的变化 ?初期：数据量小，业务简单 –少量人力、服务器就可以满足需求 ?过渡期：数据量有所膨胀，业务较复杂 –需要增加大量服务器以支撑业务 ?大数据时期：数据量急剧膨胀，业务很复杂 –传统方案扛不住，简单的增加服务器已不能满足需求 挑战 ?数据量膨胀所带来的质变 ?个性化、实时化的需求 ?…;流计算来自于一个信念： 数据的价值随着时间的流逝而降低，所以事件出现后必须尽快地对它们进行处理，最好数据出现时便立刻对其进行处理，发生一个事件进行一次处理，而不是缓存起来成一批再处理。 流计算的概念： ?流计算是针对流式数据的实时计算。 ?流式数据（流数据）：是指将数据看作数据流的形式来处理。数据流是在时间分布和数量上无限的一系列动态数据集合体；数据记录是数据流的最小组成单元。 ?流数据具有数据实时持续不断到达、到达次序独立、数据来源众多格式复杂、数据规模大且不十分关注存储、注重数据的整体价值而不关注个别数据等特点。;流计算应用场景 ?流计算是针对流数据的实时计算，其主要应用在于产生大量流数据、同时对实时性要求高的领域。 ?流计算一方面可应用于处理金融服务如股票交易、银行交易等产生的大量实时数据。 ?另一方面流计算主要应用于各种实时Web服务中，如搜索引擎、购物网站的实时广告推荐，SNS社交类网站的实时个性化内容推荐，大型网站、网店的实时用户访问情况分析等。;流计算：对流数据实时分析，从而获取有价值的实时信息;主要区别有如下几个方面： ?流中的数据元素在线到达； ?系统无法控制将要处理的新到达的数据元素的顺序； ?数据流的潜在大小也许是无穷无尽的； ?一旦数据流中的某个元素经过处理，要么被丢弃，要么被归档存储。因此，除非该数据被直接存储在内存中，否则将不容易被检索。相对于数据流的大小，这是一种典型的极小相关。;对于一个流计算系统来说，它应达到如下需求： ?高性能：处理大数据的基本要求，如每秒处理几十万条数据。 ?海量式：支持TB级甚至是PB级的数据规模。 ?实时性：必须保证一个较低的延迟时间，达到秒级别，甚至是毫秒级别。 ?分布式：支持大数据的基本架构，必须能够平滑扩展。 ?易用性：能够快速进行开发和部署。 ?可靠性：能可靠地处理流数据。 ?针对不同的应用场景，相应的流计算系统会有不同的需求，但是，针对海量数据的流计算，无论在数据采集、数据处理中都应达到秒级别的要求。;?Hadoop的批量化处理是人们喜爱它的地方，但这在某些领域仍显不足，尤其是在例如移动、Web客户端或金融、网页广告等需要实时计算的领域。这些领域产生的数据量极大，没有足够的存储空间来存储每个业务收到的数据。而流计算则可以实时对数据进行分析，并决定是否抛弃无用的数据，而这无需经过Map/Reduce的环节。 ?MapReduce框架为批处理做了高度优化，系统典型地通过调度批量任务来操作静态数据，任务不是常驻服务，数据也不是实时流入；而数据流计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配。数据流实时处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。;基于MapReduce的业务不得不面对处理延迟的问题。有一种想法是将基于MapReduce的批量处理转为小批量处理，将输入数据切成小的片段，每隔一个周期就启动一次MapReduce作业，这种实现需要减少每个片段的延迟，并且需要考虑系统的复杂度： 将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段是会降低延迟，但是，也增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优化的分段大小取决于具体应用。 为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是reduce直接输出；考虑到效率，中间结果最好只保存在内存中等等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。 用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。;传统数据处理流程示意图;?流计算一般有三个处理流程：数据实时采集、数据实时计算、实时查询服务。;阶段一：数据实时采集 为流计算提供实时数据，要保证实时性、低延迟、稳定可靠。 许多开源分布式日志收集