精华内容
下载资源
问答
  • 页式地址变换 虚地址结构 ...虚地址转换内存地址计算 如果,虚地址(逻辑地址、程序地址)以十六进制、八进制、二进制的形式给出 第一步,将虚地址转换成二进制的数; 第二步,按页的大...

    页式地址变换

    虚地址结构

    虚地址是用户程序中的逻辑地址,它包括页号和页内地址(页内位移)

    区分页号和页内地址的依据是页的大小,页内地址占虚地址的低位部分,页号占虚地址的高位部分。

    • 假设页面大小为1024字节,虚地址占用2个字节(16位)

    虚地址转换为内存地址计算

    • 如果,虚地址(逻辑地址、程序地址)以十六进制、八进制、二进制的形式给出
    • 第一步,将虚地址转换成二进制的数;
    • 第二步,按页的大小分离出页号和位移量(低位部分是位移量,高位部分是页号);
    • 第三步,根据题意产生页表,将位移量直接复制到内存地址寄存器的低位部分;
    • 第四步,以页号查页表,得到对应页装入内存的块号,并将块号转换成二进制数填入地址寄存器的高位部分,从而形成内存地址。

    举例说明:
    1.有一系统采用页式存储管理,有一作业大小是8KB,页大小为2KB,依次装入内存的第7、9、A、5块,试将虚地址0AFEH,1ADDH转换成内存地址。
    解:
    |页号|块号 |
    | 0 | 7 |
    | 1 | 9 |
    | 2 | A |
    | 3 | 5 |
    虚地址0AFEH转化为二进制数:0000 1010 1111 1110
    已知页大小是2kb,所以低位部分是11位,所以,w=010 1111 1110, p=0000 1=1
    根据页号与块号的排列 p=1时,块号为9,9的二进制数为1001,表首地址为0
    所以,MR=(首0)0100 1010 1111 1110(二进制)=4AFEH(16进制)

    同理可计算出1ADDH,大家动手试一试吧。答案会放在在评论区里。

    • 如果,虚地址以十进制数给出,那么就用公式进行计算。
    • 页 号(整除)=虚地址 / 页大小
      位移量(取模)=虚地址 mod 页大小
      根据题意产生页表;
      以页号查页表,得到对应页装入内存的块号
      内存地址=块号×页大小+位移量
    同样我们举例说明
    1. 有一系统采用页式存储管理,有一作业大小是8KB,页大小为2KB,依次装入内存的第7、9、10、5块,试将虚地址7145,3412转换成内存地址。
      解:
      |页号|块号 |
      | 0 | 7 |
      | 1 | 9 |
      | 2 | A |
      | 3 | 5 |
      首先,已知虚地址7415,页大小为2kb
      计算 P=7145/2048=3
      W=7145mod2048=1001
      MR=5*2048+1001=11241
      所以虚地址7145的内存地址是:11241

    同样的,3412的内存地址请大家动手试一下,答案放在评论区。
    其实是很简单的东西,怕自己忘记计算方式,所以记录一下,各位大佬见笑了。

    展开全文
  • 3、Spark2x 基于内存计算引擎

    千次阅读 2018-11-09 17:20:13
    Spark2x 基于内存计算引擎 一、Spark 概述 Spark 是一种基于内存进行计算的分布式批处理引擎,他的主要工作是执行以下几种计算: (1) 数据处理,可以进行快速的数据计算工作,具备容错性和可拓展性。 (2) ...

    Spark2x 基于内存的计算引擎

    一、Spark 概述

    Spark 是一种基于内存进行计算的分布式批处理引擎,他的主要工作是执行以下几种计算:

    (1) 数据处理,可以进行快速的数据计算工作,具备容错性和可拓展性。

    (2) 迭代计算,Spark 支持迭代计算,可以对多步数据逻辑处理进行计算工作。(3) 数据挖掘,在海量数据基础上进行挖掘分析,可以支持多种数据挖掘和机器学习算法。

    对比于 hadoop 来说,Spark 更适用于数据处理,机器学习,交互式分析,最主要的是迭代计算中,它可以提供比 hadoop 更低的延迟,更高效的处理,并且开发效率更高,容错性也更好,但是需要注意的是,Spark 的性能只有在进行多层迭代计算的时候才会有显著的性能提升,相对于迭代层数少的现象,Spark 的计算性能提升的并不明显,基本和 Hadoop 持平。

    Spark 是基于内存的分布式批处理引擎,它最大的特点是延迟小,具有很高的容错性和可拓展性,它和其他引擎的最大的区别在于,它支持进行迭代计算, Spark 主要适用的场景在低延迟的迭代计算中,它和传统的数据处理引擎最大的不同,在于 Spark 会将计算中的临时文件或者临时数据存放在内存中,这样在进行反复的引用时,就不需要再从磁盘中进行数据读取,而是选择更快的内存进行该操作。那么相比于传统 Hadoop 架构,Spark 理论速度会高于 Hadoop100 倍以上,但是,这个参数是有条件的,在迭代的层级较少的时候,这个差距并不明显,还有可能 Spark 的计算速度没有 hadoop 快,但是当反复的重复引用和迭代层数多以后,这个差距就会越来越明显。

    (1) SparkCore:类似于 MR 的分布式内存计算框架,Core 是整体 Spark 计算的核心进程,上层的计算按照计算的类型进行区分,用于适应不同层面的和不同目的的计算,然后计算的流程和中间处理进程都是由 Core 来进行的计算,所以

    本身从原理上来说,Spark 通过各种上层进程,满足了不同需求的计算,并且进行转化,下层的 Core 只进行计算,这样做就可以保证整体的所有组件都正常运行,并且达到资源的利用最大化,最大的特点是将中间计算结果直接放在内存中,提升计算性能。自带了 Standalone 模式的资源管理框架,同时,也支持 YARN、 MESOS 的资源管理系统。FI 集成的是 SparkOnYarn 的模式。其它模式暂不支持。(2) SparkSQL:SparkSQL 是一个用于处理结构化数据的 Spark 组件,作为

    Apache    Spark 大数据框架的一部分,主要用于结构化数据处理和对数据执行类SQL 查询。通过 SparkSQL,可以针对不同数据格式(如:JSON,Parquet,ORC 等)

    和数据源执行 ETL 操作(如:HDFS、数据库等),完成特定的查询操作。当我们需要对 Sql 进行相关的操作的时候,就像之前所说,首先用户通过 SQL 语句发送对应的请求到达 Spark 的 SQL 执行引擎,SQL 执行引擎将我们提交的请求做语义执行,转化为对应的对数据的操作,之后,将对应的操作和执行处理任务交给 Core 来进行计算。

    (3) SparkStreaming :微批处理的流处理引擎,将流数据分片以后用 SparkCore 的计算引擎中进行处理。相对于 Storm,实时性稍差,优势体现在吞吐量上。

    (4)     Mllib 和 GraphX 主要一些算法库。

    (5)     FusionInsight Spark 默认运行在 YARN 集群之上。

    (6)     Structured    Streaming 为 2.0 版本之后的 spark 独有。它是构建在

    SparkSQL 上的计算引擎,其将流式数据理解成为是不断增加的数据库表,这种流式的数据处理模型类似于数据块处理模型,可以把静态数据库表的一些查询操作应用在流式计算中,Spark 执行标准的 SQL 查询,从无边界表中获取数据。

    三、SparkCore 技术原理

    1.Spark 的流程角色和基本概念

    角色基本概念:

    (1)Client:用户方,负责提交请求 Client 和之前的概念一样,是一个引擎内的进程,提供了对外访问的接口和对内组件进程的交互。

    (2)Driver:负责应用的业务逻辑和运行规划(DAG)

    Driver 是一个新的组件,和之前的处理引擎最大的不同在于,我们处理 Spark 的数据时,由于 Spark 是一个基于内存的处理引擎,所以其数据计算时有一个很典型的特点就是迭代化的计算处理,所以我们在具体将任务切分的时候,就不能像之前的处理引擎一样,只是单纯的将任务做切分下发,因为任务和任务之间这次存在了强耦合或者是弱耦合的关联性关系,而计算的结果又会出现相互的调用,也就是结果之间存在有依赖关系,所以我们在处理 Spark 的计算时,就必须对任务的执行过程做一个非常详细的控制,什么时候需要做什么计算,需要调用什么样的结果,这都是 Driver 需要进行规划和控制的,所以在我们执行相关的任务之前,Driver 就需要对任务做相关的划分和处理的顺序的控制,将任务的执行规划整合为 DAG 运行规划图来进行下发(DAG:DAG 是一个应用被切分为任务之后的执行的相关处理流程,主要是用来控制任务的执行顺序和调用的数据,DAG

    是一个有向无环图,也就是说,任务执行是有相关的执行顺序的,这就保证了有向,但是任务同时又是一定会执行完毕的,所以无环就保证了任务一定会有终止。)(3)ApplicationMaster:负责应用的资源管理,根据应用需要,向资源管理部门(ResourceManager)申请资源。

    这里说的 AppMaster 和 MR 的有一定的不同,区别如下:

    ①MR 的 AppMaster 需要负责的功能很多,但是 Spark 的 AppMaster 功能较单一

    ②MR 的 AppMaster 在创建完成之后需要和 RM 模块进行注册操作,Spark 的不需要

    在向 RM 申请资源之后,MR 的 AppMaster 需要自己和 NM 通信要求其拉起

    Container,Spark 的不需要,Executor 是由 RM 直接下发创建的。 ④Container 和 Executor 创建完成之后,如果是 MR 的 AppMaster,则会下发 task 到 Container 中,如果是 Spark,则由 driver 下发 task。

    如果用户需要查询相关的处理进度信息,MR 的 AppMaster 负责返回执行进度,如果是 Spark,则由 Driver 执行。

    执行完成之后 MR 的 AppMaster 需要注销,Spark 的 AppMaster 不需要注销。

    如果执行过程中出现故障,那么 MR 的 AppMaster 负责重新下发 task 执行,在

    Spark 中这个工作由 Driver 做。

    所以综上所述,MR 和 Spark 的 AppMaster 最大的区别在于,MR 的 AppMaster 是

    一个综合管理的进程,但是 Spark 中,这个工作就由 Driver 来做,AppMaster 只负责资源的计算和申请操作。Driver 是一个固定进程,MR 的 AppMaster 是一个临时进程。

    (4)ResourceManager:资源管理部门,负责整个集群资源统一调度和分配。 RM 是 Yarn 中的组件,和 MR 和 Spark 没关系,这里两个引擎只是调用了 Yarn 中的 RM,没有在自身引擎内创建和维护 RM。

    (5)Executor:负责实际计算工作,一个应用会分拆给多个 Executor 来进行计算。

    Executor 是一个更小化的概念,我们的 AppMaster 在申请的时候,申请的是 Container 容器,然后 RM 将对应的资源做封装,然后和 NM 进行通信,要求 NM 启动 Container,在 Container 中,我们又将资源做了进一步的切分,最终形成一个个的 Executor,所以这里所说的 Executor 是属于 Container 的,我们在下发任务时,可以给一个 Executor 中下发多个 task 进行执行。而 Executor 之间的计算又是分布式的。

    流程基本概念:

    (1)Application:Spark 用户程序,提交一次应用为一个 Application,一个 App 会启动一个 SparkContext,也就是 Application 的 Driver,驱动整个 Application 的运行。

    我们所做的一个任务就是指提交一个 Application,一个应用中包含的就是对数据所需要执行的计算,以及对计算相关的控制操作,除了这两部分之外,我们在 Application 中还封装了相关的执行所需要的一些进程驱动,比如对 Driver 和 AppMaster 的相关配置和处理文件。那么在 Application 中我们提交的计算就是一个整体的计算进程。

    (2)Job:一个 Application 可能包含多个 Job,每个 action 算子对应一个 Job; action 算子有 collect,count 等。

    Driver 将一个 Application 中提交的计算进程,切分为执行的几个计算,比如说用户下发一个做菜的要求,那么 Driver 就会将该请求解析切分为洗菜、切菜、炒菜的一步步的 job 来进行执行。

    (3)Stage:每个 Job 可能包含多层 Stage,划分标记为 shuffle 过程;Stage按照依赖关系依次执行。

    那么在每一个 job 子任务中,我们又需要做很多的计算工作,这个时候,我们会检查当前需要执行的计算中的数据之间的关联性和相关的执行的耦合度,然后根据数据以及结果之间的依赖关系,将其分为宽依赖和窄依赖,我们从 Driver 一开始分析出的 DAG 图中,从最末端开始向总结果的方向去执行,一旦在 DAG 中发现出现宽依赖,则将其拆分为窄依赖来进行计算工作,重新规划 DAG 图,并认为凡是从开始执行直到遇到宽依赖的中间计算流程,都属于是一个计算阶段。当所有的 job 中不在存在有宽依赖时,我们的计算规划就保证已经处于是一个最小化计算的,最小化迭代的这么一个状态了。那么我们这个时候就可以将一层一层的迭代计算中所需要执行的每一步操作都封装为一个 task 然后下发执行了,这个时候整体的计算流程就已经划分为了 Application—Job—Stage—task

    (4)Task:具体执行任务的基本单位,被发到 executor 上执行。

    Task 是整体计算中的最小单位,只有 task 的计算是不存在迭代关系的,但是 task 在执行的时候可能会依赖于某一些其他 task 的计算结果。

    2.Spark 的应用运行流程

    (1)Client 向 Driver 发起应用计算请求,将 Driver 启动,并且同时申请 JobID保证全局应用的唯一合法性。

    首先,用户通过相关的接口连接到 Client,然后提交 Application 应用到 Client, Client 将请求转发到 Spark,启动 Driver,Driver 会根据 Application 中的数据和信息,对任务进行相关的计算工作,然后把 Application 中的计算请求解析,并且拆解,最终成为 DAG 的形式提交,按照如上的基本概念(2)Driver 向 RM 申请 AM,来计算本次的应用数据

    Driver 在执行完如上的计算之后,会根据用户提交的 Application 中关于 AppMaster 的控制文件和相关信息,计算其所需要使用资源,然后将请求发送给RM,请求创建一个 Container,并在其中拉起 AppMaster。

    (3)RM 在合适的设备节点上启动 AM,来进行应用的调配和控制 RM 在收到请求之后,首先会发送相关的请求到各个 NM,检查每个 NM 的负载情

    况,并且选择当前负载最小的 NM 节点进行通信,下发相关的请求给 NM,要求其在自身封装对应的资源,拉起一个 Container,并在 Container 创建完成之后在其中打开 AppMaster。

    (4)AM 向 RM 申请容器进行数据的计算 AppMaster 拉起之后,会根据 Driver 中记录 DAG 计算当前执行任务所需要消耗

    的资源,然后根据计算的结果向 RM 发起资源的申请请求,这里的 AppMaster 和 RM 中的相同,会按照轮询式的请求方法,计算每一步操作所需要消耗的资源,然后逐个下发申请,而不是根据计算所需要消耗的资源总量去进行一次性申请。

    (5)RM 选择合适的节点进行容器的下发,并且在容器上启动 Executor RM 按照之前的方式,根据负载在 NM 上拉起 Container,并且要求 Container 在

    创建完成之后在内部继续创建 Executor。

    (6)Executor 创建完成之后,会向 Driver 进行注册。保证其合法性。

    (7)Driver 会将任务按照 DAG 的执行规划,一步步的将 Stage 下发到 Executor上进行计算

    计算的过程中,数据会根据调用的依赖关系,先缓存在内存中,如果内存中的容量不足,我们也需要根据时间戳将最先写入到内存中的部分数据下盘。计算全部结束之后,Executor 就会关闭自身进程,然后 NM 将资源做回收操作。

    (8)任务计算完成之后,Driver 会向 RM 进程发送注销信息,完成应用的计算,并且向 Client 返回对应的执行结果。

    如果在执行的过程中,我们有相关的查询操作,这个时候,请求会通过 Client 下发给 Driver 进行查询,如果 Driver 查询到某一个 task 执行卡住,或者执行的速度过慢,这个时候就会选择一个 Executor 下发一个相同的任务,那个任务先执行完,就使用哪一个任务的结果,这样就可以保证在整体执行的时候不会由于某一个进程的执行速度过慢,而导致的整体计算被卡住。

    3.RDD 弹性分布数据集

    由于 Driver 整体是将数据切分成了阶段去进行执行,那么 DAG 本身就是一个关于计算执行的控制流程。DAG 主要是用于控制计算的顺序和计算的结果调用的规划。那么在实际进行计算的时候,一个大的数据也就会按照这种 DAG 被切分成了很多小的数据集被反复调用或者根据依赖关系缓存。这个时候,这种由阶段性计算产生的小的数据集就被称为 RDD 弹性分布式数据集。

    弹性分布数据集,指的是一个只读的,可分区的分布式数据集。这个数据集的全部或部分可以缓存在内存,在多次计算之间重用。

    (1)RDD 的生成:从 Hadoop 文件系统(或与 Hadoop 兼容的其它存储系统)输入创建(如 HDFS)。或者从父 RDD 转换得到新的 RDD。

    在实际的操作中,我们提交业务的时候是按照整体文件进行的提交,提交进来之后,我们首先在 Duiver 中会进行 Application 到 task 的 DAG 切分,这个时候计算的数据,就由原先的整体文件被切分为了一个个的 RDD,我们计算的时候是按照 DAG 的执行反向顺序进行的创建,由一个大的文件,也就是量级比较大的父 RDD,逐步的切分为多个子 RDD,直到最终子 RDD 的对应关系可以和 task 进行匹配。

    (2)RDD 的存储和分区:用户可以选择不同的存储级别存储 RDD 以便重用(11种)。当前 RDD 默认存储于内存,但当内存不足时,RDD 会溢出到磁盘中。RDD在需要进行分区时会根据每条记录 Key 进行分区,以此保证两个数据集能高效进行 Join 操作。

    我们在执行相关的计算时,主要有两种大类的操作,为 transfermation 和action, 其中 transfermation 执行的操作结果还是一个 RDD,相当于在执行计算的过程中,transfermation 产生的是临时的数据集,对数据做一些基本的操作和处理。如 map 、filter 、join 等。Transformation 都是 Lazy 的,代码调用到 Transformation 的时候,并不会马上执行,需要等到有 Action 操作的时候才会启动真正的计算过程。 action 产生的是结果,如 count,collect,save 等,Action 操作是返回结果或者将结果写入存储的操作。Action 是 Spark 应用真正执行的触发动作。

    RDD 的 11 种存储级别:

    (3)RDD 的优点:RDD 是只读的,可提供更高容错能力。RDD 的不可变性,可以

    实现 HadoopMapReduce 的推测式执行。RDD 的数据分区特性,可以通过的本地性来提高能。RDD 都是可序列化的,在内存不足时自动降级为磁盘存储。

    HadoopMapReduce 推测执行(SpeculativeExecution)(SpeculativeExecution):

    是指在分布式集群环境下,因为负载不均衡或者资源分布等原造成同一个 job 的个别的个别 task 运行速度明显慢于其他 task,最终延长整个 Job 的执行时间。为了避免这种情况发生,Hadoop 会为该 task 启动备份任务,让该 speculative task 与原始 task 同时处理一份数据,哪个先运行完则将谁的结果作为最终结果,以提高整 Job 的执行时间。

    RDD 的特点:失败自动重建。可以控制存储级别(内存,磁盘等)来进行重用。是静态类型的。

    4.RDD 的宽依赖和窄依赖

    RDD 父子依赖关系:

    在 RDD 中,我们可以根据某个 RDD 进行操作(计算或者转换等)得到一个新的RDD,那么这个 RDD 在执行 Application 类操作的时候是会产生对原 RDD 的依赖关系,那么此时,原 RDD 成为父 RDD,新的 RDD 为子 RDD。

    窄依赖(Narrow)指父 RDD 的每一个分区最多被一个子 RDD 的分区所用。

    宽依赖(Wide)指子 RDD 的分区依赖于父 RDD 的所有分区,是 Stage 划分的依据。

    (1)窄依赖对优化很有利。逻辑上,每个 RDD 的算子都是一个 fork/join(此 join 非 join 算子,而是指同步多个并行任务的 barrier);把计算 fork 到每个分区,算完后 join,然后下一个 fork/join。如果直接转换到物理实现,是很不经济的:一是每一个 RDD(即使是中间结果)都需要物化到内存或存储中,费时费空间;二是 join 作为全局的 barrier,是很昂贵的,会被最慢的那个节点拖死。如果子 RDD 的分区到父 RDD 的分区是窄依赖,就可以把两个 fork/join 合为一个;如果连续的变换算子序列都是窄依赖,就可以把很多个 fork/join 并为一个,不但减少了大量的全局 barrier,而且无需物化很多中间结果 RDD,这将极大地提升性能。Spark 把这个叫做 pipeline 优化。

    RDD 的序列化,我们在进行计算时,由于 RDD 之间包括我们执行的计算之间都是有依赖关系的,那么在进行实际的计算时,也会存在计算的顺序。那么,当内存的容量不足时,我们就需要将一部分的 RDD 存储在硬盘中,这个时候,由于 RDD 存在序列化编号,这样我们就可以根据编号继续按顺序进行计算操作,而不会导致由于 RDD 没有编号产生的计算混乱的问题。

    (2)窄依赖的优势:首先,narrow dependencies 可以支持在同一个 cluster node 上以管道形式执行多条命令,例如在执行了 map 后,紧接着执行 filter;其次, 则是从失败恢复的角度考虑。narrow dependencies 的失败恢复更有效,因为它只需要重新计算丢失的 parent partition 即可,而且可以并行地在不同节点进行重计算。

    (3)Stage 划分:stage 的划分是 Spark 作业调度的关键一步,它基于 DAG 确定依赖关系,借此来划分 stage,将依赖链断开,每个 stage 内部可以并行运行, 整个作业按照 stage 顺序依次执行,最终完成整个 Job。实际应用提交的 Job 中 RDD 依赖关系是十分复杂的,依据这些依赖关系来划分 stage 自然是十分困难的, Spark 此时就利用了前文提到的依赖关系,调度器从 DAG 图末端出发,逆向遍

    历整个依赖关系链,遇到 ShuffleDependency(宽依赖关系的一种叫法)就断开,遇到 NarrowDependency 就将其加入到当前 stage。stage 中 task 数目由 stage 末端的 RDD 分区个数来决定,RDD 转换是基于分区的一种粗粒度计算,一个 stage 执行的结果就是这几个分区构成的 RDD。

    整体来说,由于本身我们在提交计算的时候,计算之间就存在有相关的依赖关系,各个计算结果相互进行迭代和调用,这也就导致了在转化为 DAG 的过程中,我们的数据与数据之间,包括计算的临时结果之间也是存在有相关的调用关系的,这样的话,某一些计算的 RDD 算子,就会依赖于其之前计算的 RDD,产生了相关的依赖关系,如果某个 RDD 只依赖于一个 RDD 的运算就可以执行自身的计算,那么我们称之为叫做窄依赖,如果某一个 RDD 需要多个 RDD 反馈的结果才能够满足执行下一步执行的条件,这个时候我们就称之为 RDD 之间的关系叫做宽依赖。在具体的实际执行过程中窄依赖要远远优秀于宽依赖,所以我们需要将宽依赖拆分为窄依赖,这样就可以提升整体的执行效率,那么每遇到一个宽依赖之后,我们将其拆分为窄依赖,然后就可以称之为是一个新的阶段,也就是 stage。如图所示:

     

    在上图中,我们可以看到计算流程中一共由 4 个 RDD,RDD2/3/4 中有两个分区,所以我们可以发现 RDD2 和 RDD3 之间是具有宽依赖的,那么我们就需要将宽依赖拆分为窄依赖,如下图所示:

    我们可以发现,在这张图中,我们其实本质上并没有拆分原本的宽依赖,而是将执行的阶段做了一个划分,从原理性的角度上来说,依赖问题其实解决的主要就是内存的占用问题,作为 Spark 来说,它利用内存作为数据的临时缓存空间的计算方式速度的确很快,但是同时它也造成了对内存占用过大的情况,所以就可以出现这种情况,当宽依赖出现的时候,由于宽依赖的子 RDD 需要依赖的父 RDD 中的所有分区,所以一旦有一个分区数据的计算卡住就会导致整个 RDD 计算被卡住,但是父 RDD 中计算出的分区的数据结果是不会等待所有的分区都计算完成才会加入到子 RDD 的,这就导致每当父 RDD 算出一个分区数据就会被马上载入到子 RDD 的所有分区。这样的话,本身计算由于父 RDD 中的某个分区卡住无法继续进行,但是已经计算出的数据却被复制多份加载到了子 RDD 的所有分区,这样做的话对于内存占用过高,所以我们需要避免这种情况的产生,这个时候我们就通过拆依赖的方式来实现,当拆依赖之后,我们必须等到某个阶段执行完成之后才能执行下一阶段,如上图中,我们必须要等待 Stage1 执行完毕,所有的分区数据都计算完成才能执行 Stage2,数据也才能被加载到下一个 Stage 中,这样的话,我们就节约了内存,减小了占用率。这就是拆依赖的原理。

    RDD    Objects 产生 DAG,然后进入了 DAGScheduler 阶段,DAGScheduler 是面向

    stage 的高层次的调度器,DAGScheduler 把 DAG 拆分成很多的 tasks,每组的 tasks 都是一个 stage,每当遇到 shuffle 就会产生新的 stage,DAGScheduler

    需要记录那些 RDD 被存入磁盘等物化动作,同时需寻找 task 的最优化调度,例如数据本地性等;DAGScheduler 还要监视因为 shuffle 输出导致的失败;DAGScheduler 划分 stage 后以 TaskSet 为单位把任务交给底层次的可插拔的调度器 TaskScheduler 来处理;一个 TaskScheduler 只为一个 SparkContext 实例服务,TaskScheduler 接受来自 DAGScheduler 发送过来的分组的任务, DAGScheduler 给 TaskScheduler 发送任务的时候是以 Stage 为单位来提交的, TaskScheduler 收到任务后负责把任务分发到集群中 Worker 的 Executor 中去运行,如果某个 task 运行失败,TaskScheduler 要负责重试;另外如果 TaskScheduler 发现某个 Task 一直未运行完,就可能启动同样的任务运行同一个 Task,哪个任务先运行完就用哪个任务的结果。

    Spark 的应用调度全部都是由 Driver 来完成的,当一个请求从 Client 发送到 Driver 中时,Driver 就开始执行相关的调度执行 1.Driver 会根据用户提交的请求创建 DAG。Driver 主要分为两个核心进程,一个是 DAG 调度器,主要用来对提交的业务来进行相关的规划,需要控制对应的 RDD 的依赖关系并且根据该 RDD 的依赖关系做任务的切分,也就相当于是将 Application 切分为 Stage 的过程,切分完成之后,对应的执行控制是由 task 控制器来做的,它需要下发任务,监控任务,并且在任务出现问题的时候重启或者是重新下发任务。所以 DAG 调度器做的是计算的逻辑控制,task 调度器做的是具体的执行控制。

    2.创建完成之后就开始进行调度阶段,DAG 的调度器会将 DAG 切分为 task,其实也就相当于将 Application 切分为 task。task 是以组的形式存在的,一个组其实就是一个 stage,stage 中究竟有多少个 task 取决于 stage 中有多少个子 RDD,一个 RDD 对应的就是一个 task。

    3.DAG 从 Application 的层级开始逐层向下进行相关的检查操作,每遇到一个宽依赖就将其切分为窄依赖,然后将对应层级的 RDD 做切分,然后形成一个 stage。4.切分完成之后,DAG 就需要安排具体的执行的顺序和操作,其实这里也就相当于根据 RDD 之间的依赖关系开始做执行的安排。DAG 需要通过相关的规划执行,保障整体执行的最优化。效率达到最高。

    5.DAG 的调度器将任务安排好之后,就会将对应的 stage 分组任务交给 task 调度器去执行,task 调度器收到的执行要求是以 stage 为单位的,里面会根据 RDD 的个数产生对应多个的 task。

    6.task 调度器会将 Stage 中的 task 下发给 worker 中的 Executor 来执行,其实也就相当于是 task 是下发给 container 中的 executor 来执行的。

    7.task 调度器会实时的对计算的进度进行监控,当一个计算产生延迟并且长时无法返回对应的结果时,其会选择一个其他的 Executor 拉起该计算,两个进程谁先执行完,就使用谁的结果

    四、SparkSQL 技术原理

    SparkSQL 是 Spark 中基于 SparkCore 的一个计算工具,其将用户提交的SQL 语句解析成为 RDD,然后交由 SparkCore 执行,这样做我们就可以在 Spark

    中无缝对接 SQL 的语句查询,执行相关的任务。在 SparkSQL 中,我们使用的数据资源叫做 DataSet 和 DataFrame。具体的解释下文中将会详细阐述。

    DataSet 是一个由特定域的对象组成的强类型集合,可通过功能或关系操作并行转换其中的对象。Dataset 是一个新的数据类型。Dataset 与 RDD 高度类似,性能比较好。DataSet 以 Catalyst 逻辑执行计划表示,并且数据以编码的二进制形式存储,不需要反序列化就可以执行 sort、filter、shuffle 等操作。Dataset 与 RDD 相似, 然而, 并不是使用 Java 序列化或者 Kryo 编码器来序列化用于处理或者通过网络进行传输的对象。 虽然编码器和标准的序列化都负责将一个对象序列化成字节,编码器是动态生成的代码,并且使用了一种允许 Spark 去执行许多像 filtering, sorting 以及 hashing 这样的操作,

    不需要将字节反序列化成对象的格式。

    jvm 中存储的 java 对象可以是序列化的,也可以是反序列化的。序列化的对象是将对象格式化成二进制流,可以节省内存。反序列化则与序列化相对,是没有进行二进制格式化,正常存储在 jvm 中的一般对象。RDD 可以将序列化的二进制流存储在 jvm 中,也可以是反序列化的对象存储在 JVM 中。至于现实使用中是使用哪种方式,则需要视情况而定。例如如果是需要最终存储到磁盘的,就必须用序列化的对象。如果是中间计算的结果,后期还会继续使用这个结果,一般都是用反序列化的对象。

    本质上来说,RDD 和 DataSet 的区别并不大,他们都属于是特殊的数据形式,我们讲计算引擎在进行计算的时候,必须需要两个东西,一个是数据,一个是对数据的计算方法,也就是我们需要应用和数据。数据是信息载体,应用是对数据的操作手段和计算方法。

    由于 Spark 是在内存中进行计算的一种引擎,所以为了避免对内存的过度占用,我们一般会将数据进行序列化操作,也就是将原本正常的数据转换成为二进制表示来进行存储,这样做的好处就是节省内存,而 SparkCore 可以将源数据进行序列化操作,之后将产生的二进制数据直接封装到 RDD 中,当我们需要对其进行计算的时候,再把二进制数据转换为正常的数据,这样就是反序列化操作。Dataset 的优势就在于,其可以不进行反序列化,SparkSQL 可以直接识别出二进制数据的含义,这样节省了大量的计算延迟和转换开销。

    DataFrame 提供了详细的结构信息,使得 Spark SQL 可以清楚地知道该数据集中包含哪些列,每列的名称和类型各是什么。DataFrame 多了数据的结构信息,即 schema。这里主要对比 Dataset 和 DataFrame,因为 Dataset 和 DataFrame 拥有完全相同的成员函数,区别只是每一行的数据类型不同

    DataFrame 也可以叫 Dataset[Row],每一行的类型是 Row,不解析,每一行究竟有哪些字段,各个字段又是什么类型都无从得知,只能用 getAS 方法或者共性中的模式匹配拿出特定字段。而 Dataset 中,每一行是什么类型是不一定的,在自定义了 case class 之后可以很自由的获得每一行的信息,结合上图总结出,DataFrame 列信息明确,行信息不明确。

    由于 DataFrame 带有 schema 信息,因此,查询优化器可以进行有针对性的优化,以提高查询效率。

    DataFrame 在序列化与反序列化时,只需对数据进行序列化,不需要对数据结构进行序列化。

    Row:代表关系型操作符的输出行;类似 Mysql 的行。

    由于本身 SparkSQL 就是对接 SQL 指令的下发执行的,所以我们在看DataSet 和 DataFrame 的时候可以按照 SQL 的表格类型来看数据。DataSet 可以对应到 Row 上去理解。而行数据本身只有内容,不包含数据结构,如果需要让行包含数据结构,就需要我们自己通过 class 的类定义来实现。DataFrame 是站在列结构的角度上来对数据进行划分的,这个时候 DataFrame 是自身包含列的结构信息的,所以对于 DataFrame 来说,自身是携带数据和属性的,DataSet自身只有数据,属性信息可以通过配置携带。

    RDD:优点:类型安全,面向对象。缺点:RDD 无论是集群间的通信, 还是 IO 操作都需要对对象的结构和数据进行序列化和反序列化。序列化和反序列化的性能开销大;GC 的性能开销,频繁的创建和销毁对象, 势必会增加 GC。

    DataFrame:优点:自带 scheme(设计)信息,降低序列化反序列化开销。

    DataFrame 另一个优点,off-heap : 意味着 JVM 堆以外的内存, 这些内存直接受操作系统管理(而不是 JVM)。Spark 能够以二进制的形式序列化数据(不包括结构)到 off-heap 中, 当要操作数据时, 就直接操作 off-heap 内存. 由于 Spark 理解 schema, 所以知道该如何操作。缺点:不是面向对象的;编译期不安全。

    Dataset 的特点:快:大多数场景下,性能优于 RDD;Encoders 优于 Kryo

    或者 Java 序列化;避免不必要的格式转化。类型安全:类似于 RDD,函数尽可能编译时安全。和 DataFrame,RDD 互相转化。Dataset 具有 RDD 和 DataFrame的优点,又避免它们的缺点。

    五、Spark Structured Streaming 技术原理

    1.Spark Structured Streaming 概念

    Structured Streaming 是构建在 Spark SQL 引擎上的流式数据处理引擎。可以像使用静态 RDD 数据那样编写流式计算过程。当流数据连续不断的产生

    时,Spark SQL 将会增量的、持续不断的处理这些数据,并将结果更新到结果集中。

     

    从此处开始,后边会有很多的组件涉及到流式数据处理。那么目前在大数据的组件中,有很大的一部分都涉及到了流式数据处理。那么根据时间的进程,首先出现的是批处理,之后出现了流处理。批处理主要是针对于大量的小文件进行处理的一种方式。而流处理主要是针对于大型文件的处理。我们可以做一个想象,比如今天家里停水了,打开水龙头的时候,水断断续续的流出,这种可以理解成为是批处理的数据情况,而没有停水的时候,打开水龙头,水流持续流出,这个时候就可以理解为流式数据。而流式数据本身也具有顺序性和不可篡改的特性。其也是由很多的小水滴构成的,所以流式数据还是可以被切分成数据块的。

     

    批处理数据一般来说是针对于大量小文件的,对数据处理完成之后,比如一个批次的数据处理好,那么任务就结束了。而对于流处理数据来说,主要有两种组成方式,一种是少量的大文件,持续不断地输入构成流数据。另一种是业务持续存在,数据持续不断地从各个来源汇聚输入到引擎中构成数据流。目前在业务中,分析业务主要场景是流式数据的第一种。而互联网厂商,比如阿里、腾讯等企业更多的是使用后者。两种流式数据使用哪一种的本质区别就在于数据的来源,分析业务主要是用户自身拥有大量的数据。互联网厂商由于本身数据量产生较小,所以更多的是依托于后者,也就是底层用户产生数据,互联网厂商汇总进行分析构成流式数据。

     

    Structured Streaming 的核心是将流式的数据看成一张数据不断增加的数据库表,这种流式的数据处理模型类似于数据块处理模型,可以把静态数据库表的一些查询操作应用在流式计算中,Spark 执行标准的 SQL 查询,从无边界表中获取数据。

    无边界表:新数据不断到来,旧数据不断丢弃,实际上是一个连续不断的结构化数据流。

    在这种流程中,已经计算完成的数据被不断地丢弃,新的数据持续的被加入到数据集的末尾。对于这个数据集来说,是一个无头无尾的数据集。但是这样也体现了流式数据的持续性。

     

    Structured Streaming 的计算是按照时间顺序为方式来进行计算的。每一条查询的操作都会产生一个结果集 Result Table。每一个触发间隔,当新的数据新增到表中,都会最终更新 Result Table。无论何时结果集发生了更新,都能将变化的结果写入一个外部的存储系统。

    Structured Streaming 在 OutPut 阶段可以定义不同的数据写入方式,有如下 3 种:

    (1) Complete Mode:整个更新的结果集都会写入外部存储。整张表的写入操作将由外部存储系统的连接器完成。

    (2) Append Mode:当时间间隔触发时,只有在 Result Table 中新增加的数据行会被写入外部存储。这种方式只适用于结果集中已经存在的内容不希望发生改变的情况下,如果已经存在的数据会被更新,不适合适用此种方式。

    (3) Update Mode:当时间间隔触发时,只有在 Result Table 中被更新的数据才会被写入外部存储系统。注意,和 Complete Mode 方式的不同之处是不更新的结果集不会写入外部存储。

    三种模式的具体操作如下图所示,每种操作模式分别对应每一个时间的输入和输出操作:

     

    六、Spark Streaming 技术原理

    Spark Streaming 计算基于 DStream,将流式计算分解成一系列短小的批处理作业。

     

    Spark Streaming 本质仍是基于 RDD 计算,当 RDD 的某些 partition 丢失,可以通过 RDD 的血统机制重新恢复丢失的 RDD。

     

    事实上,Spark Streaming 绝对谈不上比 Storm 优秀。这两个框架在实时计算领域中,都很优秀,只是擅长的细分场景并不相同。Spark Streaming 仅仅在吞吐量上比 Storm 要优秀。对于 Storm 来说:

    1、建议在那种需要纯实时,不能忍受 1 秒以上延迟的场景下使用,比如实时金融系统,要求纯实时进行金融交易和分析。2、如果对于实时计算的功能中,要求可靠的事务机制和可靠性机制,即数据的处理完全精准,一条也不能多,一条也不能少,也可以考虑使用 Storm。3、如果还需要针对高峰低峰时间段,动态调整实时计算程序的并行度,以最大限度利用集群资源(通常是在小型公司,集群资源紧张的情况),也可以考虑用Storm。

    4、如果一个大数据应用系统,它就是纯粹的实时计算,不需要在中间执行 SQL 交互式查询、复杂的 transformation 算子等,那么用 Storm 是比较好的选择。对于 Spark Streaming 来说:

    1、如果对上述适用于 Storm 的三点,一条都不满足的实时场景,即,不要求纯实时,不要求强大可靠的事务机制,不要求动态调整并行度,那么可以考虑使用Spark Streaming。

    2、位于 Spark 生态技术栈中,因此 Spark Streaming 可以和 Spark Core、Spark SQL 无缝整合,也就意味着,我们可以对实时处理出来的中间数据,立即在程序中无缝进行延迟批处理、交互式查询等操作。这个特点大大增强了 Spark Streaming 的优势和功能。

     

    展开全文
  • 内存容量大小单位转换

    千次阅读 2019-08-01 10:55:28
    内存容量大小单位转换 B(Byte): 1Byte 等于 8bit KB: 1KB等于1024B MB: 1MB等于1024KB GB: 1GB等于1024MB TB: 1TB等于1024GB PB: 1PB等于1024TB 从大到小排序 PB>TB>GB>MB>KB>B ...

    内存容量大小单位转换


    B(Byte): 1Byte 等于 8bit
    KB: 1KB等于1024B
    MB: 1MB等于1024KB
    GB: 1GB等于1024MB
    TB: 1TB等于1024GB
    PB: 1PB等于1024TB

    从大到小排序
    PB>TB>GB>MB>KB>B

    展开全文
  • 市面上有一些初学者的误解,他们拿spark和hadoop比较时就会说,Spark是内存计算内存计算是spark的特性。请问在计算机领域,mysql,redis,ssh框架等等他们不是内存计算吗?依据冯诺依曼体系结构,有什么技术的程序...

           市面上有一些初学者的误解,他们拿spark和hadoop比较时就会说,Spark是内存计算,内存计算是spark的特性。请问在计算机领域,mysql,redis,ssh框架等等他们不是内存计算吗?依据冯诺依曼体系结构,有什么技术的程序不是在内存中运行,需要数据从硬盘中拉取,然后供cpu进行执行?所有说sprk的特点是内存计算相当于什么都没有说。那么spark的真正特点是什么?抛开spark的执行模型的方式,它的特点无非就是多个任务之间数据通信不需要借助硬盘而是通过内存,大大提高了程序的执行效率。而hadoop由于本身的模型特点,多个任务之间数据通信是必须借助硬盘落地的。那么spark的特点就是数据交互不会走硬盘。只能说多个任务的数据交互不走硬盘,但是sprk的shuffle过程和hadoop一样仍然必须走硬盘的。

    本文是翻译的出处 https://0x0fff.com/spark-misconceptions/。

    原文和作者一起讨论:http://www.cnblogs.com/intsmaze/p/7197420.html

    微信:intsmaze

    误解一:Spark是一种内存技术

      大家对Spark最大的误解就是spark一种内存技术。其实没有一个Spark开发者正式说明这个,这是对Spark计算过程的误解。Spark是内存计算没有错误,但是这并不是它的特性,只是很多专家在介绍spark的特性时,简化后就成了spark是内存计算。

      什么样是内存技术?就是允许你将数据持久化在RAM中并有效处理的技术。然而Spark并不具备将数据数据存储在RAM的选项,虽然我们都知道可以将数据存储在HDFS, HBase等系统中,但是不管是将数据存储在磁盘还是内存,都没有内置的持久化代码。它所能做的事就是缓存数据,而这个并不是数据持久化。已经缓存的数据可以很容易地被删除,并且在后期需要时重新计算。

      但是有人还是会认为Spark就是一种基于内存的技术,因为Spark是在内存中处理数据的。这当然是对的,因为我们无法使用其他方式来处理数据。操作系统中的API都只能让你把数据从块设备加载到内存,然后计算完的结果再存储到块设备中。我们无法直接在HDD设备上计算;所以现代系统中的所有处理基本上都是在内存中进行的。

      虽然Spark允许我们使用内存缓存以及LRU替换规则,但是你想想现在的RDBMS系统,比如Oracle ,你认为它们是如何处理数据的?它们使用共享内存段作为table pages的存储池,所有的数据读取以及写入都是通过这个池的,这个存储池同样支持LRU替换规则;所有现代的数据库同样可以通过LRU策略来满足大多数需求。但是为什么我们并没有把Oracle 称作是基于内存的解决方案呢?再想想操作系统IO,你知道吗?所有的IO操作也是会用到LRU缓存技术的。

      Spark在内存中处理所有的操作吗?Spark的核心:shuffle,其就是将数据写入到磁盘的。shuffle的处理包括两个阶段:map 和 reduce。Map操作仅仅根据key计算其哈希值,并将数据存放到本地文件系统的不同文件中,文件的个数通常是reduce端分区的个数;Reduce端会从 Map端拉取数据,并将这些数据合并到新的分区中。所有如果你的RDD有M个分区,然后你将其转换成N个分区的PairRDD,那么在shuffle阶段将会创建 M*N 个文件!虽然目前有些优化策略可以减少创建文件的个数,但这仍然无法改变每次进行shuffle操作的时候你需要将数据先写入到磁盘的事实!

     

    所以结论是:Spark并不是基于内存的技术!它其实是一种可以有效地使用内存LRU策略的技术。

    误解二:Spark要比Hadoop快 10x-100x

      大家在Spark的官网肯定看到了如下所示的图片

     

      这个图片是分别使用 Spark 和 Hadoop 运行逻辑回归(Logistic Regression)机器学习算法的运行时间比较,从上图可以看出Spark的运行速度明显比Hadoop快上百倍!但是实际上是这样的吗?大多数机器学习算法的核心部分是什么?其实就是对同一份数据集进行相同的迭代计算,而这个地方正是Spark的LRU算法所骄傲的地方。当你多次扫描相同的数据集时,你只需要在首次访问时加载它到内存,后面的访问直接从内存中获取即可。这个功能非常的棒!但是很遗憾的是,官方在使用Hadoop运行逻辑回归的时候很大可能没有使用到HDFS的缓存功能,而是采用极端的情况。如果在Hadoop中运行逻辑回归的时候采用到HDFS缓存功能,其表现很可能只会比Spark差3x-4x,而不是上图所展示的一样。

    根据经验,企业所做出的基准测试报告一般都是不可信的!一般独立的第三方基准测试报告是比较可信的,比如:TPC-H。他们的基准测试报告一般会覆盖绝大部分场景,以便真实地展示结果。

    一般来说,Spark比MapReduce运行速度快的原因主要有以下几点:

    • task启动时间比较快,Spark是fork出线程;而MR是启动一个新的进程;
    • 更快的shuffles,Spark只有在shuffle的时候才会将数据放在磁盘,而MR却不是。
    • 更快的工作流:典型的MR工作流是由很多MR作业组成的,他们之间的数据交互需要把数据持久化到磁盘才可以;而Spark支持DAG以及pipelining,在没有遇到shuffle完全可以不把数据缓存到磁盘。
    • 缓存:虽然目前HDFS也支持缓存,但是一般来说,Spark的缓存功能更加高效,特别是在SparkSQL中,我们可以将数据以列式的形式储存在内存中。

      所有的这些原因才使得Spark相比Hadoop拥有更好的性能表现;在比较短的作业确实能快上100倍,但是在真实的生产环境下,一般只会快 2.5x ~ 3x!

      吹一波水,最近太忙了,不仅要克服竞争对手给的数据中埋的雷,还要不断和比利时的合作伙伴通邮件去核对项目的进度与解决方案。但是不妨碍我每月更新一篇文章,-_-。

                                                   老铁,点赞,关注

     

    展开全文
  • 摘要  我们提出的弹性分布式数据集(RDDs),是一个让程序员在大型集群上以容错的方式...为了有效容错,RDDs提供一种受限的共享内存,基于粗粒度转换(transformations)而非细粒度地更新共享状态。尽管如此,RDD...
  • java计算机硬盘大小转换(B,KB,MB,GB,TB,PB之间的大小转换) java 硬盘大小转换 数据转换 内存转换 存储大小转换
  • 将用户程序中的指令或数据的逻辑地址转换为存储空间中物理地址的工作称为地址转换或重定位(有些地方称做地址映射、内存映射)。这个过程一般由内存管理单元(MMU)来完成。地址转换有两种方法:静态重定位、动态重...
  • 计算机各进制之间的转换

    万次阅读 2016-05-15 19:32:12
    今天翻了一本计算机基础的书籍,其中十进制、二进制、八进制、十六进制之间的转换挺有意思的,也容易犯糊涂,特温故而知新。   十进制数制系统  十进制数制系统包括 10 个数字:0、1、2、3、4、5、6、7...
  • 这是一个内存地址大小的计算工具,非常好用
  • 计算机内存寻址

    千次阅读 2015-11-01 23:14:22
    计算机管理内存的基本方式有两种:段式管理和页式管理。而在使用80x86微处理器时,内存地址分为三个不同的地址:逻辑地址,线性地址,物理地址。他们之间有什么关系,内存是如何寻址,本文主要介绍的就是内存寻址。 ...
  • 如何计算内存大小

    千次阅读 2020-11-22 23:16:19
    对电子产品、存储介质厂家...1、因为我们通常说的内存都是使用的十进制来表示的(如256MB、512MB等),所以我们计算内存大小时只需将所对应的地址转化成十进制即可。 2、转换规则: 1MB=1024KB ,1KB=1024Byte ,1Byte
  • 分页内存管理——虚拟地址到物理地址的转换

    万次阅读 多人点赞 2018-08-10 23:30:57
    此篇博客内容在于着重帮助读者明白在分页内存管理下,虚拟地址和物理地址转换计算是怎么进行的。 有关分页内存管理的其他知识请事先参阅有关资料。^_^ 一、在计算之前需要了解如下知识: 1.对每个程序而言,...
  • 十六进制和二进制之间的转换十六进制由0-9和A-F组成,对应于十进制的0-15,对应于二进制为4位;故十六进制和二进制之间的转换比较直接,示例如下: 1. 将二进制转换为十六进制:每4个二进制位为一个段转换为相应的...
  • float在内存中的数据格式及其转byte数组原理及转换过程参考文章 转换说明 https://blog.csdn.net/yezhubenyue/article/details/7436624 进制转换 http://www.cnblogs.com/xkfz007/articles/2590472.html float在...
  • 今天学习了 分页机制中的 虚拟内存地址到物理内存地址的转换,做些笔记。 首先也是非常需要注意的是这个 PAE ( 物理 地址 扩展),这个东西是默认开启的,由于 不开启 PAE 时候的计算要相对简单一些,所以从简单...
  • 内存地址转换与分段

    千次阅读 2009-06-11 23:25:00
    原文标题:Memory Translation and Segmentation原文地址:...] 本文是Intel兼容计算机(x86)的内存与保护系列文章的第一篇,延续了启动引导系列文章的主题,进一步分析操作系统内核的工作流程。与
  • 使用C语言编写一个函数,函数的...该函数可以应用在串口通信中,如果收到对方发来的字符串信息,必须转换为数值,才能参与后续计算。请使该函数在时间和内存开销上最优。 没有做过时间和内存开销上最优,求大神帮忙
  • Spark 介绍(基于内存计算的大数据并行计算框架)  Hadoop与Spark 行业广泛使用Hadoop来分析他们的数据集。原因是Hadoop框架基于一个简单的编程模型(MapReduce),它支持可扩展,灵活,容错和成本...
  • 内存地址的计算方法

    千次阅读 2017-10-25 16:00:00
    内存是按字节编址的,所以单位是字节哈,1字节可是等于8位的。因为计算的范围一般比较小,所以就记住两个就够了。记住几个常用的2的10次方为1024即1KB 2的20次方=(2的10次方)的平方,即1MB就行了 如果要求更大的,...
  • 1.内存地址通常以十六进制的数字表示,转换成二进制 2.计算字节数   例: 内存地址按字节编址,地址从A4000H到CBFFFH,共有__________字节。 1.CBFFFH - A4000H = 27FFFH 2.27FFF = 2的15次方 + 2的17次方 ...
  • 1. 引言  要成为一个程序编写高手,不仅需要熟悉各种计算机语言,而且还需要懂得计算机是如何工作的。虽然不必对计算机的各个部件...其实,有关计算机内存管理的书籍已经很多了,为了加深读者对这些内存管理函数使用方
  • 网上有不少人都是用查表的方式进行转换,但是这种方法显然很笨重,而且工作量也不小,还占用不少内存。 我今天介绍的是使用的Omega官方的转换多项式来转换的。 K型热电偶的的温度与电压曲线并非直线,但是其在-50°...
  • MEC —— 优化内存与速度的卷积计算

    千次阅读 2017-08-20 13:01:03
    本次介绍一种内存利用率高且速度较快的卷积计算方法。 来自ICML2017, 《MEC: Memory-efficient Convolution for Deep Neural Network》1. 背景工作目前的CNN模型中,全连接层往往在最后一层才会使用。 意思也就是说...
  • linux 查看内存排行并进行计算

    千次阅读 2018-04-16 14:18:28
    aux | sort -k6nr | head -n 100 | awk '{sum+=$6} END {print sum}'解释:使用ps 将进程列出,并使用sort 进行排序,-k 指定排序的位置,这里是第6个域,nr 是按照数值大小反向排序,后面的head是对100个进行计算,...
  • OS-计算机体系结构和内存层次

    千次阅读 2017-08-06 10:02:31
    计算机体系结构关心点:CPU中的高速缓存,可参考百科先初步了解下: ...CPU在处理时,如果在高速缓存L1,L2中未命中,会去内存中找,如果还是不命中,如果应用程序涉及到虚拟存储,缺页后操作系统
  • 内存计算——HANA>> 书评

    千次阅读 2013-08-27 00:02:59
    《SAP内存计算——HANA》又是一本在地铁里读完的书,最近阅读量大增,都是托了地铁的福了。一年多以前就在ITPUB里发过帖子问“SAP HANA归根揭底到底是什么?”,那时通过一些网络上的文章对SAP HANA有了简单认识,但...
  • MMU的主要作用:虚拟地址到物理地址的转换;访问权限控制;设置虚拟存储空间的缓冲。 虚拟存储器:程序一般存于掉电不丢失的硬盘中,但是硬盘读写速度慢。所以系统上电后一般只在ROM中完成小部分硬件初始化程序,并...
  • 第一周编程题(计算,温度转换问题)

    千次阅读 2019-05-13 09:37:33
    温度转换(5分) 题目内容: ...提示,为了把计算结果的浮点数转换成整数,需要使用下面的表达式: (int)x; 其中x是要转换的那个浮点数。 注意:除了题目要求的输出,不能输出任何其他内容,比如输...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 531,605
精华内容 212,642
关键字:

内存转换计算