问题标签 [lzo]

我已经让 Hadoop-Lzo 在我的本地伪集群上愉快地工作，但是第二次我在生产中尝试相同的 jar 文件，我得到：

这些库被验证在 DataNodes 上，所以我的问题是：

在哪个屏幕/设置中指定 native-lzo 库的位置？

我已经安装了 Cloudera Hadoop-LZO 包并将以下设置添加到我的客户端环境安全阀中：

但是，我得到了最奇怪的 native-lzo library not available 错误：

为什么会说native-lzo库加载成功，然后又抱怨native-lzo库不可用？这些异常是否来自 DataNodes？

现在，我使用 HTTPfs 的摄取过程大约会超时一分钟。可以调整此超时设置吗？

我正在使用 CDH4 运行 Hadoop 2.0，并使用 Oracle Java 1.6 r31 构建了大象鸟库

我的猪脚本：

结果：

我有使用 lzop 和 lzma 压缩的文件，并且文件名没有适当的扩展名。例如“文件名”而不是文件名.lzo 或文件名.lzma

我怎么知道它们是否以各自的格式压缩？

我正在使用 mrjob 编写任务，以使用 Google Ngrams 数据计算各种统计数据：https ://aws.amazon.com/datasets/8172056142375670

我使用制表符分隔文本中未压缩的数据子集在本地开发和测试了我的脚本。一旦我尝试运行该作业，我就会收到此错误：

这大概是因为公共数据集的压缩方案（来自上面的 URL 链接）：

我们将数据集存储在 Amazon S3 中的单个对象中。该文件是具有块级 LZO 压缩的序列文件格式。序列文件键是存储为 LongWritable 的数据集的行号，值是存储为 TextWritable 的原始数据。

有关如何设置可以处理这些文件的工作流的任何指导？我已经详尽地搜索了提示，但没有找到任何有用的...

（我是 mrjob 和 Hadoop 的相对 n00b。）

您好，我在 HDP 1.3 上安装了 Faunus 0.32 当我按照https://github.com/thinkaurelius/faunus/wiki/Getting-Started中的入门测试用例进行操作时，出现以下错误

我用谷歌搜索，然后在 mapred-site.xml 中添加 lzo

我正在寻找从磁盘读取顺序文件的最快方法。我在一些帖子中读到，如果我使用例如 lz4 压缩文件，我可以获得比读取平面文件更好的性能，因为我将最小化 i/o 操作。

但是当我尝试这种方法时，扫描 lz4 压缩文件给我的性能比扫描平面文件差。上面的lz4demo我没试过，但是找了一下，我的代码很相似。

我找到了这个基准： http ://skipperkongen.dk/2012/02/28/uncompressed-versus-compressed-read/ http://code.google.com/p/lz4/source/browse/trunk/lz4demo。 c?r=75

真的有可能提高读取压缩顺序文件而不是未压缩文件的性能吗？我究竟做错了什么？

我在 Amazon S3 上有许多 LZO 压缩的日志文件，我想从 PHP 中读取这些文件。AWS SDK 提供了一个不错的StreamWrapper来有效地读取这些文件，但是由于文件是压缩的，我需要先解压缩内容才能处理它。

我已经安装了允许我这样做的PHP-LZO 扩展lzo_decompress($data)，但由于我处理的是流而不是完整的文件内容，我假设我需要一次使用一个 LZO 压缩块的字符串。换句话说，我想做类似的事情：

这两个TODOs 是我不确定该怎么做的地方：

1. 检查数据流以确定我是否有完整的 LZO 块
2. 提取此块进行解压

由于压缩是由 Amazon (s3distCp) 完成的，我无法控制块大小，所以我可能需要检查传入流以确定块有多大——这是一个正确的假设吗？

（理想情况下，我会直接在流上使用自定义 StreamFilter，但我无法找到以前这样做过的人）

我在 S3 上有一个 30gb lzo 文件，我正在使用 hadoop-lzo 使用区域 us-east1 使用 Amazon EMR (AMI v2.4.2) 对其进行索引。

1% 的进度大约需要 10 分钟，因此完成一个文件大约需要 16 小时。进度显示只读取了 80mb。

相比之下，使用同一个集群（当上述作业正在运行时），我可以将文件从 S3 复制到本地硬盘，然后复制到 HDFS，最后在大约 10 分钟内运行索引器。同样，我的本地集群可以在大约 7 分钟内处理这个问题。

过去，我相信我直接在 S3 上运行 LZO 索引而没有出现这种延迟，尽管它是在早期的 AMI 版本上。我不知道我使用的是什么 AMI，因为我总是使用“最新”。（更新：我尝试了 AMI v2.2.4 的结果相同，所以也许我记错了或其他原因导致速度缓慢）

任何想法可能会发生什么？

这是 Step 的日志输出的副本：

我的解决方法

distcpFWIW，我的解决方法是通过（见下文）将文件复制到 HDFS 。在我看来，这种缓慢似乎是 AWS 可以改进的一个问题。在下面的作业中，从 S3 复制到 HDFS 需要 17 分钟，而索引只需 1 分钟。