snowmobile 狂想曲

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. — Tanenbaum, Andrew S. (1989). Computer Networks. p. 57.

这是 CS 毕业生的老朋友（大家学 OS 的时候都看过他的Operating Systems: Design and Implementation 吧），Professor Tanenbaum 在近三十年前的一个精准的断言。snowball/snowmobile 充分证明了它至今还非常有效。九零年还有个两页纸的 RFC1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers，一针见血地指出：

Avian carriers can provide high delay, low throughput, and low altitude service. The connection topology is limited to a single point-to-point path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring. This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by IEEE802.3.

可见，snowball/snowmobile 的概念不是 amazon 首创。在我们 tubitv.com，过去数年，好莱坞的 studio 给我们提供电影的主要形式也是通过 fedex 寄硬盘。不过，amazon 是第一个严肃考虑数据传输问题，并试图将其标准化，做成服务的公司。

wiki 上（请自行搜索 Zettabyte）说有人估计 2013 年人类一年的数据产量是 4ZB，也就是 4000 EB，或者说四百万 PB。思君思国思社稷的程序君陷入了深深的沉思。这么多数据，需要 40, 000 辆能够装载 100PB 的 snowmobile 才拉得完。

那么，问题来了：

挖掘机技术哪家强？

按照人类产生数据的速度，越来越多的公司会达到 EB 级，每次十几几十辆货车运来运去太不合适。有什么更好的运输方式么？

我估计 2018 年，aws 在客户的墙裂要求下，发布 snow train：

一火车可以装载数 EB 的数据。不过，由于北美的铁路系统不够健全，最终 snow train 运营的主力放在了我大宋朝。

到了 2020 年，snow train 已经无法满足人民群众日益增长的数据产量和落后的数据运力的矛盾，snow container 应运而生：

（憋笑，我用 skitch P 的）

20万吨巨轮，装载量 10000 个 container，每个 container 1EB（一个 container 现在可以装 100PB，三年后增长 10 倍不过分），总共可以装载 10 ZB 的数据量。

这样，数据的运输不仅容量足以保证，还可以跨洲了 —— 由于气候变暖引发的巨额的电费（冷却系统），各大 data center 都迁到了俄罗斯远东，阿拉斯加和冰岛。Data center 里的数据经由一辆辆卡车运出，然后集中到火车站，火车再拉去港口，最后万吨巨轮扬帆启航。

2030年，人类成功把月球打造成一个旅游基地。然而，月球开发总公司发现占 60% 的游客的程序员群体，对整体旅游环境抱怨最大的是网速太慢，还总掉线。从 github 上 pull 代码，上 stackoverflow 查代码，用 npm install（mix deps.get / brew install）等安装依赖耗时太长无法忍受，从而影响解 bug 做 feature 的心情更严重干扰了旅行的体验。faceless，sneakchat 等巨头更是威胁如果无法解决网络的问题，将会把月球从员工福利休假计划中移除。痛定思痛，月球开发总公司联合 amazon 共同打造了 snow rocket —— 第一批货物是 wikipedia，npm registry（前端势力大啊），apt 源镜像以及群众呼声最高的 stackoverflow 全镜像。哦，当然，为了照顾人口众多的中国程序员，还联合微信镜像了公众号的全部内容。

好吧，我编不下去了。我觉得数据的存储手段和传输方式未来 10 年内会有剧变，也许生物科学的黑科技能够解决问题（毕竟一克 DNA 含有几百 EB 的数据呢），否则，按照现在创造数据的增速，那时地球要被硬盘淹没了。

回到 snowmobile。按照 amazon 的说法，1EB 数据可以在 6 个月内完成迁移。以目前公布的 snowmobile 的价格，$0.005/GB 每月，迁移 1EB 数据的存储成本是 30M USD（5 x 1000 x 1000 x 6），对拥有这个量级的数据的公司来说，考虑到存储 1EB 数据到 S3 上要 27M USD / month，这个价格还是可以接受的。

snowmobile 现在没有公布卡车的集装箱内部的细节，不过可以想象，它内部会有：

• 1000+ 个 100TB 的 snowball？没理由不复用现有的 snowball 吧。此外，硬件都有 MTBF（Mean time between failure），上千个 snowball，某一两个出现故障的几率大大增多，所以需要一些冗余的 snowball standby。
• 高可用电源集群 + 若干柴油发电机。为这么些磁盘及相关设备供电不是个易事。
• 若干万兆口 + 若干千兆口。假设一个月留给运输，那么单向的数据拷贝要在 75 天内完成。1EB 的数据在 75 天内完成复制，意味着至少需要 13 个万兆口并行拷贝 - 1EB / (10Gbps / 8) / 86400 / 75。考虑到其他因素的影响，20 个万兆口再加 50 个千兆口应该能满足数据传入传出的需求。
• 大容量交换机。

假设有个 EB 量级的公司要移动数据（不管是移到 aws 还是从 aws 移到自建的 data center），并且打算使用 snowmobile，可能会发生什么威胁？

一辆或者几辆货车遭遇交通事故

10辆货车中的某一辆发生交通事故的概率不小。这样的事情一旦发生，数据交付的时间会大大延迟，所以，除了货车内部的数据冗余外，货车和货车间也需要类似 RAID5 的冗余机制。这样，可以保证交付不受影响。所以，上述最终的成本可能增加 1/3，至 40 M USD。

车队受到劫持

对于互联网公司来说，数据就是生命。当数据固定在某个数据中心时，它的安全性是最高的，好比放在银行金库里的钞票；然而，当数据物理移动时，安全性最低的，同比运钞车。走在高速公路上的 snowmobile 对于数据大盗而言，就是待宰的羔羊。以前劫持数据需要用脑，是智商的猫鼠游戏；现在用枪就可以了，谁狠谁上。

所以，对于极其重要的数据，私人安保公司护航必不可少，说不定还得动用直升机或者卫星追踪。（到 snow container 时代就是军舰，甚至航母护航，画面好美）

disclaimer：本文并非严肃的技术分析，只是一些仅仅通过 amazon 给出的 snowmobile 的官方信息做出的一些狂言妄语而已。

今日 Werner Vogels 的 keynote 信息量太大，我还没来得及整理思绪。先把今晨失眠后写下的胡言乱语发出来，抛砖引玉。