问题标签 [large-data-volumes]

我是一名数学家，偶尔会做一些统计/机器学习分析咨询项目。我可以访问的数据通常较小，最多几百兆字节（而且几乎总是少得多），但我想了解更多关于处理和分析千兆字节/兆字节规模的数据。我需要知道什么，有什么好的资源可以学习？

1. Hadoop/MapReduce 是一个明显的开始。
2. 我应该学习一种特定的编程语言吗？（我现在主要使用 Python、Ruby、R，偶尔使用 Java，但似乎 C 和 Clojure 经常用于大规模数据分析？）
3. 我对整个 NoSQL 运动并不十分熟悉，除了它与大数据有关。什么是学习它的好地方，是否有我应该熟悉的特定实现（Cassandra、CouchDB 等）？
4. 我在哪里可以了解如何将机器学习算法应用于海量数据？我的数学背景主要是在理论方面，绝对不是在数值或近似方面，而且我猜大多数标准 ML 算法并没有真正扩展。
5. 任何其他关于要学习的东西的建议都会很棒！

我有大量数据（几 TB）并且正在积累......它们包含在许多以制表符分隔的平面文本文件中（每个大约 30MB）。大部分任务涉及读取数据并根据一系列谓词语句对观察/行进行聚合（求和/平均+附加转换），然后将输出保存为文本、HDF5 或 SQLite 文件等。我通常使用 R对于此类任务，但我担心这可能有点大。一些候选解决方案是

1. 用 C（或 Fortran）编写整个内容
2. 将文件（表）直接导入关系数据库，然后在 R 或 Python 中提取块（某些转换不适用于纯 SQL 解决方案）
3. 用 Python 编写整个事情

（3）会是一个坏主意吗？我知道您可以在 Python 中包装 C 例程，但在这种情况下，由于没有任何计算上的限制（例如，需要许多迭代计算的优化例程），我认为 I/O 可能与计算本身一样成为瓶颈。您对进一步的考虑或建议有什么建议吗？谢谢

编辑感谢您的回复。关于 Hadoop 似乎存在相互矛盾的意见，但无论如何我都无法访问集群（尽管我可以使用几台未联网的机器）......

我今天刚刚迈出了真正的科学计算的第一步，当时我看到一个数据集，其中最小的文件是 48000 个字段乘 1600 行（几个人的单倍型，对于 22 号染色体）。这被认为是微小的。

我编写 Python，所以在过去的几个小时里我一直在阅读有关 HDF5、Numpy 和 PyTable 的内容，但我仍然觉得我并没有真正理解 TB 大小的数据集对我作为程序员的实际意义。

比如有人指出，数据集比较大，把整个东西读进内存就变得不可能了，不是因为机器内存不够，而是因为架构地址空间不够！这让我大吃一惊。

我在课堂上还依赖于哪些其他假设在输入这么大的情况下不起作用？我需要开始以不同的方式做或思考哪些事情？（这不一定是特定于 Python 的。）

我有一个案例，我需要使用 WCF 使用 wsHttp传输大量序列化对象图（通过NetDataContractSerializer ）。我正在使用消息安全，并希望继续这样做。使用此设置，我想传输序列化的对象图，它有时可能接近 300MB 左右，但是当我尝试这样做时，我开始看到 System.InsufficientMemoryException 类型的异常出现。

经过一番研究，默认情况下，在 WCF 中，服务调用的结果似乎包含在默认情况下包含在单个消息中，该消息包含序列化数据，并且默认情况下此数据在服务器上缓冲，直到整个消息被完全写入。因此，由于该缓冲区已满，服务器正在耗尽允许分配的内存资源，从而导致内存异常。我遇到的两个主要建议是使用流式处理或分块来解决这个问题，但是我不清楚这涉及到什么，以及在我当前的设置（wsHttp/NetDataContractSerializer/Message Security）下这两种解决方案是否可行。到目前为止，我知道使用流式消息安全性是行不通的，因为消息加密和解密需要对整个数据集而不是部分消息起作用。然而，分块听起来可能是可能的，但我不清楚如何使用我列出的其他约束来完成。如果有人可以就可用的解决方案以及如何实施它提供一些指导，我将不胜感激。

我应该补充一点，就我而言，我真的不担心与其他客户端的互操作性，因为我们拥有并控制通信的每一端，并使用共享接口模式将数据传输到任一端。因此，我对任何符合使用带有消息安全性的 wsHttp 来传输使用 NetDataContractSerializer 序列化的对象图的限制的想法持开放态度，我更喜欢不需要大幅更改现有服务和周围基础设施的解决方案。

相关资源：

• 分块频道
• 如何：启用流式传输
• WCF 上的大型附件
• 自定义消息编码器
• InsufficientMemoryException 的另一个发现
• 需要非双工分块通道
• 使用 WCF 和延迟执行流式传输大型内容

我也对可以对这些数据进行的任何类型的压缩感兴趣，但是一旦我可以转换到 .NET 4.0 以便客户端将自动支持 gzip，我可能最好在传输级别执行此操作标题，如果我理解正确的话。

更新（2010-06-29）：

关于我如何得出缓冲消息太大导致我的问题的结论的一些历史。最初我在测试时看到了下面的CommunicationException。

基础连接已关闭：连接意外关闭。

最终，在运行此程序并进行更多日志记录后，我发现导致指定消息出现问题的底层InsufficientMemoryException异常。

未能分配 268435456 字节的托管内存缓冲区。可用内存量可能很低。

这源于以下方法。

System.ServiceModel.Diagnostics.Utility.AllocateByteArray（Int32 大小）

所以换句话说，失败来自分配数组。将序列化的相同数据写入磁盘时，它占用大约 146MB，如果我将其减半，那么我将停止收到错误，但是我没有深入研究破坏缓冲区的特定阈值以及它是否特定于我的系统或不是。

更新（2010-12-06）：

我想此时我正在为以下内容寻找一些澄清。我的理解是，默认情况下，具有消息安全性的 WCF wsHttp 在将响应发送回客户端之前需要在服务器上缓冲整条消息（通常是我返回的整组数据），从而导致我的问题。

可能的解决方案：

• 限制数据大小 - 通过使用某种形式的压缩、编码或限制使用某种类似分页的方法返回的实际数据，以避免消耗传出缓冲区的最大容量。
• 流式传输 - 允许通过 WCF 以流式传输方式发送大量数据，但这与 wsHttp 或 MessageSecurity 不兼容，因为这些技术需要缓冲所有数据。
• 分块通道 - 允许将数据分解为单独的消息，但此时我不确定这对服务合同设计的限制，以及我是否仍然可以将 wsHttp 与消息绑定一起使用。

限制我可以返回的数据只能在一定程度上起作用，并且与 Streaming 选项一样，这些选项需要对 WCF 服务调用之外的许多较低级别的工作进行编码。所以我想我需要知道的是，分块通道的任何可能实现是否可以通过允许将一组数据分解为服务器上的单独消息，然后在客户端上拼凑在一起，从而避开大消息问题这样我就不必更改现有服务合同的接口/形状，并且该过程几乎对每个服务实现的客户端和服务器部分隐藏，同时仍使用消息安全性和 wsHttp。如果分块通道将要求我重写我的服务合同以公开流，那么我不会' 看不出这与 Streaming 解决方案有何不同。如果有人可以简单地为我回答这些问题，我将奖励他们并将其标记为答案。

我需要定期将 Oracle 10G 数据库表中的 1 亿条数据行（平均行长 ~ 100 字节）导出到 SQL 服务器（通过 WAN/VLAN，容量为 6MBits/sec）。到目前为止，这些是我尝试过的选项和一个快速总结。有没有人试过这个？还有其他更好的选择吗？就性能和可靠性而言，哪个选项是最好的？所花费的时间是通过对少量数据的测试计算出来的，然后推断它以估计所需的时间。

1. 使用 SQL 服务器或 SSIS 包上的数据导入向导来导入数据。完成任务大约需要 150 小时。
2. 使用 Oracle 批处理作业将数据假脱机到逗号分隔的平面文件中。然后使用 SSIS 包将此文件 FTP 到 SQL 服务器，然后直接从平面文件加载。这里的问题是预计以 GB 为单位运行的平面文件的大小。
3. 虽然这个选项完全不同，但我什至考虑使用链接服务器在运行时直接查询 Oracle 数据以避免引入数据的选项。性能是一个大问题，我在创建表索引方面对 Oracle 数据库的控制有限。

问候，

单球

我继承了一个与 Web 服务对话的 C# .NET 应用程序，并且该 Web 服务与 Oracle 数据库对话。我需要向 UI 添加一个导出功能，以生成一些数据的 Excel 电子表格。

我创建了一个 Web 服务函数来运行数据库查询，将数据加载到 DataTable 中，然后返回它，这适用于少量行。但是，在完整运行中有足够的数据，客户端应用程序会锁定几分钟，然后返回超时错误。显然，这不是检索如此大的数据集的最佳方式。

在我继续提出一些巧妙的方法来拆分电话之前，我想知道是否已经有一些东西可以处理这个问题。目前我正在考虑 startExport 函数，然后重复调用 next50Rows 函数，直到没有数据为止，但是由于 Web 服务是无状态的，这意味着我将不得不保留某种 ID 号并处理关联的权限。这意味着我不必将整个数据集加载到 Web 服务器的内存中，这是一件好事。

因此，如果有人知道通过 N ASMX Web 服务检索大量数据（表格格式）的更好方法，请告诉我！

给出了一个 rpc 服务器，它每天接收数百万个请求。每个请求 i 需要处理时间 Ti 才能得到处理。我们想在任何时候找到第 65 个百分位的处理时间（当处理时间根据它们的值按升序排序时）。我们无法存储过去所有请求的处理时间，因为请求的数量非常大。所以答案不必是精确的第 65 个百分位，您可以给出一些近似的答案，即处理时间大约是精确的第 65 个百分位数字。

提示：它与如何在不存储所有数据的情况下为非常大的数据存储直方图（即概览）有关。

我们正在设计一个大型网络抓取/解析项目。基本上，脚本需要遍历网页列表，提取特定标签的内容，并将其存储在数据库中。对于大规模（数千万页？）执行此操作，您会推荐什么语言。.

我们使用 MongoDB 作为数据库，所以任何具有可靠 MongoDB 驱动程序的东西都是一个加分项。

到目前为止，我们一直在使用（不要笑）PHP、curl 和Simple HTML DOM Parser，但我不认为它可以扩展到数百万个页面，特别是因为 PHP 没有适当的多线程。

我们需要一些易于开发的东西，可以在 Linux 服务器上运行，具有强大的 HTML/DOM 解析器来轻松提取该标签，并且可以在合理的时间内轻松下载数百万个网页。我们并不是真的在寻找网络爬虫，因为我们不需要跟踪链接和索引所有内容，我们只需要从列表中的每个页面中提取一个标签。

我有一个拥有大约 100,000 个独特页面的网站。

(1) 如何为所有这些链接创建站点地图？我应该将它们平放在一个大型站点地图协议兼容文件中吗？

(2) 需要在有 1000 项查询限制的 Google App Engine 上实现这一点，并且我所有的个人站点 URL 都存储为单独的条目。我该如何解决这个问题？

我有几个包含需要导入新格式模式的简单数据的数据库。我想出了一个灵活的模式，但它依赖于旧数据库的关键数据存储在一个表中。该表只有一个主键、一个外键（都是 int 的）、一个日期时间和一个小数字段，但是将两个旧 DB 的行数相加表明这个新表的总行数约为 200,000,000 行。

我该如何处理这么多的数据？这是可以追溯到大约 10 年前的数据，并且确实需要可用。幸运的是，我们将来查询时甚至不需要提取其中的 1%，但它确实需要可访问。

我的想法是基于一年有多个表、（源数据的）供应商等 - 甚至每年有一个数据库，最近 2 年在一个数据库中（其中还包含用于管理的存储过程这一切。）

任何和所有的帮助、想法、建议都非常、深刻、非常感谢，

马特。