问题标签 [scalding]

我正在尝试构建一个sbt简单的 hadoop 作业，我正在尝试运行它以尝试在 Amazon EMR 上运行它。但是，当我运行时sbt assembly，出现以下错误：

我试图按照这里的建议https://groups.google.com/forum/#!topic/simple-build-tool/tzkq5TioIqM但是它没有用。

我的 build.sbt 看起来像：

我刚开始使用 scalding 并试图找到读取文本文件和写入 hadoop 序列文件的示例。任何帮助表示赞赏。

我正在开发一个需要路径导航图的项目。

问题描述：为了给出项目上下文，示例 UI 应类似于：http ://bl.ocks.org/mbostock/4063570 。不同之处在于它将用于站点导航。我的问题是在后端处理数据。

对于用户路径 A->B->C->D->E 我预计算的数据格式如下所示：

现在，假设我有数百万条这样的记录，其中包含 100 条起源，我可以对它们进行分组、聚合大小并按大小降序排序并取前 10 名。因此，对于每个起源、起点和级别，我每个应该有 10 条记录。因此，对于 4 个级别的图表，对于图中的给定起始节点，我将有 10.. 10^2.. 10^3.. 10^4。

真正的问题：排序后的前10名并不能带走所有不需要的L3和L4。对于给定的原点，L1 的结束应该是 L2 的开始，L2 的结束应该是 L3 的开始，依此类推。由于这个原因，我有许多记录，其中许多 L2 开始不属于 L1 结束，并且随着级别的增加而倍增。插图：

我尝试了什么：在对前 10 名进行排序和切片后，我对每个级别的数百万条记录进行自联接 1 到 1。我有 10 个级别。它在计算上非常昂贵。

我在寻找什么：通用且更便宜的 Map-reduce 解决方案。如果我能在烫伤的情况下得到它会更好。

如果你想在 Scalding 中创建一个包含超过 22 个字段的管道，你会受到 Scala 元组的限制，它不能超过 22 个项目。

有没有办法使用集合而不是元组？我想像以下示例中的内容，遗憾的是它不起作用：

我正在尝试为hadoop上的大矩阵计算制作一种迷你框架；我的意思是，smth like~ Prod(Sum(x, y), z) // (X + Y) * Z，其中 x，y，z - 矩阵或数字，并计算它，并将一些输出结果写入文件。所以我用的是Scalding，矩阵和数字其实是一回事。还有问题，我不知道如何处理分解。

让我解释一下我的意思：如果我们谈论数字（现在没有hadoop,scalding等，只有纯Scala），我们可以这样：

所以你明白我的想法。但是对于 hadoop，我认为是正确的，我们应该制作Jobs并发送它们hadoop；所以我看到的唯一方法是处理矩阵的文件名。但至少存在四个问题：

1. 如何制作正确的 decomp 特征（像这样Expr，我看到的情况，我们只能处理Strings- 文件名）？
2. 如何从任何班级内部运行工作，这不是工作？所以我的意思是一个我可以传递矩阵名称的类，它会发送everyting并在hadoop上计算，然后把结果带回来？我发现最好只发送 hadoop 输入文件，只发送结果输出。（所以一些操作的链？但是如何制作它们，我看到的方式是发送一个分解并计算所有内容的作业？但是如果作业依赖于Expression评估，如何完成这项大工作。另一个变体 - 发送每个 Job ( Sum, Prod, 等) 分开。)
3. 如何操作输出文件？如果我们有很多操作，我们应该存储中间计算的所有结果，以及如何保留文件名？
4. 我的想法对吗？

PS谢谢你，向我展示一些类似想法（链接）的例子会非常有帮助，以便更多地了解hadoop，因为我没有找到很多关于它的信息。最成问题的问题是如何从任何类运行作业。

解决了

所以我找到了一种方法，我得到了一份分解的工作，这不是太聪明的问题，因为我不明白我想要的过程。

好的，所以，在 scalding 中，我们可以轻松地使用矩阵，使用矩阵 api，这没关系 - 以这样的方式：

但是我怎样才能将矩阵从格式转换为那种格式，就像我们通常写的那样？有一些优雅的方法吗？

至

我需要这个来对具有巨大尺寸的矩阵进行操作，并且我不知道行数和列数（如果文件可以给出大小？例如 NxM）。

我试图用TextLine( args("input") )但我不知道如何计算行号。我想在hadoop上转换矩阵，mb还有其他方法如何处理格式？烫伤可以吗？

所以这个问题与问题Transforming matrix format, scalding有关

但现在，我想做背部手术。所以我可以这样做：

但是，在那里，我们遇到了零问题。众所周知，烫伤会跳过零值字段。例如，我们得到矩阵：

烫伤格式是：

使用我上面写的函数，我们只能得到：

这是不正确的。那么，我该如何处理呢？我看到两种可能的变体：

1. 想办法，加零（其实不知道怎么插入数据）
2. 以自己的矩阵格式编写自己的操作（这是不可取的，因为我对 Scalding 矩阵操作感兴趣，并且不想自己编写所有这些操作）

Mb 有一些方法，我可以避免在矩阵中跳过零吗？

是否有任何指针可以让 Scalding 在 HDFS 上处理 LZO Protobuf 数据？

我正在尝试读取存储在二进制 Protobuf 中并使用 Scalding 在 LZO 中压缩的文件。我们可以使用 Elephantbird 来读取这些文件吗？任何指针将不胜感激！

我看过 LzoTraits 和 LzoProtobufScheme？但我不确定我应该如何使用它来读取数据？任何例子都会很棒！

After getting code from git using clone https://github.com/twitter/scalding.git and doing ./sbt update I get:

And later:

I have removed ~/.sbt directory, installed latest Scala and cloned repository anew. The problem remains.

My configuration:

What can be possibly wrong with ./sbt update? Should I install the dependency hadoop-lzo separately and set CLASSPATH to install Scalding? Any other solutions?

Here is the complete installation log:

我正在使用 Scalding 处理具有许多（> 22）字段的记录。在该过程结束时，我想将最终管道的字段名称写入文件。我知道这是可能的，因为 Mapper 和 Reducer 日志显示了此信息。我想在工作本身中获取这些信息，以将其用作穷人模式的基础。如果这不可能做到，那么有没有一种很好的方法可以将类型安全的 Pipes API 用于大型记录（即，不使用任意嵌套的元组或案例类）？