中国领先的IT技术网站
51CTO旗下网站
Hadoop在MapReduce中使用压缩详解
Hadoop对于压缩格式的是透明识别,我们的MapReduce任务的执行是透明的，Hadoop能够自动为我们将压缩的文件解压，而不用我们去关心。
作者：ggjucheng来源：博客园| 10:30
Hadoop对于压缩文件的支持
如果我们压缩的文件有相应压缩格式的扩展名（比如lzo，gz，bzip2等），hadoop就会根据扩展名去选择解码器解压。
hadoop对每个压缩格式的支持,详细见下表：
如果压缩的文件没有扩展名，则需 要在执行mapreduce任务的时候指定输入格式.
hadoop&jar&/usr/home/hadoop/hadoop-0.20.2/contrib/streaming/hadoop-streaming-0.20.2-CD&H3B4.jar&-file&/usr/home/hadoop/hello/mapper.py&-mapper&/usr/home/hadoop/hello/mapper.py&-file&/usr/home/hadoop/hello/reducer.py&-reducer&/usr/home/hadoop/hello/reducer.py&-input&lzotest&-output&result4&-jobconf&mapred.reduce.tasks=1&*-inputformat&org.apache.hadoop.mapred.LzoTextInputFormat*&&
hadoop下各种压缩算法的压缩比，压缩时间，解压时间见下表:
原始文件大小
压缩后的文件大小
解压缩速度
hadoop各种压缩算法的优缺点简述
在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否支持分割是很重要的。考虑存储在HDFS中的未压缩的文件，其大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块，将此文件用作输入的MapReduce作业会创建1个输人分片（split ,也称为&分块&。对于block，我们统一称为&块&。）每个分片都被作为一个独立map任务的输入单独进行处理。
现在假设。该文件是一个gzip格式的压缩文件，压缩后的大小为1GB。和前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。gzip格式使用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，gzip不支持分割(块)机制。
在这种情况下，MapReduce不分割gzip格式的文件，因为它知道输入是gzip压缩格式的(通过文件扩展名得知)，而gzip压缩机制不支持分割机制。这样是以牺牲本地化为代价:一个map任务将处理16个HDFS块。大都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从而导致运行时间变长。
在我们假设的例子中，如果是一个LZO格式的文件，我们会碰到同样的问题，因为基本压缩格式不为reader提供方法使其与流同步。但是，bzip2格式的压缩文件确实提供了块与块之间的同步标记(一个48位的PI近似值)，因此它支持分割机制。
对于文件的收集，这些问题会稍有不同。ZIP是存档格式，因此它可以将多个文件合并为一个ZIP文件。每个文件单独压缩，所有文档的存储位置存储在ZIP文件的尾部。这个属性表明ZIP文件支持文件边界处分割，每个分片中包括ZIP压缩文件中的一个或多个文件。
在MapReduce我们应该使用哪种压缩格式
根据应用的具体情况来决定应该使用哪种压缩格式。就个人而言，更趋向于使用最快的速度压缩，还是使用最优的空间压缩？一般来说，应该尝试不同的策略，并用具有代表性的数据集进行测试，从而找到最佳方法。对于那些大型的、没有边界的文件，如日志文件，有以下选项。
存储未压缩的文件。
使用支持分割机制的压缩格式，如bzip2。
在应用中将文件分割成几个大的数据块，然后使用任何一种支持的压缩格式单独压缩每个数据块(可不用考虑压缩格式是否支持分割)。在这里，需要选择数据块的大小使压缩后的数据块在大小上相当于HDFS的块。
使用支持压缩和分割的Sequence File(序列文件)。
对于大型文件，不要对整个文件使用不支持分割的压缩格式，因为这样会损失本地性优势，从而使降低MapReduce应用的性能。
hadoop支持Splittable压缩lzo
在hadoop中使用lzo的压缩算法可以减小数据的大小和数据的磁盘读写时间，在HDFS中存储压缩数据，可以使集群能保存更多的数据，延长集群的使用寿命。不仅如此，由于mapreduce作业通常瓶颈都在IO上，存储压缩数据就意味这更少的IO操作，job运行更加的高效。
但是在hadoop上使用压缩也有两个比较麻烦的地方：第一，有些压缩格式不能被分块，并行的处理，比如gzip。第二，另外的一些压缩格式虽然支持分块处理，但是解压的过程非常的缓慢，使job的瓶颈转移到了cpu上，例如bzip2。
如果能够拥有一种压缩算法，即能够被分块，并行的处理，速度也非常的快，那就非常的理想。这种方式就是lzo。
lzo的压缩文件是由许多的小的blocks组成（约256K），使的hadoop的job可以根据block的划分来split job。不仅如此，lzo在设计时就考虑到了效率问题，它的解压速度是gzip的两倍，这就让它能够节省很多的磁盘读写，它的压缩比的不如gzip，大约压缩出来的文件比gzip压缩的大一半，但是这样仍然比没有经过压缩的文件要节省20%-50%的存储空间，这样就可以在效率上大大的提高job执行的速度。
hadoop下lzo配置文档参考
如何在MapReduce中使用压缩
1.输入的文件的压缩
如果输入的文件是压缩过的，那么在被MapReduce读取时，它们会被自动解压，根据文件扩展名来决定应该使用哪一个压缩解码器。
2.MapReduce作业的输出的压缩
如果要压缩MapReduce作业的输出，请在作业配置文件中将press属性设置为true。将pression.codec属性设置为自己打算使用的压缩编码/解码器的类名。
如果为输出使用了一系列文件，可以设置pression.type属性来控制压缩类型，默认为RECORD，它压缩单独的记录。将它改为BLOCK，则可以压缩一组记录。由于它有更好的压缩比，所以推荐使用。
3.map作业输出结果的压缩
即使MapReduce应用使用非压缩的数据来读取和写入，我们也可以受益于压缩map阶段的中间输出。因为map作业的输出会被写入磁盘并通过网络传输到reducer节点，所以如果使用LZO之类的快速压缩，能得到更好的性能，因为传输的数据量大大减少了。以下代码显示了启用rnap输出压缩和设置压缩格式的配置属性。
conf.setCompressMapOutput(true); &conf.setMapOutputCompressorClass(GzipCodec.class);&
本地压缩库
考虑到性能，最好使用一个本地库（native library）来压缩和解压。例如，在一个测试中，使用本地gzip压缩库减少了解压时间50%，压缩时间大约减少了10%(与内置的Java实现相比较)。表4-4展示了Java和本地提供的每个压缩格式的实现。井不是所有的格式都有本地实现(例如bzip2压缩)，而另一些则仅有本地实现（例如LZO）。
Hadoop带有预置的32位和64位Linux的本地压缩库，位于库/本地目录。对于其他平台，需要自己编译库，具体请参见Hadoop的维基百科http://wiki.apache.org/hadoop/NativeHadoop。
本地库通过Java系统属性java.library.path来使用。Hadoop的脚本在bin目录中已经设置好这个属性，但如果不使用该脚本，则需要在应用中设置属性。
默认情况下，Hadoop会在它运行的平台上查找本地库，如果发现就自动加载。这意味着不必更改任何配置设置就可以使用本地库。在某些情况下，可能希望禁用本地库，比如在调试压缩相关问题的时候。为此，将属性hadoop.native.lib设置为false，即可确保内置的Java等同内置实现被使用(如果它们可用的话)。
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
专题原创原创外电头条
24H热文一周话题本月最赞
讲师：1人学习过
讲师：15人学习过
讲师：5人学习过
精选博文论坛热帖下载排行
《网管员必读―服务器与数据存储》全面、系统地介绍了在中、高级网络管理和网络工程实施中两个重要方面的主流技术和应用：硬件服务器和数据...
订阅51CTO邮刊您现在的位置：&&>>&&>>&&>>&&>>&正文
Hadoop在MapReduce中使用压缩详解
&&& Hadoop对于压缩文件的支持&&& &&& 如果我们压缩的文件有相应压缩格式的扩展名（比如lzo,gz,bzip2等），hadoop就会根据扩展名去选择解码器解压。&&& &&& hadoop对每个压缩格式的支持，详细见下表：
&&&&&&& 如果压缩的文件没有扩展名，则需 要在执行mapreduce任务的时候指定输入格式。&&& &&& hadoop jar /usr/home/hadoop/hadoop-0.20.2/contrib/streaming/hadoop-streaming-0.20.2-CD H3B4.jar&&& &&& -file /usr/home/hadoop/hello/mapper.py -mapper /usr/home/hadoop/hello/mapper.py&&& &&& -file /usr/home/hadoop/hello/reducer.py -reducer /usr/home/hadoop/hello/reducer.py&&& &&& -input lzotest -output result4&&& &&& -jobconf mapred.reduce.tasks=1&&& &&& *-inputformat org.apache.hadoop.mapred.LzoTextInputFormat*& hadoop&&& &&& 下各种压缩算法的压缩比，压缩时间，解压时间见下表：&&& &&& 压缩算法 原始文件大小 压缩后的文件大小 压缩速度 解压缩速度&&& &&& gzip 8.3GB 1.8GB 17.5MB/s 58MB/s&&& &&& bzip2 8.3GB 1.1GB 2.4MB/s 9.5MB/s&&& &&& LZO-bset 8.3GB 2GB 4MB/s 60.6MB/s&&& &&& LZO 8.3GB 2.9GB 49.3MB/S 74.6MB/s&&& &&& hadoop各种压缩算法的优缺点简述&&& &&& 在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否支持分割是很重要的。考虑在HDFS中的未压缩的文件，其大小为1GB,HDFS的块大小为64MB,所以该文件将被为16块，将此文件用作输入的MapReduce作业会创建1个输人分片（split ,也称为"分块".对于block,我们统一称为"块".）每个分片都被作为一个独立map任务的输入单独进行处理。&&& &&& 现在假设。该文件是一个gzip格式的压缩文件，压缩后的大小为1GB.和前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。gzip格式使用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，gzip不支持分割（块）机制。[1]&&
【责编:peter】
?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]
相关产品和培训
　友情推荐链接
　认证培训
　专题推荐
　?　?　?　?　?　?　?　?　?　?
　今日更新
?&?&?&?&?&?&?&?&?&?&
　社区讨论
　博客论点
　频道精选
　C/C++频道相关导航　　文件压缩主要有两个好处，一是减少了存储文件所占空间，另一个就是为数据传输提速。在hadoop大数据的背景下，这两点尤为重要，那么我现在就先来了解下hadoop中的文件压缩。
hadoop里支持很多种压缩格式，我们看一个表格：
DEFLATE是同时使用了LZ77算法与哈夫曼编码（Huffman Coding）的一个无损数据压缩算法，源代码可以在zlib库中找到。gzip是以DEFLATE算法为基础扩展出来的一种算法。
所有的压缩算法都是空间和时间的转换，更快压缩时间还是更小的压缩比，可以通过参数来指定，－1意味着速度，－9意味着空间。拿gzip做个例子，下面就意味着更快速的压缩：
gzip&-1&file&&
gzip在时间和空间上的取舍比较折中，bzip2压缩比gzip更有效，但是速度更慢。bzip2的解压速度比它的压缩速度要快。但是和其他压缩格式比又是最慢的，但是压缩效果明显是最好的。snappy和lz4的解压速度比lzo好很多。
&splittable表示压缩格式是否可以被分割，也就是说是否支持随即读。压缩数据是否能被mapreduce使用，压缩数据是否能被分割就很关键了。
举个例子，一个未压缩的文件有1GB大小，hdfs默认的block大小是64MB,那么这个文件就会被分为16个block作为mapreduce的输入，每一个单独使用一个map任务。如果这个文件是已经使用gzip压缩的呢，如果分成16个块，每个块做成一个输入，显然是不合适的，因为gzip压缩流的随即读是不可能的。实际上，当mapreduce处理压缩格式的文件的时候它会认识到这是一个gzip的压缩文件，而gzip又不支持随即读，它就会把16个块分给一个map去处理，这里就会有很多非本地处理的map任务，整个过程耗费的时间就会相当长。
lzo压缩格式也会是同样的问题，但是通过使用hadoop lzo库的索引工具以后，lzo就可以支持splittable。bzip2也是支持splittable的。
那么如何选择压缩格式呢？这取决于文件的大小，你使用的压缩工具，下面是几条选择建议，效率由高到低排序：
1.用一些包含了压缩并且支持splittable的文件格式，比如Sequence File，RCFile或者Avro文件，这些文件格式我们之后都会讲到。如果为了快速压缩可以使用lzo，lz4或者snappy压缩格式。
2.使用提供splittable的压缩格式，比如，bzip2和索引后可以支持splittable的lzo。
3.提前把文件分成几个块，每个块单独压缩，这样就无需考虑splittable的问题了
4.不要压缩文件
提示：以不支持splittable的压缩格式存储一个很大的数据文件是不合适的，非本地处理效率会非常之低。
&转至：http://blog.csdn.net/lastsweetop/article/details/9162031
【四种常用压缩工具介绍】
1 gzip压缩
优点：压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。
缺点：不支持split。
应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和java写的mapreduce程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。
优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；可以在linux系统下安装lzop命令，使用方便。
缺点：压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。
应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越明显。
3 snappy压缩
优点：高速压缩速度和合理的压缩率；支持hadoop native库。
缺点：不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；linux系统下没有对应的命令。
应用场景：当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。
4 bzip2压缩
优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便。
缺点：压缩/解压速度慢；不支持native。
应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程序（即应用程序不需要修改）的情况。
最后用一个表格比较上述4种压缩格式的特征（优缺点）：
4种压缩格式的特征的比较
压缩格式splitnative压缩率速度是否hadoop自带linux命令换成压缩格式后，原来的应用程序是否要修改
是，直接使用
和文本处理一样，不需要修改
否，需要安装
需要建索引，还需要指定输入格式
否，需要安装
和文本处理一样，不需要修改
是，直接使用
和文本处理一样，不需要修改
转载请标明出处：&
阅读(...) 评论()人气：2611734
访问用户量：2910
笔记经验：1309
总积分：1409
级别：普通会员
搜索本笔记
ta的交流分类
ta的全部笔记
浏览(8074)|(0)
&&交流分类：|笔记分类:
hadoop对于压缩文件的支持
hadoop对于压缩格式的是透明识别,我们的MapReduce任务的执行是透明的，hadoop能够自动为我们 将压缩的文件解压，而不用我们去关心。&
如果我们压缩的文件有相应压缩格式的扩展名（比如lzo，gz，bzip2等），hadoop就会根据扩展名去选择解码器解压。
hadoop对每个压缩格式的支持,详细见下表：
&文件扩展名
&是，在文件范围内
如果压缩的文件没有扩展名，则需 要在执行mapreduce任务的时候指定输入格式.&
hadoop jar /usr/home/hadoop/hadoop-0.20.2/contrib/streaming/hadoop-streaming-0.20.2-CD H3B4.jar -file /usr/home/hadoop/hello/mapper.py -mapper /usr/home/hadoop/hello/mapper.py -file /usr/home/hadoop/hello/reducer.py -reducer /usr/home/hadoop/hello/reducer.py -input lzotest -output result4 -jobconf mapred.reduce.tasks=1 *-inputformat org.apache.hadoop.mapred.LzoTextInputFormat*
hadoop下各种压缩算法的压缩比，压缩时间，解压时间见下表:
原始文件大小
压缩后的文件大小
解压缩速度
hadoop各种压缩算法的优缺点简述
在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否支持分割是很重要的。考虑存储在HDFS中的未压缩的文件，其大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块，将此文件用作输入的MapReduce作业会创建1个输人分片（split ,也称为“分块”。对于block，我们统一称为“块”。）每个分片都被作为一个独立map任务的输入单独进行处理。
现在假设。该文件是一个gzip格式的压缩文件，压缩后的大小为1GB。和前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。gzip格式使用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，gzip不支持分割(块)机制。
在这种情况下，MapReduce不分割gzip格式的文件，因为它知道输入是gzip压缩格式的(通过文件扩展名得知)，而gzip压缩机制不支持分割机制。这样是以牺牲本地化为代价:一个map任务将处理16个HDFS块。大都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从而导致运行时间变长。
在我们假设的例子中，如果是一个LZO格式的文件，我们会碰到同样的问题，因为基本压缩格式不为reader提供方法使其与流同步。但是，bzip2格式的压缩文件确实提供了块与块之间的同步标记(一个48位的PI近似值)，因此它支持分割机制。
对于文件的收集，这些问题会稍有不同。ZIP是存档格式，因此它可以将多个文件合并为一个ZIP文件。每个文件单独压缩，所有文档的存储位置存储在ZIP文件的尾部。这个属性表明ZIP文件支持文件边界处分割，每个分片中包括ZIP压缩文件中的一个或多个文件。
在MapReduce我们应该使用哪种压缩格式
根据应用的具体情况来决定应该使用哪种压缩格式。就个人而言，更趋向于使用最快的速度压缩，还是使用最优的空间压缩？一般来说，应该尝试不同的策略，并用具有代表性的数据集进行测试，从而找到最佳方法。对于那些大型的、没有边界的文件，如日志文件，有以下选项。
存储未压缩的文件。
使用支持分割机制的压缩格式，如bzip2。
在应用中将文件分割成几个大的数据块，然后使用任何一种支持的压缩格式单独压缩每个数据块(可不用考虑压缩格式是否支持分割)。在这里，需要选择数据块的大小使压缩后的数据块在大小上相当于HDFS的块。
使用支持压缩和分割的Sequence File(序列文件)。
对于大型文件，不要对整个文件使用不支持分割的压缩格式，因为这样会损失本地性优势，从而使降低MapReduce应用的性能。
hadoop支持Splittable压缩lzo
在hadoop中使用lzo的压缩算法可以减小数据的大小和数据的磁盘读写时间，在HDFS中存储压缩数据，可以使集群能保存更多的数据，延长集群的使用寿命。不仅如此，由于mapreduce作业通常瓶颈都在IO上，存储压缩数据就意味这更少的IO操作，job运行更加的高效。
但是在hadoop上使用压缩也有两个比较麻烦的地方：第一，有些压缩格式不能被分块，并行的处理，比如gzip。第二，另外的一些压缩格式虽然支持分块处理，但是解压的过程非常的缓慢，使job的瓶颈转移到了cpu上，例如bzip2。
如果能够拥有一种压缩算法，即能够被分块，并行的处理，速度也非常的快，那就非常的理想。这种方式就是lzo。
lzo的压缩文件是由许多的小的blocks组成（约256K），使的hadoop的job可以根据block的划分来split job。不仅如此，lzo在设计时就考虑到了效率问题，它的解压速度是gzip的两倍，这就让它能够节省很多的磁盘读写，它的压缩比的不如gzip，大约压缩出来的文件比gzip压缩的大一半，但是这样仍然比没有经过压缩的文件要节省20%-50%的存储空间，这样就可以在效率上大大的提高job执行的速度。
hadoop下lzo配置文档参考
如何在MapReduce中使用压缩
1.输入的文件的压缩
如果输入的文件是压缩过的，那么在被MapReduce读取时，它们会被自动解压，根据文件扩展名来决定应该使用哪一个压缩解码器。
2.MapReduce作业的输出的压缩
如果要压缩MapReduce作业的输出，请在作业配置文件中将press属性设置为true。将pression.codec属性设置为自己打算使用的压缩编码/解码器的类名。
如果为输出使用了一系列文件，可以设置pression.type属性来控制压缩类型，默认为RECORD，它压缩单独的记录。将它改为BLOCK，则可以压缩一组记录。由于它有更好的压缩比，所以推荐使用。
3.map作业输出结果的压缩
即使MapReduce应用使用非压缩的数据来读取和写入，我们也可以受益于压缩map阶段的中间输出。因为map作业的输出会被写入磁盘并通过网络传输到reducer节点，所以如果使用LZO之类的快速压缩，能得到更好的性能，因为传输的数据量大大减少了。以下代码显示了启用rnap输出压缩和设置压缩格式的配置属性。
conf.setCompressMapOutput(true); conf.setMapOutputCompressorClass(GzipCodec.class);
本地压缩库
考虑到性能，最好使用一个本地库（native library）来压缩和解压。例如，在一个测试中，使用本地gzip压缩库减少了解压时间50%，压缩时间大约减少了10%(与内置的Java实现相比较)。表4-4展示了Java和本地提供的每个压缩格式的实现。井不是所有的格式都有本地实现(例如bzip2压缩)，而另一些则仅有本地实现（例如LZO）。
Hadoop带有预置的32位和64位Linux的本地压缩库，位于库/本地目录。对于其他平台，需要自己编译库，具体请参见Hadoop的维基百科http://wiki.apache.org/hadoop/NativeHadoop。
本地库通过Java系统属性java.library.path来使用。Hadoop的脚本在bin目录中已经设置好这个属性，但如果不使用该脚本，则需要在应用中设置属性。
默认情况下，Hadoop会在它运行的平台上查找本地库，如果发现就自动加载。这意味着不必更改任何配置设置就可以使用本地库。在某些情况下，可能希望禁用本地库，比如在调试压缩相关问题的时候。为此，将属性hadoop.native.lib设置为false，即可确保内置的Java等同内置实现被使用(如果它们可用的话)。
相关笔记推荐
精品视频课程推荐
内容概述：通过一个真实完整的项目——某大型互联网企业用户上网行为日志分析系统，系统学习Hadoop、Hive，HBase、Zookeeper等云计算开发技术在真实商业系统中到底如何使用。具有极高的学习和参考价值。
该系统是一个每天5亿条数据，上百个节点的实际商业项目，该系统将海量日志数据进行分布式存储，并通过分布式算法和网络爬虫技术形成标签化的用户模型，最终实现人与内容、人与行为、人与商品的智能配对。
技术要点：Hadoop、Hive、HBase、Zookeeper、爬虫技术等
本视频课程是北京Java私塾原创精品书籍《研磨设计模式》一书的配套学习视频，由《研磨设计模式》的第一作者CC录制
课程目标：全面、系统的掌握GoF设计模式的知识，达到可以在实际项目开发中运用的能力
技术要点：如何实现可配置、如何实现缓存以及缓存的管理、如何实现用缓存来控制多实例的创建、如何实现参数化工厂、 如何实现可扩展工厂、如何实现原型管理器、如何实现Java的静态代理和动态代理、如何实现多线程处理队列请求、 如何实现命令的参数化配置、可撤销的操作、宏命令、队列请求和日志请求、如何实现翻页迭代、如何检测环状结构、 如何实现通用的增删改查、如何模拟工作流来处理流程、如何实现简单又通用的XML读取、如何实现模拟AOP的功能......
内容概述：Shiro是目前最热门、最易用、功能超强大的Java权限管理框架，强烈推荐，每个项目都必备的权限管理技术！通过本课程，你将从零开始直到彻底掌握Shiro的相关开发知识，达到可以进行实际项目开发的能力。包括：权限管理基础、Shiro入门、配置、身份认证、授权、Realms、Session管理、和Spring的集成、Web、Cache等众多开发细节技术
技术要点：源码级分析Shiro的授权过程、自定义开发Realm、多个Realms的开发配置、自定义开发AuthenticationStrategy、自定义开发自定义SessionDAO、和Struts2+Spring3的集成（包括修正struts2的bug）、Shiro和SpringMVC+Spring3的集成、包装使用其他的Cache框架、缓存数据同步更新的解决方案等等实际开发中常用的内容
深入浅出的讲解JavaBen的写法、JavaBean的用法、JavaBean的实现机制、JavaBean对应翻译的代码理解。
内容概述：本课程深入浅出的讲解Hadoop 体系下的分布式协调组件－Zookeeper,向大家介绍了Zookeeper的原理与使用，深入浅出，结合生动实例，具有很高的实战意味
技术要点：Zookeepr 原理，Zookeeper 架构，Zookeeper 简单使用，Zookeeper Watch等
浏览(8074)|(0)
&&交流分类：|笔记分类:
版权所有 Copyright(C) 私塾在线学习网}