作者注：本文最初发表于2015年12月16日。
上周四在2015中国存储峰会“云计算与业务连续性”分论坛的开场演讲上，我提出了“云计算本是O2O”的观点。具体点说，从"Online to Offline"（线上到线下）的字面含义适度引申，一方面强调"Offline to Online"，即云计算可以理解为把线下的服务器和网络等物理资源（数据中心作为支撑）搬到线上销售（当然，做起来远没有这么简单）；另一方面，如果狭义的用Online代表互联网，Offline代表传统企业应用，也可以诠释互联网和传统企业结合日益紧密的云计算发展趋势。
偷换概念是肯定的，但也不尽然。“云计算就是O2O”是两个多月前参加AWS re:Invent 2015时，讨论新推出的AWS Import/Export Snowball服务时得到的启发。虽然在上面的演讲中只有约十分之一的篇幅提到了这个实物形态很不像“雪球”的产品，其思路却真与我们常说的（正牌）O2O颇有渊源。
"Never underestimate the bandwidth of a Fedex truck."（永远不要低估一辆联邦快递卡车的带宽）是re:Invent 2015大会第一天上午主题演讲中引出Snowball之前，大屏幕上打出的一句话，也同样适用于之前就已存在的AWS Import/Export (Disk)服务。简单的说，导入/导出（Import/Export）服务是利用直接寄送（装有大量数据的）硬盘到/从AWS，利用Amazon的高速内部网络（而不是通过互联网）将数据更快、更低成本的传输进/出AWS的云中。
主题演讲结束，展厅开放，我就第一时间奔向AWS的新服务展台寻求与Snowball的近距离接触，却不经意间上了AWS re:Invent的官推……
对成长于互联网时代的开发者来说，看到我们印象中“高大上”的云计算公司也用这种“宅男拷片”式的手段来传输数据，未免会觉得新奇。AWS当然比谁都清楚，这种想法并非其首创。2009年5月21日，介绍AWS Import/Export服务的官方博客，坦率的以Andrew Stuart Tanenbaum教授的名言"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."（永远不要忽略一辆载满磁带在高速公路上飞驰的卡车的带宽）开篇。据粗浅的考证，这句话在2002年出版的Computer Networks第四版里就已经有了，那时候还没有AWS呢。
大型企业将备份磁带通过Iron Moutain（铁山）等专业信息管理公司（而非常见的快递公司）运输到异地保存，记得2010年7月我还在华尔街见过Iron Mountain的卡车。这种做法的经济性和可行性都好于昂贵的专线网络，又比普通的快递渠道专业且安全——虽然以Iron Moutain等公司为主角的磁带丢失事件也不时见诸于报端……
如果说磁盘就是当代的磁带，AWS Import/Export运输磁盘的方式模仿多于创新。当然，AWS的做法在云计算公司里已经是开先河之举了，Microsoft Azure提供类似服务要晚四年多呢。
工作（而非运输）状态下的Snowball设备
AWS Import/Export Snowball则在原有的Import/Export (Disk)的基础上做了进一步的创新，不仅递送物升级，针对运输环节加以考虑周全的设计，还整合了母公司Amazon（亚马逊）的电商积累，颇有“企业级O2O”的风采。
云计算也好，O2O也罢，一项新服务的推出，首要的一点是了解其对应的需求。从我连续两年参加re:Invent大会的感受来看，AWS争夺大中型企业客户的决心越来越明显，不断推出颇具针对性的产品/服务。譬如，re:Invent 2015大会第二天上午联合Intel（英特尔）发布的X1大内存实例，将于2016年上半年推出，采用四路2.3 GHz Intel Xeon E7-8880 v3 (Haswell)处理器，单实例拥有超过100个vCPU，高达2TB的实例内存，8倍于之前的R3实例（最大的r3.8xlarge拥有32个vCPU，244GiB内存）。R3实例可以支持（被SAP定义为）部门级的SAP HANA One，主要通过横向扩展（Scale-out）来运行OLAP应用；X1实例更强的纵向扩展（Scale-up）能力，使其可以很好的支持SAP HANA及大型OLTP应用，更容易满足大中型企业客户的需求。
AWS中文官网上的EC2 X1实例介绍，基于今年推出的至强E7 v3（四路配置）
内存的容量都有2TB，企业要处理的数据量在10TB以上应属正常。当企业需要迁入云中的数据超过一个硬盘的容量，再用快递单个硬盘的方式，不仅效率低，而且不安全。为了解决这一问题，AWS Import/Export Snowball的考虑可谓周全。
首先看存储。我们不难想到：既然运送硬盘不够，何不运送一个小型的阵列？如同不公开数据中心内部具体硬件情况一样，AWS没有透露Snowball内部的硬件细节。根据我从展台了解的信息，Snowball的裸容量为40TB，允许一个内部存储单元（硬盘）失效，可以理解为使用了某种类似RAID的技术。由于使用了压缩技术，（单个）Snowball的存储容量可达50TB——这是官方数据，前面的几句“道听途说”仅供参考。
不同连接速率下传输50TB数据所需天数（来源：AWS）
其次看网络。单个（3.5英寸）硬盘顺序传输时的带宽在千兆以太网（GbE）之上，Snowball作为一个小型盘阵（或者说，一堆硬盘的集合），如果还用千兆以太网，显然丧失了相对于AWS Import/Export (Disk)服务的优势。因此，Snowball采用万兆以太网（10GbE）简直是必然之举，这使其可以在一天之内完成50TB数据的传输，而1Gbps（千兆以太网级别）的互联网连接则需要差不多一周的时间。
具体到网络的物理接口，Snowball支持RJ-45（铜缆）和SFP+（光纤）两种，以应对不同的客户环境。
Snowball后部护板内侧的绕线盘，可以同时收纳铜缆和光纤（带SFP+模块，如手持部分）
re:Invent 2015上展出的Snowball样品后部特写，还不支持SFP+，只有RJ-45接口
Snowball前部的显示/控制界面，RJ-45和SFP+可分别配置（注意屏幕上方物理按键的灯点亮）
第三看扩展。Snowball号称PB级（petabyte-scale）数据传输解决方案，支持最多10个设备并行工作，总容量可达500TB（0.5PB），总带宽100Gbps，完全填满数据仍然只用不到1天的时间。作为对比，通过1Gbps的互联网连接传输250TB（5个Snowball）的数据，需要差不多一个月的时间。
不同连接速率下传输250TB数据所需天数（来源：AWS）
第四是租用。即使是大型企业，也不会经常性的向云里迁移大量数据，没有必要拥有自己的Snowball设备。所以Snowball采用租用方式，每次导入（暂时还不支持导出）作业的费用是200美元，由UPS（而不是Fedex）承担往返的运送工作，其中包括10天在客户处传输数据等工作的时间，超过10天后每天加收15美元。导入数据本身免费，存储按照Amazon S3的标准计费，导出数据则要收3美分每GB的传输费。
Snowball的前部嵌入一个亚马逊的Kindle，其采用的电子墨水（E-ink）技术在关闭电源的情况下也可以显示（之前设置好的）运送目的地等内容，起到快递单的作用
说到快递，就是Snowball与O2O沾边，甚至超越某些O2O之处了。因为像外卖送餐服务这样的O2O，除了时间限制，其运送物内容也不适合标准的快递服务，往往要建立起专门的运送队伍。可能有人会说，大型的磁盘阵列都可以用快递运送，Snowball这种小型的磁盘阵列有什么不可以？当然可以，但是对外包装有很高的要求。磁盘阵列通常是出厂后一次性运送到客户处拆包安装，而像Snowball这种使用模式，用户几天后还要再递送回来，包装环节显然增加了流程的复杂度和损坏的风险。
我们知道，一般的磁盘阵列都是很脆弱的。曾有人说，磁盘不抗震，Snowball用的为什么不是闪存？50TB这个容量闪存当然可以达到，但造价未免也太高，性能上又没必要（在持续传输的场景下，几个硬盘足以填满万兆以太网的带宽）；如果损坏，更难以承受。所以，如果不能解决包装问题，难免要用专人来运送。
Snowball设备前后挡板展开的状态（收起时叠放在顶部，如前面图）
AWS不愧是亚马逊的子公司，不对快递公司和客户抱有不切实际的幻想。他们把Snowball设计成了一个自包装的专用设备，外壳以塑胶包裹，重50英镑（不到23公斤），扣好前后部的挡板，即可防雨防尘，并能承受8.5G的撞击（现代硬盘在关机状态下抗振能力还凑合，加上适当的保护更没问题），以应对恶劣天气、野蛮装卸、途中颠簸等考验。这个自带的包装箱可以防止恶意侵入，内部存储的数据采用256位加密，密钥由AWS的KMS（密钥管理服务）管理，与Snowball分离，避免数据遭到篡改。
前挡板盖好的Snowball设备，可以看到保护Kindle的玻璃。设备后方的白色软球体象征“雪球”
解决了包装难题之后，循环使用与通用快递服务的结合，使得Snowball能够以最低的运营成本应对规模（使用量）的变化，真正体现了云计算和O2O的有机结合。
AWS Import/Export Snowball从美国标准和美西（俄勒冈州）区域的导入服务起步，未来会增加导出服务以满足大规模数据分发等场景的需求，AWS还在研究持续的地理位置追踪等增强功能。
