1，执行命令安装一些依赖组件 yum install -y hadoop-lzo lzo lzo-devel hadoop-lzo-native lzop 2， 下载lzo的源码包并解压 wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.09.tar.gz tar -zxvf lzo-2.09.tar.gz 3，在当前目录新建一个lzo目录，存储编译后的lzo文件 进入lzo-2.09目录 依次执行命令： expor
目前在Hadoop中用得比较多的有lzo，gzip，snappy，bzip2这4种压缩格式，笔者根据实践经验介绍一下这4种压缩格式的优缺点和应用场景，以便大家在实践中根据实际情况选择不同的压缩格式。
关闭防火墙： systemctl stop firewalld systemctl disable firewalld
优点：压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。
很明显，error显示为com.hadoop.compression.lzo.LzoCodec没有找到
数据仓库（Data Warehouse），是为企业所有决策制定过程，提供所有系统数据支持的战略集合。通过对数据仓库中数据的分析，可以帮助企业改进业务流程，控制成本，提高产品质量等。
Hive支持的压缩格式有bzip2、gzip、deflate、snappy、lzo等。Hive依赖Hadoop的压缩方法，所以Hadoop版本越高支持的压缩方法越多，可以在$HADOOP_HOME/conf/core-site.xml中进行配置：
配置CentOS能连接外网。Linux虚拟机ping www.baidu.com 是畅通的 注意：采用root角色编译，减少文件夹权限出现问题
Hive 建设离线数据仓库通常符合：一次写入，多次读取。所以需要我们在建表的时候选择恰当的存储格式和数据的压缩模式。
LZO 是致力于解压速度的一种数据压缩算法，LZO 是 Lempel-Ziv-Oberhumer 的缩写。这个算法是无损算法，参考实现程序是线程安全的。 实现它的一个自由软件工具是lzop。最初的库是用 ANSI C 编写、并且遵从 GNU通用公共许可证发布的。现在 LZO 有用于 Perl、Python 以及 Java 的各种版本。代码版权的所有者是 Markus F. X. J. Oberhumer。 LZO 库实现了许多有下述特点的算法： * 解压简单，速度非常快。 * 解压不需要内存。 *
最近遇到一个日志备份 io 过高的问题，业务日志每十分钟备份一次，本来是用 Python 写一个根据规则扫描备份日志问题不大，但是随着业务越来越多，单机上的日志文件越来越大，文件数量也越来越多，导致每每备份的瞬间 io 阻塞严重， CPU 和 load 异常的高，好在备份速度很快，对业务影响不是很大，这个问题会随着业务增长，越来越明显，这段时间抽空对备份方式做了优化，效果十分显著，整理篇文章记录一下。
3）增加磁盘后，保证每个目录数据均衡 开启数据均衡命令： bin/start-balancer.sh –threshold 10 对于参数10，代表的是集群中各个节点的磁盘空间利用率相差不超过10%，可根据实际情况进行调整。 停止数据均衡命令： bin/stop-balancer.sh 实时的通信检测，也会浪费一定资源，因此调配过后就可以关闭了。
sequenceFile文件是Hadoop用来存储二进制形式的[Key,Value]对而设计的一种平面文件(Flat File)。可以把SequenceFile当做是一个容器，把所有的文件打包到SequenceFile类中可以高效的对小文件进行存储和处理。SequenceFile文件并不按照其存储的Key进行排序存储，SequenceFile的内部类Writer提供了append功能。SequenceFile中的Key和Value可以是任意类型Writable或者是自定义Writable。
环境如下： Centos6.5 Apache Hadoop2.7.1 Apache Hbase0.98.12 Apache Zookeeper3.4.6 JDK1.7 Ant1.9.5 Maven3.0.5 最近在测Hbase的压缩，Hadoop安装了lzo和snappy，插入50条文本数据，每条数据大约4M，来看他们的压缩率对比， 然后在测的过程中，发现用java客户端去scan这50条数据时，regionserver频繁宕机看hbase的log发现并无明显异常，查看datano
Yarn上可以运行各种类型的分布式运算程序（mapreduce只是其中的一种），比如mapreduce、storm程序，spark程序等。
我们Hadoop 2.4集群默认不支持snappy压缩，但是最近有业务方说他们的部分数据是snappy压缩的（这部分数据由另外一个集群提供给他们时就是snappy压缩格式的）想迁移到到我们集群上面来进行计算，但是直接运行时报错：
此篇是接着Hadoop安装lzo的续篇 http://www.linuxidc.com/Linux/2014-03/98602.htm ，主要讲一下安装过程中出现的问题及解决方案。
计数器是收集作业统计信息的有效手段之一，用于质量控制或应用级统计。计数器还可辅助诊断系统故障。如果需要将日志信息传输到map 或reduce 任务， 更好的方法通常是看能否用一个计数器值来记录某一特定事件的发生。对于大型分布式作业而言，使用计数器更为方便。除了因为获取计数器值比输出日志更方便，还有根据计数器值统计特定事件的发生次数要比分析一堆日志文件容易得多。 hadoop内置计数器列表
一、埋点数据生成模块 1. 事件日志格式及字段含义 2. 启动日志格式及字段含义 3. 说明
对于文件的存储、传输、磁盘IO读取等操作在使用Hadoop生态圈的存储系统时是非常常见的，而文件的大小等直接影响了这些操作的速度以及对磁盘空间的消耗。
要想对正在被写入一个输出流的数据进行压缩，我们可以使用createOutputStream(OutputStreamout)方法创建一个CompressionOutputStream，将其以压缩格式写入底层的流。
Flume是Cloudrea公司开源的一款优秀的日志收集框架，主要经历了两个大的版本，分别是 Flume-OG Flume-NG OG是0.9.x的版本，依赖zookeeper，角色职责不够单一
在hdp的官网上有一个ETL工具叫做Talend Open Studio，然后我就下了，并且在群里询问了一下，突然间冒出来一群ETL高手，经高人指点认识了一款叫做Kettle的软件，经过这两天的试用，从直观感受上，Kettle更容易使用和上手，资料更多，界面更友好。。。 优点很多，这里不一一列举了，关键是它对hadoop的支持我觉得是很全面的。 但是这里面有一个问题出现了，它不支持我现在用的版本，我用的是Hortonworks的HDP1.3，好吧，经过不懈的努力，终于被我搜索到了，哈哈，原来它可以支
lzo压缩格式有很快的压缩/解压速度和合理的压缩率，并且支持分块(split)，所以lzo是目前在Hadoop中最流行的压缩格式。hadoop中的lzo不是自带的，如果要支持lzo，需要另外安装。本文介绍了在hadoop2.0上安装和配置lzo，同样也适用于hadoop1.0。
然后根据job的id去yarn上面查询了一下日志，发现报错如下: FATAL [main] org.apache.hadoop.mapred.YarnChild: Error running child : java.lang.OutOfMemoryError: GC overhead limit exceeded
二、安装lzo 1、wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.06.tar.gz 2、tar -zxvf lzo-2.06.tar.gz 3、mv lzo-2.06 lzo && cd lzo 4、export CFLAGS=-m64 5、./configure -enable-shared 6、make && make install【默认安装在了/usr/local/lib下:liblzo2.a liblzo2.la liblzo2.so liblzo2.so.2 liblzo2.so.2.0.0】 7、在/etc/ld.so.conf.d/目录下新建lzo.conf文件,内容： /usr/local/lib 8、让lzo.conf生效:/sbin/ldconfig -v
1）hadoop本身并不支持lzo压缩，故需要使用twitter提供的hadoop-lzo开源组件。hadoop-lzo需依赖hadoop和lzo进行编译，编译步骤如下。 2）将编译好后的hadoop-lzo-0.4.20.jar 放入hadoop-2.7.2/share/hadoop/common/
基础依赖环境 Apache Hadoop2.7.1 Apache Spark1.6.0 Apache Hive1.2.1 Apache Hbase0.98.12 （1）提前安装好scala的版本，我这里是2.11.7 （2）下载spark-1.6.0源码，解压进入根目录编译 （3）dev/change-scala-version.sh 2.11 修改pom文件，修改对应的hadoop，hbase，hive的版本 执行编译支持hive功能的spark （4）mvn -Pyarn
前面的文章介绍了Hadoop lzo的安装和配置（见 http://www.linuxidc.com/Linux/2014-05/101090.htm ），本文接着介绍lzo压缩在hadoop应用程序中的使用方法，包括在mapreduce程序，streaming程序和hive中的使用。 1 给lzo文件建立索引
首先要在需要编译的机器上安装maven（下载安装，配置环境变量，修改sitting.xml加阿里云镜像），这里可以自己搜索相应帖子。
Flash 性能与实际使用物料有关，受不同存储介质、不同厂家、不同型号甚至不同老化程度的影响，所以经验值仅供参考。
在hadoop中搭建lzo环境: wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.06.tar.gz export CFLAGS=-m64 ./configure -enable-shared -prefix=/usr/local/hadoop/lzo/ make && make test && make install 在hadoop-env.sh中 export LD_LIBRARY_PATH=/usr/local/
Hadoop的分布式文件系统（HDFS）是Hadoop的很重要的一部分，本文先简单介绍HDFS的几个特点，然后再分析背后的原理，即怎样实现这种特点的。
CDH中默认不支持Lzo压缩编码，需要下载额外的Parcel包，才能让Hadoop相关组件如HDFS，Hive，Spark支持Lzo编码。
原因： 因为在之前的项目中，在hadoop中的core-site.xml 和mapred-site.xml文件配置了lzo格式的压缩，这就导致上传到hdfs 的文件自动被压缩为lzo了。所以当使用提交spark-submit任务时，需要访问HDFS上的文件，而spark自身没有lzo的jar包所以无法找到。
Spark自带了机器学习的算法mlib，页面网址 http://spark.incubator.apache.org/docs/latest/mllib-guide.html 但是运行的时候，遇到了很多问题，着实让我头疼了很久，不过最后还是解决了，下面说一下这两个问题吧。 第一个demo运行到val model = SVMWithSGD.train(parsedData, numIterations)这一句的时候遇到了lzo的jar包。 我是这么解决的，方法不是很好，我修改了spark-e
这是当时创建表时的语句，指定了存储格式为lzo，然后执行了为lzo文件创建索引的命令
2）ODS层要保存全部历史数据，故其压缩格式应选择压缩比较高的，此处选择gzip。
上一篇文章《使用压缩文件优化io (一)》中记录了日志备份 io 优化方案，使用文件流数据压缩方案优化 io 性能，效果十分显著。这篇文章记录数据分析前置清洗、格式化数据的 io 优化方案，我们有一台专用的日志前置处理服务器，所有业务日志通过这台机器从 OSS 拉取回来清洗、格式化，最后进入到数据仓储中便于后续的分析。
小文件问题的影响 1.从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。
就如上一篇文章介绍的那样，如果输入文件是压缩文件，当 MapReduce 程序读取压缩文件时，根据文件名的后缀来选择 codes，输入文件自动解压缩（我们不需要指定压缩文件是哪一种压缩格式）。
you can probably install the debian libraries into quantal with no issues, precise is less likely to work, but it might possibly you will have to build it from source to get everything right. Code:
文件压缩带来两大好处：它减少了存储文件所需的空间，并加速了数据在网络或者磁盘上的传输速度。在处理大量数据时，这两项节省可能非常重要，因此需要仔细考虑如何在 Hadoop 中使用压缩。
在实际工作当中，hive当中处理的数据，一般都需要经过压缩，前期我们在学习hadoop的时候，已经配置过hadoop的压缩，我们这里的hive也是一样的,可以使用压缩来节省我们的MR处理的网络带宽。
在实际工作当中，hive当中处理的数据，一般都需要经过压缩，可以使用压缩来节省我们的MR处理的网络带宽
最近接触到一些海量数据存储的需求，为了解决这样的需求，一个想法是对数据进行一定程度的聚合。在应用层的聚合方式，这里不展开。但是让我联想到的是以前学习 prometheus tsdb的时候接触到的压缩技术。即使本质上来讲，应用层的数据聚合，就是一种数据压缩技术。而 tsdb 使用的 gorilla 技术令人印象深刻。有兴趣的可以详细看一下 prometheus 作者的这篇博客, 以及其使用的技术 gorilla 的 paper. 简而言之 prometheus 的 tsdb 简洁强大，受益于其高效的压缩【gorilla 平均能压缩 16 byte samples to an average of 1.37 bytes】和查询效率，其单机的设计并没有影响他在众多场景中的广泛使用。
最后无奈。。就用原来的方法 创建软连接，加载数据，发现可以。。这我就不明白了。。。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
