我们有100万个数据集，每个数据集大约180mb。因此，我们的数据总大小约为185T。每个数据集都是普通的DEL文件，只有三列。前两列是行键，最后一列是行的值。例如，第一列是A，第二列是B，第三列是C.A的值是数据集编号，因此A固定在一个数据集中，其范围是1-1百万。 B是位置编号，B可以是1到3百万。
我们计划做的是给出任意一组B的非重叠范围，如1-1000,10000-13000,16030-17000 ......，我们计算每个数据集的值的总和所有这些范围，并以秒为单位返回前200个数据集编号（A）。
对于bigdata中的任何一位专家都知道我们需要多少个服务器才能处理这个案例？我的老板相信10台服务器（每台16个核心）可以用50,000美元的预算完成。你觉得它可行吗？
答案 0 :(得分：0)
我认为在这种情况下，Microsoft Azure等服务可以成为您的朋友。我认为您的预算将使用“按使用付费”服务。您可以决定要用来处理数据的服务器/实例数量。
我认为一个小问题可能是您的数据目前的格式化方式。我肯定会考虑使用Azure表存储，并且首先要在这样的服务中获取数据。一旦完成，您现在拥有一个更“可查询”且可靠的数据存储。从那里，您可以使用您选择的语言与该数据进行交互。使用表存储，您可以创建分区键。
如果您有想要使用的分区，则可以创建一个服务，您可能会提供分区或更可能的分区范围，它将处理该分区。您将能够调整实例的大小以及应该驱动它们的硬件，通过这样的操作，您可以确定1个实例处理x记录需要多长时间的平均值。也许你可以写一些关于性能的日志。
获得日志后，可以很容易地确定过程需要多长时间才能获得合理的准确度。然后，您可以开始向服务添加更多实例，从而开始以更快的速度处理数据。
表存储也设计用于处理大数据集，因此通过这方面的文档，您将找到许多可以使用的关键功能。
老实说，有很多方法可以解决这个问题，这只是我过去使用的一个选项，当时它对我有用。
如果这对您来说是一个可行的选择，我会确保将您的数据和服务放在同一个数据中心。虽然我假设您的文件中有某种形式的序列，但您也可以保留存储您的总和值的占位符以供将来使用，如果您的数据在将来增长，您只需添加新数据并再次运行服务即可更新系统。
如果不确定你能否以某种方式或其他方式保留你的和值，我就不会继续这个旅程，否则如果你将来需要再次获得价值，你将再次需要从头开始。
我设法找到一个关于上面提到的处理大数据的服务的快速写法。也许它可能能够进一步帮助你。 http://www.troyhunt.com/2013/12/working-with-154-million-records-on.html