目录
- 大数据
- 大数据基础
- 大数据概述
- 大数据存储
- 分布式文件系统HDFS
- 分布式数据库HBASE
- NoSQL数据库
- 云数据库
- 大数据处理与分析
- MapReduce
- Spark
- 流计算
- 图计算
- 数据可视化
- 大数据应用
- 云计算
- 云概念
- 云架构
- 云组件
- 云技术
- 云端技术
- 终端技术
- 云安全
- 信息管理与数据安全
- 计算可用性
- 互操作性和可移植性
- 云应用
- 云方案
大数据
大数据基础
大数据概述
- 数据产生方式经历的几个阶段
- 运营式系统阶段
- 用户原创内容阶段
- 感知式系统阶段
- 三次信息化浪潮
- 大数据概念/4个基本特征(4v)
- 数据量大(volume)
- 数据类型繁多(variety)
- 处理速度快(velocity)
- 价值密度低(value)
- 数据研究经历的四个阶段:实验、理论、计算、数据
- 大数据技术
- 是伴随着大数据的采集、存储、分析和应用的相关技术,是一系列使用非传统的工具对大量的结构化、半结构化、非结构化数据进行处理,从而获得分析和预测结果的一系列数据处理和分析技术
- 大数据基本处理流程
- 大数据技术的主要内容
- 数据采集
- 利用ETL工具将分布的、异构数据源中的数据,抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础;
- 把实时采集的数据作为流计算系统的输入,进行实时处理分析
- 数据存储和管理
- 利用分布式文件系统、数据仓库、关系数据库、NoSQL数据库、云数据库等,实现对结构化、半结构化和非结构化海量数据的存储和管理
- 数据处理与分析
- 利用分布式并行编程模型和计算框架,结合机器学习和数据挖掘算法,实现对海量数据的处理和分析
- 对分析结果进行可视化呈现,帮助人们更好地理解数据、分析数据
- 数据隐私和安全
- 在从大数据中挖掘潜在的巨大商业价值和学术价值的同时,构建隐私数据保护体系和数据安全体系,有效保护个人隐私和数据安全
- 大数据关键技术
- 分布式存储:GFS/HDFS、BigTable/HBase、NoSQL
- 分布式处理:MapReduce
- 大数据计算模式
- 大数据产业
- IT基础设施层
- 数据源层
- 数据管理层
- 数据分析层
- 数据平台层
- 数据应用层
- 大数据与云计算、物联网
- 云计算:实现了通过网络提供可伸缩的、廉价的分布式计算机能力,用户只需要在具备网络接入条件的地方,就可以随时随地地获得所需的各种IT资源。关键技术包括:虚拟化、分布式存储、分布式计算、多租户等
- 物联网:物物相连的互联网,利用局部网络或互联网等通信技术把传感器、控制器、机器、人类和物等通过新的方式连在一起,形成人与物、物与物相连,实现信息化和远程管理控制
- 区别:大数据侧重于数据的存储、处理与分析,云计算侧重于整合和优化各种IT资源并通过网络廉价提供给用户;物联网侧重于物物相连,核心是应用创新
- 联系:云计算为大数据提供了技术基础,大数据为云计算提供用武之地;物联网是大数据的重要来源,大数据为物联网提供支撑;云计算为物联网提供海量存储能力,物联网为云技术提供应用空间
大数据存储
分布式文件系统HDFS
- 分布式文件系统
- 是一种通过网络实现文件在多台主机上进行分布式存储的文件系统
- 分布式文件系统把把文件分布存储到多个计算机节点上,成千上万的计算机节点构成计算机集群
- 分布式文件系统设计的需求
设计需求 | 含义 | HDFS实现情况 |
透明性 | 具备访问透明性、位置透明性、性能和伸缩透明性 | 只能提供一定程度的访问透明性,完全支持位置透明性、性能和伸缩透明性 |
并发控制 | 客户端对文件的读写不应该影响其他客户端对同一文件的读写 | 机制非常简单,任何时候只允许有一个程序写某个文件 |
文件复制 | 一个文件可以拥有不同位置的多个副本 | HDFS采用了多副本机制 |
硬件和操作系统的异构性 | 可以在不同的操作系统和计算机上实现同样的客户端和服务端程序 | 采用Java语言开发,具有很好的跨平台能力 |
可伸缩性 | 支持节点的动态加入或退出 | 建立在大规模廉价机器上的分布式文件系统集群,具有很好的伸缩性 |
容错 | 保证文件服务在客户端或服务端出现问题时能正常使用 | 具有多副本机制和故障自动检测、恢复机制 |
安全 | 保证系统安全性 | 安全性较弱 |
- 分布式文件系统的结构(分布式文件系统是如何实现较高水平扩展的)
- 在物理结构上是由计算机集群中的多个节点构成的
- 这些节点分为两类,一类叫“主节点”(Master Node)或者也被称为“名称结点”(NameNode),一类叫“从节点”(Slave Node)或者也被称为“数据节点”(DataNode)
- HDFS中的块与普通文件系统中块的区别
- 传统文件系统中,为了提高磁盘读写效率,一般以数据库为单位,而不是以字节为单位
- HDFS中的块 ,默认一个块大小为64MB,而HDFS中的文件会被拆分成多个块,每个块作为独立单元进行存储。HDFS在块的大小的设计上明显要大于普通文件系统。
- HDFS简介
- HDFS要实现以下目标:
- 兼容廉价的硬件设备
- 流数据读写
- 大数据集
- 简单的文件模型
- 强大的跨平台兼容性
- 局限性
- 不适合低延迟数据访问
- 无法高效存储大量小文件
- 不支持多用户写入及任意修改文件
- HDFS相关概念
- 块:HDFS默认一个块64MB,块的大小远远大于普通文件系统
- 名称节点:负责管理分布式文件系统的命名空间,保存了两个核心的数据结构,即FsImage和EditLog
- 数据节点:分布式文件系统HDFS的工作节点,负责数据的存储和读取,会根据客户端或者是名称节点的调度来进行数据的存储和检索,并且向名称节点定期发送自己所存储的块的列表
- 第二名称节点:完成EditLog与FsImage的合并操作,减小EditLog文件大小,缩短名称节点重启时间;其次,作为名称节点的“检查点”,保存名称节点中的元数据信息。
- HDFS体系结构
- 主从结构模型,一个HDFS集群包括一个名称节点和若干个数据节点
- 名称节点作为中心服务器,负责管理文件系统的命名空间及客户端对文件的访问。集群中的数据节点一般是一个节点运行一个数据节点进程,负责处理文件系统客户端的读/写请求,在名称节点的统一调度下进行数据块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地Linux文件系统中的
- 局限性:
- 命名空间的限制:名称节点是保存在内存中的,因此,名称节点能够容纳的对象(文件、块)的个数会受到内存空间大小的限制
- 性能的瓶颈:整个分布式文件系统的吞吐量,受限于单个名称节点的吞吐量
- 隔离问题:由于集群中只有一个名称节点,只有一个命名空间,因此,无法对不同应用程序进行隔离
- 集群的可用性:一旦这个唯一的名称节点发生故障,会导致整个集群变得不可用
- 命名空间
- 包含目录、文件和块
- 在HDFS1.0体系结构中,在整个HDFS集群中只有一个命名空间,并且只有唯一一个名称节点,该节点负责对这个命名空间进行管理
- HDFS使用的是传统的分级文件体系,因此,用户可以像使用普通文件系统一样,创建、删除目录和文件,在目录间转移文件,重命名文件等
- 通信协议
- HDFS是一个部署在集群上的分布式文件系统,因此,很多数据需要通过网络进行传输
- 所有的HDFS通信协议都是构建在TCP/IP协议基础之上的
- 客户端通过一个可配置的端口向名称节点主动发起TCP连接,并使用客户端协议与名称节点进行交互
- 名称节点和数据节点之间则使用数据节点协议进行交互
- 客户端与数据节点的交互是通过RPC(Remote Procedure Call)来实现的。在设计上,名称节点不会主动发起RPC,而是响应来自客户端和数据节点的RPC请求
- 试述HDFS是如何减轻中心节点的负担
- HDFS的文件块为64M,该设计导致NameNode的元数据较少,减少元数据占用NameNode内存容量;
- HDFS集群只有一个名称节点,该节点负责所有数据的管理,这种设计大大简化了分布式文件系统的结构。可以保证数据不会脱离名称节点的控制;同时数据块数据不会经过名称节点,大大减轻中心服务器的负担,方便数据管理
- HDFS存储原理
- 数据的冗余存储
- 多副本方式,通常一个数据块的多个副本会被分布到不同的数据节点上
- 优点:加快数据传输速度、容易检查数据错误、保证数据可靠性
- 数据存取策略
- 数据存放
- 为了提高数据的可靠性与系统的可用性,以及充分利用网络带宽,采用机架为基础的数据存放策略
- 默认每个数据节点都在不同机架上,缺点是不能充分利用同一机架内部及其之间的带宽;优点是:首先,数据可靠性高,即使一个机架发生故障,其他机架上数据副本仍是可用的;其次,在读取数据时,可以在多个机架上并行读取数据,大大提高了数据读取数据;最后,可以更容易地实现系统内部负载均衡和错误处理
- 默认冗余复制因子为3,其副本放置策略:
- 第一个副本:放置在上传文件的数据节点;如果是集群外提交,则随机挑选一台磁盘不太满、CPU不太忙的节点;第二个副本:放置在与第一个副本不同的机架的节点上;第三个副本:与第一个副本相同机架的其他节点上;更多副本:随机节点
- 数据读取:HDFS提供了一个API可以确定一个数据节点所属的机架ID,客户端也可以调用API获取自己所属的机架ID;当客户端读取数据时,从名称节点获得数据块不同副本的存放位置列表,列表中包含了副本所在的数据节点,可以调用API来确定客户端和这些数据节点所属的机架ID,当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时,就优先选择该副本读取数据,如果没有发现,就随机选择一个副本读取数据
- 数据复制:流水线复制策略。当客户端要往HDFS写入一个文件时,这个文件首先被写入本地,并被分成若干个块,每个块向HDFS集群中名称节点发起写请求,名称节点会根据系统中各个数据节点的使用情况,选择一个数据节点列表返回客户端,然后客户端就把数据首先写入列表中第一个数据节点,同时把列表传给第一个数据,当第一个数据节点接收到4KB数据时,写入本地,并向第二个数据节点发起连接请求,把自己已经接到的4KB数据和列表传给第二个数据节点,当第二个数据节点接收到4KB数据时,写入本地,并向第三个数据节点发起连接请求,依此类推,列表中多个数据节点形成一条数据复制的流水线
- 数据错误与恢复
- 名称节点出错:第一:把名称节点上的元数据信息同步存储到其他文件系统;第二:运行一个第二名称节点。一般把两种方式结合使用,当名称节点发生宕机时,首先到远程挂载的网络文件系统中获取备份的元数据信息,放到第二名称节点上进行恢复,并把第二名称节点作为名称节点来使用(备份机制)
- 数据节点出错:由于一些数据节点的不可用,会导致一些数据块的副本数量小于冗余因子。名称节点会定期检查这种情况,一旦发现某个数据块的副本数量小于冗余因子,就会启动数据冗余复制,为它生成新的副本
- 数据出错: md5和sha1对数据块进行校验
- HDFS读数据过程
- 客户端通过FileSystem.open()打开文件,HDFS会创建输入流
- 输入流远程调用名称节点,获得文件开始部分数据块保存位置
- 客户端调用read()函数读取数据
- 数据从该数据节点读到客户端;当该数据块读取完毕时,关闭和数据节点的连接
- 输入流查找下一个数据块
- 找到数据块的最佳数据节点,读取数据
- 当客户端读取完毕时,关闭输入流
- HDFS写数据过程
- 客户端通过FileSystem.create()创建文件
- 输出流通过RPC远程调用名称节点,在文件系统的命名空间创建一个新的文件
- 获得输出流以后,客户端调用输出流的write()方法向HDFS中对应的文件写入数据
- 客户端向输出流中写入的数据首先会被分成一个个分包,放入内部队列。输出流会向名称节点申请保存文件和副本数据块的若干数节点,幸好层数据流管道。类似流水线复制策略,数据包会流经管道上各个数据节点
- 数据通过网络发送。为了保证所有数据节点数据是准确的,数据节点要发送“确认包”,经数据流管道最终发往客户端,客户端收到应答时,将对应的分包从内部队列移除,不断执行(3)~(5),直至数据全部写完
- 客户端调用close()关闭输出流。
分布式数据库HBASE
- 概述
- HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库,主要用来存储非结构化和半结构化的松散数据
- HBase与其它组成部分的相互关系
- HBase利用Hadoop MapReduce来处理HBase中的海量数据,实现高性能计算;利用Zookeeper作为协同服务,实现稳定服务和失败恢复;使用HDFS作为高可靠的底层存储,利用廉价集群提供海量数据存储能力;Sqoop为HBase的底层数据导入功能,Pig和Hive为HBase提供了高层语言支持,HBase是BigTable的开源实现
- HBase与传统关系数据库的对比分析
对比 | HBase | 传统关系数据库 |
数据类型 | 关系模型 | 存储为未经解释的字符串 |
数据操作 | 丰富 | 不存在复杂的表与表关系 |
存储模式 | 行 | 列 |
数据索引 | 复杂的多个索引 | 行键 |
数据维护 | 更新操作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。 | 更新操作不会删除数据旧版本,而是生成一个新版本 |
可伸缩性 | 很难实现横向扩展,纵向扩展的空间也比较有限 | 轻易地通过在集群中增加或减少硬件数量来实现性能的伸缩。 |
- HBase数据模型
- HBase是一个稀疏、多维度、排序的映射表,采用行键 、列族、列限定符和时间戳进行索引
- 数据模型相关概念
- 行:每个HBase表都由若干行组成,每个行由行键来标识
- 行键:一个表只出现一次,否则就是在更新同一行,行键可以是任意字节数组
- 列族:基本的访问控制单元。需要在表创建时就定义好,数量不能太多,而且不能频繁修改
- 列限定符:列族里的数据通过列限定符来定位
- 时间戳:每个单元格都保存着同一份数据的多个版本,这个版本采用时间戳索引。可以由用户自己赋值,也可以由HBase在数据写入时自动赋值
- 面向列的存储
- 行式数据库使用NSM存储模型,一个元组会被连续地存储在磁盘页中,也就是说,数据是一行一行被存储的;列式数据库采用DSM存储模型,以关系数据库中的属性或列为单位进行存储,关系中多个元组的同一属性值会被存储在一起,而一个元组中不同属性值通常会被分别存放于不同的磁盘页中
- 行式数据库主要适合于小批量的数据处理,列式数据库主要适合于批量数据处理和即席查询
- 优点:降低I/O开销,支持大量并发用户查询,数据处理速度快
- 缺点:执行连接操作时需要昂贵的元组重构代价
NoSQL数据库
- 简介
- Not only SQL:非关系型数据库的统称 ,所采用的数据模型并非传统关系数据库的关系模型,而是类似键/值、列族、文档等非关系模型,没有固定的表结构,通过也不存在连接操作,也没有严格遵守ACID约束
- 三个特点:
- 灵活的可扩展性
- 灵活的数据模型
- 与云计算紧密融合
- NoSQL与关系数据库的比较
比较标准 | 关系数据库 | NoSQL |
数据库原理 | 完全支持 | 部分支持 |
数据规模 | 大 | 超大 |
数据库模式 | 固定 | 灵活 |
查询效率 | 快 | 可以实现高效的简单查询,但不具备高度结构化查询特性 |
一致性 | 强一致性 | 弱一致性 |
数据完整性 | 容易实现 | 很难实现 |
扩展性 | 一般 | 好 |
可用性 | 好 | 很好 |
标准化 | 是 | 否 |
技术支持 | 高 | 低 |
可维护性 | 复杂 | 复杂 |
- NoSQL的特点
- 运行在PC服务器集群上,成本很低
- 省去关系数据与非关系数据的转换环节,执行速度更快
- 满足企业具体需求,操作简捷
- 大多数是开源项目,支持者源于社区
- 弹性扩展
- 大数据量的存储与管理
- 灵活的数据模型
- 四大类型
四大类型 | 键值数据库 | 列族数据库(Hbase) | 文档数据库 | 图数据库 |
适用场合 | 通过键来查询的业务 | 不需要ACID事务支持的情形 | 只在相同的文档上添加事务 | 具有高度相互关联关系的数据 |
模型 | 键/值对 | 列族 | 键/值,值是版本化的文档 | 图结构 |
优点 | 扩展性好,灵活性好,大量写操作时性能高 | 查找速度快,可扩展性强,容易进行分布式扩展,复杂性低 | 性能好,灵活性高,复杂性低,数据结构灵活 | 灵活性高,支持复杂的图形算法,可用于构建复杂的关系图谱 |
缺点 | 无法存储结构化信息,条件查询效率较低 | 功能较少,大都不支持强事务一致性 | 缺乏统一的查询语法 | 复杂性高,只能支持一定的数据规模 |
- 三大基石
- CAP
- C(Consistency):一致性,是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的,或者说,所有节点在同一时间具有相同的数据
- A:(Availability):可用性,是指快速获取数据,可以在确定的时间内返回操作结果,保证每个请求不管成功或者失败都有响应;
- P(Tolerance of Network Partition):分区容忍性,是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行,也就是说,系统中任意信息的丢失或失败不会影响系统的继续运作
- 当处理CAP的问题时,可以有几个明显的选择(不同产品在设计时,是如何运用CAP理论的)
- CA:强调一致性(C)和可用性(A),放弃分区容忍性(P),最简单的做法是把所有与事务相关的内容都放到同一台机器上。扩展性都比较差(MySQL,SQLServer)
- CP:强调一致性(C)和分区容忍性(P),放弃可用性(A),当出现网络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务(MongoDB,HBase等NoSQL数据库)
- AP:强调可用性(A)和分区容忍性(P),放弃一致性(C),允许系统返回不一致的数据(Dynamo、Riak)
- BASE
- 一个数据库事务具有ACID四性
- A(Atomicity):原子性,是指事务必须是原子工作单元,对于其数据修改,要么全都执行,要么全都不执行
- C(Consistency):一致性,是指事务在完成时,必须使所有的数据都保持一致状态
- I(Isolation):隔离性,是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
- D(Durability):持久性,是指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致命的系统故障也将一直保持
- BASE
- 基本可用(Basically Availble):是指一个分布式系统的一部分发生问题变得不可用时,其他部分仍然可以正常使用,也就是允许分区失败的情形出现
- 软状态(Soft-state):是与“硬状态(hard-state)”相对应的一种提法。数据库保存的数据是“硬状态”时,可以保证数据一致性,即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步,具有一定的滞后性
- 最终一致性(Eventual consistency):允许系统的状态或者多个副本之间存在暂时的不一致,但随着时间的推移,总会变得一致。这种不一致的实际一般不会过长,但要视具体情况而定。
- 最终一致性
- 最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以区分为:因果一致性; “读己之所写”一致性;会话一致性;单调读一致性;单调写一致性。
- NewSQL
- NewSQL是对各种新的可扩展、高性能数据库的简称,这类数据库不仅具有NoSQL对海量数据的存储管理能力,还保持了传统数据库支持ACID和SQL特性
云数据库
- 云数据库是部署和虚拟化在云计算环境中的数据库
- 云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点
- 云计算的三种类型:IaaS、PaaS、SaaS
- 云数据库系统架构:UMP系统
- UMP系统功能:容灾,读写分离,分库分表,资源管理、资源调度、资源隔离、数据安全
大数据处理与分析
MapReduce
- MapReduce采用“分而治之”策略,一个存储在分布式文件系统中的大规模数据集,会被切分成许多独立的分片,这些分片可以被多个Map任务并行处理,MapReduce设计的一个理念就是“计算向数据靠拢”
- MapReduce工作流程
- Map和Reduce函数的输入、输出及处理过程
- MapRecude算法执行过程
- MapReduce框架使用InputFormat模块做Map前预处理;然后将输入文件切分成逻辑上的多个InputSplit
- 因为InputSplit是逻辑切分而非物理切分,所以,还需要通过RecordReader根据InputSplit中的信息来处理InputSplit中的具体记录,加载数据并转换为适合Map任务读取的键值对,输入给Map任务
- Map任务会根据用户自定义的映射规则, 输出一系列的<key,value>作为中间结果
- 为了让Reduce可以并行处理Map的结果,需要对Map的输出进行一定的分区、排序、合并、归并等操作,得到<key,value-list>形式的中间结果,再交给对应的Reduce进行处理,这个过程称为Shuffle
- Redecu以一系列<key,value-list>中间结果作输入,执行用户定义的逻辑,输出结果给OutputFormat模块
- OutputFormat模块会验证输出目录是否已经存在以及输出结果类型是否符合配置文件中的配置类型,如果都满足,就输出Reduce的结果到分布式文件系统
- 适合用MapReduce处理数据集需要满足的前提条件:待处理数据可以分解成许多小数据集,而且每一个小数据集都可以完全并行地进行处理
- MapReduce模型采用Master(JobTracker)-Slave(TaskTracker)结构,试描述JobTracker和TaskTracker功能
- Master上运行JobTracker,Slave上运行TaskTracker,用户提交的每个计算作业,会被划分成若干个任务, JobTracker负责作业和任务的调度,监控他们的执行,并重新调度已经失败的任务。TaskTracker负责执行由JobTracker指派的任务
- Shuffle过程
- Map端的Shuffle过程
- 输入数据和执行Map任务
- 写入缓存
- 溢写(分区、排序和合并)
- 文件归并
- Reduce端的Shuffle过程
- “领取”数据
- 归并数据
- 把数据输入Reduce任务
- MapReduce的本地计算和原因
- 移动数据需要大量的网络传输开销,尤其是在大规模数据环境下,开销尤其惊人
- 本地计算指在一个集群中,只要有可能,MapReduce框架就会将Map程序就近地在HDFS数据所在的节点运行,即将计算节点和存储节点放在一起运行,从而减少节点间数据移动开销
- 不是所有的MapReduce程序都需要Map和Reduce两个过程,对于关系的选择运算,只需要经过Map过程就能实现,对于关系R中的每个元组t,检测是否满足条件所需元组,如果满足条件,则输出键值对。此时,键和值都是t,Reduce函数是一个恒等式。
- Map和Reduce任务数量
- Map任务数量取决于MapReduce作业大小
- Reduce任务数据取决于Map输出结果中key的数量
- 试用MapReduce来对英语句子“Whatever is worth doing is worth doing well”进行词频统计过程
- MapReduce数如何保证相同单词数据汇划分到同一个Reduce上进行处理?
- 对有相同KEY的Map输出的键值对进行归并,得到新的键值对作为Reduce任务的输入,由Reduce任务计算每个单词出现的次数,以保证结果的正确性
Spark
- Spark是基于内存计算的大数据并行计算框架,可用于构建大型的、低延迟的数据分析应用程序。
- Spark特点:运行速度快;容易使用;通用性;运行模式多样
- Hadoop的缺点:表达能力有限;磁盘I/O开销大;延迟高
- Spark的优点:
- 计算模式也属于MapReduce,但不局限于Map和Reduce操作,还提供了多种数据集操作类型,编程模型比MapReduce更灵活
- Spark提供了内存计算,中间结果直接存放内存中,带来更高的迭代运算效率
- Spark基于DAG的任务调度执行机制,要优于MapReduce的迭代执行机制
流计算
- 流数据:数据以大量、快速、时变的流形式持续到达
- 批处理计算与流计算的比较
- 对于批处理来说,数据装载、数据计算本身是完全脱节的过程,数据是一批批加载,计算也是一批批请求;同时,它还是一个高时延的计算,还是一个主动发起的计算
- 流计算是持续的,只要有数据输入就会持续计算;它是低时延的,是一个事件触发计算
- 流处理系统与传统的数据处理系统区别:
- 流处理系统处理的是实时数据,而传统的数据处理系统处理的是预先存储好的静态数据
- 用户通过流处理系统获取的是实时结果,而通过传统数据处理系统获取的是过去某一时间的结果。
- 流处理系统无需用户主动发出查询,实时查询服务可以主动将实时的结果推送给用户
- 流数据具有如下特征:
- 数据快速持续到达,潜在大小也许是无穷无尽的
- 数据来源众多,格式复杂
- 数据量大,但是不十分关注存储,一旦经过处理,要么被丢弃,要么被归档存储
- 注重数据的整体价值,不过分关注个别数据
- 数据顺序颠倒,或者不完整,系统无法控制将要处理的新到达的数据元素的顺序
- 流计算的基本理念
- 数据的价值随着时间的流逝而降低,当事件出现时就应该立即进行处理,而不是缓存起来进行批量处理。
- 为了及时处理流数据,就需要一个低延迟、可扩展、高可靠的处理引擎
- 流计算处理流程:数据实时采集;数据实时计算;实时查询服务
- 数据实时采集的基本架构一般有3个部分
- Agent:主动采集数据,并把数据推送到Collector部分
- Collector:接收多个Agent数据,并实现有序、可靠、高性能的转发
- Store:存储Collector转发过来的数据
图计算
- BSP(“大同步”模型)计算过程包括一系列全局超步(所谓的超步就是计算中的一次迭代),每个超步主要包括三个组件:
- 局部计算:每个参与的处理器都有自身的计算任务
- 通讯:处理器群相互交换数据
- 栅栏同步(Barrier Synchronization):当一个处理器遇到“路障”(或栅栏),会等到其他所有处理器完成它们的计算步骤
- Pregel选择纯消息传递模型的理由
- 消息传递具有足够的表达能力,没有必要使用远程读取或共享内存的方式
- 有助于提升系统整体性能
- Worker与Master的作用
- Worker:借助于名称服务系统定位到Master的位置,并向Master发送自己的注册信息,Master会为每个Worker分配一个唯一ID,在一个Worker中,它所管辖的分区状态背会保存在内存,在每个超步中,Worker会对自己所管辖分区中的每个顶点进行遍历,并调用顶点上的Computer函数
- Master:Pregel采用检查点机制来实现容错。在每个超步的开始,Master会通知所有的Worker把自己管辖的分区的状态写入持久化存储设备,Master周期地ping每个Worker,Worker收到ping消息后向Master反馈消息。如果指定的时间间隔内没有收到某个Worker的反馈,Master就会将它标为失效,并启动恢复模式
- Pregel的执行过程
- 选择集群中的多台机器执行图计算任务,有一台机器会被选为Master,其他机器作为Worker
- Master把一个图分成多个分区,并把分区分配到多个Worker。
- Master会把用户输入划分成多个部分。通常是基于文件边界进行划分
- Master向每个Worker发送指令,Worker收到指令后,开始运行一个超步。当一个超步中的所有工作都完成以后,Worker会通知Master,并把自己在下一个超步还处于“活跃”状态的顶点的数量报告给Master。上述步骤会被不断重复,直到所有顶点都不再活跃并且系统中不会有任何消息在传输,这时,执行过程才会结束。
- 计算过程结束后,Master会给所有的Worker发送指令,通知每个Worker对自己的计算结果进行持久化存储
- (书上的例子!)
数据可视化
- 概念
- 将大型数据集中的数据以图形图像形式表示, 并利用数据分析和开发工具发现其中未知信息的处理过程
- 工具与方法
- 有关时间趋势的可视化:R和illustrator
- 有关比例的可视化 :HTML、CSS和JavaScript
- 有关关系的可视化:R和illustrator
- 发现差异:R
- 有关空间关系的可视化:Python
- 方法
- 有关时间趋势的可视化
- 以时间为横坐标
- 工具:R语言
- 图形:柱状图、散点图、折线图
- 有关比例的可视化
- 图形:饼图、面包圈图、堆叠柱形图、
- 有关关系的可视化
- 图形:散点图,气泡图、直方图
- 发现差异
- 图表类型:热点图、切尔诺夫脸谱图、星图、雷达图、平行坐标
- 有关空间关系的可视化
- 与地图有关
大数据应用
- 推荐方法包括如下几类:
- 专家推荐
- 基于统计的推荐
- 基于内容的推荐
- 协同过滤推荐
- 混合推荐
- 协同过滤推荐
- 基于用户的协同过滤:UserCF算法的实现主要包括两个步骤:
- 第一步:找到和目标用户兴趣相似的用户集合
- 第二步:找到该集合中的用户所喜欢的、且目标用户没有听说过的物品推荐给目标用户
- 基于物品的协同过滤:
- 计算物品之间的相似度
- 根据物品的相似度和用户的历史行为,给用户生成推荐列表
- UserCF算法适合应用于新闻推荐、微博话推荐题等应用场景,其推荐结果在新颖性方面有一定的优势;ItemCF在电子商务、电影、图书等应用场景。
- UserCF算法和ItemCF算法的思想、计算过程都相似,两者最主要的区别:
- UserCF算法推荐的是那些和目标用户有共同兴趣爱好的其他用户所喜欢的物品
- ItemCF算法推荐的是那些和目标用户之前喜欢的物品类似的其他物品
- UserCF算法的推荐更偏向社会化,而ItemCF算法的推荐更偏向于个性化
- 能根据给出的数据写结果
- 冷启动问题:
- 提供非个性化推荐,最简单就是热门排行榜
- 利用用户注册时提供的年龄、性别等数据做粗粒度个性化
- 对于新加入的物品,可以利用内容信息,将它们推荐给喜欢过它们相似物品的用户
- 在系统冷启动时,可以引入专家知识,通过一定的高效方式叙述建立起物品的相关度表
云计算
全是看着重点整理的
云概念
- 云计算能让人们方便快捷地自助使用远程计算资源
- 5个基本特征
- 自助服务:消费者不需要或很少需要云服务提供商的协助,就可以单方面按需获取云端的计算资源
- 快速弹性:需要时能快速获取资源从而扩展计算能力,不需要时能迅速释放资源以便降低计算能力,从而减少资源的使用费用
- 计费服务:消费者使用云端计算资源是要付费的
- 广泛的网络访问 :消费者可以随时随地使用任何云终端设备接入网络并使用云端的计算资源
- 资源池化:云端计算资源需要被池化,以便通过多租户形式共享给多个消费者,也只有池化才能根据消费者的需求动态分配或再分配各种物理的和虚拟的资源
- 三个服务模式
模式 | Iaas(架构即服务) | Paas(平台即服务) | SaaS |
概念 | 云服务提供商把IT系统的基础设施层作为服务租出去,由消费者自己安装操作系统、中间件、数据库和应用程序 | 云服务提供商把IT系统中的平台软件层作为服务租出去,消费者自己开发或者安装程序,并运行程序 | 云服务提供商把IT系通中的应用软件层作为服务租出去,消费者不用自己安装应用软件,直接使用即可 |
功能 | 资源抽象;负载管理 | 平台即服务。平台及服务。平台级服务 | 保证每家企业数据的安全性和保密性;灵活租赁的收费 |
例子 | 计算服务、备份和恢复服务、内容分发网络CDN、存储服务 | 数据分析、人工智能、Docker;推送、通信、语音识别、图像识别、统计、广告等 | 企业使用、多语言多币种、非实时强交互(ERP/CRM/工程软件/可靠性软件);不适合“”实时处理软件(飞行控制)、产生大量数据的软件(视频监控)、关键软件(核电厂离心机监控) |
应用 | 天翼云 | 八百客App | 云OA、云CRM和云ERP |
优点 | 灵活 | 管理难度低 | 管理难度极低 |
缺点 | 难管理,浪费资源 | 灵活性下降 | 灵活性低 |
- 4种部署模型
- 公共云
- 云端资源开发给社会公众使用。云端的所有权、日常管理和操作的主体可以是一个商业组织、学术机构、政府部门或者它们其中的几个联合。云端可能部署在本地,也可能部署于其他地方
- 私有云
- 云端资源只给一个单位组织内的用户使用,这是私有云的核心特征。而云端的所有权、日程管理和操作的主体到底属于谁并没有严格的规定,可能是本单位,也可能是第三方机构,还可能是二者的联合。云端可能位于本单位内部,也可能托管在其他地方。
- 社区云
- 云端资源专门给固定的几个单位内的用户使用,而这些单位对云端具有相同的诉求(如安全要求、云端使命、规章制度、合规性要求等)。云端的所有权、日常管理的操作的主体可能是本社区内的一个或多个单位,也可能是社区外的第三方机构,还可能是二者的联合。云端可能部署在本地,也可能部署与他处。
- 混合云
- 混合云由两个或两个以上不同类型的云(私有云、社区云、公共云)组成,它们各自独立,但用标准的或专有的技术将它们组合起点,而这些技术能实现云之间的数据和应用程序的平滑流转。由多个相同类型的云组合在一起,混合云属于多云的一种。
- 私有云和公共云构成的混合云是目前最流行的——当私有云资源短暂性需求过大(称为云爆发,Cloud Bursting)时,自动租赁公共云资源来平抑私有云资源的需求峰值。
- 优势:架构灵活、容易掌控、安全高、费用低
- 构成:公有云、私有云、网络连接、管理工具
- 功能:数据备份、灾备、负载延伸、公共云做开发测试
云架构
- 云架构中的5种角色
- 云服务消费者
- 即租赁使用云服务产品的公司企业和个人消费者
- 云服务提供商
- 云服务提供商负责组建云端并对外提供云服务产品的个人或单位组织,即提供云服务(云计算产品)的厂商
- 云服务代理商
- 云服务代理商代理云服务提供商向消费者销售云计算服务并获取一定报酬
- 云计算审计员
- 开展独立评估的第三方个人或者单位组织
- 云服务承运商
- 在云服务提供商和消费者之间提供连接媒介以便把云服务产品转移到消费者手中
- 角色之间的关系
- 云服务管理
云组件
- 如何运行和管理大量的虚拟机并让远方的用户自助使用这些虚拟机
- 运行:虚拟化平台:服务器虚拟化、网络虚拟化、存储虚拟化
- 管理:云管理工具:创建、启动、停止。备份、迁移虚拟机、资源管理
- 使用:云服务交付:访问网络、通信协议、云终端
- 包括
- 开源组件: 计算项目;虚拟化;操作系统;数据库;中间件;基础服务; 云管理工具(Nova,Glance,swift,Neutron,Cinder,Keystone);应用软件
- 商业组件:
云技术
云端技术
- 布局:
- 1.计算离用户最近;2.内容离用户最近;3.靠近能源之地;4.靠近寒冷之地
- 最理想的建云端的地区:寒冷、电力充裕、人口密集、无地质灾害、计算机网络设施发达
- 存储
- 种类
- 直接存储:存储模块直接接插到主板上
- 外部存储:存储和CPU不在同一台计算机上
- 分布式存储:通过分布式文件系统吧各台计算机上的直接存储整合成一个大的存储,对参与存储的每台计算机来说,既有直接存储部分,也有外部存储部分,所以说分布式存储融合了前面两种存储方案
- 评价指标:容量、速度、每秒读写次数(IOPS)、可用性
- IOPS:每秒钟能响应的读(或写)操作的次数
- 虚拟化与容器技术
- 虚拟化是云计算的重要技术,主要用于物理资源的池化,从而可以弹性地分配给用户
- 物理资源包括服务器、网络和存储
- 容器技术:有效的将单个操作系统的资源划分到孤立的组中,以便更好的在孤立的组之间平衡有冲突的资源使用需求,这种技术就是容器技术
- 热迁移(Live Migration),又叫动态迁移、实时迁移,即虚拟机保存/恢复,通常是将整个虚拟机的运行状态完整保存下来,同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后,虚拟机仍旧平滑运行,用户不会察觉到任何差异
- 主机虚拟化
- 即把一台 IBM 机器划分成若干台逻辑的服务器,每台逻辑服务器拥有独占的计算资源(CPU、内存、硬盘、网卡),可以单独安装和运行操作系统
- 一台虚拟机的计算能力小于物理机
- 过渡分配资源,内存1.5倍,CPU 16倍,存储3倍。
- 资源浪费严重
- 灵活性高
- 网络虚拟化
- 对物理网络资源进行抽象并池化,以便于分割或合并资源来满足共享的目的
- 6种过渡技术:虚拟局域网络(VLAN)、虚拟专用网络
(VPN)、主动可编程网络(APN)、叠加网络(Overlay Network)、软件定义网络(SDN)和网络功能虚拟化(NFV) - 不容易被网络设备厂商绑定
- 能快捷满足业务的需求;成本低; 数据传送的路径全局最优
- 远程桌面
- 电脑桌面位于网络上,远程登陆使用
- 三种方法实现远程桌面
- IaaS云桌面:基于 IaaS 云服务的虚拟机或裸机,租户租用云服务提供商的虚拟机或裸机,然后自己安装操作系统、应用软件并开启远程桌面
- IaaS容器桌面:是 IaaS 云服务的应用软件容器,租户共享底层的操作系统内核,单独安装应用软件和一些基础运行库。比如:openvz、virtualozzo、Windows Server Container、Hyper-V Container
- PaaS云桌面:基于半平台 PaaS 云服务,并为每个租户创建一个系统账户,其实就是利用了现代操作系统的多用户特点,即同时让许多人登录并使用计算机,如微软RDS、Linux多用户登陆
- 负载均衡
- 把用户任务合理分配到云端的机器上
- 原因
- 很多租户
- 云端有很多计算机
- 进入云端的宽带专线条数有限
- 策略
- 让唤醒的每台服务器承担尽可能多的活跃桌面。
- 使每台服务器消耗的计算资源的占比尽可能相等。
- 应用软件相同的租户桌面尽可能分配到相同的服务器上。
- 尽可能把同一个用户的每次登陆分配到同一台服务器上。
- 集群
- 负载均衡技术用于解决如何把许多互不相关的小型任务或中型任务合理地分配到不同的服务器上的问题。互不相关的小型任务或中型任务是指任务之间没有关联性,而且只用一台服务器就可以完成的任务。绝大多数个人租户的任务都属于这类任务。对于大型任务,由于一台服务器无法按时完成,所以就要把大型任务拆分成许多中小型任务,然后再分配给多台服务器,由它们协同完成,这就是计算机集群技术所要解决的问题
- 两大技术:
- 任务拆分:原则之一是尽量降低子任务之间的关联性,从而提高处理任务的并行度
- 任务调度:最能满足租户要求的调度方法就是合理的
- 容错计算
- 容错计算,也有人称为高可用性计算和高可靠性计算,其重点是保证任务在被处理的过程中不会异常终止,以及任务完成后输出结果的正确
- 容许部分参与计算的机器出错,但不影响计算结果
- 接力容错:由若干台计算机参与同一个任务的计算,但是同一时刻只由一台计算机处理任务,只有当这台计算机出现故障时,才由下一台计算机接力处理
- 并行容错:参与容错的计算机同时处理相同的任务,输出相同的结果。可以在服务器内部的部件层次做并行,也可以在服务器层次做并行,前者主要由服务器生产厂商设计和完成
- 家目录漫游
- 用户登录计算机后首先进入的那个目录就是他的家目录,用户的资料默认保存在它的家目录中。C:\Users,/home
- 租户隔离
- 一个租户的操作行为和数据对于其他租户来说是不可见的。
- 行为隔离
- 个租户消耗计算资源的变动不会引起其他租户计算资源的可感知变动
- 原则:按实际使用量分配资源,但不超过租用额度
- SaaS、PaaS 和 IaaS 模式都需要实施租户行为隔离
- 数据隔离
- 租户数据一般保存在家目录或者数据库中,而家目录和数据库被保存在云端的磁盘中
- PaaS 型租户的数据隔离一般采用容器或者操作系统的访问控制列表(ACL)的形式,主要在操作系统层设置;
- 而 SaaS 型租户的数据隔离主要在应用软件层及以上展开,租户身份鉴别和权限控制策略由应用软件开发者负责。
- SaaS 型租户数据一般全部保存在数据库中,对于同一个数据库管理系统的租户数据隔离有三种方法可选:一是分离数据库;二是共享数据库但分离Schema;三是共享数据库和 Schema
- 四级成熟度
- Level1: 定制开发
- 软件服务提供商为每个客户定制一套软件
- 多次开发,多次部署软件
- 每个客户使用一个独立的数据库实例和应用服务器实例
- 数据库中的数据结构和应用的代码可根据客户需求做定制化修改
- 若扩大规模,基本靠人肉战术
- Level 2:可配置
- 软件提供商趋向开发通用型产品,通常具有可配置性
- 一次开发多次部署
- 每个客户独立部署一个运行实例
- 可配置性的实现方式:通过元数据来实现
- 这种成熟度仅仅是商业模式上的SaaS
- Level 3:高性能的多租户架构
- 每个租户部署一个运行实例,必然导致硬件及运行维护成本很难产生较大的规模效应。
- 一次开发一次部署
- 共享软件实例
- 实现方案:独立数据库、共享数据库独立数据结构、共享数据结构等多种实现方案
- Level 4:可伸缩性的多租户架构
- 集中式数据库是SaaS应用的瓶颈
- 一次开发无限扩展
- 通过接入租户负载平衡层分配不同的实例
- 最复杂的是对原有单个Instance的数据库服务器,实现其数据的水平拆分。
- 租户负载平衡层存放用户租户与对应实例的映射关系。
- 多租户在数据存储上的三种主要方案
- 独立数据库
- 一个租户一个数据库
- 优点:为不同租户提供独立的数据库,有助于简化数据模型的扩展设计,满足不同租户的独特需求;发生故障,恢复数据库比较简单
- 缺点:增大了数据库安装数量,随之带来维护成本和购置成本的增加
- 共享数据库,隔离数据架构
- 多个租户或所有租户共享一个数据库,但是一个租户一个架构(Schema)
- 优点:为安全性要求较高的租户提供一定程度上的逻辑数据隔离,并不是完全隔离;每个数据库可以支持更多的租户数量。
- 缺点:出现故障,数据恢复比较困难;跨租户统计数据,存在一定困难
- 共享数据库,共享数据架构
- 多个租户或所有租户共享一个数据库,但是一个租户一个架构(Schema)
- 优点:成本低;每个数据库可以支持的租户数量最多。
- 缺点:隔离级别低,安全性低,开发安全性功能;数据库备份和恢复困难,需要逐个表逐条数据备份和还原
- 数据库层的水平扩展的三种方案
-
- 统一身份认证
- 概念:登录云端时只需一次验证,之后就可以进入任何有权进
入的应用系统 - 功能
- 统一用户管理(Identification)——租户的账号、密码等信息集中存储,统一管理
- 身份鉴别(Authentication)——当租户登录应用系统时,验证他的票据或者身份是否合法
- 权限控制(Authorization)——规定登录后的租户具备哪些操作权限
- 操作日志登记(Accountability)——记录租户的操作行为,以便事后责任追溯
终端技术
- 按功能分类
- 人机交互终端
- 机机交互终端
- 输入终端
- 输出终端
- 按移动性分类
- 移动终端
- 固定终端
- 两用终端
- 按屏幕尺寸分类
云安全
- 云安全概念
- 云用户是否自由
- 数据是否完整
- 数据是否泄密
- 数据是否丢失
- 计算是否可用
信息管理与数据安全
- 数据安全
- 生命周期:创建、存储、使用、共享、归档、销毁
- 数据是否完整、数据是否泄密、数据是否一致都属于数据是否安全的范畴
- 数据存放在云端比存放在本地更安全原因:
- 数据完整性方面:云端通过采用服务器集群、异地容灾和容错等技术,可保证数据万无一失,采用数据快照回滚技术,能最大程度降低用户误删数据的损失,所以云端的数据丢失的概率极低;
- 数据泄密方面:防火墙过滤、入侵检测、用户行为分析、泄密预测、非对称加密等
- 数据一致性方面:机房恒温恒湿、多级电力保障、阵列存储系统、安全防范、专家运维
计算可用性
- 不可用的原因
- 停电、断网、硬件故障、软件故障
- 云端可用性高的原因
- 云终端是一个纯硬件、低功耗产品,几乎不会出故障
- 采用多路供电、恒温恒湿系统,引入集群技术、容错技术及负载均衡技术等措施确保计算持续可用
互操作性和可移植性
- 互操作性
- 互操作性使得我们可以随时使用新的或者来自不同云服务提供商的组件来替换已有的组件,而不会中断云中的任 务,也不影响数据在不同系统之间进行交换
- 实施
- 物理计算设备:1.尽可能采用虚拟化来屏蔽底层硬件的差异;2.如选择相同或更好的物理硬件和管理安全控制
- 物理网络设备:网络硬件设备应该虚拟化,并尽可能使得 API 具备相同的功能
- 虚拟化:1.利用开放虚拟化文件格式,以确保互操作性;2.了解并记录使用了哪些特定的虚拟化扩展钩子(Hook)
- 框架:1.搞清楚 API 的不同之处,然后拟定修改应用系统的计划;2.使用公开发布的 API ;3.要尽量避免可能会破坏系统的数据完整性的状态依赖
- 存储:1.以一个被广泛接受的可移植的格式存放非结构化数据;2.评估数据在传输过程中是否需要加密;3.检查各种兼容的数据库系统
- 可移植性
- 可移植性是指能把应用和数据迁移到其他地方而不用理会云服务提供商、平台、操作系统、基础设施、地点、存储、数据格式或者 API 接口
- 实施
- 服务水平:了解清楚 SLA会如何影响将来更换云服务提供商。
- 不同的架构:了解应用与平台的依赖性
- 安全集成:(1),使用诸如SAML 这种开放标准的身份机制将有助于提高可移植性(2)加密密钥应该托管在本地,并尽可能地在本地维护。(3)重视元数据。当移动文件和文件的元数据到一个新的云端时,要确保安全地删除了源文件元数据的全部副本,否则遗留下来的元数据可能会成为一个安全隐患
云应用
- 企业私有办公云
- 园区云
- 医疗云
- 公民档案云
- 卫生保健云
- 教育云
- 交通云
- 出行云
- 购物云
- 农村农业云
- 高性能计算云
- 人工智能云
云方案
- 云方案设计流程:
- 系统拓扑
- 网络设计
- 存储设计
- 硬件选型
- 软件选型
- 部署步骤
- 需求分析的内容
- 需求分析是指理解用户需求,就用户的功能需求与客户达成一致,并需要估计项目风险和评估项目代价,最终形成开发计划的一个复杂过程。
- 接入的终端数:重点统计并行接入的终端数目。
- 用户类型:根据使用的应用软件来分类。
- 数据安全性:用户类型和公司制度,安全性,桌面隔离,虚拟技术,云端体系架构和投资预算
- 小型方案
- 用户需求:满足60名以内的终端用户,允许适度的不可用,要求满足若干个员工(比如财务人员、老板)的高安全性。
- 适用场合:办公、电教室、多媒体阅览室、门柜业务、家庭等
- 中型方案
- 用户需求:能满足100至500个用户日常办公的需要,每个用户分配一个账号,他就能在任何一台云终端上登录云端桌面,实现公司内部的移动办公。
- 应用场所:包括大型的阅览室、大型培训教室、中型公司、大型门柜业务等。
- 大型方案
- 能接入 500 台以上的云终端,可以满足大型公司内各类员工的办公需求。公司员工用各自的账号能在公司内部的任何云终端上登录自己的远程桌面,实现公司内部移动办公;同时,要求出差在外的员工也能安全访问远程桌面,公司安全管理部门能监控到外发的电子文档资料。
参考文档
mongodb增删改查操作 大数据技术原理与应用课后答案