首页 > 解决方案 > 传输原始数据,例如 int、float-tuple:解析字符串或转换为字节数组更有效?

问题描述

在进行大量 MapReduce 操作时,我希望传输的数据开销尽可能小。我目前需要传输很多东西之一是 (int,float) 元组等。我目前正在尝试在两种传输方式之间进行选择:

  1. 序列化为字符串,例如“4,3.4”。如果我使用 ASCII-US,我猜测传输对象的大小将只是字符串形式所需的字符数量,即如果我的整数很长或者我的浮点数很精确,那么对象可能会变得很大。

  2. 序列化为字节数组:int 使用 4 个字节,float 使用 4 个字节。这样我就一直使用 8 个字节。在特殊情况下,我可以少用字符串,但我猜测字符串方式平均会更贵。

因此,我目前倾向于第二种选择,虽然转换比序列化为字符串稍微复杂一些,但它应该更有效,对吧?

标签: javamapreducebigdatabyte

解决方案


这是一个相当复杂的问题。

  • 一方面,将数字从二进制转换为文本形式……然后再转换回来,计算成本(相对)昂贵。转换为十进制特别昂贵,因为转换涉及重复除/乘以 10。

  • 另一方面,如果数据值(平均)很小,则文本表示在编码时可能(平均)占用更少的字节。根据网络的端到端速度和延迟(包括 NIC、虚拟化等),更小的在线表示可能会导致更大的吞吐量。

  • 另一方面,如果通信成本在整个计算中只是微不足道的一部分,这将是没有意义的。

我的建议是:

  1. 提防过早的优化!
  2. 在您的环境中对编码 + 传输 + 解码的两种替代方案(二进制和文本)进行基准测试。确保您使用的是典型的实际数据的测试数据来执行此操作。
  3. 对整个应用程序进行基准测试。(这假设您注意了第一点!)
  4. 确定二进制与文本表示的差异是否会对完整应用程序在真实数据上的整体性能产生显着影响
  5. 重做代码......如果你的测量等告诉你这将是值得的。

注意:如果测量告诉您二进制与文本之间的差异对您的应用程序实际上很重要,这可能表明您的计算在通信与计算方面花费了太多时间。看看你是否可以减少沟通是值得的;例如,通过改变计算的粒度,或移动的数据量。


最后 ...

在进行大量 MapReduce 操作时,我希望传输的数据开销尽可能小。

这不应该是你的目标。目标应该是:

  • 使整个应用程序运行足够快以满足性能要求。
  • 通过不试图实现超出实际需求的性能来优化开发时间。

像“尽可能快”或“尽可能高效”或“尽可能小”这样的目标可能是危险的努力下降。你应该尽量避免它们。


推荐阅读