标签: distributed

我一直在研究MapReduce,它似乎是实现容错分布式计算的一种非常好的方法.我阅读了很多关于该主题的论文和文章,在一系列虚拟机上安装了Hadoop,并做了一些非常有趣的测试.我真的认为我理解Map和Reduce步骤.

但这是我的问题:我无法弄清楚它如何帮助http服务器日志分析.

我的理解是大公司(例如Facebook)使用MapReduce来计算他们的http日志,以便加快从中提取受众统计数据的过程.我工作的公司,虽然比Facebook小,但每天都有大量的网络日志需要计算(100Go每月增长5%到10%).现在我们在一台服务器上处理这些日志,它运行得很好.但是,作为一种即将有用的优化,可以立即想到分发计算工作.

以下是我现在无法回答的问题,非常感谢任何帮助:

• MapReduce概念能否真正应用于网络日志分析？
  
• MapReduce是最聪明的做法吗？
  
• 您将如何在各种计算实例之间拆分Web日志文件？

谢谢.
萨科

我正在寻找有关如何最好地考虑设计高级应用程序协议以在最终用户设备和服务器之间同步元数据的指导.

我的目标:用户可以在任何设备或网络上与应用程序数据进行交互.此协议的目的是通过服务器将在一个端点上进行的更改传达给其他端点,并确保所有设备都保持应用程序数据的一致性.如果用户在一台设备或Web上进行更改,协议会将数据推送到中央存储库,其他设备可以从中央存储库中提取数据.

其他一些设计思路:

• 我将其称为"元数据同步",因为有效载荷将非常小,形式为对象ID和关于这些ID的小元数据.当客户端端点通过此协议检索新元数据时,它们将基于此元数据从外部源获取实际对象数据.获取"真实"对象数据超出了范围,我只是在谈论元数据同步.
• 使用HTTP进行传输,使用JSON进行有效负载容器.问题基本上是关于如何最好地设计JSON有效负载模式.
• 我希望在Web上以及桌面和移动设备上轻松实现和维护.最好的方法是简单的基于计时器或基于事件的HTTP请求/响应,而没有任何持久性通道.此外,你不应该有博士学位阅读它,我希望我的规格适合2页,而不是200页.
• 身份验证和安全性超出了此问题的范围:假设请求是安全的并经过身份验证.
• 目标是设备上数据的最终一致性,它并非完全是实时的.例如,用户可以在离线时在一台设备上进行更改.再次上线时,用户将执行"同步"操作以推送本地更改并检索远程更改.
• 话虽如此,协议应该支持这两种操作模式:
  • 在设备上从头开始,应该能够拉出整个元数据图片
  • "随时随地同步".当并排查看两个设备上的数据并进行更改时,应该很容易将这些更改推送为其他设备可以近实时接收的短消息(取决于它何时决定联系服务器进行同步).

作为一个具体的例子,你可以想到Dropbox(它不是我正在研究的,但它有助于理解模型):在一系列设备上,用户可以管理文件和文件夹 - 移动它们,创建新的,删除旧的等.在我的上下文中,"元数据"将是文件和文件夹结构,但不是实际的文件内容.元数据字段将类似于文件/文件夹名称和修改时间(所有设备应该看到修改的同一时间).

另一个例子是IMAP.我没有阅读协议,但我的目标(减去实际的消息体)是相同的.

感觉有两个宏大的方法如何做到这一点:

• 交易消息.系统中的每个更改都表示为delta,端点与这些增量进行通信.示例:DVCS变更集.
• REST:将对象图作为一个整体或部分进行通信,而不必过多担心单个原子的变化.

编辑:一些答案正确地说,有关该应用程序的信息不足以提供足够好的建议.该应用程序的确切性质可能会分散注意力,但一个非常基本的RSS阅读应用程序是一个足够好的近似.所以我们假设应用规范如下:

• 有两个类:提要和项目.
• 我可以添加,重命名和删除Feed.添加订阅订阅它并开始接收该订阅源的项目.我还可以在UI中重新排序Feed显示顺序.
• 当我读取项目时,它们被标记为已读.我无法将它们标记为未读或与它们做任何其他事情.
• 基于以上所述,对象模型是:
  • "feed"具有属性"url","displayName"和"displayOrder"(displayOrder是UI的供稿列表中的供稿索引;在本地重新排序供稿会更改所有供稿的displayOrder,以使索引保持唯一且顺序).
  • "item"具有属性"url"和"unread",以及多对一关系"feed"(每个项目属于一个Feed)."url"也表现为项目的GUID.
  • 实际项目内容在每台设备上本地下载,不属于同步.

基于这种设计,我可以在一台设备上设置我的应用程序:添加一堆供稿,重命名并重新排序它们,并读取它们上的一些项目,然后标记为未读取.当我切换设备时,其他设备可以同步配置并向我显示具有相同名称,顺序和相同项目读取/未读状态的相同馈送列表.

(结束编辑)

我想在答案中:

• 我遗漏了什么重要的东西？限制,目标？
• 有什么好的背景阅读？(我意识到这就是许多计算机科学课程在很长的篇幅和细节上谈论的内容......我希望通过查看一些速成课程或掘金来使其短路.)
• 这些协议的一些很好的例子,我可以建模,甚至开箱即用？(我上面提到了Dropbox和IMAP ......我应该阅读IMAP RFC.)

我试图建立一个分布式文件系统中文件可用性的数学模型.我在MathOverflow上发布了这个问题,但这可能也被归类为CS问题,所以我也在这里给它一个镜头.

系统的工作方式如下:节点在r*b遥控节点存储文件(使用擦除代码编码),其中r是复制因子,b是整数常量.如果远程节点中至少有b个可用并且返回其文件的一部分,则擦除编码文件具有可以恢复文件的属性.

最简单的方法是假设所有远程节点彼此独立并具有相同的可用性p.根据这些假设,文件的可用性遵循二项分布,即二项分布http://bit.ly/dyJwwE

不幸的是,这两个假设可能会引入一个不容错误的错误,如本文所示:http://deim.urv.cat/~lluis.pamies/uploads/Main/icpp09-paper.pdf .

克服所有节点具有相同可用性的假设的一种方法是计算可用/不可用节点的每种可能组合的概率,并取所有这些结果的总和(这是他们在上面的论文中建议的那种,比我刚才描述的更正式.您可以将此方法视为具有深度r*b的二叉树,并且每个离开是可用/不可用节点的一种可能组合.文件的可用性与您通过> = b可用节点到达的可能性相同.这种方法更正确但是具有Ordo http://bit.ly/cEZcAP的计算成本.此外,它不涉及节点独立性的假设.

你们有没有一个好的近似的想法,它引入的误差比二项式分布 - aproximation少,但计算成本比http://bit.ly/d52MM9 http://bit.ly/cEZcAP好？

您可以假设每个节点的可用性数据是由一组元组组成的(measurement-date, node measuring, node being measured, succes/failure-bit).使用此数据,您可以计算节点之间可用性与可用性差异的相关性.

是否存在用.NET实现的分布式共享内存系统的现有库/框架/产品,或者可以从.NET客户端轻松访问？

谷歌搜索提供了一些学术论文的链接,但我找不到任何真正的实现.

注意:我最感兴趣的是在局域网上运行的东西,而不是"云".

我正在寻找一种通过网络(lan)进行分布式计算的方法.在C/C++中是否有用于此目的的良好框架或库.

在REQ/REP套接字中,如果套接字向死(断开连接)节点发送请求,则消息不会被传递并停留在占用内存的消息队列中.如何清理这些未传递的消息(比方说,队列中的消息超过1分钟)？

谢谢!

我需要构建一个依赖于在站点之间复制大文件的分布式系统.

我想过使用像bittorrent这样的p2p技术来节省带宽,提高可靠性.

我非常错吗？

有没有人构建过这样的解决方案？

你推荐哪些图书馆？

我正在开发一个用于通过HTTP进行通信的Java库,我想测试其可靠性和性能,以防网络问题,如数据包丢失,高延迟,低带宽和拥塞.我正在使用Apache的httpclient库从客户端进行连接,而Java自己的com.sun.net.httpserver.HttpServer用于启动HTTP服务器.

是否有可用的库来做这种事情,或者我应该自己推出？我想我可以尝试将自己的org.apache.http.conn.scheme.SchemeSocketFactory插入客户端,并模拟上面提到的几个问题,但我更喜欢使用已经有效的东西:-)

这类似于为单元测试创​​建TCP网络错误的问题,但我正在寻找在Linux上涉及Java的解决方案.我看过针对该问题的建议点击,但我不确定它能提供我正在寻找的东西.

要使用电子邮件相互通信,用户不需要使用相同的"提供者"(某些用户可能使用gmail,其他yahoo或hotmail,他们仍然可以互相编写电子邮件).不幸的是,它与社交网络不同.使用Facebook的用户无法使用Google+查看用户的帖子,评论,喜欢和分享,反之亦然.

但为什么它应该是那样的？让我们想象一下以下的架构.每个用户都可以使用他/她喜欢的任何提供商"广播".RSS格式提供了这种可能性.任何用户都可以选择任何"提供者"来生成他/她的RSS提要并查看他/她订阅的用户的RSS提要.所以,只要使用RSS,我们就可以构建一个类似Twitter的分布式系统(你可以发帖,你可以关注其他但你不能分享).

这种方法仍然缺少的是评论其他帖子的可能性(喜欢,不喜欢或评级也可以被视为评论).理论上,人们可以用与帖子相同的方式发布/广播评论.事实上评论也是帖子,唯一的区别是他们"附加"到其他帖子.因此,可以生成像XML这样的RSS,其中一些帖子(那些是评论)有额外的标签,其中包含评论的帖子的URL.

通过RSS的这么小的扩展,可以构建分布式社交网络或分布式社交新闻系统(如Reddit).

这个方向有没有发展？

我已阅读分布式tensorflow文档和这个答案.

根据此,在数据并行方法:

• 该算法在各个核之间分配数据.
• 每个核心独立地尝试估计相同的参数
• 然后,核心彼此交换它们的估计值,以得出对该步骤的正确估计.

在模型并行方法中:

• 该算法将相同的数据发送到所有核心.
• 每个核心负责估计不同的参数
• 然后,核心彼此交换它们的估计值,以得出所有参数的正确估计值.

这些方法如何做In-graph replication和Between-graph replication有关？

这篇文章说:

例如,可以在不同的GPU上并行地训练网络中的不同层.此培训过程通常称为"模型并行性"(或TensorFlow文档中的"图中复制").

和:

在"数据并行"(或TensorFlow文档中的"图形间复制")中,您为每个设备使用相同的模型,但使用不同的训练样本在每个设备中训练模型.

那是准确的吗？

来自tensorflow文档页面中链接的Tensorflow DevSummit视频: 看起来数据被拆分并分发给每个工作人员.那么不In-graph replication遵循数据并行方法吗？