读书笔记——大数据浪潮

2019-08-24  本文已影响0人  八月秋风早

数据集:类型,语义,结构,组织,粒度,可访问性

公有云,私有云,混合云

云计算改变了IT架构,大数据影响业务决策,影响在业务层

数据中心

零拷贝技术

硬件基础架构必须具备伸缩性和动态重新配置功能,以针对不同的应用环境

存储系统应尽可能具备更多的接口功能

分布式存储系统,要保证多个副本数据完全一致

列式存储数据库:Bigtable,Hypertable

数据库编程模型:MR,并行编程模型 并行处理和分发

map函数处理输入并产生中间键值对

避免了开发并行应用程序的繁琐步骤:数据调度,容错,节点通信等问题

大数据分析:聚类分析、因子分析、相关分析、回归分析等

大数据处理方法:布隆过滤器、索引、Hashing(散列),Triel树,并行计算

大数据架构:实时(HANA),离线(Timetunnel,Chukwa)内存 海量

涵盖数据采集,归类,挖掘,呈现,部署和移植的一体化解决方案

大数据一体机

IDH 4000个节点

HBase适合高并发查询,大对象存储 HDFS低延迟

Hadoop调优

动态不停机扩容

校验和是检查数据完整性的重要方式之一

Hadoop校验机制)(略)

对本地文件iO检查,对HDFS的IO进行检查

DN接受数据的两种情况:一是本地上传,二是从其他DN上接受

MR在并行处理时需要将文件分割成许多部分,编程中可以使MR在程序中使用压缩

序列化是将对象转化为字节流的方法,即用字节流描述对象,两个目的:进程间通信,以及数据持久化

Hadoop使用RPC实现进程间通信

HDFS不支持多用户同时操作一个文件

fsck file-blocks

安全模式是不会进行数据块的复制的

Namenode本地文件结构:{dsf.name.dir}/current/version  edit、fsimages 、fstime

这是元数据的镜像  version是java文件 包含namespaceID cTIme storageType layoutVersion

namespaceID是文件系统的唯一标识符,是在文件系统第一次格式化是创建,在DN和NN之间保持一致,NN会使用他识别新的DN,DN向NN注册才会获得  cTime是创建时间,除非文件系统被更新,否则是0 layoutVersion是负整数,定义了HDFS数据持久的版本,各节点版本号要一致

edit、fsimages 、fstime都是二进制文件,可以通过Writable进行序列化

StandbyNOde结构和NN一样

DN结构:

DN不需要格式化,启动时自动创建存储目录current/version blkXXX subdirXXX version

namespaceID cTIme,layoutVersion都和NN一样storageID是唯一的,也是多出来的,用来标识DN

blk前缀文件 有两种:HDFS文件快本身,即原始文件;块的元数据信息.meta

元数据文件由一个包含版本和类型信息的文件头与一系列的校验和组成

当目录中存储的块数量达到一定规模,DN会创建一个新的目录,用于保存新的块以及元数据,达到numblokcs指定的数量时,便会创建

Clinet读取DN时,如果是坏的,下次不会再读了

distcp用于两个HDFS之间复制数据,有许多选项可以复制,比如忽略失败,限制文件等,其实是一个MP任务,只需要map

如果不同的Hadoop版本,distcp会因RPC系统不兼容而失败

要考虑每个节点多少个map任务

fsck只能检测,不能修复,检测系统中不一致的情况

hdfs://ip:90000/user/root  nn端口是9000  有属性可以设置 lfs.default.name

MR

map接受key value同时输出keyvalue  具有相同key的value给reduce函数

reduce接受(key values)输出也是

hive中影响map任务数量的因素:输入文件总个数,输入文件大小,Block大小

HBase

client用RPC机制与HMaster和RegionServer通信,管理类的操作,Client与Hmaster进行RPC;读写操作,Client与RegionServer进行RPC

最好将具备共同IO特性的列放在一个cf中

HBase存储格式:Hfile hLogfiel 以wal的格式存储,物理上是顺序文件类型

rowkey需要填充到相同长度

scan时可以设置起始行和结束行(rowkey)

HBase0。92版本之后引入协处理器(coprocessors)新特性:访问控制,复杂索引,二级索引

Hive

hive的数据是存储在HDFS上的

HIVe——port:10000

metastore和hive运行在同一个进程里

JDBC,ODBC都是使用Thrift与Hive服务器进行通信

外表是不会把源数据移到自己的仓库的,甚至不检查是否存在

如果hive和其他工具一起管理表,则建立外表,比如,从hive中导出数据给其他程序使用;或者同一数据集关联不同的数据模式。否则完全又hive管理,就是托管表,

外部表更安全,方便共享

托管表,会移动文件到指定的位置,所以load data时会出现文件不存在

序列化工具就是比如insert 或ctas,serDe会把hive的数据行内部表示形式序列化成字节形式到输出文件中

反序列化就是查询

TEXT:每个文本行就是一个row

hive不支持delete,如果想删除,首先查出需要保留的内容,然后用这些数据覆盖这些表 insert overwrite into tablename select tablename where

针对有多人写入数据的场景,可以考虑采用 Hbase 的方案

若待处理的数据只有几十 GB 的话,不建议使用 Hadoop,因为没有任何好处

MapReduce 编程模型

称为映射和缩减阶段,

在 Map 中进行数据的读取和预处理,之后将预处理的结果发送到 Reduce 中进行合并;

每个分片大小参数是很重要的,

由于 Mapper 和 Reducer 往往不在同一个节点上运行,所以

Reducer 需要从多个节点上下载 Mapper 的结果数据,并对这些数据进行处理,然后才能

被 Reducer 处理。

MapReduce 数据本地化(Data-Local)

MapReduce 计算框架中负责计算任务调度的 JobTracker 对应 HDFS 的 NameNode

的角色,只不过一个负责计算任务调度,一个负责存储任务调度。MapReduce 计算框架中负责真正计算任务的 TaskTracker对应到HDFS 的DataNode

的角色,一个负责计算,一个负责管理存储数据

考虑到“本地化原则”,一般地,将 NameNode 和 JobTracker 部署到同一台机器上,各个 DataNode 和 TaskNode 也同样部署到同一台机器上。

这样做的目的是将 map 任务分配给含有该 map 处理的数据块的 TaskTracker 上,同时将程序 JAR 包复制到该 TaskTracker 上来运行,这叫“运算移动,数据不移动”。而分配

reduce 任务时并不考虑数据本地化。

ZooKeeper 命名空间中的 Znode,兼具文件和目录两种特点节点类型

Persistent Nodes:永久有效地节点,除非 client 显式的删除,否则一直存在。

Ephemeral Nodes:临时节点,仅在创建该节点 client 保持连接期间有效,一旦连接丢失,zookeeper 会自动删除该节点。

Sequence Nodes:顺序节点,client 申请创建该节点时, ZooKeeper 会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式 queue 等特殊功能的关键。

客户端可以在节点上设置 watch,我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发 watch 所对应的操作。当 watch 被触发时,ZooKeeper 将会向客

户端发送且仅发送一条通知,因为 watch 只能被触发一次,这样可以减少网络流量

传统的文件系统中,ACL 分为两个维度,一个是属组,一个是权限,子目录/文件默认

继承父目录的 ACL。而在 Zookeeper 中,node 的 ACL 是没有继承关系的,是独立控制的。

Zookeeper 的 ACL,可以从三个维度来理解:一是 scheme; 二是 user; 三是 permission,

通常表示为 scheme:id:permissions, 下面从这三个方面分别来介绍:

锁服务可以分为两类,一个是保持独占,另一个是控制时序

Hbase 适用场景:

1) 大数据量存储,大数据量高并发操作

2) 需要对数据随机读写操作

3) 读写访问均是非常简单的操作

fsck 用来检查系统中共不一致的情况,比如文件只有目录,副本丢失等情况

MR过程中,可能会涉及分区,合并,全排序,分布式缓存,压缩等技术

在map端的key有数据倾斜的情况,即大多数数据的key相同,这样会导致大多数数据会集中在一个kreduce上,造成其压力太大

如果mapreduce的数据源是大量的文本文件或可分割文件,那么map任务就是这些文件占据的快的数量;如果是成千上百的文件,那么作业将会在内核中创建和销毁map任务进程上消耗大量时间,会比实际处理数据时间还要长

每个文件都至少需要一个map任务

合并小文件:

1.如果是一个大逻辑文件的分片,可以写一个程序

2.本身小,无法合并,需要容器,对文件进行分组

HARfies:缓解小文件消耗nn内存的问题,对于客户端来说,使用HAR文件

没有影响

缺陷在于无法被压缩,无法优化mr访问本地磁盘性能

可以自己创建

SerquenceFile,文件名作为key。内容作为value

map端和reduce端都可能发生数据倾斜,map端如果倾斜,会让多样化的数据集处理效率低,

原因:

1.大量的不可分块的超大文件

2.大量小文件

reduce端如果倾斜,则来源于mr的默认分区器

数据倾斜是不可避免的

如果倾斜,找出来:把没完成的和已完成的比较一下

上一篇下一篇

猜你喜欢

热点阅读