精华内容
下载资源
问答
  • 流计算产品预研

    千次阅读 2017-11-19 15:39:58
    国内各大云平台现有流计算产品预研

    国内各大云平台现有流计算产品预研

    阿里云

      Alibaba Cloud StreamCompute(阿里云流计算)是运行在阿里云平台上的流式大数据分析平台,提供给用户在云上进行流式数据实时化分析工具。使用阿里云StreamSQL,用户可以轻松搭建自己的流式数据分析和计算服务,彻底规避掉底层流式处理逻辑的繁杂重复开发工作,属于阿里云的大数据基础服务,目前正在公测中。

    产品特点

    • 开发门槛低

        无需用户在流计算框架上进行代码编程以及相关工作,提供了SQL语义的流式数据分析能力(StreamSQL)降低使用门槛

    • 性能优越、功能强大

        关键性能指标超越Storm的6到8倍,数据计算延迟优化到秒级乃至亚秒级,单个作业吞吐量可达百万(记录/秒)级别,单集群规模在数千台;实现exactly once语义

    • 全链路生态

        阿里云提供了全链路流计算开发平台,涵盖从数据采集到数据生产的各个环节,深度整合各类云数据存储,包括DataHub、日志服务(SLS)、RDS、OTS、ADS、IOTHub等各类数据存储系统,无需额外的数据集成工作,阿里云流计算可以直接读写上述产品数据

    • 运维监控快捷简单

        阿里云流计算是完全托管的流式计算引擎,用户隔离、一键式启用、天然集成了数据开发、数据运维、监控预警等服务

    产品定位

    阿里云流计算提供类标准的StreamSQL语义协助用户简单轻松的完成流式计算逻辑的处理。同时,受限于SQL代码功能有限,无法满足某些特定场景的业务需求,阿里云流计算同时为部分授信用户提供全功能的UDF函数。用户使用StreamSQL+UDF可完成大部分流式数据处理分析逻辑,目前流计算更擅长于做流式数据分析、统计、处理,对于非SQL能够解决的领域,例如复杂的迭代数据处理、复杂的规则引擎告警则不适合用现有的流计算产品去解决。

    目前流计算擅长解决的几个领域的应用场景:

    • 实时网络点击PV、UV统计
    • 统计交通卡口的平均5分钟通过车流量
    • 水利大坝的压力数据统计和展现
    • 网络支付涉及金融盗窃固定行为规则的告警

    曾经阿里云流计算对接,但发现无法满足的情况:

    • Oracle存储过程用阿里云流计算替换
    • 现有的Spark作业无缝迁移到流计算
    • 多种复杂规则引擎告警

    最适用于简单编写流计算SQL即可完成自身流式数据分析业务的场景

    全链路计算

      不同于现有的离线/批量计算模型(和批量计算差异性在下一小节细述),流计算全链路整体上更加强调数据的实时性,包括数据实时采集、数据实时计算、数据实时集成。三大类数据的实时处理逻辑在全链路上保证了流式计算的低时延。全链路流计算示意图如下:


    这里写图片描述

    • 数据采集 用户使用流式数据采集工具将数据流式且实时地采集并传输到大数据消息Pub/Sub系统,该系统将为下游流计算提供源源不断的事件源去触发流式计算作业的运行。

    • 流式计算 流数据作为流计算的触发源驱动流计算运行。因此,一个流计算作业必须至少使用一个流数据作为源。一批进入的数据流将直接触发下游流计算的一次流式计算处理。

    • 数据集成 流计算将计算的结果数据直接写入目的数据存储,这其中包括多种数据存储,包括数据存储系统、消息投递系统,甚至直接对接业务规则告警系统发出告警信息。不同于批量计算(例如阿里云MaxCompute或者开源Hadoop),流计算天生自带数据集成模块,可以将结果数据直接写入到目的数据存储

    • 数据消费 流计算一旦将结果数据投递到目的数据源后,后续的数据消费从系统划分来说,和流计算已经完全解耦。用户可以使用数据存储系统访问数据,使用消息投递系统进行信息接收,或者直接使用告警系统进行告警。

    业务流程

    阿里云流计算全流程系统架构情况如下图所示。


    这里写图片描述

    1. 数据采集 广义的实时数据采集指: 用户使用流式数据采集工具将数据流式且实时地采集并传输到大数据Pub/Sub系统,该系统将为下游流计算提供源源不断的事件源去触发流式计算作业的运行。阿里云大数据生态中提供了诸多针对不同场景领域的流式数据Pub/Sub系统,阿里云流计算天然集成上图中诸多Pub/Sub系统,以方便用户可以轻松集成各类流式数据存储系统。例如用户可以直接使用流计算对接SLS的LogHub系统,以做到快速集成并使用 ECS 日志。

    2. 流式计算 流数据作为流计算的触发源驱动流计算运行。因此,一个流计算作业必须至少使用一个流数据作为数据源头。同时,对于一些业务较为复杂的场景,流计算还支持和静态数据存储进行关联查询。例如针对每条DataHub流式数据,流计算将根据流式数据的主键和RDS中数据进行关联查询(即join查询);同时,阿里云流计算还支持针对多条数据流进行关联操作,StreamSQL支持阿里集团量级的复杂业务也不在话下。

    3. 实时数据集成 为尽可能减少数据处理时延,同时减少数据链路复杂度。阿里云流计算将计算的结果数据可不经其他过程直接写入目的数据存储,从而最大程度降低全链路数据时延,保证数据加工的新鲜度。为了打通阿里云生态,阿里云流计算天然集成了OLTP(RDS产品线等)、NoSQL(OTS等)、OLAP(ADS等)、MessageQueue(DataHub、ONS等)、MassiveStorage(OSS、MaxCompute等)。

    4. 数据消费 流式计算的结果数据进入各类数据存储后,用户可以使用各类个性化的应用消费结果数据: 用户可以使用数据存储系统访问数据,使用消息投递系统进行信息接收,或者直接使用告警系统进行告警。

    附: 数据链路情况

    对于上图的数据链路,部分数据存储由于和流计算模型不能一一匹配,需要使用其他类型的流数据做中转,说明如下:

    • DataHub

        DataHub提供了多类数据(包括日志、数据库BinLog、IoT数据流等等)从其他数据存储上传到DataHub的工具、界面,以及和一些开源、商业软件的集成,参看《DataHub相关介绍文档》,即可获取丰富多样的数据采集工具。

    • 日志服务(LogService)

      LogService是针对日志类数据一站式服务,在阿里巴巴集团经历大量大数据场景锤炼而成。LogService提供了诸多的针对日志的采集、消费、投递、查询分析等功能。

    • 物联网套件(IoTHub)

        物联网套件是阿里云专门为物联网领域的开发人员推出的,其目的是帮助开发者搭建安全性能强大的数据通道,方便终端(如传感器、执行器、嵌入式设备或智能家电等等)和云端的双向通信。

        使用IotHub 规则引擎可以将IoT数据方便投递到DataHub,并利用流计算和MaxCompute进行数据加工计算。查看《IoT规则引擎使用》以查看如何将IoT数据推送到DataHub。

    • 数据传输(DTS)

        DTS支持以数据库为核心的结构化存储产品之间的数据传输。 它是一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服务。使用DTS的数据传输功能,可以方便的将RDS等BinLog解析并投递到DataHub,并利用流计算和MaxCompute进行数据加工计算。

    • Message Service

        阿里云消息服务阿里云商用的消息中间件服务,具有大规模,高可靠、高并发访问和超强消息堆积能力的特点。流计算可以直接从消息服务读取流式数据。阿里云流计算对接消息服务当前仍在开发中。

    • MQ

        阿里云MQ服务是企业级互联网架构的核心产品,基于高可用分布式集群技术,搭建了包括发布订阅、消息轨迹、资源统计、定时(延时)、监控报警等一套完整的消息云服务。阿里云流计算对接ONS服务当前仍在开发中。

    主要概念

    阿里云流计算处理的数据来自哪里?如何加载数据到流计算;流计算处理后的结果数据如何继续应用?

    阿里云流计算本身不带有业务存储,所有的数据均是来自于外部周边阿里云提供的存储系统持有的数据。目前阿里云支持几类数据存储类型:

    • 流式的数据输入: 为下游流式计算提供流式数据输入,是流计算进行数据处理的数据触发机制,推动流计算持续进行数据计算。每个流计算作业必须至少声明一个流式数据输入源。

    • 静态数据输入: 静态存储为流计算提供了数据关联查询,对于每条流式数据,可以关联外部一个静态数据源进行查询。因此,静态数据输入也被成为维表。

    • 结果表输出: 流计算将计算的结果数据写出到目的数据表,为下游数据继续消费提供各类读写接口。

    阿里云流计算支持哪几个流式数据输入?维表输入?结果表输出?

    目前支持流式输入表有:

    • 大数据总线(DataHub)

    • 日志服务(LogService)

    支持静态输入表有:

    • 表格存储(TableStore)

    • 云数据库(RDS)

    • 分布式数据库(DRDS)

    支持输出表有:

    • 大数据总线(DataHub)

    • 日志服务(LogService)

    • 消息服务(MessageService)

    • 分析型数据库(AnalyticDB)

    • 表格存储(TableStore)

    • 云数据库(RDS)

    • 分布式数据库(DRDS)

    阿里云流计算提供的编程接口是什么?如何编写流式数据处理逻辑?

    阿里云流计算提供StreamSQL编写业务逻辑,为流式数据分析定制多种数据处理函数和操作符。以Word Count统计为例,下面给出一个具体的SQL例子:

    -- 声明一个流式源表
    create stream table stream_source(word string) ;
    -- 声明一个目标表
    create result table stream_result(word string, cnt bigint) ;
    --统计word次数
    insert into stream_result select
       t.word
       ,count(1)
    from stream_source t
      group by t.word;
    

    单个阿里云流计算作业包含几个部分?

    一个静态的流计算作业目前分为几大类静态信息,包括:

    • 代码: SQL代码,用户编写的业务逻辑,流计算作业核心逻辑,其中包括 输入表DDL声明(分为流式输入表、静态输入表)、输出表DDL声明,以及执行业务逻辑的DML。

    • 参数: 参数用来描述作业运行时指标,例如并发量、批处理数据量等信息。

    • 属性: 作业的业务信息,例如创建人、创建时间等相关记录。

    我存放的数据不在上述支持的存储列表,如何处理?

    如果您所选择的阿里云存储产品不在我们系统支持范围之内,请提交工单告之我们。如果您使用了自建开源存储,需要您将您的数据转移到上述支持的列表存储中。您需要自己搭建相关的转换常驻程序完成上述转换逻辑,例如当前流计算流式数据源输入暂时还不支持阿里云消息服务,那么用户可以选择写应用程序将消息服务中的数据转换为DataHub,再交由流计算读取DataHub进行处理。

    华为云

      实时流计算服务(Cloud Stream Service,简称CS),是运行在华为云上的实时流式大数据分析服务,全托管的方式使用户无需感知计算集群,只需聚焦于Stream SQL业务,即时执行作业,完全兼容Apache Flink API。

      Cloud Stream实时流计算平台是华为公司在IT领域主推的低时延(ms级时延)、高吞吐、高可靠的分布式实时流计算服务。它以Flink为基础,加入华为沉淀的增强特性和安全增强,是一个批流合一的分布式计算服务,提供了数据处理所必须的丰富Stream SQL特性,后续还会支持在Stream SQL上增加机器学习和图计算相关算法的功能,适用于实时性要求高、吞吐量大的业务场景。

    特点和优势

    • 丰富的Stream SQL在线分析能力

        支持window、join等聚合函数,用SQL表达业务逻辑,简便快捷实现业务。

    • 分布式实时计算

        支持大规模集群计算,集群弹性伸缩,最大化节省成本。

    • 易用

        在SQL编辑平台写Stream SQL,Stream SQL定义数据流入、数据处理、数据流出,快速便捷实现业务逻辑,降低流数据分析门槛。

    • 全托管

        用户完全不感知计算集群,对运行的作业可视化查看运行状态。

    • 开箱即用

        不再关心各种大数据框架,写StreamSQL,即时运行作业。

    • 安全隔离

        租户三重安全机制保障,确保作业安全运行,且租户计算集群完全和其他租户物理隔离,独立的安防设置,确保计算集群的安全性。

    • 高吞吐低时延

        从DIS中读取数据,服务支持自然反压机制,支持高吞吐压力;毫秒级延迟,满足实时计算的业务场景。

    产品架构


    这里写图片描述

      在实时业务架构中,流计算服务使用DIS服务作为数据源,用户在流计算服务中提交StreamSQL作为数据处理逻辑,处理结果输出到持久化数据存储,以供下游业务使用。

    • Source数据源

        从DIS服务中读取数据

    • 流式计算

        提供Stream SQLFlink API两种能力,上手成本最低,使用简便

    • Sink数据输出

        分析的结果数据,实时写入DIS(数据接入服务)/ OBS(对象存储服务)等服务,以供下游业务使用

    应用场景

      Cloud Stream服务的使用,聚焦于互联网和物联网场景,适用于实时性要求高、吞吐量大的业务场景。主要应用在互联网行业中小企业/物联网/车联网/金融反欺诈等多种行业应用场景,如,互联网汽车、日志在线分析、在线机器学习、在线图计算、在线推荐算法应用等。

    • 实时流分析场景

        应用:实时大数据分析。

        场景特点:面向流数据,支持window、CEP、Join等复杂的流分析操作,毫秒级延迟。

        适用场景:在线分析,金融风控,交通流量分析,ETL,实时决策。

    • 物联网IOT场景

        应用:物联网在线数据分析。

        场景特点:物联网IoT直接调用Cloud Stream服务API,Cloud Stream可以实时读取传感器信息并执行用户的分析逻辑,分析结果对接到DIS、RDS等服务用于可视化、持久化、告警或报表展示。

        适用场景:电梯IoT、工业IoT、共享单车、互联网汽车和智能家居。

    上下游数据

    • 数据接入服务(DIS)

        数据接入服务(DIS)是Cloud Stream的数据源和作业输出数据的存储地。

      1. 数据源:DIS接入用户数据,Cloud Stream从DIS读取数据,作为作业的输入数据。
      2. 数据的存储地:Cloud Stream将作业的输出数据写入DIS。
      3. 对象存储服务(Object Storage Service)

    • 对象存储服务(OBS)

        可用作CloudStream的数据源和作业Checkpoint数据的备份地。

      1. 数据源:Cloud Stream支持从OBS上读取用户存储的数据,作为作业的输入数据。

      2. 作业Checkpoint数据的备份地:如果作业开启了Checkpoint功能,Cloud Stream支持将作业快照存储到OBS中,以便作业在出现异常时可以从Checkpoint(一致性检查点)恢复作业。

    • 关系型数据库(Relational Database Service)

        关系型数据库(RDS)用于存储Cloud Stream作业输出的结果数据。

    • 与统一身份认证服务的关系

        统一身份认证服务(Identity and Access Management,简称IAM)为Cloud Stream提供了鉴权功能。

    • 云审计服务(Cloud Trace Service)

        云审计服务(CTS)为用户提供Cloud Stream的操作记录,供用户查询、审计和回溯使用。

    注意:

      Cloud Stream支持从DIS上读取编码格式为csv或json格式的数据。

      Cloud Stream只支持从OBS上存放和读取csv格式的数据。

    代码实例

    创建作业并提交

    使用实时流计算服务,首先要创建一个作业,如“JobSample”。

    登录Cloud Stream管理控制台。

    在Cloud Stream管理控制台的左侧导航栏中,单击“作业管理”,进入“作业管理”页面。

    单击“新建”,弹出“新建作业”页面。

    输入“作业名称”和“作业描述”,例如:作业名称为“JobSample”,作业描述为“This is a job sample.”。

    在“作业模板”下拉框中,选择“默认”,使用系统默认的作业模板。

    单击“确定”,进入“作业编辑”页面,在SQL语句编辑区域中会显示“默认”作业模板的SQL语句。

    在SQL语句编辑区域中,根据作业的实际需要,编辑SQL语句。例如:

    /** 创建输入流,从DIS的dis-source-stream通道获取数据,数据编码格式为CSV,分隔符为逗号 **/
    create source stream stream_source (
      name STRING,
      v2 STRING,
      time LONG
    ) WITH (
      type = "dis",
      region = "cn-north-1",
      channel = "dis-source-stream",
      partitionCnt = "3",
      encode = "csv",
      fieldDelimiter = ","
    ) timestamp by proctime.proctime;
    
    /** 创建输出流,结果输出到DIS的dis-sink-stream1通道,若通道有多个partition,以name作为key 派发,输出格式为json,
        enableOutputnull为false表示当属性为null时,该属性不进行输出 **/
    create sink stream stream_sink (
      name STRING,
      v2 STRING
    ) WITH (
      type="dis",
      region="cn-north-1",
      channel = "dis-sink-stream1",
      partitionKey = "name",
      encode = "json",
      enableOutputnull = "false"
    );
    
    /** 创建输出流,结果输出到DIS的dis-sink-stream2通道,若通道有多个partition,以name作为key 派发,输出格式为csv **/
    create sink stream stream_sink2 (
      name STRING,
      cnt BIGINT
    ) WITH (
      type="dis",
      region="cn-north-1",
      channel = "dis-sink-stream2",
      partitionKey = "name",
      encode = "csv",
      fieldDelimiter = ","
    );
    
    /** 直接将入流 stream_source 输出到 stream_sink **/
    insert into stream_sink select name, v2 from stream_source;
    
    /** 计算从运行开始流进来的事件个数 **/
    insert into stream_sink2
    select name, count(v2) OVER (ORDER BY proctime RANGE UNBOUNDED preceding) as cnt1
    from stream_source;
    

    单击“语义校验”,确保语义校验成功。

    在“作业编辑”页面的右侧“运行参数设置”页签,使用默认运行参数即可。

    单击“保存”。

    单击“提交”,将作业发布线上。

    百度云

    无流计算产品

    腾讯云

    大数据处理套件TBDS

      腾讯大数据处理套件(Tencent Big Data Suite)是基于腾讯多年海量数据处理经验,对外提供的可靠、安全、易用的大数据处理平台。您可以按需部署大数据处理服务实现数据处理需求,例如报表展示,数据提取、分析,客户画像等大数据应用。该平台中集成了流式计算

    • 实时流处理计算

        灵活:支持 TStorm(用 Java 语言重写的 Storm 流处理引擎)、Storm 流式任务作业引擎,覆盖实时要求极高的流式作业场景;支持基于 Spark 上的 Spark Streaming,满足毫秒级的实时计算场景需求,如实时推荐、用户行为分析等。

    网易蜂巢

    无流计算产品

    总结

    1. 从国内各大厂家的云计算产品综合比较来看,流计算平台仍然处于起步阶段,相对来说最为成熟完善的阿里云流计算平台也是处于公测中,还有许多根本就没有流计算平台产品推出。

    2. 阿里云流计算平台技术最成熟、架构最为完善、业务场景丰富、用户相对较多

    3. 华为流计算平台与阿里云流计算平台在各方面都较为类似,但是华为的不够成熟、不够规范、架构脉络不清晰、相关资料较少、还处于起步阶段

    4. 腾讯云将流计算集成在大数据开发套件之中,相关资料太少,只知道底层引擎采用的是腾讯自己用java重写的TStrom,另外支持SparkStreaming

    5. 阿里云之前的流计算平台底层引擎采用的是阿里自己改写的Storm(JStorm),最新版本的话与华为一样,底层引擎都选用的是Flink,可见未来的流计算引擎的趋势应该是Flink

    展开全文
  • 阿里云StreamCompute流计算架构

    千次阅读 2019-06-20 17:48:11
    下图为阿里云流计算全流程系统架构,主要包含:数据采集,流数据,流计算,数据源,数据消费这些过程。 数据采集 用户可以使用流式数据采集工具将数据流式且实时地采集并传输到大数据Pub/Sub系统,该系统将...

    下图为阿里云流计算全流程系统架构,主要包含:数据采集,流数据,流计算,数据源,数据消费这些过程。

     

     

     

    •  数据采集 

    用户可以使用流式数据采集工具将数据流式且实时地采集并传输到大数据Pub/Sub系统,该系统将为下游流计算提供源源不断的事件源去触发流式计算作业的运行。

    阿里云大数据生态中提供了诸多针对不同场景领域的流式数据Pub/Sub系统,以方便用户可以集成各类流式数据存储系统。

     

    •  流数据

    流数据作为流计算的触发源驱动流计算运行

    一个流计算作业必须至少使用一个流数据作为数据源头。

    流数据的承载方式包括:DataHub,LogService,IOTHub,DTS,MQ等。其中针对XX的业务场景,DataHub流数据处理平台作为数据源头比较适合,但是数据写入DataHub私有云提供方目前无自动化的采集工具可以使用,需要开发力量额外编写Java代码进行写入

     

     

     

    • 流式计算 

    流式计算可将源头流数据实时计算处理。

    阿里云流计算支持针对多条数据流使用BlinkSQL进行关联操作。

    流式计算大部分计算逻辑均在StreamCompute流计算平台内编写统计、计算SQL完成,再之后以运维任务的方式启动并长期在线运行。

     

    • 结果数据集成至数据源

    为尽可能减少数据处理时延,同时减少数据链路复杂度。

    阿里云流计算将计算的结果数据可不经其他过程直接写入目的数据存储,从而最大程度降低全链路数据时延,保证数据加工的新鲜度。

    阿里云流计算集成了OLTP(RDS产品线等)、NoSQL(OTS等)、OLAP(ADS等)、MessageQueue(DataHub、ONS等)、MassiveStorage(OSS、MaxCompute等)。

    之前的测试中,我们使用ADS分析型数据库作为结果计算数据的存储。

     

    • 数据消费 

    流式计算的结果数据进入各类数据存储后,用户可以使用各类个性化的应用消费结果数据,也可以将计算结果用于数据展示系统。

    展开全文
  • 现今实时流计算模型

    千次阅读 2012-11-27 22:30:29
    近年来,一种新的数据密集型应用已经得到了广泛的认同,这类应用的特征是:数据不宜用持久稳定关系建模,而适宜用瞬态数据建模。这些应用的实例包括金融服务、网络监控、电信数据管理、Web应用、生产制造、传感...
    1.引言
    

    近年来,一种新的数据密集型应用已经得到了广泛的认同,这类应用的特征是:数据不宜用持久稳定关系建模,而适宜用瞬态数据流建模。这些应用的实例包括金融服务、网络监控、电信数据管理、Web应用、生产制造、传感检测等等。在这种数据流模型中,单独的数据单元可能是相关的元组(tuples),例如网络测量、呼叫记录、网页访问等产生的数据。但是,这些数据以大量、快速、时变(可能是不可预知)的数据流持续到达,由此产生了一些基础性的新的研究问题。

    数据流计算来自于一个信念:数据的价值随着时间的流逝而降低,所以事件出现后必须尽快地对它们进行处理,最好数据出现时便立刻对其进行处理,发生一个事件进行一次处理,而不是缓存起来成一批处理。例如商用搜索引擎,像Google、Bing和Yahoo !等,通常在用户查询响应中提供结构化的Web结果,同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告,通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询,每个页面都可能会包含多个广告。为了及时处理用户反馈,需要一个低延迟、可扩展、高可靠的处理引擎。

    对于这些实时性要求很高的应用,若把持续到达的数据简单地放到传统数据库管理系统(DBMS)中,并在其中进行操作,是不太切实的。传统的DBMS并不是为快速连续的存放单独的数据单元而设计的,而且也并不支持“持续处理”,而“持续处理”是数据流应用的典型特征。另外,现在人们都认识到,“近似性”和“自适应性”是对数据流进行快速查询和其他处理(如数据分析和数据采集)的关键要素,而传统DBMS的主要目标恰恰与之相反:通过稳定的查询设计,得到精确的答案。

    另外一些方案是采用MapReduce来进行实时数据流处理。但是,尽管MapReduce做了实时性改进,仍然很难稳定地满足应用需求。这是因为MapReduce(Hadoop)框架为批处理做了高度优化,系统典型地通过调度批量任务来操作静态数据,任务不是常驻服务,数据也不是实时流入;而数据流计算的典型范式之一是不确定数据速率的事件流流入系统,系统处理能力必须与事件流量匹配。

    最近Facebook在SIGMOD’ 2011上发表了利用Hbase/Hadoop进行实时处理数据的论文,通过一些实时性改造,让批处理计算平台也具备实时计算的能力。这类基于MapReduce流式处理的缺点有三:

    1)将输入数据分隔成固定大小的片段,再由MapReduce平台处理,缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟,增加附加开销,并且分段之间的依赖管理更加复杂(例如一个分段可能会需要前一个分段的信息);反之,大的分段会增加延迟。最优化的分段大小取决于具体应用。

    2)为了支持流式处理,MapReduce需要被改造成Pipeline的模式,而不是reduce直接输出;考虑到效率,中间结果最好只保存在内存中等等。这些改动使得原有的MapReduce框架的复杂度大大增加,不利于系统的维护和扩展。

    3)用户被迫使用MapReduce的接口来定义流式作业,这使得用户程序的可伸缩性降低。

    综上所述,流式处理的模式决定了要和批处理使用非常不同的架构,试图搭建一个既适合流式计算又适合批处理的通用平台,结果可能会是一个高度复杂的系统,并且最终系统可能对两种计算都不理想。

    2. 数据流模型

    在数据流模型中,需要处理的输入数据(全部或部分)并不存储在可随机访问的磁盘或内存中,但它们却以一个或多个“连续数据流”的形式到达。数据流不同于传统的存储关系模型,主要区别有如下几个方面:

        流中的数据元素在线到达;
        系统无法控制将要处理的新到达的数据元素的顺序,无论这些数据元素是在一个数据流中还是跨多个数据流;也即重放的数据流可能和上次数据流的元素顺序不一致;
        数据流的潜在大小也许是无穷无尽的;
        一旦数据流中的某个元素经过处理,要么被丢弃,要么被归档存储。因此,除非该数据被直接存储在内存中,否则将不容易被检索。相对于数据流的大小,这是一种典型的极小相关。

    数据流模型中的操作并不排除传统关系型数据的存在。通常,数据流操作将建立数据流和关系型数据的联系。在数据流处理过程中,更新存储关系的同时可能会产生传输处理问题。

    3. 百度现有数据流系统

    百度内部有很多独立的数据流计算系统,用来满足各产品线的业务需求。以下列举几个典型系统稍作分析。

        广告点击计费反作弊系统

    对于商务搜索部门来说,广告点击计费和网页检索反作弊是非常重要的两个方面。点击计费业务对时效性、高可靠和准确度的要求都非常高,目前由独立的数据流处理系统支撑业务。系统的每来一个元组就处理一次;为了保证业务处理的及时性,在关键处理环节上进行拆分,尽量并行处理;系统本身有容错支持,但非全局容错,只支持某些功能模块的双机互为热备,异常情况下仍然存在丢失少量数据的风险;另外,现有系统仅仅通过目前点击流量进行反作弊计费,而点击依赖的网页检索流量并没有流入系统,反作弊准确性方面还有提升空间。

        广告检索反作弊系统

    出于实时性和开发效率的权衡,许多实时系统都借助Hadoop来解决问题。相对而言,检索反作弊的时效性要求要低于点击,现有系统也是基于MapReduce框架实现的。MapReduce提供了容错机制,提供了Order By等机制,并保证了最多30分钟的执行时间,这些特性都支撑该系统的运行。不过,检索反作弊系统的设计初衷也是希望做到尽量实时,目前该系统的时效性受限于上游日志文件的生成时限,以及Hadoop平台执行时任务启动开销和执行时间的不稳定。

        统一日志统计平台

    LOG日志统计平台上运行着一些实时性作业,例如Columbus等,时效性是它们关注的重点。5分钟的统计作业目前在Hadoop实时集群执行,期望保证时效性。不过类似于检索反作弊系统,MapReduce作业的启动开销不可避免;另外,如果Hadoop集群某些机器出现问题,至少需要重新执行多个任务,也会影响作业的时效性;再者,如果统计作业发现数据出现问题,想从某个时间点重新计算,则可能会重复执行以前的大量计算。

        统一服务监控平台

    对诺亚监控系统而言,时效性和准确度也是其关心的问题,不过由于不涉及钱的问题,它相对要求低一些。诺亚的集群是人工配置的,存在宕机风险;如果流量增大,也需要人工修改配置;诺亚的大部分算子是Aggregator,涉及中间状态的保存,目前没有冗余备份机制,如果发生故障会导致结果不准。

        站点统计平台

    对福尔摩斯站点统计系统来说,已经基本做到了实时统计,但其现有架构仍然存在很多问题。例如不支持自动容错,不支持自动扩展,不能很好的保证线上服务的可用性和稳定性,系统扩容时往往会影响线上服务,运维人力成本高等;再者,福尔摩斯是个专用系统,许多业务逻辑和系统逻辑混合在一起,每每需要进行业务变更时,改动量很大,也不适合一些规则和业务的快速上线。

    综上所述,实现百度公司通用的数据流计算平台是非常必要、非常迫切的一件事情,有助于提升公司业务水平,节省维护成本和开发成本。

    4. 百度下一代数据流系统

    在百度基础架构部的下一代规划中,实时计算是重要的组成部分。图1从整个分析系统的架构角度,给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴,批处理计算可以是MapReduce、MPI等,实时计算可以是DStream等,批处理和实时都可以或不依赖统一的资源调度系统。另外,计算系统的输入、输出,包括中间过程的输入、输出,都与存储系统或者传输通道(Bigpipe)交互。计算系统的上层是 数据仓库,或者计算系统直接和用户交互,交互方式可以是SQL-like,或者是MR-like等。

    图2.jpg
    2012-8-31 10:39 上传
    下载附件(69.76 KB)


    (图 1 数据分析系统整体组成示意图)

    实时计算方向重要的一个模块就是实时数据流计算。如图2所示,百度下一代通用数据流计算系统DStream提供分布式的、高可靠的、高可用的、可伸缩的、可扩展的、易开发的流式计算服务,一般故障恢复时间在10s以内,极端故障恢复在5分钟内。DStream的Release 1.0版本将在2012年上半年发布。

    如图2所示,DStream包括Client、Processing Master(PM)、Processing Node(PN)三大组件,PN上有多个Processing Element(PE)实例执行。DStream依赖几个第三方系统,Bigpipe、Zookeeper和HDFS,分别用于数据流输入输出和操作日志的存储、分布式异常监控、用户文件存储和计算状态存储。

    图1.jpg
    2012-8-31 10:39 上传
    下载附件(61.12 KB)


    (图 2 数据流计算系统DStream结构示意图)

    5. 业界数据流项目

    近年来,业界出现了不少实时数据流计算系统,虽然没有一个类似于Hadoop的集大成者,但是也都各具特色,值得我们学习和研究。下面简单介绍几种业界典型的流式计算系统,包括Yahoo! S4、Twitter Storm、IBM StreamBase 及学术界开源的Borealis。

        S4

    Yahoo! S4(Simple Scalable Streaming System)是一个通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统。基于S4框架,开发者可以容易地开发面向持续流数据处理的应用。S4的最新版本是alpha version v0.3.0,最近刚成为Apache孵化项目,其设计特点有以下几个方面:

    1)Actor计算模型

    为了能在普通机型构成的集群上进行分布式处理,并且集群内部不使用共享内存,S4架构采用了Actor模式,这种模式提供了封装和地址透明语义,因此在允许应用大规模并发的同时,也提供了简单的编程接口。S4系统通过处理单元(Processing Elements,PEs)进行计算,消息在处理单元间以数据事件的形式传送,PE消费事件,发出一个或多个可能被其他PE处理的事件,或者直接发布结果。每个PE的状态对于其他PE不可见,PE之间唯一的交互模式就是发出事件和消费事件。框架提供了路由事件到合适的PE和创建新PE实例的功能。S4的设计模式符合封装和地址透明的特性。

    2)对等集群架构

    除了遵循Actor模式,S4也参照了MapReduce模式。为了简化部署和运维,从而达到更好地稳定性和扩展性,S4采用了对等架构,集群中的所有处理节点都是等同的,没有中心控制。这种架构将使得集群的扩展性很好,处理节点的总数理论上无上限;同时,S4将没有单点容错的问题。

    3)可插拔体系架构

    S4系统使用Java语言开发,采用了极富层次的模块化编程,每个通用功能点都尽量抽象出来作为通用模块,而且尽可能地让各模块实现可定制化。

    4)支持部分容错

    基于Zookeeper服务的集群管理层将会自动路由事件从失效节点到其他节点。除非显式保存到持久性存储,否则节点故障时,节点上处理事件的状态会丢失。

    5)支持面向对象

    节点间通信采用“plain old Java objects”(POJOs) 模式,应用开发者不需要写schemas 或用哈希表来在节点间发送tuples。

        Storm

    Storm是Twitter近期开源的实时数据流计算系统,它被托管在GitHub上,遵循 Eclipse Public License 1.0。GitHub上的最新版本是Storm 0.5.2,用Clojure函数式语言开发。Storm为分布式实时计算提供了一组通用原语,可被用于“流处理”之中,实时处理消息并更新数据库,这是管理队列及工作者集群的另一种方式。Storm的主要特点如下:

    1)简单的编程模型

    类似于MapReduce降低了并行批处理复杂性,Storm降低了进行实时处理的复杂性。

    2)支持各种编程语言

    可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持,只需实现一个简单的Storm通信协议即可。

    3)支持容错

    Storm会管理工作进程和节点的故障。

    4)支持水平扩展

    计算是在多个线程、进程和服务器之间并行进行的。

    5)可靠的消息处理

    Storm保证每个消息至少能得到一次完整处理。任务失败时,它会负责从消息源重试消息。

    6)高效消息处理

    系统的设计保证了消息能得到快速的处理,使用?MQ作为其底层消息队列。

        StreamBase

    StreamBase 是IBM开发的一款商业流式计算系统,在金融行业和政府部门使用,其本身是商业应用软件,但提供了develop edition。相对于付费使用的enterprise edition,前者的功能更少,但这并不妨碍我们从外部使用和API接口来对StreamBase本身分析。StreamBase的设计特点有以下几个方面:

    1)超便捷的应用接口

    StreamBase 使用Java语言开发,IDE是基于Eclipse来进行二次开发,功能非常强大。StreamBase也提供了相当多的operator、functor以及其他组件来帮助构建应用程序。用户只需要通过IDE拖拉控件,然后关联一下,设置好传输的schema并且设置一下控件计算过程,就可以编译出一个高效处理的流式应用程序了。同时,StreamBase还提供了类SQL语言来描述计算过程。

    2)支持异构流输入输出

    StreamBase通过Adapter组件支持异构数据流的输入和输出,数据源或者目的地可以是CSV文件、JDBC、JMS、Simulation(系统提供了流产生模拟器)等,也可以用户自行定制。

    3) 支持计算状态保存

    StreamBase通过QueryTable保存数据流的tuples,QueryTable支持内存表和磁盘表,对于磁盘表的话支持三种写模式:

    non-transaction模式,只写入并不做transaction。

    half-transaction模式,保证transaction,但flush时机并不确定。

    full-transaction模式,这种模式保证transaction,并且强制每次flush。

    4)支持多种容错方案

    StreamBase 提出了以下4种模板策略来解决容错问题:

    Hot-Hot Server Pair Template

    primary和secondary server都在同时计算,并且将计算结果交给下游。优点是primary server如果故障的话那么secondary server依然工作,几乎没有任何切换时间;并且下游只需要选取先到来的tuple就可以处理了,保证处理速度最快。缺点是浪费计算和网络资源。

    Hot-Warm Server Pair Template

    primary和secondary server都在同时计算,但只有primary server将计算结果交给下游。优点是如果primary server故障,secondary server可以很快切换,而不需要任何恢复状态的工作。相对于Hot-Hot方式时间稍微长一些,但没有Hot-Hot那么耗费网络资源,同时也浪费了计算资源。

    Shared Disk Template

    primary server在计算之后,将计算的一些中间关键状态存储到磁盘、SAN(Storage Area Network)或是可靠的存储介质。如果primary server故障, secondary server会从介质中读取出关键状态,然后接着继续计算。优点是没有浪费任何计算和网路资源,但是恢复时间依赖状态的量级而定,相对于前两种,恢复时间可能会稍长。

    Fast Restart Template

    这种方案限定了应用场景,只针对无状态的应用。对于无状态的情况,方案可以非常简单,只要发现primary server故障,secondary server立即启动,并接着上游的数据流继续计算即可。

        Borealis

    Borealis是Brandeis University、 Brown University和 MIT合作开发的分布式流式系统。Borealis系统是三所大学在之前的流式系统Aurora、Medusa演化而来。目前Borealis系统已经停止维护,最新的Release版本发布于2008年。

    Borealis具有丰富的论文、完整的用户/开发者文档,系统是C++实现的,运行于x86-based Linux平台。系统自身是开源的,同时使用了较多的第三方开源组件,包括用于查询语言翻译的ANTLR、C++的网络编程框架库NMSTL等。

    Borealis系统的流式模型和其他流式系统基本一致:接受多元的数据流和输出,为了容错,采用确定性计算,对于容错性要求高的系统,会对输入流使用算子进行定序。Borealis的设计特点有以下几个方面:

    1)可变集群架构

    Borealis集群的节点可以部署为对等架构,也可以设计一个协作节点来执行全局的系统监控和其他优化任务,比如全局的负载分布和global load shedding。Borealis实际上提供了完整的3级监控和优化(local,neighborhood,global)。

    2)支持多种负载均衡机制

    负载均衡方面,Borealis提供了动态和静态两种部署机制:

    Correlation-based operator distribution

    通过分析不同operators和nodes间的负载变化的关系,决定和动态调整operatpr的部署,使之达到负载均衡。

    Resilient operator distribution algorithm

    该算法的目标是提供一种静态的operator部署方案,该方案能够在不需要重新调整的情况下处理最大可能的输入速度变化范围。

    由于动态调整需要时间和消耗,前者适用于负载变化持续时间较长的系统;而后者则能处理较快较短的负载峰值。在实现上前者使用相关系数作为节点关联度指标,并通过贪心算法将NP问题转化为多项式求解;而后者在部署前计算完毕,保证系统能够容忍负载峰值。该算法在线性代数上建模,包括Operator Ordering、Operator Assignment两个阶段。

    3)支持多种容错方案

    Borealis通过多种容错机制来满足用户需求:

    Amnesia Backup

    备机发现主机故障,立即从一个空的状态开始重做。

    Passive Standby

    主机处理,备机待命,主机按周期做checkpoints,主机故障后切换到备机,重放checkpoint和数据流,对于不确定性计算可以很好地支持,缺点是恢复时间较长。

    Active Standby

    主备机同时计算,主机故障时直接切换到备机,不支持不确定性计算,浪费计算资源,优势在于几乎没有恢复时间。

    Upstream Backup

    通过上游备份来容错,故障时从上游重放数据即可,恢复时间最长,不过最节省资源。

    Rollback Recovery

    除了基础的容错方案,Borealis还提供了更高级的容错机制Rollback Recovery,它是一种基于副本在节点失效、网络失效或网络分区时的故障恢复机制,在尽量减少系统不一致的情况下,尽可能的保证系统的可用性。该机制允许用户定义一个阈值来在一致性和可用性之间做一个平衡。当系统数据恢复后,系统支持重新计算输出正确的结果,保证最终一致性。该机制使用了data-serializing operator(SUnion)来确保所有的副本处理同样顺序的数据。当失效恢复后,通过checkpoint/redo、undo/redo来实现恢复重放。
    6. 结论与展望

    实时计算是近年来分布式计算领域研究的重点,无论是工业界还是学术界,都诞生了几个具有代表性的实时数据流计算系统,用于解决实际生产问题和进行学术研究。

    S4的最新版本是alpha version v0.3.0,动态负载均衡和在线服务迁移等重要功能都尚未实现;Storm通过简单实现满足Twitter实际需求,但基于重放的恢复机制很难保证高可用性和计算一致性,另外基于函数式语言Clojure开发也使得它很难广泛开源使用;StreamBase虽然功能齐全却是商用软件,使用成本较大;Borealis对数据流计算的各方面研究广泛且深入,有很好的参考价值,但由于是学术界产物,尚未在工业界大规模使用。

    百度现有实时流式计算平台多为独立系统或者依赖MapReduce框架,在可靠性、高可用、实时性、伸缩性、维护成本、开发成本等方面都存在不足。

    基于数据流计算领域业界系统分析和百度现状分析,我们基础架构部的实时计算小组决定开发属于百度自己的通用实时数据流计算系统——DStream,用于满足百度内部所有的实时数据流处理需求,并希望DStream能在实时计算领域成为集大成者。

    实时计算是分布式计算领域重要组成部分,随着应用规模的不断扩大以及对实时性需求的不断提高,实时数据流计算的前景一片光明,欢迎大家关注和参与实时计算项目。
    展开全文
  • •Spark最初由美国加州伯克利大学(UCBerkeley)的AMP实验室于 2009年开发,是基于内存计算的大数据并行计算框架,可用于构建大 型的、低延迟的数据分析应用程序 •2013年Spark加入Apache孵化器项目后发展迅猛,如今...

    第10讲 Spark

    10.1 Spark概述

    10.1.1 Spark简介

    •Spark最初由美国加州伯克利大学(UCBerkeley)的AMP实验室于 2009年开发,是基于内存计算的大数据并行计算框架,可用于构建大 型的、低延迟的数据分析应用程序
    •2013年Spark加入Apache孵化器项目后发展迅猛,如今已成为Apache 软件基金会最重要的三大分布式计算系统开源项目之一(Hadoop、 Spark、Storm)
    Hadoop进行批量数据离线处理MapReduce负责批处理
    Spark基于内存的实时数据分析框架
    Storm数据流分析框架
    •Spark在2014年打破了Hadoop保持的基准排序纪录
    Spark/206个节点/23分钟/100TB数据
    Hadoop/2000个节点/72分钟/100TB数据
    Spark用十分之一的计算资源,获得了比Hadoop快3倍的速度

    Spark具有如下几个主要特点:
    •运行速度快:使用DAG执行引擎以支持循环数据流与内存计算
    •容易使用:支持使用Scala、Java、Python和R语言进行编程,可以通过Spark Shell进行交互式编程
    •通用性:Spark提供了完整而强大的技术栈,包括SQL查询、流式计算 、机器学习和图算法组件
    •运行模式多样:可运行于独立的集群模式中,可运行于Hadoop中,也可运行于Amazon EC2等云环境中,并且可以访问HDFS、Cassandra、 HBase、Hive等多种数据源

    Spark如今已吸引了国内外各大公司的注意,如腾讯、淘宝、百度、亚马 逊等公司均不同程度地使用了Spark来构建大数据分析应用,并应用到实际的生产环境中

    10.1.2 Scala简介

    Scala是一门现代的多范式编程语言,运行于Java平台(JVM,Java 虚拟机),并兼容现有的Java程序 。集成了面向对象和函数式编程的特点。
    Scala的特性:
    •Scala具备强大的并发性,支持函数式编程,可以更好地支持分布式系统
    •Scala语法简洁,能提供优雅的API Scala兼容Java,运行速度快,且能融合到Hadoop生态圈中

    Scala是Spark的主要编程语言,但Spark还支持Java、Python、R 作为编程语言
    Scala的优势是提供了REPL(Read-Eval-Print Loop,交互式解释器),提高程序开发效率

    10.1.3 Spark与Hadoop的比较

    Hadoop存在如下一些缺点:
    •表达能力有限。并不是所有的应用都能抽象成map和reduce函数
    •磁盘IO开销大 。尤其是在完成迭代操作时。
    •延迟高
    任务之间的衔接涉及IO开销
    在前一个任务执行完成之前,其他任务就无法开始, 难以胜任复杂、多阶段的计算任务

    Spark在借鉴Hadoop MapReduce优点的同时,很好地解决了 MapReduce所面临的问题
    相比于Hadoop MapReduce,Spark主要具有如下优点:
    •Spark的计算模式也属于MapReduce,但不局限于Map和Reduce操作,还提供了多种数据集操作类型编程模型比Hadoop MapReduce更灵活
    •Spark提供了内存计算,可将中间结果放到内存中,对于迭代运算效率更高
    Spark基于DAG的任务调度执行机制,要优于Hadoop MapReduce的迭代执行机制
    在这里插入图片描述
    在这里插入图片描述
    •使用Hadoop进行迭代计算非常耗资源
    •Spark将数据载入内存后,之后的迭代计算都可以直接使用内存中的中间 结果作运算,避免了从磁盘中频繁读取数据
    在这里插入图片描述

    10.2 Spark生态系统

    在实际应用中,大数据处理主要包括以下三个类型:
    •复杂的批量数据处理:通常时间跨度在数十分钟到数小时之间
    •基于历史数据的交互式查询:通常时间跨度在数十秒到数分钟之间
    •基于实时数据流的数据处理:通常时间跨度在数百毫秒到数秒之间
    当同时存在以上三种场景时,就需要同时部署三种不同的软件
    •比如: MapReduce / Impala / Storm

    这样做难免会带来一些问题:
    •不同场景之间输入输出数据无法做到无缝共享,通常需要进行数据格式的转换
    •不同的软件需要不同的开发和维护团队,带来了较高的使用成本
    •比较难以对同一个集群中的各个系统进行统一的资源协调和分配

    •Spark的设计遵循“一个软件栈满足不同应用场景”的理念,逐渐形成了一套完整的生态系统
    •既能够提供内存计算框架,也可以支持SQL即时查询、实时流式计 算、机器学习和图计算等
    •Spark可以部署在资源管理器YARN之上,提供一站式的大数据解决方案
    •因此,Spark所提供的生态系统足以应对上述三种场景,即同时支持批处理、交互式查询和流数据处理

    Spark生态系统已经成为伯克利数据分析软件栈BDAS(Berkeley Data Analytics Stack)的重要组成部分
    Spark的生态系统主要包含了Spark Core、Spark SQL、Spark Streaming、 MLLib和GraphX 等组件
    提供内存计算、交互式查询分析、流计算、机器学习算法、图计算
    在这里插入图片描述
    在这里插入图片描述

    10.3 Spark运行架构

    10.3.1 基本概念

    •RDD:是Resillient Distributed Dataset(弹性分布式数据集)的简称,是分布式内存的一个抽象概念,提供了一种高度受限的共享内存模型
    •DAG:是Directed Acyclic Graph(有向无环图)的简称,反映RDD之间的依赖关系
    •Executor:是运行在工作节点(WorkerNode)的一个进程,负责运行Task
    •Application:用户编写的Spark应用程序
    •Task:运行在Executor上的工作单元
    •Job:一个Job包含多个RDD及作用于相应RDD上的各种操作
    •Stage:是Job的基本调度单位,一个Job会分为多组Task,每组Task被称为 Stage,或者也被称为TaskSet,代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集

    在这里插入图片描述
    Spark运行架构包括集群资源管理器(Cluster Manager)运行作业任务的工作节点 (Worker Node)每个应用的任务控制节点(Driver)每个工作节点上负责具体任务的执行进程(Executor)

    •资源管理器可以自带或Mesos或YARN

    与Hadoop MapReduce计算框架相比,Spark所采用的Executor有两个优点:
    •一是利用多线程来执行具体的任务,减少任务的启动开销
    •二是Executor中有一个BlockManager存储模块,会将内存和磁盘共同作为存储设备, 有效减少IO开销

    10.3.2 架构设计

    在这里插入图片描述
    •一个Application由一个Driver和若干个Job构成,一个Job由多个Stage构成,一个 Stage由多个没有Shuffle关系的Task组成
    在这里插入图片描述
    •当执行一个Application时,Driver会向集群管理器申请资源,启动Executor,并向 Executor发送应用程序代码和文件,然后在Executor上执行Task,运行结束后,执行 结果会返回给Driver,或者写到HDFS或者其他数据库中

    10.3.3 Spark运行基本流程

    在这里插入图片描述
    (1)首先为应用构建起基本的运行环境,即由Driver创建一个SparkContext, 进行资源的申请、任务的分配和监控
    (2)资源管理器为Executor分配资源, 并启动Executor进程
    (3)SparkContext根据RDD的依赖关系构建DAG图,DAG图提交给 DAGScheduler解析成Stage,然后把一个个TaskSet提交给底层调度器 TaskScheduler处理;Executor向 SparkContext申请Task,Task Scheduler 将Task发放给Executor运行,并提供应用程序代码
    (4)Task在Executor上运行,把执行结果反馈给TaskScheduler,然后反馈给 DAGScheduler,运行完毕后写入数据并释放所有资源

    总体而言,Spark运行架构具有以下特点:
    (1)每个Application都有自己专属的Executor进程,并且该进程在Application运行期间一直驻留。Executor进程以多线程的方式运行Task
    (2)Spark运行过程与资源管理器无关,只要能够获取 Executor进程并保持通信即可
    (3)Task采用了数据本地性和推测执行等优化机制

    10.3.4 Spark运行原理

    1.设计背景

    •许多迭代式算法(比如机器学习、图算法等)和交互式数据挖掘工具,共同之处是,不同计算阶段之间会重用中间结果
    •目前的MapReduce框架都是把中间结果写入到HDFS中,带来了大量的数据复制、磁盘IO和序列化开销
    •RDD就是为了满足这种需求而出现的,它提供了一个抽象的数据架构,我们不必担心底层数据的分布式特性,只需将具体的应用逻辑表达为一系列转换处理,不同RDD之间的转换操作形成依赖关系,可以实现管道化,避免中间数据存储

    2.RDD概念

    •一个RDD就是一个分布式对象集合,本质上是一个只读的分区记录集合,每个RDD可分成多个分区,每个分区就是一个数据集片段,并且一 个RDD的不同分区可以被保存到集群中不同的节点上,从而可以在集群中的不同节点上进行并行计算
    •RDD提供了一种高度受限的共享内存模型,即RDD是只读的记录分区的集合,不能直接修改,只能基于稳定的物理存储中的数据集创建RDD, 或者通过在其他RDD上执行确定的转换操作(如map、join和group by) 而创建得到新的RDD

    •RDD提供了一组丰富的操作以支持常见的数据运算,分为**“动作” (Action)**和“转换”(Transformation)两种类型
    •RDD提供的转换接口都非常简单,都是类似map、filter、groupBy、join 等
    粗粒度的数据转换操作
    ,而不是针对某个数据项的细粒度修改(不适合网页爬虫)
    •表面上RDD的功能很受限、不够强大,实际上RDD已经被实践证明可以高效地表达许多框架的编程模型(比如MapReduce、SQL、Pregel)
    •Spark用Scala语言实现了RDD的API,程序员可以通过调用API实现对RDD的各种操作

    RDD典型的执行过程如下:
    在这里插入图片描述
    •RDD读入外部数据源进行创建
    •RDD经过一系列的转换(Transformation)操作,每一次都会产生不同的RDD,供给下一个转换操作使用
    •最后一个RDD经过
    “动作”操作
    进行转换,并输出到外部数据源
    这一系列处理称为一个Lineage(血缘关系),即DAG拓扑排序的结果
    优点:惰性调用、管道化、避免同步等待、不需要保存中间结果、每次操作变得简单

    3.RDD特性

    Spark采用RDD以后能够实现高效计算的原因主要在于:
    (1)高效的容错性
    •现有容错机制:数据复制或者记录日志
    •RDD:血缘关系、重新计算丢失分区、无需回滚系统、重算过程在不同节点之间并行、只记录粗粒度的操作
    (2)中间结果持久化到内存,数据在内存中的多个RDD操作之间进行传递,避免了不必要的读写磁盘开销
    (3)存放的数据可以是Java对象,避免了不必要的对象序列化和反序列化

    4.RDD之间的依赖关系

    在这里插入图片描述
    •窄依赖表现为一个父RDD的分区对应于一个子RDD的分区多个父RDD的分区对应于一个子RDD的分区
    •宽依赖则表现为存在一个父RDD的一个分区对应一个子RDD的多个分区

    5.Stage的划分

    Spark通过分析各个RDD的依赖关系生成了DAG,再通过分析各个RDD 中的分区之间的依赖关系来决定如何划分Stage,具体划分方法是:
    •在DAG中进行反向解析,遇到宽依赖断开
    •遇到窄依赖就把当前的RDD加入到Stage
    •将窄依赖尽量划分在同一个Stage中,可以实现流水线计算

    在这里插入图片描述
    被分成三个Stage,在Stage2中,从map到union都是窄依赖,这两步操作可以形成一个流水线操作
    流水线操作实例:分区7通过map操作生成的分区9, 可以不用等待分区8到分区10这个map操作的计算结束,而是继续进行union操作, 得到分区13,这样流水线执行大大提高了计算的效率

    Stage的类型包括两种:ShuffleMapStage和ResultStage,具体如下:
    (1)ShuffleMapStage:不是最终的Stage,在它之后还有其他Stage, 所以,它的输出一定需要经过Shuffle过程,并作为后续Stage的输入;
    这种Stage是以Shuffle为输出边界,其输入边界可以是从外部获取数据,也可以是另一个ShuffleMapStage的输出,其输出可以是另一个Stage的开始;
    在一个Job里可能有该类型的Stage,也可能没有该类型Stage;
    (2)ResultStage:最终的Stage,没有输出,而是直接产生结果或存储。
    这种Stage是直接输出结果,其输入边界可以是从外部获取数据,也可以 是另一个ShuffleMapStage的输出。
    在一个Job里必定有该类型Stage。
    因此,一个Job含有一个或多个Stage,其中至少含有一个ResultStage。

    6.RDD运行过程

    通过上述对RDD概念、依赖关系和Stage划分的介绍,结合之前介绍的Spark运行 基本流程,再总结一下RDD在Spark架构中的运行过程:
    (1)创建RDD对象;
    (2)SparkContext负责计算RDD之间的依赖关系,构建DAG;
    (3)DAGScheduler负责把DAG图分解成多个Stage,每个Stage中包含了多个 Task,每个Task会被TaskScheduler分发给各个WorkerNode上的Executor去执 行。

    10.4 Spark SQL

    10.4.1 从Shark说起

    •Shark即Hive on Spark,为了实现与Hive兼容, Shark在HiveQL方面重用了Hive中HiveQL的解 析、逻辑执行计划翻译、执行计划优化等逻辑, 可以近似认为仅将物理执行计划从MapReduce作业替换成了Spark作业,通过Hive的HiveQL解 析,把HiveQL翻译成Spark上的RDD操作。
    •Shark的设计导致了两个问题:
    一是执行计划优化完全依赖于Hive,不方便 添加新的优化策略;
    二是因为Spark是线程级并行,而 MapReduce是进程级并行,因此,Spark在兼容Hive的实现上存在线程安全问题,导致 Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支 ·在这里插入图片描述

    10.4.2 Spark SQL设计

    Spark SQL在Hive兼容层面仅依赖HiveQL解析、Hive元数据,也就是说,从 HQL被解析成抽象语法树(AST)起,就全部由Spark SQL接管了。Spark SQL执行计划生成和优化都由Catalyst(函数式关系查询优化框架)负责
    在这里插入图片描述
    •Spark SQL增加了SchemaRDD(即带有Schema信息的RDD),使用户可 以在Spark SQL中执行SQL语句,数据既可以来自RDD,也可以是Hive、 HDFS、Cassandra等外部数据源,还可以是JSON格式的数据
    •Spark SQL目前支持Scala、Java、Python三种语言,支持SQL-92规范
    在这里插入图片描述

    10.5 Spark的部署和应用方式

    10.5.1 Spark三种部署方式

    Spark支持三种不同类型的部署方式,包括:
    •Standalone(类似于MapReduce1.0,slot为资源分配单位)
    •Spark on Mesos(和Spark有血缘关系,更好支持Mesos)
    •Spark on YARN
    在这里插入图片描述

    10.5.2 从Hadoop+Storm架构转向Spark架构

    在这里插入图片描述
    在这里插入图片描述
    用Spark架构具有如下优点:
    •实现一键式安装和配置、线程级别 的任务监控和告警
    •降低硬件集群、软件维护、任务监 控和应用开发的难度
    •便于做成统一的硬件、计算平台资 源池

    需要说明的是,Spark Streaming无 法实现毫秒级的流计算,因此,对 于需要毫秒级实时响应的企业应用 而言,仍然需要采用流计算框架 (如Storm)

    10.5.3 Hadoop和Spark的统一部署

    在这里插入图片描述
    •由于Hadoop生态系统中的一些组件所实现的功能,目前还是无法由Spark 取代的,比如,Storm
    •现有的Hadoop组件开发的应用,完全转移到Spark上需要一定的成本

    不同的计算框架统一运行在YARN中,可以带来如下好处:
    •计算资源按需伸缩
    •不用负载应用混搭,集群利用率高
    •共享底层存储,避免数据跨集群迁移

    10.6 Spark编程实践

    10.6.1 Spark安装

    安装Spark之前需要安装Java环境Hadoop环境
    •下载地址: http://spark.apache.org
    进入下载页面后,点击主页右侧的“Download Spark”按钮进入下载页面,下载页面中提供了几个下载选项,主要是Spark release及Package type的选择,如下图所 示。
    第1项Spark release一般默认选择最新的发行版本,如截止至2016年3月份的最 新版本为1.6.0。
    第2项package type则选择“Pre-build with user-provided Hadoop [can use with most Hadoop distributions]”,可适用于多数Hadoop版本。选择好之 后,再点击第4项给出的链接就可以下载Spark了。
    在这里插入图片描述
    在这里插入图片描述

    10.6.2 启动Spark Shell

    在这里插入图片描述

    10.6.3 Spark RDD基本操作

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述

    10.6.4 Spark应用程序

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    第11讲 流计算

    11.1 流计算概述

    11.1.1 静态数据和流数据

    很多企业为了支持决策分析而构建的数据仓库系统,其中存放的大量 历史数据就是静态数据。技术人员可以利用数据挖掘和OLAP(OnLine Analytical Processing)分析工具从静态数据中找到对企业有价值的信息
    在这里插入图片描述

    • 近年来,在Web应用、网络监控、传感监测等领域,兴起了一种新的数据密集型应用——流数据,即数据以大量、快速、时变的流形式持续到达
    • 实例:PM2.5检测、电子商务网站用户点击流
    • 流数据具有如下特征:
    – 数据快速持续到达,潜在大小也许是无穷无尽的
    – 数据来源众多,格式复杂 – 数据量大,但是不十分关注存储,一旦经过处理,要么被丢弃, 要么被归档存储 – 注重数据的整体价值,不过分关注个别数据
    – 数据顺序颠倒,或者不完整,系统无法控制将要处理的新到达的 数据元素的顺序

    11.1.2 批量计算和实时计算

    • 对静态数据和流数据的处理,对应着两种截然不同的计算模式:批量计算实时计算
    在这里插入图片描述
    •批量计算:充裕时间处理静态数据, 如Hadoop
    •流数据不适合采用批量计算,因为流数据不适合用传统的关系模型建模
    流数据必须采用实时计算,响应时间为秒级
    •在大数据时代,数据格式复杂、来源 众多、数据量巨大,对实时计算提出 了很大的挑战。因此,针对流数据的 实时计算——流计算,应运而生

    11.1.3 流计算概念

    流计算:实时获取来自不同数据源的海量数据,经过实时分析处理,获得有价值的信息
    • 流计算秉承一个基本理念,即数据的价值随着时间的流逝而降低, 如用户点击流。因此,当事件出现时就应该立即进行处理,而不是缓存起来进行批量处理。为了及时处理流数据,就需要一个低延迟、可扩展、高可靠的处理引擎
    • 对于一个流计算系统来说,它应达到如下需求: – 高性能 – 海量式 – 实时性 – 分布式 – 易用性 – 可靠性

    11.1.4 流计算与Hadoop

    • Hadoop设计的初衷是面向大规模数据的批量处理
    • MapReduce是专门面向静态数据的批量处理的,内部各种实现机制都为批处理做了高度优化,不适合用于处理持续到达的动态数据
    • 可能会想到一种“变通”的方案来降低批处理的时间延迟——将基于 MapReduce的批量处理转为小批量处理,将输入数据切成小的片段 ,每隔一个周期就启动一次MapReduce作业。但这种方式也无法有效处理流数据
    – 切分成小片段,可以降低延迟,但是也增加了附加开销,还要处理片段之间依赖关系
    – 需要改造MapReduce以支持流式处理

    结论:鱼和熊掌不可兼得,Hadoop擅长批处理,不适合流计算

    11.1.5 流计算框架

    • 当前业界诞生了许多专门的流数据实时计算系统来满足各自需求
    • 商业级:IBM InfoSphere Streams和IBM StreamBase
    • 开源流计算框架
    – Twitter Storm:免费、开源的分布式实时计算系统,可简单、高效、可 靠地处理大量的流数据
    – Yahoo! S4(Simple Scalable Streaming System):开源流计算平台, 是通用的、分布式的、可扩展的、分区容错的、可插拔的流式系统
    • 公司为支持自身业务开发的流计算框架:
    – Facebook Puma
    – Dstream(百度)
    – 银河流数据处理平台(淘宝)

    11.2 流计算处理流程

    11.2.1 概述

    • 传统的数据处理流程,需要先采集数据并存储在关系数据库等数据管 理系统中,之后由用户通过查询操作和数据管理系统进行交互
    在这里插入图片描述
    • 传统的数据处理流程隐含了两个前提:
    – 存储的数据是旧的。存储的静态数据是过去某一时刻的快照,这 些数据在查询时可能已不具备时效性了
    – 需要用户主动发出查询来获取结果

    流计算的处理流程一般包含三个阶段:数据实时采集、数据实时计算 、实时查询服务
    在这里插入图片描述

    11.2.2 数据实时采集

    • 数据实时采集阶段通常采集多个数据源的海量数据,需要保证实时性 、低延迟与稳定可靠
    • 以日志数据为例,由于分布式集群的广泛应用,数据分散存储在不同 的机器上,因此需要实时汇总来自不同机器上的日志数据
    • 目前有许多互联网公司发布的开源分布式日志采集系统均可满足每秒 数百MB的数据采集和传输需求,如:
    – Facebook的Scribe
    – LinkedIn的Kafka
    – 淘宝的Time Tunnel
    – 基于Hadoop的Chukwa和Flume

    • 数据采集系统的基本架构一般有以下三个部分:
    – Agent:主动采集数据,并把数据推送到Collector部分
    – Collector:接收多个Agent的数据,并实现有序、可靠、高性能的转发
    – Store:存储Collector转发过来的数据(对于流计算不存储数据)
    在这里插入图片描述

    11.2.3 数据实时计算

    • 数据实时计算阶段对采集的数据进行实时的分析和计算,并反馈实时 结果
    • 经流处理系统处理后的数据,可视情况进行存储,以便之后再进行分 析计算。在时效性要求较高的场景中,处理之后的数据也可以直接丢弃

    11.2.4 实时查询服务

    • 实时查询服务:经由流计算框架得出的结果可供用户进行实时查询、 展示或储存
    • 传统的数据处理流程,用户需要主动发出查询才能获得想要的结果。 而在流处理流程中,实时查询服务可以不断更新结果,并将用户所需 的结果实时推送给用户
    • 虽然通过对传统的数据处理系统进行定时查询,也可以实现不断地更新结果和结果推送,但通过这样的方式获取的结果,仍然是根据过去某一时刻的数据得到的结果,与实时结果有着本质的区别

    • 可见,流处理系统与传统的数据处理系统有如下不同:
    – 流处理系统处理的是实时的数据,而传统的数据处理系统处理的 是预先存储好的静态数据
    – 用户通过流处理系统获取的是实时结果,而通过传统的数据处理 系统,获取的是过去某一时刻的结果
    – 流处理系统无需用户主动发出查询,实时查询服务可以主动将实时结果推送给用户

    11.3 流计算的应用

    • 流计算是针对流数据的实时计算,可以应用在多种场景中
    • 如百度、淘宝等大型网站中,每天都会产生大量流数据, 包括用户的搜索内容、用户的浏览记录等数据。采用流计 算进行实时数据分析,可以了解每个时刻的流量变化情况 ,甚至可以分析用户的实时浏览轨迹,从而进行实时个性 化内容推荐
    • 但是,并不是每个应用场景都需要用到流计算的。流计算 适合于需要处理持续到达的流数据、对数据处理有较高实 时性要求的场景

    11.3.1 应用场景1: 实时分析

    • 传统的业务分析一般采用分布式离线计算的方式,即将数据 全部保存起来,然后每隔一定的时间进行离线分析来得到结 果。但这样会导致一定的延时,难以保证结果的实时性
    • 随着分析业务对实时性要求的提升,离线分析模式已经不适 合用于流数据的分析,也不适用于要求实时响应的互联网应 用场景
    • 虽然分布式离线分析带来的小时级的分析延时可以满足大部 分商家的需求,但随着实时性要求越来越高,如何实现秒级 别的实时分析响应成为业务分析的一大挑战
    • 针对流数据,“量子恒道”开发了海量数据实时流计算框架Super Mario。通过该框架,量子恒道可处理每天TB级的实时流数据,并且 从用户发出请求到数据展示,整个延时控制在2-3秒内,达到了实时 性的要求
    在这里插入图片描述

    11.3.1 应用场景2: 实时交通

    • 流计算不仅为互联网带来改变,也能改变我们的生活
    • 如提供导航路线,一般的导航路线并没有考虑实时的交通 状况,即便在计算路线时有考虑交通状况,往往也只是使 用了以往的交通状况数据。要达到根据实时交通状态进行 导航的效果,就需要获取海量的实时交通数据并进行实时 分析
    • 借助于流计算的实时特性,不仅可以根据交通情况制定路 线,而且在行驶过程中,也可以根据交通情况的变化实时 更新路线,始终为用户提供最佳的行驶路线

    11.4 开源流计算框架Storm

    11.4.1 Storm简介

    • 以前只有政府机构和金融机构能够通过昂贵的定制系统来满足流数据 实时分析计算需求
    • 早期对于流计算的研究多数是基于对传统数据库处理的流式化,即实 时数据库,很少研究流计算框架
    • Yahoo! S4和Twitter Storm的开源,改变了这个情况
    • 在流数据处理上比MapReduce更有优势
    • 批处理系统关注吞吐率,流处理系统关注延时
    • Yahoo! S4和Twitter Storm改变了开发实时应用的方式
    – 以前既要关注处理逻辑,还要解决实时数据获取、传输、存储
    – 现在可以快速低成本搭建起实时流处理系统

    • Twitter Storm是一个免费、开源的分布式实时计算系统, Storm对于实时计算的意义类似于Hadoop对于批处理的 意义,Storm可以简单、高效、可靠地处理流数据,并支 持多种编程语言
    • Storm框架可以方便地与数据库系统进行整合,从而开发 出强大的实时计算系统
    • Twitter是全球访问量最大的社交网站之一,Twitter开发Storm流处理 框架也是为了应对其不断增长的流数据实时处理需求
    在这里插入图片描述

    11.4.2 Storm的特点

    • Storm可用于许多领域中,如实时分析、在线机器学习、持续计算、 远程RPC、数据提取加载转换
    • Storm具有以下主要特点: – 整合性 – 简易的API – 可扩展性 – 可靠的消息处理 – 支持各种编程语言 – 快速部署 – 免费、开源

    11.4.3 Storm设计思想

    11.4.4 Storm框架设计

    11.5 Spark Streaming、Samza以及三种流计算框架的比较

    11.6 Storm编程实践

    第12讲 图计算

    12.1 图计算简介

    12.2 Pregel简介

    12.3 Pregel图计算模型

    12.4 Pregel的C++ API

    12.5 Pregel的体系结构

    12.6 Pregel的应用实例——单源最短路径

    12.7 Hama的安装和使用

    第13讲 大数据在不同领域的应用

    13.1 大数据应用概览

    13.2 推荐系统

    13.3 大数据在智能医疗和智能物流领域运用

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 1:数据:数据(数据):在时间分布和数量上无限的一系列动态数据的集合体。:2:数据的特点: 1:数据快速到达,潜在大小也许是无穷无尽的。 2:数据来源众多,格式复杂。 3: 数据量大,但是不十分关注...
  • 流计算:即时信息(入门级)

    千次阅读 2008-12-18 16:46:00
    传统的数据操作,首先将数据采集并存储在DBMS中,然后通过query和DBMS进行交互,得到用户想...流计算(Stream Computing)就是专门针对这种数据类型准备的。在流数据不断变化的运动过程中实时地进行分析,捕捉到可能对
  • 随着流计算越来越流行和普及,越来越多的原本主要针对离线批式数据的统计和机器学习模型也被用于流数据。 比如在风控系统中,当我们计算好特征后,还需要把这些特征输入评分模型进行风险评分。根据不同的使用场景,...
  • 那些年我们用过的流计算框架

    千次阅读 2017-10-23 00:00:00
    数据时代,从数据中获取业务需要的信息才能创造价值,这类工作就需要计算框架来完成。传统的数据处理流程中,总是先收集数据,然后将数据放到DB中。当人们需要的时候通过DB对数据...基于此,一种新的数据计算结构---
  • 腾讯实时计算团队为业务部门提供高效、稳定和易用的实时数据服务。其每秒接入的数据峰值达到了 2.1 亿条,每天接入的数据量达到了 17 万亿条,每天的数据增长量达到了 3P...
  • 工作流产品整理

    千次阅读 2007-05-24 16:44:00
    第 I 条 工作简介1 什么是工作?简单地讲,工作就是业务流程(Business Process)的计算机化或自动化。企业或组织内有许多繁琐复杂的业务流程,这些流程构成了企业或组织的日常运营活动。通过现代的技术手段...
  • GPU通用计算(GPGPU)——将图形处理器用于高性能计算领域1.1 研究背景和意义随着当前计算机性能的不断提高,应用范围越来越广泛,不同的计算任务和计算需求都在快速增长,这就决定了处理器朝着通用化和专用化两个...
  •  实时计算的概念实时计算一般都是针对海量数据进行的,一般要求为秒级。实时计算主要分为两块:数据的实时入库、数据的实时计算。主要应用的场景:1) 数据源是实时的不间断的,要求用户的响应时间也是实时的(比如...
  • 1. Java 8新增的Stream特殊集合:  1) Stream,即,和之前讲过的I/O并非一种... 2) 它的特殊之处在于,专门用于对集合中的元素进行聚集操作(聚集操作泛义上将就是诸如统计操作之类的操作,比如求平均值、最
  • 作者简介:田浩兵,中国移动云能力中心SaaS产品部技术专家组成员、边缘应用产品组研发经理,曾参与能力开放平台、中小企业云平台、集中化计划建设、云视频等项目及产品的研发工作,在微服务架构设计及媒体处理领域...
  • 什么是工作管理系统(WFMC)

    千次阅读 2007-09-11 22:52:00
    )有许多软件厂商提供各自的工作软件产品,而且新的产品也不断涌现,用户有很大的选择余地,但是如果没有可遵循的行业标准,就会使这些产品之间存在巨大差异,导致这些产品之间不能协同工作,成为一个个信息的...
  • [Flink基础]--什么是处理?

    千次阅读 2018-09-29 12:56:46
    什么是处理? Data Artisans由ApacheFlink®的原始创建者创建,我们花了很长时间来解决处理领域的问题。在这篇介绍性文章中,我们将提供有关处理和Apache Flink适合的视角。要了解更多信息,您可以下载有关...
  • 产品 模型 API 保证次数 容错机制 状态管理 延时 吞吐量 成熟度 Strom Native 组合式 At-least-once Record ACKs 无 Very Low Low High Trident mirco-batching 组合式 Exectly-once Record ...
  • 流式计算系统分析

    千次阅读 2012-11-29 00:09:42
    2011年度的Hadoop China大会刚刚落下帷幕,这次会议的一个热点议题就是数据流计算,在MapReduce计算模型风靡全球之后,Stream Processing将会是下一个研究热点,无论是在工业界还是学术界。本文从深层次对各种典型的...
  • 价值图(VSM)是一种精益制造技术,用于分析,设计和管理将产品带给客户所需的材料和信息。它使用标准符号系统来描述各种工作和信息。项目被映射为添加值或不从客户的角度添加值,目的是根除不增加价值的...
  • 什么是流式计算

    千次阅读 2019-09-09 19:16:55
    一、流式计算的背景 在日常生活中,我们通常会先把数据存储在一张表中,然后再进行加工、分析,这里就涉及到一个时效性的问题。如果我们处理以年、月为单位的级别的数据,那么多数据的实时性要求并不高;但如果我们...
  • 计算范式

    千次阅读 2016-07-09 10:12:33
    尝试对并行计算,分布式计算,云计算,串行计算,异构计算等概念进行梳理
  • 人们常说,那个人是做“水泥生意”的,意思是说,那个人以出售或交易“水泥产品”而谋生。我们要问,计算(能力)怎么出售呢?  记得,我在上大学(57年,南京大学数学天文系)时,计算数学的实习课程用的是手摇...
  • 计算是思科创造的一个术语,由OpenFog Consortium支持,该联盟由Arm、思科、戴尔、英特尔、微软和普林斯顿大学边缘实验室于2015年成立。其使命宣言(部分)内容如下: 我们的工作将定义分布式计算、网络、存储、...
  • 计算广告——读书笔记(二)

    千次阅读 2019-04-05 18:56:29
    一般个性化系统由四部分组成:用于实时响应请求,完成决策的在线投放(online serving)引擎,离线的分布式计算(distributed computing)数据处理平台,用于在线实时反馈的流计算(stream computing)平台,链接和...
  • 什么是普适计算

    万次阅读 2010-09-03 13:29:00
    的含义十分广泛,所涉及的技术包括移动通信技术、小型计算设备制造技术、小型计算设备上的操作系统技术及软件技术等,间断连接与轻量计算(即计算资源相对有限)是普适计算最重要的两个特征。普适计算的软件技术就是...
  • 媒体及媒体传输协议简介

    千次阅读 多人点赞 2019-06-01 22:26:10
    媒体(streaming media):是指将一连串的媒体数据压缩后,经过网上分段发送数据,在网上即时传输影音以供观赏的一种技术与过程,此技术使得数据包得以像流水一样发送;如果不使用此技术,就必须在使用前下载整个...
  • Android ListView功能扩展,实现高性能的瀑布布局

    万次阅读 多人点赞 2015-10-08 09:11:01
    一直关注我博客的朋友们应该知道,其实在很早之前我就发布过一篇关于实现瀑布布局的文章,Android瀑布照片墙实现,体验不规则排列的美感。但是这篇文章中使用的实现算法比较简单,其实就是在
  • 计算机组成原理 — GPU 图形处理器

    万次阅读 多人点赞 2019-08-12 19:32:44
    例如 TensenCore 专门用于加速深度学习中的张量运算。 CUDA 编程模型 CUDA(Compute Unified Device Architecture,统一计算架构)是由 NVIDIA 所推出的一种集成技术,是对于 GPGPU 的正式名称,本质是一种...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 144,964
精华内容 57,985
关键字:

哪个产品是用于流计算的