赞
踩
https://blog.csdn.net/wyz0516071128/article/details/80997158
1数据倾斜的原因
关键词 | 情形 | 后果 |
Join | 其中一个表较小, 但是key集中 | 分发到某一个或几个Reduce上的数据远高于平均值 |
大表与大表,但是分桶的判断字段0值或空值过多 | 这些空值都由一个reduce处理,灰常慢 | |
group by | group by 维度过小, 某值的数量过多 | 处理某值的reduce灰常耗时 |
Count Distinct | 某特殊值过多 | 处理此特殊值的reduce耗时 |
1)、key分布不均匀, 分发到某一个或几个Reduce上的数据远高于平均值。
2)、业务数据本身的特性, 某特殊值过多,处理此特殊值的reduce耗时。
3)、建表时考虑不周。
4)、某些SQL语句本身就有数据倾斜, 由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜。
任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
单一reduce的记录数与平均记录数差异过大,通常可能达到3倍甚至更多。 最长时长远大于平均时长。
(绝即大多数task执行得都非常快,但个别task执行的极慢。)
1.增加jvm内存,这适用于【唯一值非常少,极少数值有非常多的记录值】的情况,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。
2.增加reduce的个数,这适用于【唯一值比较多,这个字段的某些值有远远多于其他值的记录数,但是它的占比也小于百分之一或千分之一】的情况,我们知道,这种情况下,最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。
3.自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。
4.重新设计key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。
5.使用combiner合并,combiner是在map阶段,reduce之前的一个中间阶段,在这个阶段可以选择性的把大量的相同key数据先进行一个合并,可以看做是local reduce,然后再交给reduce来处理,这样做的好处很多,即减轻了map端向reduce端发送的数据量(减轻了网络带宽),也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率),推荐使用这种方法。
大小表Join:
使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.
大表Join大表:
把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
count distinct大量相同特殊值:
count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。
group by维度过小:
采用sum() group by的方式来替换count(distinct)完成计算。
hadoop的核心思想是MapReduce,但shuffle又是MapReduce的核心。shuffle的主要工作是从Map结束到Reduce开始之间的过程。首先看下这张图,就能了解shuffle所处的位置。图中的partitions、copy phase、sort phase所代表的就是shuffle的不同阶段。
shuffle阶段又可以分为Map端的shuffle和Reduce端的shuffle。
一、Map端的shuffle
Map端会处理输入数据并产生中间结果,这个中间结果会写到本地磁盘,而不是HDFS。每个Map的输出会先写到内存缓冲区中,当写入的数据达到设定的阈值时,系统将会启动一个线程将缓冲区的数据写到磁盘,这个过程叫做spill(读音:[spɪl] )。
在spill写入之前,会先进行二次排序,首先根据数据所属的partition进行排序,然后每个partition中的数据再按key来排序。partition的目是将记录划分到不同的Reducer上去,以期望能够达到负载均衡,以后的Reducer就会根据partition来读取自己对应的数据。接着运行combiner(如果设置了的话),combiner的本质也是一个Reducer,其目的是对将要写入到磁盘上的文件先进行一次处理,这样,写入到磁盘的数据量就会减少。最后将数据写到本地磁盘产生spill文件(spill文件保存在{mapred.local.dir}指定的目录中,Map任务结束后就会被删除)。
最后,每个Map任务可能产生多个spill文件,在每个Map任务完成前,会通过多路归并算法将这些spill文件归并成一个文件。至此,Map的shuffle过程就结束了。
二、Reduce端的shuffle
Reduce端的shuffle主要包括三个阶段,copy、sort(merge)和reduce。
首先要将Map端产生的输出文件拷贝到Reduce端,但每个Reducer如何知道自己应该处理哪些数据呢?因为Map端进行partition的时候,实际上就相当于指定了每个Reducer要处理的数据(partition就对应了Reducer),所以Reducer在拷贝数据的时候只需拷贝与自己对应的partition中的数据即可。每个Reducer会处理一个或者多个partition,但需要先将自己对应的partition中的数据从每个Map的输出结果中拷贝过来。
接下来就是sort阶段,也成为merge阶段,因为这个阶段的主要工作是执行了归并排序。从Map端拷贝到Reduce端的数据都是有序的,所以很适合归并排序。最终在Reduce端生成一个较大的文件作为Reduce的输入。
最后就是Reduce过程了,在这个过程中产生了最终的输出结果,并将其写到HDFS上。
现在来总结一下shuffle过程,我画了张图,希望能够帮助理解。
(Remote Procedure Call)远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
使用 RPC 编程是在客户机和服务器实体之间进行可靠通信的最强大、最高效的方法之一。它为在分布式计算环境中运行的几乎所有应用程序提供基础。任何 RPC 客户机-服务器程序的重要实体都包括 IDL 文件(接口定义文件)、客户机 stub、服务器 stub 以及由客户机和服务器程序共用的头文件。客户机和服务器 stub 使用 RPC 运行时库通信。RPC 运行时库提供一套标准的运行时例程来支持 RPC 应用程序。在一般的应用程序中,被调用的过程在相同的地址空间中运行,并把结果返回给发出调用的过程。在分布式环境中,客户机和服务器在不同的机器上运行,客户端调用在服务器端运行的过程,并把结果发送回客户机。这称为远程过程调用 (RPC),是 RPC 编程的基础。
Namenode:负责管理元数据的信息
SecondName:做namenode冷备份,对于namenode的机器当掉后能快速切换到制定的Secondname上
DateNode:主要做储存数据的。
JobTracker:管理任务,并把任务分配到taskTasker
TaskTracker:执行任务
1) 首先,client上传文件到HDFS文件系统的虚拟目录/hdfs://host-name:9000/…下,它以为数据就存放在这个目录下,其实不然,但对于用户,它只需这样以为就足够了。
(2)实际上,在client提出上传请求时,NameNode会响应它元数据信息,告诉client文件应该分成多少块,存放在哪些DataNode上;同时也会告诉datanode应该复制多少样本,复制在哪。
(3)然后,另一个client想下载这个文件,它会在虚拟目录/hdfs://host-name:9000/…下直接下载得到文件爱你,它以为它是这样得到的,其实不然,但对于用户,它只需这样以为就足够了。
(4)实际上,client请求下载时,NameNode会告诉它在哪些datanode中下载。然后,client去对应的datanode中把block下载下来,合并成一个block得到最终的完整的文件。
1.创建 hadoop 帐户。
2.setup.改 IP ( ???)
3.安装 Java,并修改/etc/profile 文件,配置 java 的环境变量。
4.修改 Host 文件域名。
5.安装 SSH,配置无密钥通信。
6.解压 hadoop。
7.配置 conf 文件下 hadoop-env.sh、core-site.sh、mapre-site.sh、hdfs-site.sh。
8.配置 hadoop 的环境变量。
9.Hadoop namenode -format 格式化namenode
10.Start-all.sh 启动
概念:MapReduce是一种并行可扩展计算模型,并且有较好的容错性,主要解决海量离线数据的批处理。实现下面目标
★ 易于编程 ★ 良好的扩展性 ★ 高容错性
简述:一个作业执行过程中有一个Jobtracker和多个Tasktracker,分别对应于HDFS中的namenode和datanode。Jobclient在用户端把已配置参数打包成jar文件存储在HDFS,并把存储路径提交给Jobtracker,然后Jobtracker创建每一个Task,并且分发到Tasktracker服务中去执行。
详细步骤:
(1) 开发人员编写好MapReduce program,将程序打包运行。
(2) JobClient向JobTracker申请可用Job,JobTracker返回JobClient一个可用Job ID。
(3) JobClient得到Job ID后,将运行Job所需要的资源拷贝到共享文件系统HDFS中。
(4) 资源准备完备后,JobClient向JobTracker提交Job。
(5) JobTracker收到提交的Job后,初始化Job。
(6) 初始化完成后,JobTracker从HDFS中获取输入splits(作业可以该启动多少Mapper任务)。
(7) 与此同时,TaskTracker不断地向JobTracker汇报心跳信息,并且返回要执行的任务。
(8) TaskTracker得到JobTracker分配(尽量满足数据本地化)的任务后,向HDFS获取Job资源(若数据是本地的,不需拷贝数据)。
(9) 获取资源后,TaskTracker会开启JVM子进程运行任务。
1.client上传文件到hdfs,发出上传请求
(检查是否已存在文件、检查权限。若通过检查,直接先将操作写入EditLog,并返回输出流对象。)
2.Namenode首先往edits中记录元数据操作日志,并返回元数据信息给client
(即分成多少block,不同block放在哪些datanode上)
3.client根据namenode返回的信息,对文件进行切分,写入到datanode中。
(client端按128MB的块切分文件。client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点,此后client端和NameNode分配的多个DataNode构成pipeline管道,client端向输出流对象中写数据。client每向第一个DataNode写入一个packet,这个packet便会直接在pipeline里传给第二个、第三个…DataNode。)
4.datanode再将block复制到其他datanode上,并向datanode返回成功信息,若失败,则重新分配datanode进行复制
5.client上传文件成功后,将成功信息返回给NameNode,NameNode将本次元数据信息写入内存
描述:client请求下载时,NameNode会告诉它在哪些datanode中下载。然后,client去对应的datanode中把block下载下来,合并成一个block得到最终的完整的文件。
读详细步骤:
(1)client访问NameNode,查询元数据信息,获得这个文件的数据块位置列表,返回输入流对象。
(2)就近挑选一台datanode服务器,请求建立输入流 。
(3)DataNode向输入流中写数据,以packet为单位来校验。
(4)关闭输入流
(1)在Linux文件系统中,我们可以使用下面的Shell脚本判断某个文件是否存在:
# 这里的-f参数判断$file是否存在
if [ ! -f "$file" ]; then
echo "文件不存在!"
fi
(2)Hadoop内置提供了判断某个文件是否存在的命令:可以使用test命令来判断某个文件是否存在。如果文件存在,这个命令将返回0;反之则返回1。
$ hadoop fs -test -e /path
$ echo $?
fsimage与editlog作用:
(1)fsimage保存了最新的元数据检查点,在HDFS启动时加载fsimage的信息,包含了整个HDFS文件系统的所有目录和文件的信息。 对于文件来说包括了数据块描述信息、修改时间、访问时间等;对于目录来说包括修改时间、访问权限控制信息(目录所属用户,所在组)等。
(2)editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录,HDFS客户端执行所有的写操作都会被记录到editlog中。
---------------------
大家都知道namenode与secondary namenode 的关系,当他们要进行数据同步时叫做checkpoint时就用到了fsimage与edit,fsimage是保存最新的元数据的信息,当fsimage数据到一定的大小时会去生成一个新的文件来保存元数据的信息,这个新的文件就是edit,edit会回滚最新的数据。
不管是hadoop1.x 还是hadoop2.x 都是默认的保存三份,可以通过参数dfs.replication就行修改,副本的数目要根据机器的个数来确定。
Core-site.xml 文件的优化
fs.trash.interval
默认值: 0
说明: 这个是开启hdfs文件删除自动转移到垃圾箱的选项,值为垃圾箱文件清除时间。一般开启这个会比较好,以防错误删除重要文件。单位是分钟。
dfs.namenode.handler.count
默认值:10
说明:Hadoop系统里启动的任务线程数,这里改为40,同样可以尝试该值大小对效率的影响变化进行最合适的值的设定。
mapreduce.tasktracker.http.threads
默认值:40
说明:map和reduce是通过http进行数据传输的,这个是设置传输的并行线程数。
---------------------
(1)执行hadoop job -list 拿到job-id
(2)Hadoop job kill hadoop-id
1,reduce side join
在reduce阶段join。
map阶段标记数据来自哪个文件,比如来自file1标记tag=1,来自file2标记tag=2。
reduce阶段把key相同的file1的数据和file2的数据通过笛卡尔乘积join在一起。
个人理解:举个例子
file1 有{1:'a', 2:'b', 3:'c'}
file2 有{1:'A', 2:'B'}
可以join成{1:['a','A'], 2:['b', 'B']}
2,map side join
在map阶段join。
适用于情况:两个待连接表中,有一个表非常大,而另一个表非常小。以至于小的表可以放进去内存中。
那么就把小表在每个map task中复制一份,然后只扫描大表,对大表中的每一条记录,看看key是否存在于小表中,将匹配的key的数据join起来输出。
3,semijoin半连接
这个是要改进reduce side join。建立一个小表file3,把file1的所有要参加join的数据的key复制进去,然后把file3复制到每一个map task中去,然后找出不在file2中的key,过滤掉这些数据后再进行reduce side join,减少跨机器数据传输。
个人理解:举个例子
file1 有{1:'a', 2:'b', 3:'c'}
file2 有{1:'A', 2:'B'}
建立一个小表file3,所有要参加join的数据的key复制进去也就是
[1, 2, 3],然后发现file2中没有key=3的,所以可以过滤掉key=3的数据后再进行reduce join,来减少跨机器数据传输。
4,加入bloom filter
继续改进3。引入bloom filter。这种数据结构的特点是,存在false positive。如果使用它判断一个元素在集合中(positive),那其实有可能不在(false)。但是如果使用它判断一个元素不在集合中,那这个元素就真的不在这个集合中了。(没有false negative)
利用这个特点可以怎么改进3呢?在3中的file3我们可以用bloom filter来实现,要判断file2的key是否存在于file3中的时候直接使用bloom filter来判断。这样,如果判断说file2的某个key存在于file3中(positive),但是实际不在(false),那也无所谓,只是少过滤了一些key而已,还是可以正确地join。但是bloom filter可以保证没有false negative,如果判断file2的某个key不在file3中,那就真的不在file3中,这样可以保证join的正确性(不会少join了一些数据)。
(1)二次排序就是首先按照第一字段排序,然后再对第一字段相同的行按照第二字段排序,注意不能破坏第一次排序的结果。
这里主要讲如何使用一个MapReduce就可以实现二次排序。Hadoop有自带的SecondarySort程序,但这个程序只能对整数进行排序,所以我们需要对其进行改进,使其可以对任意字符串进行排序。
(2)一个 MapReduce 作业由 Map 阶段和 Reduce 阶段两部分组成,这两阶段会对数据排序。从这个意义上说,MapReduce 框架本质就是一个 Distributed Sort。
在 Map阶段,在 Map 阶段,Map Task 会在本地磁盘输出一个按照 key 排序(采用的是快速排序)的文件(中间可能产生多个文件,但最终会合并成一个)
在 Reduce 阶段,每个 Reduce Task 会对收到的数据排序,这样,数据便按照 Key 分成了若干组,之后以组为单位交给 reduce()处理。实际上 Map 阶段的排序就是为了减轻 Reduce端排序负载。由于这些排序是 MapReduce 自动完成的,用户无法控制,因此,在hadoop 1.x 中无法避免,也不可以关闭,但 hadoop2.x 是可以关闭的。
combine和partition都是函数,中间的步骤应该只有shuffle! combine分为map端和reduce端,作用是把同一个key的键值对合并在一起,可以自定义的,partition是分割map每个节点的结果,按照key分别映射给不同的reduce,也是可以自定义的。这里其实可以理解归类。
(1) Gzip 压缩
优点:压缩率比较高,而且压缩/解压速度也比较快; hadoop 本身支持,在应用中处理gzip 格式的文件就和直接处理文本一样;大部分 linux 系统都自带 gzip 命令,使用方便.
缺点:不支持 split。
应用场景: 当每个文件压缩之后在 130M 以内的(1 个块大小内),都可以考虑用 gzip压缩格式。 例如说一天或者一个小时的日志压缩成一个 gzip 文件,运行 mapreduce 程序的时候通过多个 gzip 文件达到并发。 hive 程序, streaming 程序,和 java 写的 mapreduce 程序完全和文本处理一样,压缩之后原来的程序不需要做任何修改。
(2) Bzip2 压缩
优点:支持 split;具有很高的压缩率,比 gzip 压缩率都高; hadoop 本身支持,但不支持 native;在 linux 系统下自带 bzip2 命令,使用方便。
缺点:压缩/解压速度慢;不支持 native。
应用场景: 适合对速度要求不高,但需要较高的压缩率的时候,可以作为 mapreduce 作业的输出格式; 或者输出之后的数据比较大,处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况;或者对单个很大的文本文件想压缩减少存储空间,同时又需要支持 split,而且兼容之前的应用程序(即应用程序不需要修改)的情况。
(3) Lzo 压缩
优点:压缩/解压速度也比较快,合理的压缩率;支持 split,是 hadoop 中最流行的压缩格式;可以在 linux 系统下安装 lzop 命令,使用方便。
缺点:压缩率比 gzip 要低一些; hadoop 本身不支持,需要安装;在应用中对 lzo 格式的文件需要做一些特殊处理(为了支持 split 需要建索引,还需要指定 inputformat 为 lzo 格式)。
应用场景: 一个很大的文本文件,压缩之后还大于 200M 以上的可以考虑,而且单个文件越大, lzo 优点越越明显。
(4) Snappy 压缩
优点:高速压缩速度和合理的压缩率。
缺点:不支持 split;压缩率比 gzip 要低; hadoop 本身不支持,需要安装;
应用场景: 当 Mapreduce 作业的 Map 输出的数据比较大的时候,作为 Map 到 Reduce的中间数据的压缩格式;或者作为一个 Mapreduce 作业的输出和另外一个Mapreduce 作业的输入。
目前Hadoop有三种比较流行的资源调度器:FIFO 、Capacity Scheduler、Fair Scheduler。目前hadoop2.7默认使用的是Capacity Scheduler容量调度器。
一、FIFO(先入先出调度器)
hadoop1.x使用的默认调度器就是FIFO。FIFO采用队列方式将一个一个job任务按照时间先后顺序进行服务。比如排在最前面的job需要若干maptask和若干reducetask,当发现有空闲的服务器节点就分配给这个job,直到job执行完毕。
二、Capacity Scheduler(容量调度器)
hadoop2.x使用的默认调度器是Capacity Scheduler。
1、支持多个队列,每个队列可配置一定量的资源,每个采用FIFO的方式调度。
2、为了防止同一个用户的job任务独占队列中的资源,调度器会对同一用户提交的job任务所占资源进行限制。
3、分配新的job任务时,首先计算每个队列中正在运行task个数与其队列应该分配的资源量做比值,然后选择比值最小的队列。比如如图队列A15个task,20%资源量,那么就是15%0.2=70,队列B是25%0.5=50 ,队列C是25%0.3=80.33 。所以选择最小值队列B。
4、其次,按照job任务的优先级和时间顺序,同时要考虑到用户的资源量和内存的限制,对队列中的job任务进行排序执行。
5、多个队列同时按照任务队列内的先后顺序一次执行。例如下图中job11、job21、job31分别在各自队列中顺序比较靠前,三个任务就同时执行。
三、Fair Scheduler(公平调度器)
1、支持多个队列,每个队列可以配置一定的资源,每个队列中的job任务公平共享其所在队列的所有资源。
2、队列中的job任务都是按照优先级分配资源,优先级越高分配的资源越多,但是为了确保公平每个job任务都会分配到资源。优先级是根据每个job任务的理想获取资源量减去实际获取资源量的差值决定的,差值越大优先级越高。
第一不会给储存带来影响,因为有其他的副本保存着,不过建议尽快修复,第二会影响运算的效率,机器少了,reduce在保存数据时选择就少了,一个数据的块就大了所以就会慢。
1.原因是hadoop集群在启动的时候,datanode会上报自己的block的信息给namenode。namenode把这些信息放到内存中。那么如果块变大了,那么namenode的记录的信息相对减少,所以namenode就有更多的内存去做的别的事情,使得整个集群的性能增强。
2.增大会不会带来负面相应。
因为这个可以灵活设置,所以这里不是问题。关键是什么时候,该如何设置。
如果对于数两级别为PB的话,建议可以block设置的大一些。
如果数据量相对较少,可以设置的小一些64M也未尝不可。
负面效应,如果网络环境不好,可能会造成重新传输。
在mapreduce中map是有块的大小来决定的,reduce的数量可以按照用户的业务来配置。
随着大数据的快速发展,多机器的协调工作,避免主要机器单点故障的问题,于是就引入管理机器的一个软件,他就是zookeeper来协助机器正常的运行。Zookeeper有两个角色分别是leader与follower ,其中leader是主节点,其他的是副节点,在安装配置上一定要注意配置奇数个的机器上,便于zookeeper快速切换选举其他的机器。在其他的软件执行任务时在zookeeper注册时会在zookeeper下生成相对应的目录,以便zookeeper去管理机器。
三种广泛使用的输入格式是:
·文本输入:Hadoop中的默认输入格式。
·Key值:用于纯文本文件
·序列:用于依次读取文件
需要在主节点上部署jobtracker和namenode,然后在多个从节点上部署datanode。
需要启动平衡器才能在所有节点之间重新平均分配数据,以便Hadoop集群自动查找新的datanode。要优化集群性能,应该重新启动平衡器以在数据节点之间重新分配数据。
“Hive”,HBase,HDFS,ZooKeeper,NoSQL,Lucene / SolrSee,Avro,Oozie,Flume,和SQL是一些增强大数据性能的Hadoop工具。
DataNode,NameNode,TaskTracker和JobTracker都是运行Hadoop集群需要的守护进程。
Hadoop 是一个开源软件框架,用于存储大量数据,并发处理/查询在具有多个商用硬件(即低成本硬件)节点的集群上的那些数据。总之,Hadoop 包括以下内容:
HDFS(Hadoop Distributed File System,Hadoop 分布式文件系统):HDFS 允许你以一种分布式和冗余的方式存储大量数据。例如,1 GB(即 1024 MB)文本文件可以拆分为 16 * 128MB 文件,并存储在 Hadoop 集群中的 8 个不同节点上。每个分裂可以复制 3 次,以实现容错,以便如果 1 个节点故障的话,也有备份。HDFS 适用于顺序的“一次写入、多次读取”的类型访问。
MapReduce:一个计算框架。它以分布式和并行的方式处理大量的数据。当你对所有年龄> 18 的用户在上述 1 GB 文件上执行查询时,将会有“8 个映射”函数并行运行,以在其 128 MB 拆分文件中提取年龄> 18 的用户,然后“reduce”函数将运行以将所有单独的输出组合成单个最终结果。
YARN(Yet Another Resource Nagotiator,又一资源定位器):用于作业调度和集群资源管理的框架。
Hadoop 生态系统,拥有 15 多种框架和工具,如 Sqoop,Flume,Kafka,Pig,Hive,Spark,Impala 等,以便将数据摄入 HDFS,在 HDFS 中转移数据(即变换,丰富,聚合等),并查询来自 HDFS 的数据用于商业智能和分析。某些工具(如 Pig 和 Hive)是 MapReduce 上的抽象层,而 Spark 和 Impala 等其他工具则是来自 MapReduce 的改进架构/设计,用于显著提高的延迟以支持近实时(即 NRT)和实时处理。
Hadoop 组织正在从以下几个方面提高自己的能力:
现有数据基础设施:
基于 Hadoop 的更智能的数据基础设施,其中
这使得组织能够使用更强大的工具来做出更好的业务决策,这些更强大的工具用于获取数据,转移存储的数据(例如聚合,丰富,变换等),以及使用低延迟的报告功能和商业智能。
提取数据,存储数据(即数据建模)和处理数据(即数据加工,数据转换和查询数据)。
(1)提取数据
从各种来源提取数据,例如:
并将其存储在基于 HDFS的数据中心上。可以通过批处理作业(例如每 15 分钟运行一次,每晚一次等),近实时(即 100 毫秒至 2 分钟)流式传输和实时流式传输(即 100 毫秒以下)去采集数据。
Hadoop 中使用的一个常用术语是“Schema-On-Read”。这意味着未处理(也称为原始)的数据可以被加载到 HDFS,其具有基于处理应用的需求在处理之时应用的结构。这与“Schema-On-Write”不同,后者用于需要在加载数据之前在 RDBM 中定义模式。
(2)存储数据
数据可以存储在 HDFS 或 NoSQL 数据库,如 HBase。HDFS 针对顺序访问和“一次写入和多次读取”的使用模式进行了优化。HDFS 具有很高的读写速率,因为它可以将 I / O 并行到多个驱动器。HBase 在 HDFS 之上,并以柱状方式将数据存储为键/值对。列作为列家族在一起。HBase 适合随机读/写访问。在 Hadoop 中存储数据之前,你需要考虑以下几点:
(3)处理数据
Hadoop 的处理框架使用 HDFS。它使用“Shared Nothing”架构,在分布式系统中,每个节点完全独立于系统中的其他节点。没有共享资源,如 CPU,内存以及会成为瓶颈的磁盘存储。Hadoop 的处理框架(如 Spark,Pig,Hive,Impala 等)处理数据的不同子集,并且不需要管理对共享数据的访问。 “Shared Nothing”架构是非常可扩展的,因为更多的节点可以被添加而没有更进一步的争用和容错,因为每个节点是独立的,并且没有单点故障,系统可以从单个节点的故障快速恢复。
CSV 文件
CSV 文件通常用于在 Hadoop 和外部系统之间交换数据。CSV 是可读和可解析的。 CSV 可以方便地用于从数据库到 Hadoop 或到分析数据库的批量加载。在 Hadoop 中使用 CSV 文件时,不包括页眉或页脚行。文件的每一行都应包含记录。CSV 文件对模式评估的支持是有限的,因为新字段只能附加到记录的结尾,并且现有字段不能受到限制。CSV 文件不支持块压缩,因此压缩 CSV 文件会有明显的读取性能成本。
JSON 文件
JSON 记录与 JSON 文件不同;每一行都是其 JSON 记录。由于 JSON 将模式和数据一起存储在每个记录中,因此它能够实现完整的模式演进和可拆分性。此外,JSON 文件不支持块级压缩。
序列文件
序列文件以与 CSV 文件类似的结构用二进制格式存储数据。像 CSV 一样,序列文件不存储元数据,因此只有模式进化才将新字段附加到记录的末尾。与 CSV 文件不同,序列文件确实支持块压缩。序列文件也是可拆分的。序列文件可以用于解决“小文件问题”,方式是通过组合较小的通过存储文件名作为键和文件内容作为值的 XML 文件。由于读取序列文件的复杂性,它们更适合用于在飞行中的(即中间的)数据存储。
注意:序列文件是以 Java 为中心的,不能跨平台使用。
Avro 文件
适合于有模式的长期存储。Avro 文件存储具有数据的元数据,但也允许指定用于读取文件的独立模式。启用完全的模式进化支持,允许你通过定义新的独立模式重命名、添加和删除字段以及更改字段的数据类型。Avro 文件以 JSON 格式定义模式,数据将采用二进制 JSON 格式。Avro 文件也是可拆分的,并支持块压缩。更适合需要行级访问的使用模式。这意味着查询该行中的所有列。不适用于行有 50+ 列,但使用模式只需要访问 10 个或更少的列。Parquet 文件格式更适合这个列访问使用模式。
Columnar 格式,例如 RCFile,ORC
RDBM 以面向行的方式存储记录,因为这对于需要在获取许多列的记录的情况下是高效的。如果在向磁盘写入记录时已知所有列值,则面向行的写也是有效的。但是这种方法不能有效地获取行中的仅 10% 的列或者在写入时所有列值都不知道的情况。这是 Columnar 文件更有意义的地方。所以 Columnar 格式在以下情况下工作良好
RC 和 ORC 格式是专门用 Hive 写的而不是通用作为 Parquet。
Parquet 文件
Parquet 文件是一个 columnar 文件,如 RC 和 ORC。Parquet 文件支持块压缩并针对查询性能进行了优化,可以从 50 多个列记录中选择 10 个或更少的列。Parquet 文件写入性能比非 columnar 文件格式慢。Parquet 通过允许在最后添加新列,还支持有限的模式演变。Parquet 可以使用 Avro API 和 Avro 架构进行读写。
所以,总而言之,相对于其他,你应该会更喜欢序列,Avro 和 Parquet 文件格式;序列文件用于原始和中间存储,Avro 和 Parquet 文件用于处理。
创建目录
hadoop dfs -mkdir /home
上传文件或目录到hdfs
hadoop dfs -put hello /
hadoop dfs -put hellodir/ /
查看目录
hadoop dfs -ls /
创建一个空文件
hadoop dfs -touchz /wahaha
删除一个文件
hadoop dfs -rm /wahaha
删除一个目录
hadoop dfs -rmr /home
重命名
hadoop dfs -mv /hello /hello2
查看文件
hadoop dfs -cat /hello
将指定目录下的所有内容merge成一个文件,下载到本地
hadoop dfs -getmerge /hellodir wa
使用du文件和目录大小
hadoop dfs -du /
将目录拷贝到本地
hadoop dfs -copyToLocal /home localdir
查看dfs的情况
hadoop dfsadmin -report
查看正在跑的Java程序
jps
Linux与shell常用指令:linux常用命令与shell编程
list与set的区别?
List特点:元素有放入顺序,元素可重复 ,Set特点:元素无放入顺序,元素不可重复。
ArrayList、Vector、LinkedList 的区别及其优缺点?HashMap、HashTable 的区别及优缺点?
ArrayList 和 Vector 是采用数组方式存储数据的,是根据索引来访问元素的,都可以
根据需要自动扩展内部数据长度,以便增加和插入元素,都允许直接序号索引元素,但
是插入数据要涉及到数组元素移动等内存操作,所以索引数据快插入数据慢,他们最大
的区别就是 synchronized 同步的使用。
LinkedList 使用双向链表实现存储,按序号索引数据需要进行向前或向后遍历,但
是插入数据时只需要记录本项的前后项即可,所以插入数度较快!
如果只是查找特定位置的元素或只在集合的末端增加、移除元素,那么使用 Vector
或 ArrayList 都可以。如果是对其它指定位置的插入、删除操作,最好选择 LinkedList
HashMap、HashTable 的区别及其优缺点:
HashTable 中的方法是同步的 HashMap 的方法在缺省情况下是非同步的 因此在多线程环境下需要做额外的同步机制。
HashTable 不允许有 null 值 key 和 value 都不允许,而 HashMap 允许有 null 值 key和 value 都允许 因此 HashMap 使用 containKey()来判断是否存在某个键。
HashTable 使用 Enumeration ,而 HashMap 使用 iterator。
Hashtable 是 Dictionary 的子类,HashMap 是 Map 接口的一个实现类。
使用 StringBuffer 而不是 String?
当需要对字符串进行操作时,使用 StringBuffer 而不是 String,String 是 read-only 的,如果对它进行修改,会产生临时对象,而 StringBuffer 是可修改的,不会产生临时对象。
ArrayList反转?
用Collections.reverse(list)即可。
链表的反转?
简单描述一下java的gc机制,常用的JAVA调优的方法,OOM如何产生的,如何处理OOM问题???
1、程序在运行时会产生很多的对象的信息,当这些对象的信息没有用时,则会被gc回收
2、调优的方式主要是调节年轻代与老年代的内存的大小
3、OOM是OutOfMemory的缩写(搞得跟多高大上似的)就是线程创建的多了,没有及时的回收过来所产生的
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。