当前位置:   article > 正文

北邮大数据技术基础复习提纲_北邮 大数据 笔记

北邮 大数据 笔记
  • 自己用的。不保证正确性
  • 大数据概述
  • 大数据带来的思维转变:
  • ①全样而非抽样②效率而非精确③相关而非因果

  • 大数据的4V模型:
  • ①数据量大(volume)②多样化(variety)③快速化(velocity)④价值密度低(value)

  • 大数据的产生阶段:
  • ①运营式系统阶段②用户原创内容阶段③感知式系统阶段

  • 科学研究的四阶段(范式):
  • ①实验②理论③计算④数据探索

  • 大数据的四种计算模式
  • ①批处理计算:针对大规模数据的批量处理(数据量大,对时间要求不高)

    ②流处理:针对流数据的实时计算

    ③图计算:针对大规模图结构数据的处理(将数据表征为图的形式)

    ④查询分析计算:大规模数据的存储管理和查询分析(对时间要求高)

  • 大数据的框架(6层):
  • 从下至上:

    数据收集层->数据存储层->资源管理与服务协调->计算引擎层->数据分析层->数据可视化层

  • 数据收集层的收集类型:
  • ①结构化(关系型):sqoop/canal

    ②非结构化(非关系型):Flume

  • Flume的多路合并和多路复用的拓扑结构
  • ①多路合并:在流式日志收集应用中,常见的一种场景是大量的日志产生客户端将日志发送到少数几个聚集节点上,由这些节点对日志进行聚集合并后,写入后端的HDFS中

    ②多路复用:将数据路由到多个目标系统中【Eg:Source产生的数据按照类别被写入不同的Channel,之后由不同Sink写入不同的目标系统中,需要注意的是,Sink可进一步写入另外一个Agent,进而实现Agent级联】

  • 分布式消息队列
  • Kafka:用于数据收集
  • Kafka的设计动机:
  • ①数据生产者和消费者耦合度过高

    ②生产者和消费者数据处理速率不对等

    ③大量并发的网络连接对后端消费者不够友好

  • Kafka的架构:
  • ①架构类型:push-pull【produce:push,consumer:pull】

    ②组件构成:consumer,producer,broker,zookeeper(减轻Kafka的压力)

  • ELKSTACK(日志收集与分析)的功能组件:
  • ①ElasticSearch(核心组件):用于数据查询

    ②LogStash:数据采集和传输

    ③Kibana:用于①数据的可视化

  • 网络爬虫策略(抓取):
  • ①反向链接数策略:反向链接数是指一个网页被其他网页链接指向的数量,表示的是一个网页的内容受其他人推荐的程度,用其评价网页的重要程度

    ②ParticalPageRank策略

    ③OPIC策略(online page importance calculation)

    ④大站优先策略

  • 数据存储层
  • 将数据存入分布式存储系统前,需要考虑:
  • ①数据序列化②文件存储格式③存储系统

  • 行式存储和列式存储的区别及各自优点:
  • 行式存储:写入一次完成,数据压缩比较低

    列式存储:一行记录拆分为单列存储,写入次数比行存多,读数据压缩率高

  • 列式存储的典型格式:
  • ①ORC:

    ②Parquet:

    ③Carbondata:

  • 分布式文件系统
  • 横向扩展和纵向扩展各自的优点和概念
  • 横向扩展:①概念:通过增加(例如网络等)节点来增加性能和容量

           ②优点:

    纵向扩展:①概念:利用现有的存储系统,通过不断增加存储容量来满足数据增长的需求(通过增加单节点的性能来增加容量)

        ②优点:

  • HDFS的架构:
  • ①架构类型:主从【主:NameNode,从:DataNode】

    ②各组件及其功能:【NameNode,DataNode,Cilent?】

    NameNode:(a) 管理元信息: NameNode维护着整个文件系统的目录树,各个文件的数据块信息等。

     (b)管理DataNode:DataNode周期性向NameNode汇报心跳以表明自己活着

    DataNode:DataNode存储实际的数据块,并周期性通过心跳向NameNode汇报自己的状态信息。

    Cilent(算组件吗?):(a)通过客户端与NameNode和DataNode交互,完成HDFS管理(比如服务启动与停止)和数据读写等操作

    (b)文件的分块操作也是在客户端完成的

  • HDFS的容错性设计:
  • NameNode故障:对每个(主)NameNode分配一个(从)standby Namenode,故障时,从节点会接管主节点

    DataNode故障:NameNode通过心跳机制汇报的状态信息判断,在其他节点上存相同的副本,一个损坏可以通过另一个重构

    数据块损坏:通过DataNode保存数据块时生成的校验码判断,损害就通过其他节点上的副本重构

  • NoSQL数据库的CAP理论内容【只能达到其中两种】:
  • 1.C(consistency):一致性,读能读到最新版本的数据

    2.A(availability):可用性,无论请求成功还是失败都有响应

    3.P(partition Tolerance):分区容错性,系统任意信息的丢失/失败,不会影响系统的继续运作

    {CA:关系数据库,单点集群,扩展性不太强

    CP:一般性能不是很高

    AP:一致性要求不高,大多数使用【{}内是老师没说的】

    }

  • ACID各属性:
  • 原子性:要么全执行,要么全不执行

    一致性:数据要保持一致状态

    隔离性:修改之间要隔离

    持久性:影响会一直存在下去

  • base理论内容:
  • 基本可用:允许分区失败

    软状态:数据可以有一段时间不同步,有一定的滞后性

    最终一致性:可以暂时读不到更新的数据,过段时间一定要读到更新后的数据

  • 一致性的三种模式:
  • ①强一致性:更新过的数据能被后续的访问都能看到

    ②弱一致性:容忍后续的部分或者全部访问不到

    ③最终一致性:经过一段时间后要求能访问到更新后的数据

  • 判断强/弱一致性:
  • --数据复制的份数 W---更新数据时需要保证写完成的节点数
  • --读取数据时需要读取的节点数
  • ①W+R>N 强一致性

    ②W+R<=N 弱一致性

  • NoSQL的数据库类型及各典型及合适存的数据:
  • ①key-value:典型:radis,EROSPIKE

     适合存的数据:将数据存储于内存中,只存储结构不复杂的数据/涉及频繁读写的数据【eg:存用户的登录信息/淘宝的购物车】

    ②key-column:典型:HBASE,CASSANDRA,HYPERTABLE,riak

    适合存的数据:按列存的(?)

    ③key-document:典型:mongoDB,CouchDB

    适合存的数据:有嵌套结果的数据

    ④图模型:典型:neo4j,GraphDB,INFINITEGRAPH

              适合存的数据:有高度相互关联关系的数据(Eg:社交网络)

  • 图模型的属性:
  • 节点+关系+属性+标签

    四、分布式结构化存储系统

    1.Hbase的逻辑数据模型和物理数据模型

    逻辑数据模型:面向用户。用户看到的)类似于数据库中的database和table逻辑概念,HBase将之称为namespace和table,一个namespace中包含一组table

    物理数据模型:面向计算机物理表示的模型,描述Hbase数据在存储介质的组织结构)HBase是列簇式存储引擎,它以column family为单位存储数据,每个column family内部数据是以key value格式保存的,key value组成如下:

    [row key, column family, column qualifier, timestamp] => value

  • Hbase的基本架构:
  • ①架构类型:master/slave【master--HMaster;slave--RegionServer】

    ②关键组件:HMaster,RegionServer,zookeeper,client

  • Region定位:
  • ①客户端和zookeeper交互:获取hbase:meta系统表所在的RegionServer

    ②客户端和hbase:meta系统表所在的RegionServer交互:获取rowkey所在的RegionServer

    ③客户端和rowkey所在的RegionServer交互:执行rowkey相关操作

  • RegionServer关键组件:
  • BlockCache:读缓存

    MemStore(避免频繁的写操作+将随机写转换为顺序写):写缓存,写入磁盘前对数据排序

    HFile:保存Hbase表中实际的数据

    WAL(避免数据丢失,提高可靠性):用于保存还没存到内存上的数据,恢复宕机/掉电数据(write ahead log)

  • RegionServer读写流程
  • 读流程:(通过多级缓存操作提高读的效率)

    ①查找blockcache,找不到转②

    ②查找Memcache,找不到转③

    ③查找HFile

    写流程:

    ①RS收到写请求,先将日志写入WAL

    ②RS将数据写入MemStore,通知client写入成功

    ③到Mem到达一定阈值以后,RS将数据刷新到HDFS,保存为HFile

  • HBase物理存储是如何实现的?(HBase是列蔟式存储,每一行/每一单元格的数据是怎么存的)
  • 行式存储

  • HBase存储多版本数据原因:
  • 数据有时效性,历史数据也有价值,存储多版本数据,既能保存当前又能保存历史

  • HBase的多版本数据是按照什么排序的:
  • TimeStamp(时间戳)

  • Kudu是什么类型的数据库:
  • 纯列式

  • 分布式协调与资源管理
  • 为什么zookeeper通常由奇数个实例构成【但不是一定是奇数个】
  • 数据写入多数节点,才算数据写入成功【ZAB协议】,奇数节点(2n+1)和偶数节点的(2n+2)的容错都为n节点,用少的【奇数写入成功需n+1,偶数节点写入成功需2n+2】

  • zookeeper的负载均衡是对谁的负载均衡?
  • Leader【kafka里的负载均衡是对leader particion的负载均衡】

  • 需要YARN【第二代资源管理与调度系统】的原因(资源管理与任务调度在一起的缺点):
  • ①JobTracker (master) 同时兼备了资源管理和作业控制两个功能,这成为系统的

    一个最大瓶颈,严重制约了Hadoop集群扩展性

    ②master/slave结构,存在单点故障,一点故障,整个集群不可用

    ③资源利用率低,采用基于槽位的资源分配模型,常导致一槽位紧张二另一槽位闲置

    【其中②③不能回答括号内问题】

  • YARN基本架构和功能组件
  • ①架构种类:master/slave架构【master:ResourceManager;slave:NodeManager】

    功能组件:resourcemanager+nodemanager+zookeeper:资源管理与服务协+client

  • 各组件的功能
  • ①ResourceManager:负责整个系统的资源管理和分配,调度器负责整个系统的资源管理和分配,应用管理器:负责管理整个系统中的所有应用程序(提交/重启等)

    ②NodeManager:每个节点上的资源管理器,定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态,接收并处理来自AM的任务启动/停止等各种请求

    ③client:与RS和NS进行交互,提交应用程序

    ④ApplicationMaster:提交应用程序时,提供它用来跟踪和执行,向RS申请资源,与NodeManager通信启动/停止任务,监控任务运行状态,失败重申重启

    ⑤container:yarn中的资源基本分配单位,提供资源隔离环境

  • YARN的工作流程
  • ①用户使用Client向RS提交应用程序

    ②启动applicationMaster【RM为此应用分配container,与对应的NM通信,告诉它在container里启动此应用的AM】

    ③ApplicationMaster注册(向RM)

    ④AM通过轮询方式获取资源【向RM申请资源】

    ⑤请求启动container(AM申请完后,与对应NM通信,请求为其启动任务)

    ⑥启动container(NM为任务设置好运行环境,通过container启动任务)

    ⑦container监控(AM和RM之间有心跳,每次通信都可以获取自己管理的container的运行状态/container可以向AM汇报自己的状态和进度)

    ⑧注销AM(应用程序完成后,AM向RM申请注销,并退出执行)

  • 资源管理架构的演化(三阶段)
  • 集中式架构-->双层调度架构-->共享状态架构

  • 计算引擎
  • MapReduce各组件(5基本+1可选)
  • inputFormat,Mapper,Partitioner,Reducer,OutputFormat,combiner(可选)

  • MapReduce各组件功能
  • ①inputFormat:数据切分+为Mapper提供输入数据

    ②Mapper:进行map函数处理,封装了数据处理逻辑

    ③partitioner:对Mapper产生的中间结果进行分片,以便将同一组的数据交给同一个Reducer处理,它直接影响Reduce阶段的负载均衡

    ④Reducer:基于Mapper产生的结果进行规约操作,产生最终结果

    ⑤outputFormat:对输出数据格式化操作

    ⑥combiner(可选组件):相当于map端的reducer,做一个局部聚集,减少网络数据传输量,减少磁盘的I/O操作,减少reducer端的计算压力【作用,老师上课经常强调】

  • MapReduce的关键技术点(优化方式)
  • ①数据本地性(根据数据所在位置,尽可能让数据所在节点完成数据的任务)

    ②推测执行(推测“拖后腿任务”,为这样的任务启动备份任务,与原任务同时运行,采用最先成功运行完成任务的计算结果为最终结果)

  • spark概念
  • ①是DAG计算引擎②采用RDD模型

  • RDD的操作
  • ①transformation:记录操作(RDD的转换关系),将一种RDD转换为另一种RDD【惰性计算】

    ②action:处理RDD得到结果,真正触发动作的执行

  • spark运行流程
  • ①driver创建sparkconText,进行资源申请,任务的分配与监控

    ②资源管理器为Executor分配资源,并启动Executor进程

    ③sc构建DAG,将DAG交给schedule解析为stage(阶段),把taskSet交给task scheduler,再将分好的task交给executor运行

    ④task在executor上运行,把结果反馈给taskscheduler,再接着反馈给DAGscheduler,运行完后,写入数据并释放资源

  • spark生命周期
  • ①生成逻辑计划(BYdriver):根据RDD翻译DAG

    ②生成物理计划(BYdriver):根据DAG换分stage和task

    ③调度并执行任务(BYecutorAnddriver):计算每个stage,将任务分给executor计算

  • spark生态系统组件
  • 流式计算Spark StreamingSQL引擎Spark SQL机器学习库MLLib图计算框架GraphX

  • 流式计算引擎有哪几种及各自的特点
  • ①面向行:延迟低,吞吐率低【一行行处理】

    ②面向微批处理:延迟高,吞吐率高【一个个batch处理】

  • storm的可靠性机制
  • Acker机制,为每个消息保存一个校验值(初始为0)——>当tuple来的时候,ID和其校验值进行一次异或——>处理完,变为全0,可靠;没有变为全0,没处理完或出现故障

  • Flink的窗口【一个窗口进行一次聚合】
  • 两种驱动方式:①时间②计数

    窗口:会话窗口,翻滚计数窗口,翻滚时间窗口,滑动时间窗口

    【翻滚:不重叠,滑动窗口的特例(步长为窗口大小)】

    【滑动:有可能重叠,不停往前滑】

  • 图计算之pregel计算
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/803157
推荐阅读
相关标签
  

闽ICP备14008679号